6321 字
32 分钟

Multi-Agent 与 A2A 协作:从角色分工到协议化运行

本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 8 的配套学习笔记。 核心结论:Multi-Agent 的价值不在 Agent 数量,而在边界清晰的专业分工、最小上下文、独立验证与故障隔离。A2A 让跨系统 Agent 交换任务、消息和产物;它不替代 MCP 工具连接,也不替代身份、授权、事务和业务状态验证。


0. 学习目标、范围与版本说明#

学完本文后,你应该能够:

  1. 判断一个问题是需要模块化、并行节点,还是需要真正的多 Agent;
  2. 选择 supervisor-worker、planner-executor、handoff、reviewer、blackboard 或 debate 拓扑;
  3. 为每个 Agent 定义职责、输入、输出、工具、权限、预算与终止条件;
  4. 设计 Task、Message、Artifact、Decision 和 Shared State 契约;
  5. 处理任务租约、重复投递、超时、冲突、循环、取消和部分失败;
  6. 让非 LLM 服务承担事实查询、规则求值、执行和验证;
  7. 解释 A2A Agent Card、Task、Message、Part、Artifact、streaming 与 push notification;
  8. 区分 A2A、MCP、内部函数调用、消息队列和工作流编排;
  9. 建立 Agent 身份、能力发现、最小授权、来源与跨边界数据控制;
  10. 用单 Agent baseline、消融和贡献分析证明多 Agent 的净收益。

本文 A2A 内容以 2026-07-15 可访问的官方 latest 文档为参考。生产实现必须固定协商版本与 SDK 版本;不要让 /latest/ 文档在未来变化后成为唯一可复现依据。


1. 先问:为什么必须是多个 Agent#

1.1 模块不等于 Agent#

query_order() 是工具/服务
search_policy() 是检索模块
verify_amount() 是规则函数
compose_reply() 可以是一次模型调用

只有当一个单元具备相对独立的目标、上下文、决策、能力和生命周期时,才值得称为 Agent。

1.2 多 Agent 的真实收益#

Context Isolation
不同专家只看必要数据
Capability Isolation
不同身份只持有最小工具权限
Parallelism
独立子任务并发执行
Independent Review
生成与验证分离
Organizational Boundary
跨团队/供应商/系统协作
Failure Isolation
某个专家失败不污染整个 Runtime

1.3 不应使用多 Agent 的信号#

只是想让代码更模块化
任务步骤固定且简单
所有角色看到相同上下文、使用相同模型/工具
没有可测的专业分工
延迟和成本很敏感
单 Agent 已稳定完成
多角色只是在重复投票

Anthropic Effective Agents 建议从简单组合开始;OpenAI Agents SDK、Google ADK、AutoGen、LangChain/LangGraph 等都提供多 Agent 组合,但框架支持不等于业务需要。[S1]

1.4 最小证明#

引入多 Agent 前写下:

Baseline:当前单 Agent 指标
Bottleneck:它具体失败在哪里
Hypothesis:哪个边界拆分会改善什么指标
Cost:新增消息、token、延迟、故障面
Experiment:怎样通过消融证明贡献
Rollback:失败时如何回到单 Agent

2. 常见拓扑与适用边界#

2.1 Supervisor-Worker#

Supervisor
-> Worker A
-> Worker B
-> Worker C
-> aggregate/verify

适合任务分解与专家路由。风险:Supervisor 成为瓶颈和单点,错误分配会级联。

2.2 Planner-Executor#

Planner Agent -> Plan
Executor Agent/Runtime -> Observations
Planner/Repairer -> Updated Plan

适合长任务,但执行器不应由自由文本授权高风险动作。

2.3 Researcher-Writer-Reviewer#

Researcher -> Evidence Bundle
Writer -> Draft with Claims
Reviewer -> Claim/Evidence Review

适合报告与研究。Reviewer 要有独立 rubric 与来源,不只读 Writer 的自我说明。

2.4 Handoff#

Triage Agent --handoff--> Refund Specialist

控制权转移给专家,适合会话分流。需要明确上下文、权限、返回条件与用户可见身份。

2.5 Agents-as-Tools#

Manager Agent --call--> Specialist Agent --result--> Manager

Manager 保持控制,专家像有状态高级工具。OpenAI Agents SDK 公开区分 handoff 与 agent-as-tool 等组合。[S2]

