操控编码Agent：终端UI还是协议？深度解析两种集成路径

当开发者试图在一个统一应用中同时运行多个编码Agent时，直觉上最直接的做法是给每个Agent分配一个伪终端（pty），然后像人类用户那样向终端敲入命令。这一思路在初期确实可行，但随着任务复杂度和Agent能力的提升，其局限迅速暴露。

为什么终端UI方案会失效

以Codex的终端界面为例：当它正忙于执行任务时，通过pty键入的消息无法被接收，导致你无法在任务中途进行干预或调整方向。更棘手的是，不同版本之间的屏幕输出格式会发生变化，任何依赖解析TUI（文本用户界面）来判断Agent状态的逻辑都变得极其脆弱。

判断一个Agent是否在等待输入，实际上变成了纯粹的猜测工作。你无法可靠地从一堆ANSI转义序列和动态刷新的文本中提取出"现在需要人类介入"这一信号。对于需要精确编排多个Agent协作的自动化场景，这种不确定性是致命的。

伪终端（pty） 是 Unix 系统中用于模拟真实终端设备的内核设施，SSH、tmux、xterm 等工具都依赖它。程序通过 pty 启动子进程后，子进程会以为自己连接着一个真实的交互式终端，从而正常输出 ANSI 转义序列、响应控制键。正因如此，pty 常被用来"脚本化"那些只提供交互式界面的程序。

但这种做法存在一个根本性错配：pty 暴露的是面向人类视觉的字节流，而非面向程序的结构化接口。开发者要判断 Agent 处于何种状态，只能对屏幕上渲染出的文本做模式匹配。而 TUI 应用通常使用全屏刷新、光标定位、颜色高亮等手段绘制界面，同一逻辑状态在不同帧里可能对应完全不同的字节序列。这使得解析逻辑既复杂又容易随版本失效，也是文章中"猜谜式"判断的根源。

协议方案：结构化事件带来的确定性

转向各Agent自有的协议接口，情况则完全不同。Claude Code会流式输出JSON事件，每一步工具调用、每一次提问、每一轮对话结束都以结构化数据的形式呈现。Codex提供了codex app-server，允许你在回合进行中发送消息，实现真正的实时干预。Gemini CLI和Cursor的Agent则采用ACP（Agent Client Protocol）协议。

这些协议带来的核心优势在于：你不会再收到需要肉眼解析的屏幕文本，而是获得明确的事件类型——工具调用、待回答问题、回合结束。程序可以基于这些事件做出确定性的逻辑判断，而不必依赖正则表达式去"刮"屏幕内容。用一位开发者的原话说，这种方式"不需要屏幕抓取"。

ACP（Agent Client Protocol） 是一个为编辑器/IDE 与编码 Agent 之间通信设计的开放协议，由 Zed 团队推动，目标类似 LSP（Language Server Protocol）之于语言工具。它规定了一套 JSON-RPC 风格的请求/响应与通知消息，覆盖会话创建、提示发送、工具调用授权、文件读写等交互，使客户端不必为每个 Agent 写一套私有对接逻辑。

将 ACP 与 Claude Code、Codex 各自的 JSON 事件流对比，差别在于抽象层次：后两者是各厂商自有的"原生"接口，字段和语义随产品迭代；ACP 则试图定义一个中立的中间层，由 Agent 侧实现协议服务端、编辑器侧实现客户端。如果多个 Agent 都遵循 ACP，客户端就只需维护一份实现。当然，协议能否真正收敛，取决于它能否被足够多的 Agent 采纳，这正是文章末尾强调的未知数。

代价：碎片化与版本漂移

协议方案并非没有成本。目前行业内尚无统一标准，每个Agent都需要单独编写适配器。更麻烦的是，协议本身的变化速度几乎与Agent迭代同步——今天能用的接口，下个版本可能就有字段调整。这意味着维护适配器的持续投入不可避免。

这种碎片化状态对所有构建在Agent CLI之上的工具开发者而言，是一个需要长期面对的工程现实。选择协议路线，意味着接受更高的初期开发成本和持续的维护负担，换取的是运行时的可靠性和可控性。

适配器模式（Adapter Pattern） 是软件工程中用来隔离接口差异的经典手段：为每个异构数据源或服务编写一层薄封装，把其特有的 API 转换成上层系统统一期望的形状。在本文语境里，为 Claude Code、Codex、Gemini CLI、Cursor 各写一个适配器，就是让上层编排逻辑只面对"工具调用/待答问题/回合结束"这些统一事件，而不直接依赖任一 Agent 的原始 JSON 结构。

适配器模式能显著降低上层代码的耦合度，但代价是把复杂度转移到了适配器本身。当底层协议频繁变动时，每个适配器都需要独立跟进和测试。因此实践中通常会引入契约测试或录制回放机制：用固定样本验证适配器在协议变更后是否仍然正确解析，把"版本漂移"的风险限制在可控范围内。

开发者的真实困境

实际开发中，不少团队可能处于混合状态：部分Agent通过协议驱动，部分仍依赖终端模拟。这种混合模式虽然能暂时兼顾，但增加了系统复杂度和不一致性。

如果你正在构建基于Agent CLI的工具，一个关键决策是：你选择站在Agent自有协议之上，还是继续留在终端层？抑或等待某个统一标准胜出？ACP作为目前唯一有跨Agent倾向的协议，是否会成为那个收敛点，目前还没有确定答案。

这场关于集成方式的讨论，本质上是自动化工具在"快速适配"与"稳定可靠"之间的权衡。终端UI路径降低了初期门槛，但牺牲了运行时的确定性和可编程性；协议路径则要求更多前期投入，却为复杂的多Agent编排打开了可能性。