《人工智能 智能体互联》7项国标架构拆解：AID身份码、ACDL描述语言与AIP协议技术实现

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定义的AID（Agent ID）格式如下：

aid:<country>:<org_type>:<org_id>:agent:<agent_type>-<serial>

举个例子：

aid:cn:org:123456789:agent:data-analysis-001

用Python定义对应的数据结构：

from dataclasses import dataclass, field
from enum import Enum
from datetime import datetime
from typing import Optional

class OrgType(Enum):
    ENTERPRISE = "ent"       # 企业
    INSTITUTION = "inst"     # 机构
    INDIVIDUAL = "ind"       # 个人开发者

class AgentStatus(Enum):
    REGISTERED = "registered"
    ACTIVE = "active"
    SUSPENDED = "suspended"
    DEREGISTERED = "deregistered"

@dataclass
class AgentIdentity:
    """GB/Z 185.2 智能体身份码数据结构"""
    country: str              # 国家代码，如 "cn"
    org_type: OrgType         # 组织类型
    org_id: str               # 组织标识（兼容统一社会信用代码）
    agent_type: str           # Agent类型标识
    serial: str               # 序列号
    
    # 扩展字段
    version: str = "1.0.0"
    risk_level: int = 1       # 安全风险等级 1-5
    sim_compat_level: int = 0 # 仿真适配等级（物理Agent用）
    
    @property
    def aid(self) -> str:
        return f"aid:{self.country}:{self.org_type.value}:{self.org_id}:agent:{self.agent_type}-{self.serial}"

# 实例化
agent = AgentIdentity(
    country="cn",
    org_type=OrgType.ENTERPRISE,
    org_id="91110000MA001ABC",
    agent_type="data-analysis",
    serial="001",
    risk_level=2
)
print(agent.aid)
# 输出: aid:cn:ent:91110000MA001ABC:agent:data-analysis-001

AID编码有个关键设计：它兼容了现有的统一社会信用代码体系。这意味着企业不用另搞一套身份系统，直接复用工商登记的组织编码就行。

身份管理（GB/Z 185.3）则定义了Agent的全生命周期。物理Agent（工业机器人、人形机器人等）还要额外分三级管控------普通仓储机器人、人形操作机器人、重载工业机器人，权限逐级收紧。

这里有个实操细节：标准里提到仿真平台支持"批量注册、批量注销"机器人智能体账号。这对于做数字孪生仿真训练的团队来说很实用------一次仿真可能涉及几百个机器人节点，逐个注册不现实。

ACDL描述语言：Agent自报能力清单

身份解决"我是谁"，能力描述解决"我能干什么"。

GB/Z 185.4定义了ACDL（Agent 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的核心设计思路是"输入输出+约束条件"三段式。每个能力都明确声明：我需要什么样的输入、产出什么样的输出、有什么限制条件（超时、行数上限、格式枚举等）。

对于物理Agent，ACDL还要求强制包含硬件参数：伺服扭矩、减速器精度、视觉传感器参数、仿真兼容引擎类型。这部分是专门为具身智能场景加的。

智能体发现：多中心化的"Agent黄页"

知道"有哪些Agent"和"能找到合适的Agent"是两回事。GB/Z 185.5定义了智能体发现机制。

官方提了一个概念叫"多中心化智能体发现与能力匹配"。相比单一注册中心，多中心化的好处是避免性能瓶颈和单点故障------亿级Agent规模下，一个注册中心扛不住。

用Go实现一个简单的注册中心原型：

package main

import (
    "crypto/ed25519"
    "encoding/json"
    "fmt"
    "sync"
    "time"
)

type AgentID struct {
    Prefix   string `json:"prefix"`    // "aid"
    OrgType  string `json:"org_type"`
    OrgID    string `json:"org_id"`
    AgentType string `json:"agent_type"`
    Serial   string `json:"serial"`
}

func (a AgentID) String() string {
    return fmt.Sprintf("%s:%s:%s:agent:%s-%s",
        a.Prefix, a.OrgType, a.OrgID, a.AgentType, a.Serial)
}

type Capability struct {
    ID          string                 `json:"id"`
    Name        string                 `json:"name"`
    Description string                 `json:"description"`
    Input       json.RawMessage        `json:"input"`
    Output      json.RawMessage        `json:"output"`
    Constraints map[string]interface{} `json:"constraints,omitempty"`
}

type AgentManifest struct {
    AID           AgentID      `json:"aid"`
    Name          string       `json:"name"`
    Version       string       `json:"version"`
    Capabilities  []Capability `json:"capabilities"`
    AuthEndpoint  string       `json:"auth_endpoint"`
    ServiceAddr   string       `json:"service_addr"`
    Signature     string       `json:"signature"`
    RegisteredAt  time.Time    `json:"registered_at"`
    HeartbeatAt   time.Time    `json:"heartbeat_at"`
}

type Registry struct {
    mu       sync.RWMutex
    agents   map[string]*AgentManifest // key: AID string
    pubKey   ed25519.PublicKey
    privKey  ed25519.PrivateKey
    capacity int
}

func NewRegistry(maxCapacity int) *Registry {
    pub, priv, _ := ed25519.GenerateKey(nil)
    return &Registry{
        agents:   make(map[string]*AgentManifest),
        pubKey:   pub,
        privKey:  priv,
        capacity: maxCapacity,
    }
}

// Register 注册智能体
func (r *Registry) Register(manifest *AgentManifest) error {
    r.mu.Lock()
    defer r.mu.Unlock()

    if len(r.agents) >= r.capacity {
        return fmt.Errorf("registry full: %d/%d", len(r.agents), r.capacity)
    }

    aidKey := manifest.AID.String()
    if _, exists := r.agents[aidKey]; exists {
        return fmt.Errorf("agent already registered: %s", aidKey)
    }

    manifest.RegisteredAt = time.Now()
    manifest.HeartbeatAt = time.Now()
    r.agents[aidKey] = manifest
    return nil
}

// Discover 按能力标签发现智能体
func (r *Registry) Discover(capabilityFilter string) []*AgentManifest {
    r.mu.RLock()
    defer r.mu.RUnlock()

    var results []*AgentManifest
    for _, manifest := range r.agents {
        for _, cap := range manifest.Capabilities {
            if cap.ID == capabilityFilter || cap.Name == capabilityFilter {
                results = append(results, manifest)
                break
            }
        }
    }
    return results
}

// Heartbeat 更新心跳时间
func (r *Registry) Heartbeat(aid AgentID) error {
    r.mu.Lock()
    defer r.mu.Unlock()

    manifest, exists := r.agents[aid.String()]
    if !exists {
        return fmt.Errorf("agent not found: %s", aid.String())
    }
    manifest.HeartbeatAt = time.Now()
    return nil
}

func main() {
    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定义的是AIP（Agent 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:00+08: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（国标）	A2A（Google）	MCP（Anthropic）
主导方	市场监管总局/SAC/TC28	Google	Anthropic
文件性质	国家标准化指导性技术文件	企业开源协议	企业开源协议
身份体系	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偏向中心化注册（类似DNS），MCP则没有标准化发现机制。

开发者适配路径

标准发布后，开发者最关心的问题是"我该怎么适配"。

目前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是语言，工具调用是手脚。