2.6 Critic/Verifier#

Producer -> Artifact
Verifier -> pass/fail/unknown
Repairer -> revised artifact

适合有明确成功条件的代码、证据与业务决策。

2.7 Blackboard#

Agents <-> Shared Blackboard

Agent 读取共享任务板并提交事实/产物。适合异步、跨专业协作;必须解决并发、来源、权限和冲突。

2.8 Debate/Group Chat#

多个 Agent 交换观点再裁决。可用于高价值分析实验,但消息数量、群体偏差、迎合和无结论循环难控制,生产主链路慎用。


3. 角色设计:职责、权力与证据#

3.1 Agent Contract#

from typing import Literal
from pydantic import BaseModel
class AgentContract(BaseModel):
agent_id: str
version: str
role: str
accepted_task_types: list[str]
input_schema_ref: str
output_schema_ref: str
allowed_capabilities: list[str]
allowed_data_classes: list[str]
max_side_effect: Literal["none", "read", "reversible_write", "irreversible"]
default_budget: dict
terminal_conditions: list[str]
escalation_routes: list[str]
owner: str

3.2 单一职责不是角色扮演文案#

差:

你是一个聪明的业务专家,请努力解决问题。

好:

Policy Agent
Input: verified facts + policy query requirements
Output: evidence bundle + missing/conflicting requirements
Tools: published policy search/read only
Cannot: decide user identity, execute refund, write memory
Success: all required claims have versioned citations or explicit insufficiency

3.3 权力分离#

Context Agent:抽取/整理,不查询敏感业务
Business Service:返回权威事实,不做语言决策
Policy Agent:检索证据,不执行动作
Decision Agent:提出建议,不授权
Policy Engine:确定性裁决
Execution Service:执行已授权命令
Verification Service:查询最终状态

不是每个名字后带 Agent 的节点都需要 LLM。


4. Task Contract:协作的最小单位#

4.1 Task Envelope#

class AgentTask(BaseModel):
task_id: str
context_id: str
parent_task_id: str | None
requester_agent_id: str
assignee_agent_id: str
task_type: str
goal: str
input_refs: list[str]
constraints: list[str]
expected_artifact_schema: str
success_conditions: list[str]
deadline_at: str
budget: dict
authz_context_ref: str
idempotency_key: str
trace_id: str

4.2 Task 状态#

内部可采用:

created
-> assigned
-> accepted
-> working
-> input_required
-> completed
-> failed
-> cancelled
-> expired

跨 A2A 时映射到协商版本定义的 TaskState,不能假设不同实现的内部状态完全一致。

4.3 Task 不等于 Message#

Task:有生命周期、目标和最终产物
Message:Agent/User 之间的一次交流
Artifact:Task 生成的结果对象
Event:状态或增量变化通知

4.4 幂等#

重复交付 Task 时,Assignee 根据 idempotency_key + task_type + input versions 去重。完成的 Task 返回已有 Artifact,不重新执行副作用。


5. Message 与 Artifact:少传散文,多传引用#

5.1 Message#

class AgentMessage(BaseModel):
message_id: str
task_id: str
context_id: str
sender: str
recipient: str
role: Literal["requester", "assignee"]
parts: list[dict]
in_reply_to: str | None
created_at: str
data_classification: str

5.2 Part#

Text Part:简短解释/问题
Data Part:结构化 JSON
File Part:文件或受控 URI
Reference Part:事实、证据、Trace、Artifact 引用

5.3 Artifact#

class AgentArtifact(BaseModel):
artifact_id: str
task_id: str
name: str
schema_ref: str
parts: list[dict]
source_refs: list[str]
producer_agent: str
producer_version: str
content_hash: str
created_at: str
status: Literal["draft", "verified", "rejected"]

5.4 Provenance#

Writer 生成的报告应引用 Researcher 的 Evidence Bundle;Decision Agent 的建议应引用事实与规则 Artifact。不要把上游摘要复制后失去来源。

5.5 Data Minimization#

跨 Agent 只传任务所需字段:

不要传完整对话,如果只需 order_id + intent
不要传原始身份证明,如果只需 verified_subject_ref
不要传工具 Secret
不要把 Reviewer 的内部安全策略暴露给外部 Agent

