智能体互联协议 AIP 1.0 提速：国标给智能体补的六课，MCP 与 A2A 都解决不了

8 月 6 日，智能体互联协议 AIP 1.0 的落地节奏明显加快：首批兼容实现正式对外亮相，跨厂商的互操作测试也同步启动。这意味着国内以国家标准方式推进的智能体互联，已经从纸面规范走进了真实可运行的代码，不再是停留在白皮书和新闻稿里的愿景描述。

AIP 的全称是 Agent Interconnection Protocol，中文叫智能体互联协议。它由全国信息技术标准化技术委员会牵头推进，定位是面向海量 AI 智能体互联的多中心化通信协议，直接回答的是智能体与智能体之间怎么互相发现、怎么互相信任、怎么协同完成一件真实任务这一类最基础的问题。

这件事的分量，要从两个时间点看。第一个是 5 月 8 日，国家网信办、国家发展改革委、工业和信息化部三部门联合发布《智能体规范应用与创新发展实施意见》，明确提出在 19 个典型应用场景积极稳妥推动智能体应用，并把 AIP 列为智能体互联的关键国家标准来推广应用。

第二个时间点是 5 月 12 日，全国信标委人工智能分委会面向全社会启动 AIP 应用验证先锋计划，公开征集互联网企业、央国企、科创企业、高校科研机构、独立开发者和技术团队参与实测适配。到 8 月，首批兼容实现与互操作测试启动，等于把先锋计划的征集成果落到了可以运行的代码上。

过去两年，智能体之间的连接已经有两套主流协议在跑，AIP 为什么还要另起炉灶？要回答这个问题，得先看清楚 MCP 和 A2A 各自管的是哪一段，以及这两套协议之间，究竟留下了什么样的空档一直没有被填上，这决定了 AIP 存在的必要性。

MCP，也就是 Model Context Protocol，解决的是智能体与外部工具之间的连接问题。一个智能体想查数据库、发邮件、调用支付接口，都可以通过 MCP 服务器暴露成标准工具，一次接入、到处运行，这是工具接入层的统一，也是目前生态最成熟、应用最广泛的一层协议。

A2A，也就是 Agent2Agent Protocol，解决的是智能体与智能体之间的协作问题。它定义了能力卡、任务、消息这些核心概念，让不同厂商的智能体能互相发现、互相派活、汇报进度，这是交互层的统一，由谷歌在 2025 年发起并持续演进，已经有超过一百五十家组织加入。

两套协议拼起来，覆盖了工具接入和智能体协作，看起来已经够用。但真实世界里，智能体互联缺的不是通信管道，而是治理底座：调用一个陌生智能体之前，怎么确认它的身份是真实的，协作出了问题该找谁负责，服务要收费又该怎么结算对账，这些全都没有着落。

AIP 补的正是这一段。它的设计目标非常明确：补齐 MCP 与 A2A 协议的短板，解决可信接入、身份认证、能力发现、互联协作、结算交易、行为审计这六个核心问题，把智能体互联从「能连上」推进到「敢连、可管、能追责」的完整状态。

第一课，可信接入。目前的智能体互联里，绝大多数接入都是「先连上再说」：拿到一个地址、一组参数，就直接发起调用，调用方对服务方的真实身份几乎没有验证手段，被冒名顶替、被恶意节点钓鱼，都是真实存在的风险，而这些风险最终都会落在用户的业务上。

AIP 把可信接入放在了协议的第一位，要求接入方和服务方在建立连接之前，先完成身份与权限的校验，而不是把校验责任留给每个应用自己去实现。这一层一旦成为标准，智能体互联的安全基线就从「各自为战」变成了「协议兜底」，安全水位整体被抬高了一个台阶。

第二课，身份认证。智能体不是人，没有身份证，也没有统一的组织归属，一个智能体到底是哪家公司运营的、运行在谁的服务器上、由谁对它的行为负责，在现有的两套协议里都找不到答案，出事了连追责对象都定位不到。

AIP 给出的方案是为智能体建立标准化的身份体系，让每一个参与互联的智能体都拥有可验证的身份标识，身份信息可以被对方校验、被监管方核验。这相当于给智能体发了一张「身份证」，把「你是谁、谁为你负责」变成了协议层面的强制要求，而不是可选的加分项。

第三课，能力发现。A2A 有能力卡，MCP 有工具清单，但两者描述的都是「能做什么」的功能层面，缺少对服务质量的描述：这个智能体响应快不快、可用率多高、收费怎么算，调用方在接入前基本无从判断，只能靠一次次试错来摸清底细。

