AI 代理時代的一週：從更強的模型到「說到做到」的 AI

🧭 本單元白話講

想像你把一件要忙好幾個小時的工作交給 AI，然後自己去做別的事。以前這很難，因為 AI 常常做到一半就停下來，或是做完了卻沒做對。這一週的主角是 Anthropic 推出的兩個新模型：Claude Sonnet 5.5 和 Claude Opus 5.5。它們都屬於 Claude 5.5 這個家族，而且官方提到，Haiku 5.5（主打大量、省錢的用途）也預告幾週內加入。

為什麼說 AI 更能「自己跑完長任務」？Opus 5.5 的官方使用指南說，它相較前代最大的進步在多步驟的工作，例如把一項修改貫穿整個大型程式庫，直到 測試程式設計師寫的自動檢查，用來確認程式改完之後還能正常運作全部通過。早期測試者讓它連續跑好幾個小時的程式任務，幾乎不用盯著。指南也提到，只要你把「完成的標準」講清楚，它就知道什麼時候算做完。

Sonnet 5.5 的進步則是又快又省。官方說它比 Sonnet 5 生成速度快 30% 以上，而且大多數工作的成本最多可降低 30%。它的價格表沒有變：每百萬個輸入 tokenAI 讀寫文字時的計量單位，大約是一個字或半個字收 2 美元，每百萬個輸出 token 收 10 美元。省錢的原因是完成同一件事通常只需要少很多 token。成績方面也有大幅進步：在 Terminal-Bench 4.0 這項 代理式程式評測讓 AI 像員工一樣自己操作電腦、寫程式、解決問題的考試中，Sonnet 5.5 拿到 70.6%，Sonnet 5 只有 10.3%。

兩者怎麼選？官方的說法很明確：Sonnet 5.5 最擅長範圍明確的日常任務、修 bug，以及製作漂亮的文件、簡報和試算表。Opus 5.5 則是為需要細心判斷的複雜工作而生。官方還特別提醒：有幾項測驗中，開到 Max 努力等級的 Sonnet 5.5 表現可以跟 Opus 5.5 相當，但分數只反映一部分，在自家與外部測試者的實測裡，需要長時間判斷的開放式工作，Opus 5.5 仍然明顯比較強。

對你來說，實用的結論是：任務範圍小、要快、要省，就選 Sonnet；任務大、模糊、需要一路做判斷，就選 Opus。不論選哪個，下一個單元會談到的重點都一樣，就是要把任務和完成標準一次講清楚。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元我們看了新一代模型登場，你可能注意到：模型越來越強，卻也越來越大。這一單元要回答一個疑問：模型那麼大，為什麼還能又快又省？答案藏在一種叫 混合專家（MoE）把模型拆成很多個「專家」小模組，每次只叫其中幾個出來工作的設計 的架構裡。

先用一個比喻。想像一間大醫院，有幾十位不同科別的專科醫師，但你掛號看診時，只會被分配到最相關的幾位，而不是全部醫師同時圍著你。醫院的「總人才量」很大，但你這次真正動用的人力很少。MoE 模型也是這樣：它有很多個專家，每讀或寫一個 token語言模型處理文字的最小單位，大約是一個字或半個詞，只會挑出少數幾位專家來運算。

看真實數字會更有感。德國 Aleph Alpha 在 2026 年 10 月 3 日發表的開放權重模型 Kolibri，總參數是 781 億（78.1B），但每個 token 只動用約 34.6 億（3.46B），也就是只用到 4.4%。參數模型裡被訓練出來的數字，可以想成模型「腦中的知識量」 多代表容量大、能記住更多東西；而每次只啟用一小部分，代表運算量接近一個 35 億參數的小模型，所以速度快、成本低。順帶一提，它的權重檔約 78 GB（8 位元浮點數格式），這代表「全部專家仍然要放進記憶體」，省的是運算，不是存放空間。

那專家變多，會不會把效率吃掉？Ai2 釋出的開源訓練工具 Olmo-core 3 做了一個很直接的實驗：把專家數量從 8 個增加到 128 個，但每個 token 仍然只選 4 個專家，所以每次啟用的參數約維持在 32 億。結果總參數從 46 億暴增到 470 億，訓練速度卻只掉不到 5%。這說明「專家池變大、每次只叫幾個」這個設計，真的能讓容量成長而不拖垮效率。

不過 MoE 也有代價。Ai2 指出，整個模型仍要存放在 GPU 記憶體中，而且要把每個 token 送到正確的專家那裡，在大型叢集中會產生額外的通訊與協調成本。模型越大，這些成本就越可能吃掉「只用部分專家」帶來的好處。Olmo-core 3 的做法是讓專家常駐在 GPU 上、把資料送過去，而不是反覆搬運權重；在初步測試中，47B 的 MoE 每張 GPU 每秒處理 52,000 個 token，約是舊作法 19,400 的 2.7 倍。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元我們看到，混合專家（MoE）架構讓模型內部能依任務分派不同「專家」處理。模型內部再厲害，最後還是要靠你下的指令來發揮——這一單元就來學怎麼把指令下對。

