2026 年 10 月的三组公开信息把「智能体怎么接系统」从项目级集成问题推成了协议层的标准问题：Linux Foundation 9 月通讯确认 Agent Router 加入 AAIF、A2A 成为托管项目；阶跃星辰发布搭载 StepAOS 1.0 的智能体手机并支持 MCP、A2A 接入；150 多款应用集体拒绝 GUI 路线。核心结论是——MCP 管纵向的工具调用，A2A 管横向的任务委派，两者分层共存而非二选一。
如果一个团队只接一个智能体、工具全在自己的代码库里，那么 MCP（A2A 之外更常见的是 Model Context Protocol，模型上下文协议）就够了，引入 A2A 是徒增复杂度。反过来，一旦你需要调用的智能体是别人家的、跑在别人的基础设施上、用别人的框架写的，A2A 就是那条边界。MCP 是纵向的，智能体向下连工具；A2A 是横向的，智能体向同行委派任务。 两者构成同一技术栈的两层，不是竞品。
2026 年 10 月中旬的三组公开信息，把这条分工从「业界共识」推成了「工程约束」。
一组来自标准侧。据 Linux Foundation 2026 年 9 月的官方通讯，Envoy AI Gateway 已于 9 月 10 日更名为 Agent Router 并作为第六个项目加入 Agentic AI Foundation（AAIF）；A2A 也已成为 AAIF 的托管项目，在供应链、金融服务与移动平台上投入生产运行，包括华为的 HarmonyOS、Google Cloud、Microsoft Azure 与 AWS Bedrock。同一份通讯提到，MCP 工具调用量在这个夏天出现跃升——来自 ChatGPT 用户的调用到 8 月已达到 1 月的 98 倍，Resend 的月工具调用量突破一百万。
第二组来自产品侧。据人民网上海 10 月 15 日电，阶跃星辰于 10 月 13 日发布首款智能体手机 STEPX Neo，搭载自研智能体原生操作系统 StepAOS 1.0 与个人智能体「阶跃 Amoo」，全栈售价 3999 元，已获入网许可。据网易财经同日报道，该机型的基础设施之一正是 StepStudio 开发工具对 MCP、A2A 协议的支持。
第三组来自生态博弈。据中国青年报 2026 年 10 月 15 日报道，150 多款应用集体拒绝「豆包手机」的 GUI 路线，转而要求智能体按协议接入。同篇报道引述阶跃星辰董事长印奇的表述，认为 MCP 是智能体连接应用的最佳方式，但未来将与 A2A 等路径融合；据该文报道，阶跃智能体手机基本放弃 GUI 模拟操作，按合作方要求以 MCP、A2A 等协议逐一接入应用，而整体合作推进速度并不算快。
这三组信息共同说明一件事：「智能体怎么接系统」正在从项目级集成问题，变成协议层的标准问题。 而协议层的问题不能靠「多写点适配代码」解决——那正是过去十年 API 碎片化消耗掉的成本。本文按定位、机制、治理、落地四层拆解 MCP 与 A2A，给出选型判断、五步落地顺序，以及一份在自建 MCP 服务时可以直接对照检查的清单。
先划清与已有内容的边界：本文讲的是连接层的标准与选型；API 网关在微服务架构中的角色与边界讲的是传统 HTTP 流量在服务间怎么走；AI Agent 运行时隔离怎么做讲的是执行侧的四道边界与权限最小化；AI Agent 提示词注入怎么防讲的是输入侧的攻击面。本文的协议选型是这四者共同依赖的地基：网关决定流量怎么汇，隔离决定智能体做不成什么，注入防护决定输入可信度，而协议决定前两者作用在哪一层、作用到什么范围。
---
结论先说：MCP 是智能体与外部工具、数据源、服务之间的标准接口，解决的是调用问题。
据 Anthropic 官方文档，MCP 最初于 2024 年 11 月发布，定义了三个核心原语：tools（由模型控制的动作）、resources（由应用控制的数据，如文件与 JSON）、prompts（由用户控制的结构化模板）。传输方式上，本地进程用 stdio，远程服务用 Streamable HTTP。
治理侧的变化更值得关注。据 agentsurface.dev 在 2026 年 9 月 25 日核对的资料，MCP 的中立治理已归属 Linux Foundation 旗下成立于 2025 年 12 月 9 日的 Agentic AI Foundation，MCP 与 goose、AGENTS.md 同为该基金会的锚定项目。AAIF 有多个成员组织，赛迪网在报道中提到其成员规模已达 260 余家，并提到华为向 MCP 贡献代码、中国移动在电信生产环境规模化落地、阿里巴巴作为黄金成员贡献 Open Sandbox 项目。
需要说明的是，这类成员数量与厂商贡献的统计在不同来源中口径不一（有来源记为 146 家、亦有记为 250 家以上），本文按赛迪网的报道表述其量级，不做精确断言。可以确定的是：MCP 已经从一家公司的协议变成了多方共建的公共基础设施。
MCP 的定位可以这样记：它把「1 对 1 谈」变成「1 对多接」。系统按标准把业务动作封装成工具，谁来连、连几家，都不需要再改系统本身——据《财联社》等媒体在报道 AI 接入企业业务系统时的描述，这一层的接口主动权由此从集成商手里回到了系统自己手里。这对企业意味着什么，可以参照企业后台权限模型设计里的思路：工具的暴露面一旦标准化，就应当用权限模型而不是项目约定来管理。
结论先说：A2A 是智能体与智能体之间的标准协议，解决的是发现、委派与结果回收问题。
据 agentsurface.dev 的协议档案，A2A 由 Google 于 2025 年 4 月发布，2025 年 6 月 23 日捐赠给 Linux Foundation，并于 2026 年 8 月 27 日作为 Growth Stage 项目被 AAIF 接受。规范版本方面，v1.0.0 发布于 2026 年 3 月 12 日，v1.0.1 为 2026 年 5 月 28 日的缺陷修复版本，官方描述为生产可用级别，具备 150 余家参与组织、五种语言的 SDK 与一个八状态的任务生命周期。
A2A 的核心对象是五个：Agent Card、Task、Message、Part、Artifact。其中 Agent Card 是一份发布在约定路径上的 JSON 文档，用于声明身份、公开密钥与能力——据该协议文档，规范注册的规范位置是 /.well-known/agent-card.json，为兼容 1.0 之前的服务器，也接受 .well-known/agent.json 作为回退。
有一个细节值得企业注意：Agent Card 是免认证提供的，因为客户端必须先读到卡片才知道该如何认证。这意味着卡片本身是一个必须在被发现阶段就假定不可信的攻击面，后文第五节会具体展开。
A2A 采用「不透明执行」原则：协作双方基于声明的能力与交换的信息协作，无需共享内部的思考过程、计划或工具实现。这一点在企业多团队环境下价值很高——一个用 LangChain 搭、一个用 CrewAI 搭、一个用自研框架的智能体，可以互相协作而不必打通内部实现。
「MCP 和 A2A 是不是要二选一」这个问题在线上讨论中出现频率极高。结论是不选：把 MCP 当成 A2A 的替代品，或反过来，都是把两个不同维度的问题放错了位置。
据 2026 年的一篇系统性综述给出的界定：MCP 是「工具连接的 USB-C」（纵向，智能体到工具），A2A 是「智能体协作的 HTTP」（横向，智能体到智能体）。生产系统通常同时使用两者——A2A 把任务路由到正确的专业智能体，MCP 为该智能体提供上下文与工具。
这条分工可以直接对应到工程决策上：
| 判断维度 | MCP | A2A |
|---|---|---|
| 解决的问题 | 智能体如何调用工具或数据源 | 智能体如何把任务委派给另一个智能体 |
| 方向 | 纵向：智能体向下的能力调用 | 横向：智能体之间的对等协作 |
| 不透明的是谁 | 工具是无状态的，推理全在智能体侧 | 双方都是完整智能体，互相看不到内部 |
| 发现方式 | 工具清单：有哪些函数、参数是什么结构 | Agent Card：签名声明身份、技能与可达端点 |
| 生命周期 | 调用、读取、订阅，请求—响应式 | 提交任务、跟踪状态、流式更新、取消、收集产物 |
| 认证模型 | 客户端认证到它选择的服务器 | 每张卡片自声明认证方案，因调用方未选择对端 |
| 失败形态 | 工具报错，智能体重试或绕行 | 对端中途失联、任务长期挂起 |
对大多数企业来说，这张表的用途不是让你选一个，而是让你在架构评审时能准确地说出「这一段为什么用 A2A 而不是让对方调我们的 REST 接口」。这正是 A2A 相对传统集成方式的核心差别：传统做法下，一次伙伴集成往往等于一个 REST 端点加一份文档，两者会在任一方变更后立刻漂移；A2A 用机器可读的卡片替代了那份文档。
---
结论先说：MCP 在 2026 年 7 月 28 日发布了自诞生以来最大的一次修订，核心是从有状态转向无状态。
据 Flavio Copes 与 agentsurface.dev 的梳理，这次修订移除了 Streamable HTTP 上的协议级会话与 Mcp-Session-Id 头，移除了 initialize / notifications/initialized 握手；原先由服务端发起的 roots/list、sampling/createMessage、elicitation/create 改为多轮往返请求；HTTP GET 端点与 resources/subscribe 合并为单一订阅流。同时加入了正式扩展框架、OAuth 2.0 / OIDC 加固、12 个月最短窗口的弃用生命周期、JSON Schema 2020-12 工具 schema 与 W3C Trace Context。Roots、Sampling、Logging 及旧的 HTTP+SSE 传输被标记弃用，但仍可用。
这组变更对企业的实际影响有两条，都很直接。
第一，部署形态变了。 据 DevToolHub 的分析，粘性会话路由的要求被彻底消除，一个无状态的 MCP 服务放在普通负载均衡后面，从「特殊情况」变成了「常规部署」。据 Linux Foundation 9 月通讯，MCP 调用量的跃升在时间上与这次修订吻合——原因正是无状态让服务端可以随需求增长加机器，Resend 也表示其远程 MCP 服务无需改动即已支持新规范。
第二，认证从可选变成了硬要求。 这是最容易被低估的一点。Curity 在其技术分析中指出：没有会话之后，服务器识别调用方只能依靠 OAuth 访问令牌，因此 MCP 授权对任何服务真实用户的远程服务器都变成了必需品。DevToolHub 的梳理更直接——MCP 服务器现在就是 OAuth 2.1 资源服务器。配套要求包括：必须暴露 Protected Resource Metadata 端点（RFC 9728）或在 WWW-Authenticate 头中携带 resource_metadata；客户端请求令牌时必须指明目标 MCP 服务器（Resource Indicators，RFC 8707），否则为 A 服务器签发的令牌可能被重放到B 服务器；授权服务器应包含 iss 参数且客户端必须校验。同时，Dynamic Client Registration 被弃用，转向 Client ID Metadata Documents。
一个真实的教训在这里：据 DevToolHub 的文章回溯，安全公司 OX Security 的研究人员此前披露过 MCP SDK 的 STDIO 传输存在设计缺陷，可在 7000 余个公开服务器上触发任意命令执行。那是另一个传输层的另一个缺陷，7 月的修订并未修补它——它修的是另一个层面的缺口：一种标准化的方式，让服务器确认令牌属于自己，而不是回调给了别人。这两件事的性质差别值得记住：协议修订解决的是标准化问题，不是全部实现缺陷。
结论先说：A2A 刻意保持有状态的任务模型，因为工具调用本身无法表达「暂停、等待补充输入、然后继续」。
A2A 的任务状态机是它与 MCP 最本质的差异之一。farasat.me 在 2026 年 10 月 5 日核对的规格要点中提到，任务可以停在 input-required 或 auth-required 这类状态上，而一次普通的工具调用无法表达这些情况。
按照 agentsurface.dev 与 matthewswong.com 整理的操作清单，A2A v1.0 定义了十一个操作：发送消息、发送消息并流式更新、读取任务、列出任务、取消任务、重新订阅运行中的任务、创建任务的 webhook 配置、读取/列出/删除 webhook 配置，以及获取经过认证的扩展卡片。同一批操作在 JSON-RPC、gRPC 与 HTTP+JSON 三种绑定下的方法名一致。协议还要求请求携带 A2A-Version 头——这里有个容易踩的坑：规范规定空的版本值会被解释为 0.3，因此忘记带这个头的客户端会与仍同时支持新旧版本的服务端静默协商到旧协议。
对工程团队的含义是：A2A 的适配成本高于 MCP，但换来的是跨长时程任务的可控性。如果你的场景是「一次调用、一次返回」，用 A2A 是浪费；如果你的场景是「转交一件需要对方追问、需要等待数小时、需要中途取消的任务」，那么 A2A 的状态机是唯一合适的选择，REST 轮询方案会在异常处理上留下大量自定义代码。
结论先说：智能体要代替人付款时，A2A 的任务模型需要一个签名授权层，这就是 AP2 的位置。
据 reactify-solutions 的梳理，AP2 于 2025 年 9 月发布时有 60 余家发布伙伴，其模型建立在三种签名的 Mandate 之上：Intent Mandate 记录用户想要什么、预算多少；Cart Mandate 记录智能体实际选了什么；Payment Mandate 由商户或网络会签。据同源梳理，截至 2026 年 4 月有三个公开的 AP2 生产部署：PayPal 与 Google Cloud Conversational Commerce Agent 的集成、Mastercard Agent Pay 在 PayPal 内运行的试点，以及用于稳定币支付的 A2A x402 扩展。
对企业的现实意义是：当智能体开始涉及资金，协议的边界就不再只是「能不能调通」，而是「授权链条上有没有可审计的签名记录」。这与医疗信息化的数据隐私与操作留痕中讲的留痕逻辑同源——差别只在于 AI 场景里，授权链条的起点不是人的点击，而是一份必须防篡改的意图声明。
---
结论先说：跨智能体的提示注入会传递，而 A2A 规范不提供任何协议级防护。
据 grith.ai 汇总 Red Hat、Palo Alto Networks Unit 42、Semgrep、Trustwave SpiderLabs 与 Solo.io 等多方安全分析的内容，A2A v1.0 在提示注入防御上的结论是零。具体缺口包括：规范对「跨智能体提示注入」这一威胁不提供任何控制手段；Unit 42 已构建出可用的概念验证；Agent Card 签名在规范中表述为「可」数字签名而非「必须」；不存在协议级的工具调用评估闸；任务状态中没有「需用户同意」这一状态，学术论文曾提议补充但未进入规范；授权机制完全由实现方定义；令牌生命周期未被强制。
同一份梳理还指出一处结构性矛盾：A2A 的「不透明执行」原则意味着调用方在协议层面看不到对端调用了哪些工具、读了哪些文件、产生了什么副作用。这在设计上是特性，但从安全角度看是缺口——调用方无法评估它委派出去的那个智能体的行为。
这需要与AI Agent 提示词注入怎么防里讲的六道防线对照阅读：那一篇的核心论点是「指令与数据同构」使输入过滤无法根治，防线必须做在模型之外。A2A 把这个问题从单智能体放大到了生态：据 arnav.au 的分析，投毒内容可以经由互联的智能体工作流传播，一个智能体吸收的恶意指令会扩散给它下游协作的智能体；Cisco 已记录通过实时 Server-Sent Events 流投递的间接提示注入——隐藏指令藏在流式更新里，在任务执行中途劫持行为。
这不是 A2A 独有的问题，MCP 也有类似教训。真正的结论是两层：协议层负责身份与传输的完整性，注入防护必须做在主机层与工作流层。
结论先说：Agent Card 是明文 JSON、通过 HTTP GET 获取、在 0.3 及之后版本中「支持但不强制」签名——这三条合起来构成一个低成本的注入通道。
据腾讯云开发者社区转述的一篇分析文章，2026 年 6 月发表在 IEEE 的研究首次系统性测量了「Agent Card 投毒」攻击。攻击方式很直接：攻击者在 Agent Card 的 url 字段填入自己控制的端点，编排智能体在发现阶段解析卡片后，会忠实地把后续任务路由到攻击者的服务器。
该研究测试了三种攻击层级——朴素文本覆写、结构化 JSON 嵌入与自然语言社会工程攻击——据文章转述，在无防护的编排智能体上三种攻击全部成功。正则清洗能拦住语法显式的尝试，但被自然语言社会工程攻击全部绕过；以 LLM 为基础的卡片审计在试点中拦截了全部 9 次攻击尝试、100 次良性测试零误报，但研究明确标注这是试点规模（每层级每组合 n=3），需要更大规模验证。
这篇分析指出的结构性问题值得完整复述：A2A 的发现层假设 Agent Card 可信，但协议本身不提供任何密码学验证机制。在只涉及同一组织内部智能体的场景里，这个问题可能被网络边界防护掩盖；而 A2A 的整个价值主张恰恰是跨组织边界协作——当编排智能体需要调用另一家公司的专业智能体时，它凭什么信任那张卡片上写的地址？
同源的 arnav.au 分析补充了另外两类：Keysight 研究人员记录的 Agent Card 投毒（元数据中嵌入对抗指令，把发现产物变成注入载体），以及 Palo Alto Networks 研究人员展示的被攻陷服务器发布伪造的端点与文档地址，把合法客户端智能体重定向到恶意端点。它还给出了一条实操建议：A2A 0.3 及之后支持卡片签名但不强制，因此在生产部署中的加固做法是在客户端强制校验——拒绝把任务委派给任何卡片签名并非来自可信签发方的智能体。
针对 FreeBuf 梳理的检测规则，落地时的可观测项包括：业务时间之外的 A2A 智能体注册、非白名单 IP 的注册、重复的能力注册、来自未授权来源的 DNS 响应、A2A 主机名的异常 DNS 查询量，以及 A2A 智能体的 TLS 证书指纹变化。最后一项尤其值得纳入日常巡检——它是发现身份劫持最直接的信号。
结论先说：MCP 把鉴权写进了规范，A2A 把授权留给了实现方——这个不对称是当前最容易被低估的架构风险。
据 arnav.au 的分析，A2A 支持强认证方案但不强制任何一种，且完全没有定义授权框架。规范本身承认授权逻辑——哪个智能体可以访问哪些技能、触发哪些动作——是各实现方的责任。企业指南要求智能体在敏感动作前执行授权检查，但未规定机制。这带来三类可预期的失效模式：仅依赖上游校验形成的信任漏洞；能力膨胀，即智能体被授予超出预期范围的文件或网络权限（Cisco 的 A2A 威胁工作中记录了这一点）；以及多租户系统中的跨边界升级，当令牌未绑定租户上下文时，一个租户中被攻陷的智能体可以调用另一个租户的特权服务。
MCP 侧的情况在改善但也有代价。据 Curity 的分析，无状态化之后访问令牌承载了服务器所需的全部状态信息，且令牌可以被交换——处理请求的任一组件都可以用标准令牌交换（RFC 8693）换出一个短时、最小权限、被锁定的令牌。这意味着 OAuth 授权从一项附加功能变成了基础设施。如果你在 7 月 28 日规范发布后仍在运行无认证的远程 MCP 服务器，那么它现在的状态已不符合规范要求。
可行的做法是：把 OAuth 授权的服务端令牌交换与最小权限限定，参照大模型私有化部署的决策要点中关于数据边界的判断标准来做取舍——哪些 MCP 服务可以走公网、哪些必须留在内网或经内网代理转发，是同一个决策的两种问法。
结论先说：模型与工具的流量汇聚正在形成一个独立的基础设施层，Agent Router 是目前公开可查的代表。
据 AAIF 官方博客，Envoy AI Gateway 已更名为 Agent Router 并加入 AAIF。该项目由 Bloomberg 与 Tetrate 在 2024 年 10 月起步，解决的是一个被官方明确称为「流量问题」而非「模型问题」的困境——每家供应商暴露不同 API，每个使用模型或构建智能体的团队都需要理解这些差异、管理供应商凭证，并在接入每一家新供应商时重建部分集成。Agent Router 的做法是给开发者一个 OpenAI 兼容的稳定接口以访问模型，并提供一个用于所有 MCP 工具的路由器；平台团队则一次性描述供应商、凭证、配额与工具，由它把这份意图转成配置。
据官方博客与 Tetrate 的说明，该项目在 2026 年 6 月发布 1.0 并对 1.x 系列作出兼容性承诺，8 月发布 1.1；现有十一家公开采用方，包括 Bloomberg、Tetrate、腾讯云、Nutanix、LY Corporation 等；九个维护者席位由 Bloomberg、Nutanix、AMD、Tetrate 与 Netflix 共同分享，没有任何一家公司占多数，另有来自 21 个组织的 132 名贡献者。
对企业的参考价值在两点：一是选型时可以把它当作一种「解耦模型供应商」的可选项，据其文档它可连接 OpenAI、Anthropic、Amazon Bedrock、Google Gemini、Microsoft Azure 等多家服务，换模型时不必改代码；二是它把「MCP 工具访问控制」显式列为平台职责，Tetrate 的说明提到每个 MCP profile 只暴露经批准的工具，网关为每次调用附加用户身份与审计记录。这恰好回答了审计方最常问的那个问题：哪个智能体、以谁的身份、调用了哪些工具。
若需要把这条链路的成本与效果纳入评估，大模型调用成本怎么控制一文讨论的任务分类与模型路由方法可以与本文的协议选型合并使用——成本控制的入口往往就是选型阶段定的。
---
结论先说：满足全部五项，才值得为跨智能体协作付 A2A 的复杂度成本。
按 farasat.me 在 2026 年 10 月 5 日给出的实务判断，其核心立场是：所有智能体都在自己代码库里的团队不需要 A2A，需要调用别人拥有并运行的智能体的那天，才是建立这条边界的时机。本文把这一判断展开为五个可操作的问题：
综合前述机制与治理事实，建议按以下顺序推进，每一步都有可以立刻验证的产出。
第一步：盘点现有接口，确定哪些值得封装为 MCP。 优先挑读取类、查询类、可逆且低风险的动作。据第三方技术分析团队的观察，企业新系统应按 MCP 友好设计——提供清晰的接口定义、细粒度的权限模型与可观测的调用日志。这一步的产出是一份工具清单，与需求诊断清单里「数据来源」「权限结构」两项的追问逻辑一致。
第二步：按 2026-07-28 规范重建远程 MCP 服务，并补齐 OAuth 2.1。 这一步不能跳。无状态化之后没有会话可依赖，必须实现 Protected Resource Metadata 端点、启用 Resource Indicators 限定令牌受众、校验 iss，并把 Dynamic Client Registration 换成 Client ID Metadata Documents。Tier 1 SDK（TypeScript、Python、Go、C#）都已支持新核心，Rust 支持处于 beta；官方建议直接按新规范构建新服务，仅在确有受支持的旧客户端时才加兼容层。
第三步：把工具访问收口到一层可控的路由上，并开启强制签名校验。 这既是审计要求，也是安全要求。这一步同时产出了成本数据——每次调用的模型、工具、耗时、令牌消耗都可归集，为后续的成本治理提供基线。
第四步：只在出现跨边界需求时引入 A2A，并先做内部场景。 据 reactify-solutions 对生产部署的观察，企业的落地节奏是内部优先、外部待身份体系成熟后推进；SAP 对外部 A2A 调用方设置了更紧的访问控制，也印证了这一节奏。任务模型要按八状态完整实现，版本头不要漏。
第五步：把不信任假设写进集成层，而不是依赖协议自觉。 具体包括：把远端智能体的输出当作不可信输入处理；卡片域名使用白名单；凭证按最小作用域签发；保留任务 ID 的完整审计链路；在涉及敏感数据或资金的动作上设置人工确认。
这五步的排序原则是：先把纵向打通并治理干净，再考虑横向互联。反过来做——先建 A2A 网络再补 MCP 认证——等于在未加固的地基上盖二层。
可直接对照检查，共十二项：
/.well-known/oauth-protected-resource 端点？iss 参数？---
据网易财经与人民网上海的报道，STEPX Neo 的设计逻辑是把「软硬模」三位一体体系落到实处：硬件负责感知与表达，模型负责理解与决策，软件负责调度与执行。其中软件层 StepAOS 1.0 从零打造，把长期记忆、任务调度与安全机制纳入底层；模型采用端云协同架构，简单指令交由端侧模型快速处理且部分支持离线运行，复杂需求由云端模型拆解规划后再下发端侧执行。
据中国青年报 10 月 15 日的报道，该机型基本放弃 GUI 模拟操作，按合作方要求以 MCP、A2A 等协议逐一接入应用，而合作推进速度并不算快。这一事实对协议落地的判断很有价值：协议标准化降低的是长期集成成本，没有解决「商业上谁先开放」这个前置问题。企业在评估协议路线时，应当把它当作技术选型而非商务捷径。
同篇报道还给出了一组关于 GUI 路线的信息：150 多款应用集体拒绝豆包手机的 GUI 路线。报道同时指出三条备选路径各有短板——MCP 需要每个应用专门开发统一接口、开放多少权限需逐一商量；A2A 在企业内部工作流落地较快，但不适合大规模复杂场景的消费端日常服务；CLI 权限极大但手机应用几乎不提供命令行入口。这段分析给出了一条通用教训：没有哪条协议能单独覆盖全部场景，选型本质上是在承认取舍。
据信网 2026 年 9 月 17 日报道，在 2026 OPPO 开发者大会期间，曹操出行宣布 AI 打车服务正式接入 OPPO 内测的下一代端侧智能体「小布 Next」。报道称，曹操出行升级了 caocao-mcp，即智能体调用其服务的统一标准协议，成为小布 Next 内首个支持 UI 交互的 AI 出行服务。
这个案例中有一个设计值得单独记下：caocao-mcp 采用三层递进交互机制——不具备渲染能力的智能体获得结构完整的可读文本；具备网页加载能力的智能体得到即时可用的交互页面；具备 UI 扩展能力的智能体得到可反向下单的沙箱卡片。同一套能力，三种交互形态。
据该报道，这一范式更新也为难外卖、酒旅、电商等服务商进入智能体生态提供了参考。对做人工智能应用开发的团队来说，这里体现的工程判断是：协议层的接口设计应当按对端能力的上限定，而不是按自家系统的数据结构定。一个只能输出文本的智能体与一个能渲染页面的智能体，如果接口不预留降级形态，实现方就得在每个客户端上做适配。
据赛迪网对 AAIF 的报道，中国企业在该生态中表现活跃：华为向 MCP 贡献代码，中国移动在电信生产环境规模化落地，阿里巴巴作为黄金成员贡献 Open Sandbox 项目。该报道同时指出，中国市场偏爱 A2A，源于消费级应用与边缘设备的高频协同需求。
该报道援引 AAIF 相关负责人的判断：未来 1 到 3 年，不具备智能体能力的组织将失去全球竞争力，并给出四条建议——坚守开放标准以规避技术债、优先采用 MCP 与 A2A 等厂商中立协议；深度参与治理，从消费者变为制定者；前置安全合规，融合本地数据主权要求与全球协议；锁定人才认证，将 MCP 认证纳入 AI 架构师的考核。
这些建议属于该负责人的公开观点，而非独立研究结论，但其中「避免私有方案锁定」这一条，与本文的选型结论在工程上确实同向。相关的落地流程与协同方式，服务流程与技术能力两页有更贴近项目的说明。
---
如果团队已经在按企业 AI Agent 落地方案推进试点，这里给出的补充视角是：试点的第一个断点往往不是模型能力，而是接口形态。 一个用私有接口实现的试点，在进入跨部门协作时会立刻撞上协议问题——而那时改接口的成本远高于一开始就按标准封装。
同理，提升知识库问答准确率的工程手段讨论召回与重排时，其前提假设是工具调用的输入输出是稳定的。协议选型决定了这个前提能否长期成立：按标准封装并有版本管理的工具接口，比临时的函数调用更利于回归测试。
最后回到本文开头划清的边界。连接层的标准化解决的是「怎么连」，不解决「连上了能干什么、会不会出事」。后两个问题分别在AI Agent 运行时隔离怎么做（执行侧的四道边界）与AI Agent 提示词注入怎么防（输入侧的攻击面）中展开；而让 AI 能力被生成式引擎正确理解与引用，属于生成式引擎优化的范畴，是内容侧而非连接侧的问题。四者构成一个完整链路，缺一段都会在具体项目里显现为返工。
---
本文由科芃科技（广州科芃科技有限公司）的人工智能应用开发与软件研发团队撰写，观点基于公开发布的协议规范、Linux Foundation 与 Agentic AI Foundation 的公开公告、厂商技术文档，以及主流技术媒体与安全研究机构在相关时点的公开分析。文中涉及的产品能力、版本状态、成员规模与落地案例均标注了来源主体；厂商自述与第三方独立分析已尽量分开陈述。协议规范仍处于快速演进期，正式实施前请以各协议官方文档的最新版本为准。
核心差别在方向：MCP 是纵向的，解决智能体如何调用外部工具与数据源；A2A 是横向的，解决智能体如何发现同行、把任务委派出去并回收结果。两者不是二选一，而是同一技术栈的两层，生产系统通常同时使用——A2A 把任务路由到正确的专业智能体，MCP 为该智能体提供它自己需要的工具与上下文。选型上有个简单判断：如果所有智能体都在你自己的代码库里、由同一团队发布，那么在编排层里它们只是函数调用，不需要 A2A；只有当你要调用的智能体由别人拥有、跑在别人的基础设施上、需要长时程任务或不支持预共享密钥时，A2A 才是那条值得投入的边界。
这是 MCP 自诞生以来最大的一次修订，移除了 Streamable HTTP 上的协议级会话与 Mcp-Session-Id 头，也移除了 initialize 握手。两方面影响最直接：一是部署简化，粘性会话路由不再需要，无状态 MCP 服务放在普通负载均衡后成为常规部署；二是认证变成硬要求——没有会话后服务器只能靠 OAuth 访问令牌识别调用方，MCP 服务器现在就是 OAuth 2.1 资源服务器，必须暴露 Protected Resource Metadata 端点（RFC 9728）、在请求令牌时用 Resource Indicators（RFC 8707）限定令牌受众、校验 iss 参数，并把动态客户端注册换成 Client ID Metadata Documents。官方建议直接按新规范构建新服务，仅在确有受支持的旧客户端时才加兼容层，Roots、Sampling、Logging 与旧的 HTTP+SSE 传输有至少 12 个月的弃用窗口。
Agent Card 是 A2A 协议里用于发现与信任的机器可读声明，发布在 /.well-known/agent-card.json，包含身份、公开密钥与能力列表，它的设计作用相当于让智能体像微服务一样可被自动发现。薄弱之处在于三条事实叠加：卡片是明文 JSON、通过 HTTP GET 获取、在 0.3 及之后版本中「支持但不强制」签名。2026 年 6 月发表在 IEEE 的研究首次系统性测量了 Agent Card 投毒攻击，攻击者只需在 url 字段填入自己控制的端点，编排智能体解析卡片后就会把任务路由过去；测试的三种攻击层级在无防护的编排智能体上全部成功。加固做法是在客户端强制校验卡片签名，拒绝把任务委派给签名并非来自可信签发方的智能体，并把 TLS 证书指纹变化纳入日常巡检告警。
因为标准给你的是机制，不是安全结论。A2A v1.0 在提示注入防御上的结论是零：规范不提供任何协议级的跨智能体注入控制手段，没有协议级的工具调用评估闸，任务状态里没有「需用户同意」这一状态，授权机制完全由实现方定义，令牌生命周期也未被强制。多方安全分析还指出，「不透明执行」原则意味着调用方在协议层面看不到对端调用了哪些工具、产生了什么副作用。授权上的空缺还会带来三类可预期的失效模式：仅依赖上游校验形成的信任漏洞、能力膨胀，以及多租户系统中令牌未绑定租户上下文时的跨边界升级。务实的做法是：把远端智能体输出当作不可信输入、卡片域名白名单、凭证按最小作用域签发、保留任务 ID 审计链路、涉及资金或敏感数据的动作设人工确认。
先盘点现有接口，确定哪些值得封装为 MCP，优先挑读取类、查询类、可逆且低风险的动作。给系统做 MCP 友好设计的要点是提供清晰的接口定义、细粒度的权限模型和可观测的调用日志，让未来的智能体能以标准方式接入而不形成新的信息孤岛。这个顺序之所以重要，是因为接口标准化的收益在跨部门协作时才兑现，而改动成本随时间单调上升——先用私有接口实现的试点，在需要对接外部系统时改造成本远高于一开始就按标准封装。同时要同步建立管理规范，包括 MCP 服务的命名规则、版本控制、权限范围与数据访问边界。试点阶段建议先从低风险场景切入，验证实际效果后再逐步扩展到核心业务流程。
可以先不做的条件很明确：如果智能体全在你自己代码库里、任务都是一次调用一次返回、双方已共享密钥、或你的治理要求必须逐步审查对端行为，那么 A2A 带来的只是复杂度——最后一条尤其关键，A2A 的「不透明执行」原则与强审查要求本身是冲突的。值得引入的条件包括：需要对端由另一家公司拥有并运营、不允许预共享密钥、任务需要持续数小时且中途可能需要对方追问补充输入、需要支持取消与状态跟踪。自托管平台的务实做法是现在就跟踪规范但不交付端点，只有当某个工作流真正出现两个独立智能体时才建设；企业的落地节奏通常是内部优先、外部等身份体系成熟后再推进。