AnyCode 将多种编程 Agent 接入同一工作区

把 Claude Code、Codex 和开放模型放进同一个桌面窗口，难点不在聊天界面，而在保留各自的会话、权限和运行规则，还要让它们可靠地交接任务。AnyCode 作者给出的答案是：工作区统一交互，底层引擎继续负责执行。

这篇文章值得读的地方，是它把多 Agent 协作拆成了具体工程问题：消息送达是否等于完成，进程退出后如何恢复，另一个 Agent 能否替你批准工具调用。对做 AI 编程工具和 MCP 集成的程序员，这些细节比多开几个聊天标签更有参考价值。

统一工作区，不代表统一 Agent 的能力

AnyCode 是采用 Apache 2.0 许可的开源桌面应用，支持 macOS、Windows 和 Linux。每个会话选择一种引擎：Claude Code CLI、通过 app-server 协议接入的 Codex CLI，或者 AnyCode 自己的 Native agent loop。

外层提供一致的对话记录、工具调用、权限提示、终端、上下文用量、MCP servers 和 Git 审查。底层不支持的操作，界面直接禁用。

界面可以统一，执行能力必须以引擎为准。

Claude Code 和 Codex 在本地运行，继续使用用户自己的账户，由 CLI 处理认证。Native 则需要接入 GLM Coding Plan、MiniMax、Kimi 等订阅，或 API key，也支持兼容 OpenAI、Anthropic 的端点，包括本地端点。

下面是 Native 使用 GLM-5.3 的一次真实运行，涵盖提出修改、批准编辑、检查预览、审查 diff 和提交。作者说明，输入经过自动化处理，Agent 工作片段有加速，并在视频里标记，因此不能据此判断实际耗时。

接入 CLI，真正要接住的是会话生命周期

编码 Agent 会不断接收对话、选择工具、读取结果，必要时等待批准。承载这套循环的运行框架（harness），必须处理整个过程。

Claude Code 在无界面模式下，通过 stdin 和 stdout 双向传输 stream-json，用 --resume 恢复会话，权限请求也走同一条 stdio 通道。

Codex app-server 使用 JSON-RPC：thread/start、thread/resume 管理会话，turn/start、turn/interrupt 管理轮次，命令执行与文件修改还有各自的审批请求。适配器需要在中断、关闭、恢复和等待批准之间，保住引擎原来的会话标识。

信任边界也参与适配。在尚未信任的目录里，AnyCode 只向 Claude Code 提供用户级设置，防止仓库内 Claude 配置定义的 hooks 进入 CLI。

作者用录制的协议消息样本固定两个 CLI 适配器的行为，检查修改是否引入回归。但这些测试通过，不等于兼容刚发布的 CLI；后者需要另行选择运行真实二进制验证。

Native 遇到的问题则来自供应商差异。有些服务要求后续请求带回先前返回的推理内容，有些会拒绝。AnyCode 默认回传，被拒后去掉推理内容重试一次，并在对话里提示。Responses 传输方式只支持回传加密推理，文本推理没有文档规定的回传形式。

恢复同样属于运行框架的职责。Agent 忙碌时消息排队；Claude 会话在空闲时进程退出，会自动恢复。恢复失败则保留未发送消息，并说明如何重启。后台子会话的报告也会跨会话重启保留，之后重试交付。原文只明确描述了 Claude 的这项自动恢复行为，不能扩大到全部引擎。

多 Agent 交接，先分清送达和完成

AnyCode 用 Sessions API 让不同引擎的会话互相通信，应用外的 Agent 也能接入。它是绑定 127.0.0.1、使用 token 保护的本地 MCP 端点，仅在应用打开时运行。

这需要手动启用 API，并给调用方配置 MCP server。Settings 提供 Claude Code 和 Codex 的现成配置；在 AnyCode 内运行，并不会自动获得这些工具。

典型流程是让 Claude Code 请求 Codex 审查当前修改：

1. 调用 create_session，传入 engine: "codex" 和项目路径，保存返回的 session id。
2. 会话就绪后调用 send_message，使用 mode: "next_turn"，要求检查当前 diff、提供文件和行号、不编辑文件。
3. 把 session id 与返回的 message id 交给 wait_for_result，等待对应轮次的答案。
4. 根据结果修改，再向同一会话追问，结束后调用 close_session。

此外，list_sessions 可以读取已共享会话的状态和最新答案，cancel_turn 可以停止正在运行的轮次。send_message 既能排队到下一轮，也能在 Codex 会话里引导正在执行的轮次。

消息被接收，只证明进入了处理流程，不证明工作已经完成。

wait_for_result 每次最多等待 120 秒，返回 pending 就继续等待。API 同时跟踪消息接收和对应轮次的完成状态，避免调用方把送达回执当成审查结果。

权限分层开放：每个会话的共享默认关闭；新会话只能开在已信任、且勾选「Allow agents to open tasks here」的项目中，同时最多八个。External approvals 也默认关闭，开启后外部客户端只能逐项批准或拒绝待处理请求，不能选择「always allow」。

这套 API 与应用内的父子会话委派互补。Native 和 Codex 标签还提供 Orchestrate mode，把标签变成只读监督者，协调 planner、executor、reviewer。

远程入口也复用同一套接口。仓库附带 Telegram bridge 示例插件，由 AnyCode 启动和监督，将一个私聊连接到共享会话：文本触发新一轮，/new 新建会话，开启 External approvals 后可用 Allow、Deny 按钮审批。插件只用 Node 内置模块，可以作为其他渠道桥接的模板。

桌面端则分为沙箱 renderer、运行会话的宿主进程，以及中间的类型化消息协议。作者认为它有机会扩展成 VPS 后端加桌面薄客户端，但远程传输和部署仍需开发，尚未交付。

我的判断

我认可这套方案对边界的处理：引擎保留执行权，工作区负责展示、协调和恢复；跨 Agent 通信显式跟踪请求与结果，权限按会话、项目和审批分别控制。这些做法直接对应真实故障和误操作。

相比在几个终端间手动复制提示词，它提供了可追踪的任务交接；相比自己写调用多个模型的脚本，它保留了 Claude Code、Codex 各自的运行环境。不过，增加适配器也增加了协议升级与状态恢复的维护成本。

作者没有提供协作效率、成功率或与其他方案的对照数据，因此「多 Agent 更有效」仍不能当作已验证结论。作者日常使用并借助 Agent 开发 AnyCode，说明它有实际使用反馈，但不足以证明适合一般团队。

它目前是 alpha，版本 v0.0.90，存储、API 和 UI 都没有兼容性保证，构建也尚未签名。Native 侧实际使用过 Z.AI、Kimi、DeepSeek、MiniMax 和 Xiaomi MiMo，其他供应商验证较少。

作者在协议和权限边界变更时，依靠类型检查、测试、协议样本和仅用于开发的 GUI 冒烟流程验收。这比单凭 Agent 自报完成更可信，但文章没给出测试覆盖范围。

能拿来做什么

• 试用时选一个普通前端或 Node 修改任务，完整走过编辑、审批、预览、diff 审查和提交，记录哪个环节会让你想切回原工具。
• 尝试跨 Agent 审查时，把任务限定为检查当前 diff，要求给出文件和行号，并明确不编辑文件；通过 message id 等待对应答案。
• 开发 Node MCP 集成时，分别记录消息接收与轮次完成状态，并处理 pending 后继续等待，别把请求提交成功当成任务成功。
• 自建编码工作区时，先验证会话恢复、未发送消息保留和审批边界，再增加并行角色；CLI 升级后补做真实二进制验证。