• 博客园logo
  • 会员
  • 周边
  • 新闻
  • 博问
  • 闪存
  • 赞助商
  • YouClaw
    • 搜索
      所有博客
    • 搜索
      当前博客
  • 写随笔 我的博客 短消息 简洁模式
    用户头像
    我的博客 我的园子 账号设置 会员中心 简洁模式 ... 退出登录
    注册 登录
思想人生从关注生活开始
博客园    首页    新随笔    联系   管理    订阅  订阅

ACP 协议设计哲学 —— 为什么 OpenClaw 选择自研 Agent Client Protocol

 

关键词:ACP|Agent Client Protocol|JSON-RPC 扩展|TypeBox|流式通信|多端同步

在构建一个支持 WhatsApp、Telegram、Web、iOS、Android 和 CLI 的 AI 智能体系统时,通信协议的选择直接决定了系统的扩展性、一致性与开发效率。

OpenClaw 没有采用现成的 gRPC、GraphQL 或 REST,而是基于 JSON-RPC 2.0 扩展出一套专为 AI Agent 场景定制的轻量级协议——ACP(Agent Client Protocol)。这并非“重复造轮子”,而是一次面向领域特性的精准设计。

本文将揭示:为什么通用协议不够用?ACP 解决了哪些 AI 原生问题?以及它是如何保障类型安全与多端一致性的。

一、通用协议为何“水土不服”?

1. REST / HTTP —— 请求-响应模型的局限

  • 不支持服务端主动推送(如工具调用进度、思考过程)
  •  难以表达流式输出(Streaming),需依赖 SSE 或长轮询
  • 无内置幂等性或会话上下文概念

对 AI 而言,“发送消息”只是开始,后续可能有多轮 tool_call → observation → text.delta 事件流。

2. gRPC —— 强大但过重

  • 支持双向流、强类型、高效序列化
  • 依赖 Protobuf,前端(JS/TS)集成复杂
  • 调试困难:二进制格式无法直接阅读
  • 跨平台成本高:iOS/Android 需生成客户端 stub

OpenClaw 需要的是“人类可读 + 机器可靠”的平衡。

3. GraphQL —— 查询语言 ≠ 控制协议

  • 灵活查询
  • 本质仍是请求-响应,不擅长表达异步事件
  • 缺乏对命令式操作(如 exec, abort)的自然建模

二、ACP 的设计原则:为 AI Agent 量身定制

OpenClaw 团队提出 ACP 的四大设计原则:

image

 

ACP = JSON-RPC 2.0 + WebSocket + AI 原生语义扩展

三、ACP 核心机制详解

1. 基础结构:兼容 JSON-RPC 2.0

所有请求遵循标准格式:

{
  "jsonrpc": "2.0",
  "method": "chat.send",
  "params": { /* ... */ },
  "id": "req_abc123"
}
  • method:RPC 方法名(如 agent.run, config.get)
  • params:参数对象
  • id:用于匹配响应(支持幂等性)

2. 服务端事件推送(非请求-响应)

当智能体执行过程中产生新状态,网关主动推送事件:

{
  "event": "assistant.text.delta",
  "payload": {
    "runId": "run_xyz789",
    "delta": "正在重启服务器..."
  }
}

常见事件类型:

  • assistant.text.delta:AI 生成文本片段
  • tool.call.request:AI 请求调用工具(如 bash_exec)
  • tool.call.result:工具执行结果返回
  • agent.lifecycle:start / end / error

这使得 Web UI 可实时渲染“打字机效果”或“工具调用卡片”。

3. 幂等性与任务追踪

  • 每个 chat.send 可携带 idempotencyKey
  • 网关缓存结果,防止网络重试导致重复执行
  • 所有事件携带 runId,客户端可关联完整执行链

4. 错误模型标准化

ACP 定义统一错误码:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32001,
    "message": "Model context overflow",
    "data": { "model": "claude-3-5-sonnet" }
  },
  "id": "req_abc123"
}

常见错误码:

  • -32001:上下文溢出(触发自动压缩)
  • -32002:需要用户审批(弹出确认框)
  • -32003:账号限流(触发换号逻辑)

四、TypeBox:实现端到端类型安全

OpenClaw 使用 TypeBox 定义所有 ACP 方法的参数与响应结构。

示例:chat.send 参数 Schema


