多 Agent 真正缺的，往往不是更多 Agent
整理版優先睇
多Agent嘅價值，唔係開多幾個模型，而係拆得清任務、溝通有協議、工作區夠隔離
呢篇文章講緊多Agent系統嘅真正核心。好多團隊一遇複雜任務就諗住「多拉幾個Agent一齊做」，但作者指出，如果冇好好嘅組織結構，多Agent只會放大混亂。作者以編排器-工作者模型做骨架，強調任務圖、結構化協議（JSONL inbox）同埋工作區隔離（worktrees）先係基礎。結論係：先拆好任務、定義好依賴同職責，先好諗並行同擴展。否則，開得越多Agent，錯得越離譜。
文章分幾層深入：先講核心結構（主Agent統籌、子Agent做具體任務），再講任務圖點樣做協作骨架，然後講點樣用JSONL inbox做通訊協議、用worktrees做隔離，最後講交叉驗證同常見誤區。作者特別提醒，錯誤會喺Agent之間互相傳染，所以一定要有獨立驗證機制。
整體嚟講，呢篇係好實戰嘅方法論，適合想認真用多Agent嘅開發者。作者唔係sell fancy工具，而係講清楚組織原則：先有任務圖、協議同隔離，之後先諗並行同人工審查。
- 多Agent嘅真正價值係拆任務同可控協作，唔係開多幾個模型
- 最常見嘅組織方式係編排器-工作者：主Agent拆任務、分派、彙總；子Agent獨立做細任務
- 任務圖係協作骨架，記錄每個任務係乜、歸邊個、依賴邊個，避免混亂
- 用JSONL inbox做通訊協議，保留請求編號、發送方、狀態；用worktrees隔離工作區，避免互相踩文件
- 多Agent容易互相傳染錯誤，一定要有交叉驗證；擴展前要先確保單Agent邊界同驗收通過
核心觀點：先有組織，再談並行
多Agent嘅價值，唔係開多幾個模型，而係將複雜任務拆得更清楚、協作得更可控。作者一開波就點出普遍問題：好多團隊見任務複雜就自然諗「多拉幾個Agent一齊做」，但人數一多，混亂一樣放大。人類團隊如果冇分工、協議同邊界，會互相等、互相改、互相誤解，多Agent都係咁。
並行有兩種用法：分段併發同投票取共識。前者提高吞吐，後者提供多視角，但前提都係任務可拆、結果可合併，唔可以將「多跑幾次」當成組織能力。
真正依賴嘅底座，係JSONL inbox呢類結構化協議、任務圖、Worktree隔離同摘要回傳
任務圖：協作嘅骨架
多Agent最怕兩件事：大家都唔知邊個做緊乜，同埋前置任務未完成，後面嘅Agent已經開工。更穩嘅做法，係將任務寫成一張任務圖：係乜、歸邊個、依賴邊個。
有咗任務圖，主Agent先知道邊啲任務可以並行、邊啲必須等。每完成一步，先更新狀態，再進入下一步，系統先有恢復現場嘅可能。
協議同隔離：要行喺並行前面
子Agent之間如果只靠自然語言「傾住協作」，好快會出事。邊個承諾咗乜、邊個等緊邊個，模型未必記得穩。更可靠嘅做法，係將通信寫成append-only嘅JSONL inbox，至少保留請求編號、發送方、接收方、狀態同時間戳。
另一件事係隔離。任務圖可以放喺.tasks/，每個子Agent用自己的.worktrees/工作區，搜索、試錯、調試細節留喺自己度，主Agent只拎摘要。咁可以減少主上下文污染，避免多個Agent同時改同一批文件。
協議負責把話說清，隔離負責別互相踩
交叉驗證同常見誤區
多Agent仲有一個風險：錯誤會相互傳染。A畀出一個有偏差嘅判斷，B順住佢補強，C再將結論講得更肯定，最後大家一起將錯話講圓。更多Agent唔等於天然更聰明。
多Agent體系裏要有交叉驗證
但順序唔可以反：先有可持久化任務圖，再有明確身份嘅子Agent，再有結構化通信協議，最後先加獨立Agent、測試、編譯器或人工審查呢類外部反饋。
作者用一段偽TypeScript展示最小框架，主流程只關心任務圖、inbox同最終摘要，子Agent被限制喺自己嘅工具、工作區同輪次裏。呢個骨架更貼近多Agent真正需要解決嘅三件事：依賴、隔離、彙總。
一句講清楚：多 Agent 嘅價值，唔係在於開多啲模型，而係在於將複雜任務拆得更清楚、協作得更可控。
當任務越來越長，好多團隊自然會諗到「拉多幾個 Agent 一齊做」。呢個方向有時的確有用。例如一邊查資料、一邊寫 code、一邊做測試，彼此可以並行。問題在於，人數一多，混亂都會一齊放大。
人類團隊如果冇分工、協議同邊界，就會互相等、互相改、互相誤解。多 Agent 都係一樣。先有組織，再講並行，否則只係將問題放大。
核心結構：編排器－工作者
多 Agent 最常見嘅組織方式，係主 Agent 作為 Orchestrator 統籌全局，下面掛住多個子 Agent 獨立並行工作。主 Agent 負責拆任務、分派同彙總；子 Agent 只喺自己嘅上下文同工作區入面完成具體子任務。
並行都有兩種用法：能夠拆開嘅任務用分段併發，高風險判斷用投票取共識。佢哋能夠提高吞吐量，或者提供多個視角，但前提仍然係任務可拆、結果能夠合併，唔可以將「多跑幾次」當成組織能力。
多 Agent 先要有任務圖，再有協議同隔離。
任務圖，係協作嘅骨架
多 Agent 最怕兩件事：第一係大家唔知道邊個做緊乜，第二係前置任務未完成，後面嘅 Agent 已經開工。更穩陣嘅做法，就係將任務寫成一張任務圖：係乜、歸邊個、依賴邊個。
有咗任務圖，主 Agent 先至知道邊啲任務可以並行，邊啲必須等。每完成一步，先更新狀態，再進入下一步，系統先至有恢復現場嘅可能。
協議同隔離，要行喺並行前面
子 Agent 之間如果只靠自然語言「聊住協作」，好快就會出問題。邊個承諾咗乜、邊個等緊邊個，模型未必記得穩。更可靠嘅做法，係將通信寫成 append-only 嘅 JSONL inbox，至少保留請求編號、發送方、接收方、狀態同時間戳。
另一件事係隔離。任務圖可以放在 .tasks/，每個子 Agent 用自己嘅 .worktrees/ 工作區，搜索、試錯、調試細節留喺自己嗰度，主 Agent 只攞摘要。咁樣既能減少主上下文污染，亦都能避免多個 Agent 同時改同一批文件。協議負責將話講清楚，隔離負責唔好互相踩。
多了 Agent，亦都可能多咗偏差
多 Agent 仲有一個風險：錯誤會互相傳染。A 俾出一個有偏差嘅判斷，B 順住佢補強，C 再將結論講得更肯定，最後大家一齊將錯話講到圓。更多 Agent 唔等於天然更聰明。
所以，多 Agent 體系入面要有交叉驗證。但順序唔可以調轉：先有可持久化任務圖，再有明確身份嘅子 Agent，再有結構化通信協議，最後再加獨立 Agent、測試、編譯器或人工審查呢類外部反饋。
用一段 code 睇出組織骨架
下面呢段偽 TypeScript 展示嘅係最細框架：主流程維護任務圖同 inbox，子 Agent 只攞最細運行信息，最後只將摘要匯返主上下文。
呢段 code 入面，主流程只關心任務圖、inbox 同最終摘要。子 Agent 被限制喺自己嘅工具、工作區同輪次入面，唔繼承完整記憶同 Skills；搜索、試錯同調試細節留喺隔離上下文入面。呢個骨架更加貼近多 Agent 真正需要解決嘅三件事：依賴、隔離、彙總。
常見誤區：任務一複雜，就加 Agent 先
如果一個任務本身仲未定義清楚，拆畀五個 Agent，只會得到五種混亂。更穩陣嘅順序，係先將單 Agent 嘅邊界同驗收跑通，再將真正能夠獨立嘅部分拆出去。得唔得並行，取決於任務結構，唔取決於開得幾個模型。
組織問題解決咗之後，下一步就輪到另一個更現實嘅問題：呢啲 Agent 到底有冇將事做啱？咁就需要評測。
多 Agent 先要有任務圖、協議同隔離，之後再講並行同擴展。
Agent 科普系列：
一句話說清楚：多 Agent 的價值，不在於把模型開得更多，而在於把複雜任務拆得更清楚、協作得更可控。
當任務越來越長，很多團隊會自然想到“多拉幾個 Agent 一起做”。這個方向有時確實有用。比如一邊查資料、一邊寫代碼、一邊做測試，彼此可以並行。問題在於，人數一多，混亂也會一起放大。
人類團隊如果沒有分工、協議和邊界，會互相等、互相改、互相誤解。多 Agent 也是一樣。先有組織，再談並行，否則只是把問題放大。
核心結構：編排器-工作者
多 Agent 最常見的組織方式，是主 Agent 作為 Orchestrator 統籌全局，下掛多個子 Agent 獨立並行工作。主 Agent 負責拆任務、分派和彙總；子 Agent 只在自己的上下文和工作區裏完成具體子任務。
並行也有兩種用法：能拆開的任務用分段併發，高風險判斷用投票取共識。它們能提高吞吐，或者提供多視角，但前提仍然是任務可拆、結果能合併，不能把“多跑幾次”當成組織能力。
多 Agent 先要有任務圖，再有協議和隔離。
任務圖，是協作的骨架
多 Agent 最怕兩件事：一是大家不知道誰在做什麼，二是前置任務沒完成，後面的 Agent 已經開工。更穩的做法，是把任務寫成一張任務圖：是什麼、歸誰、依賴誰。
有了任務圖，主 Agent 才能知道哪些任務可以並行，哪些必須等待。每完成一步，先更新狀態，再進入下一步，系統才有恢復現場的可能。
協議和隔離，要走在並行前面
子 Agent 之間如果只靠自然語言“聊着協作”，很快就會出問題。誰承諾了什麼、誰在等誰，模型未必記得穩。更可靠的做法，是把通信寫成 append-only 的 JSONL inbox，至少保留請求編號、發送方、接收方、狀態和時間戳。
另一件事是隔離。任務圖可以放在 .tasks/，每個子 Agent 用自己的 .worktrees/ 工作區，搜索、試錯、調試細節留在自己那裏，主 Agent 只拿摘要。這樣既能減少主上下文污染，也能避免多個 Agent 同時改同一批文件。協議負責把話說清，隔離負責別互相踩。
多了 Agent，也可能多了偏差
多 Agent 還有一個風險：錯誤會相互傳染。A 給出一個有偏差的判斷，B 順着它補強，C 再把結論說得更肯定，最後大家一起把錯話說圓。更多 Agent 不等於天然更聰明。
所以，多 Agent 體系裏要有交叉驗證。但順序不能反：先有可持久化任務圖，再有明確身份的子 Agent，再有結構化通信協議，最後再加獨立 Agent、測試、編譯器或人工審查這類外部反饋。
用一段代碼看出組織骨架
下面這段偽 TypeScript 展示的是最小框架：主流程維護任務圖和 inbox，子 Agent 只拿最小運行信息，最後只把摘要匯回主上下文。
這段代碼裏，主流程只關心任務圖、inbox 和最終摘要。子 Agent 被限制在自己的工具、工作區和輪次裏，不繼承完整記憶和 Skills；搜索、試錯和調試細節留在隔離上下文裏。這個骨架更貼近多 Agent 真正需要解決的三件事：依賴、隔離、彙總。
常見誤區：任務一複雜，就先加 Agent
如果一個任務本身還沒有定義清楚，拆給五個 Agent，只會得到五種混亂。更穩的順序，是先把單 Agent 的邊界和驗收跑通，再把真正能獨立的部分拆出去。能不能並行，取決於任務結構，不取決於能開幾個模型。
組織問題解決以後，下一步就輪到另一個更現實的問題：這些 Agent 到底有沒有把事做對？這就需要評測。
多 Agent 先要有任務圖、協議和隔離，之後再談並行和擴展。
Agent 科普系列：