2026 年 7 月 3 日，我国正式发布《人工智能 智能体互联》系列 7 项国家标准，标准编号为 GB/Z 185-2026。这是国内首套覆盖智能体全生命周期互联互通的国家级标准体系。它关注的重点不是单个智能体如何生成一段漂亮回答，而是多个智能体、多个平台、多个行业系统之间如何发现彼此、理解能力、交换任务、协同执行，并在治理约束下运行。
参与研制的单位覆盖产学研用多方，包括中国电子技术标准化研究院、北京邮电大学、华为、清华大学、阿里云、中国移动、中兴通讯、中国联通、中国电信等 70 余家机构。这种阵容本身说明了一个问题：智能体互联不是某一家平台的私有 API 能完全解决的，它更像操作系统、网络协议和行业应用之间的共同接口。
标准真正瞄准的是智能体的“互联互通层”
过去很多智能体项目的集成方式很直接：给模型一个工具列表，写几个函数调用，再接上企业系统。单个应用里这样做没问题，但一旦进入跨部门、跨厂商、跨云、跨行业的场景，问题会迅速变复杂。
典型问题包括：
- 一个智能体如何声明自己能做什么？
- 调用方如何知道它支持哪些输入、输出、权限和约束？
- 多个智能体之间如何传递任务状态，而不是只传一段自然语言？
- 出错、拒绝、超时、降级时如何表达？
- 生命周期里从注册、发现、调用、监控到下线，如何形成一致机制？
GB/Z 185-2026 的关键词是“全生命周期互联互通”。这意味着标准不只关心一次调用，而是把智能体从创建、接入、交互、协作、治理到退出的过程纳入统一框架。对于工程团队来说，这比“又一个 agent demo”更重要，因为真实系统的问题往往发生在边界上：权限边界、数据边界、责任边界和供应商边界。
为什么需要国家级标准，而不只是 SDK
SDK 解决的是“我怎么调用你”。标准要解决的是“不同实现之间如何稳定协作”。
在智能体互联场景里，单靠 SDK 会遇到几个明显限制：
- 厂商绑定：能力描述、鉴权、工具协议、事件格式都可能绑定某个平台。
- 语义不一致：同样叫
task_status，不同系统可能有完全不同的状态机。 - 运维困难：日志、审计、追踪、错误码没有统一约定，跨系统排障成本很高。
- 安全责任模糊：智能体可以调用外部工具后，权限、授权、数据流向必须可检查。
国家标准的价值不在于替代所有实现细节，而在于给产业协作划出共同语义。企业仍然可以使用自己的模型、编排框架、云服务和业务插件，但在智能体登记、能力发现、任务交换、状态表达、治理接口等层面，应该尽量对齐一套可互认的规则。
可以这样实践：先给智能体做一张“能力卡”
以下示例不是 GB/Z 185-2026 的原文格式，而是一个可以落地改造的最小实践：用 YAML 描述智能体身份、能力、输入输出、权限和运行约束。团队可以把它作为内部 agent registry 的起点，等标准文本或配套实现细则明确后，再映射到正式字段。
把下面内容保存为 agent-card.yaml：
agent_id: invoice-audit-agent
name: Invoice Audit Agent
version: 1.0.0
owner: finance-platform-team
lifecycle_status: active
capabilities:
- capability_id: invoice.validate
description: Validate invoice fields against company reimbursement rules.
input_schema:
type: object
required:
- invoice_id
- amount
- seller_tax_id
properties:
invoice_id:
type: string
amount:
type: number
seller_tax_id:
type: string
output_schema:
type: object
required:
- decision
- reasons
properties:
decision:
type: string
enum: [approved, rejected, manual_review]
reasons:
type: array
items:
type: string
interfaces:
http:
endpoint: http://localhost:8080/tasks
auth: bearer_token
governance:
data_classification: internal
allowed_callers:
- reimbursement-service
audit_required: true
max_task_duration_seconds: 30
下面用一个很小的 Python 服务模拟“智能体接收任务”。运行前需要安装依赖：
python -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn pyyaml
保存为 agent_server.py：
from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
from typing import List, Optional
import yaml
app = FastAPI(title="Agent Interconnect Demo")
with open("agent-card.yaml", "r", encoding="utf-8") as f:
AGENT_CARD = yaml.safe_load(f)
class InvoiceTask(BaseModel):
task_id: str
caller: str
invoice_id: str
amount: float
seller_tax_id: str
class AgentResult(BaseModel):
task_id: str
status: str
decision: str
reasons: List[str]
@app.get("/.well-known/agent-card")
def get_agent_card():
return AGENT_CARD
@app.post("/tasks", response_model=AgentResult)
def run_task(task: InvoiceTask, authorization: Optional[str] = Header(default=None)):
if authorization != "Bearer demo-token":
raise HTTPException(status_code=401, detail="missing or invalid token")
allowed_callers = AGENT_CARD["governance"]["allowed_callers"]
if task.caller not in allowed_callers:
raise HTTPException(status_code=403, detail="caller is not allowed")
reasons = []
decision = "approved"
if task.amount <= 0:
decision = "rejected"
reasons.append("amount must be greater than zero")
if len(task.seller_tax_id) < 8:
decision = "manual_review"
reasons.append("seller tax id looks incomplete")
if not reasons:
reasons.append("invoice passed basic validation")
return AgentResult(
task_id=task.task_id,
status="completed",
decision=decision,
reasons=reasons,
)
启动服务：
uvicorn agent_server:app --reload --port 8080
另开一个终端，先查看能力卡：
curl http://localhost:8080/.well-known/agent-card
再提交一个任务：
curl -X POST http://localhost:8080/tasks \
-H 'Authorization: Bearer demo-token' \
-H 'Content-Type: application/json' \
-d '{
"task_id": "task-001",
"caller": "reimbursement-service",
"invoice_id": "INV-2026-0001",
"amount": 1280.5,
"seller_tax_id": "91310000MA1K000000"
}'
这个例子故意很小，但它体现了智能体互联标准落地时常见的几个工程动作：能力可发现、接口可调用、输入输出有结构、调用方受控、结果状态可追踪。真正的生产系统还需要补上签名、审计日志、任务队列、幂等键、分布式追踪、数据脱敏和策略引擎。
工程团队现在应该关注什么
GB/Z 185-2026 是推荐性国家标准，从工程采用角度看，不必等所有工具链成熟后才行动。更现实的做法是先整理现有智能体系统里的“互联资产”。
可以从这份清单开始：
- 智能体是否有稳定 ID、版本号、负责人和生命周期状态？
- 能力是否用结构化 schema 描述，而不是只写在提示词里？
- 调用接口是否区分任务提交、状态查询、结果回传和错误处理？
- 权限是否绑定到调用方、数据范围和工具范围？
- 任务执行过程是否能审计，包括输入摘要、工具调用、输出、失败原因？
- 下线或升级智能体时，调用方是否能感知兼容性变化？
风险也要说清楚。标准发布不等于所有产品马上兼容；不同厂商对标准的实现深度可能不同；早期团队如果过度抽象，也可能把简单场景做重。比较稳的路线是：内部先统一元数据、schema、状态码和审计模型，把对外协议适配层做薄。这样标准生态成熟后，迁移成本会低很多。
结语：把智能体当成网络里的服务，而不是孤立的聊天框
GB/Z 185-2026 的意义，在于把“智能体”从应用功能推向产业基础设施。开发者要改变的不是某一行提示词，而是系统设计视角：智能体需要身份、能力描述、协议边界、治理规则和生命周期管理。
如果你的团队已经在做多智能体协作、企业工具调用、行业大模型平台或跨云 AI 应用，现在就应该开始盘点接口和元数据。未来真正难的不是让一个智能体回答问题，而是让一组智能体在可控、可审计、可替换的前提下完成工作。