說實話今年 DevDay 放出 20 項發(fā)布時我的第一反應不是又來了而是終于來了。OpenAI DevDay 2026 這場 keynote 從 GPT-6.1 Sol 開場到 dots、ChatGPT Spaces 兩個產(chǎn)品級功能收尾全程看下來最強烈的感受是模型性能的比拼已經(jīng)不是重點了他們把大量篇幅花在了智能體怎么被團隊真正用起來這件事上。這篇文章把我現(xiàn)場準確說是線上直播加會后文檔看到的東西、實測的感受、踩過的坑都整理出來給還沒時間啃發(fā)布會和文檔的開發(fā)者一份直給的經(jīng)驗參考。1. GPT-6.1 Sol 到底升級了什么必須先說清楚GPT-6.1 Sol 不是 GPT-6 的跳代版本OpenAI 自己定義是6.x 時代第一款工程化型號。名字里的 Sol 取自 solar他們對這款模型的定位是能曬著太陽連續(xù)跑一天任務的模型說白了就是專門為長時間、多步驟的智能體任務設計的而不是為了單純刷榜。1.1 模型定位從考試型到工作型過去兩年模型比拼的是單輪回答質量現(xiàn)在大家真正頭疼的是讓模型在一個長任務里連續(xù)決策上千步能不能不跑偏、不重復、不突然失憶。GPT-6.1 Sol 的幾個核心技術指標都是沖這個去的我挑重點說。上下文窗口拉到 4M token。注意不是支持而是可穩(wěn)定使用?，F(xiàn)場演示直接把一份大型代碼倉庫的索引文件塞進去做整體重構全程沒有分段處理這個能力對大型項目管理是質變。輸出側延遲下降明顯。官方給的數(shù)據(jù)是首 token 延遲平均降低 38%我實測一個中等復雜度的流式回復體感上確實接近實時。工具調用可靠性提升。Function calling 在連續(xù) 50 輪調用測試里的成功率從上一代的 91% 提到 96.4%。這對智能體場景很關鍵——以前跑長途任務一半失敗是模型自己把工具參數(shù)編錯了。我沒法驗證官方每個數(shù)字但從文檔里能看出一個明顯變化GPT-6.1 Sol 的 reasoning effort 參數(shù)默認值改了系統(tǒng)更傾向于在后臺做多路徑推演而不是只給一條最優(yōu)路徑。好處是復雜任務的成功率上去了代價是輸出長度變長后面算成本時要注意。1.2 基準和實測分數(shù)高不等于好用官方放出的對比表里SWE-bench Verified 從 GPT-6 的 78.2% 漲到 83.5%GAIA 的 avg 從 71.4% 到 76.1%Multilingual MMLU 也有 5 個點左右的提升。這些數(shù)字在發(fā)布現(xiàn)場很正常但我自己跑了三個真實任務感受會更具體。第一個任務把一個遺留 Python 服務的依賴從 pip 遷移到 uv60 多個包的版本兼容沖突模型全程自己查文檔、改配置、跑測試只在中途問了我一次是否允許執(zhí)行 shell 命令。第二個任務讓模型把一份 PDF 發(fā)票批量轉成結構化 JSON100 份文件里第一次跑就有 93 份直接成功剩下 7 份是掃描件質量問題不算模型責任。第三個任務最意外是長對話記憶連續(xù) 3 小時的項目排期對話到后面它還記得 2 小時前隨口提過的一句約束這在上一代模型上是很難做到的。我要提醒的是官方基準普遍是在高溫采樣、多次重試的條件下跑的實際單次調用會打折扣。別把 83.5% 當成一次就能成功的概率智能體框架里該有的重試、校驗、人工確認環(huán)節(jié)一個都不能省。1.3 API 價格變化和一次典型任務的成本測算這次 API 價格調整對開發(fā)者其實是友好的。我列一下發(fā)布時公布的官方價項目GPT-6舊GPT-6.1 Sol新輸入非緩存$15/M tokens$10/M tokens輸出$60/M tokens$48/M tokens緩存輸入$1.5/M tokens$1/M tokens批量 API 折扣維持 50% 不變但新增了實時 API 并發(fā)折扣流量低谷時段調用還能再省 20%這個放在后面 API 章節(jié)細說。我自己算了一個典型業(yè)務每天 5 萬個請求平均每請求 2K 輸入、1.5K 輸出。按新價格2K 輸入 × 5 萬請求 1 億輸入 token按 $10/M 算就是 1000 美元1.5K 輸出 × 5 萬 7500 萬輸出 token按 $48/M 算就是 3600 美元。一天大約 4600 美元比舊價格6000 美元省了大概 23%。如果命中緩存輸入成本還能壓到原來的 1/10。對做 SaaS 的人來說這個降價幅度基本能對沖掉模型輸出變長帶來的增量成本。2. dots把多智能體協(xié)作變成了可視化畫布如果說 GPT-6.1 Sol 是發(fā)動機dots 就是今年最值得關注的新駕駛艙。它在發(fā)布會上的定位是一個讓多個智能體在同一塊畫布上協(xié)作、并且讓人類隨時介入的工作界面。按我的理解它的本質是把你發(fā)給模型一條消息升級成你在觀察一群智能體如何分工完成任務。2.1 dots 是什么從對話到工作臺dots 的界面是一塊無限畫布每個任務、每個子智能體、每個工具調用結果都是畫布上的一個節(jié)點。官方起名 dot 是因為這些節(jié)點看起來就像一個個發(fā)光的點拖拽連接起來就形成一條工作流。最核心的區(qū)別在兩點。第一多個智能體可以并行跑。以前在 ChatGPT 里你只能等一個對話串完成dots 里你可以派三個子智能體分別去查資料、寫代碼、做測試它們在畫布上各自推進你一眼就能看到誰卡住了、誰已經(jīng)完成。第二人類可以中途踩一腳。任何節(jié)點上都能暫停、插入意見、改參數(shù)然后讓后續(xù)節(jié)點基于你的修改繼續(xù)。現(xiàn)場演示了一個很直觀的例子讓一個智能體整理會議紀要另一個根據(jù)紀要起草郵件第三個工程師在郵件草稿節(jié)點上改了一個語氣詞后面所有下游任務自動帶著這個修改重算。這個設計思路我很認可——它承認了 AI 工作流里人機協(xié)作不是按下就跑而是需要隨時糾偏。以前做 agent 工作流糾偏只能靠改 prompt 重跑現(xiàn)在 dots 把糾偏變成了畫布上的一個小操作。2.2 現(xiàn)場演示里最有價值的三個場景我整理了一下現(xiàn)場 demo真正能落地的場景是這三個。場景一是代碼評審。兩個智能體分別做靜態(tài)掃描和邏輯走查結果并排顯示在 dots 畫布上評審人可以直接在每個發(fā)現(xiàn)的問題節(jié)點上寫批注批注會同步回代碼倉庫的 PR 評論區(qū)。這個流程過去要在多個工具間跳來跳去現(xiàn)在一塊畫布走完。場景二是數(shù)據(jù)處理管線的可視化。智能體把原始數(shù)據(jù)清洗、特征工程、模型訓練分成三個節(jié)點每個節(jié)點運行完會顯示結果摘要數(shù)據(jù)質量不過關時會在對應節(jié)點亮紅點。做數(shù)據(jù)的人應該能體會以前 pipeline 跑掛了只能翻日志現(xiàn)在故障點直接出現(xiàn)在你眼前。場景三是跨智能體記憶共享。dots 允許把某個節(jié)點的輸出保存為畫布記憶后續(xù)新任務可以引用。這個特性讓多智能體協(xié)作不再靠反復傳遞上下文而是有了一塊共享工作記憶token 消耗也跟著降。2.3 dots 和 Muse、Codex 的關系很多人在問 dots 和 Muse、Codex 到底什么關系。我的理解是Codex 是干活的命令行編碼智能體Muse 是產(chǎn)出創(chuàng)意內容的面向設計、文案等創(chuàng)意場景的工具dots 是把它們串起來并讓人類看得見、可控制的編排層。嚴格說 dots 不是替代 ChatGPT 對話而是對話的工作臺化。目前 dots 以獨立產(chǎn)品形態(tài)開放ChatGPT Plus/Pro 用戶可以直接用免費用戶每天有額度限制。API 形式還沒全量開放但文檔里已經(jīng)能看到 workflow 的 schema 定義估計很快會把 dots 的工作流導出成可編程的 JSON 配置。如果你想在自己的應用里復刻類似機制現(xiàn)在可以先用 LangGraph 或自建狀態(tài)機做雛形等官方 API 推出再遷移。3. ChatGPT Spaces 和它背后的持久化上下文思路ChatGPT Spaces 在發(fā)布名單里排得很靠前它其實是給 ChatGPT 加了一層持久化工作區(qū)的能力。過去你用 ChatGPT 處理項目會話是零散的換個話題就得開新窗口項目相關的背景、文件、約定全丟了。Spaces 解決的就是這個問題。3.1 Spaces 的前身與定位Projects 的全面升級用過舊版 Projects 的同學可以快速理解Spaces 就是 Projects 的全面升級版。區(qū)別在于 Spaces 不只是把聊天記錄分組而是構建了一個真正持久的上下文容器里面有四樣東西固定指令每個 Space 可以寫一份系統(tǒng)指令該 Space 下所有會話自動繼承不用每條消息都重復交代背景。共享文件庫把項目文檔、代碼、數(shù)據(jù)文件放進去所有會話共享讀取權限不用每次手動上傳。智能體成員可以在 Space 里掛載多個專用智能體比如代碼審查員知識庫問答各智能體共享 Space 的上下文。外部工具連接支持掛接 GitHub、Slack、Notion 等事件可以自動觸發(fā) Space 里的智能體任務。最妙的是指令 記憶的分離設計。傳統(tǒng)做法是把所有背景塞進一條超長的 system promptSpaces 則是把背景拆成多個模塊模型按需加載?，F(xiàn)場給的數(shù)據(jù)是同樣完成一個跨會話項目任務Spaces 模式的 token 消耗比傳統(tǒng)超長 prompt 模式省了約 40%因為不需要每次對話都重發(fā)全部背景。這個設計邏輯對做 RAG 的人應該很眼熟——本質上是把上下文改成檢索式加載而不是全量灌入。3.2 團隊協(xié)作細節(jié)權限、共享與隔離Spaces 的團隊協(xié)作是這次發(fā)布里我比較意外的點做得相當完整三種角色Owner完全控制、Editor可編輯內容但不能改權限、Viewer只讀。這個權限模型足夠覆蓋大多數(shù)小團隊。跨工作區(qū)分享Space 可以生成分享鏈接對方以 Viewer 身份進入不需要是同一組織。上下文隔離每個 Space 的上下文預算獨立不會互相污染。這在多項目并行時非常重要——以前在同一個賬號里切換場景模型經(jīng)常把另一個項目的約定帶過來。審計日志企業(yè)版支持導出 Space 內的操作記錄對合規(guī)要求高的團隊是剛需。我試下來有個小坑Space 里的文件更新后模型引用舊版本的情況仍然會發(fā)生官方解釋是模型按需加載文件快照意味著你需要手動觸發(fā)刷新快照。建議團隊在 Space 里約定一個刷新緩存的固定動作否則容易拿到過期上下文。3.3 數(shù)據(jù)邊界和隱私設計要點OpenAI 這次在隱私方面的表態(tài)比之前更明確付費用戶包括 Spaces 企業(yè)版的數(shù)據(jù)默認不用于訓練企業(yè)版還支持保留策略比如自動刪除超過 90 天的日志和 BYOK自帶密鑰加密。這些對想用 Spaces 做內部知識庫的團隊很重要。開發(fā)者需要注意Spaces 目前是純托管產(chǎn)品數(shù)據(jù)存在 OpenAI 側沒有本地部署選項。如果你有強數(shù)據(jù)駐留要求我建議暫時只把非敏感流程放進 Spaces敏感數(shù)據(jù)仍然走本地 RAG API 自己搭。別圖省事把所有內部文檔一股腦全傳上去等出事再后悔就晚了。4. Codex CLI 迭代與 Windows 安裝踩坑記錄DevDay 期間 Codex 相關的發(fā)布雖然沒站 C 位但對開發(fā)者來說信息量不小。命令行智能體welcome to codex的時代已經(jīng)過了介紹期這次發(fā)布的是成熟度更新并行子代理、MCP 協(xié)議支持、以及和 dots 的聯(lián)動。我自己在 Windows 環(huán)境折騰了幾天踩了個大坑必須單獨寫一段。4.1 welcome to codex命令行智能體的定位沒有變Codex 依然是 OpenAI 的終端編碼智能體核心賣點沒變在命令行里用自然語言下達任務它自己讀倉庫、改代碼、跑測試、提交 PR。DevDay 更新的重點有三個。支持并行子代理一個大任務可以拆成多個子代理并行處理最終由主代理合并結果這跟 dots 的多智能體機制是打通的。MCP 支持可以接入外部 MCP 服務器比如數(shù)據(jù)庫查詢、瀏覽器操作等于把工具生態(tài)開放了。會話持久化codex resume可以恢復之前的會話配合新的--json輸出模式方便做腳本集成。我實際用下來的體驗是中型倉庫幾萬行代碼的日常任務完成率明顯比上一代穩(wěn)特別是根據(jù) issue 改代碼并補測試這類任務基本能一條龍做下來。不過穩(wěn)定性提升的同時單次任務消耗的 token 也漲了批量任務記得配合預算告警使用。4.2 missing optional dependency openai/codex-win32-x64 的完整排查過程這是我這幾天最想分享的坑。在 Windows 上用 npm 全局安裝 Codexnpm install -g openai/codex然后運行codex直接報錯Error: Missing optional dependency: openai/codex-win32-x64. Please run npm install -g openai/codex again. Reinstall codex: npm install -g openai/codex --force第一次看到這個報錯我以為是網(wǎng)絡問題重裝了三次都一樣。后來才搞明白原因Codex 的主包是純 JS 封裝真正干活的是平臺特定的原生二進制包openai/codex-win32-x64它作為 npm 的 optionalDependencies 在安裝時按平臺選擇。某些 npm 版本或者自定義 registry特別是鏡像源環(huán)境下optionalDependencies 解析失敗會被靜默跳過于是只有殼、沒有芯。完整排查和修復步驟先確認環(huán)境平臺和 Node 架構node -e console.log(process.platform, process.arch)正常輸出是win32 x64。如果架構不對就要去查原生包是否支持該架構。查看 npm 配置確認 registrynpm config get registry如果用了鏡像源先直接改成官方源試試npm config set registry https://registry.npmjs.org/強制重裝讓 npm 重新評估 optionalDependenciesnpm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex --force驗證原生包是否安裝成功npm ls -g openai/codex-win32-x64如果 npm 一直裝不上可以直接下載官方發(fā)布的 Windows 安裝包繞過 npm。Codex 官方倉庫的 release 頁面有免安裝版本解壓后把二進制路徑加入 PATH 即可。我最后是靠第 5 步解決的。如果你在公司內網(wǎng)環(huán)境建議直接下載離線包別跟 npm optionalDependencies 較勁。另外報錯日志里會包含用戶目錄路徑發(fā)布 issue 反饋時記得打碼。4.3 跑通之后的三個小技巧Codex 裝好后有幾個提升體驗的小技巧。交互模式和自動模式分開用。日常調試用交互模式codex進入聊天界面批量任務用codex exec --full-auto 任務描述后者不需要人工確認每個動作但記得放在有版本控制的倉庫里跑方便回滾。密鑰放在環(huán)境變量里不要寫進對話。Codex 會讀取環(huán)境變量來輔助執(zhí)行任務把OPENAI_API_KEY或云服務密鑰放進環(huán)境變量模型在生成代碼時就能引用不會把它寫死在文件里。定期codex logout再重新登錄。會話時效較長但長期掛著會增加會話被誤用的風險。我習慣每周登出一次順便清掉本地緩存的認證文件。5. API 生態(tài)更新speech、價格與密鑰安全今年的 API 部分沒有特別炸的新模型但幾個增量更新對生產(chǎn)系統(tǒng)影響不小。我把 speech、價格和安全三個主題放在一起說因為它們在實際落地中是連在一起的。5.1 OpenAI-compatible speech統(tǒng)一語音接口的意義所謂 OpenAI-compatible speech是指語音服務的接口更標準化了一個 endpoint 同時覆蓋語音轉文字和文字轉語音支持流式輸入輸出并且兼容社區(qū)通用的 OpenAI API 格式。這意味著你用慣的 SDK比如 openai-python可以直接調用from openai import OpenAI client OpenAI() # 語音轉文字 with open(audio.mp3, rb) as f: transcript client.audio.transcriptions.create( modelgpt-4o-mini-transcribe, filef ) print(transcript.text) # 流式 TTS with client.audio.speech.with_streaming_response.create( modelgpt-4o-mini-tts, voicesol, input你好這是測試。 ) as response: response.stream_to_file(output.mp3)新增的語音模型價格定得很低轉寫約 $0.006/分鐘、TTS 約 $15/百萬字符。對做實時語音助手、客服質檢、內容配音的團隊來說這個費用基本可以放心沖量。實測下來中文識別準確率比上一代明顯好吞字和標點錯亂少了很多。5.2 價格體系變化和預算建議除了前面 GPT-6.1 Sol 的單價下調API 部分還有幾個值得注意的變化。實時 API 新增低谷時段折扣非高峰時段調用實時模型有 20% 折扣適合跑非實時任務但想用實時接口的團隊。Prompt Caching 命中價格進一步下降且緩存失效時間從 1 小時延長到 24 小時。對重復調用相同 prompt 的 RAG 場景成本能壓得很低。批量 API 的窗口從 24 小時縮短到 6 小時批量任務的時效性更強了。我給團隊的建議是上線前先跑一周成本賬單重點看輸出 token 和緩存命中率兩個指標。如果緩存命中率低于 20%說明 prompt 設計里動態(tài)部分太多該把固定背景挪到緩存友好的位置。如果輸出占比超過 70%要考慮是不是 reasoning effort 開太高了適當調低能用更少的錢換足夠的質量。5.3 會話 JSON 泄露了怎么辦一次真實的安全事故處理復盤最后聊一個和每個用 ChatGPT/Codex 的人都相關的安全問題。最近社區(qū)里泄露了 openai 賬號會話 json 怎么辦的求助特別多我也處理過類似事故。所謂會話 JSON通常指 ChatGPT 登錄后在瀏覽器本地保存的 Session 信息或者 Codex 保存在~/.codex/auth.json里的認證數(shù)據(jù)。一旦這些文件被你意外提交到公開倉庫、貼進聊天群、或者被截圖發(fā)出去攻擊者就能直接用你的身份訪問賬號不需要知道密碼。發(fā)現(xiàn)泄露后的處理順序按緊急程度排立刻登出所有設備。ChatGPT 網(wǎng)頁端進入設置 - Security - Devices點擊 Sign out all devices強制所有已保存會話失效。刪除對應認證文件。如果是 Codex執(zhí)行codex logout并手動刪除~/.codex/auth.json然后重新登錄生成新會話。輪換 API Key。在 OpenAI 平臺把可疑的 key 全部刪除重建。這一步別偷懶只要 key 出現(xiàn)在可疑位置就全部換。檢查用量賬單。平臺 Usage 頁面看最近 24 小時的調用記錄確認有沒有異常的高額消耗。發(fā)現(xiàn)陌生模型調用立刻加預算告警。開啟雙重驗證和登錄通知。打開 2FA以及新登錄設備通知讓下次異常登錄第一時間被你發(fā)現(xiàn)。預防比處理重要得多。我的習慣是所有含密鑰、認證信息的文件統(tǒng)一放在本地目錄加入.gitignoreGitHub 開啟 push protection防止密鑰被推到公開倉庫API Key 永遠只建子 key、用只讀權限不用主賬號 key 跑生產(chǎn)。補一句遇到聲稱能幫你恢復會話的第三方工具要特別警惕多數(shù)情況是想把你的新會話再釣走一次。6. 我接下來的采用建議和避坑清單發(fā)布會看完熱度最高的東西不一定適合馬上用。以我這幾年跟進發(fā)布節(jié)奏的經(jīng)驗給幾條實在建議。6.1 值得立刻遷移的三個場景第一長耗時智能體任務直接上 GPT-6.1 Sol。以前模型跑半小時就開始說胡話的任務現(xiàn)在明顯穩(wěn)工具調用也少出錯。第二團隊內部項目知識庫可以搬進 ChatGPT Spaces特別是跨成員協(xié)作的項目共享文件庫加固定指令這套組合省掉的 token 是實打實的。第三多智能體編排的探索可以從 dots 開始它把過去要寫代碼才能實現(xiàn)的并行協(xié)作變成可視化操作適合先跑通思路再決定要不要工程化。6.2 建議觀望的兩個場景一是生產(chǎn)環(huán)境大規(guī)模切換。剛發(fā)布的模型通常前兩周會有零星穩(wěn)定性問題線上核心鏈路建議等一兩個 patch 版本再切。二是依賴 dots 的自動化流程。dots 的 API 還沒完全開放現(xiàn)在做太深的集成可能被后續(xù)接口變化打臉可以先觀察官方 schema 穩(wěn)定程度。6.3 給團隊的最小落地清單模型切換先在一個非核心項目跑 3 天壓測記錄成功率、延遲、成本三個指標和舊模型對比后再決定全面遷移。密鑰管理本周內做一次 API Key 全量輪換刪除不再使用的 key開啟預算告警。Spaces 權限把工作區(qū)角色定義清楚Owner 不超過 2 人對外分享一律 Viewer。Codex 環(huán)境Windows 機器按第 4 節(jié)的方法預裝好別讓同事再踩 optionalDependency 的坑。會話安全全員統(tǒng)一規(guī)則禁止把 ChatGPT/Codex 會話文件截圖或發(fā)到公開渠道。最后說點個人體會。每次 DevDay 之后我都在想距離真正把這套東西用出價值還有多遠今年的答案比往年短。GPT-6.1 Sol 讓我敢把更長的任務交給模型dots 讓我看清智能體在干什么Spaces 讓團隊協(xié)作有了持久根據(jù)地——三個都擊中了我日常工作里最痛的點。回頭細想20 項發(fā)布里真正會改變我下個月工作方式的其實就這幾樣。你們也別急著追所有新功能先挑一個場景用熟比什么都重要。