MCP与A2A成为热点：企业AI Agent如何连接工具、系统与其他智能体？

先分清两个协议分别解决什么问题

MCP采用客户端与服务器架构，服务器可以暴露工具、资源和提示模板，让AI应用以统一方式发现和调用能力。例如查询订单、读取知识库、创建工单或获取数据库结构。它关注的是“一个Agent如何获得上下文并使用工具”。

A2A面向独立智能体之间的互操作，支持能力发现、任务状态、消息、产物、流式响应和长任务通知。它关注的是“不同Agent如何了解彼此能力、委派任务并交换结果”。两者可以配合使用，不是互相替代。

• Agent到工具、API和资源：优先考虑MCP
• Agent到Agent的跨团队或跨平台协作：考虑A2A
• 简单内部调用：现有API和消息机制可能已经足够
• 协议只解决连接标准，不自动解决业务语义和质量

企业落地不应绕过现有API与集成治理

企业已经存在API网关、服务总线、主数据、权限平台和审计体系时，MCP服务器应建立在这些能力之上，而不是直接把数据库或核心系统裸露给模型。协议适配层负责把现有服务转化为Agent可理解的工具描述，同时保留原有鉴权、限流和审计。

对于没有稳定API的遗留系统，应先评估接口改造、只读数据服务或受控自动化方案。让Agent直接模拟人工点击虽然能快速验证，但长期稳定性、可审计性和变更成本通常较差。

工具设计质量决定Agent是否可靠

工具名称、描述、输入结构和返回结果都会影响模型的选择。一个“操作订单”的大工具往往边界模糊，更稳妥的方式是拆分查询订单、创建草稿、校验库存、提交审批等能力，并为高风险动作设计明确确认。

返回内容应尽量结构化，包含状态、错误码、可追踪ID和必要依据。工具必须具备幂等、超时、重试、限流和失败补偿机制，避免Agent重复调用造成重复下单、重复通知或数据污染。

• 一个工具只承担清晰、可描述的业务动作
• 输入参数使用严格Schema和业务校验
• 查询与写入分离，高风险写入增加审批
• 返回结果同时服务于模型判断和人工排查

授权必须绑定目标资源并遵循最小权限

远程MCP和A2A服务进入生产环境后，应使用HTTPS和成熟身份协议。访问令牌需要验证签发方、受众、有效期和权限范围，不能把上游令牌未经校验直接传给下游系统，也不能用一个长期密钥覆盖所有用户和工具。

A2A的Agent Card会描述身份、能力、服务地址和认证要求。公开目录只暴露必要信息，包含内部技能、地址或敏感能力的扩展卡片需要认证访问。跨组织协作还要明确数据传输、保存和责任边界。

多Agent系统需要目录、编排和全链路可观测

当Agent数量增加后，企业需要维护能力目录、版本、负责人、运行状态和依赖关系。编排层决定任务由谁执行、如何传递上下文、什么时候并行、何时请求人工输入，以及失败后如何回退。

每次跨Agent任务应使用统一追踪ID，记录任务状态、消息、工具调用、产物、成本和耗时。否则当最终结果出错时，很难判断问题来自模型、工具、网络、权限、业务规则还是另一个Agent。

推荐的落地顺序：先工具化，再协作化

多数企业不需要从第一天就建设复杂的多Agent网络。更合理的顺序是先梳理高价值业务能力，用标准API或MCP形成受控工具；再建立单Agent工作流和评测；当职责确实需要跨系统、跨团队或跨供应商委派时，再引入A2A。

最终验收应关注任务成功率、权限正确性、可追踪性、故障恢复和业务收益，而不是接入了多少协议或创建了多少Agent。