6. 共享状态 vs 消息传递#

6.1 消息传递#

优点:边界清楚、可审计、跨系统;缺点:复制、最终一致、Schema 演进。

6.2 Shared State#

优点:协作方便、读取最新进度;缺点:并发覆盖、隐式耦合、权限复杂。

6.3 推荐混合#

Task/Message/Event 记录协作事实
Shared State 保存规范化当前视图
Artifact Store 保存不可变产物
Business System 保存最终业务真相

6.4 Blackboard Entry#

class BlackboardEntry(BaseModel):
entry_id: str
task_id: str
kind: Literal["fact", "hypothesis", "decision", "question", "artifact_ref"]
value: dict
source_refs: list[str]
author_agent: str
confidence: float | None
status: Literal["proposed", "verified", "invalidated"]
version: int

模型写入的事实默认 proposed;Verifier/权威工具确认后才是 verified

6.5 CAS 与 Event Log#

Shared State 使用 expected_version 更新;所有变更写 append-only event。这样既有当前视图,也能回放谁修改了什么。


7. 调度、租约与并行#

7.1 Task DAG#

Context Task
Business Facts ─┐
├-> Decision -> Execute -> Verify
Policy Evidence ┘

7.2 Lease#

class TaskLease(BaseModel):
task_id: str
worker_agent_id: str
lease_token: str
acquired_at: str
expires_at: str
attempt: int

Agent 必须心跳续租;过期后新 Agent 可接管。旧 Agent 完成时用 lease token/Task version CAS,防止双写。

7.3 并行一致性#

Business Agent 和 Policy Agent 并行时:

Policy Query 可能依赖 product_type/order_time

应先确定最小共享事实,或允许 Policy 返回条件化候选,汇合后再求值。

7.4 Fan-out Budget#

max_active_subtasks
max_depth
max_total_agents
max_messages
max_tokens/cost
deadline

子 Agent 不能无限再委派。

7.5 Straggler#

策略:

等待必需分支
对可选分支设 deadline
取消重复/低价值分支
返回 partial artifact + missing parts

不能因一个快速 Agent 完成就把整个 Task 标为成功。


8. Handoff、Delegation 与 Return#

8.1 Handoff#

控制权转移:

Triage -> Specialist

需要:

handoff reason
context package
allowed capabilities
return/escalation condition
user-visible disclosure

8.2 Delegation#

调用方保留主任务,委托子任务:

Coordinator -> Policy Agent: produce Evidence Bundle
Policy Agent -> Coordinator: Artifact

8.3 Peer Collaboration#

跨组织 Agent 通过 A2A Task 协作,双方各自拥有 Runtime,不共享内部 memory/CoT/tool registry。

8.4 Return Contract#

class DelegationResult(BaseModel):
task_id: str
status: Literal["completed", "failed", "input_required", "partial"]
artifact_refs: list[str]
missing_requirements: list[str]
warnings: list[str]
usage: dict
trace_ref: str

8.5 上下文不能全量转交#

新 Agent 应获取:

目标
已验证事实
相关消息摘要/引用
策略与权限
预期输出
剩余预算

不需要原 Agent 全部历史和隐藏推理。


9. A2A 协议定位#

9.1 A2A 解决什么#

A2A 官方项目把协议定位为 Agent-to-Agent 的开放协作协议:Client Agent 发现 Remote Agent 的能力,发送 Message/Task,接收状态、流式更新与 Artifact。[S3]

A2A Client Agent
-> discover Agent Card
-> authenticate
-> send message/task
-> stream/poll/push status
-> receive artifact

9.2 A2A vs MCP#

问题A2AMCP
主要连接Agent ↔ AgentHost/Agent ↔ Tool/Resource/Prompt Server
交互单位Task、Message、ArtifactTool Call、Resource Read、Prompt Get 等
对端自治对端自行规划/执行Server 暴露明确能力原语
长任务Task 生命周期、stream/push取决于工具/协议扩展
内部实现暴露不要求共享Tool/Resource Schema 可发现
共同要求身份、授权、版本、审计、最小数据身份、授权、版本、审计、最小数据

9.3 A2A vs 消息队列#

消息队列解决可靠传输/解耦;A2A 还定义 Agent 能力发现、任务/消息/产物语义。生产实现可能在内部使用队列,但二者不等价。

