这份指导性技术文件只解决一件事：让不同厂商的智能体能够互相找到、互相认出、互相调用。它不是又一份技术白皮书，而是国内智能体互联的顶层设计——后面六个分标准，都从这张总图展开。

第1部分：总体架构

01 标准概况

过去两年，AI Agent 从演示走向生产，但一个尴尬的现实是：不同厂商的智能体各说各话——A 家的智能体找不到 B 家的工具，C 平台的助手调不动 D 云的智能体。能力有了，连接没有。

国际上有 MCP、A2A 等协议在尝试解决，但尚未形成广泛共识；而在企业与政务场景最在意的环节——身份、凭证、多中心管理——开源协议的覆盖依然偏弱。这正是 GB/Z 185 系列要补上的空白。

（1）系列标准共七个部分。

本文件是第 1 部分，负责给出概念模型与功能参考架构，即全局的“总图”。

（2）适用范围与四个核心术语

这份文件不规定具体协议字段，只回答“系统应该怎样分工、域与域之间怎样对接”。读它的正确姿势是：先记住五个域，再看十组接口。开工之前，四个术语先钉死。

1）智能体 Agent：能够感知环境、主动行动以实现目标的软件实体。三个定语缺一不可——只能被动响应的，是脚本；能感知、会主动、朝目标，才叫智能体。

2）智能体互联：智能体通过标准协议或接口，与其他智能体、外部工具建立连接、协同完成任务。特别强调：包含智能体与工具的调用连接——工具不是配角。

3）智能体身份码：由注册机构分配的唯一标识符，用于识别、鉴权与管理智能体。可以理解为智能体的“身份证号”。

4）智能体凭证 ：防篡改、携带身份属性，用于身份鉴别——相当于带签名的证件，用来证明“你是你”，而不是“你说你是”。

国内标准与开源协议最不一样的地方，就在后两个术语：把身份与凭证抬到了与能力同等重要的位置。

02 概念模型

MODEL五大概念域如何分工：

整套体系把参与方划成五个相互交互的概念域。读懂这张分工表，后面的接口就都能对上号。

（1）用户域：

任务的发起方与结果的接收方，可以是个人，也可以是机构。它不需要懂协议，只负责提出需求、验收结果。

（2）智能体域：

核心主体，承载智能体自身能力：身份维护、描述维护、互联鉴权、智能体交互、工具访问。几乎所有的“动作”都发生在这一域。

（3）管理服务域：

负责身份的全生命周期管理、凭证发放与注销，以及身份鉴别校验——整个体系的“户籍科”。

（4）互联服务域：

智能体描述管理、能力发现与群组消息分发，解决“互相找得到、消息传得到”。

（5）资源访问域：

各类外部工具服务：数据库、业务系统、设备接口，供智能体调用执行外部能力。

一句话记住这套分工：管理域管「你是谁」，互联域管「你在哪」，智能体域管「你能干什么」，资源域管「你能用什么」，用户域管「要你干什么」。

把身份与连接拆成两个域，是这份标准与多数开源协议最大的不同——它把“信任”从业务逻辑里抽出来，单独立法。

03 功能参考架构

（1）每个域要切实具备的能力。

功能参考架构不是一张好看的框图，而是把“每个域该具备什么能力”落到功能点上。五个域的职责边界清不清，直接决定后面接口好不好接。

注意智能体域的五项能力——一个能互联的智能体，至少要会“管身份、管描述、会鉴权、会对话、会调工具”，缺一项就会在某个环节断链。

（2）十组 FRAI 接口

如果说概念域是“部门”，FRAI 接口就是部门之间的“交接单”。

标准定义的十组接口，按用途可归为四类。

1）身份注册与凭证（FRAI-01～05）

智能体注册、身份码分配、凭证发放、凭证更新与注销——对应“上户口、发证件、办注销”。身份是所有互联动作的前置条件。

2）描述注册与发现（FRAI-06～07）

描述登记回答“我会什么”，能力发现回答“谁需要我”。两者合起来构成智能体之间的“招聘市场”。