// src/acp/schemas/chat.ts
import { Type } from '@sinclair/typebox'

export const ChatSendParams = Type.Object({
  sessionKey: Type.String(),
  message: Type.Optional(Type.String()),
  attachments: Type.Array(AttachmentSchema),
  timeoutMs: Type.Optional(Type.Number({ minimum: 1000, maximum: 300000 })),
  idempotencyKey: Type.Optional(Type.String())
})

 

优势:

  1. 运行时校验:网关收到请求后自动验证参数合法性
  2. 编译时类型:ui/ 和 apps/ios/ 可导入该 Schema,获得 TypeScript 类型提示
  3. 文档自动生成:结合 Swagger 可输出 API 文档

从源头杜绝“字段不存在”或“类型错误”类 bug。

五、ACP 如何支撑多端一致性?

由于所有客户端(Web/iOS/Android/CLI)都实现同一套 ACP 协议,它们天然具备功能对齐:

image

 

协议即契约——只要遵守 ACP,任何新客户端都能立即获得全部能力。

六、ACP vs 其他 AI 协议(对比视野)

image

 

ACP 的独特价值在于:它连接了“渠道 ↔ 模型 ↔ 工具”全链路。

结语:协议是系统的“宪法”

在 OpenClaw 中,ACP 不仅是通信格式,更是系统架构的约束与保障。它强制解耦了渠道、协议、智能体三层,使得:

  • 渠道开发者无需懂 LLM
  • 智能体开发者无需关心 WhatsApp 协议
  • 客户端开发者只需实现一套协议

这种“协议优先”(Protocol-First)的设计哲学,正是 OpenClaw 能够快速扩展到多端、多渠道、多模型的核心秘密。

在下一篇文章中,我们将聚焦 OpenClaw 的启动与配置体系,解析 openclaw.mjs、config.yaml 与环境变量如何协同工作。

下一篇预告:
第 4 篇:启动与配置体系 —— openclaw.mjs、config.yaml 与环境变量管理

您的 AI 助手,从此由您定义。若感兴趣可以浏览本书其他章节内容:

第 1 篇:OpenClaw 是什么?—— 工业级 AI 智能体网关的定位与愿景

第 2 篇:三位一体架构详解 —— 网关层、协议层、智能体系如何协同工作

第 3 篇:ACP 协议设计哲学 —— 为什么 OpenClaw 选择自研 Agent Client Protocol

第 4 篇:启动与配置体系 —— openclaw.mjs、config.yaml 与环境变量管理

第 5 篇:run.ts 上篇 —— 模型调度、账号轮询与上下文守护机制

第 6 篇:run.ts 下篇 —— 故障转移、重试策略与结果封装

第 7 篇:记忆系统基石 —— memory-search.ts 中的 RAG 配置解析与合并逻辑

第 8 篇:向量检索实战 —— OpenClaw 如何实现混合搜索(向量 + 全文)

第 9 篇:长期记忆与会话同步 —— 如何让 AI “记住”跨天对话

第 10 篇:exec.ts 上篇 —— 安全执行 Shell 命令的三层隔离模型

第 11 篇:exec.ts 下篇 —— 用户审批、后台任务与权限提升控制

第 12 篇:process.ts —— AI 如何像开发者一样管理后台进程

第 13 篇:安全边界设计 —— OpenClaw 如何防范 AI 滥用系统权限

第 14 篇:server-channels.ts —— 渠道插件生命周期管理器

第 15 篇:WhatsApp 深度集成 —— session.ts 与 Baileys 的健壮连接管理

第 16 篇:消息流入中枢 —— monitor-inbox.ts 如何解析、去重与防抖

第 17 篇:聊天 RPC 接口 —— chat.ts 中的历史查询、发送与中止逻辑

第 18 篇:Skills System —— 为什么“文档即工具”是 OpenClaw 的扩展灵魂

第 19 篇:可观测性工程 —— ws-log.ts 如何让 WebSocket 日志可读可用

第 20 篇:从零部署 OpenClaw —— 实战:接入 WhatsApp + 创建自定义 Skill

posted @ 2026-03-11 21:54  JackYang  阅读(234)  评论(0)    收藏  举报
刷新页面返回顶部
博客园  ©  2004-2026
浙公网安备 33010602011771号 浙ICP备2021040463号-3