←

让 Codex 通过 ACP 调用 ZCode：接通、审查与持续迭代

· 7 分钟阅读

我原来让 Codex 负责开发，再通过另一个 Agent 做审查。最近想把审查者换成本机的 ZCode，于是从一个很直接的问题开始：能不能让 Codex 调用它？

这次最终接通的是 Codex → acpx → zcode-acp → ZCode。我把调用脚本、审查提示词和留档规则整理成了开源的 zcode-acp-review Skill。首版支持 Windows 和 PowerShell 7。

比起“多接了一个模型”，我更关心三个问题：它到底怎么接通，第二个 Agent 应该审什么，以及每次调用后留下什么，才能帮助下一次改进。

ACP 是协议，不是把 ZCode 包成 MCP 工具

Agent Client Protocol 的架构区分客户端和 Agent。客户端发起会话与请求，Agent 返回消息，也可能请求文件或终端等能力。常见本地连接通过标准输入输出传递协议消息。

因此，“接入 ACP”并不意味着启动了一个 HTTP 服务，更不意味着自动获得一个 MCP 工具。

对比点 这次使用的 ACP 常见 MCP 工具接入
主要交互对象 一个有会话的编码 Agent 工具、资源或提示词提供方
我希望它做什么 阅读上下文、调查、给出审查结论 执行某项暴露出来的能力
本次实际接法 本地进程之间通过 stdio 通信 本项目没有搭建 MCP 服务

这不是说 MCP 不能包装 Agent。可以再加一层 MCP 工具，但那是额外实现，不是 ACP 自带的结果。

为什么要有 acpx？Codex 自己不行吗？

我当时也问了这个问题。答案是：需要有人实现 ACP 客户端，但不一定非要 acpx。

这次的链路可以拆成这样：

Codex：组织任务、调用本地脚本、核实结果
  ↓
review.ps1：整理输入、选择会话、保存短记录
  ↓
acpx：作为无界面的 ACP 客户端
  ↓ ACP / stdio
zcode-acp：把 ACP 请求适配到 ZCode
  ↓
本机 ZCode app-server：执行审查任务

acpx负责客户端侧的会话和协议交互。zcode-acp是社区提供的适配器。两者不是模型。

Codex 在这里通过本地命令能力驱动客户端。如果自己写一个 ACP 客户端，也能替换 acpx；只是还得处理初始化、会话、流式消息、权限和失败状态。现阶段复用已有客户端更直接。

反过来，把 Codex 暴露为 ACP Agent，也不等于让 Codex 自动获得调用其他 ACP Agent 的能力。客户端与被调用的 Agent 是两个不同角色。

接通时，Windows 的细节比概念更费时间

我没有继续使用直接 CLI 问答的路径，因为之前的尝试没有达到预期。这不代表 ZCode 没有 CLI：这次仍然使用了应用内置入口，只是通过适配器进入 app-server 链路。

这套实现固定了 acpx 0.15.1 和 zcode-acp-server 0.35.1。本机使用 Node.js 22.22.2、ZCode 3.10.2，内置 CLI 版本为 0.16.5。

有几个值得留下来的细节：

  • 用 argv 数组注册启动入口。 本机用字符串拼接 Agent 命令没有成功，改为明确的 Node 路径与入口文件数组后接通。acpx 的配置说明也提供了这一方式。
  • 明确传入 ZCODE_NODE。 自动寻找运行时在这里触发过 spawn EFTYPE，明确使用 Node 后解决。还需要设置本地运行时与 ZCode 入口。
  • 固定版本，并区分“安装成功”和“调用成功”。 本机安装钩子出过问题，使用 --ignore-scripts 后验证了发布包的 ACP 入口。这不代表上游所有构建功能都可用。

第一次接通时，我让它回答：“你好，你是什么模型？”它自述为 GLM-5.3，ACP 配置事件也显示相同模型。这个结果能帮助确认会话路径和配置，但不能独立证明服务端实际使用了哪个模型。

审查者应该独立判断，不只是附和方案

我的目标不是让两个 Agent 互相说“通过”。

方案审查时，ZCode 应先理解需求、验收条件和现有约束，再判断方案是否合理。代码审查时，先读需求与基线代码，形成自己的判断，再看改动。它可以调查上下文，但职责是审查，不是实施。

主 Agent 收到反馈后仍要核实：问题是否真实、证据是否充分、是否在本次范围内。不能把第二个 Agent 的输出直接升级成事实，也不自动循环到它说通过为止。

复审沿用同一个会话，同时重新提供本次文档或代码版本。这样既能保留前一轮背景，又避免只凭旧结论判断新改动。会话失效时应该报错，而不是悄悄开启新会话并假装记得之前的内容。

还有一个边界必须讲清楚：当前脚本允许 ZCode 自主使用工具，-TrustWorkspace 是显式确认入口。“不要修改文件”是提示词约束，不是只读沙箱。 如果材料敏感或要求强隔离，需要另外限制工作区、凭据和运行环境。

每次调用留一份短记录，才有改进依据

用户提出的一个要求我很认同：每次调用结束，都留一点简单文档，后面根据记录优化。

我没有选择保存完整对话和工具流水。短记录只回答这些问题：

  1. 审了什么：任务、文档哈希、代码基线和目标。
  2. 怎么调用的：会话、模型配置、脚本与提示词版本、依赖版本。
  3. 有没有完成：成功、失败或中断，耗时多少。
  4. 说了什么：长度受限的结论摘录。
  5. 核实后怎样：有效问题、误报、待确认、处理证据和改进建议。

脚本负责前面的事实记录，主 Agent 补充最后的核实。失败和复审也分别留档，并链接上一轮。

completed 只表示调用正常返回，不代表审查通过。强制结束可能留下 running；记录目录不可写时应在发送任务前停止。短记录也可能包含本地路径或敏感摘录，基础脱敏不能替代公开前的检查。

这样下一次才能讨论：哪些提示帮助发现了问题，哪些产生了误报，是否缺了某项上下文。记录的价值来自核实与处理，而不是数量。

开源了什么，别人怎么用？

zcode-acp-review 提供三个部分：

  • Skill：告诉宿主什么时候调用，以及如何处理反馈。
  • PowerShell 脚本：安装固定依赖、发起审查、复用会话和留档。
  • 审查提示词与使用说明：约定职责、输入和失败处理。

使用者需要自行安装并登录 ZCode，提供本机 zcode.cjs 路径。仓库不分发 ZCode，也不提供模型凭据。安装命令、权限说明、卸载方式和验证范围都在 README 中。

它是一个可以直接试用的小工具，还不是跨平台 Agent 编排框架。当前验证集中在 Windows 的安装与调用链、方案中的计数错误、同会话复审和失败记录；不据此宣称能稳定发现复杂业务缺陷，也没有验证每种宿主的自动 Skill 发现行为。

这次实践延续了我在上一篇开发流程文章里的想法：让每一步有明确输入、结果和核实依据。接通另一个 Agent 只是开始，后面的审查质量和记录迭代，才是我准备继续观察的部分。