3）消息交互（FRAI-08～09）

点对点消息与群组消息。一个任务可以由多个智能体分头执行、再汇总结果，群组消息就是分头执行的基础设施。

4）工具调用（FRAI-10）

智能体访问资源域工具的通道，补齐从“协商”到“真正干活”的最后一公里。

把十组接口串起来，一次完整协作跑下来是这样的链路：

这条链路的价值不在任何单点，而在标准化：任何一家按 FRAI 实现的智能体，理论上都能接入任何一家同样实现的平台，互联从此不靠私下对接。

04 典型业务场景

附录 A 的四个落地样本：附录 A 用四个场景演示这套架构怎么用，从最简单的注册，到最复杂的跨中心协同与具身智能调度。

（1）SCENE 01 · 注册流程

（2）SCENE 02 · 跨中心发现

（3）SCENE 03 · 手机终端协同

（4）SCENE 04 · 机器人协同作业

四个场景没有一个是“两个智能体私下拉个群”，全部经由标准接口与凭证校验——这正是“体系化互联”与“点对点适配”的分水岭。

05 技术对照

（1）标准和 MCP 是什么关系。

一句话：目标重叠，重心不同——MCP 解决“应用如何接工具”，GB/Z 185 解决“智能体之间如何成体系地互联”。至少四组能力可以直接对齐。

至于 A2A，它更接近“智能体之间的对话与任务委派”，与系列第 6 部分（智能体交互）目标一致；差异同样落在身份体系与多中心治理上——这恰是国内标准着墨最多的地方。

（2）开发者的现实意义

如果你正在用 AgentScope、LangChain4J 这类框架搭 SAA（Orchestrator-Worker）架构，会发现最难的从来不是编排本身，而是跨团队的五个问题：怎么注册、怎么描述能力、怎么发现对方、怎么鉴权、怎么调工具。

第2部分 身份码

这是 GB/Z 185《人工智能 智能体互联》系列的第 2 部分。整个系列规划 7 个部分：总体架构、身份码、身份管理、智能体描述、智能体发现、智能体交互、智能体工具调用，目标是解决多智能体跨平台、跨架构的互联互通互操作。第 1 部分搭骨架，第 2 部分回答的第一个问题是：这个智能体到底是谁。

01 系列定位

多智能体互联，本质上要连续回答四个问题：你是谁、你能做什么、去哪里找你、怎么和你协作。这 7 个部分正好把这条链拆开，一段一段立规矩。

身份码排在第二位并不偶然：先有唯一身份，才谈得上发现、交互与调用。没有它，后面每一层都只能靠 IP、URL 或私有 ID 临时凑合。

02 范围与引用：站在 OID 体系上

文件规定智能体身份码的编码规则、分配与管理要求，适用于智能体互联场景下身份码的制定与应用。范围很窄，但覆盖面很宽——凡是要跨系统识别智能体的地方都用得上。

规范性引用只有两份：GB/Z 185.1—2026 定总体架构，GB/T 26231 定 OID 对象标识符国家编号体系。编码设计整体建立在 OID 之上，不是另造一套命名空间。

03 六个术语，四类角色

术语把“程序”和“进程”彻底分开，这是理解全文的前提。

四类角色串起来是一条责任链：服务方发号、请求方申请、本体注册、实例运行。谁发的号谁负责，这条链在后面的管理要求里会反复出现。

04 编码规则：六段点分，根是固定的

身份码用小数点分隔的多层 OID 节点表示，全局固定根前缀 1.2.156.3088，从左到右六段依次是：OID 根 · 版本号 · 服务方编码 · 请求方编码 · 本体序列号 · 实例序列号

字符集只允许阿拉伯数字 0-9 与 A-Z，字母大小写不敏感，且编码必须全局唯一、全生命周期可追溯。

附录 C 给了一个完整样例，逐段拆开看最直观：

注意最后两段：同一个 Agent 程序部署 5 份，前五段完全一致，只有实例序列号不同。这就是“一码一实例”在编码层面的落地方式。

