当开发者开始在终端里并行运行多个编码 Agent 时，真正需要被打通的往往不是模型本身，而是 CLI 暴露出来的配置接口、事件机制和权限体系。Calyx 作为一款用于在 macOS 终端中并行运行与监督编码 Agent 的工具，需要同时接入 Claude Code、Codex、OpenCode、Hermes、Grok 和 pi 六种 CLI。这也促使开发者逐一梳理了这些工具在 hooks、权限、子代理和 MCP 配置上的实际暴露能力。
从素材给出的信息来看，这次对比基于 Calyx 代码中固定的版本信息：Claude Code 2.1.251、Codex 0.148.0、OpenCode 1.18.18；Hermes、Grok 和 pi 则对应 2026 年 9 月中旬的状态。所有结论来自集成代码，部分基于厂商文档的地方也被单独注明。
MCP 配置：同一条连接，六种写法
在 Calyx 的接入场景中，每个 CLI 最终都指向同一个本地 MCP 服务地址：http://127.0.0.1:<port>/mcp，并通过 Authorization: Bearer <token> 完成认证。同时，连接还需要携带两个身份标识头：X-Calyx-Surface-ID 和 X-Calyx-Session-ID。
真正的差异出现在配置文件如何表达“这个请求头的值来自哪个环境变量”。各家的写法并不相同：
- Claude Code 支持在字符串中使用 ${VAR} 插值，且必须写成 ${VAR:-} 这种带空默认值的形式。如果变量未定义且未使用默认值，整个 ~/.claude.json 解析都会失败，并影响用户在其他终端中运行的 Claude Code。
- Codex 不使用占位字符串，而是提供 env_http_headers 字段，将请求头名称直接映射到环境变量名。测试显示，当变量未设置时，Codex 会直接省略该请求头，而不是发送一个空值。
- OpenCode 使用第三种语法 {env:VAR}，并将传输类型称为 remote。
- Hermes 也支持 ${VAR}，但不带默认值。
- Grok 则允许在 [mcp_servers.*] 表下的所有字符串字段中展开 ${VAR} 或 ${VAR:-default}，因此不需要额外的映射表。
- pi 没有 MCP 客户端。其扩展通过 fetch 直接与 /mcp 进行 JSON-RPC 通信，并在会话开始时发送一次 initialize 请求以绑定面板。
这些差异看似只是配置语法问题，但对需要批量集成多个 Agent 的工具来说，它们直接影响自动化配置的稳定性。尤其是在环境变量缺失、默认值处理和配置文件解析失败等边界情况下，不同 CLI 的行为会给上层监控工具带来完全不同的处理成本。
事件上报：命令 Hook、插件 API 与扩展机制并存
Calyx 还需要获取各 CLI 的运行事件，例如会话开始、工具调用前后、权限请求、子代理启动等。素材显示，目前主要存在三种事件接入方式。
- 命令 Hook：Claude Code、Codex 和 Grok 采用这种方式。CLI 会运行一个外部程序，并将事件以 JSON 形式写入其标准输入，再读取标准输出。Calyx 安装了一个名为 calyx-agent-hook 的 shell 脚本，用于读取端点文件、校验面板身份变量，并通过 curl –data-binary @- 将 stdin 内容转发到 /agent-event。Codex 和 Grok 会传入自身名称参数，未传参数时脚本默认按 Claude Code 处理。所有路径都以 exit 0 结束，避免一次失败的请求中断用户的 hook 链。
- 插件 API 回调：OpenCode 会自动加载 ~/.config/opencode/plugins/ 下的 JavaScript 文件，运行在 Bun 环境中，无需在 opencode.json 中配置。插件导出一个函数，接收工作目录并返回事件处理器，再将 OpenCode 事件映射到命令 Hook 的事件名称后上报。
- 扩展 API：pi 的 TypeScript 扩展文件放在 ~/.pi/agent/extensions/ 下，通过导出函数接收 pi 的扩展 API，并使用 pi.on(event, handler) 注册事件处理器。其上报结构与 OpenCode 插件类似。
Hermes 则是例外。Calyx 没有为 Hermes 注册 hooks，其状态主要来自 MCP 连接本身。Calyx 会根据面板屏幕上的文本分类判断其处于工作、阻塞还是空闲状态；在启用 Command Tracking 且面板运行交互式 zsh 或 fish 时，面板自身退出信号会标记该行结束。
事件覆盖：Claude Code 最细，OpenCode 与 pi 各有侧重
在事件数量上，各 CLI 暴露的粒度也不一致。Claude Code 注册了 10 个事件，包括 SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Notification（matcher 为 permission_prompt）、Stop、SessionEnd、PermissionRequest、SubagentStart、SubagentStop。
Codex 注册了与 Claude Code 相同的事件集合，但少了 Notification，共计 9 个。OpenCode 注册了 7 个事件：session.created、tool.execute.before、tool.execute.after、permission.asked、permission.replied、session.idle、session.deleted。
Hermes 没有注册任何事件。素材中关于 Grok 的事件列表在“PreToolU”处截断，因此无法确认完整覆盖范围；但可以确认的是，Grok 与 Claude Code、Codex 一样采用命令 Hook 机制，并通过脚本参数区分自身。
pi 的情况则更特殊。由于它没有 MCP 客户端，Calyx 的工具需要通过一个名为 calyx 的统一调度工具进入模型，该工具接收 {tool, args} 参数。之所以使用单一调度工具，而不是为每个 IPC 工具单独注册，是因为 pi 会在每一轮对话中把所有已注册工具的名称和描述写入系统提示词。工具数量过多会直接放大上下文负担，因此 Calyx 选择压缩为一个入口。
对自动化工作流与安全沙箱的启示
这次对比显示，编码 Agent CLI 的竞争已经不只停留在模型能力或代码生成质量层面。对于希望构建多 Agent 监控、自动化流水线或安全沙箱的开发者来说，CLI 是否提供稳定的事件 Hook、是否支持权限请求回调、是否能通过 MCP 传递身份信息，都会影响上层工具的设计方式。
Claude Code 的事件覆盖最完整，尤其是 PermissionRequest、SubagentStart 和 SubagentStop 等事件，对权限审计和子代理观察更友好。Codex 的事件模型与其接近，但在 Notification 上有所缺失。OpenCode 通过插件机制提供更灵活的 JavaScript 接入，但其事件命名和生命周期与 Claude Code 体系并不完全一致。pi 的扩展机制可用，但受制于工具注册方式和缺少 MCP 客户端，需要额外封装。Hermes 暴露的信息最少，更多依赖外部观察而非内部事件。
这些差异意味着，开发者如果要在多个编码 Agent 之上构建统一控制面板，不能假设所有 CLI 都能提供相同的可观测性。请求头语法、环境变量缺省行为、事件回调方式、权限事件粒度，都会成为集成过程中的实际变量。
从更长远的角度看，编码 Agent 正在从单轮对话工具转向长期运行的终端工作负载。谁能把会话、工具调用、权限确认和子代理状态更清晰地暴露给外部系统，谁就更容易进入企业级开发流程、自动化测试环境和安全隔离场景。此次对比没有给出“最佳”答案，但它清楚展示了一点：CLI 接口设计本身，正在成为 AI 编程基础设施的重要组成部分。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/bian-ma-agent-cli-de-jie-kou-xi-jie-liu-kuan-gong-ju-zai
