从工程落地开发看《人工智能 智能体互联》7个国标讲了哪些内容？

近日，国家标准委发布人工智能 智能体互联系列技术指导文件。

这些文件构成了GB/Z 185《人工智能 智能体互联》系列国家标准化指导性技术文件，旨在为国内智能体产业建立统一的技术架构与互操作标准。该标准体系涵盖了从总体架构、身份码识别到身份管理的全生命周期规范，确保不同平台间的智能体能够安全、可靠地识别彼此。此外，文档详细规定了智能体描述、发现机制及交互模式，为智能体之间的协作提供了语言和逻辑基础。最后，标准还定义了工具调用的通用流程，支持智能体与外部软硬件资源的无缝集成。这套标准的发布，对于提升人工智能系统的可组合性和产业协同效能具有重要意义。

从技术实操看，这些技术文件，讲了哪些内容？

一、总体架构

《人工智能 智能体互联 第1部分：总体架构》讲了这些内容。该文件为技术人员提供了一套从整体架构搭建、模块功能划分、API接口对齐，到具体业务流转（如注册、发现、协同计算）的标准化实操指南。

从技术实操视角出发，为开发和部署跨平台、跨架构的智能体互联系统提供了基础的框架蓝图。从工程和技术落地的角度来看，该文件主要讲解了以下四个核心内容：

1. 智能体互联的“5大概念域”划分

从系统部署和架构设计来看，文件将智能体互联环境划分为5个逻辑概念域，明确了各系统模块的边界与信息交互关系：

用户域：任务的发起方和结果接收方（如个人或机构）。

智能体域：具体执行智能体业务逻辑的地方，包含智能体身份维护、描述维护、互联鉴权、智能体交互和工具访问等功能。

管理服务域：负责后端的安全与身份管控，包含身份管理、凭证管理和身份鉴别功能。

互联服务域：为智能体协作提供中间件/平台服务，包含描述管理、智能体发现和消息分发功能。

资源访问域：提供供智能体调用的外部工具和资源服务。

2. 核心功能模块的实操定义

基于上述概念模型，文件给出了具体的功能参考架构，开发者需要根据这些功能模块来构建系统：

身份与安全实操：智能体需要具备“身份维护”和“互联鉴权”功能，依靠管理服务域的分配、鉴别和全生命周期管理，确保互联过程的安全与可信。

注册与发现实操：智能体需将自身的名称、功能等信息按标准格式提交给“描述管理”模块，其他智能体则通过“智能体发现”功能进行能力匹配以实现协作。

交互与工具实操：明确了智能体之间进行信息互通的“智能体交互”模块，以及调用外部资源的“工具访问”模块。

3. 标准化接口设计（FRAI）

为了让不同厂商和平台的模块能对接，文件定义了10个功能参考架构接口（FRAI-01 至 FRAI-10），这是研发人员在API设计时直接对标的规范：

FRAI-01/02/04/05：定义了身份码、凭证申请、同步与交互的接口标准。

FRAI-03：定义了智能体之间互相进行身份鉴权、接受鉴权请求的接口。

FRAI-06/07：规范了智能体描述信息提交、更新、注销以及信息同步的接口。

FRAI-08/09：定义了智能体之间交互的通信接口，其中 FRAI-08 用于点对点模式，FRAI-09 用于通过消息分发实现的群组模式。

FRAI-10：规范了智能体通过工具服务调用外部工具的接口。

4. 典型场景的参考执行流程

文件在附录中提供了4种可以直接作为业务开发参考的典型场景实操流程图：

智能体注册场景：给出了智能体上线前申请身份码、发放凭证、注册描述信息的完整时序逻辑。

跨中心智能体发现场景：展示了跨系统（不同注册服务方）时，如何进行权限申请、信息同步以及能力匹配查询的流程。

手机终端智能体互联场景：展示了手机个人助手如何接收任务，调度终端或云端智能体，寻找协作智能体并进行双向身份鉴别，最终通过群组模式进行交互和调用工具的实操链路。

机器人智能体互联场景：展示了机器人自主感知环境触发任务后，分解任务、寻找协作智能体进行身份鉴别，并采用点对点模式进行信息交互的流程。