05 分配与管理：四条硬规矩

编码规则只是形式，真正决定能不能长期用的是管理要求。

废弃编码禁止复用：已停用的服务方编码不得重新分配给别的机构，否则历史记录会指向错误主体。

本体核心功能变更建议重新申请；多版本同时对外提供服务，应分配不同本体序列号。

一码唯一：一条身份码只能唯一对应一个智能体——要么本体，要么实例。

服务方负主体责任：自定义序列号的定义、分配、管理由注册服务方承担。

第 1 条最容易被工程团队忽略，却最贵：编码复用等于身份历史被污染，追溯链一断，审计就失去意义。

06 附录：实体链路与海外通路

三条路指向同一个结论：可以分域治理，但根只有一个。互认的是规则，不是编号体系。

07 工程落地：现在能做的三件事

这三件事的共同点是：都不需要等系列标准全部发齐。身份码是现在就能落地的第一层地基，早做一天，后面少改一处。

第3部分 智能体身份管理

第 2 部分解决了“编号怎么发”，第 3 部分解决“发完之后怎么管、怎么验”。两者是一对：身份码是标识，身份管理是账户、凭证与鉴别的运行机制。这份文件适用于智能体身份管理系统的开发、应用与测评，也是整个系列里安全分量最重的一份。

01 从身份码到身份管理

有了身份码，并不等于系统认得这个智能体。编号只是一个字符串，要让它变成可验证的身份，还需要三样东西：一份绑定证明材料的账户、一份由发行方签名的凭证、一次能给出结论的鉴别。

所以 185.3 的定位很清晰：它不重复编码规则，只规定这些编码如何被创建、维护、签发与校验。一句话概括两者的分工：185.2 回答“你是谁”，185.3 回答“凭什么信你、信多久、谁能作废这个信任”。

02 引用文件与七个角色

规范性引用四处，分别兜住身份码、信息安全、人工智能与大模型四个层面。

七个术语把“谁负责什么”切得很细：

缩略语只有两个，但都指向硬件级安全：HSM 硬件安全模块与 TEE 可信执行环境。密钥放哪里，这份文件是给了倾向的。

03 整体框架：域、角色与四条主流程

框架先按参与方划域，再按职责定角色，最后收敛成四条业务流程。

角色覆盖双方：委托方、智能体、工具提供方站在业务侧；注册服务方、凭证发行方、身份验证方站在管理侧。一个机构可以兼多个角色，但职责必须写清楚。

身份注册与核验：建立智能体数字身份，是所有身份能力的前提。

身份账户管理：更新、锁定、解锁、注销，覆盖账户全生命周期。

凭证管理：发行、更新、锁定、解锁、注销。

身份鉴别：智能体之间交互、访问外部工具时完成校验与鉴权。

业务示例最能说明角色如何落位：智能体 A 调用智能体 B 或某个外部工具时，B 与工具提供方就是身份依赖方，先验证 A 的身份，再决定放不放行。

04 注册与核验：先证明你是谁（5步骤）

四类核验材料：

这四类材料的设计意图很明确：既要证明“这个程序是什么”，也要证明“谁允许它做什么”。附录 A 给出了基于公钥证书的完整注册流程。

密钥存放有明确建议：存进 HSM 硬件安全模块或 TEE 可信执行环境，而不是放在应用服务器的文件里。

05 账户生命周期：更新不改码

账户由注册服务方管理，所有操作留审计日志，且日志必须防篡改——这条不是锦上添花，是事后追责的唯一证据链。

最需要提前定好的一条规则：什么变更走“身份更新”，什么情况已算“新智能体”而必须重新注册、分配新身份码——标准明确建议把这条界线写清楚，否则版本一多就会乱。

06 凭证管理：有效期不得超过账户

凭证由发行方数字签名，有明确有效期，且凭证有效期不能超过所属身份账户的生命周期——账户没了，凭证必须跟着失效。

（1）凭证发行：两条申请路径，注册服务方代为发起，或智能体直接发起。

