https://yennj12.js.org/yennj12_blog_V4/tags/agent-communication/Recent content in Agent Communication on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 01:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part1-coordination-zh/Mon, 22 Jun 2026 01:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part1-coordination-zh/大多數人看到多 Agent 系統，第一反應是「多幾個 Agent 就能平行加速」。 工程現實卻是：沒有協調機制的多 Agent，比單 Agent 更慢、更貴、更難除錯。 正確答案是：先確定協調模式，再決定幾個 Agent——而不是反過來。 協調成本才是多 Agent 系統的真正瓶頸，比 LLM token 更貴。 面試情境 你負責設計一個研究助理平台：使用者輸入一個複雜問題，系統要自動拆解子任務、分派給不同專業 Agent（搜尋、摘要、數據分析、引用驗證），最後整合回一份報告。規模目標是 2,000 個並發研究任務，每個任務平均涉及 8 個子 Agent。請說明協調架構如何設計，以及當兩個 Agent 搶同一份外部資源時你怎麼處理衝突？ 一、核心問題：多 Agent 協調比單 Agent 難在哪裡 1.1 單 Agent 的極限在哪裡 單一 LLM Agent 在以下情境開始出現瓶頸： 情境 問題 數字 超長 context 精度隨 token 數下降 > 32K tokens 後 recall 掉 15–30% 串行任務鏈 無法利用並行，延遲線性增長 10 步 × 3s = 30s 異構技能需求 同一 Agent 無法同時是程式碼專家與法律專家 prompt 膨脹、精度下降 長時間運行 上下文視窗耗盡，需要切割狀態 超過 4 小時任務必須外化記憶 多 Agent 解決了以上問題——但引入了一整類新問題：