前一天我們談 Multi-Agent Coordination。

當多個 Agent 開始互相傳遞結果時，下一個問題是：

它們要用什麼格式溝通？

最簡單的做法：

全部用自然語言

例如：

Agent A:
我分析完了，問題可能在 cache，你可以接著處理。

對人來說很好讀。

但對系統來說，這句話留下很多不確定性：

• 分析成功嗎？
• Evidence 在哪裡？
• 哪個 Artifact？
• 可信度多少？
• 下一個 Agent 可以直接執行嗎？
• 是否需要 Approval？
• 是否有未解決風險？

所以 Protocol 的核心不是：

Agent 能不能傳訊息

而是：

不同 Agent 能不能對同一個 Message 有一致解讀

Protocol 不是 Prompt Convention

在 Prompt 裡寫：

請用以下格式回覆。

有幫助。

但真正可靠的 Protocol 應該有：

• Schema
• Validation
• Version
• Error Handling
• Compatibility

也就是：

Message 是 Interface，不只是文字。

Message Envelope

可以先定義通用 Envelope：

message_id
sender
receiver
type
task_id
timestamp
payload

例如：

{
  "type": "task_result",
  "task_id": "task_123",
  "sender": "research_agent",
  "receiver": "coordinator",
  "payload": {}
}

Payload 再根據 type 使用不同 Schema。

Message Type

常見 Type 可以包括：

task_request
task_result
permission_request
approval_result
artifact_created
error
progress
cancel
heartbeat

有 Type，系統就不需要從自然語言猜：

這句話是在報告結果，還是在要求權限？

Task Request

一個 Task Request 可以明確包含：

goal
scope
inputs
tools
budget
completion
return_schema

這就是 Day 7 的 Delegation Contract。

Protocol 把它變成可驗證介面。

Task Result

Result 可以包含：

status
summary
evidence
artifacts
uncertainty
risks
next_action

Coordinator 收到後可以直接驗證 Schema。

不需要先請另一個模型讀懂「大概完成了」。

Artifact 不應該塞進 Message

如果 Child 產生 5MB Log 或 PDF，不要把完整內容塞進 Agent Message。

Protocol 可以傳：

artifact_id
artifact_type
location
summary
checksum

Message 傳 Metadata。

Artifact Store 保存實體。

這樣避免 Context 和 Message Bus 被大型內容塞滿。

Request / Response 不夠

Long-running Agent 還需要 Event。

例如：

TASK_STARTED
ARTIFACT_READY
APPROVAL_REQUIRED
TASK_BLOCKED
TASK_COMPLETED

Event 沒有要求立即 Response。

這更適合 Background Task。

所以 Protocol 可能同時有：

• Command
• Query
• Event

Correlation ID

如果一個 Agent 同時發出三個 Request，Response 要對應哪一個？

需要：

message_id
correlation_id

否則在 Parallel Execution 中很容易對錯。

Versioning

Protocol 一定會演進。

例如：

task_result v1
只有 summary

task_result v2
增加 evidence

如果 Agent A 已更新，Agent B 還沒更新，怎麼辦？

需要：

• version field
• backward compatibility
• migration
• unknown field policy

不要假設所有 Agent 永遠一起 Deploy。

Validation

Protocol Message 進入系統時要驗證：

• Required fields
• Type
• Enum
• Size
• Scope
• Signature
• Version

如果 Validation 失敗，應該回 Structured Error。

不是讓下游 Agent自己猜。

Trust Boundary

Agent Message 也可能是不可信輸入。

尤其來自：

• External Agent
• Plugin
• MCP Server
• Third-party Service

不要因為 Message 是 JSON，就自動當成可信。

需要驗證：

• Sender Identity
• Permission
• Scope
• Payload
• Artifact Reference

Protocol 解決格式。

不等於解決信任。

Capability Negotiation

不同 Agent 可能有不同能力。

可以交換：

supported_tools
supported_protocol_version
max_payload
supported_artifact_types

這叫 Capability Negotiation。

Coordinator 可以先知道：

這個 Agent 到底能不能接這個 Task？

避免派出去才失敗。

Protocol vs Shared Memory

另一個常見設計是：

全部 Agent 共用一個 Database，大家自己讀寫。

這不是 Protocol 消失。

只是 Protocol 被藏進 Shared Schema。

如果沒有：

• ownership
• version
• event
• conflict rule

Shared DB 一樣會混亂。

顯式 Message Protocol 通常比較容易追蹤責任。

Error Protocol

錯誤也需要 Schema。

例如：

error_type
retryable
message
failed_operation
evidence
suggested_action

這讓 Coordinator 可以直接對應 Recovery Policy。

不要把 Error 只做成一段 Exception String。

常見錯誤設計

1. 全部自然語言

容易歧義。

2. Prompt 要求 JSON，但不驗證

格式仍可能錯。

3. 大型 Artifact 直接塞 Message

Context 和 Bus 都被塞滿。

4. 沒有 Correlation ID

Parallel Response 對錯。

5. 沒有 Version

不同 Agent 更新後不相容。

6. JSON = Trusted

忘記安全邊界。

第一版 Agent Protocol

可以先支援五種 Message：

task_request
task_result
progress
error
permission_request

每個都有：

message_id
type
version
task_id
sender
receiver
timestamp
payload

再加：

• schema validation
• correlation id
• artifact reference
• error response

這就已經足以支援大部分 Coordinator / Subagent。

今天的結論

Agent Protocol 的目的不是讓 Agent 「更會聊天」。

而是：

把 Agent 之間的協作從模糊自然語言，變成可驗證、可版本化、可追蹤的 Interface。

最重要的原則：

自然語言負責語意，Protocol 負責邊界。

下一篇會進入 Autonomy：

Agent 到底應該被允許自己跑多久？自主性越高，真的代表系統越強嗎？

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