2026 年 10 月 2 日（週五）
涵蓋台北時間 10/1 07:00 ～ 10/2 07:00 發布的消息補做（製作日 2026-10-04）
讀法：沒有標示的句子＝有來源的事實。〔推論〕是我們的判斷；〔廠商宣稱〕是廠商自己說、還沒有第三方驗證；〔未驗證〕是還沒查實。每則底下可以點「展開」看證據與限制。
今天最值得知道的事：同一個模型換一套「外殼」，排名就可能反過來。挑 AI 工具時，該比的是「模型＋外殼＋任務」的組合，不是模型的名字。〔推論〕
#1選模型，要連「外殼」一起選
主軸 ③ 協作
發生什麼
一篇 10/1 提交到 arXiv（論文預印本網站）的論文，評估了 66 種 agent 配置。agent 是能自己呼叫工具、連續做多步工作的 AI；外殼（harness）是包住模型、負責呼叫工具、回傳結果、管理對話的那層程式。研究用 4 種可設定的外殼搭 5 個模型，再加兩組原廠組合，在三個基準測試上共評分 6,204 條執行紀錄。
在 Terminal-Bench 4 上，Claude 模型裝在 OpenHands 外殼裡時領先 GPT 模型 7.94 分，裝在 PI 外殼裡卻落後 30.16 分。5 個模型裡有 4 個，最適合的外殼會隨基準改變。論文摘要的說法是：“Model rankings reverse across harnesses.”
為什麼重要
作者的解釋是：模型幾乎都會自己嘗試修正錯誤，所以結果很大程度取決於外殼有沒有把失敗訊息用模型能用的形式傳回去。同一天另一篇論文發現，同一個配置重跑所造成的分數差異，約佔全部差異的 54%。
單看排行榜上的模型名稱挑工具，很可能挑錯。〔推論〕
可以怎麼用
評估 AI 工具時，可以用自己真實的任務、在自己實際會用的那套工具裡測，同一個設定重跑幾次再下結論，換模型時也順便看看工具回傳的錯誤訊息模型讀不讀得懂。〔推論〕
展開：證據與限制
- 兩篇都是論文本身（arXiv 預印本，10/1 提交），頁面沒有標示已通過同行審查。
- 第一篇只涵蓋 3 個基準、4 種可設定外殼；摘要沒有寫出 5 個模型的確切版本。排名反轉是這組設定下的結果，不是普遍定律。
- 第二篇（〈Agents Are Systems, Not Models〉）只用了 4 個科學任務。它還發現：影響最大的是「給 agent 的任務資訊」，超過時間預算和模型大小；只在提示詞裡要求 agent「自己驗證答案」，行為幾乎不變，給它專用的驗證工具才有明顯改變。
- 還不知道：這些結論放到一般商業程式碼上是否同樣成立。
來源：arXiv 2610.00917、arXiv 2610.01618（一手·論文）
#2Claude Code 開放 Mods：工具本身可以被改寫
主軸 ③ 協作 · ② 思維
發生什麼
Anthropic 10/1 為 AI 寫程式工具 Claude Code 推出 mods：用 TypeScript 寫小函式，掛在工具呼叫、權限請求、畫面繪製等事件上，可以在事件前後執行，也能改寫、擋下或取代它。官方列出的用途包括：改寫送進模型前的提示詞、在模型讀到之前遮掉工具輸出裡的密鑰、換掉內建介面。內建的 /diff 指令已經改成一個 mod。Mods 跟著外掛（plugin）發佈，終端機版和桌面 app 都能用。
為什麼重要
AI 寫程式工具從「固定的產品」變成「執行中可以改寫的平台」，團隊可以把自己的規則直接寫進工具裡。〔推論〕代價是：官方寫明 mods 不在沙箱裡，權限和 Claude Code 本身一樣大。
裝了別人寫的 mod，等於讓那段程式碼以你的權限執行；外掛的供應鏈風險因此進到了 AI 開發工具裡。〔推論〕
可以怎麼用
只裝讀得懂、來源可信的 mod，團隊導入前先決定誰能安裝、誰負責審查，並先在不含敏感資料的測試環境裡試用。〔推論〕
展開：證據與限制
- 來源是 Anthropic 官方部落格（10/1）與同日的 GitHub 版本 v2.1.287；版本說明的第一條就是加入 mods。
- 官方說，在 Team／Enterprise 方案或有集中管理設定的機器上，會先載入內建的 sec-default mod，阻止使用者自裝的 mod 覆寫拒絕規則。〔廠商宣稱〕
- 「原本的 hooks（事件掛勾設定）做不到、mods 做得到」「之後會把更多內建功能改成 mod」都是官方說法。〔廠商宣稱〕
- 還不知道：社群寫的 mod 品質與安全性，目前沒有第三方評估。
來源：Claude 官方部落格、GitHub release v2.1.287（一手）
#3第二個審查者，要不要換一家的模型？
主軸 ③ 協作
發生什麼
10/1 一篇單一作者的論文做了受控實驗：在 30 份作品裡人為植入 150 個錯誤，用來自 2 家公司的 3 個審查模型、10 種審查條件，共審查 900 次。
結果：最強的跨模型審查者，和「同一個模型開新對話來審」相比，F1（同時看抓得到和抓得準的綜合分數）沒有顯著差異，但兩者抓到的錯誤只有部分重疊。只能審兩次的時候，「同模型一次＋跨模型一次」抓到 56.7% 的植入錯誤，高於「同模型兩次」的 42.7%；但這個組合並沒有顯著勝過「最強的跨模型審查者審兩次」。
為什麼重要
作者也發現，輕量的跨模型審查者並沒有比同模型審查更好。換一家模型來審，好處可能來自「看的角度不同」，而不是「比較強」。〔推論〕不過論文自己也說，無法把這兩個因素分開。
想用第二個模型把關時，該追求的是互補，而不是找一個更貴的模型重做一遍。〔推論〕
可以怎麼用
對錯誤代價高、又負擔得起兩次審查的產出，可以試試一次「同模型開新對話」加一次「換一家模型」，但收益要用自己的任務確認，而且用輕量模型當審查者時，不必期待它多抓到錯。〔推論〕
展開：證據與限制
- 來源是論文本身（arXiv，10/1 提交），單一作者，資料需要向作者索取。
- 錯誤是人為植入的，真實工作裡的錯誤分布可能不同。
- 作者自承無法把「模型不同」和「審查者能力不同」這兩個因素分開。
- 「不給審查者看需求說明」對兩個較弱的審查層級有幫助、對最強的那層沒有；作者註明這是未經統計檢定的估計，結果會隨失敗場次的計分方式而變。
- 還不知道：換成真實工作裡自然發生的錯誤，結果是否一樣。
來源：arXiv 2610.01471（一手·論文）
#4把「流程」寫成程式，判斷才交給 agent
主軸 ③ 協作 · ② 思維
發生什麼
GitHub 10/1 在 Copilot 的命令列版（CLI）、應用程式，以及給開發者整合用的工具包（SDK）推出 dynamic workflows（動態工作流程）：用程式碼定義一件任務怎麼執行——哪些步驟自動跑、什麼時候叫 agent、結果怎麼用。步驟可以串行、平行，也能在檢查點停下來等人確認再繼續。官方舉的例子包括「兩個模型都同意才回報」。
同一天，Kiro CLI 2.27 新增「Workflows: sub-agent tool」設定（啟用 Workflows 時預設開啟）：開著時，主對話可以直接委派子代理，也可以經由 workflow；關掉則只能經由 workflow 委派。
為什麼重要
讓 agent 自己決定所有步驟容易跑偏、也難追查，把可預期的步驟固定在程式裡、只把需要判斷的部分交給 agent，結果比較容易重現。〔推論〕
兩家工具同一天都推出 workflow 相關功能，「多 agent 協作要先有骨架」可能正在成為常見做法。〔推論〕
可以怎麼用
可以把常交給 AI 的多步驟工作拆開：每次都一樣的步驟寫成固定流程，需要判斷的才交給模型，並在無法復原的步驟前加一個人工確認點。〔推論〕
展開：證據與限制
- 來源是 GitHub 官方 changelog（10/1）與 Kiro CLI changelog（10/1）。
- GitHub 說這樣能獲得多 agent 工作需要的可靠性與可觀測性，頁面沒有附實測數據。〔廠商宣稱〕
- GitHub 頁面明說這和既有的 /fleet（由 Copilot 自己委派子代理並協調）不同：動態工作流程執行的是程式碼定義好的流程。
- 功能目前是公開預覽；終端機版要先開啟實驗功能，Copilot app 則不需設定。
- 還不知道：實際用起來比讓 agent 自由委派可靠多少，目前沒有公開比較。
來源：GitHub changelog、Kiro CLI 2.27 changelog（一手）
#5小型「決策模型」：簡單的判斷不必動用大模型
主軸 ① 能力 · ③ 協作
發生什麼
10/1 同一天，Strands Agents 的 Strands Labs 和 Cloudflare 各自開源了「決策模型」。這類模型不生成文字，只在給定的選項裡挑一個或打分數，並附上信心值。
Strands Decider 2B 是把 20 億參數的 Qwen3.5 模型拿掉輸出文字的部分，換上一個約 100 萬參數的選擇頭。Cloudflare 的 Clef 與 Clef-flash 則跑在自家的 Workers AI 平台上。Strands 列出的用途包括模型路由（決定一個請求交給哪個模型）、工具選擇、評測與防護規則；Cloudflare 舉的例子則是客服單分派、網域分類等。
為什麼重要
很多 agent 流程裡的判斷其實是選擇題（要不要呼叫工具、交給哪個模型、這段內容能不能放行），拿大模型來做又慢又貴。〔推論〕
把例行判斷交給專用小模型、難題留給大模型，可能會成為控制成本與延遲的常見分工。〔推論〕
可以怎麼用
可以找出流程裡「從幾個選項挑一個」的步驟先試小模型，並先用自己的資料確認它的信心值和實際錯誤率對得上，再決定信心值多低時改交給大模型。〔推論〕
展開：證據與限制
- 來源是 Strands Agents 官方部落格（10/1）與 Cloudflare 官方部落格（10/1）。
- Strands 頁面寫延遲中位數約 115 毫秒（常見硬體；圖表以 RTX 3090 測得）；Cloudflare 自家表格寫 Clef-flash 中位數 38.8 毫秒、Clef 209.3 毫秒。〔廠商宣稱〕
- 兩家的準確度與排名，都是廠商自己用第三方設計的基準跑出來的。〔廠商宣稱〕 Cloudflare 自己列出，Clef 在 When2Call、BRIGHT 兩項評測上分數低於對手 Jev。
- Strands 自述：在複雜問題上明顯不如推理模型，也不適合寫程式、聊天、摘要。
- 還不知道：真實流程裡搭配大模型使用時，整體錯誤率會怎麼變。
來源：Strands Agents 部落格、Cloudflare 部落格（一手）
#6讓 AI 做研究：去找「適合 AI 的問題」
主軸 ① 能力 · ② 思維
發生什麼
物理學家 Matthew Schwartz 在 Anthropic 網站 10/1 刊出的客座文章裡說，他不再把 Claude 當成自己期望中的那種合作者，而是照它實際的樣子合作，改去找適合 Claude 的問題：計算量大、需要的方法散落在不同領域的題目。他建立並維護開源工具 BootLoops（多由 Claude 協助產生），並說三個月內，從約 400 個候選問題中產出 36 份稿子，橫跨 18 個領域、有 19 位共同作者。
為什麼重要
他列出的失敗模式很具體：模型愛宣布「做完了」但其實沒做完、時間估不準、傾向硬算而不是先造工具、對話被壓縮之後會忘記前面的內容。他認為自動檢查仍不可靠，所以一律親自看圖。他也直說，Claude 目前幫不了深層的概念問題，題目有不有趣，還是要靠人判斷。
長期跟 AI 合作時，人的角色正從「動手做」轉向「選題」和「驗收」。〔推論〕
可以怎麼用
交給 AI 之前，可以先想這件事是不是「量大、方法明確」的類型，AI 說完成時用能檢查的成果（數字、圖、測試）驗收，長時間的工作則定期把重點整理成檔案。〔推論〕
展開：證據與限制
- 來源是作者本人的第一人稱文章，刊在 Anthropic 研究網站（10/1）；這是單一作者的經驗，不是對照實驗。
- 他的做法：每個專案一個 Claude Code 對話，再加一個負責協調、分配算力、驗證的主對話；另外有寫作用的對話和「對抗式審稿人」對話。
- 文末註明作者是 Anthropic 的訪問研究員，BootLoops 不是 Anthropic 的專案；文中的科學成果，我們沒有看到獨立複核。
來源：Anthropic 研究網站（一手·作者本人）
今天的工程思維
今天六則講的是同一件事：AI 的表現不只取決於模型，而是整個系統——外殼怎麼回傳錯誤、流程裡哪些步驟固定、哪些判斷交給小模型、誰來審、人在哪裡驗收。「挑最強的模型」越來越不是答案，「把模型放在對的位置」才是。〔推論〕