AIP 把能力发现扩展成了包含身份、能力、质量、计费在内的完整声明体系，调用方可以在建立协作之前，先读取服务方的能力声明，再决定要不要接入、用哪种方式接入，把「先试后信」变成「先看清再连」，决策成本大幅下降。

第四课，互联协作。真实场景里的智能体协作往往是跨厂商、跨平台的：一个调度智能体要把任务分给不同公司提供的执行智能体，还要协调它们之间的依赖关系，纯靠点对点的临时对接，每次合作都要重写一遍集成代码，成本高且不可复用。

AIP 的多中心化设计，让任意两个智能体之间都能遵循同一套协议完成协作，不依赖某个中心平台的撮合，也不要求所有参与方都接入同一个生态。多中心化意味着可以存在多个认证中心、多个服务目录，它们之间互相承认、共同组网，生态不系于一家之手。

第五课，结算交易。当智能体开始替人完成真实任务，服务收费就不可避免：执行智能体提供了服务，调度智能体应该按约定付费，而现在的协议层完全没有交易语义，钱的问题全部被推到了业务层手工解决，效率低且纠纷不断。

AIP 把结算交易纳入协议设计，让智能体之间的服务调用可以携带计价与结算信息，谁用了谁的服务、按什么标准计价、费用如何清算，都有标准化的表达方式，为智能体经济打下协议层的地基，也让按次付费、按量计费成为可能。

第六课，行为审计。智能体是自主行动的，一个任务链路可能横跨十几个智能体，一旦某个环节出错，要还原「到底是谁、在什么时候、做了哪个决定」几乎不可能，因为每一步调用都没有留下可统一核验的记录，追责无从谈起。

AIP 要求互联过程的行为全程可审计，关键动作记录可查询、可追溯，出了问题可以沿着审计链路定位到具体节点。对金融、政务这类强监管场景来说，这一条比任何功能特性都更重要，没有审计能力，就没有进入这些行业的资格。

把六课放在一起看，AIP 的核心思路就很清楚了：MCP 管工具怎么接，A2A 管任务怎么派，AIP 管的是这些动作发生之前和之后的事，也就是身份、信任、结算与追责，恰好补上了现有协议栈里最薄弱的治理层，让互联从技术动作升级为可信行为。

为了看得更清楚，把三套协议放在同一张表里对比。MCP 面向智能体与工具，解决的是工具接入，核心机制是工具列表与调用，身份认证与结算都不在协议范围内；A2A 面向智能体之间，解决的是任务协作，核心机制是能力卡与任务消息，同样缺少身份认证与行为审计这两项关键能力。

AIP 面向海量智能体组网，解决的是可信互联，核心机制是身份认证、能力发现、结算与审计，覆盖的维度最全。三者不是替代关系，而是分层互补：MCP 管工具、A2A 管协作、AIP 管治理，未来的智能体技术栈大概率是三层同时存在、各司其职。

表格里最扎眼的差异在最后三行：MCP 和 A2A 把身份、结算、审计全部排除在协议范围之外，而 AIP 把这三项做成了协议内置能力。这不是设计上的巧合，而是定位决定的：前两者解决「能不能连」，AIP 解决「连了之后敢不敢用」，出发点完全不同。

为什么 AIP 敢把这么重的治理逻辑塞进协议层？因为智能体互联走到今天，最大的瓶颈已经不是技术连通，而是信任缺失。企业不敢让智能体调用外部服务，怕的是身份不可验证；不敢把任务交给外部智能体，怕的是出错无法追责，两头堵住了落地。

再往下挖一层，AIP 的多中心化设计也很值得琢磨。它没有选择建立一个唯一的中心认证平台，而是允许存在多个认证中心、多个服务目录，它们之间通过协议互相承认、共同组网，避免把整个智能体生态的信任命脉系在一家机构身上，这是架构上很关键的一步。

多中心化的代价是协议实现更复杂，但它换来的东西很实在：任何一方都可以搭建自己的认证中心，中小团队不需要依附巨头也能进入互联网络，生态的进入门槛被压到了协议层面，而不是平台层面，竞争与创新因此有了空间。

对独立开发者来说，AIP 的先锋计划可能是今年最值得关注的参与通道。征集对象明确包含独立开发者和技术团队，参与方式不是交论文，而是做兼容实现、跑实测适配，这等于给了小团队一个提前卡位国标生态的机会，而且门槛并不算高。

