目標先講清楚：
我要把接下來的 Agent 開發路線與工作流寫清楚，並回答一個常見問題：既然 LLM 有長上下文（long context），為什麼還要拆成多個 Agent？

為什麼不是「一個超大 Agent 搞定一切」？

長上下文≠萬能。實務上，上下文失效（context fail） 會讓單一超大 Agent 變得脆弱，常見四種症狀是：

• Context poisoning：錯誤被寫進長期脈絡（goals/notes/memory），之後不斷被模型當作事實引用。 (Drew Breunig)
• Context distraction：脈絡太長或太雜，模型被歷史細節牽著走，忽略新的指示與證據。 (Drew Breunig)
• Context confusion：同時塞太多工具說明或不相關資訊，模型選錯工具、把雜訊當事實。 (Drew Breunig)
• Context clash：來自不同來源/回合的內容互相矛盾，模型卡在衝突中產生含糊或不一致結論。 (Drew Breunig)

另一方面，最新的多代理系統實務也印證：把任務拆成「多個協作的專注代理」，各自有清楚的工具、提示與探索路徑，會比單一巨無霸更穩、更好排錯。Anthropic 在其 Multi-Agent Research 的工程文章裡，詳細談到如何用「一個規劃代理 + 多個並行子代理」來做檢索與調查，以及在協調、評估與可靠性上的工程教訓。 (Anthropic)

Google Agentic Design Pattern - Ch.1

參考「Agentic Design Patterns / Prompt Chaining」等資源，我把第一章常用的提示與流程設計要點蒐整成五步： (Agentic Design Patterns)

1. 明確分解任務：先列出步驟序列，定義每一步的輸入/輸出契約。
2. 要求結構化輸出：用 JSON/XML 等格式傳遞，降低自然語言歧義導致的後續失敗。
3. 夾帶外部工具：步驟間可查 API/DB、做檢核或交給計算器，結果再回填。
4. 漸進式驗證：每步做完整性/格式檢查，不合格就觸發補救（conditional step）。
5. 角色分工：為每步指定明確身份與目標，降低走偏風險。

這套「分而治之 + 中間態可驗證」的做法，正是多代理工作流得以可測試、可維運的基礎；與 Anthropic 的多代理實戰脈絡相呼應。 (Anthropic)

我的 Agent Workflow

先上流程，再逐步加工具與記憶；每個子代理只處理一件事，輸出必為結構化。

• 第一步：把「執行邏輯」拆成各個Agent
• 第二步：定義「結構化輸出」

這種 「監督者 + 專注子代理」 的拓樸，和產業實務的 Orchestrator–Worker 多代理設計一致，能隔離責任、清楚觀測、方便回滾。 (Anthropic)

實際在開發過程中，也會依照測試結果對workflow進行調整．

接下來要做什麼

接下來會介紹常用到的結構化輸出常使用的方式

參考資源

• How Long Contexts Fail（上下文為何會失效）：提出 poisoning / distraction / confusion / clash 四大類，並給出修復思路。強烈建議先讀完，再設計長上下文系統。 (Drew Breunig)
• Anthropic：How we built our multi-agent research system：從原型到上線的工程教訓，包含規劃代理、並行子代理、評估與可靠性等實務。 (Anthropic)
• Agentic Design（Prompt Chaining）：把複雜任務拆成可驗證的步驟鏈，要求結構化輸出與中途驗證。 (Agentic Design Patterns)