2026 年 10 月 3 日（週六）

#1OpenAI 官方教你在 GPT-6 家族裡挑模型

主軸 ③ 協作 · ① 能力

發生什麼

OpenAI 10/2 發布 GPT-6 家族的模型指南。三個型號的 API 定價（每百萬 token；token 是模型計算文字量的單位）：Astra 輸入 10 美元、輸出 50 美元；GPT-6.1 Sol 輸入 2 美元、輸出 10 美元；Luna 輸入 0.1 美元、輸出 0.5 美元。

指南建議的分工：最難的推理用 Astra；複雜的程式、研究、操作電腦用 Sol；大量、目標明確的重複工作（抽取發票欄位、分類、結構化摘要）用 Luna。推理強度也分級：例行抽取或小修用低、需要判斷用中、難除錯和深度分析用高；更高的等級只在「高」仍不夠、而且改善值得成本時才用。

為什麼重要

指南引述 OpenAI 開發者體驗團隊的 Eric Provencher：模型更懂細微與模糊之處了，過度具體的指示現在可能反而有害。指南也建議更新 skills（可重複使用的 AI 工作指示）和 AGENTS.md（寫給 AI 看的專案規則檔），用明確的決策邊界取代「凡事先問」，並定義清楚什麼才算「完成」。

模型變強之後，提示詞的重點正從「一步步教它做」轉向「講清楚邊界和驗收標準」。〔推論〕

可以怎麼用

可以把手上的 AI 任務分成難推理、一般複雜、大量重複三類，各配一個模型和推理強度，並回頭檢查專案規則檔，把過時的逐步指示改成「什麼情況要停下來問」和「怎樣算完成」。〔推論〕

#2模型下架當天生效：換代要事先準備

主軸 ③ 協作

發生什麼

GitHub 10/2 宣布，即日起在 Copilot 所有功能裡下架四個模型，並指定替代：Gemini 3.5 Flash 和 3.6 Flash 改用 Gemini 3.8 Flash；Kimi K2.7 Code 改用 Kimi K3；Claude Opus 4.7 改用 Claude Opus 5.5。企業管理員可能要先在模型政策裡啟用替代模型，使用者的選單才看得到。

前一天（10/1），OpenAI 也在 API 文件公告：gpt-5.3-codex 和 gpt-5.1 改用 gpt-6-sol，gpt-5.4-nano 改用 gpt-6-luna，下架日是 2027 年 4 月 1 日。

為什麼重要

兩家的節奏不同：GitHub 是公告當天生效，OpenAI 的 API 給了六個月。

如果你的流程寫死某個模型名稱，換代時可能直接中斷；在託管的工具裡，你能準備的時間可能是零。〔推論〕

可以怎麼用

可以把流程裡用到的模型名稱集中在一個設定處、替每個模型記下替代選項，團隊管理員也定期檢查模型政策，新模型上架後先開放測試。〔推論〕

#3型別系統是約束 AI 的「回壓」

主軸 ② 思維 · ③ 協作

發生什麼

開發者 Geoffrey Huntley 10/2 在個人部落格整理了一場 podcast 對談，主張軟體不再需要「人人讀得懂」，而是要「能向人解釋」。他說自己已經兩年沒有手寫程式碼，目前混用 GPT-6.1 Sol（低推理或不推理）和 GLM、Kimi 等模型。他的原則是：先找出哪些任務真的需要前沿等級的智慧，其餘交給便宜的模型。

他也把型別系統（例如規定某個欄位只能放數字，放錯了程式就無法編譯）當成約束 AI 的回壓（back pressure）：編譯器一報錯，模型就能自己修正。用他的話說：“Types are a form of verification.”

為什麼重要

他說 Rust 專案比 Python 專案更適合交給 AI 維護，理由是編譯器能擋下更多錯誤。

AI 寫程式的品質，越來越取決於環境能不能自動給出明確的錯誤回饋，而不只是模型本身。〔推論〕

可以怎麼用

讓 AI 工作的專案，可以盡量開啟嚴格的型別檢查、程式風格檢查（lint）和測試，讓錯誤在 AI 那一端就被擋下，挑模型時也先問「這件事需要多聰明」再決定用哪一級。〔推論〕

#4把上下文放進檔案系統，讓 AI 自己去查

主軸 ② 思維

發生什麼

Latent Space podcast 10/2 訪問 MIT 的 Alex Zhang，他是 RLM（遞迴語言模型）論文的第一作者。他描述 RLM 的做法：外殼裡唯一的工具是程式碼，模型可以把自己當成工具遞迴呼叫；要處理的長內容不塞進提示詞，而是放在程式環境的記憶裡，例如檔案系統。

他舉另一個 agent 為例：它把執行紀錄和上下文都存在磁碟上，所以就算對話被壓縮過，模型還是能回頭查原始內容。

為什麼重要

Zhang 說，多數 agent 外殼的做法，是把每一步的紀錄一直接在提示詞後面，越跑越長；他主張讓每次呼叫模型時，輸入都維持在模型熟悉的樣子。

把資料放在檔案裡、讓 AI 需要時自己去查，可能正在成為長任務 agent 的主流設計。〔推論〕

可以怎麼用

做長時間的 AI 工作時，可以把中間成果、決定和待辦寫成檔案，讓 AI 需要時自己去讀，而不是期待它記住整段對話。〔推論〕

#5多 agent 為什麼越跑越慢：一份坦白的修正紀錄

主軸 ② 思維

發生什麼

AI 寫程式工具 Cline 在 10/2 的 SDK 版本說明裡，寫出長時間 agent 團隊越跑越慢的原因：每一段串流輸出、每 2 秒一次的心跳，都會把整份團隊狀態重新存一次，連每位已完成成員的完整對話紀錄也包在裡面。說明裡提到，單一本機資料庫曾長到 1.66 GB，同一筆執行紀錄被重寫約 33.9 萬次。

修正方式是：串流片段和心跳不再存檔，改成約每 300 毫秒批次寫入有變動的部分，並限制事件紀錄的筆數與保存天數。

為什麼重要

多 agent 系統出問題，常常不在模型，而在「狀態和紀錄怎麼存」這種傳統工程細節；跑得越久，小設計越會被放大。〔推論〕

可以怎麼用

自己搭多 agent 流程時，可以一開始就決定哪些紀錄要存、存多久、多久存一次，並在長時間執行前先小規模觀察儲存空間和寫入次數的成長速度。〔推論〕