昨天在「隔離、修剪、摘要」三條路上只點了名字就收尾，其中隔離看起來最誘人：把一段髒工作丟給子代理，它燒掉的五萬 token 不會回到主線歷史，主線只收一段結論。但這筆帳只算了一半。隔離的瞬間你就製造了一道縫——上下文必須在那裡被重新組裝一次，而重組時掉的東西，主線看不見，評估指標也看不見。今天把這道縫拆開：什麼時候該隔離、交接封包該裝什麼、以及為什麼每個子代理評分都是 0.95 的系統仍然會錯三成。
📖 學
兩份互相打臉的實戰報告
2025 年 6 月同一個月，兩家做 agent 的公司給出方向完全相反的結論。
Anthropic 6 月 13 日的〈How we built our multi-agent research system〉描述 Research 功能的架構：一個 LeadResearcher 規劃研究流程，用工具生出多個 subagent 並行搜尋，各自帶回發現，LeadResearcher 綜合後決定要不要再派，最後把全部材料交給 CitationAgent 標引用位置。實測數字是 Opus 4 當 lead、Sonnet 4 當 subagent 的組合，在內部研究評估上比單一 Opus 4 高 90.2%。代價寫得同樣清楚：這套架構的 token 消耗約是一般聊天互動的 15 倍，而且他們發現約 80% 的表現變異可以用 token 使用量解釋。
「80% 的變異來自 token 用量」等於承認：多代理的優勢有很大一部分不是分工的巧思，而是單純花了更多算力。算一下代價密度——假設單代理跑一題吃 20K token，15 倍就是 300K，多出的 280K 換 90.2 個百分點，每提升 1 個百分點約多燒 3.1K token。這個數字把問題轉成一句可回答的話：你這題的一個百分點，值不值 3.1K token。Anthropic 給的適用範圍也很窄：廣度優先、答案需要同時探索許多獨立路徑、且總資訊量超過單一上下文視窗的研究型任務。
同月 12 日，Cognition 的 Walden Yan 發〈Don’t Build Multi-Agents〉，主張正好相反。他的兩條原則是：其一，共享上下文，而且要共享完整的 agent trace，不是只傳個別訊息；其二，行動隱含決策，衝突的決策帶來壞結果。 他舉的例子夠具體：任務是做 Flappy Bird，拆成「做會動的背景與綠色水管」和「做一隻可以上下移動的鳥」。結果 subagent 1 誤解成 Super Mario 風格的背景，subagent 2 做出的鳥不像遊戲素材、動起來也不對，最後那個負責合併的 agent 只能把兩個誤解拼在一起。就算你把原始任務複製給每個子代理，第二層問題還在：兩個子代理看不到彼此在做什麼，視覺風格照樣不一致——它們基於各自的隱含假設行動，而那些假設從沒被誰講明過。
判準：子任務之間有沒有決策耦合
兩邊都對，因為任務型態不同。研究是唯讀的：subagent 各自去讀網頁，讀誰不影響別人讀到什麼，結果可以直接加總，錯了頂多是漏掉一條線索。寫程式是寫入的：共享一個 repo、一份風格約定、一組介面契約，A 做的每個決定都改變 B 的正確答案。
所以判準只有一句：子任務之間有沒有隱含決策耦合。 有耦合就別讓多個代理並行寫入；沒耦合（純檢索、純分類、純驗證）放心並行。到 2026 年這條線已收斂成更好用的一句：多代理系統在寫入保持單執行緒、額外的代理貢獻情報而非行動時最可靠。Cognition 2026 年 3 月的 Devin manage Devins 就是這個形狀——coordinator 界定範圍、每塊派給跑在獨立 VM 的 Devin、再收攏，理由講得很白：上下文會累積、專注會退化、子任務品質跟著掉。
Claude Code 的子代理是同一判準的另一種答案：它派子任務但不與子任務並行工作，子代理通常只回答問題、不寫程式碼。好處正是昨天談的那件事——調查過程不必留在主線歷史裡，主線因此能跑更久。這是拿「不做寫入」換「不必共享決策」。
縫才是評估單位
Future AGI 2026 年 4 月的〈Evaluating LLM Agent Handoffs〉把這件事推到評估層，主張很銳利：handoff（交接）是跨框架的評估單位。 七種框架做的是同一件事，只是名字不同——Claude Agent SDK 的 Task 派發、OpenAI Agents SDK 的 handoff()、LangGraph 的 edge、CrewAI 的 delegation、AutoGen 的一個 turn、Google ADK 的 sub-agent invocation、A2A 的服務間訊息。形狀完全一致：發送方產出範圍與限制，接收方消化並回傳結果，發送方讀結果決定下一步。
為什麼不能只評每個代理？做個算術。四個代理各自 0.95，串起來 0.95⁴ ≈ 0.81，這已經比儀表板上那四個 0.95 難看了。再加上三道縫，若每道縫獨立地有 10% 機率掉掉一個限制條件，端到端全對的機率是 0.95⁴ × 0.9³ ≈ 0.8145 × 0.729 ≈ 0.59。你的面板顯示四個 0.95，實際是六成。每個代理都綠燈，是最危險的狀態，不是最安全的。
那篇提出四條與框架無關的 rubric，剛好對應交接的四個時刻：
| Rubric | 評誰 | 抓什麼 | 典型症狀 |
|---|---|---|---|
| dispatch correctness | 發送方的派發決策 | 該不該派、派給誰、範圍夠不夠緊、工具給太多沒 | 該內聯處理卻派了，或派給錯的接收方 |
| scope fidelity | 接收方的執行 | 有沒有越界、有沒有用不該用的工具、有沒有捏造上下文 | 憑空說「我們先前已經決定 X」而那一輪根本不存在 |
| result integration | 發送方拿到結果後 | 有沒有真的讀回傳值並讓它改變計畫 | 忽略結果自己重做一遍，答案對但成本翻倍 |
| recovery on error | 發送方的錯誤路徑 | 超時或報錯後有沒有重試、降級、升級 | 吞掉錯誤，帶著不存在的產物繼續規劃 |
第三條最容易漏掉，因為它表現為浪費而不是錯答案：子代理帶回材料，主代理視而不見自己再推一次，使用者看到的答案沒問題，只有成本翻倍，而任何盯最終答案的指標都照不到。第四條最兇：派發失敗又沒有結構化復原，比不派更糟——發送方接下來是在對著不存在的狀態做規劃。
交接要帶什麼：Handoff Debt 的實測
「多帶點上下文過去」聽起來理所當然，但昨天的教訓是別憑感覺——2026 年的〈Handoff Debt〉正好量了它。做法很乾淨：在確定的交接點打斷一個 coding agent、凍結 repo，讓後手模型在四種交接視角下接手——只有 repo 狀態、原始 trace、摘要筆記、結構化筆記。75 個來源任務展開成 181 個交接點任務，每個後手模型跑 724 次接手。
結果：相對「只給 repo」的裸接手，帶上下文的交接讓 agent 事件中位數少 20–59%、累積 prompt token 少 42–63%。但解題率的差異小得多，而且因模型而異。
這個落差要記牢：交接筆記買到的主要是效率，不是正確率。 省 42–63% 的 prompt token 是真的省，但別拿它說服自己「加了交接摘要品質就會變好」。這正好接住昨天留下的懷疑——壓縮不保證正收益，得對照基線量，而這裡的基線就是 repo-only 裸接手。
看似矛盾的一點：Cognition 說要共享完整 trace，Handoff Debt 卻顯示原始 trace 不如結構化筆記划算。兩者保護的東西不同——完整 trace 保證資訊不遺失，結構化筆記保證 token 不爆炸。 折衷是昨天那手法的延伸：交接封包放結構化筆記，附上可回查的指標（檔案路徑、span id），需要細節才去撈。大東西留在檔案系統，上下文只放門牌號碼。
交接封包的七個欄位
把上面全部收成一張可以照抄的清單。派發子代理時，這七項缺一項就記一筆債：
- 目標與完成定義——不是「研究 X」，是「產出什麼、什麼算完成」。
- 硬限制——預算上限、日期範圍、排除清單。要用 JSON 區塊明列，理由在下面。
- 已試過與已排除——後手最貴的成本就是重跑前手已經否定的路。
- 當前狀態與指標——改過哪些檔、卡在哪、相關檔案路徑。
- 允許的工具子集——過度授權直接拉低 dispatch correctness。
- 回傳格式契約——你要它回什麼結構，講死。
- 失敗時的處置——超時怎麼辦、找不到怎麼辦，寫進派發 prompt，別等它自己發明。
第 2 項為什麼要結構化：把生產環境的交接失敗做分群，最大一類就是掉限制條件（dropped constraint）——接收方在某道縫上弄丟了預算上限或日期範圍。原因很直觀：散文裡的限制在摘要時最先被吃掉，因為它們在語意上像修飾語。放進 JSON 區塊，它就從修飾語變成欄位，摘要器要刪掉它得多跨一道門檻。
🧠 記
隔離不是免費的。它省下的是主線 token，付出的是一道縫。省下的量得到、縫上掉的量不到，所以直覺會系統性高估隔離的收益。決定開子代理時，預設要問的不是「省多少 token」，而是「這道縫上會掉什麼」。
判準是子任務之間有沒有隱含決策耦合，不是任務大不大。唯讀、可加總、彼此不改變對方正確答案的工作（檢索、分類、驗證、審查）放心並行；共享狀態的寫入保持單執行緒，讓額外的代理提供情報而不是執行動作。Anthropic 的 +90.2% 和 Cognition 的 Flappy Bird 慘劇不矛盾，只是站在這條線的兩邊。
交接筆記買的是效率不是智商。20–59% 的事件減少、42–63% 的 token 減少是實測得到的，解題率的改善則小而不穩。所以說服自己的理由要用成本寫，不要用品質寫；而且要有 repo-only 那種裸接手的基線，否則你不知道自己買到了什麼。
評估要放在縫上，不在兩端。四個 0.95 的代理加三道各掉 10% 限制的縫，端到端是 0.59。只看最終答案的分數會漏掉最貴的一種失敗——主代理忽略子代理成果自己重做，答案完全正確，成本安靜地翻倍。
✍️ 實踐
拿一次你最近真的跑過的子代理派發來驗，20 分鐘。
- 抓現場：找出最近一次 sub-agent／Task 派發，把派發 prompt 原文和子代理完整回傳各複製一份。憑印象檢討沒有用。
- 七欄打分：對照上面七欄逐項勾，缺一欄記 1 分債。第一次做多半缺第 3、5、7 項。
- 查越界：讀回傳，找兩種東西——有沒有「我們先前已決定／確認 X」但那件事從沒發生（捏造上下文）；有沒有動到未授權的工具。任一出現就是 scope fidelity 破了。
- 查自己：看你拿到回傳後的下一則動作，有沒有真的引用它，還是繞過去自己重做一遍。這是 result integration，也最容易在自己身上抓到。
- 改一項、重跑：只做一個改動——把所有硬限制抽成派發 prompt 尾端的 JSON 區塊，其餘一字不動，重跑同一任務。
- 記一行帳：
日期｜派發目標｜缺哪幾欄｜是否越界｜是否重做｜前後 token 差。累積十行，就會看出自己的縫固定漏在哪一欄。
沒有多代理系統也成立：單代理的 /compact 或會話重開，壓縮後的摘要就是你交給下一個自己的交接封包，同一張七欄清單照用。
🔗 延伸學習
- How we built our multi-agent research system — Anthropic Engineering（orchestrator-worker 架構、90.2%、15× token、80% 變異來自 token 用量）
- Don’t Build Multi-Agents — Walden Yan, Cognition（兩條上下文工程原則、Flappy Bird 案例、Claude Code 子代理為何不並行寫入）
- Evaluating LLM Agent Handoffs (2026) — Future AGI（七框架同一原語對照表、四條 rubric、掉限制／越界／略過整合／不復原四類失敗分群）
- Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks（四種交接視角、181 個交接點任務、事件減 20–59%／token 減 42–63%）
💬 問 AI
我要檢查一次子代理派發的交接品質。以下是我的「派發 prompt 原文」與「子代理回傳原文」。
【派發 prompt】
<貼上>
【子代理回傳】
<貼上>
【我拿到回傳後的下一步動作】
<貼上>
請依序做四件事，每項先給 0–1 分再說理由，不要客套：
1. dispatch correctness:這件事該派給子代理，還是我自己內聯做更好?範圍界定夠不夠緊?我有沒有過度授權工具?
2. scope fidelity:子代理有沒有越出被派發的範圍?有沒有捏造上下文(宣稱「我們先前已決定 X」但派發 prompt 裡沒有)?有沒有用到未授權的工具?
3. result integration:我的下一步有沒有真的使用回傳值並讓它改變計畫,還是繞過它自己重做了一遍?
4. recovery on error:如果子代理超時或報錯,我的派發 prompt 有沒有指定處置?沒有的話補一句該怎麼寫。
最後用這七個欄位檢查我的派發 prompt,列出缺哪幾項:目標與完成定義、硬限制、已試過與已排除、當前狀態與檔案指標、允許的工具子集、回傳格式契約、失敗處置。
然後直接改寫我的派發 prompt:補齊缺項,並把所有硬限制抽成結尾的一個 JSON 區塊。只給改寫後的成品,不要解說。