AI Agent 的下一场竞争，不再只是比谁的模型更聪明，而是比谁能连接更多工具、找到更多智能体，并在不同平台之间安全地把任务办完。

A2A与MCP会师：AI Agent互联网来了，企业如何抓住下一波红利？-Mo 动态
[多个企业AI Agent通过开放协议网络交换任务并协同工作]

8 月 17 日，一条看似属于开发者圈的消息，可能预示着企业 AI 市场即将换挡。

据 Axios 报道，由 Google 发起的 Agent2Agent Protocol（A2A）将成为 Agentic AI Foundation 的托管项目。它将与已经进入该开放生态的 Model Context Protocol（MCP）处在同一个“屋檐”下。Axios

如果把 AI Agent 看成数字员工，MCP 更像一套标准化“工具插座”，让 Agent 接入数据库、文件、搜索和业务系统；A2A 则像数字员工之间的协作语言，让不同厂商、不同框架、甚至不同组织中的 Agent 能够发现彼此、委派任务并交换结果。

二者靠拢的意义，并不在于又多了一个技术缩写，而在于 AI Agent 正从孤立的产品功能，走向一个类似早期互联网的开放协作网络。

对企业来说，这既是机会，也是风险。开放协议可能降低集成成本、缓解厂商锁定，却也会把身份、授权、数据可信度和责任边界推到台前。

发生了什么：A2A为何正在成为Agent世界的“通用语”？

A2A 最初由 Google 推动，随后被贡献给 Linux Foundation。它的目标，是让彼此内部实现不透明的 Agent 也能协作。官方文档列出的核心能力包括：发现对方能力、协商交互形式、处理长时任务，以及在不暴露内部记忆、工具和专有逻辑的情况下交换任务。A2A 官方文档｜A2A GitHub

这与传统 API 有一个关键区别。API 通常要求调用方预先知道明确的接口与参数，而 Agent 接收的是目标，执行路径可能随上下文变化。一个采购 Agent 可能先询价，再调用库存 Agent 核验交期，随后让合规 Agent 检查供应商，最后才生成订单。整个过程不是一组完全固定的请求，而是动态协作。

因此，A2A 解决的是“Agent 如何与另一个 Agent 共同完成工作”；MCP 解决的则更多是“Agent 如何使用外部工具与数据”。二者并非替代关系，而是上下两层互补：

协议 主要连接对象 典型任务 企业价值
MCP Agent 与工具、数据源 查数据库、读文档、调用业务系统 减少重复连接器开发
A2A Agent 与独立 Agent 能力发现、任务委派、状态同步 支持跨平台多智能体协作
共同治理层 身份、权限、审计、评测 授权、审批、追踪、回滚 让开放连接可以进入生产环境

需要强调的是，“进入同一基金会生态”不等于两种协议已经合并，也不代表所有平台从此天然兼容。它更像一个行业信号：Agent 基础设施正在从厂商各自为战，转向围绕开放标准建立公共层。

行业分析：模型竞争之后，协议层正在争夺新的入口

1. 企业不想再为每个Agent重做一遍集成

过去两年，企业上线一个 Agent，往往需要分别连接 CRM、ERP、工单、文档与身份系统。换一个模型或平台，许多集成工作又要重来。

开放协议试图把这些连接抽象成可复用接口。其商业影响类似于 USB、HTTP 或数据库标准驱动的生态扩张：当连接成本下降，创新重心便可以从“怎么接上”转向“接上之后创造什么价值”。

2. AI市场可能出现“模型—工具—Agent”三层分工

未来企业未必只采购一个全能 Agent，而可能组合不同供应商的能力：底层使用多种模型，中间由专业 Agent 完成研究、财务、法务或运营任务，上层再由一个编排者接收用户目标。

这意味着应用的护城河会从“我接入了某个大模型”，转向专有数据、业务流程、可信执行记录和持续评测。模型仍然重要，但它将越来越像可路由的计算资源。

3. 协议开放不等于风险自动消失

开放连接也会扩大攻击面。恶意 Agent 可能虚报能力，不可信结果可能沿任务链传播；提示注入、越权调用、敏感数据外泄，则可能从单一工具扩散到整个多智能体网络。

因此，企业不能把“协议兼容”理解为“安全认证”。每个 Agent 都需要可验证身份，每次委派都需要限定权限，每项关键结果都应附带来源和执行记录。真正决定企业能否采用 A2A 的，不只是通信能不能成功，而是责任能不能追溯。

