Zerg Client：能自己开终端窗格的编程智能体

当编程智能体学会「开窗」

大多数 AI 编程工具的设计逻辑，是把模型塞进一个聊天框里，让你复制粘贴代码。Zerg Client 的思路不太一样：它把终端本身变成了智能体的操作界面。在 Product Hunt 上，这款产品以「The coding agent harness that drives its own terminal panes」为标语亮相，目前处于评估测试阶段。

据官方描述，你可以直接要求它开一个 Vim 或 htop，智能体会在自己旁边的窗格里把这套交互式程序跑起来。这个细节看似简单，背后是「harness」这个词的实质含义——它不只是个对话框，而是能调度终端会话的运行框架。

多窗格、多智能体、多模型

Zerg Client 的窗格设计支持嵌套，这些窗格里可以再放更多智能体，每个智能体跑在自己的模型上。这意味着工作流可以并行拆解：一个窗格里的智能体负责改代码，另一个窗格里的智能体跑测试、看日志，甚至用 htop 观察资源占用。

可用模型取决于用户的登录方式和各提供商的开通权限，产品没有罗列统一的模型清单。硬件方面明确限定为搭载 Apple 芯片的 Mac，这一点在同类工具中并不罕见——本地终端交互对系统层的依赖较重，先做单平台是常见取舍。

从 Product Hunt 的数据看，该产品获得 79 票、4 条评论，排名 #17。这个热度谈不上爆发，但说明它在开发者小圈子里已经引起了注意。

harness 在智能体语境下的含义

在 AI 工程领域，harness（直译“挽具”）指包裹在模型之外的一层运行框架，负责把模型的输出转化为真实动作，并把执行结果反馈回模型。它通常包含工具调用、会话状态维护、错误重试和上下文注入等机制。对编程智能体而言，harness 决定了模型能否读写文件、执行命令、观察输出。Zerg Client 自称 harness，强调的是它并非单纯的聊天前端，而是承担调度终端会话、管理窗格生命周期的中间层；模型本身只负责决策，具体“动手”由 harness 完成。

终端即界面：一个值得关注的方向

把终端当作智能体的「手」而不是「输出口」，是个有分量的产品判断。传统 AI 编程助手止步于生成代码，真正跑起来、调起来、观察起来仍要人来做。Zerg Client 试图补上这一段：让智能体直接驱动 Vim、htop 这类交互式程序，等于把「读-改-跑-看」的循环交给了它自己。

这也带来一些现实问题。交互式程序依赖键盘输入和 TTY 状态，智能体驱动它们需要稳定的会话管理能力；多窗格多智能体并行时，如何避免互相干扰、如何界定权限边界，都是评估阶段需要验证的点。官方目前给出的信息还比较克制，没有公开具体的调度机制。

TTY 与交互式程序对智能体驱动的影响

TTY（teletypewriter）是 Unix 系统中终端设备的抽象，交互式程序如 Vim、htop 依赖它来判断自己是否运行在真实终端中，并据此启用全屏绘制、键盘事件监听等行为。这类程序通常要求分配伪终端（pty），否则会退化为非交互模式或直接报错。智能体要驱动它们，不能只发送普通管道输入，而需要维持一个带 pty 的持久会话，处理光标定位、转义序列和窗口尺寸变化。这也是为什么终端智能体比纯文本代码生成复杂得多，会话管理的稳定性直接决定交互式程序能否被可靠操控。

谁该关注它

如果你已经在用 AI 编程工具，但厌倦了「复制-粘贴-切窗口」的往复，Zerg Client 的窗格模型提供了另一种交互范式。它目前是评估测试版，且仅面向 Apple 芯片 Mac，适合愿意尝鲜、能接受早期产品稳定性的开发者。

对于更广泛的团队，暂时观望更稳妥——多智能体协同的权限与可靠性，往往要在真实项目中才能看清。