6.5 智能体间互操作协议

当一个系统里存在多个智能体（来自不同团队、不同系统、甚至不同组织）时，仅靠“把提示词写好”无法让它们稳定协作。你需要一类智能体间互操作协议，把“发现、委派、回传、审计”做成可移植的接口。

6.5.1 为什么需要互操作协议

多智能体协作的常见挑战包括：

• 点对点集成爆炸：每新增一个智能体，都要为既有智能体增加对接逻辑。

• 供应商/实现锁定：更换智能体实现会牵连大量调用方。

• 通信不一致：消息格式、任务状态与错误语义各说各话。

• 安全碎片化：身份认证、授权与审计分散，治理困难。

• 不可发现：上游智能体无法“自动找到”合适的下游能力。

互操作协议的目标是提供一个统一层，让智能体能够以一致方式：

1. 发现对方的能力

2. 提交任务并追踪状态

3. 在长任务中持续回传进度

4. 在安全边界内传递上下文并完成审计

6.5.2 两类协议：智能体互操作与工具连接

工程上常见两类“连接协议”，解决的问题不同：

维度	工具连接协议	智能体互操作协议
连接对象	智能体 ↔ 工具/数据源	智能体 ↔ 智能体
协议目的	让智能体获得外部能力	让智能体协作完成任务
交互粒度	原子操作与资源访问	任务级工作单元与状态机
核心抽象	资源、工具、提示模板	能力描述、任务、进度、审计
生命周期	请求-响应为主	可能跨秒/分钟/小时的任务流

6.5.3 协议能力结构

一个实用的智能体互操作协议通常包含以下组件。

1. 能力描述

每个智能体需要发布一个“能力描述文档”，用于：

• 说明智能体身份与用途

• 列出可接受的任务类型

• 给出输入/输出结构（例如 JSON Schema）

• 声明认证方式与调用端点

示意如下：

{
  "name": "HR Assistant",
  "description": "处理员工入职、离职、请假等事务",
  "capabilities": [
    {
      "name": "onboard_employee",
      "description": "处理新员工入职流程",
      "inputSchema": {"type": "object", "properties": {"employee_name": {"type": "string"}}},
      "outputSchema": {"type": "object", "properties": {"employee_id": {"type": "string"}}}
    }
  ],
  "authentication": {"type": "oauth2"},
  "endpoint": "<endpoint>"
}

2. 任务模型

智能体之间的协作应该以“任务”为核心单元：

• id：任务唯一标识

• type：对应能力类型

• status：任务状态机（如 queued / in_progress / done / failed / canceled）

• input / output：结构化输入输出

• created_at / updated_at：时间戳

• trace_id：可观测性链路标识（便于跨系统排障）

示意如下：

{
  "id": "task-12345",
  "type": "onboard_employee",
  "status": "in_progress",
  "created_at": "<timestamp>",
  "updated_at": "<timestamp>",
  "trace_id": "<trace-id>",
  "input": {"employee_name": "张三"},
  "output": null
}

3. 进度回传

长任务需要支持“增量回传”，典型形态包括：

• 轮询：客户端按间隔拉取任务状态

• 流式：服务端推送进度事件（例如 Server-Sent Events 或 WebSocket）

关键是事件语义要稳定：progress、checkpoint、error、final_output 等。

4. 安全与审计

互操作协议必须能表达：

• 调用方身份与租户归属

• 授权范围（能做什么、不能做什么）

• 审计事件（谁在何时触发了什么任务，传递了哪些上下文）

建议把“敏感上下文”与“可审计元数据”分离传递，避免把凭证或隐私信息直接塞进任务输入。

6.5.4 设计建议

• 先统一数据结构：能力描述、任务状态、错误语义、审计字段。

• 再统一交互方式：请求-响应、轮询、流式事件。

• 最后再做生态：目录、发现服务、跨组织信任体系。

---

下一节: 本章小结