智能体互联，指的是让来自不同厂商、不同平台和不同架构的 AI 智能体，按照共同规则完成身份核验、能力描述、发现匹配、交互协作和工具调用，从各自孤立的工具变成能够互相调用、共同完成任务的网络。它不是一款软件，也不是把所有智能体迁进同一个平台，而是一套跨系统协作的底层约定。
2026 年发布的 GB/Z 185—2026《人工智能 智能体互联》系列国家标准，给这套约定提供了完整框架。工业和信息化部科技司的解读指出，系列标准围绕身份可信、能力可见、发现匹配、交互协作、工具调用和任务完成展开，目标不是只让智能体连得上，还要让它信得过、管得住、可追溯。
对企业来说，企业级 AI Agent 的价值已经不只取决于单个 Agent 有多聪明，还要看另一个 Agent 能不能找到它、确认它是谁、判断它能做什么、在什么权限内调用它，以及任务失败后能不能追责。本文从定义、运行机制、协议边界和企业落地四个层面拆解智能体互联，帮助你判断现在该不该投入，以及第一步该做什么。
一、智能体互联到底是什么
1. 一套跨平台的协作规则
把智能体互联拆开看，至少要同时解决三件事。第一是连得上，双方要有稳定的身份和通信方式。第二是读得懂，彼此能理解对方能做什么、需要什么输入、会产出什么结果。第三是管得住，调用是否被授权、数据流向哪里、出了问题由谁负责，都要有记录。只完成第一件事，通常只是接口对接；三件事都完成，才接近真正的互联。
这也意味着，判断一个智能体是否具备互联能力，可以先看它能否清楚回答五个问题，我是谁、我能做什么、我现在是否可用、调用我需要什么权限、结果由谁负责。
智能体互联网与智能体互联的联系也在这里。智能体互联网描述的是更大范围的协作生态，智能体互联提供的是让这个生态成立的基础能力。就企业当前可落地的部分而言，先把互联能力做扎实，比追逐一个宏大的网络概念更重要。
2. 五个概念域分别负责什么
GB/Z 185—2026 属于国家标准化指导性技术文件，不是强制认证门槛，但它给出了一套可参照的公共框架。总体架构把智能体互联拆成五个概念域，这个拆法很适合企业做系统设计。
- 用户域负责任务发起和结果接收。
- 智能体域负责身份维护、描述维护、互联鉴权、交互和工具访问。
- 管理服务域提供身份、凭证和鉴别服务。
- 互联服务域提供描述管理、智能体发现和消息分发。
- 资源访问域连接工具和外部资源。
换成业务语言，就是谁发起任务、哪个 Agent 执行、谁证明身份、谁负责撮合、最后调用哪些系统和工具。五个域分开之后，安全、扩展和替换才不会互相牵制。
系列标准共七个部分，分别覆盖总体架构、身份码、身份管理、能力描述、发现、交互和工具调用。它们拼成一条完整链路。身份码和身份管理回答谁在互联、是否可信，能力描述和发现回答具备什么能力、如何被找到，交互和工具调用回答如何协同完成任务。
3. 三个容易混淆的边界
互联不等于接 API。 API 解决系统之间能不能传数据，互联还要解决对方是谁、是否有权、能力是否匹配、结果是否可追溯。把十个接口接通，不等于十个智能体能协同。
多 Agent 协作不等于智能体互联。 同一个平台内的多个 Agent 可以靠私有编排协作，但换成另一家厂商的 Agent，身份、权限、语义和审计往往全部重来。互联的重点是跨平台、跨归属、可替换。
上了协议不等于可信协作。 MCP、A2A 能降低连接和通信成本，但协议本身不会自动给出企业级身份体系、数据边界和责任机制。协议是路，治理是交通规则，两者缺一不可。
二、为什么现在要谈智能体互联
过去两年，企业做 Agent 项目大多从一个场景开始，客服、数据分析、内容生成、流程自动化，各自建设。场景一多，问题就从模型能力转移到系统关系。不同厂商的 Agent 身份不统一，能力说明不可读，跨平台调用靠定制开发，同一个客户请求要在几个系统之间重复解释上下文。工业和信息化部科技司把这类问题概括为适配成本高、协同效率低、可信管理难。
标准开始落地，说明产业已经从讨论概念走向补基础设施。央广网 2026 年 7 月报道，首批已发放 2000 余个重点行业智能体身份码。身份码只是入口，却释放了一个明确信号，智能体正在被当作需要注册、鉴别和追溯的网络实体来管理，而不只是某个软件里的功能按钮。
另一个值得警惕的数据来自 Gartner。2025 年，Gartner 预测到 2027 年底，超过 40% 的代理型 AI 项目可能因为成本持续上升、商业价值不明确或风险控制不足而被取消。这个判断对智能体互联同样适用。连接更多 Agent 本身不产生价值，只有把重复适配、任务交接和结果验收做成可复用能力，互联才值得投入。
互联不是把系统关系搞得更多，而是让跨系统的协作成本更低、责任更清楚。
三、智能体互联如何跑起来
把标准链路还原成一次真实任务，会更容易理解。假设一名运营人员要让 Agent 完成一次会员流失预警，从发起请求到生成可执行策略，中间至少要经过四道关。
1. 身份可信是入口
请求方和服务方先要证明自己是谁。GB/Z 185—2026 用身份码、身份账户、身份凭证和身份鉴别管理智能体的全生命周期。一个身份码只对应一个智能体，注册之后还要支持更新、锁定、解锁和注销。交互前，双方需要完成双向身份鉴别，再根据凭证和鉴别结果做访问控制。
企业最容易犯的错误，是把 Agent 当成一段代码，而不是一个非人类身份。更稳妥的做法，是给每个 Agent 明确负责人、用途、运行环境、可访问数据和有效期。不要多个 Agent 共用一把 API 密钥，否则一次越权就很难定位是谁做的。
2. 能力描述决定能否被调用
身份解决你是谁，能力描述解决你能做什么。标准要求描述智能体的能力、状态、接口和服务特性，并管理注册、发布和变更。对企业来说，一份有用的能力描述不能只写擅长数据分析，而要说明输入是什么、输出是什么、能访问哪些数据、能执行哪些动作、响应时间多长、失败时怎么处理、当前版本是否可用。
能力描述不是产品介绍，而是机器可读的服务契约。 只有写到这个程度，另一个 Agent 才能在不问人的情况下判断是否调用它。版本变更也要进入管理，否则上游 Agent 仍按旧接口调用，任务会在最不应该出错的地方失败。
3. 发现与匹配决定协作效率
有了身份和能力描述，还需要一个发现机制。发现不是简单搜索关键词，而是根据任务要求、权限范围、地域、成本、服务质量和可用状态做匹配。一个 Agent 能分析数据，不代表它有权访问这批数据；一个 Agent 价格低，也不代表它能在规定时间内完成任务。
企业可以先建内部能力目录，把自建 Agent、供应商 Agent 和 SaaS 内嵌 Agent 统一登记。对外部 Agent，则要设置白名单和准入条件。发现机制越清楚，跨部门任务越不需要靠人拉群协调。
4. 交互和工具调用决定任务能否完成
标准支持点对点、群组和混合等交互模式，也规定了外部工具调用的架构、流程和数据格式。落到任务上，至少要能完成子任务分派、进度同步、结果交付、超时处理和人工接管。
真正决定能不能上生产的，往往是过程记录。一个可追溯的任务链应该留下目标、计划、调用的 Agent、访问的数据、执行的动作、人工审批和最终结果。出现错误时，团队才能判断是理解错了、权限越界、数据过期，还是某个工具返回异常。
互联的终点不是连上，而是任务完成且结果可追溯。
四、智能体互联与 MCP、A2A 是什么关系
MCP 和 A2A 经常被放在一起讨论，但它们解决的不是同一个问题。MCP 官方文档把自身定位为连接 AI 应用与数据、工具和应用的开放协议，重点是让 Agent 能标准化地获取上下文、调用工具。A2A 官方文档则把它定义为智能体之间通信与协作的开放标准，重点是让不同框架、不同厂商构建的 Agent 能发现彼此、委派任务、交换结果。A2A 最初由 Google 开发，后来捐赠给 Linux 基金会。
层次主要解决典型对象企业关注点MCP智能体连接工具、数据和应用Agent 与工具工具接入、数据访问、权限控制A2A智能体之间发现、委派任务和交付结果Agent 与 Agent跨平台协作、任务状态、结果交付GB/Z 185—2026覆盖身份、描述、发现、交互、工具调用和治理的完整框架智能体互联体系身份可信、能力可见、全程可追溯
三者不是替代关系。MCP 更像工具插座，A2A 更像 Agent 之间的协作语言，GB/Z 185—2026 则在更上层补齐身份、发现、权限和治理。企业选型时不要只问用哪一个协议，而要判断自己缺的是工具连接、Agent 通信，还是整套可信协作机制。
如果工具接入是当前瓶颈，可以优先看 MCP 协议 的落地能力。如果已经有多个厂商的 Agent，需要重点补身份、能力目录和协作审计。
五、企业能拿它解决什么问题
1. 跨系统任务不再靠人搬运
以一个退款纠纷为例。客服 Agent 接收诉求，订单 Agent 查询交易，规则 Agent 判断是否符合退款条件，支付 Agent 执行退款或给出失败原因。金额超过阈值时，流程转人工审批。整个过程里，人只需要确认关键动作，不需要在四个系统之间复制订单号、解释背景、追问进度。
这类场景的价值不在某一个 Agent 更聪明，而在任务链路被标准化。适配逻辑从一次性开发变成可复用的连接能力，责任也从某个人记在聊天记录里，变成系统里的身份、权限和审计记录。
2. 能力复用比重复造 Agent 更划算
当 Agent 有了统一描述和发现方式，能力就可以像内部服务一样被复用。数据分析 Agent 不只服务一个报表场景，还可以被运营、财务和客服的 Agent 调用。供应商的 Agent 也不必为每个客户重做接口，只要按统一方式登记能力、权限和计费规则。
这也是平台化建设真正有意义的地方。企业不需要把所有 Agent 都做成一个样子，而是要让不同来源的 Agent 在同一套规则下被管理、调度和组合。
3. 让协作结果可验收
评估智能体互联，不能只看接入了多少个 Agent。更有效的指标包括任务完成率、一次交付成功率、跨 Agent 交接成功率、人工接管率、端到端耗时、单任务成本和审计记录完整度。先测基线，再看试点是否改善，避免把演示效果当成生产结果。
这些指标最后都要回到业务结果。客服看问题解决时长，运营看策略执行周期，数据团队看分析请求到结论的时间。技术指标负责解释变化，业务指标负责判断值不值得继续投入。
六、从能连到能管，企业该怎么落地
智能体互联不适合一上来就做大平台。更现实的路径，是选一个高频、跨角色、结果可验证的任务，用最小闭环跑通身份、描述、发现、协作和治理，再逐步扩展。下面三步可以直接作为项目起点。
1. 第一步，画清连接地图
先不要急着选协议，先把现有 Agent 和它们背后的系统画出来。每个 Agent 至少记录负责人、所在平台、可访问数据、可执行动作、调用频率和风险等级。内部自建 Agent、供应商 Agent、SaaS 内嵌 Agent 和面向客户的 Agent 要分开看，因为它们的身份来源、权限边界和退出方式不同。
地图上要标出三类边界，哪些数据只能读、哪些动作可以自动执行、哪些动作必须人工确认。很多项目失败，不是连接技术不通，而是边界没有提前画清楚。
图 1 智能体互联先回答四个问题，谁在连、能做什么、怎么找到、怎么协作。
2. 第二步，跑通最小互操作闭环
选一个跨两个以上系统的任务，只接入完成这个任务必需的 Agent。最小闭环要包含身份核验、能力卡、权限判断、任务分派、结果回传和审计记录。不要一开始就追求所有 Agent 互通，也不要为了展示效果接入一堆低价值工具。
验收标准要在项目开始前定好。除了任务是否完成，还要看人工接管次数、平均耗时、失败原因是否可定位、权限是否按最小范围授予。没有基线，就不要承诺提升比例。
图 2 最小互操作闭环从任务请求走到结果验收，每一步都要留下记录。
3. 第三步，把治理写进协作链
多 Agent 协作 会放大两个风险。一个是错误传播，一个 Agent 理解错了，可能把错误任务继续分派给下游。另一个是权限叠加，单个 Agent 权限不大，几个 Agent 串起来后可能触达核心数据或执行高风险动作。Agent 治理 不能等到上线后再补。
至少要把身份生命周期、最小权限、数据边界、人工审批、版本管理、运行审计和供应商退出机制写进协作链。高风险动作要有暂停、回滚和人工接管。每个 Agent 的输出要能追溯到输入、工具和决策依据。
可互联、可治理、可退出，才算真正可上线。
图 3 治理要穿过身份、权限、数据和行动四道闸门。
这也是企业级 Agent 平台需要补的能力。ThinkingAI 的 Agentic Engine 把 Agent 创建、多 Agent 协作、MCP 服务、运行治理和私有化部署放在同一套平台能力里，服务全球 1500 家企业，接入产品超过 8000 款。对于需要跨系统协作又要求数据留在自己环境里的团队，这类统一底座可以减少每个场景重复搭身份、权限和审计的成本。
七、哪些企业现在就该做，哪些可以再等等
如果企业只有一个 Agent，流程固定，不跨系统，也没有审计要求，当前更重要的是把数据和流程整理好，不必为了概念去搭互联平台。相反，出现下面几种情况，智能体互联就从可选项变成基础设施。
- 同时使用多个厂商或多个平台的 Agent，接口和身份各自一套。
- 一个任务要跨三个以上系统，人员经常复制粘贴、重复解释上下文。
- 需要把供应商 Agent、客户侧 Agent 和内部 Agent 放进同一条任务链。
- 任务高频、结果可验证，出错后必须定位责任。
- 处于金融、医疗、政务等强监管场景，需要权限、审计和退出机制。
可以用五个条件做初筛，任务频率、跨边界程度、结果可验证性、错误可撤销性、治理准备度。五项越靠前，越适合先做。反过来，低频、低风险、结果难验证的任务，即使技术上能互联，也未必值得投入。
互联成熟度不看接入了多少 Agent，而看有多少任务能不靠人重新解释上下文就完成。
常见问题
智能体互联和智能体互联网是一回事吗？
不完全是一回事。智能体互联强调不同智能体之间的身份、描述、发现、交互和工具调用能力。智能体互联网更像一个更大的生态愿景，强调大量智能体在跨组织环境中自主发现和协作。前者是后者的基础，后者还需要商业模式、监管规则和更成熟的可信基础设施。
智能体互联就是多 Agent 协作吗？
不是。多 Agent 协作可以发生在同一个平台、同一个团队甚至同一套私有编排里。智能体互联的重点是跨平台、跨厂商、跨归属，并且把身份、权限、发现和审计做成公共规则。内部能协作，不代表外部能互联。
小企业没有自研 Agent 平台，也能参与吗？
可以。小企业不需要自己造一套完整基础设施，但选择产品时要看几个条件，是否支持标准接口或 MCP，是否能提供 Agent 身份和权限管理，是否留下调用记录，是否允许导出配置和数据。否则接入越快，后续迁移和审计成本可能越高。
智能体互联会带来哪些新风险？
常见风险包括身份冒用、权限越界、提示词注入、数据泄露、错误在多个 Agent 之间放大，以及员工私建 Agent 形成的影子资产。治理重点不是禁止连接，而是让每次连接都有身份、有权限、有边界、有记录、有退出方式。
企业第一步应该做什么？
选一个跨角色、高频、结果可验证的任务，画清涉及的 Agent、数据和动作边界，明确负责人和验收指标，然后跑通一次包含身份核验、能力匹配、任务执行和审计记录的完整闭环。先证明一个任务能稳定完成，再谈平台化和规模化。