9.4 A2A vs Handoff#

Handoff 是一种控制模式;A2A 是可承载委派/协作的跨系统协议。一个进程内 Handoff 不必使用 A2A。


10. Agent Card 与能力发现#

10.1 Agent Card#

官方 A2A 文档使用 Agent Card 描述远程 Agent 的身份、URL、版本、能力、输入输出模式、Skills 和安全方案。[S4]

概念示例:

{
"name": "Order Policy Agent",
"description": "Returns versioned policy evidence for order fulfillment tasks",
"url": "${POLICY_AGENT_A2A_URL}",
"version": "3.4.0",
"capabilities": {
"streaming": true,
"pushNotifications": false
},
"defaultInputModes": ["application/json"],
"defaultOutputModes": ["application/json"],
"skills": [
{
"id": "refund-policy-evidence",
"name": "Refund policy evidence",
"description": "Produces evidence bundles; does not authorize refunds"
}
]
}

字段以实际协商规范为准。

10.2 Capability 不等于 Authority#

Card 声明“会创建退款”不代表当前用户授权它创建退款。调用方仍需:

验证发布者/endpoint
认证 Agent
检查本地 allowlist
最小授权 scope
每 Task 资源级 Policy

10.3 Card Trust#

来源 DNS/TLS
组织目录/签名
Card version/hash
Owner/review/expiry
安全方案
能力变化 diff

不要从任意网页自动发现 Agent 后立即交付敏感任务。

10.4 Skill 描述投毒#

Agent Card 的 Skill 描述是远端提供的不可信元数据。进入 Planner 前要做长度、内容、安全和 allowlist 检查。


11. A2A Task、Message 与 Artifact#

11.1 Task 生命周期#

A2A Task 为长时协作提供状态;官方“Life of a Task”说明 Message 可以创建/继续 Task,并在需要输入、工作和终止状态间变化。[S5]

11.2 Context ID#

同一协作上下文的多个 Task/Message 通过 Context 关联,但 Context 不是无限共享 Memory。双方仍应按 Task 最小披露信息。

11.3 Artifact 增量#

长报告/文件可以逐步更新 Artifact。接收方要根据 artifact id、append/last-chunk 等协商语义组装,并验证 hash/Schema;不能把中间 chunk 当最终完成。

11.4 Streaming#

message/stream
-> task status updates
-> artifact updates
-> terminal state

断线后使用 Task ID 查询或 resubscribe(以实际版本能力为准)。

11.5 Push Notification#

长任务可配置回调接收状态。安全要求:

验证 callback URL
防 SSRF
回调认证/签名
重放保护
事件幂等
不在 URL/query 泄露 Secret

官方 streaming/async 文档见 [S5]


12. A2A 安全与信任边界#

12.1 Agent 身份#

Human/User Principal
Calling Agent Identity
Remote Agent Identity
Delegated Scope
Target Resource

Audit 必须同时记录“哪个用户通过哪个 Agent 委托哪个远端 Agent”。

12.2 Authentication vs Authorization#

认证远端 Agent 只证明它是谁;授权还要判断:

当前用户能否调用该 Skill
能否发送这些数据
能否让远端执行该动作
返回 Artifact 能否进入当前 Context/Memory

12.3 Delegation Token#

audience=remote-agent
subject/calling-agent
delegated scopes
tenant/resource constraints
short expiry
task/context binding

不要把用户的广域 token 原样透传。

12.4 Remote Output#

远端 Message/Artifact 是不可信输入:

Schema 校验
size/type 限制
malware/content scan
Prompt Injection 隔离
source/provenance 验证
不得直接触发本地高风险工具

12.5 Data Residency#

跨系统前检查:

远端区域
数据分类
保留/训练政策
日志和子处理者
删除能力
合同与合规

13. 冲突、循环与失败处理#

13.1 冲突类型#

事实冲突
建议冲突
资源竞争
计划冲突
版本冲突

13.2 事实冲突#

根据来源权威、版本和时间交给 Verifier;不靠多数投票决定订单状态。

13.3 建议冲突#

保留不同建议、假设和证据,由 Decision Policy/人类裁决。

13.4 循环检测#

A -> B -> A 委派环
同一 task fingerprint 重复
相同 Message 内容反复
Artifact 无新增信息