官方教學（Opus 5.5 使用指南）的第一個建議很直接：整個任務在一則訊息裡一次講完，並且說清楚「終點線」，例如「測試全部通過」或「每個端點都已搬完」，然後放手讓它做。原因是 Opus 5.5 在多步驟、長時間的工作上比前代更能持續跑下去，早期測試者甚至讓它跑好幾個小時的程式任務、幾乎不用盯。有了明確的完成標準，它就知道自己什麼時候算做完。

舉個官方範例：「把付款端點從舊的客戶端搬到新的。完成的定義是：每個端點都用新客戶端、舊客戶端已刪除、測試全數通過。只有在測試失敗且你無法解釋原因時才停下來問我。」你會發現這段話包含三件事：任務、完成標準用來判斷『做完了』的具體條件，不是『做好一點』這種模糊感覺，以及什麼情況才需要打斷你。

第二個建議是反直覺的：把「請仔細思考」「一步一步想」這類句子刪掉。官方說明 Opus 5.5 每次回覆前一定會先思考，而且自己決定要想多久；他們在聊天產品的測試中，拿掉「think carefully」之後回覆更快開始，品質沒有明顯下降。如果只是簡單問題，直接寫「直接回答」即可。

另一個獨立測試則針對 AI 最讓人頭痛的問題：幻覺AI 在不知道答案時，自己編出一個看起來很像真的內容。研究者設計成對的網頁，一頁有答案、另一頁少了那一欄（還放了舊價格這類誘餌），要求 AI 擷取資料。只要在提示詞加上一句「查無的欄位填 null，不要猜（Do not guess）」，編造欄位的比例就從約 70.7% 降到 20.2%。這句話成本幾乎是零，卻等於告訴 AI：『不知道』是合法答案。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元我們學會把任務和完成標準一次講清楚；這一單元要問的是下一個問題：就算你講得很清楚，AI 回報「做完了」，你要怎麼確定它真的做完？

先看一個真實案例。有位顧客的 745 美元廚房電器卡在物流「例外」狀態，已經比預計送達日晚了 15 天。AI 客服 agent 做事很仔細：一共 9 次工具呼叫，查訂單、查物流、查顧客資料、查了兩次退款政策、確認沒有既有工單、開了一張新工單、記錄時間線，連政策也讀對了（她的帳號等級確實不符合延遲補償資格）。最後它把工單標成「已解決」，還回覆「您的問題已解決，還有什麼我能協助的嗎？」

問題出在哪？物流例外其實還沒排除，這張工單正確的最終狀態應該是「暫緩、等待處理」，而不是「已解決」；顧客也沒有得到她真正想問的答案。重點是：如果只檢查 工具呼叫AI 為了做事而去操作系統的每一個動作，例如查訂單、開工單，9 次都格式正確；如果只檢查「有沒有寫入資料庫」，它也確實有寫。只有去看資料庫裡那一個欄位，才會發現 status 是 solved，而要求的是 hold。

這就是微軟與 Hugging Face 的 ThinkingBox 評測法的核心：不評 AI 講了什麼、也不評它做了哪些動作，而是讓 agent 在隔離的環境裡操作，結束後直接檢查 終態任務跑完之後，資料庫裡實際留下來的資料與狀態 和副作用（多改了不該改的紀錄、多產生了不該有的東西）。他們用 507 個有狀態的商業流程、每個跑 20 次來測。

數字很驚人：在 12 個模型、121,680 次有效試驗中，有 79,853 次沒通過可執行的檢查；而這些失敗裡，有 67.24% 看起來都很「正常」：agent 乾淨地結束、有呼叫會改資料的工具、也沒有回報任何工具錯誤。換句話說，大多數失敗不會報錯，它們只是安靜地做錯。

另一份素材給了第二個警訊：AI 傾向「補答案」。在網頁擷取測試中，頁面上其實沒有某個欄位（只有舊價格之類的誘餌），沒被要求不准猜時，許多模型編造的比例很高；在提示詞加一句「沒有就填 null，不要猜」之後，整體編造欄位比例從 70.7% 降到 20.2%。但就算加了這句，各模型仍有高低差異（例如 Solar Pro 4 仍有 19/36 編造），所以它能降低風險，卻不能取代驗收。

把兩個案例合起來，你可以建立自己的驗收習慣：第一，事先寫下「完成」應該長什麼樣（呼應上一單元）；第二，任務結束後不要只讀 AI 的回報，直接打開結果去看——資料庫那個欄位、檔案內容、實際寄出的訊息；第三，對可能沒有答案的任務，明確允許 AI 說「沒有」；第四，重要任務多跑幾次，因為一次成功不等於穩定可靠。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

✅ 離開前自測（全勾＝這課真的學會了）