二、身份码

《人工智能 智能体互联 第2部分：身份码》从技术实操和系统实现的视角出发，主要规定了智能体身份码的编码规则、分配机制与管理要求。它为智能体在特定系统或跨系统环境中的唯一识别、验证与管理提供了底层的数据标识标准。从工程和技术落地的角度来看，该文件主要讲解了以下四个核心内容：

1. 身份码的统一编码结构（OID体系）

文件规定智能体身份码必须遵循分层结构的OID（对象标识符）体系，各部分从左至右以小数点“.”分隔，标准格式为 `1.2.156.3088.X.XXXXXX.XXXXXX.XXXXXXXXX`。开发者在设计身份解析系统时，需要按以下5个部分进行解析与组装：

智能体身份码OID（前缀）：作为全局标识的起点，固定为 `1.2.156.3088`，分别代表ISO、国家成员体、中国以及智能体节点。

版本号：用于标识编码规则的版本，当前文件约定的版本号为1。

注册服务方：由主管部门分配，代表提供注册服务的机构，标识范围为 1~ZZZZZZ。

注册请求方：由服务方分配给发起注册的组织或个人的标识，范围为 1~ZZZZZZ。

自定义序列号：由注册服务方自行设定和管理，用于保证身份码的唯一性和全生命周期可追溯性。

2. 智能体“本体”与“实例”的实操区分

在业务逻辑中，文件从技术上严格区分了智能体本体（实现特定功能的可执行程序）和智能体实例（由本体创建、具有独立状态和生命周期的执行实体）。

本体标识：当为智能体本体申请身份码时，自定义序列号中的实例序列号部分会以特定字符“0”进行标识。

实例标识：在实际运行中，一个本体可以创建多个实例，系统可基于已获得的本体身份码，进一步为实例申请生成对应的身份码，该过程在技术上通常可以自动化实现。

3. 身份码的分配与生命周期管理规则

为了确保系统的健壮性，文件为开发者和运维人员设定了严格的分配与更新约束条件：

绝对唯一性：一个智能体身份码只能对应一个智能体，且废弃的注册服务方编码严禁重新分配。

核心变更与版本控制：当智能体的核心功能发生变更时，建议重新申请更新本体序列号。而在智能体需要提供多版本共存服务时，系统必须为该智能体本体的不同版本分配不同的序列号。

4. 国际化接入与生态扩展机制

为了支持跨国界的技术互通，文件在附录中为国际智能体获取身份码提供了三种实操接入方案：

国际智能体直接向境内经主管部门认可的服务方申请注册。

海外机构按照规定申请成为合规的身份注册服务方，直接为其生态内的智能体发码。

海外管理体系与中国体系的核心节点（3088节点）建立双边或多边互信协议，在互认框架下采用本标准规则进行发码。

三、身份管理

《人工智能 智能体互联 第3部分：身份管理》从技术实操视角出发，为智能体在互联环境中如何“证明我是我”、如何安全获取授权以及如何进行全生命周期管理提供了详细的技术实现路径。从工程落地的角度来看，该文件重点讲解了以下五个核心实操内容：

1. 解耦的身份管理架构设计

文件设计了一套多角色协同的管理框架，在技术实现上将“身份”与“验证”进行了解耦，主要包含以下实操角色：

智能体身份注册服务方：负责给智能体建账和分配身份码。

智能体凭证发行方：类似于CA（证书授权中心），专门负责生成和签名防篡改的“智能体凭证”。

智能体身份验证方：在智能体互相调用或访问工具时，负责查验凭证有效性的独立实体。

这种解耦设计意味着开发者在搭建系统时，可以将身份分配、密钥签发和实时鉴权作为独立的微服务或系统模块来部署。

2. 身份注册与硬核实操“自证材料”

在智能体首次上线注册时，不仅仅是提交一个名称，系统需要对其进行风险评估并索要硬核的技术证明材料。文件给出了具体可操作的自证材料清单：

系统构成证明：要求提供智能体核心代码、模型和算法的唯一哈希值（Hash）或指纹，以及运行环境（如硬件ID、容器环境）的唯一标识摘要。