保存 delegation path 与最大深度:

{
"delegation_path": ["coordinator", "policy-agent", "legal-agent"],
"max_depth": 3,
"visited_task_fingerprints": ["sha256:..."]
}

13.5 部分失败#

必需 Agent 失败 -> task fail/input_required/human
可选 Agent 失败 -> partial artifact + warning
Verifier 失败 -> unknown,不自动 pass

13.6 Cancel Propagation#

父 Task 取消后:

停止新委派
取消尚未执行子 Task
向远端发取消请求
记录不可取消的外部动作
继续对账必要结果
汇总部分完成状态

14. OrderFlow-Agent 设计#

14.1 角色#

Coordinator
固定 StateGraph + 局部 LLM 路由
Context Agent
意图、槽位、最小上下文
Business Facts Service(非 LLM)
订单、物流、工单权威查询
Policy Agent
RuleRAG + Evidence Bundle
Decision Agent
基于事实/证据提出结构化建议
Policy Engine(非 LLM)
权限、金额、条件与确认裁决
Execution Service(非 LLM)
幂等退款/补偿/工单
Verification Service(规则 + 查询)
最终业务状态与安全校验

14.2 为什么不是七个聊天 Agent#

事实查询、Policy、Execution、Verification 的核心权力应保持确定性。LLM 只用于语言理解、证据组织和复杂建议。

14.3 Shared State#

class OrderFlowSharedState(BaseModel):
run_id: str
task_id: str
intent_artifact_ref: str | None
fact_bundle_ref: str | None
evidence_bundle_ref: str | None
decision_proposal_ref: str | None
policy_decision_ref: str | None
execution_ref: str | None
verification_ref: str | None
state_version: int

14.4 协作流#

Coordinator
-> Context Agent: normalized task artifact
-> Business Facts + Policy Agent (parallel after minimum facts)
-> merge fact/evidence artifacts
-> Decision Agent: proposal
-> Policy Engine: allow/deny/confirm/human
-> Execution Service
-> Verification Service
-> Coordinator: verified response

14.5 跨系统 A2A#

如果 Policy Agent 由集团规则平台独立运行:

OrderFlow Coordinator (A2A Client)
-> discover approved Policy Agent Card
-> send Evidence Task with verified facts refs
-> stream Task status
-> receive signed Evidence Bundle Artifact
-> local schema/source/policy validation

远端只返回证据,不拥有退款执行权限。

14.6 Coordinator Runtime 骨架#

class Coordinator:
async def advance(self, run_id: str) -> None:
state = await self.state_store.load_for_update(run_id)
enforce_team_budget(state)
ready = self.task_graph.ready_tasks(state)
for task in ready[: state.remaining_parallel_slots]:
contract = self.agent_registry.resolve(task.assignee, task.task_type)
enforce_delegation_policy(state, task, contract)
lease = await self.leases.reserve(task.id, contract.agent_id)
await self.dispatcher.dispatch(
task=build_minimal_task_envelope(task, state),
lease=lease,
)
events = await self.inbox.read_new(run_id, after=state.inbox_watermark)
for event in deduplicate_and_order(events):
state = apply_validated_agent_event(state, event)
conflicts = detect_conflicts(state.blackboard)
if conflicts:
state = route_conflicts_to_verifier(state, conflicts)
await self.state_store.compare_and_swap(state)

关键点:

调度依据 Task Graph,不依赖自由聊天
每次委派前重新做 Policy
任务包按最小数据构建
结果通过 Inbox 去重/排序/Schema 校验
事实冲突进入 Verifier
共享状态用 CAS 提交

14.7 迟到结果#

Worker lease 已过期后返回 Artifact:

验证 task/attempt/lease token
-> 若新 Attempt 已完成,不覆盖当前结果
-> 保存为 late artifact 供诊断
-> 如内容仍有价值,由 Verifier 显式合并

不能用“最后到达者覆盖”。


15. 大厂与主流框架公开方案对照#

