着智能体应用逐步从单一系统内部使用，向跨平台、跨系统协同发展，如何准确识别参与互联的智能体，成为智能体互联首先需要解决的基础问题。在上一篇对GB/Z 185.1—2026《人工智能 智能体互联 第1部分：总体架构》的解读中，我们介绍了智能体互联的概念模型、功能参考架构以及主要接口关系。其中，智能体身份维护、身份管理、身份鉴别等功能，共同构成了智能体互联中的身份基础。
作为系列标准的第二部分，GB/Z 185.2—2026《人工智能 智能体互联 第2部分：身份码》进一步聚焦于智能体的身份标识，规定了智能体身份码的编码规则、分配与管理要求，为智能体在特定系统环境或跨系统环境中的识别、验证与管理提供统一的编码参考。
01
标准的定位与主要内容
GB/Z 185.2—2026是规范类指导性技术文件，适用于智能体互联中智能体身份码的制定与应用。第2部分集中回答了三个基础问题：
第一，智能体身份码按照什么结构进行编码
第二，身份码中的各级标识由谁分配
第三，身份码在变更、版本共存及废弃等情况下如何管理
从GB/Z 185系列标准的整体安排来看，第1部分给出了智能体互联的总体架构，第2部分解决智能体的身份标识问题，第3部分则将在此基础上进一步规范身份管理框架和全生命周期过程。
因此，身份码可以理解为智能体进入互联体系后，用于表明“它是谁”的基础标识。至于如何申请、更新和注销身份，如何发放身份凭证，以及如何开展身份鉴别，则需要结合后续身份管理标准。我们会持续为大家进行标准解读，欢迎关注！
02
理解身份码前，需要区分几个关键对象
标准在术语和定义中，对智能体本体、智能体实例、身份注册服务方和身份注册请求方等概念进行了界定。
1.智能体本体
智能体本体，是指实现特定功能、与智能体描述配套的可执行程序。
一般情况下，智能体本体通过智能体注册服务进行注册，完成注册后，可以根据实际任务需要创建相应的智能体实例。
可以将其理解为智能体的功能主体或可执行程序本身。例如，一个已经开发完成、具备特定业务处理能力的智能体程序，可以作为一个智能体本体进行注册。
2.智能体实例
智能体实例，是由智能体本体创建、具有独立状态和生命周期的实体。
同一个智能体本体可以创建多个智能体实例。虽然这些实例来源于同一个本体，但由于其运行状态和生命周期相互独立，因此需要在身份标识上加以区分。
3.智能体身份注册服务方
智能体身份注册服务方，是处理智能体身份注册请求、执行身份核验并管理智能体身份账户的实体。
标准明确，智能体互联环境中可能存在多个身份注册服务方。身份注册服务方应为组织，其标识由主管部门分配。
4.智能体身份注册请求方
智能体身份注册请求方，是向身份注册服务方发起智能体身份注册请求，并承担相应责任的实体。
身份注册请求方可以是组织，也可以是个人，其标识由对应的身份注册服务方分配。
这里需要注意，身份注册服务方与身份注册请求方是两个不同角色：前者负责提供注册、核验和管理服务，后者负责提交注册申请并承担相应责任。
5.智能体身份码
智能体身份码，是由智能体身份注册服务方分配给智能体，用于在特定系统环境或跨系统环境中对智能体进行识别、验证与管理的标识符。
因此，智能体身份码并不等同于系统内部自行设置的名称、账号、数据库主键或普通业务编号，而是按照统一规则形成的层级化标识。
03
智能体身份码采用怎样的编码结构？
标准规定，智能体身份码遵循GB/T 26231的有关规定，采用分层结构的对象标识符，即OID标识体系。
身份码由多层节点标识符依次组成，每位标识符使用阿拉伯数字“0～9”或英文字母“A～Z”表示，英文字母不区分大小写，中间不留空格。不同组成部分之间使用小数点“.”分隔。
身份码从左至右依次由以下五个部分组成：
1)智能体身份码OID
2)智能体身份码版本
3)智能体身份注册服务方
4)智能体身份注册请求方
5)自定义序列号
3.1 智能体身份码OID
智能体身份码前缀由OID标识管理部门统一分配和管理，作为智能体身份码在全局标识体系中的根标识，也是解析智能体身份信息的起点。
标准规定，智能体身份码OID固定为：1.2.156.3088
根据标准附录C给出的示例：
- “1”表示ISO；
- “2”表示国家成员体；
- “156”表示中国；
- “3088”表示智能体节点。
也就是说，后续身份码版本、注册服务方、注册请求方及智能体序列号，均在这一根标识基础上逐级扩展。
3.2 智能体身份码版本
身份码版本用于区分智能体身份码编码规则的版本。
其标识范围为“1～Z”，可标识35个版本，当前文件约定的身份码版本号为“1”。
将版本号纳入身份码结构，有利于在编码规则发生调整时区分不同版本的身份码。对于系统设计而言，也需要避免将身份码仅作为一串无法解析的普通文本保存，而应考虑其版本字段及相应的识别规则。
3.3 智能体身份注册服务方
一般情况下，智能体互联环境中可能存在多个身份注册服务方。
结合身份码前缀中的国家或地区代码，可以进一步标识具体的身份注册服务方。其身份码由主管部门分配，标识范围为“1～ZZZZZZ”，可标识约20亿个服务方。
这一层级主要用于说明：该智能体身份由哪一个身份注册服务方负责注册和管理。
3.4 智能体身份注册请求方
每个身份注册请求方的标识，由其所对应的身份注册服务方分配。
身份注册请求方可以是组织，也可以是个人，标识范围同样为“1～ZZZZZZ”，可标识约20亿个请求方。
通过这一层级，可以进一步识别具体由哪个组织或个人发起了智能体身份注册申请。
3.5 自定义序列号
自定义序列号由智能体身份注册服务方自行设定，也可以按照业务种类或其他规则进行编号，但应保证唯一性和全生命周期的可追溯性。
标准进一步将自定义序列号细分为两个层次。
一是智能体本体序列号。身份注册服务方审核通过后，宜为智能体分配一个用于区分智能体本体的序列号。
二是智能体实例序列号。对于由智能体本体创建的实例，身份注册服务方宜分配相应的实例序列号。当注册对象为智能体本体本身时，其实例序列号使用特定字符“0”表示。
智能体本体序列号和实例序列号宜采用“1～ZZZZZZZZZ”的标识范围，分别可标识约101万亿个本体和实例。
这一设计体现了标准对智能体本体与运行实例的分别管理。同一个本体可以创建多个实例，但不同实例具有独立的状态和生命周期，因此需要通过不同的实例序列号进行区分。
04
一串智能体身份码应该如何识读？
标准附录C给出了一个完整的身份码示例：
1.2.156.3088.1.1.34C2.478BDF.3GF546
按照标准说明，这一身份码可以逐级解析为：
05
智能体身份码如何分配和管理？
标准主要提出五项要求：
- 废弃编码不得复用：已废弃的智能体身份注册服务方编码不应重新分配，以避免影响历史身份码的识别和追溯。
- 核心功能变更宜更新本体序列号：当智能体本体的核心功能发生变化时，注册请求方宜申请新的本体序列号。标准未明确“核心功能变更”的具体判定条件，实际应用中需结合项目制度确定。
- 多版本共存应分别编码：同一智能体存在多个版本同时提供服务时，应为不同版本分配不同的本体序列号。
- 身份码与智能体一一对应：一个智能体身份码只能对应一个智能体，不同本体或实例不应共用同一身份码。
- 服务方承担序列号管理责任：自定义序列号可根据业务规则设置，但其定义、分配和管理由智能体身份注册服务方负责，并应保证唯一性和可追溯性。
06
身份注册服务方、请求方、本体和实例之间是什么关系？
为帮助读者理解身份码涉及的不同实体，标准附录A给出了相关实体之间的关联关系。
其中，“身份注册服务方”向“身份注册请求方”提供身份注册、身份核验和身份管理服务；“身份注册请求方”向“服务方”提交智能体本体或者智能体实例的注册申请。
对于智能体本体和实例，标准给出了两种典型情况。
第一种情况，是“身份注册请求方”先为“智能体本体”申请身份码。本体注册完成并创建实例后，再基于已经获得的本体身份码，为相应实例申请独立的身份码。该过程一般可以自动化实现。
第二种情况，是“身份注册请求方”直接为“智能体实例”提交注册申请。审核通过后，身份注册服务方先为相应的智能体本体分配身份码，再基于本体身份码为实例生成和分配对应的身份码。
无论采用哪种方式，智能体实例均来源于相应的智能体本体，本体身份与实例身份之间需要保持明确的关联关系。
07
国际智能体如何获取身份码？
标准附录B列出了国际智能体获取智能体身份码的三种方式。
- 国际智能体可以向经主管部门认可的智能体身份注册服务方申请注册，获得智能体身份码。
- 海外机构可以依据本文件及相关管理规定，向主管部门申请成为身份注册服务方。获得批准后，该机构取得由主管部门分配的唯一身份注册服务方身份码，并为国际智能体提供身份注册服务。
- 海外机构可以在所在国家或地区建立智能体身份管理体系，并通过双边或多边协议，与本文件体系的核心节点建立互信互认关系。在互认框架下，相关体系按照本文件的身份码编码规则，为其下属国际智能体分配身份码。
对信息化项目建设工作的启示
从信息化项目建设角度看，智能体身份码虽然最终表现为一串编码，但要将标准要求落实到系统中，通常不只是增加一个数据字段。
项目方案和需求设计中，需要明确身份注册服务方和身份注册请求方的角色，区分智能体本体与智能体实例，设计本体序列号和实例序列号的生成、分配及关联机制，并考虑身份码版本、唯一性校验、多版本共存和历史追溯等内容。
对于智能体平台、智能体管理系统或多智能体协同系统，相关建设内容可能涉及身份码生成与解析、身份注册服务对接、本体与实例关系管理、身份码唯一性校验、多版本身份区分以及变更和历史记录管理等功能。具体项目是否需要建设独立的身份码管理模块，或通过已有平台和接口服务实现，则需要结合项目范围和总体架构确定。
这些功能一旦纳入项目建设范围，就会进一步转化为软件功能设计、接口开发、数据结构设计、联调测试和运行管理等具体工作量。对于建设单位而言，如何在项目立项和预算申报阶段准确识别这些功能，并合理测算项目规模与造价，是项目投资管理中需要同步考虑的问题。
针对信息化项目功能范围难梳理、软件规模难量化、造价依据难匹配等问题，可以借助已经落地的数字化工具提高测算效率。例如，“软件造价喵”集成了近10年中国软件行业基准数据及60余项省市级软件造价标准，支持上传可研方案、需求文件或设计文档，辅助识别项目功能点并生成造价评估报告，可用于预算编制、财政评审、结算审计等环节。
09
结语
GB/Z 185.2—2026《人工智能 智能体互联 第2部分：身份码》围绕智能体身份标识，规定了身份码的编码结构、分配规则和管理要求，明确了身份注册服务方、身份注册请求方、智能体本体和智能体实例等相关对象及其关系，为智能体在特定系统或跨系统环境中的识别、验证和管理提供了统一参考。
对于相关信息化项目而言，身份码不仅是一项编码规则，还涉及注册主体、本体与实例关系、版本管理及全生命周期追溯等建设内容。后续，本账号将继续围绕GB/Z 185《人工智能 智能体互联》系列标准开展解读。