行为边界与授权证明：需要结构化声明智能体的用途、权限边界、可访问资源，以及委托方（人或机构）的数字授权签名。

通过这些技术手段，注册服务方能够从代码级和运行环境级确保智能体身份的真实性。

3. 基于硬件安全与公钥基础设施（PKI）的凭证生成

文件明确了智能体凭证的技术底座，强烈建议采用非对称加密和硬件级安全方案：

密钥安全生成：实操中，智能体应借助内置或集成的硬件安全模块（HSM）或可信执行环境（TEE）来生成专属的公私密钥对。私钥必须由智能体在安全区域本地持有，绝不外泄。

公钥证书签发：智能体将公钥提交给凭证发行方，发行方使用国家认可的密码算法签发符合标准的公钥证书作为“智能体凭证”。

4. 动态防伪造的“握手”与身份鉴别流程

当智能体A需要调用智能体B或外部工具时，文件规定了一套严密的动态身份鉴别实操流程（类似SSL/TLS握手）：

动态挑战与过程凭证：为防止重放攻击，验证方会生成一个动态参数（如随机数、时间戳）发给智能体A。智能体A必须使用自己的私钥，将这个随机数与当前场景信息打包签名，生成动态的“过程凭证包”（Process Credential Package）。

多维度验证：验证方不仅要验证数字签名和证书信任链（追溯到根证书），还要实时查验凭证是否被吊销/锁定，并校验凭证中声明的授权范围是否与当前请求的操作意图一致（防止越权操作）。

生成鉴别断言：验证通过后，验证方会生成一份防篡改的“身份鉴别断言”（包含鉴别结果、身份属性摘要、时间戳等），依赖方凭此断言建立安全会话并提供服务。

5. 账户与凭证的全生命周期风控联动

在日常运维中，文件规定了身份的更新、锁定和注销机制，并强调了严格的级联控制逻辑：

核心变更即更新：当智能体的核心代码、功能列表或运行环境发生变化时，技术上应触发身份更新流程。

锁定/注销的强一致性：一旦智能体身份账户被置为锁定状态或注销，系统必须联动其凭证，任何针对该凭证的验证必须立刻返回“无效”状态，切断其互联能力。注销后，系统还需要归档相关的历史版本和审计日志以备追溯。

文件为开发者提供了一套基于公钥证书体系（PKI）、结合硬件安全（HSM/TEE）、采用动态挑战验证机制的智能体安全准入与鉴权开发指南，确保了跨平台智能体互相调用时的绝对安全与可信。

四、智能体描述

《人工智能 智能体互联 第4部分：智能体描述》从技术实操和系统落地的视角出发，主要规定了如何用机器可理解的数据结构来“定义和包装”一个智能体，以及这些描述信息如何在系统中进行注册、上线发布和版本变更。

从工程开发和API设计的角度来看，该文件重点讲解了以下四个核心内容：

1. 智能体描述的基础数据结构设计

文件为开发者定义了一套标准化的智能体描述属性表（类似API的JSON Schema），确保不同厂商的智能体能够互相读懂对方的基本信息和通信规范。实操中，开发者需要为智能体配置以下关键字段：

基础标识与网络访问：包括唯一的身份码（`agentId`）、版本号（`version`），以及决定如何建立连接的访问地址（`accessAddress`）和访问方法（`accessMethod`，如URL、IP或FQDN等）。

通信与安全配置：必须声明对应的认证方式（`authentication`），并可通过辅助功能描述（`capabilities`）来声明是否支持特定的通信机制（例如是否支持SSE流式传输、异步消息或历史状态查询）。

全局数据接口：声明智能体全局默认支持的输入和输出类型（如文本、图像、文件等）。

2. 细粒度的“技能（Skill）”表达模型

智能体的具体能力在技术上被拆解细化为一个个独立的“技能（Skill）”对象。为了让其他智能体或发现服务能够精准调度，开发者需要为每个技能定义一套标准参数：

接口定义：包含独立的技能标识（`skillId`）、输入类型和输出类型。

上下文约束：可以通过“标签（`tags`）”进行业务归类，并提供典型输入输出的“样例（`examples`）”供调用方参考。