方案公开多 Agent 抽象可借鉴仍需自建
OpenAI Agents SDKhandoff、agents-as-tools控制权/专家调用模式跨系统任务治理
Anthropic patternsorchestrator-workers、parallelization、evaluator-optimizer简单组合与分工持久状态/协议
Google ADKparent/sub-agent、transfer、shared session stateAgent hierarchy业务权限/事务
Microsoft AutoGenteams、group chat、Magentic-One消息驱动与 ledger生产约束/成本
AWS Bedrocksupervisor + collaborator Agents托管 multi-agent collaboration领域验证/可迁移性
LangChain/LangGraphsubagents、handoffs、router、custom workflow多种拓扑与 StateGraph跨组织协议
A2AAgent Card、Task、Message、Artifact、stream/push跨 Agent 互操作内部工具/业务治理
MCPTool/Resource/Prompt 等原语Agent 到能力连接Agent 间长任务协作

官方资料见 [S1][S6]


16. 论文思想与工程落点#

工作主要思想工程落点局限
AutoGen [P1]多 Agent 可对话编程框架消息、角色、工具、人类代理对话不等于事务协议
CAMEL [P2]role-playing agent cooperation角色和任务提示角色漂移/模拟场景
MetaGPT [P3]SOP 化软件团队结构化角色产物软件场景结果不可泛化
ChatDev [P4]communicative software agents阶段化协作成本/正确性需外部测试
AgentVerse [P5]recruitment、decision、execution、evaluation动态团队与阶段复杂度与稳定性
Multi-Agent Debate [P6]多模型讨论提高推理冲突/裁决实验同质错误与消息成本
Mixture-of-Agents [P7]多模型输出分层聚合多样模型组合延迟/token 高
Magentic-One [P8]orchestrator ledger + specialistsTask/Progress Ledger通用任务与业务差异
GAIA [P9]真实助手问题需工具/推理端到端任务评估不覆盖内部权限

论文展示的是特定模型、任务和通信设定下的结果。生产系统要验证“分工带来的独立信息/能力”是否超过协调开销。


17. Multi-Agent Evaluation#

17.1 Baseline#

Single strong Agent
Single Agent + deterministic tools
Workflow + specialist calls
Full Multi-Agent

不能只比较“多 Agent v1 vs 没有系统”。

17.2 协作指标#

Task Allocation Accuracy
Handoff Precision/Recall
Subtask Success Rate
Artifact Schema Validity
Message Efficiency
Duplicate Work Rate
Conflict Resolution Accuracy
Loop/Deadlock Rate

17.3 端到端#

Verified Task Success
Policy Compliance
Unsafe Action Rate
Latency
Cost per Verified Success
Human Escalation

17.4 Agent Contribution#

消融:

移除 Agent
替换为 deterministic node
替换为 oracle artifact
打乱/隐藏它的输出
限制其工具

计算边际贡献:

Δ success
Δ cost
Δ latency
Δ safety

17.5 Communication Ablation#

比较:

完整 history
结构化 artifact only
minimal facts + references

验证减少消息是否保持质量并降低泄露/成本。

17.6 A2A 指标#

Agent Discovery Success
Card Trust/Version Failure
Task Completion/Expiry
Stream Reconnect Success
Push Delivery Duplicate Rate
Artifact Assembly Accuracy
Cross-agent Trace Completeness
Delegated Scope Violation

17.7 跨 Agent Trace#

root agent.run span
-> coordinator.allocate
-> a2a.client.send (task_id, remote_agent_id)
[trace propagation across boundary]
-> remote agent.task
-> remote tool/retrieval spans
-> a2a.client.artifact.receive
-> artifact.verify
-> decision.merge

跨组织不一定允许共享完整 Trace,但至少交换:

traceparent/correlation id(按信任策略)
task/message/artifact ids
Agent Card version/hash
remote agent version
latency/usage summary
terminal error code
artifact content hash

敏感 Prompt、工具参数和内部拓扑不应为追踪方便自动跨边界暴露。

17.8 协作成本分解#

Useful Work
直接产生被采用 Artifact 的模型/工具成本
Coordination
路由、消息、状态同步、聚合
Redundancy
重复研究/重复调用
Verification
冲突与产物校验
Recovery
重试、迟到结果、重新委派

上线前应报告各部分比例,而不仅是总 token。多 Agent 的质量增益可能被协调/冗余成本完全抵消。

17.9 Online Guardrail#

max remote agents per run
max delegation depth
max cross-boundary bytes
max coordination token ratio
max duplicate task rate
kill switch per agent/version
fallback to local workflow