写代码的人最关心的是落地形态。AIP 的接入不是另起炉灶重写一切，而是围绕身份、能力、任务、审计四个核心对象做标准化，下面用一段最小示例演示一个智能体如何声明自身能力，供调用方发现与核验，代码可以直接在本地运行验证。

import json, hashlib, time from dataclasses import dataclass, field @dataclass class AIPAgent: agent_id: str name: str capabilities: list = field(default_factory=list) endpoint: str = "" def capability_declaration(self) -> str: doc = { "agent_id": self.agent_id, "name": self.name, "endpoint": self.endpoint, "capabilities": self.capabilities, "issued_at": int(time.time()), } payload = json.dumps(doc, sort_keys=True, ensure_ascii=False) signature = hashlib.sha256(payload.encode()).hexdigest()[:16] return json.dumps({"declaration": doc, "signature": signature}, ensure_ascii=False) agent = AIPAgent( agent_id="agent-001", name="订单处理智能体", capabilities=["order.create", "order.query", "invoice.query"], endpoint="https://example.com/aip", ) print(agent.capability_declaration())

这段代码演示的是 AIP 能力声明的最小形态：智能体把自己的身份标识、服务端点、能力列表和签发时间打包成一份结构化声明，再对声明内容计算签名，调用方拿到声明后可以校验签名，确认内容没有被中途篡改过。

真实协议里，签名会用非对称密钥而不是简单的哈希，声明也会注册到认证中心供对方查询，但核心思想没有变：先证明身份、再声明能力、最后才谈协作。把这三个动作标准化，正是 AIP 与现有协议最大的不同，也是它敢叫「互联」的原因。

从产业节奏看，AIP 的推进速度其实相当快。5 月发实施意见，同月启动先锋计划，8 月就有首批兼容实现和互操作测试，前后只有三个月。对比 MCP 从发布到生态成型用了大半年，国标路线在组织动员上的效率优势很明显，执行力也不是社区自发能比的。

互操作测试是这轮提速里最实的信号。协议写得再好，不同厂商的实现互相连不通就毫无意义，跨厂商互测启动，意味着 AIP 开始从规范文档走向真实兼容性验证，这一步通常是协议生态起飞的前置条件，也是协议从理想走向可用的分水岭。

当然，AIP 也不是万能药。协议内置身份与结算，不等于安全就自动到位：认证中心自身的防护水平、密钥管理的规范程度、智能体侧的执行环境是否可信，仍然是决定整个链路安全性的变量，协议只能兜底，不能包办一切。

另外，AIP 与 MCP、A2A 的关系还需要生态来磨合。理论上三层互补，实际上先落地谁、谁先被主流框架集成，直接决定开发者会不会真的把 AIP 接进自己的技术栈，标准之间的竞争从来都是生态之争，不是文档之争，落地速度决定话语权。

对做 Agent 应用的团队，现在值得做的判断有三个。第一个，把 AIP 加入技术雷达，持续跟踪兼容实现的进展，不用急着接入，但别等到国标强制落地那天才第一次听说这个名字，被动接招的成本远高于主动研究。

第二个，如果你的产品需要跨企业调用外部智能体，提前研究 AIP 的身份与审计模型，这部分的标准化程度，很可能直接决定你未来在监管侧的合规成本是高是低，现在花小钱研究，省的是将来返工的大钱。

第三个，独立开发者可以认真考虑报名先锋计划。国标生态早期的参与名额往往有限，而早期参与者获得的适配经验和生态位，是后来者花多少时间都追不回来的，这可能是普通开发者离国标制定最近的一次机会。

回到开头那个问题：AIP 为什么要在 MCP 和 A2A 之外另起炉灶？因为协议栈里最缺的不是连通能力，而是信任机制。工具怎么接、任务怎么派，前两年已经被两套协议解决了，但智能体之间敢不敢互相调用，这件事一直没人管，也没人敢管。

AIP 1.0 的提速，等于正式宣布这一层要有人管了，而且是以国家标准的方式管。接下来半年，第一批兼容实现的互操作结果、先锋计划的实测报告，会比任何白皮书都更能说明这套协议的成色，也决定它能不能真的长成基础设施。

把 AIP 补的六课再往产业层面展开一层，会发现它的出现不是孤立事件，而是智能体应用从单点走向规模化的必然产物。单机智能体自己干活的时候，信任问题只存在于用户和产品之间，一旦智能体开始互相调用，信任关系就从一对一变成立体网络，复杂度完全不同。

立体网络里的信任成本是指数级上升的：十个智能体两两对接，要维护四十五对信任关系，一百个智能体就是四千九百五十对，靠人工维护每对关系的认证与授权，规模一大必然崩溃，协议标准化是唯一能扛住这个量级的解法，没有替代方案。

