Skip to content

版本 9：MCP 工具与 A2A 远程 Agent

把内部能力扩展为有契约、可发现和可治理的生态连接。

它解决什么问题

当数据工具由不同团队维护、某些专家由外部服务提供时，进程内函数和本地子 Agent 不再够用。MCP 统一 Agent 对工具与资源的访问，A2A 统一 Agent 对远程 Agent 任务与产物的协作，两者解决不同边界。

核心定义与工作原理

MCP Server 暴露经过授权的搜索、数据库和文档资源；Host 决定向 Agent 提供哪些能力。A2A Remote Agent 通过 Agent Card 声明能力，以 Task、Message、Artifact 和状态生命周期协作。网关处理身份、租户、超时、签名、版本与审计。

架构视图（Architecture View）

分析时固定追问：谁拥有控制权，状态存在哪里，模型能决定什么，失败从哪里恢复，人工在哪个边界介入，运行证据如何被观察。

产品视图（Product View）

产品获得能力市场和跨团队复用，但用户承诺不能依赖不可控远端。展示外部来源与状态，观察能力发现成功率、远端 SLA、协议错误率、降级率、数据合规事件和供应商成本。

简单实践

把内部知识库接成 MCP，把外部法律研究服务建模为 A2A Agent。分别写请求契约、最小权限、超时、数据出境规则和不可用时的本地降级路径；不需要启动服务。

实践只要求架构图、状态或消息契约、失败路径和产品指标，不要求安装依赖或运行代码。

正常场景

任务按约定入口进入，编排层保留业务状态，各节点或 Agent 产出结构化结果，质量门控制下一阶段，用户获得可理解的进度与最终产物。

失败与恢复场景

模型超时、工具失败或子任务质量不足时，区分可重试、可降级和必须人工接管的错误。恢复应依赖业务状态或检查点，而不是把整段任务盲目重跑。

什么时候使用

  • 核心抽象与任务形态一致。
  • 团队能运维它的状态、观测和升级路径。
  • 能满足审批、权限、恢复与成本约束。

什么时候不要使用

同一进程的稳定函数无需协议化。不要把 MCP 当 Agent 间协作协议，也不要把 A2A 当普通工具调用；外部 Agent 不可信，其返回必须验证后才能进入报告。

Trade-offs

获得 代价
更清晰地表达目标架构 增加建模和治理成本
复用运行与生态能力 接受版本、依赖和迁移成本
提升自主性或协作能力 增加时延、成本与故障面

产品视角

  • 用户与业务问题：解决哪个可量化瓶颈？
  • 产品价值：提升成功率、速度、可控性还是覆盖范围？
  • 用户体验：进度、等待、切换和失败是否可理解？
  • 自主性边界：哪些判断交给模型，哪些由代码或人决定？
  • 数据与权限：状态、敏感数据和工具权限如何隔离？
  • 失败与降级：能否重试、续跑、切回简单流程或人工处理？
  • 产品指标：完成率、P95 时延、单任务成本、人工介入率、恢复成功率。

框架中的对应实现

MCP Host–Client–Server、capability negotiation；A2A Agent Card、Task、Message、Artifact、task lifecycle；统一身份与策略网关。

Workflow、Graph Orchestration、Supervisor、Handoff、Context Isolation、HITL、Durable Execution、Evals。

检查清单

  • [ ] 产品约束先于实现选择
  • [ ] 区分代码控制与模型控制
  • [ ] 明确状态事实源、预算和恢复点
  • [ ] 覆盖权限、审计和可观测性
  • [ ] 记录组织成本与退出方案

延伸练习与参考资料

用同一产品场景改画另一种架构，比较运行语义而非 API 长短；继续阅读对应框架的官方架构、持久化、HITL 与观测文档。