6月26日市场监管总局正式发布了《人工智能 智能体互联》系列7项国家标准GB/Z 185.1~185.7。这是国内首套多智能体协同运行的国家级规范。说白了以前各家Agent都是方言——华为的Agent调不动阿里的工具字节的Agent找不到腾讯的Agent。这次标准的本质就是给所有智能体统一普通话。我从技术架构角度拆开这7项标准逐层看身份码怎么编、能力怎么描述、发现机制怎么跑、交互协议怎么定、工具调用怎么标准化。最后和Google A2A、Anthropic MCP做个架构层面的对比。7项标准的全景分层先看全貌。7项标准不是零散的而是一个完整的闭环链路标准编号名称定位解决什么问题GB/Z 185.1总体架构顶层设计分层框架和参考点定义GB/Z 185.2身份码信任基础我是谁的唯一标识GB/Z 185.3身份管理生命周期注册→认证→授权→注销GB/Z 185.4智能体描述能力画像我能做什么的标准化表达GB/Z 185.5智能体发现供需匹配“去哪找到合适的Agent”GB/Z 185.6智能体交互协同规则“怎么对话、怎么协商”GB/Z 185.7智能体工具调用执行层“怎么无差别调用外部工具”整个体系按身份标识→能力描述→供需发现→协同交互→工具调用串联。前3项管身份中间1项管能力表达后面3项管协作执行。起草单位包括中国电子标准院、北邮、华为、阿里云、蚂蚁、浪潮、联想、海康、宇树等。归口单位是SAC/TC28人工智能分会。注意一点这次标准以GB/Z指导性技术文件形式发布不是强制GB。官方的说法是产业培育阶段的敏捷标准化安排后续会适时推进身份码相关标准转为强制性国标。AID身份码Agent的数字身份证身份码是整个体系的基石。没有统一身份后面的发现、交互、工具调用全没法做。GB/Z 185.2定义的AIDAgent ID格式如下aid:country:org_type:org_id:agent:agent_type-serial举个例子aid:cn:org:123456789:agent:data-analysis-001用Python定义对应的数据结构fromdataclassesimportdataclass,fieldfromenumimportEnumfromdatetimeimportdatetimefromtypingimportOptionalclassOrgType(Enum):ENTERPRISEent# 企业INSTITUTIONinst# 机构INDIVIDUALind# 个人开发者classAgentStatus(Enum):REGISTEREDregisteredACTIVEactiveSUSPENDEDsuspendedDEREGISTEREDderegistereddataclassclassAgentIdentity:GB/Z 185.2 智能体身份码数据结构country:str# 国家代码如 cnorg_type:OrgType# 组织类型org_id:str# 组织标识兼容统一社会信用代码agent_type:str# Agent类型标识serial:str# 序列号# 扩展字段version:str1.0.0risk_level:int1# 安全风险等级 1-5sim_compat_level:int0# 仿真适配等级物理Agent用propertydefaid(self)-str:returnfaid:{self.country}:{self.org_type.value}:{self.org_id}:agent:{self.agent_type}-{self.serial}# 实例化agentAgentIdentity(countrycn,org_typeOrgType.ENTERPRISE,org_id91110000MA001ABC,agent_typedata-analysis,serial001,risk_level2)print(agent.aid)# 输出: aid:cn:ent:91110000MA001ABC:agent:data-analysis-001AID编码有个关键设计它兼容了现有的统一社会信用代码体系。这意味着企业不用另搞一套身份系统直接复用工商登记的组织编码就行。身份管理GB/Z 185.3则定义了Agent的全生命周期。物理Agent工业机器人、人形机器人等还要额外分三级管控——普通仓储机器人、人形操作机器人、重载工业机器人权限逐级收紧。这里有个实操细节标准里提到仿真平台支持批量注册、批量注销机器人智能体账号。这对于做数字孪生仿真训练的团队来说很实用——一次仿真可能涉及几百个机器人节点逐个注册不现实。ACDL描述语言Agent自报能力清单身份解决我是谁能力描述解决我能干什么。GB/Z 185.4定义了ACDLAgent Capability Description Language采用JSON Schema格式。每个Agent对外暴露一份能力清单其他Agent读取后就能判断这个Agent适不适合处理我的任务。{agent:{aid:aid:cn:ent:91110000MA001ABC:agent:data-analysis-001,name:数据分析智能体,version:2.3.0,capabilities:[{id:cap:sql-query,name:SQL查询分析,description:对结构化数据执行SQL查询并返回分析结果,input:{type:object,properties:{query:{type:string,description:SQL查询语句},datasource:{type:string,description:数据源标识}},required:[query]},output:{type:array,items:{type:object}},constraints:{timeout_ms:30000,max_rows:10000}},{id:cap:report-gen,name:报告生成,description:根据数据生成可视化分析报告,input:{type:object,properties:{data:{type:array},format:{type:string,enum:[pdf,html,png]}},required:[data,format]},output:{type:string,format:binary}}]}}ACDL的核心设计思路是输入输出约束条件三段式。每个能力都明确声明我需要什么样的输入、产出什么样的输出、有什么限制条件超时、行数上限、格式枚举等。对于物理AgentACDL还要求强制包含硬件参数伺服扭矩、减速器精度、视觉传感器参数、仿真兼容引擎类型。这部分是专门为具身智能场景加的。智能体发现多中心化的Agent黄页知道有哪些Agent和能找到合适的Agent是两回事。GB/Z 185.5定义了智能体发现机制。官方提了一个概念叫多中心化智能体发现与能力匹配。相比单一注册中心多中心化的好处是避免性能瓶颈和单点故障——亿级Agent规模下一个注册中心扛不住。用Go实现一个简单的注册中心原型packagemainimport(crypto/ed25519encoding/jsonfmtsynctime)typeAgentIDstruct{Prefixstringjson:prefix// aidOrgTypestringjson:org_typeOrgIDstringjson:org_idAgentTypestringjson:agent_typeSerialstringjson:serial}func(a AgentID)String()string{returnfmt.Sprintf(%s:%s:%s:agent:%s-%s,a.Prefix,a.OrgType,a.OrgID,a.AgentType,a.Serial)}typeCapabilitystruct{IDstringjson:idNamestringjson:nameDescriptionstringjson:descriptionInput json.RawMessagejson:inputOutput json.RawMessagejson:outputConstraintsmap[string]interface{}json:constraints,omitempty}typeAgentManifeststruct{AID AgentIDjson:aidNamestringjson:nameVersionstringjson:versionCapabilities[]Capabilityjson:capabilitiesAuthEndpointstringjson:auth_endpointServiceAddrstringjson:service_addrSignaturestringjson:signatureRegisteredAt time.Timejson:registered_atHeartbeatAt time.Timejson:heartbeat_at}typeRegistrystruct{mu sync.RWMutex agentsmap[string]*AgentManifest// key: AID stringpubKey ed25519.PublicKey privKey ed25519.PrivateKey capacityint}funcNewRegistry(maxCapacityint)*Registry{pub,priv,_:ed25519.GenerateKey(nil)returnRegistry{agents:make(map[string]*AgentManifest),pubKey:pub,privKey:priv,capacity:maxCapacity,}}// Register 注册智能体func(r*Registry)Register(manifest*AgentManifest)error{r.mu.Lock()deferr.mu.Unlock()iflen(r.agents)r.capacity{returnfmt.Errorf(registry full: %d/%d,len(r.agents),r.capacity)}aidKey:manifest.AID.String()if_,exists:r.agents[aidKey];exists{returnfmt.Errorf(agent already registered: %s,aidKey)}manifest.RegisteredAttime.Now()manifest.HeartbeatAttime.Now()r.agents[aidKey]manifestreturnnil}// Discover 按能力标签发现智能体func(r*Registry)Discover(capabilityFilterstring)[]*AgentManifest{r.mu.RLock()deferr.mu.RUnlock()varresults[]*AgentManifestfor_,manifest:ranger.agents{for_,cap:rangemanifest.Capabilities{ifcap.IDcapabilityFilter||cap.NamecapabilityFilter{resultsappend(results,manifest)break}}}returnresults}// Heartbeat 更新心跳时间func(r*Registry)Heartbeat(aid AgentID)error{r.mu.Lock()deferr.mu.Unlock()manifest,exists:r.agents[aid.String()]if!exists{returnfmt.Errorf(agent not found: %s,aid.String())}manifest.HeartbeatAttime.Now()returnnil}funcmain(){registry:NewRegistry(10000)agent:AgentManifest{AID:AgentID{Prefix:aid,OrgType:ent,OrgID:91110000MA001ABC,AgentType:data-analysis,Serial:001,},Name:数据分析智能体,Version:2.3.0,AuthEndpoint:https://agent.example.com/auth,ServiceAddr:grpc://agent.example.com:50051,Capabilities:[]Capability{{ID:cap:sql-query,Name:SQL查询分析},{ID:cap:report-gen,Name:报告生成},},}registry.Register(agent)found:registry.Discover(cap:sql-query)fmt.Printf(发现 %d 个匹配的Agent\n,len(found))// 输出: 发现 1 个匹配的Agent}这只是单节点的原型。实际部署中多中心化意味着多个Registry实例可以联邦式互联每个Registry管理一个子网的Agent跨子网发现通过联邦查询完成。标准里还提到局域网/工厂内网的自动发现能力——异构机器人接入后无需人工配置自动注册到发现层。这对工业场景落地很关键。AIP交互协议Agent之间的通用语言GB/Z 185.6定义的是AIPAgent Interconnection Protocol解决Agent之间怎么对话的问题。AIP消息的基本结构包含几个核心字段{message_id:msg-20260626-001,source_aid:aid:cn:ent:ORG_A:agent:planner-001,target_aid:aid:cn:ent:ORG_B:agent:executor-002,conversation_id:conv-task-12345,message_type:task_request,payload:{task_id:task-12345,action:execute_data_pipeline,parameters:{input_source:s3://data/raw/,output_format:parquet,transform_steps:[filter,aggregate,enrich]}},auth_token:eyJhbGciOiJFZERTQSIs...,timestamp:2026-06-26T10:30:0008:00,ttl_seconds:300}AIP支持的交互模式包括单轮请求-响应、多轮协商任务拆分时的来回讨论、广播-订阅一对多的状态同步。协议层面有几个设计取舍值得关注。AIP采用了和A2A不同的技术路线——A2A基于HTTP/JSON Task生命周期管理AIP则更强调跨域身份认证和分级权限管控。这不是说哪个更好而是定位不同A2A是Google主导的企业级协议偏向单一大平台内部协调AIP是国家标准的跨组织互联规范必须处理跨信任域的认证问题。工具调用标准化一次对接、全域可用GB/Z 185.7解决的是Agent怎么调用外部工具的问题。以前的痛点一个Agent要调用10家不同厂商的API每个API的输入输出格式都不一样对接成本极高。标准化工具调用接口后所有工具对外暴露统一的调用规范Agent不用关心底层是哪家实现的。对于工业场景标准明确将CAE仿真引擎、运动控制算法、力传感数据分析模块定义为标准化可调用工具。云端大模型Agent可以跨厂商调用合规的物理机器人硬件和仿真软件实现大模型→仿真→实体机器人的端到端链路。这部分和前面的ACDL是配合的——ACDL描述我能做什么工具调用标准定义怎么让我做。与A2A、MCP的架构差异维度AIP国标A2AGoogleMCPAnthropic主导方市场监管总局/SAC/TC28GoogleAnthropic文件性质国家标准化指导性技术文件企业开源协议企业开源协议身份体系AID全球唯一编码兼容统一社会信用代码无统一身份标准无统一身份标准发现机制多中心化联邦发现Agent Card 中心化注册无标准化发现机制安全认证分级权限全程追溯ed25519签名OAuth 2.0基于API Key物理Agent支持明确覆盖机器人、仿真平台有限不涉及适用范围跨组织、跨厂商、跨域企业内部/合作伙伴Claude生态强制程度未来可能转强制GB自愿采用自愿采用核心差异在三个方面身份可信度。AIP从底层设计了ed25519签名分级权限全程追溯这是跨组织互联的基础设施级需求。A2A和MCP在这方面基本空白——它们更适用于单一信任域内的协作。物理Agent覆盖。AIP明确把人形机器人、工业机械臂、仿真平台纳入标准体系GB/Z 185.2甚至要求身份码包含硬件厂商、关节执行器型号、仿真适配等级等字段。A2A和MCP目前都不涉及物理Agent。架构治理模式。AIP是多中心化的联邦架构A2A偏向中心化注册类似DNSMCP则没有标准化发现机制。开发者适配路径标准发布后开发者最关心的问题是我该怎么适配。目前AIP协议已有开源实现——中国电子技术标准化研究院联合北邮推进了AIP开源代码研发。官方也发起了先锋计划百余家企业参与标准试点验证。适配路径大致分三步第一步接入身份体系。按GB/Z 185.2生成AID身份码通过身份管理接口完成注册。如果已有统一社会信用代码直接复用即可。第二步发布能力描述。按ACDL格式编写能力清单参考上面的JSON示例注册到发现层。第三步对接交互协议。实现AIP消息格式解析支持task_request/task_response/task_error等基本消息类型。工具类Agent还需要按GB/Z 185.7标准化输入输出接口。适用边界需要说清楚当前7项标准是GB/Z指导性不是强制GB。企业可以自愿采用但如果要做政企采购、跨组织协作遵循标准会大幅降低对接成本。官方已明确适时推进身份码相关标准转为强制性国标。替代方案方面如果你的Agent只在单一平台内部运行比如都在阿里云生态内用A2A或者平台自有协议也够用。但一旦涉及跨厂商、跨组织、特别是物理Agent场景AIP的标准化价值就体现出来了。一个踩坑提醒目前标准刚发布各厂商的适配实现参差不齐。建议先在测试环境跑通注册→发现→交互→工具调用的全链路再上生产。官方提供了求索评测基准体系可以用来做标准适配的合规性检测。以上就是《人工智能 智能体互联》7项国标的技术架构拆解。核心就一句话中国Agent产业从各自为战进入标准互通阶段身份码是基石ACDL是名片AIP是语言工具调用是手脚。