4. 生产化焦点正从“能否运行”转向“能否持续治理”

OpenAI 在 2026 年 7 月发布企业 Agent 产品 Presence 时，将部署流程概括为：确定高价值工作、连接知识与系统、建立权限和政策、测试 Agent，再投入生产；上线后的会话与升级记录还要继续用于发现缺口和迭代。OpenAI Presence

这反映出一个更广泛的行业变化：Agent 已不再是一次性交付的软件功能，而是会随模型、数据、政策与用户行为变化的运行实体。它需要持续运营，而不是上线即结束。

AI Agent五大应用场景：哪些业务最先受益？

场景一：跨平台客户服务，真正把问题闭环

一个客服 Agent 可以识别客户意图，调用订单 Agent 查询履约情况，再委派退款 Agent 核对政策和金额，最后把结果写回工单系统。复杂事项进入人工审批，常规事项自动完成。

这比传统客服机器人多走了一大步：不只是回答“如何退款”，而是把退款真正办完。

适合指标：一次解决率、平均处理时长、转人工率、误操作率、客户满意度。

场景二：供应链与采购，多方Agent动态协商

采购 Agent 可根据需求寻找供应商，由库存 Agent 核验现货，物流 Agent 估算交付周期，合规 Agent 检查资质，财务 Agent 判断预算。不同组织的 Agent 可以只交换完成任务所需的信息，而不公开内部系统。

适合从低金额、标准品、规则明确的采购开始，高金额订单保留人工签批。

适合指标：采购周期、询价覆盖率、异常订单率、节省金额、人工审批时长。

场景三：企业研究与决策支持，专业Agent协同产出

研究 Agent 负责获取资料，数据 Agent 计算指标，事实核查 Agent 验证来源，写作 Agent 形成报告。通过角色分离，可以降低单一 Agent 一边搜索、一边分析、一边给自己打分所产生的偏差。

它适合竞品监测、市场情报、投研初筛、专利分析和政策跟踪，但最终决策仍应由人承担。

适合指标：研究周期、来源覆盖度、引用准确率、事实错误率、人工返工时间。

场景四：软件研发与IT运维，从写代码到跨系统处置

开发 Agent 可以接收需求、修改代码并运行测试；审查 Agent 检查质量与安全；运维 Agent 负责灰度发布和指标监控。当异常出现时，诊断 Agent 读取日志，变更 Agent 查询最近发布，修复 Agent 创建补丁。

这个场景反馈信号明确，但生产权限敏感。自动修复应设置影响范围、运行时限、审批点与回滚条件。

适合指标：交付周期、测试通过率、平均恢复时间、变更失败率、回滚率。

场景五：财务与合规，让例外处理进入自动化

财务 Agent 能读取合同、发票和采购订单，发现差异后请求业务 Agent 补充材料，再由合规 Agent 判断是否触发审查。相比只适合固定规则的传统自动化，它能处理更多半结构化信息和例外情况。

涉及付款、税务和监管申报时，应采用“Agent 准备、人类批准、系统执行”的三段式设计。

适合指标：关账周期、对账耗时、异常识别率、误报率、合规事件数。

企业落地方法论：不要先建“Agent大军”，先跑通一个闭环

A2A与MCP会师：AI Agent互联网来了，企业如何抓住下一波红利？-Mo 动态

第一步：用价值、可验证性和风险筛选任务

优先选择高频、耗时、边界清晰、结果可检查且失败可恢复的任务。可以用以下公式排优先级：

任务优先级 = 业务价值 × 执行频率 × 可验证性 ÷ 风险与集成成本

首个项目不应是“让 Agent 管理整个公司”，而应是“把一类工单的处理时间缩短 50%，同时将错误率控制在既定阈值内”。

第二步：画清任务链，再决定哪里使用MCP、哪里使用A2A

如果只是让一个 Agent 调用数据库和业务工具，MCP 或传统 API 可能已经足够；只有当任务确实跨越不同专业能力、平台或组织边界时，才需要 A2A。

不要为了追逐多智能体概念，把一个简单工作流拆成十个 Agent。更多 Agent 意味着更多延迟、成本、故障点和责任边界。

第三步：建立Agent身份和最小权限