环境依赖（`dependencies`）：在实操中，可特别声明该技能运行所需的软硬件环境、配置或物理环境依赖，方便调度系统进行资源评估。

3. 智能体注册与安全审核机制

在智能体接入互联网络时，系统不只是简单录入信息，而是需要执行一套严谨的注册与查验流程：

身份联动验证：智能体提供方提交包含程序包/实例及描述信息的注册请求后，描述管理方必须首先去请求“身份验证方”，验证该智能体身份的真实性（与第3部分的身份鉴别机制联动）。

风险评估与测试：管理方会检查注册信息的合规性，并可以要求智能体提供方补充功能、性能、安全等方面的测试数据或证明材料，评估通过后才会为其生成注册标识。

4. 业务化发布的硬性技术门槛与变更管理

文件从实操层面区分了“注册”（登记信息）和“发布”（上线可被发现）。发布不仅是技术操作，还涉及业务运营配置：

发布证书与运营审核：发布前，智能体需要申请专门的“发布证书”以防篡改。在提交发布请求时，开发者必须附带详细的运营级信息，包括：服务国家/地区、是否为开放测试版、付费要求、权限要求（数据/设备等权限说明）以及电子版权证书。

自主发布机制：除了通过管理方发布，系统也允许智能体提供方通过自主的方式暴露描述信息（例如在自有Web服务器上通过标准化的 `.well-known` 目录地址存放发布文件）。

版本变更与同步发现：当智能体发生变更（如接口升级）时，需重新提交变更审核。变更生效后，描述管理方系统必须将最新的版本信息同步给“智能体发现服务”，以确保网络中的其他智能体搜索到的是最新可用的接口与能力描述。

总结来说，该文件为开发者提供了一本智能体API结构定义及上架发布的“说明书”，规定了智能体应该如何描述自己的接口、功能和运行要求，以及如何通过安全审核并最终发布到网络中供其他智能体调用。

五、智能体发现

《人工智能 智能体互联 第5部分：智能体发现》从技术实操和系统落地的视角出发，主要规定了在多智能体互联网络中，智能体如何寻找、匹配并获取符合业务需求的其他协作智能体。它为开发者实现动态检索或静态配置协作方提供了标准的流程指南。

从工程开发的角度来看，该文件重点讲解了以下核心内容：

1. 两种“双轨制”的发现机制

文件在实操层面确立了两种不同的智能体发现机制，系统在实现时可以任选一种或将两者组合使用，并做好有效衔接：

基于“智能体发现服务”的发现：通过调用中心化的发现平台进行动态查询匹配。

基于“预置信息”的发现：通过读取本地或指定的静态配置直接获取目标智能体信息。

2. 基于“智能体发现服务”的动态调用实操

对于依赖中心化平台进行动态调度的场景，文件规定了详细的接口与流转要求：

接口规范：发现服务应至少提供API（应用程序接口）、GUI（图形用户界面）或LUI（语言用户界面）中的一种查询方式供外部调用。

查询条件组装：开发者在构建发现请求时，必须将“自然语言描述”作为必要条件，同时可以组合使用智能体名称、身份码等其他精确信息进行混合检索。

服务端搜索与权限过滤：发现服务在收到请求后，通过分析意图进行匹配。但在实操中，服务端代码必须执行严格的权限过滤：只能返回配置为“允许发现”的智能体，且必须遵循原智能体的可用性要求（例如是否需要付费、是否仅供特定用户群使用）。

客户端二次校验：请求方智能体在收到结果集后，不能盲目调用，而是必须在本地执行对当前业务的“符合性检查”；如果结果不符合，系统需支持修改查询条件并重新发起重试。

3. 基于“预置信息”的去中心化/静态实操

为了支持高频调用、离线环境或固定协作伙伴的场景，文件允许智能体直接查询本地缓存或预置信息。文件界定了预置信息的四种合法获取途径，供开发者参考实现：

提供者预置：在智能体开发或部署阶段直接硬编码或写入配置文件。

本地缓存机制：使用过往调用发现服务留下的结果缓存。但文件要求开发者必须实现时效性保障机制（例如通过代码周期性向服务方确认缓存智能体的可用性）。

用户配置：留出接口供终端用户手动输入目标智能体信息。

