https://yennj12.js.org/yennj12_blog_V4/tags/swarm/Recent content in Swarm on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 02:00: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 解決了以上問題——但引入了一整類新問題：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part2-emergence-collective-zh/Mon, 22 Jun 2026 02:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part2-emergence-collective-zh/大多數工程師遇到複雜問題，第一直覺是「換一個更大的模型」。 真正懂系統設計的人知道：讓十個中等模型彼此辯論，往往比一個頂尖模型獨自思考更準確。 湧現不是魔法，是可以設計的協作協議。 問題不是「能不能湧現」，而是「湧現後你有沒有辦法控制它」。 面試情境： 你的團隊正在構建一個醫療診斷輔助系統，需要在 99.5% 準確率與 < 3 秒延遲之間取得平衡。單一 GPT-4 只能達到 94% 準確率，且有時會「幻覺」出不存在的藥物交互作用。請設計一個多 Agent 集體推理架構，說明如何透過湧現行為提升準確率，同時保持可控性與可解釋性。 一、核心問題：湧現智慧的工程機會與不可控性 湧現（Emergence） 是系統層級的性質，無法從單一元件預測。一個 Agent 讀文件，十個 Agent 互相辯論，系統的行為質量不是線性疊加，而是非線性躍升。 為什麼湧現在 LLM 多 Agent 系統中特別有價值？ LLM 的認知偏差問題： 問題類型 單一 LLM 表現 多 Agent 集體推理 確認偏誤 容易強化初始假設 反對 Agent 強制挑戰 幻覺 4–8% 幻覺率（GPT-4） 辯論後降至 1–2% 知識盲點 受限於訓練資料 不同模型互補不同知識 複雜推理 單次 context 限制 分工後各擅勝場 湧現的工程挑戰： 不可預測性：5 個 Agent 的交互可能產生 120 種路徑排列 放大效應：一個 Agent 的錯誤可能被其他 Agent 強化而非糾正（Echo Chamber） 成本爆炸：N 個 Agent 互相溝通 = O(N²) token 消耗 延遲累積：串行辯論每輪加 2–5 秒，3 輪 = 6–15 秒額外延遲 工程師的任務不是「讓系統湧現」，而是設計湧現發生的條件，並在湧現失控前有干預能力。