Card/Agent 版本出现高错误率或安全事件时,Control Plane 应能立即停用,并让未开始 Task 回到本地 fallback。


18. 测试与故障注入#

18.1 A2A 版本与兼容性测试#

本小节属于测试章节的前置协议检查。

Client 不能只测“HTTP 200”。契约矩阵至少覆盖:

协议版本协商
Agent Card 必需/未知字段
输入输出 MIME mode
Task state 映射
Message Part 类型
Artifact 增量组装
stream reconnect/resubscribe
push event duplicate/out-of-order
错误对象与重试语义

保存 fixture:

agent-card-vN.json
task-working.json
task-input-required.json
artifact-update-1.json
artifact-update-final.json
error-auth-expired.json

远端升级先进入 compatibility/shadow 环境,通过 Artifact 与状态回归后再切换 Card pointer。

18.2 Contract#

Task/Message/Artifact Schema
版本兼容
未知 Part/MIME
大型 Artifact
重复/乱序事件

18.3 Coordination#

Supervisor 错误路由
两个 Worker 抢同一 lease
Worker 超时后旧结果到达
并行事实版本冲突
Agent A/B 委派循环

18.4 A2A#

Agent Card 变更/伪造
认证过期
Task input_required
stream 断线与 resubscribe
push 重放/SSRF
取消与完成竞态

18.5 Security#

远端 Artifact Prompt Injection
过宽 delegation token
跨租户 reference
Agent Card Skill 描述投毒
远端请求额外敏感数据

18.6 Recovery#

Coordinator 崩溃
Task 已完成但 Artifact 未登记
Artifact 已登记但 Shared State CAS 失败
Verifier 不可用
部分分支成功

19. Failure Taxonomy#

编号失败示例首要层
A01Unneeded Split模块被包装成 AgentArchitecture
A02Role Overlap两 Agent 重复查询Role Design
A03Wrong AllocationSupervisor 分给错误专家Router
A04Context Over-share全历史发给外部 AgentContext Policy
A05Artifact Loss输出无 Schema/来源Contract
A06State Race并发覆盖 BlackboardState Store
A07Duplicate Task重复副作用Idempotency
A08Delegation LoopA->B->ACoordinator
A09Conflict Misread多数投票覆盖权威事实Verifier
A10Straggler Stall可选 Agent 阻塞全局Scheduler
A11Handoff Loss专家缺关键事实Handoff Package
A12Scope Violation远端 Agent 获广域 tokenAuthorization
A13Artifact Injection远端文本控制本地工具Trust Boundary
A14No Net Benefit成本增但成功率不升Evaluation

20. 常见反模式#

20.1 每个函数都是 Agent#

增加模型调用、状态和故障面,没有自治收益。

20.2 所有 Agent 使用同一上下文#

没有上下文隔离,只复制成本和泄露面。

20.3 群聊就是协作协议#

自然语言消息无法替代 Task 生命周期、Artifact Schema 和幂等。

20.4 多数投票决定业务事实#

订单状态由真相源决定,不由 Agent 数量决定。

20.5 Supervisor 有超级权限#

路由组件不应自动拥有所有执行能力。

20.6 Agent Card 声明就是可信能力#

Card 需要来源、签名/目录、版本和本地策略验证。

20.7 A2A 替代 MCP#

自治 Agent 协作与工具/资源暴露是不同抽象。

20.8 只看最终答案#

错误路由、重复工作、越权数据可能被最终话术掩盖。


21. 项目目录与实践任务#

app/
multi_agent/
contracts.py
coordinator.py
scheduler.py
leases.py
blackboard.py
artifacts.py
conflict_resolver.py
budgets.py
agents/
context_agent.py
policy_agent.py
decision_agent.py
services/
business_facts.py
policy_engine.py
execution.py
verification.py
a2a/
agent_card.py
client.py
server.py
auth.py
task_mapper.py
artifact_validator.py
push_receiver.py
tests/
contracts/
coordination/
a2a/
security/
recovery/
scenarios/
data/
multi_agent_eval.jsonl
docs/
role_matrix.md
collaboration_protocol.md
a2a_trust_model.md

实践顺序:

