Agent 編排和直接用一個 Agent 做所有事有什麼不同？
最核心的差別是分工。一個 Agent 做所有事的問題是：它要同時保持所有任務的上下文，容量有限、越長越可能出錯，而且出了問題你不知道是哪一步搞砸的。
Agent 編排把大任務切成幾個各自有清楚目標的小任務，每個 Agent 只負責自己那一塊，上下文更乾淨、出錯更容易定位。好比一家公司不會讓一個人同時做業務、研發、財務、行政，而是讓各部門專心做好自己的事，再由主管整合。代價是你需要設計好各 Agent 之間的協作介面，以及總指揮 Agent 的任務拆解邏輯。
錯誤在 Agent 之間傳遞這個問題怎麼防？
幾個實用的設計模式。第一，輸入驗證：每個 Agent 在接收到上游輸出時，先做格式和合理性檢查，不要假設上游的輸出一定是乾淨的。第二，在重要節點設人工確認點：不是每一步都要人確認，但在「一步做錯影響整條鏈」的地方，設一個讓人過目的點，比全部跑完才回頭排查省時間。
第三，限制 Agent 的副作用範圍：每個 Agent 能改哪些東西、能呼叫哪些工具，事先設定清楚。你不會希望一個因錯誤輸入而偏軌的 Agent 開始刪除真實資料或發出對外訊息。第四，做好日誌：每個 Agent 的輸入和輸出都記下來，出問題時才能準確定位是哪個環節出了什麼問題。
總指揮 Agent 本身也是一個 AI 模型嗎？它怎麼知道要怎麼拆任務？
是的，通常也是一個 AI 模型，但它的系統提示和指令是為「規劃和協調」而不是「執行具體任務」量身設計的。你在設計它的提示時，會告訴它這個系統有哪些 Agent 可以用、每個 Agent 能做什麼、任務要按什麼規則拆解。
它靠什麼知道要怎麼拆？一部分靠你在提示裡寫清楚的分工規則，一部分靠它自己的推理能力。對於規則清楚的任務（例如「這類報告永遠分三段，分別交給研究/撰寫/審稿 Agent」），把規則寫死在提示裡最穩；對於更動態的任務，你需要總指揮有足夠的上下文去自己判斷，這通常需要用更強的模型做總指揮。
進階：什麼情況下 Agent 編排會失敗，怎麼提早判斷？
幾個常見的失敗模式值得提前預案。第一，任務邊界不清楚：如果 Agent A 和 B 都以為某件事是對方在做，它就沒人做；兩個都做了就有衝突。任務邊界定義不清是最常見的錯誤，要在設計階段就用具體的案例走一遍。
第二，上下文傳遞不完整：總指揮把任務交給 Worker Agent 時，有沒有把必要的背景資訊一起帶過去？Worker Agent 只知道自己收到的那一份，如果上下文不夠，它只能用猜的。第三，失敗沒有被妥善處理：某個 Agent 超時、報錯、回傳空值，整條鏈怎麼反應？有沒有重試機制、fallback 選項、或是告知使用者任務無法完成的路徑？這些都要在設計時想清楚。
場景：一個 SaaS 公司想每週自動生成「競品監測報告」。
沒有 Agent 編排時：工程師寫了一個超長提示詞，叫單一 Claude 做「查五家競品的定價更新、摘要各家社群媒體動態、整理成報告格式、標出需要管理層注意的項目」。結果 Claude 的上下文被各種資訊塞滿、輸出品質不穩定，查到第三家公司時已快忘了第一家的細節。
用 Agent 編排後：一個「研究協調 Agent」把任務拆成：Research Agent A 查定價（只做這件事）、Research Agent B 爬社群媒體（只做這件事）、Writer Agent 把收到的資料整理成格式化報告、Review Agent 做最後校對並標出優先項。各 Agent 上下文乾淨、可以並行跑，整體準確率和速度都比單一 Agent 更好。
Agent 編排的核心取捨是：模組化能力 vs 協調複雜度。
拆分成多個 Agent 的好處是每個 Agent 職責清楚、可以並行跑、出錯容易定位、可以替換個別 Agent 而不影響整體。這讓複雜任務的長期維護更容易，系統也更容易橫向擴展。
代價是你需要設計清楚的任務邊界、上下文傳遞格式、失敗處理邏輯和整合機制——這些加在一起，前期的設計複雜度遠比單一 Agent 高。對於簡單任務，這個前期投資完全不值得；對於複雜、重複、長期要維護的流程，這個投資能帶來顯著回報。