这正是 AIP 多中心化架构的底气所在。每个智能体只需要和自己的认证中心建立信任，再通过中心之间的互认完成跨域访问，信任链从两两直连变成树状传导，接入成本从 O(n²) 降到 O(n)，规模增长不再被信任维护拖死，这是指数级的好转。

类似的信任传导机制在现实世界里早有先例：银行之间不需要两两互信，而是通过清算中心完成跨行转账；航空公司之间不需要互相审核资质，而是通过联盟规则共享常旅客权益。AIP 把同一套经过验证的逻辑搬进了智能体世界，风险低得多。

再看结算交易这一课，它的想象力比字面意思大得多。当智能体可以标准地计价、清算、对账，就会出现真正的智能体经济：一个调度智能体可以同时向多家执行智能体询价比价，选中最优解并自动完成费用结算，全程不需要人介入。

这种经济形态在今天的互联网里已经有雏形，网约车平台撮合乘客与司机、外卖平台撮合用户与商家，本质都是智能调度加自动结算，只是调度和结算都发生在单一平台内部，AIP 要做的，是把这套机制开放成任意智能体之间的通用能力。

开放的结果是去平台化：不再需要一个超级平台来承接所有供需匹配，任何智能体都可以既是服务的需求方，也是服务的提供方，供需两端在协议层直接见面，平台从撮合者降级为众多节点之一，格局完全被改写。

当然，去平台化不等于无秩序。AIP 用行为审计补上了秩序这一环：每一次协作的来龙去脉都有记录，谁在什么时候调用了谁、结果如何、费用多少，全部可查，让开放生态在失去中心管控的同时，仍然保有问责能力，这很关键。

对技术团队而言，理解 AIP 还有一个更实际的用处：即使你的产品短期内不接国标，它的设计思路本身就是一份高质量的技术蓝图。身份、能力、结算、审计这四个维度，任何做多智能体系统的团队都迟早要自己补一遍，绕不开。

与其到时候自己发明一套互相不兼容的临时方案，不如直接借鉴 AIP 的对象模型来设计内部接口，未来想接国标时改造成本最低，不接国标也能白得一套经过论证的治理框架，这笔账怎么算都不亏，属于稳赚不赔的准备动作。

再从监管视角看一眼。三部门把 AIP 写进《实施意见》，信号已经非常明确：智能体互联不是纯技术问题，而是被纳入了数字基础设施的范畴，标准的制定权、认证体系的建设权，都是这个新基础设施里最有价值的卡位，先占先得。

19 个典型应用场景里，金融、政务、医疗这类强监管行业对可信互联的需求最迫切，这些行业也是最早会把 AIP 认证能力写进采购要求的领域，先完成兼容实现的厂商，在招投标里就多一张硬牌，这是最直接的商业回报。

反过来看，迟迟不关注 AIP 的团队会面临什么？最直接的风险是重复造轮子：自己搭的身份体系、结算体系与国标不兼容，将来接入外部生态时全部要推翻重来，这比现在多花两个月研究协议的成本高得多，而且是沉没成本。

还有一个容易被忽略的点：AIP 的能力声明体系对提示词工程也有影响。未来智能体接入外部服务，不再靠人肉阅读文档写提示词，而是直接读取机器可读的能力声明，自动生成调用方式，这份声明本身就是最标准的上下文，幻觉空间被压缩。

把视线拉回当下，8 月启动的互操作测试是接下来最值得盯的事件。测试覆盖哪些场景、暴露了哪些兼容性问题、首批通过测试的实现名单，这三件事的结果直接决定 AIP 在开发者社区的接受速度，也是判断国标成色的第一手样本。

可以预见，未来半年到一年，主流 Agent 框架会陆续把 AIP 客户端能力做成内置选项，就像当年 MCP 客户端从插件变成标配一样，等到框架层默认支持的时候再开始学，就已经落后半个身位了，先机从来都留给提前动手的人。

最后做一个不太一样的提醒：协议标准从来不是技术竞赛的终点，而是起点。AIP 给了智能体一张身份证，但持证之后做什么、怎么做、做到什么程度，比拼的仍然是各家在具体场景里的工程能力，标准负责降低门槛，不负责保证谁赢。

对开发者来说，智能体互联的下半场已经开场：上半场比谁的工具接得多，下半场比谁的身份立得住、账算得清、责追得到，提前理解 AIP 补的这六课，就是提前拿到下半场的入场券，而这张入场券，现在正摆在所有人面前。