人工智能正在从“模型能力竞争”进入“智能体协同竞争”阶段。

     过去，医疗AI更多表现为单点工具：一个报告审核模型、一个危急值提醒系统、一个微生物判读助手、一个科研写作助手、一个LIS查询机器人。它们各自运行、各自调用数据、各自输出结果，真正跨系统、跨平台、跨场景协同并不容易。

      GB/Z 185《人工智能 智能体互联》系列标准的发布，释放出一个清晰信号：未来智能体不能只是“能回答问题”，还要能被识别、被注册、被描述、被发现、被鉴权、被调用，并能与其他智能体和外部工具协同完成任务。

该系列标准共包括七个部分：

• 总体架构

• 身份码

• 身份管理

• 智能体描述

• 智能体发现

• 智能体交互

• 智能体工具调用

这一套标准解决的核心问题，是智能体之间如何实现跨平台、跨架构的互联、互通、互操作。

对于检验医学而言，这不是单纯的信息技术文件，而是未来智慧检验、检验AI平台、实验室自动化系统、LIS、HIS、质控平台、设备中间件、报告审核系统和科研数据平台之间协同运行的基础框架。

未来的检验AI不应只是一个“问答机器人”，而可能是一组智能体：

• 检验申请审核智能体

• 标本流程监控智能体

• TAT预警智能体

• 危急值通知智能体

• 报告审核智能体

• 微生物判读智能体

• 质控异常分析智能体

• 医保合规审核智能体

• 科研数据整理智能体

• 临床沟通智能体

这些智能体如果要真正协同，就必须解决“谁是谁、能做什么、是否可信、怎么找到、怎么交互、能调用哪些工具、调用过程如何追溯”等问题。GB/Z 185系列标准正是在搭建这套底层规则。

01 核心标准梳理

标准1：智能体互联不是简单联网，而是五个域的协同架构

GB/Z 185.1给出了智能体互联的总体架构。智能体互联概念模型包括五个概念域：

• 用户域

• 智能体域

• 管理服务域

• 互联服务域

• 资源访问域

用户域负责发起任务和接收结果。智能体域负责智能体身份维护、描述维护、互联鉴权、交互和工具访问。管理服务域负责身份管理、凭证管理和身份鉴别。互联服务域负责智能体描述管理、智能体发现和消息分发。资源访问域负责提供工具服务。

放到检验科场景中，可以这样理解：

• 医生、检验人员、患者服务中心属于用户域

• 检验报告审核AI、TAT监控AI、危急值AI属于智能体域

• 医院AI身份认证、授权、凭证系统属于管理服务域

• 智能体目录、能力匹配、消息分发平台属于互联服务域

• LIS、HIS、仪器中间件、质控系统、知识库、数据库属于资源访问域

这说明，检验AI建设不能只买一个模型。真正的智慧实验室，需要有统一架构，把用户、智能体、身份、发现、交互和工具调用全部打通。

标准2：每个智能体都需要身份码，不能是“黑盒工具随便接入”

GB/Z 185.2规定了智能体身份码的编码规则、分配与管理要求。

智能体身份码采用分层结构的OID标识体系，固定前缀为：

1.2.156.3088

身份码由智能体身份码OID、版本、身份注册服务方、身份注册请求方、自定义序列号等部分组成。标准要求，一个智能体身份码只能对应一个智能体；废弃的服务方编码不应重新分配；当智能体核心功能发生变更时，宜申请更新智能体本体序列号。

未来，如果多个AI智能体接入LIS、HIS、EMR、设备中间件和质控平台，不能只靠“系统账号+接口权限”粗放管理。每个智能体都应有可识别、可验证、可追溯的身份。

例如：

• 危急值智能体是谁开发的

• 报告审核智能体属于哪个平台

• 微生物判读智能体当前是哪个版本

• 科研数据提取智能体是否被授权访问脱敏数据

• 医保合规智能体是否具备读取收费明细和检验项目编码的权限

身份码的意义在于，让智能体从“系统里的一个功能模块”变成“可治理、可追责、可生命周期管理的数字实体”。

标准3：身份管理强调注册、核验、账户、凭证和鉴别

GB/Z 185.3进一步规定了智能体身份管理框架，覆盖身份注册及核验、身份账户管理、凭证管理和身份鉴别。

标准将智能体身份定义为“可验证的数字身份”。智能体在互联前，需要经过身份注册、风险评估、证明材料提交、身份核验、身份账户建立和凭证发行。

可用于身份核验的材料包括：

• 系统构成相关证明材料

• 委托授权相关证明材料