1. 建单 Agent + Workflow baseline
2. 只拆一个有明确瓶颈的 Policy Agent
3. 用 Artifact Contract 代替自由聊天
4. 加 Task lease/idempotency/budget
5. 加独立 Verification Service
6. 做单/多 Agent 消融
7. 再把跨系统 Policy Agent 暴露为 A2A
8. 加 Card trust、auth、stream/push recovery
9. 做循环、重复、注入与取消测试
10. 净收益成立后再增加角色

22. 达标检查清单#

Role/Topology#

  • 每个 Agent 有独立目标、输入输出、能力和边界;
  • 能说明为何不是模块/工具/固定节点;
  • 非 LLM 服务承担事实、Policy、Execution、Verification;
  • 拓扑与任务依赖匹配;
  • 有 fan-out/depth/message/cost 预算。

Coordination#

  • Task/Message/Artifact/Event 分离;
  • Artifact 有 Schema、hash、来源和 Producer 版本;
  • Shared State 使用 CAS,事件可回放;
  • Task 有 lease/idempotency/deadline;
  • 支持 partial/input_required/cancel/recovery。

A2A/Security#

  • 区分 A2A 与 MCP;
  • Agent Card 进入本地可信目录后才可用;
  • Delegation Token 有 audience/scope/resource/expiry;
  • 远端 Message/Artifact 视为不可信输入;
  • streaming/push 支持重连、去重和 SSRF 防护;
  • 跨境/保留/删除策略在发送前检查。

Evaluation#

  • 有单强 Agent baseline;
  • 做 Agent 与通信消融;
  • 统计边际成功、成本、延迟和安全贡献;
  • 测路由、冲突、循环、重复和部分失败;
  • 无净收益时能收回角色。

23. 面试与架构评审问题#

  1. 模块、工具和 Agent 有什么边界?
  2. Supervisor-Worker 与 Agents-as-Tools 有何区别?
  3. Handoff 时最小上下文包包含什么?
  4. Shared State 和消息传递如何组合?
  5. 如何防止两个 Agent 同时完成同一 Task?
  6. 多 Agent 冲突为什么不能总用投票?
  7. A2A 与 MCP 分别解决什么问题?
  8. Agent Card 为什么不是授权证明?
  9. A2A streaming/push 有哪些恢复与安全风险?
  10. 如何防止跨 Agent Prompt Injection 触发本地工具?
  11. 如何量化一个 Agent 的边际贡献?
  12. 什么时候应该把多 Agent 收缩回 Workflow?

24. 参考资料与延伸阅读#

以下资料用于核对公开协议、框架能力和论文原始思想。A2A /latest/ 文档会演进,生产系统需固定版本;论文中的协作收益需在自己的模型、任务和通信预算下复验。

官方多 Agent 与 A2A#

[S1] 多 Agent 官方工程模式#

[S2] OpenAI Handoff 与 Agents-as-Tools#

[S3] A2A 官方规范与架构#

[S4] A2A Agent Discovery#

[S5] A2A Task 与异步交互#

[S6] 云与框架多 Agent#

论文与 Benchmark#

[P1] AutoGen#

[P2] CAMEL#

[P3] MetaGPT#

[P4] ChatDev#

[P5] AgentVerse#

[P6] Multi-Agent Debate#

[P7] Mixture-of-Agents#

[P8] Magentic-One#

[P9] GAIA#


25. 阶段总结#

可靠的 Multi-Agent 系统不是“多个模型互相聊天”,而是:

角色有不可重叠的职责;
Task 有目标、预算和生命周期;
Message 有最小数据边界;
Artifact 有 Schema、来源和版本;
Shared State 有并发控制;
委派有身份、权限和深度;
冲突由证据与 Policy 解决;
最终结果由环境 Verifier 确认。

A2A 进一步让这些协作跨越进程、框架和组织,但协议互通不等于信任互通。每个跨系统 Task 仍要回答:

对方是谁?
公开声称会什么?
当前主体允许委托什么?
能发送哪些数据?
产物如何验证?
失败、取消和重放如何收敛?

只有多 Agent 相比单 Agent/Workflow 在验证成功率、隔离、并行或组织边界上产生可测净收益,新增的通信、成本和故障面才值得承担。

Multi-Agent 与 A2A 协作:从角色分工到协议化运行
https://jupiter-ws.cn/posts/agent/multi-agent-a2a-collaboration/
作者
Jupiter
发布于
2026-04-17
许可协议
CC BY-NC-SA 4.0