今天被扣子 3.0 更新的消息刷屏了，铺天盖地都在说新增了本地 Agent 支持，能够对接 Claude Code、Codex CLI 这些工具。这恰好击中了我之前的一个想法：能不能做一个统一的管理中枢，把任务分配给多个本地编程智能体，让它们像团队一样协作？
其实早在龙虾 OpenClaw 火起来的那段时间，大概两个月前，我就琢磨过用 Git 仓库作为任务看板来驱动多 Agent 协作，还让 Claude 帮忙出了一套方案（具体链接就不放了）。可惜的是，翻遍了各家发布的文章，都没找到具体的连接方法。多数文章也就一句话带过：“只需一行命令，即可连接本地 Claude Code。”
干脆直接上官网查帮助文档。在接入本地 Agent 的界面拿到了这么一行命令：
npx -y coze-bridge@latest --pat-token=sat_QK6PJiIoT6cN......GsZ0zj95Wetq2 --pair-code=ab0d0a......c7d19e
命令拿到后，干脆把 coze-bridge 这个 npm 包下载下来，做了完整的源码分析。结果发现，它的核心是一套叫 ACP（Agent Client Protocol）的协议。ACP 本质上是一个基于 JSON-RPC 2.0 的开放协议，用来标准化编辑器或 IDE（客户端）与 AI 编程助手（Agent）之间的通信方式。而且这个协议的应用范围已经超出了编程领域，扩展到了各类桌面或 Web 应用与 AI Agent 的交互场景。
这一发现让我的想法有了具体的实现路径：基于 ACP 协议的特性，完全有可能做出一个真正的多 Agent 协同管理产品。
coze-bridge 是什么？
coze-bridge 是字节跳动发布的 npm 包，当前版本 0.1.90。它的角色其实就是本机的一个后台守护程序，专门把扣子云端的 Agent 服务跟本地的 AI Agent（比如 Claude Code、Codex、OpenClaw）桥接起来。把它想象成一个翻译官会更直观：扣子云端用的是自己的 Frontier 协议，而本地 Agent 用的是 ACP 协议。coze-bridge 负责将两边的“语言”互相翻译。
架构上大致是这样的：用户在扣子网页上操作，云端通过 Frontier WebSocket 下发指令；本机的 bridge daemon 接收到指令后解析，然后 spawn 本地 ACP Agent 子进程去执行，最终结果原路返回。
Daemon 生命周期管理
coze-bridge 以守护进程模式运行，通过 ~/.coze/bridge/bridge.pid 文件实现单实例锁。启动时会 spawn 一个 detached: true 的子进程，在 127.0.0.1 随机端口开启一个 HTTP IPC 服务，用 token 来认证。系统自启方面，它支持 macOS（通过 launchd）、Linux（systemctl）和 Windows（schtasks），覆盖了三大主流平台。
配对流程
配对流程也比较清晰：CLI 带 --pat-token 和 --pair-code 启动，如果 daemon 还没运行就先启动它，然后向本地的 IPC 服务发送 POST /pair 请求。接着调用 Coze 云端的 handshake API（https://www.coze.cn），获取 deviceId，再建立 Frontier WebSocket 连接。之后每 10 秒会发送一次心跳（_agent/health），并自动连接 Agent。
Spawn 子进程机制
值得留意的是，coze-bridge 启动的是全新的子进程，而不是连接用户本地已经运行的 Agent。它安装的是专门的 ACP wrapper 包，而不是用户日常使用的 CLI 工具。所以运行扣子命令时，我的 Mac 弹出了两次 Codex 对电脑有危害的提示，原因就在这里。
| 用户日常用的 | bridge 启动的 | NPM 包 |
|---|---|---|
| claude（Claude Code CLI） | claude-agent-acp | @agentclientprotocol/claude-agent-acp |
| codex（Codex CLI） | codex-acp | @zed-industries/codex-acp |
| openclaw | openclaw | 检测本地安装 |
coze-bridge 通过 Node.js 的 child_process.spawn() 启动子进程，stdio 设为管道模式，通过 stdin 写入命令、stdout 读取响应。
外部调用清单
| 目标 | 协议 | 用途 |
|---|---|---|
| https://www.coze.cn | HTTP | handshake API、pair 配对、reconnect |
| wss://frontier.coze.cn | WebSocket | 长连接通道、指令收发、心跳 |
| https://llm-gateway.coze.cn | HTTP | LLM 网关、model API 调用 |
| npm install -g | 本地进程 | 自动安装 ACP wrapper 包 |
ACP 协议：专为 AI Agent 设计
ACP（Agent Client Protocol）是一套标准化的本地进程间通信协议，思路类似 LSP（Language Server Protocol），但专门为 AI Agent 设计。
协议格式
每一帧是一行 JSON（ldjson，Line-Delimited JSON），通过 stdin/stdout 双向通信。
| coze-bridge daemon | ⇄ | Agent 子进程 |
|---|---|---|
| stdin → 写入 JSON 命令 | stdout → 输出 JSON 响应 |
每帧格式示例：{"method":"session.prompt","params":{...},"id":"1"}
协议核心能力
| ACP 方法 | 方向 | 用途 |
|---|---|---|
| initialize | Client → Agent | 握手，协商协议版本和能力 |
| session.prompt | Client → Agent | 发送用户消息给 agent |
| session.cancel | Client → Agent | 取消正在进行的 prompt |
| session.request_permission | Agent → Client | Agent 请求权限（如执行命令） |
| fs/read_text_file | Agent → Client | Agent 请求读取文件 |
| fs/write_text_file | Agent → Client | Agent 请求写入文件 |
三种协议的层级关系
协议栈上，底层是 ACP 在 bridge 和本地 agent 子进程之间通过 stdin/stdout 传输 ldjson 数据。上层是字节内部的 Frontier 协议，通过 WebSocket 在 Coze 云端和本机 bridge daemon 之间传输自定义帧格式。中间的 coze-bridge 就是做协议转换的连接器。因为扣子用 Frontier 协议与 ACP 不兼容，所以 bridge 的翻译角色至关重要。
基于 ACP 的 Agent 团队管理方案
ACP 协议的核心特性，正好解决了 Agent 团队管理中的几个关键难题：
| 传统痛点 | ACP 怎么解决 |
|---|---|
| 每个 Agent CLI 接口不同 | 统一的 stdin/stdout ldjson 协议 |
| 无法程序化控制 Agent | ACP 天生就是给程序用的 |
| Agent 之间无法协作 | 内置 fs/read、fs/write 文件协作 |
| 状态管理混乱 | session 机制天然支持会话隔离 |
| 权限控制困难 | session.request_permission 机制 |
产品架构设计
一个基于 ACP 的 Agent 团队管理产品，其架构大致可以分为三层：
- 上层：产品控制面板（Web UI），包括任务管理、Agent 管理、监控看板、成果输出等功能。
- 中层：调度引擎（Scheduler），负责任务编排、拆解、依赖管理、并行调度和结果聚合。
- 底层：ACP Agent Pool，多个 Agent 实例并行工作，比如 #1 负责编码（claude）、#2 负责设计（claude）、#3 负责测试（codex）、#4 负责审查（openclaw）等。
任务拆解与分发流程
用户输入一个复杂任务后，主控 Agent 先拆解，再分发给多个专职 Agent 并行执行。举个例子，用户输入“开发一个用户登录模块”，主控 Agent 通过 session.prompt 接收任务，分解出子任务列表：数据库设计 → API 接口 → 前端页面 → 单元测试 → 代码审查。然后通过 ACP 并行分发给对应的 Agent。
Agent 间协作机制
ACP 协议内置的 fs/read_text_file 和 fs/write_text_file 让 Agent 之间可以通过共享 workspace 文件间接协作。典型的协作链路是：Agent #1 写 schema.sql → Agent #2 读 schema 写 API → Agent #3 读 API 写前端 → Agent #4 读 API 写测试。整个过程完全依赖于文件系统作为通信媒介。
实现与挑战
三步走路线图
实现这样一个产品，大致可以分为三个迭代阶段：
- MVP：启动多个 ACP Agent，提供简单的 Web UI 创建任务和基础的任务队列能力。
- 智能调度：主控 Agent 自动拆解任务，引入 DAG 依赖管理，支持并行执行和失败重试。
- 团队协作：多用户共享 Agent 池，实时监控看板，成果自动聚合。
关键技术挑战
| 挑战 | 解决方案 |
|---|---|
| Agent 进程管理 | 守护进程 + 健康检查 + 自动重启 |
| 任务状态同步 | 基于 ACP session 机制 + 本地状态机 |
| Agent 间通信 | 共享 workspace 文件，可选消息队列 |
| 资源消耗 | Agent 池大小限制 + 空闲回收 |
| 错误处理 | ACP 错误码映射 + 重试策略 |
一些总结
通过拆解 coze-bridge 的源码，发现了一个非常重要的事实：业内其实已经存在了 ACP 这样的开放协议。它用一套统一的 stdin/stdout ldjson 协议，让不同厂商的 AI Agent 都能被程序化控制。这为“Agent 团队管理”从概念变成可落地的技术方案提供了坚实的基础。
打算抽空写一个本地用的管理小工具，如果大家有兴趣，欢迎在评论区聊聊具体需求。