`.well-known`地址：通过访问目标服务器上的标准化Web目录（`.well-known`，常用于存放网站配置、证书等文件）来自动拉取智能体描述。

4. 发现系统与描述管理系统的解耦与数据同步

从系统架构设计来看，文件明确指出“智能体发现服务”和上游的“智能体描述管理方”可以作为完全独立的两个软件系统来实现。这就要求架构师在设计时，必须在两个微服务之间建立可靠的数据同步机制，确保发现服务能够实时拉取到最新发布的智能体描述、变更信息和注销状态，从而保证搜索结果的准确性与时效性。

总结来说，该文件为开发者提供了一套“如何找到其他智能体”的API逻辑与系统架构规范，无论是通过复杂的自然语言动态匹配，还是通过高效的本地缓存与配置读取，都给出了清晰的技术落地路径。

六、智能体交互

《人工智能 智能体互联 第6部分：智能体交互》从技术实操视角出发，主要规定了在多智能体协同作业时，底层通信网络该如何搭建、API数据包该如何封装，以及应用层该采用何种协作架构。

从工程和开发落地的角度来看，该文件重点讲解了以下四个核心内容：

1. 交互前置条件与三大通信模式

文件明确指出，智能体之间必须在完成双向“身份鉴别”后，才能建立连接和交互。在此基础上，规定了三种网络交互拓扑模式：

点对点模式：请求智能体与服务智能体进行一对一的直接通信，这是系统实现时强制要求必须支持的基础模式。

群组模式：类似于群聊，需要通过引入独立的“消息分发功能模块”作为中间件来实现。请求智能体可以创建群组、邀请其他智能体加入或审批加入申请，群内消息由分发模块进行广播。

混合模式：在同一个复杂任务会话中，请求方既通过群组广播消息，同时又与特定智能体建立点对点私聊通道。

2. 结构化的“四层”报文数据模型（API设计依据）

为了保证跨平台智能体能互相听懂，文件将接口数据结构自下而上拆分为四个层级，开发者在设计API时需要直接参考这些字段：

数据（Data）：最小的数据单元，要求必须包含MIME类型（`type`）、元数据结构（`metadata`）和具体载荷（`payload`）。

消息（Message）：通信的传输单元。除了包含Data，还需要封装发送方角色、会话/任务ID。针对大模型常见的流式输出，消息体中专门设计了“消息分块索引（`chunkIndex`）”和“是否结束标志（`lastChunk`）”。

任务（Task）：业务执行单元。必须包含状态机字段（`state`，如进行中、完成、失败等），并支持声明前置“依赖信息”（即完成当前任务需要依赖的其他任务成果）。

会话（Session）：全局上下文容器。由请求方创建并管理，记录了所有参与的服务智能体列表（包含它们的身份码和访问地址）以及历史上下文消息。

3. 底层网络通信的三种代码实现方案（附录A）

针对点对点模式在网络层面的落地，文件给出了三种经典的实操架构，供开发者根据业务延迟和算力要求进行选择：

远程调用方式（短连接请求-响应）：建立连接->发送任务->同步等待处理->返回结果并断开连接。适合耗时短、简单的单次问答交互。

流式实现方式（长连接分批返回）：建立长连接后，服务智能体一边处理一边分批次多次返回结果（类似大模型的打字机效果），任务彻底完成后才断开。适合需要持续数据传输的场景。

通知实现方式（异步回调机制）：请求方发送任务后立即断开连接；服务方在后台慢慢处理，或者等待某个条件触发后，由服务方主动向请求方发起新连接并推送结果。适合高耗时或条件触发的异步场景。

4. 宏观应用层的三种业务协作架构（附录B）

在具体编写多智能体协同应用（如AutoGen类的应用）时，文件提供了三种标准的调度代码逻辑：

主从方式（MapReduce思想）：主智能体接收用户指令，将复杂任务拆解并分发（支持并发分发或串行分发）给多个从智能体，最后由主智能体将各方结果“融合”后返回给用户。

代理协商方式（动态路由与退回机制）：代理智能体将任务指派给下级智能体，如果该智能体评估自身能力不足无法完成，会将任务“交还”给代理，代理重新协商寻找下一个能接单的智能体执行。

