多智能体模式

只有任务边界、通信协议和冲突处理都清楚时，多 Agent 才会带来真正的收益。

文章	重点
多智能体编排模式	主管-工人、流水线和辩论
多智能体通信	任务交接、状态共享和冲突处理
A2A 协议	跨厂商、跨框架的 Agent 互操作

文章学习清单

多智能体编排模式

• 用主管-工人模式做一个任务：主管拆解，两个工人分别执行，主管汇总

  • 预期结果：主管输出带依赖、边界和验收条件的子任务，两个工人只接收各自需要的上下文并返回结构化结果，主管最后去重、补查和汇总。

  • 验收标准：日志能看到任务分派、并发或串行关系、超时/失败处理和最终裁决，工人不能越权修改主管状态。

• 用流水线做一个"调研 → 写作 → 审校"的内容生产链

  • 预期结果：调研输出证据与限制，写作只基于交接包成稿，审校按明确标准返回问题或 patch，主管决定是否重新写作。

  • 验收标准：每阶段都有可独立测试的输入输出，审校发现事实缺失或格式错误时能回到对应阶段，而不是无条件重跑整条流水线。

• 用辩论模式让两个立场相反的 Agent 评审同一份方案，再让第三个裁决

  • 预期结果：两个 Agent 的角色、证据和评价维度确实不同，裁决 Agent 按预先定义的 rubric 比较主张并保留不确定性。

  • 验收标准：同一问题重复运行时能区分共识与分歧，裁决结果能指出采纳哪条意见及原因，不能用多数票替代事实核验或安全规则。

• 对同一个模式，分别用裸代码和框架各实现一次，体会框架省了什么

  • 预期结果：裸代码版本展示状态、调度、重试、并发、checkpoint 和日志的实际工作量，框架版本能对应到这些能力而不是只改变调用语法。

  • 验收标准：能列出框架自动处理与仍需自己负责的部分，并用延迟、可调试性、依赖复杂度和迁移成本说明是否值得采用。

多智能体通信

• 实现两个 Agent 的 handoff：只传摘要和证据，不传全部历史

  • 预期结果：handoff 包至少包含任务目标、完成结论、证据、限制、未解决问题、交付格式和版本标识，下游不需要读取上游完整 messages。

  • 验收标准：比较完整历史与 handoff 的 token 和结果质量，确认下游可以继续完成任务，并能根据证据来源回溯，而不是依赖上游一句无依据的总结。

• 为共享 state 写一张字段归属表，明确谁能读、谁能写

  • 预期结果：每个字段都有 owner、读写权限、更新方式、版本和状态转移规则，例如 findings 只能追加、draft 由 writer 写、final_answer 由 supervisor 写。

  • 验收标准：让无权限 Agent 尝试修改字段时请求被拒绝或转成建议，发生并发更新时能发现版本冲突并留下审计记录。

• 让两个 Agent 分别给同一文件生成 patch，但只允许主管 Agent 落盘

  • 预期结果：两个 Agent 都基于同一基线返回文件、目标范围、意图、patch、风险和 base_hash，只有统一合并点能写文件。

  • 验收标准：文件最终只发生一次受控落盘，审校 Agent 的意见不会悄悄覆盖作者修改，应用前后都能检查 Markdown/代码结构和变更摘要。

• 故意制造同一段落冲突，练习用 base_hash 和 target_range 检测冲突

  • 预期结果：当文件版本变化或目标范围重叠时，patch 被标记为过期/冲突而不是强行套用。

  • 验收标准：能复现“同一行冲突”和“行不重叠但语义冲突”两种情况；前者重新基于最新文件生成 patch，后者由 reviewer 通读发现并记录。

• 设计一套冲突裁决规则：事实冲突、判断冲突、文件冲突分别怎么处理

  • 回答要点：事实冲突比较来源可信度、时间、统计口径和证据完整性；判断冲突使用风险 rubric、目标优先级和可逆性；文件冲突按文件锁/分区锁、base_hash、patch 队列和单一合并点处理。权限、资金、删除、生产发布等高风险冲突不能只靠模型投票，应暂停并人工确认。

• 合并后做一次 reviewer 通读，检查有没有行不冲突但语义冲突的问题

  • 预期结果：reviewer 不只检查 diff 是否能应用，还会检查术语、结论、前后引用、标题层级、重复内容和安全边界。

  • 验收标准：准备一个“不同位置表达互相矛盾”的样例，确认 reviewer 能指出冲突位置、影响和修改建议，并把最终审查结论写入 trace。

A2A 协议

• 读一遍官方规范首页与"key concepts"，说清 Agent Card / Task / Message / Artifact 各是什么

  • 参考答案：Agent Card 描述远程 Agent 的身份、能力、技能、端点和认证信息；Task 是有状态的委派工作单元；Message 是通信消息；Artifact 是交付结果。要特别区分“沟通消息”和“最终产物”，客户端应根据 Task 状态与 Artifact 处理异步任务，而不是只把一次 HTTP 返回当作完整协议。