（2）凭证更新：账户变更联动更新；短生命周期凭证建议配置自动化周期性更新。

（3）凭证锁定／解锁：操作需记录原因代码；锁定状态下验证直接判定无效；支持多方角色发起，并支持外部查询锁定状态。

（4）凭证注销：账户注销联动注销，且支持查询注销状态。

注意“支持外部查询状态”这个要求——它意味着凭证状态必须能被第三方实时问到，否则依赖方无法判断一张看起来有效的凭证是不是已经作废。

07 身份鉴别：一次调用前的五步校验

附录 C 提供了基于公钥证书的完整鉴别时序图，工程实现可照着对齐状态机。

08 工程落地：四条能马上用的结论

身份管理做的不是“发一张证”，而是让每一次调用都能回答三个问题：你是谁、谁授权你、这份授权还有效吗。

第4部分 智能体描述

第 4 部分解决“怎么把能力讲清楚”。它定义的不是接口协议，而是一份结构化的自我说明书：有哪些字段、每项技能能用什么输入换来什么输出，以及这份说明书如何注册、发布、更新。

01 描述：智能体的自我说明书

一个智能体要被别的系统用起来，对方至少要能回答三件事：它是谁、能做什么、怎么找它。这三件事以前散落在文档、接口注释和人的口头介绍里，现在被收进一份统一格式的结构化数据集。

所以这份描述有两个读者：人读得懂用途，机器读得懂字段。前者决定要不要用，后者决定怎么自动调用。

它在系列里的位置也很清楚：向下绑定身份码，向上喂给发现服务——第 5 部分能检索到什么，取决于这里写得多规范。

02 四个角色与两类对象

四个概念里，只有“描述管理方”是新增的治理角色，其余三个都来自前几部分。它相当于一个带审核权的登记处，而不是简单的文件托管。

03 基础属性：七个必填，六个选填

整体分两大块：智能体基础属性与技能数组。基础属性里有七项是必填的，构成机器识别一个智能体的最小完备信息集。

必填项的设计逻辑可以这样读：身份、名称、版本、说明解决“你是谁”，capabilities 解决“还能干什么”，输入输出类型解决“怎么接”。选填项则全是部署与商务层面的信息。

agentId 不是普通字段，是主键。它直接引用 185.2 定义的身份码，意味着描述与身份在数据层面强绑定——两张表靠它关联，不容许出现两套 ID。

04 技能数组：能力的最小单元

技能是必填数组，一个智能体可以挂多项技能。这是把“一个大而全的智能体”拆成可被发现、可被单独调用的能力条目的关键设计。

tags 和输入输出类型放在技能层而不是智能体层，是有意为之：检索粒度到技能，调用协商也到技能。电力场景里，车牌识别、告警研判、报告生成完全可以各做一个 skill。

05 注册：先把身份核验清楚

注册是把元信息登记到描述管理方的动作，也是发布的前置条件。流程四步。

06 发布：有了证书才能被检索到

注册完成不等于能被找到。发布之后，这条描述才进入可被发现的数据集，供第 5 部分的发现服务检索。

两种发布模式：管理方代理发布提供方自建 well-known 暴露文档

代理发布是主流路径，四步走完，证书贯穿其中。

07 变更：别让发现服务读到旧能力

智能体迭代时，描述必须跟着动。变更流程五步，其中第 4 步最容易被漏掉。

7.1提交变更申请：带上更新后的描述；如需重新发布，同步携带发布所需附加材料。

7.2 管理方审核：对变更内容做审核，而不是照单全收。

7.3返回审核结果：通过或不通过，均需给出结论。

7.4更新并同步发现服务：审核通过后更新已发布信息，并同步给智能体发现服务。

7.5可选自检：提供方可自行做变更有效性校验。

第 4 步是整条流程的价值所在：只改了自己的描述、没同步发现服务，外部拿到的仍是过时能力——调用失败会以“对方不靠谱”的形式出现，很难归因。

08 工程落地：五条经验