任务订阅方式（事件驱动体系）：智能体的执行不是由直接请求发起的，而是观测预设的“触发信号源”（如特定时间、地点或事件）。当条件满足时，才会触发任务分发或直接执行。

总结而言，该文件为开发者提供了一套从底层网络连接方式（长短连接/异步回调）、API报文字段规范，到上层业务逻辑编排（群组分发/主从调度/事件订阅）的完整多智能体协同开发手册。

七、智能体工具调用

《人工智能 智能体互联 第7部分：智能体工具调用》从技术实操和系统对接的视角出发，为基于大语言模型的智能体如何无缝集成和调用外部工具提供了标准化的架构、交互流转机制及API数据规范。从工程落地开发的角度来看，主要讲解了以下四个核心内容：

1. 智能体工具调用的模块化架构设计

文件设计了清晰的系统解耦架构，规范了智能体访问外部资源的各组件角色，开发者在实现时需划分以下逻辑模块：

智能体：作为“大脑”，负责基于大模型理解用户意图，生成具体的工具调用需求，并接收处理最终的执行结果。

工具访问：类似客户端代理（Client），负责与资源访问域交互，将智能体的指令转换为规则化的标准请求发送出去，并将接收到的结果回传。

工具服务：类似服务端网关（Server Gateway），接收来自“工具访问”的请求，根据请求调用相应工具，并将执行结果返回。

工具描述列表：系统维护的清单，详细记录每个工具的具体功能、输入输出参数及规范，作为工具服务进行调度的依据。

工具：具备特定功能、实际执行操作的软硬件系统或程序实体。

2. 三大核心工具生命周期与交互流程

文件明确了智能体与工具服务之间进行协同交互的三个主要时序流转过程：

工具列表获取（初始化）：“工具访问”模块需主动向“工具服务”建立连接并申请工具列表，工具服务进行数据同步后，反馈给智能体当前的可用工具。

工具列表更新（事件驱动）：当工具本身发生更新时，采用提醒机制。工具端向工具服务发送更新提醒，工具服务再通知“工具访问”模块，触发其重新走列表获取流程以完成更新。

工具调用闭环机制：智能体分析任务并选择工具 -> 工具访问模块下发调用需求 -> 工具服务执行调度 -> 结果层层回传。这是一个支持多轮循环的机制，智能体会根据回传结果判断当前任务是否完成；若未完成，则会继续循环上述调用流程，直至符合终止要求。

3. 标准化的API报文字段与数据格式

对于API接口开发者而言，文件直接给出了开发对齐所需的数据字典和结构规范（要求为JSON/对象格式）：

工具属性描述：规定了任何工具在系统注册时必须声明的核心字段，包括 `toolId`（唯一标识）、`toolName`、`toolDescription`、`toolVersion`，以及结构化的入参（`toolInputParam`）和出参（`toolOutputParam`）。

服务初始化与更新通信包：定义了请求和同步时需要包含 `requestType` 或 `syncType`（标识是获取完整列表还是增量更新）、`timestamp`（时间戳）以及相关的工具列表字段（如 `toolSyncList`、`toolUpdateList`）。

工具调用与结果通信包：发起真实调用时，请求体内必须携带 `sessionId` 以维持任务上下文，以及包含入参的 `toolInvokeList`；而响应结果体必须包含 `toolResultList`，其中包括明确的工具执行结果状态码（用于标识成功或失败的原因）。

4. 典型场景的JSON实操代码级示例

为了帮助开发人员快速落地，文件在附录中以常见的“日历工具”为例，给出了详尽的实操参考：

接口能力定义样例：给出了如何使用 JSON 格式描述“添加日程（add_schedule）”和“查询日程（check_schedule）”工具的具体代码结构，包含精确的参数类型约定（如日期要求格式为yyyy-MM-dd）。

全链路报文样例：展示了系统间从申请列表到服务端同步 `toolSyncList`，再到客户端传入 `sessionId` 与具体参数（日期、时间、事件内容）发起 `toolInvokeList` 调用，并最终返回包含状态码 `code: 0` （代表成功）的真实 JSON 报文示例。（文/ResGov人工智能治理研究中心）