• 找一份真实的 Agent Card（JSON）看看，弄明白 Client 靠它获得哪些信息

  • 参考答案：Client 至少要读取 supportedInterfaces、capabilities、skills、defaultInputModes、defaultOutputModes、securitySchemes 和 securityRequirements。这些字段分别用于选择传输端点、判断是否支持流式/推送、匹配技能与媒体类型、完成认证配置；名片中的声明只能作为协商输入，不能替代服务端对身份、租户和权限的实际校验。

  • 预期结果：能从 Agent Card 找到服务端点、支持的输入输出模式、技能描述、流式/推送能力、认证要求和版本信息。

  • 验收标准：根据名片设计一次客户端能力协商，并能说明哪些信息可以公开、哪些租户或权限信息不能仅靠名片信任。

• 理顺 Task 的生命周期状态，特别是 input-required / auth-required 这两个中断态怎么处理

  • 参考答案：客户端要区分 submitted、working、completed、failed、canceled、rejected 等终态，以及 input-required、auth-required 等需要继续交互的中断态。遇到 input-required，应在同一任务上下文补充消息；遇到 auth-required，应完成受控鉴权后继续，不能把中断态误判成失败或无限轮询。

• 能手写一个 SendMessage 的 JSON-RPC 请求体，说清 message / configuration 里每个字段的作用

  • 参考答案：请求信封固定包含 jsonrpc、id、method: "SendMessage" 和 params。params.message 至少包含 messageId、role 和 parts；configuration 可用 acceptedOutputModes 约束产出媒体类型、用 historyLength 控制历史长度、用 returnImmediately 选择阻塞或立即返回。客户端还应保存请求 id、message id、task id 与 context id 的关联，并对非法参数、超时和重复消息做幂等处理。

  • 预期结果：请求包含 JSON-RPC 信封、message 的 id/role/parts，以及按需填写 acceptedOutputModes、historyLength、returnImmediately 等 configuration。

  • 验收标准：字段命名、枚举、媒体类型和请求 id 符合当前版本规范，能解释客户端如何关联响应任务，并对非法参数、重复 message id 和超时做处理。

• 说清 returnImmediately = true/false 两种模式下，后续怎么拿到最终结果（阻塞 vs 轮询/订阅）

  • 参考答案：false 通常等待任务进入终态或中断态后返回，适合短任务但会占用连接；true 创建任务后立即返回，客户端要用 GetTask、SubscribeToTask 或推送通知获取状态和 Artifact。生产实现还要考虑断线恢复、重复查询、取消、终态幂等和推送签名校验。

• 用官方 SDK（Python/JS）跑通一个最小例子：一个 A2A Server + 一个 Client 完成一次任务委派

  • 参考答案：先从 Agent Card 或配置中选择双方都支持的接口和 protocolVersion，再由 Client 发送 SendMessage。Server 返回 Task 后，Client 应记录 task id 和 context id，按需通过 GetTask、SubscribeToTask 或推送配置跟踪状态，直到读取 Artifact；测试至少覆盖成功、失败或取消，以及一个长任务异步路径，并验证日志不会泄露认证密钥。

  • 预期结果：Client 能发现或配置 Server，发送任务后观察状态变化，并从最终 Task 的 Artifact 中取到结果。

  • 验收标准：至少测试一次成功、一次失败或取消、一次长任务异步获取；日志包含 task id、context id、状态转换、请求关联 id 和错误信息，不把认证密钥写入日志。

• 用一句话向别人解释清楚 A2A 和 MCP 的分工

  • 参考答案：MCP 主要标准化 Agent 与工具、资源、数据源的连接，A2A 主要标准化一个 Agent 与另一个自治 Agent 的发现、委派、状态和产物交换；两者互补而不是替代。判断时还要看边界：同一进程内的普通函数无需为了协议而协议，跨团队或跨厂商的黑盒 Agent 才更需要 A2A。

• 想清楚：你的 09-projects/projects/multi-agent-app 里，哪些 Agent 值得用 A2A 对外暴露，哪些直接编排即可？

  • 回答要点：适合暴露的是能力边界稳定、输入输出清晰、低风险且可能跨团队复用的 Agent，例如只读检索或文档摘要；内部强耦合、需要共享私有状态或频繁往返的 Agent 直接编排更简单。判断标准包括跨边界价值、认证与租户隔离、异步需求、版本兼容、延迟成本、故障恢复和可观测性。

• 解释 v1.0 的 supportedInterfaces、protocolVersion 和 tenant 如何共同完成端点选择与多租户路由

  • 参考答案：Client 按 supportedInterfaces 的顺序选择自己支持的 protocolBinding，再使用该项的 url 和 protocolVersion。若该项声明了 tenant，每个请求的 tenant 必须原样携带；这是 Server 自定义的路由键，不能把它当作用户可任意修改的租户权限。协议版本按 Major.Minor 协商，v1.0.1 的 patch 号不写进 A2A-Version。

• 说明 Agent Card 签名、扩展协商和错误详情在生产客户端中的验证顺序

  • 参考答案：先通过受信任来源获取名片，按 RFC 8785 对去掉 signatures 且遵循 ProtoJSON presence 的内容做规范化，再用受信任的 JWK 验证 JWS；随后根据 capabilities.extensions 判断必需扩展，并在请求中声明 A2A-Extensions。调用失败时按绑定解析错误：JSON-RPC 读取 -320xx 和 error.data，gRPC/HTTP 读取 google.rpc.Status 的 code、message、details，详情对象必须含 @type。这些声明都不能替代服务端实际的身份、权限和租户检查。