• 行为边界相关证明材料

• 第三方认证、安全评测、合规评测等其他证明材料

检验AI智能体不是普通办公工具。它可能读取患者检验结果、访问报告、参与危急值通知、调用诊疗知识库，甚至影响临床判断。因此，必须明确：

• 谁授权它运行

• 它能访问哪些数据

• 它能调用哪些工具

• 它的功能边界在哪里

• 它的运行环境是否安全

• 它发生变更后是否重新审核

• 它的凭证是否过期、锁定或注销

检验科在引入AI智能体时，应从“功能验收”转向“身份和权限验收”。尤其涉及患者数据、危急值、报告审核、医保合规和科研数据调用的智能体，必须建立身份账户、凭证、日志和审计机制。

标准4：智能体描述决定“别人能不能找到你、理解你、正确调用你”

GB/Z 185.4规定了智能体描述方法。

智能体描述是机器和人类都能理解的信息，用于说明智能体名称、功能、版本、提供方、访问方式、认证方式、输入输出类型、技能等内容。

标准列出的智能体描述属性包括：

• 身份码

• 名称

• 智能体版本

• 描述

• 提供方

• 访问地址

• 访问方法

• 认证方式

• 辅助功能描述

• 默认输入类型

• 默认输出类型

• 技能

技能属性又包括技能标识、技能名称、技能描述、标签、样例、输入类型、输出类型和运行依赖。

一个“报告审核智能体”，不能只写成“能审核报告”。它至少应描述清楚：

• 支持哪些检验专业：生化、免疫、血液、微生物、分子

• 支持哪些输入：结构化检验结果、历史结果、诊断信息、用药信息

• 输出什么：审核建议、风险等级、复查建议、解释性文字

• 是否支持异步消息、任务状态查询

• 是否可访问患者历史结果

• 是否依赖特定LIS字段

• 是否适用于儿童、孕产妇、肿瘤、ICU等特殊场景

• 是否具备危急值识别能力

• 是否只做提示，不做自动放行

没有清晰描述，智能体发现和协作就会失效。更严重的是，临床可能误用智能体，把一个只适合科研数据整理的工具用于临床报告解释，带来安全风险。

标准5：智能体发现解决“该找谁来完成任务”

GB/Z 185.5确立了智能体发现流程，包括基于智能体发现服务的发现和基于预置信息的发现。

简单理解，智能体发现就是：当一个智能体遇到自己不能独立完成的任务时，能够根据业务需求找到合适的其他智能体。

在检验科场景中，这类需求会非常常见。例如，临床医生询问：“这个患者PCT升高、血培养阴性、CRP持续下降，是否提示感染控制有效？”

一个临床沟通智能体可能需要调用：

• 感染指标解释智能体

• 微生物结果判读智能体

• 抗菌药物知识库工具

• 患者历史检验趋势工具

• 电子病历摘要工具

智能体发现服务需要根据功能、性能、安全约束、状态、付费或授权条件，匹配合适的目标智能体。标准还要求，发现结果可以是0个、1个或多个条目，并且智能体应检查结果是否符合当前业务需要。

未来智慧检验系统不应依赖人工硬编码“固定调用谁”，而应具备基于任务需求的能力匹配机制。

标准6：智能体交互要有模式、内容结构和任务状态

GB/Z 185.6规定了智能体交互模式、内容元素、交互流程和实现参考。

标准提出三种交互模式：

• 点对点模式

• 群组模式

• 混合模式

点对点适合一个智能体与另一个智能体直接协作。群组模式适合多个智能体围绕同一任务进行消息分发和协同。混合模式则同时包含点对点和群组交互。

在内容结构上，标准明确了四类关键元素：

• 数据

• 消息

• 任务

• 会话

医学检验任务往往不是一次问答就能完成，而是一个带上下文、带状态、带多轮协作的过程。

例如，危急值处理可能包括：

• 识别危急值

• 核对标本状态

• 查询历史结果

• 判断是否重复检测

• 联系临床科室

• 记录通知对象

• 确认接收时间

• 生成闭环记录

这不是一个简单“消息”，而是一个任务，有状态、有会话、有多个消息、有最终结果。GB/Z 185.6给出的数据、消息、任务、会话结构，为这类流程型检验AI提供了标准化表达基础。

标准7：工具调用是智能体真正进入业务系统的关键

GB/Z 185.7规定了智能体工具调用总体架构、调用流程和数据格式。

标准将工具定义为“提供特定功能且可被使用的设备、软件或系统”。智能体根据用户请求发起工具调用，与资源访问域中的工具服务建立连接，实现对工具库的访问和调用。工具调用流程包括：

