尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

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

智能体互联协议 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 管治理未来的智能体技术栈大概率是三层同时存在、各司其职。维度MCPA2AAIP连接对象智能体↔工具智能体↔智能体海量智能体组网核心问题工具接入任务协作可信互联关键机制工具列表与调用能力卡与任务消息身份认证、结算、审计身份认证不在协议范围不在协议范围协议内置结算交易不在协议范围不在协议范围协议内置行为审计不在协议范围不在协议范围协议内置表格里最扎眼的差异在最后三行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_factorylist) 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_keysTrue, ensure_asciiFalse) signature hashlib.sha256(payload.encode()).hexdigest()[:16] return json.dumps({declaration: doc, signature: signature}, ensure_asciiFalse) agent AIPAgent( agent_idagent-001, name订单处理智能体, capabilities[order.create, order.query, invoice.query], endpointhttps://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 补的这六课就是提前拿到下半场的入场券而这张入场券现在正摆在所有人面前。
返回列表