對應原題（Common ‧ Agents and Tool Use）
- How does multi-agent orchestration work, and when does it break down? — Asked at: Cognition
- Your agent drifts after a long run and confidently works on the wrong thing. Diagnose it.
— Asked at: Cognition兩題都來自 Cognition（Devin）。這家公司公開主張「多數情況下不要建多 agent」，所以這題期待的不是熱情，是判斷力。
🎯 什麼情境該想到我
當你「想把 agent 拆成多個專家、或你的 agent 跑了 40 步後開始自信地做錯事」的時候。
⚙️ Part 1：多 Agent 編排
常見拓撲
| 拓撲 | 形狀 | 適合 |
|---|---|---|
| Supervisor / Orchestrator-Worker | 一個主導者分派給多個 worker，收集結果 | 可平行的獨立子任務 |
| Pipeline | 固定順序：A → B → C | 流程明確、階段分明（其實不太算「多 agent」，比較像工作流） |
| Debate / Peer review | 兩個以上互相批評 | 需要不同視角（作者 vs 審查者） |
| Hierarchical | 樹狀多層 | 大型任務分解。層數越多越脆弱 |
| Blackboard | 共享狀態，各自讀寫 | 鬆耦合協作。狀態競爭難處理 |
★ 什麼時候真的有用
只有三個正當理由：
| 理由 | 例子 |
|---|---|
| 1. 子任務真正獨立且可平行 | 同時研究 5 個主題、同時審查 20 個檔案 |
| 2. 需要隔離（不同的上下文／工具／權限） | 一個能寫檔、一個只能讀；一個接生產資料、一個不能 |
| 3. 需要不同視角 | 寫的人和審的人分開，避免自我確認偏誤 |
★ 什麼時候垮掉（題目的重點）
| 失效 | 機制 |
|---|---|
| ★ 上下文分裂 | 子 agent 看不到彼此的推理。A 決定用 PostgreSQL、B 決定用 MongoDB——兩份輸出都「對」，合起來是垃圾 |
| 隱含相依 | 你以為子任務獨立，其實不是。分頭寫的兩個模組介面對不上 |
| 錯誤放大 | 上游 agent 的錯誤被下游當成事實建構，而且下游沒有能力質疑 |
| 成本與延遲倍增 | N 個 agent = N 份上下文 × 各自的迴圈 |
| ★ 除錯地獄 | 結果錯了，是哪個 agent 的哪一步？trace 變成樹狀，人類很難讀 |
| 協調開銷超過收益 | 分派、彙總、衝突解決本身就要好幾次 LLM 呼叫 |
★ Cognition 的論點（值得原樣引用）
Cognition 公開主張的兩條原則：
1. 分享完整的上下文。
2. 行動隱含著決策；互相衝突的決策產生糟糕的結果。
推論：平行的子 agent 各自做決策卻不知道對方做了什麼，衝突是必然的，不是意外。
所以他們的建議是——單一線性 agent + 好的上下文壓縮，優於平行多 agent。
★ 但 Anthropic 的多 agent 研究系統是相反的例子
Anthropic 公開過多 agent 研究系統有效的案例。差別在哪？
| Cognition（寫程式） | Anthropic（做研究） | |
|---|---|---|
| 子任務性質 | 共同修改同一個產物 | 各自檢索不同主題 |
| 是否需要共享決策 | 是（介面、架構、命名） | 否 |
| 子 agent 回傳什麼 | 程式碼（必須互相相容） | 摘要（可獨立消化） |
| 結果 | 多 agent 會垮 | 多 agent 有效 |
★ 綜合判準（面試答法）：
「問一個問題：子任務之間需不需要共享決策？」
- 唯讀、可平行、結果能獨立摘要 → 多 agent 有效（研究、審查、資訊蒐集）
- 要相依地『寫』同一個產物 → 多 agent 會垮（寫程式、改文件、設計系統）
「我會先用單一 agent 做到能跑，量出瓶頸真的是可平行的唯讀工作，才拆。」
⚙️ Part 2：★ Agent Drift 診斷手冊
症狀：跑了幾十步後，agent 自信地在做一件和原始目標無關（或相反）的事。
它不覺得自己錯了——這才是難處。
Step 1：二分法找「最後一次還正確」的那一步
讀 trace，找出分歧點。這一步跳不過——沒有完整 trace 就沒有這題的答案。
Step 2：檢查那一步的上下文發生了什麼
按發生機率排序：
| # | 成因 | 怎麼查 |
|---|---|---|
| 1 | ★ 原始目標被壓縮掉或滑出視窗 | 印出那一步實際送進模型的 prompt。目標還在嗎？ 這是最常見的原因 |
| 2 | 摘要漂移 | 比對原始訊息與摘要。反覆摘要後語意常悄悄偏掉 |
| 3 | ★ 自我污染 | 模型前面說的推測（「這應該是快取問題」）被寫進歷史，幾步後被它自己當成已確認的事實 |
| 4 | 工具錯誤被誤讀 | 一個 ERROR: not found 被理解成「這個東西不存在」，於是走上錯誤的分支 |
| 5 | 矛盾資訊並存 | 上下文裡同時有 v1 和 v2 的說明，模型挑了錯的那個 |
| 6 | lost-in-the-middle | 目標在上下文正中間 → 被忽略（見 位置編碼與 RoPE） |
| 7 | 記憶污染 | 長期記憶裡有錯誤或惡意的「事實」被每輪注入（見 Agent 記憶設計） |
★ 第 3 項「自我污染」最隱蔽：
模型的輸出會進入自己的上下文。它在第 5 步猜的東西，到第 15 步就變成上下文裡一句看起來很確定的陳述——
而模型無法分辨「這是我猜的」和「這是工具回報的」。
Step 3：對策
| 對策 | 說明 |
|---|---|
| ★ 目標釘住 | 原始目標與硬約束放進 system prompt，永遠不參與壓縮 |
| ★ 結尾重述 | 每一輪在上下文最後重述一次目標（對抗 lost-in-the-middle，成本幾十個 token） |
| 定期對齊檢查 | 每 N 步問一次：「現在的子目標是什麼？和原始目標一致嗎？」偏離就中止或求助 |
| ★ 標記事實 vs 推測 | 工具回傳用明確標記包起來（<observation>），模型的推測不享有同等權重 |
| 可驗證的檢查點 | 中途就跑測試／驗證，不要等最後（見 工具-把命令變成可驗證的目標） |
| 預算 + 人類檢查點 | 超過 N 步就停下來讓人看一眼（見 可逆性、審計與人類把關） |
| 短任務優於長任務 | ★ 最有效的預防：把長任務切成有明確產出的短任務，每段重新開始 |
面試答法：「我會先看 trace 二分定位分歧點，然後印出那一步實際的 prompt——八成的 drift 是因為原始目標已經不在上下文裡了。
預防上我會做三件事：目標釘在 system prompt 不參與壓縮、每輪結尾重述目標、以及把長任務切短。」
⚠️ 注意 / 什麼時候不適用
- 沒有完整 trace 就沒得診斷。每一步的完整 prompt、工具呼叫、回傳都要能重放。這是 agent 系統的基礎設施，不是加分項。
- 多 agent 的評估更難。要能分別評估每個 agent 與整體，否則不知道問題在哪一層。
- 「加一個 reviewer agent」不一定有用。同一個模型審自己的輸出有強烈的確認偏誤；要有獨立的資訊或可驗證的判準才有價值。
- debate 會收斂到錯誤的共識。兩個模型互相說服，可能一起走偏。
- 別用多 agent 掩蓋單 agent 的問題。工具設計爛、上下文管理爛，拆成五個 agent 只會有五倍的問題。
- Drift 有時是任務本身太模糊。目標無法被驗證時，模型沒有東西可以校準——先讓目標可驗證。
🧪 我實際套用的紀錄
- 2026-09-20：從面試題庫展開。待辦：確認現有 agent 的原始目標有沒有被排除在壓縮之外。
🔗 相關
- ReAct 與 Agent Loop —— 單 agent 的基礎
- Agent 記憶設計 —— 上下文壓縮與記憶污染
- 工具集設計 —— 子 agent 封裝
- 可逆性、審計與人類把關 —— 檢查點設計
- 位置編碼與 RoPE —— lost-in-the-middle
- 工具-防止agent造假通過驗收 —— 「我做完了」不可信
- 工具-把命令變成可驗證的目標 —— 讓目標可校準