1. 获取工具列表

2. 更新工具列表

3. 选择工具

4. 发送调用请求

5. 工具服务执行

6. 返回执行结果

7. 智能体判断任务是否完成

8. 如未完成，继续循环调用

放到检验科场景中，工具可以是：

• LIS查询工具

• HIS诊断读取工具

• 检验历史趋势工具

• 质控数据分析工具

• 设备状态查询工具

• 危急值通知工具

• 报告生成工具

• 知识库检索工具

• 医保编码匹配工具

• 科研数据库脱敏导出工具

没有工具调用，检验AI只能给出建议；有了规范化工具调用，智能体才能在授权范围内查询数据、整理趋势、生成报告草稿、触发提醒、调用质控分析，并把执行结果返回给用户。

但这也意味着风险更高。工具调用必须有身份鉴别、权限控制、状态返回、失败原因、日志审计和数据边界。

02 对检验的启示

智慧检验科建设要从“AI功能采购”转向“智能体架构设计”

过去采购AI系统，往往关注模型准确率、功能演示、界面体验。GB/Z 185系列标准提示，未来还要关注：

• 是否有智能体身份

• 是否能进行身份鉴别

• 是否能描述能力边界

• 是否支持智能体发现

• 是否能与其他智能体交互

• 是否支持工具调用

• 是否有日志和凭证管理

• 是否支持版本更新和注销

这会改变医院信息化和检验科建设逻辑。

检验AI要有“身份、权限、边界、审计”

检验数据属于敏感医疗数据。任何智能体接入检验系统，都应回答四个问题：

• 它是谁

• 它能做什么

• 它被谁授权

• 它做过什么

尤其是报告审核、危急值、微生物解释、肿瘤标志物解读、分子检测报告解释、医保合规审核等高风险场景，智能体不能以“普通接口账号”模糊接入。

检验科需要提前梳理可被工具化的业务能力

未来智能体调用工具，前提是工具本身要标准化。

检验科可优先梳理以下工具：

• 检验结果查询工具

• 历史结果趋势工具

• 危急值记录工具

• 标本状态查询工具

• TAT统计工具

• 质控规则查询工具

• 参考区间与临床决策阈值工具

• 检验项目医保编码工具

• 报告模板生成工具

• 临床解释知识库工具

这些工具如果能形成标准输入输出，将更容易被智能体安全调用。

检验AI协作场景会从单点走向多智能体

未来一个复杂任务可能由多个智能体完成。

例如“不明原因感染辅助分析”可以由以下智能体协作：

• 病原学智能体分析培养、mNGS、PCR结果

• 炎症指标智能体分析PCT、CRP、IL-6趋势

• 血液学智能体分析白细胞、中性粒、淋巴细胞变化

• 用药智能体分析抗菌药物暴露

• 报告解释智能体整合输出临床沟通建议

这类场景高度依赖智能体发现、交互和工具调用标准。

医院AI治理要纳入智能体生命周期管理

智能体不是一次上线后永久有效。当模型更新、功能扩展、权限变化、运行环境改变、知识库更新、接口调整时，都可能影响安全性和准确性。

因此，检验科和信息部门应建立智能体生命周期管理机制，包括：

• 注册

• 审核

• 发布

• 发现

• 调用

• 监测

• 更新

• 锁定

• 注销

• 审计

这与GB/Z 185系列标准的整体逻辑一致。

GB/Z 185《人工智能 智能体互联》系列标准的意义，不在于给AI多加几个技术名词，而在于为智能体从“单点应用”走向“系统协作”提供底层规则。

检验AI的下一步，不只是回答得更像专家，而是能在标准化、安全化、可追溯的框架下参与真实业务流程。

真正成熟的检验AI，不是“一个模型包打天下”，而是“多智能体协同运行”。

来源和出处：

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.1—2026《人工智能 智能体互联 第1部分：总体架构》

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.2—2026《人工智能 智能体互联 第2部分：身份码》

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.3—2026《人工智能 智能体互联 第3部分：身份管理》

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.4—2026《人工智能 智能体互联 第4部分：智能体描述》

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.5—2026《人工智能 智能体互联 第5部分：智能体发现》

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.6—2026《人工智能 智能体互联 第6部分：智能体交互》

国家市场监督管理总局，国家标准化管理委员会. GB/Z 185.7—2026《人工智能 智能体互联 第7部分：智能体工具调用》

声明：本文仅用于分享，不代表平台立场，如有侵权或涉及版权问题，请尽快联系我们，我们第一时间更正，谢谢！