互联的前提不是接口能通，而是彼此说得清自己是谁、会做什么、愿意以什么方式被调用——描述，就是这份说清楚的能力。

第5部分 智能体发现

有了身份和描述，还要能被找到：中心检索与本地预置，两条路怎么走。

第 5 部分解决“别人怎么找到我”。这一环看着最轻，却决定了整个互联体系是活的还是死的——描述再规范，搜不到就等于不存在。

01 发现：从认得出到找得到

发现之前的所有工作都是在准备元数据，发现是第一个把元数据用起来的能力：查询、过滤、返回，然后把控制权交给后续的交互环节。

三道门槛缺一不可：先有 185.2 身份码、再完成 185.3 身份注册、最后是 185.4 描述注册发布——任一环节缺失，这个智能体在发现机制里就是查不到的。

02 定义与三种入口

描述文档格式遵从 GB/Z 185.4——所以发现的输出物不是链接列表，而是可直接用于后续调用的结构化文档。

入口支持三类，覆盖三种使用者：

同一套发现能力要同时服务机器和人，这也是为什么查询条件既可以人工配置、也可以由智能体自主生成。

03 方式一：中心检索五步

依赖中心化发现服务，服务端需要与描述管理方保持数据同步，否则查到的可能是过期能力。

部署上有两种形态：发现服务与描述管理方可以是同一系统，也可以拆开。拆开就必须做数据同步，这是架构选型时最容易低估的一笔成本。

04 方式二：本地预置

不调中心服务，直接读本地已有的描述信息。适合封闭、稳定、Agent 数量有限的场景。

缓存是这套模式唯一的软肋：数据会过期，业务系统必须自行设计有效性校验机制——否则失败会以“对方能力不对”的形式出现，而不是“我的缓存旧了”。

05 两种模式怎么选

这三条其实是同一个判断标准的不同切面：元数据的变动频率与参与方数量。变的人多、加的人快，就上中心；几年不变的，本地就够。

组合模式最实用：冷启动查中心、热路径读本地，既保证覆盖率，又不牺牲时延。

06 结果集与可发现开关

发现返回的是描述文档，里面带着后续调用需要的全部元数据：

四项里前三项决定“找不找得到、连不连得上”，第四项决定“连上之后怎么自动对齐格式”。

“是否允许被发现”是一个开关，不是权限的补充：关掉之后，该智能体在检索结果里直接消失，用于内部 Agent 的访问隔离——避免内部业务智能体被外部随意检索。

07 工程落地：四条建议

互联体系的效率，不取决于最强的那一个智能体，而取决于任意两个陌生智能体之间，能不能在几秒内互相找到并确认对方能干什么。

第6部分 智能体交互

第 6 部分解决“说得上话”。前置条件写得很硬：先经发现定位目标智能体，再完成双向身份鉴别，之后才能开始交互——这三步缺一步，后面的协议设计都是空转。

01 交互：链路的第五环

前四环都在准备“对象”，交互是第一个真正产生业务结果的环节：任务下发、结果回传、多轮往复，全在这里发生。

前置条件不是建议，是准入：必须通过智能体发现定位目标智能体，并完成双向身份鉴别，才可开展交互。发现解决“是谁”，鉴别解决“是不是它”。

02 两个角色，随时互换

这不是两种设备，而是两种运行时姿态：同一个智能体在 A 任务里当请求方，在 B 任务里可能就是服务方。所以实现时别把角色写死到部署单元上，角色应该挂在这一次会话的身份上。

03 三种交互模式

04 四层模型：会话→任务→消息→数据

两条关键约束藏在这张表里：消息必须携带发送方的智能体身份码，实现全过程身份可追溯；消息支持分片，大图片、大报告才不会被协议卡住。

任务状态是六值枚举，不是自由文本——接受、拒绝、进行中、完成、失败、取消，落地时直接做成状态机，别自创状态名。

05 点对点流程：八步闭环

06 群组流程：多一个中转

群组不是把点对点连起来就行：多出的分发模块要负责成员管理、消息广播与顺序，它本身就是一个需要治理的组件。

