研究背景

先把几类东西分开

讨论 agent 集成时，最容易混淆的是把“协议”、“命令”、“适配器”和“产品”说成一回事。实际上它们分属四层。

层级	典型例子	作用
协议	ACP、JSON-RPC、SSE、NDJSON	定义宿主如何跟 agent 交换消息
命令	codex exec、claude -p	一次性跑任务的入口
适配器	codex-acp、claude-code-acp	把上游 runtime 翻译成宿主能消费的协议
产品	Zed、OpenClaw、Multica	真正面向用户的编辑器、网关、daemon

三种最常见的集成形态

1. 直接调 provider API

product -> OpenAI compatible API / Anthropic API / gateway

特点：

• 最薄。
• 对产品最容易统一。
• 一般不会拿到上游 agent 的完整本地工具/会话语义。

2. 直接拉本地 CLI

product -> local CLI -> stdout/stderr/json stream

特点：

• 适合脚本和 daemon。
• 很多时候够用。
• 上游如果只暴露“命令 + 事件流”，这是最自然的接法。

3. 接长期运行的 agent server 或 adapter

product -> ACP / JSON-RPC -> adapter or app-server -> runtime

特点：

• 更适合 IDE、长期会话、权限交互、工具审批、线程恢复。
• 宿主控制力更强。
• 实现复杂度也更高。

这套框架套到本文对象上

对象	更接近哪类
codex exec	一次性命令
codex app-server	长期运行的 runtime server
codex-acp	协议适配器
claude --output-format stream-json	CLI 事件流接口
Zed	IDE 宿主
OpenClaw	gateway / orchestration
Multica	本地 daemon 宿主

一个高频误区

“支持 Codex” 并不等于：

• 调 OpenAI API；
• 调 codex exec；
• 接 codex-acp；
• 嵌入 codex 的内部 runtime。

这四件事差别很大，必须看产品到底调用了哪一层。