这份指导性技术文件只解决一件事让不同厂商的智能体能够互相找到、互相认出、互相调用。它不是又一份技术白皮书而是国内智能体互联的顶层设计——后面六个分标准都从这张总图展开。第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-0105智能体注册、身份码分配、凭证发放、凭证更新与注销——对应“上户口、发证件、办注销”。身份是所有互联动作的前置条件。2描述注册与发现FRAI-0607描述登记回答“我会什么”能力发现回答“谁需要我”。两者合起来构成智能体之间的“招聘市场”。3消息交互FRAI-0809点对点消息与群组消息。一个任务可以由多个智能体分头执行、再汇总结果群组消息就是分头执行的基础设施。4工具调用FRAI-10智能体访问资源域工具的通道补齐从“协商”到“真正干活”的最后一公里。把十组接口串起来一次完整协作跑下来是这样的链路这条链路的价值不在任何单点而在标准化任何一家按 FRAI 实现的智能体理论上都能接入任何一家同样实现的平台互联从此不靠私下对接。04 典型业务场景附录 A 的四个落地样本附录 A 用四个场景演示这套架构怎么用从最简单的注册到最复杂的跨中心协同与具身智能调度。1SCENE 01 · 注册流程2SCENE 02 · 跨中心发现3SCENE 03 · 手机终端协同4SCENE 04 · 机器人协同作业四个场景没有一个是“两个智能体私下拉个群”全部经由标准接口与凭证校验——这正是“体系化互联”与“点对点适配”的分水岭。05 技术对照1标准和 MCP 是什么关系。一句话目标重叠重心不同——MCP 解决“应用如何接工具”GB/Z 185 解决“智能体之间如何成体系地互联”。至少四组能力可以直接对齐。至于 A2A它更接近“智能体之间的对话与任务委派”与系列第 6 部分智能体交互目标一致差异同样落在身份体系与多中心治理上——这恰是国内标准着墨最多的地方。2开发者的现实意义如果你正在用 AgentScope、LangChain4J 这类框架搭 SAAOrchestrator-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、GBZ185.1-2026《人工智能 智能体互联 第1部分总体架构》解读 附下载2、GBZ185.2-2026《人工智能 智能体互联 第2部分身份码》解读 附下载3、GBZ185.3-2026《人工智能 智能体互联 第3部分身份管理》解读 附下载4、GBZ185.4-2026《人工智能 智能体互联 第4部分智能体描述》 解读 附下载5、GBZ185.5-2026 《人工智能 智能体互联 第5部分智能体发现》解读 附下载7、GBZ185.6-2026 《人工智能 智能体互联 第6部分智能体交互》解读 附下载 
长河君 · 2026/11/6 3:38:10 · 阅读 1.2k 【学习笔记】GB/Z 185.x-2026 人工智能 智能体系列标准解读
这份指导性技术文件只解决一件事让不同厂商的智能体能够互相找到、互相认出、互相调用。它不是又一份技术白皮书而是国内智能体互联的顶层设计——后面六个分标准都从这张总图展开。第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-0105智能体注册、身份码分配、凭证发放、凭证更新与注销——对应“上户口、发证件、办注销”。身份是所有互联动作的前置条件。2描述注册与发现FRAI-0607描述登记回答“我会什么”能力发现回答“谁需要我”。两者合起来构成智能体之间的“招聘市场”。3消息交互FRAI-0809点对点消息与群组消息。一个任务可以由多个智能体分头执行、再汇总结果群组消息就是分头执行的基础设施。4工具调用FRAI-10智能体访问资源域工具的通道补齐从“协商”到“真正干活”的最后一公里。把十组接口串起来一次完整协作跑下来是这样的链路这条链路的价值不在任何单点而在标准化任何一家按 FRAI 实现的智能体理论上都能接入任何一家同样实现的平台互联从此不靠私下对接。04 典型业务场景附录 A 的四个落地样本附录 A 用四个场景演示这套架构怎么用从最简单的注册到最复杂的跨中心协同与具身智能调度。1SCENE 01 · 注册流程2SCENE 02 · 跨中心发现3SCENE 03 · 手机终端协同4SCENE 04 · 机器人协同作业四个场景没有一个是“两个智能体私下拉个群”全部经由标准接口与凭证校验——这正是“体系化互联”与“点对点适配”的分水岭。05 技术对照1标准和 MCP 是什么关系。一句话目标重叠重心不同——MCP 解决“应用如何接工具”GB/Z 185 解决“智能体之间如何成体系地互联”。至少四组能力可以直接对齐。至于 A2A它更接近“智能体之间的对话与任务委派”与系列第 6 部分智能体交互目标一致差异同样落在身份体系与多中心治理上——这恰是国内标准着墨最多的地方。2开发者的现实意义如果你正在用 AgentScope、LangChain4J 这类框架搭 SAAOrchestrator-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、GBZ185.1-2026《人工智能 智能体互联 第1部分总体架构》解读 附下载2、GBZ185.2-2026《人工智能 智能体互联 第2部分身份码》解读 附下载3、GBZ185.3-2026《人工智能 智能体互联 第3部分身份管理》解读 附下载4、GBZ185.4-2026《人工智能 智能体互联 第4部分智能体描述》 解读 附下载5、GBZ185.5-2026 《人工智能 智能体互联 第5部分智能体发现》解读 附下载7、GBZ185.6-2026 《人工智能 智能体互联 第6部分智能体交互》解读 附下载