每个 Agent 应拥有独立的工作身份，而不是共享管理员账号。权限要同时限定：可访问的数据、可调用的工具、单次任务预算、执行时段、影响对象和最大操作次数。

建议按四级自治设计：只读建议、人工确认后执行、低风险自动执行、高风险禁止自动执行。

第四步：建立证据链、评测集与故障恢复

生产 Agent 必须留下完整记录：谁发起任务、使用了哪些上下文、调用了什么工具、把任务交给了谁、为何作出决定、最终修改了什么。

上线前应使用历史案例、边界案例、恶意输入和工具故障构建评测集。上线后持续监测任务完成率、人工接管率、单任务成本、延迟与风险事件率，并准备暂停、回滚和降级路径。

第五步：小范围灰度，再扩展到多Agent网络

建议依次经历：离线测试、只读模式、影子运行、人工逐次确认、有限自治、规模化协作。每次只扩大一个变量，例如任务范围、用户群或执行权限，以便确认效果变化来自哪里。

落地阶段 Agent权限 人的角色 放行条件
离线评测 无生产访问 标注正确结果 核心指标达到基线
影子运行 只读 对比Agent与人工结果 稳定覆盖边界案例
辅助执行 每步确认 审批关键动作 回滚、审计机制完备
有限自治 自动执行低风险动作 处理异常与抽检 风险事件率低于阈值
多Agent协作 受限跨系统委派 治理网络与责任 身份、追踪、评测全覆盖

企业采购与架构避坑：问供应商这六个问题

  1. Agent 是否支持独立身份、细粒度权限和凭据轮换？
  2. 每次工具调用和任务委派能否完整审计？
  3. A2A 或 MCP 的兼容范围是什么，是否通过一致性测试？
  4. 更换模型、工具或编排平台时，哪些资产可以迁移？
  5. 失败后能否暂停、回滚、重放，并由人工接管？
  6. 成本是按用户、调用、Token、任务还是业务结果计算？

如果供应商只展示“Agent 能做什么”，却无法解释“出错时如何控制”，它更可能适合 Demo，而非生产。

未来趋势：从Agent应用走向Agent互联网

趋势一：协议会逐步变成基础设施，而不是卖点

当 MCP 和 A2A 被更多平台采用，支持协议本身会像支持 HTTPS 一样逐渐成为标配。厂商真正的差异将转向运行可靠性、行业知识、评测数据与治理能力。

趋势二：Agent目录与可信市场将出现

Agent 需要发现“谁能做什么”，企业也需要判断“谁值得信任”。未来可能出现带能力说明、服务等级、价格、信誉和审计证明的 Agent 目录，形成面向机器的服务市场。

趋势三：身份系统将同时管理人、机器与Agent

传统 IAM 管理员工和应用账号，下一步则要管理短期运行、动态委派任务的 Agent。权限将更细、更短暂，也更依赖任务上下文。非人身份治理会成为安全投入重点。

趋势四：多模型路由成为企业标配

规划任务使用强推理模型，分类和抽取使用小模型，敏感数据在本地处理，关键事实再交叉验证。企业不会把所有工作交给一个模型，而会根据质量、成本、速度和合规要求动态路由。

趋势五：AgentOps成为新的生产岗位与平台层

企业将需要像管理软件服务一样管理 Agent：登记、版本控制、授权、评测、监控、计费、事故响应和退役。管理者的工作，也会从分配每个步骤，转向定义目标、边界和验收标准。

结语：开放协议打开大门，可信执行决定谁能留下

A2A 与 MCP 汇入同一开放生态，是 AI Agent 产业从“单点智能”迈向“网络协作”的重要信号。它可能降低连接成本，带来跨平台组合创新，也可能让 Agent 的风险沿着开放网络扩散。

因此，企业此刻最值得做的，并不是批量采购 Agent，而是建立一套可复用的连接与治理底座：业务目标明确、数据来源可信、身份权限可控、行动过程可追踪、错误结果可撤销。

互联网的价值来自连接，Agent 互联网也一样。但连接只是第一步。未来真正有竞争力的企业，将是那些既能让 Agent 自由协作，又能让每一次行动保持在可信边界内的企业。

参考资料

编辑说明：本文以 2026 年 8 月 17 日公开报道为新闻切口，结合协议官方资料进行独立分析和重新撰写，并非对任何来源文章的翻译或转载。