Multi-Agent 与 A2A 协作:从角色分工到协议化运行
本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 8 的配套学习笔记。 核心结论:Multi-Agent 的价值不在 Agent 数量,而在边界清晰的专业分工、最小上下文、独立验证与故障隔离。A2A 让跨系统 Agent 交换任务、消息和产物;它不替代 MCP 工具连接,也不替代身份、授权、事务和业务状态验证。
0. 学习目标、范围与版本说明
学完本文后,你应该能够:
- 判断一个问题是需要模块化、并行节点,还是需要真正的多 Agent;
- 选择 supervisor-worker、planner-executor、handoff、reviewer、blackboard 或 debate 拓扑;
- 为每个 Agent 定义职责、输入、输出、工具、权限、预算与终止条件;
- 设计 Task、Message、Artifact、Decision 和 Shared State 契约;
- 处理任务租约、重复投递、超时、冲突、循环、取消和部分失败;
- 让非 LLM 服务承担事实查询、规则求值、执行和验证;
- 解释 A2A Agent Card、Task、Message、Part、Artifact、streaming 与 push notification;
- 区分 A2A、MCP、内部函数调用、消息队列和工作流编排;
- 建立 Agent 身份、能力发现、最小授权、来源与跨边界数据控制;
- 用单 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 某个专家失败不污染整个 Runtime1.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:失败时如何回到单 Agent2. 常见拓扑与适用边界
2.1 Supervisor-Worker
Supervisor -> Worker A -> Worker B -> Worker C -> aggregate/verify适合任务分解与专家路由。风险:Supervisor 成为瓶颈和单点,错误分配会级联。
2.2 Planner-Executor
Planner Agent -> PlanExecutor Agent/Runtime -> ObservationsPlanner/Repairer -> Updated Plan适合长任务,但执行器不应由自由文本授权高风险动作。
2.3 Researcher-Writer-Reviewer
Researcher -> Evidence BundleWriter -> Draft with ClaimsReviewer -> 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--> ManagerManager 保持控制,专家像有状态高级工具。OpenAI Agents SDK 公开区分 handoff 与 agent-as-tool 等组合。[S2]
2.6 Critic/Verifier
Producer -> ArtifactVerifier -> pass/fail/unknownRepairer -> revised artifact适合有明确成功条件的代码、证据与业务决策。
2.7 Blackboard
Agents <-> Shared BlackboardAgent 读取共享任务板并提交事实/产物。适合异步、跨专业协作;必须解决并发、来源、权限和冲突。
2.8 Debate/Group Chat
多个 Agent 交换观点再裁决。可用于高价值分析实验,但消息数量、群体偏差、迎合和无结论循环难控制,生产主链路慎用。
3. 角色设计:职责、权力与证据
3.1 Agent Contract
from typing import Literalfrom 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: str3.2 单一职责不是角色扮演文案
差:
你是一个聪明的业务专家,请努力解决问题。好:
Policy AgentInput: verified facts + policy query requirementsOutput: evidence bundle + missing/conflicting requirementsTools: published policy search/read onlyCannot: decide user identity, execute refund, write memorySuccess: all required claims have versioned citations or explicit insufficiency3.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: str4.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: str5.2 Part
Text Part:简短解释/问题Data Part:结构化 JSONFile Part:文件或受控 URIReference 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 的内部安全策略暴露给外部 Agent6. 共享状态 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 -> VerifyPolicy Evidence ┘7.2 Lease
class TaskLease(BaseModel): task_id: str worker_agent_id: str lease_token: str acquired_at: str expires_at: str attempt: intAgent 必须心跳续租;过期后新 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_subtasksmax_depthmax_total_agentsmax_messagesmax_tokens/costdeadline子 Agent 不能无限再委派。
7.5 Straggler
策略:
等待必需分支对可选分支设 deadline取消重复/低价值分支返回 partial artifact + missing parts不能因一个快速 Agent 完成就把整个 Task 标为成功。
8. Handoff、Delegation 与 Return
8.1 Handoff
控制权转移:
Triage -> Specialist需要:
handoff reasoncontext packageallowed capabilitiesreturn/escalation conditionuser-visible disclosure8.2 Delegation
调用方保留主任务,委托子任务:
Coordinator -> Policy Agent: produce Evidence BundlePolicy Agent -> Coordinator: Artifact8.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: str8.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 artifact9.2 A2A vs MCP
| 问题 | A2A | MCP |
|---|---|---|
| 主要连接 | Agent ↔ Agent | Host/Agent ↔ Tool/Resource/Prompt Server |
| 交互单位 | Task、Message、Artifact | Tool 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 资源级 Policy10.3 Card Trust
来源 DNS/TLS组织目录/签名Card version/hashOwner/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 PrincipalCalling Agent IdentityRemote Agent IdentityDelegated ScopeTarget ResourceAudit 必须同时记录“哪个用户通过哪个 Agent 委托哪个远端 Agent”。
12.2 Authentication vs Authorization
认证远端 Agent 只证明它是谁;授权还要判断:
当前用户能否调用该 Skill能否发送这些数据能否让远端执行该动作返回 Artifact 能否进入当前 Context/Memory12.3 Delegation Token
audience=remote-agentsubject/calling-agentdelegated scopestenant/resource constraintsshort expirytask/context binding不要把用户的广域 token 原样透传。
12.4 Remote Output
远端 Message/Artifact 是不可信输入:
Schema 校验size/type 限制malware/content scanPrompt 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 + warningVerifier 失败 -> unknown,不自动 pass13.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: int14.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 response14.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 SDK | handoff、agents-as-tools | 控制权/专家调用模式 | 跨系统任务治理 |
| Anthropic patterns | orchestrator-workers、parallelization、evaluator-optimizer | 简单组合与分工 | 持久状态/协议 |
| Google ADK | parent/sub-agent、transfer、shared session state | Agent hierarchy | 业务权限/事务 |
| Microsoft AutoGen | teams、group chat、Magentic-One | 消息驱动与 ledger | 生产约束/成本 |
| AWS Bedrock | supervisor + collaborator Agents | 托管 multi-agent collaboration | 领域验证/可迁移性 |
| LangChain/LangGraph | subagents、handoffs、router、custom workflow | 多种拓扑与 StateGraph | 跨组织协议 |
| A2A | Agent Card、Task、Message、Artifact、stream/push | 跨 Agent 互操作 | 内部工具/业务治理 |
| MCP | Tool/Resource/Prompt 等原语 | Agent 到能力连接 | Agent 间长任务协作 |
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 + specialists | Task/Progress Ledger | 通用任务与业务差异 |
| GAIA [P9] | 真实助手问题需工具/推理 | 端到端任务评估 | 不覆盖内部权限 |
论文展示的是特定模型、任务和通信设定下的结果。生产系统要验证“分工带来的独立信息/能力”是否超过协调开销。
17. Multi-Agent Evaluation
17.1 Baseline
Single strong AgentSingle Agent + deterministic toolsWorkflow + specialist callsFull Multi-Agent不能只比较“多 Agent v1 vs 没有系统”。
17.2 协作指标
Task Allocation AccuracyHandoff Precision/RecallSubtask Success RateArtifact Schema ValidityMessage EfficiencyDuplicate Work RateConflict Resolution AccuracyLoop/Deadlock Rate17.3 端到端
Verified Task SuccessPolicy ComplianceUnsafe Action RateLatencyCost per Verified SuccessHuman Escalation17.4 Agent Contribution
消融:
移除 Agent替换为 deterministic node替换为 oracle artifact打乱/隐藏它的输出限制其工具计算边际贡献:
Δ successΔ costΔ latencyΔ safety17.5 Communication Ablation
比较:
完整 history结构化 artifact onlyminimal facts + references验证减少消息是否保持质量并降低泄露/成本。
17.6 A2A 指标
Agent Discovery SuccessCard Trust/Version FailureTask Completion/ExpiryStream Reconnect SuccessPush Delivery Duplicate RateArtifact Assembly AccuracyCross-agent Trace CompletenessDelegated Scope Violation17.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 idsAgent Card version/hashremote agent versionlatency/usage summaryterminal error codeartifact content hash敏感 Prompt、工具参数和内部拓扑不应为追踪方便自动跨边界暴露。
17.8 协作成本分解
Useful Work 直接产生被采用 Artifact 的模型/工具成本
Coordination 路由、消息、状态同步、聚合
Redundancy 重复研究/重复调用
Verification 冲突与产物校验
Recovery 重试、迟到结果、重新委派上线前应报告各部分比例,而不仅是总 token。多 Agent 的质量增益可能被协调/冗余成本完全抵消。
17.9 Online Guardrail
max remote agents per runmax delegation depthmax cross-boundary bytesmax coordination token ratiomax duplicate task ratekill switch per agent/versionfallback to local workflowCard/Agent 版本出现高错误率或安全事件时,Control Plane 应能立即停用,并让未开始 Task 回到本地 fallback。
18. 测试与故障注入
18.1 A2A 版本与兼容性测试
本小节属于测试章节的前置协议检查。
Client 不能只测“HTTP 200”。契约矩阵至少覆盖:
协议版本协商Agent Card 必需/未知字段输入输出 MIME modeTask state 映射Message Part 类型Artifact 增量组装stream reconnect/resubscribepush event duplicate/out-of-order错误对象与重试语义保存 fixture:
agent-card-vN.jsontask-working.jsontask-input-required.jsonartifact-update-1.jsonartifact-update-final.jsonerror-auth-expired.json远端升级先进入 compatibility/shadow 环境,通过 Artifact 与状态回归后再切换 Card pointer。
18.2 Contract
Task/Message/Artifact Schema版本兼容未知 Part/MIME大型 Artifact重复/乱序事件18.3 Coordination
Supervisor 错误路由两个 Worker 抢同一 leaseWorker 超时后旧结果到达并行事实版本冲突Agent A/B 委派循环18.4 A2A
Agent Card 变更/伪造认证过期Task input_requiredstream 断线与 resubscribepush 重放/SSRF取消与完成竞态18.5 Security
远端 Artifact Prompt Injection过宽 delegation token跨租户 referenceAgent Card Skill 描述投毒远端请求额外敏感数据18.6 Recovery
Coordinator 崩溃Task 已完成但 Artifact 未登记Artifact 已登记但 Shared State CAS 失败Verifier 不可用部分分支成功19. Failure Taxonomy
| 编号 | 失败 | 示例 | 首要层 |
|---|---|---|---|
| A01 | Unneeded Split | 模块被包装成 Agent | Architecture |
| A02 | Role Overlap | 两 Agent 重复查询 | Role Design |
| A03 | Wrong Allocation | Supervisor 分给错误专家 | Router |
| A04 | Context Over-share | 全历史发给外部 Agent | Context Policy |
| A05 | Artifact Loss | 输出无 Schema/来源 | Contract |
| A06 | State Race | 并发覆盖 Blackboard | State Store |
| A07 | Duplicate Task | 重复副作用 | Idempotency |
| A08 | Delegation Loop | A->B->A | Coordinator |
| A09 | Conflict Misread | 多数投票覆盖权威事实 | Verifier |
| A10 | Straggler Stall | 可选 Agent 阻塞全局 | Scheduler |
| A11 | Handoff Loss | 专家缺关键事实 | Handoff Package |
| A12 | Scope Violation | 远端 Agent 获广域 token | Authorization |
| A13 | Artifact Injection | 远端文本控制本地工具 | Trust Boundary |
| A14 | No 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.pytests/ contracts/ coordination/ a2a/ security/ recovery/ scenarios/data/ multi_agent_eval.jsonldocs/ role_matrix.md collaboration_protocol.md a2a_trust_model.md实践顺序:
1. 建单 Agent + Workflow baseline2. 只拆一个有明确瓶颈的 Policy Agent3. 用 Artifact Contract 代替自由聊天4. 加 Task lease/idempotency/budget5. 加独立 Verification Service6. 做单/多 Agent 消融7. 再把跨系统 Policy Agent 暴露为 A2A8. 加 Card trust、auth、stream/push recovery9. 做循环、重复、注入与取消测试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. 面试与架构评审问题
- 模块、工具和 Agent 有什么边界?
- Supervisor-Worker 与 Agents-as-Tools 有何区别?
- Handoff 时最小上下文包包含什么?
- Shared State 和消息传递如何组合?
- 如何防止两个 Agent 同时完成同一 Task?
- 多 Agent 冲突为什么不能总用投票?
- A2A 与 MCP 分别解决什么问题?
- Agent Card 为什么不是授权证明?
- A2A streaming/push 有哪些恢复与安全风险?
- 如何防止跨 Agent Prompt Injection 触发本地工具?
- 如何量化一个 Agent 的边际贡献?
- 什么时候应该把多 Agent 收缩回 Workflow?
24. 参考资料与延伸阅读
以下资料用于核对公开协议、框架能力和论文原始思想。A2A
/latest/文档会演进,生产系统需固定版本;论文中的协作收益需在自己的模型、任务和通信预算下复验。
官方多 Agent 与 A2A
[S1] 多 Agent 官方工程模式
- Anthropic Building effective agents;
- Google ADK Multi-agent systems;
- LangChain Multi-agent。
[S2] OpenAI Handoff 与 Agents-as-Tools
[S3] A2A 官方规范与架构
- A2A Protocol;
- A2A Specification;
- a2aproject/A2A;
- Google Developers Blog A2A: a new era of agent interoperability。
[S4] A2A Agent Discovery
[S5] A2A Task 与异步交互
[S6] 云与框架多 Agent
- Microsoft AutoGen Teams;
- AWS Multi-agent collaboration。
论文与 Benchmark
[P1] AutoGen
- Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, 2023。
[P2] CAMEL
- Li et al., CAMEL: Communicative Agents for Mind Exploration of Large Scale Language Model Society, NeurIPS 2023。
[P3] MetaGPT
- Hong et al., MetaGPT: Meta Programming for Multi-Agent Collaborative Framework, ICLR 2024。
[P4] ChatDev
- Qian et al., ChatDev: Communicative Agents for Software Development, ACL 2024。
[P5] AgentVerse
- Chen et al., AgentVerse: Facilitating Multi-Agent Collaboration and Exploring Emergent Behaviors, ICLR 2024。
[P6] Multi-Agent Debate
- Du et al., Improving Factuality and Reasoning in Language Models through Multiagent Debate, ICML 2024。
[P7] Mixture-of-Agents
- Wang et al., Mixture-of-Agents Enhances Large Language Model Capabilities, 2024。
[P8] Magentic-One
- Fourney et al., Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks, 2024。
[P9] GAIA
- Mialon et al., GAIA: A Benchmark for General AI Assistants, ICLR 2024。
25. 阶段总结
可靠的 Multi-Agent 系统不是“多个模型互相聊天”,而是:
角色有不可重叠的职责;Task 有目标、预算和生命周期;Message 有最小数据边界;Artifact 有 Schema、来源和版本;Shared State 有并发控制;委派有身份、权限和深度;冲突由证据与 Policy 解决;最终结果由环境 Verifier 确认。A2A 进一步让这些协作跨越进程、框架和组织,但协议互通不等于信任互通。每个跨系统 Task 仍要回答:
对方是谁?公开声称会什么?当前主体允许委托什么?能发送哪些数据?产物如何验证?失败、取消和重放如何收敛?只有多 Agent 相比单 Agent/Workflow 在验证成功率、隔离、并行或组织边界上产生可测净收益,新增的通信、成本和故障面才值得承担。