07 两个附录：传输与协作模式

这三种不是三选一的“标准答案”，而是按任务时长与结果形态选：秒级同步走远程调用，持续输出走流式，分钟级以上走异步回调。

08 工程落地提示

协议的价值不在于规定消息长什么样，而在于让两个从未合作过的智能体，在不打电话沟通的前提下，也能把一件事做完、做干净、收好尾。

第7部分：智能体工具调用

前六部分解决“是谁、会什么、怎么找到、怎么对话”，第七部分解决“怎么真的动手”。模型的推理能力再强，接不上业务系统就只能聊天；工具调用这一层，才是把智能体从演示推进到生产的那道门。

01 收尾：最后一公里

到这里，一个智能体从出生、被别人认识、被找到、能对话，到能真正调用外部能力，闭环才算完整。缺了第七部分，前面六部分都只是“说说而已”。

02 先把“工具”说清楚

标准给的定义很宽：可以被智能体调用、具备特定业务功能的硬件设备、软件程序、业务系统，都算工具。

这就意味着，你项目里那些存量的东西不需要重写，只要能包一层就能用：

关键不在“它是不是 AI 原生”，而在它是否被标准的工具描述与报文包住——包住了，智能体就能理解、能调用。

03 四层总体架构

链路是单向四跳，每一跳职责不重叠：

为什么要多一层“工具访问”：它把智能体侧的调用意图，翻译成工具服务能懂的标准化请求，顺带承担工具列表同步。没有这层，每家智能体都要自己适配一遍工具服务。

04 三个流程

05 六类标准化报文

报文是这套标准最可直接落地的部分，六类各有明确字段：

两个字段值得单独盯：sessionId 与第 6 部分的会话体系打通，一次工具调用能挂回具体的会话与任务，全链路可溯源；状态码要能区分成功、失败及失败原因，否则上层无法判断该重试还是该放弃。

工具描述就是接口说明书：六个必选字段缺一个，智能体就可能在“该传什么参数、会返回什么”上猜错——这类错误不会报错，只会安静地给出错误结果。

06 附录 A：一份日历工具的样例

资料性附录用日历工具走通了全流程——添加日程、查询日程，把工具描述、列表申请与同步、调用请求与返回的 JSON 全给了出来，可以直接当开发模板抄。

{ "toolId": "calendar.add_event", "toolName": "添加日程", "toolVersion": "1.0.0", "toolInputParam": { "title": "string", "startTime": "ISO8601" }, "toolOutputParam": { "eventId": "string", "status": "int" } }

07 整套链条：七篇连起来看

把七部分串成一条端到端流程，就得到国产智能体互联的完整骨架：

185.2 身份码：分配全局唯一 agentId。

185.3 身份管理：完成注册、账户、凭证与身份鉴别。

185.4 智能体描述：编写能力元数据并注册发布。

185.5 智能体发现：其他智能体检索、定位目标。

185.6 智能体交互：建立会话—任务—消息，多智能体协同。

185.7 工具调用：调用外部业务工具与硬件接口。

这条链的每一环都依赖上一环：没有身份码就无法鉴别，没有描述就搜不到，没有会话就无法把工具调用挂到具体业务上下文里。

08 落地建议

国家标准把智能体互联拆成七件事：证明你是谁、登记你会什么、让别人找到你、与你建立会话、把任务说清楚，最后——让你真的能调用外部世界。

参考文献：

1、GBZ+185.1-2026《人工智能 智能体互联 第1部分：总体架构》解读 附下载

2、GBZ+185.2-2026《人工智能 智能体互联 第2部分：身份码》解读 附下载

3、GBZ+185.3-2026《人工智能 智能体互联 第3部分：身份管理》解读 附下载

4、GBZ+185.4-2026《人工智能 智能体互联 第4部分：智能体描述》 解读 附下载

5、GBZ+185.5-2026 《人工智能 智能体互联 第5部分：智能体发现》解读 附下载

7、GBZ+185.6-2026 《人工智能 智能体互联 第6部分：智能体交互》解读 附下载