Agent 协议地图：MCP、A2A 与运行时如何分工

Agent 生态里最容易混淆的是协议与框架。把它们放到不同层次，选择会清楚很多。

三个层次

层次	解决的问题	代表
工具与上下文协议	如何发现并调用外部能力	MCP
Agent 间协议	独立 Agent 如何交换任务与 Artifact	A2A
工作流运行时	单个应用如何管理状态、循环与恢复	LangGraph、Agents SDK

MCP 规定 Host、Client、Server 和 tools/resources/prompts 等原语；A2A 描述 Agent Card、skills、messages、tasks 与 artifacts。运行时负责本应用内部的状态和执行策略。

什么时候先不用多 Agent

如果任务可以由一个 Agent 调用几个清晰工具完成，单 Agent 更容易测试和追踪。只有当权限、上下文、生命周期或团队边界确实独立时，再引入远程 Agent 或 handoff。

评估一个新框架

• 能否固定模型与工具输出进行确定性测试？
• 是否支持超时、取消、checkpoint 和人工确认？
• Trace 是否覆盖模型、工具和状态转换？
• 能否导出数据，避免关键资产被框架锁定？
• 采用协议后，集成代码是否真的减少？

实践建议

先实现一个只读 MCP Server，再实现一个最小 A2A Agent；使用同一“查询技术笔记”任务比较消息、认证、错误和长任务处理。实验过程记录在项目页的 MCP × A2A Interoperability Lab。

规范会变化，实施前重新查看 MCP 最新规范 与 A2A 文档。