前一天我們談 Worktree Isolation。

現在每個 Agent 已經可以有：

• 自己的 Task
• 自己的 Context
• 自己的 Permission
• 自己的 Budget
• 自己的 Workspace

看起來 Multi-Agent 已經完成了。

但真正困難的部分才剛開始：

誰負責讓這些 Agent 一起完成同一個目標？

多 Agent 最容易被高估的地方是：

把任務拆開，就等於完成 Coordination。

其實 Delegation 只是開始。

真正的 Coordination 還要處理：

1. Dependency
2. Ownership
3. Shared State
4. Conflict
5. Result Merge
6. Failure Propagation
7. Budget Allocation
8. Completion

Coordination 不是 Agent 互相聊天

很多 Multi-Agent Demo 會讓 Agent A、B、C 在聊天室裡互相發訊息。

看起來很像團隊。

但如果沒有結構化 State，它們只是多個模型互相增加 Context。

Production Coordination 更需要：

明確誰負責什麼、依賴誰、何時完成、結果交給誰。

Coordinator

最簡單的架構是：

Coordinator
├── Agent A
├── Agent B
└── Agent C

Coordinator 負責：

• 分解 Task
• 建立 Child
• 分配 Budget
• 管理 Dependency
• 收集 Result
• Resolve Conflict
• 判斷 Completion

Coordinator 可以是：

• Model
• Code
• Hybrid

固定規則最好放 Code。

需要語意判斷的部分交給 Model。

Dependency Graph

假設任務是：

研究需求
↓
提出方案
↓
實作
↓
Review
↓
Test

這不是五個可以任意平行的 Agent。

它是一個 Dependency Graph。

可以表示：

A → B → C
        ↓
       D + E

Scheduler 根據 Dependency 決定誰能開始。

不要讓 Agent 自己用聊天猜 Dependencies。

Shared State

不同 Agent 可能需要知道：

• Current Goal
• Approved Decision
• Artifact
• Latest Build
• Current Branch
• Constraint

但不需要共享全部 Conversation。

Shared State 應該是：

結構化、最小、可版本化。

例如：

decision:
use PostgreSQL

artifact:
architecture_v3.md

build:
commit abc123

不要用一個巨大 Shared Chat 當 State Store。

Ownership

每個 Artifact 最好有 Owner。

例如：

API Spec
Owner: planner

Implementation
Owner: coding agent

Security Review
Owner: security agent

如果兩個 Agent 同時擁有同一個 Mutable Artifact，很容易衝突。

Ownership 可以降低：

• Duplicate Work
• Conflicting Writes
• Responsibility Ambiguity

Result Contract

Child Agent 的結果要有固定 Contract。

例如：

status
summary
artifacts
evidence
risks
blocked_by
next_action

Coordinator 不應該每次重新理解一整段自然語言。

Structured Result 能讓 Coordination 更穩定。

Conflict

兩個 Agent 可能得出不同結論。

例如：

Agent A:
應該加 Cache

Agent B:
問題其實是 DB Index

Coordinator 不能只選比較有自信的那個。

需要 Conflict Policy。

例如：

• 比 Evidence
• 執行 deterministic test
• 請第三方 Judge
• 要求兩邊補證據
• 交由 Human

重點是：

Conflict Resolution 要依證據，不是依 Agent 人設。

Permission Bubbling

假設 Child Agent 想 Deploy，但它沒有權限。

它不應該自己提升。

可以：

Child
↓
permission_request
↓
Parent / Coordinator
↓
Policy Engine
↓
Approval

這叫 Permission Bubbling。

權限需求向上回報。

不是向下擴散。

Failure Propagation

如果 Child B 失敗，Parent 要怎麼辦？

策略可能包括：

• Retry B
• Replace B
• Skip B
• Replan
• Continue Partial
• Fail Parent

這取決於 Dependency。

如果 B 是 Optional Research，可能可以繼續。

如果 B 是 Security Verification，可能必須停止。

所以 Child Failure 需要 Severity。

Partial Success

Multi-Agent Task 不一定只有 Completed / Failed。

例如三個來源：

A success
B success
C failed

Parent 是否能產生部分結果？

可以有：

Completed
Partially Completed
Blocked
Failed

這比硬把所有 Child 都要求 100% 成功更實際。

Budget Allocation

Parent 有 Global Budget。

需要分配給 Child。

例如：

Global
100K tokens

Research A
20K

Research B
20K

Implementation
40K

Reserve
20K

不要讓先啟動的 Agent 把全部 Budget 用掉。

Coordinator 要保留整合與 Recovery 資源。

Completion

Parent 何時算完成？

不是：

所有 Agent 都說 Done。

而是：

• Required Child 完成
• Required Artifact 存在
• Verification 通過
• Conflict 解決
• Approval 完成
• Budget 未違反

Completion 是 Graph-level Verification。

常見錯誤設計

1. 多 Agent = 群聊

沒有 State、Dependency、Owner。

2. Shared Context 全部同步

Token 成本爆炸。

3. 沒有 Result Contract

Parent 每次重新理解自然語言。

4. Child 自己拿更多權限

破壞 Least Privilege。

5. Agent 都說 Done 就算完成

沒有整體 Verification。

6. 沒有 Global Budget

Coordination 本身耗光資源。

第一版 Coordinator

至少需要：

parent_task
child_tasks
dependency_graph
shared_state
artifact_registry
budget
completion_rule

以及：

• spawn
• wait
• merge result
• handle failure
• resolve conflict
• cancel children

今天的結論

Multi-Agent 的難點不是建立更多 Agent。

而是：

讓多個獨立 Loop 在有限 Context、Budget、Permission 下，仍然能對同一個目標收斂。

最重要的原則：

Agent 可以分工，但責任、依賴與完成條件必須集中管理。

下一篇會進入 Protocols：

Agent 之間到底應該交換自由文字，還是使用明確 Message Schema、Artifact 與 Event？

完整系列與程式碼範例收錄於 https://github.com/hardness1020/awesome-agent-architecture