用 Paneflow Conductor 让一个编码智能体驱动其他智能体

启动一个编码智能体很简单。并行启动多个智能体后，问题会变成协调：哪个正在工作、哪个在等待、哪个分支正在变化、哪个结果应该进入下一步。

Paneflow 0.6.0 发布的 Paneflow Conductor 让这种协调变得明确。一个智能体可以通过公开的 paneflow CLI 发现其他智能体、读取它们的输出、发送下一个 prompt，并等待当前 turn 完成。

用一个 CLI 管理整支队列

所有操作都经过 Paneflow 的本地 socket。Conductor 可以是 Claude Code、Codex、OpenCode、Gemini，也可以是一个脚本，因为接口只是 shell 命令。

paneflow ps
paneflow status claude-impl
paneflow read claude-impl --lines 120
paneflow send claude-impl "Keep going and finish with REPORT_DONE"
paneflow wait --match claude-impl --pattern '^REPORT_DONE'
paneflow watch

这就是关键变化。Codex 可以检查 Claude Code 产出的内容。Claude Code 可以把 review 任务交给 OpenCode。脚本可以启动同一个 workflow，而不必关心每个面板里运行的是哪个 harness。

对于可重复的工作，paneflow up 可以从 TOML 文件启动带 hook 的工作区，paneflow flow run 可以执行包含 spawn、wait、feed 和 review 的多智能体 pipeline。

委托任务，不隐藏终端

Paneflow Conductor 不替代智能体，也不会把 Paneflow 变成托管 runtime。面板仍然是真实终端。你可以读取、接管、停止命令，或改变方向。

价值在于，智能体不再需要靠复制粘贴获取上下文。Conductor 智能体可以读取相邻面板，理解当前状态，发送聚焦的 follow-up，然后等待 REPORT_DONE 这样的 sentinel 后再继续。

当你把实现、review、测试和文档拆开时，这个 pattern 很有用。leader 智能体不需要从过期笔记里猜测。它可以直接检查真实队列。

等待状态，而不是等待计时器

Paneflow 0.6.0 为带 hook 的智能体加入了按 turn 跟踪的状态机。面板可以报告 thinking、waiting_for_input、finished 等状态。paneflow watch 会把生命周期事件以 JSONL 形式 stream 出来，paneflow wait 会在条件满足时返回，而不是等待任意 sleep。

这是编排和 screen scraping 的区别。Conductor 不应该每隔几秒 poll 一次终端，然后猜输出已经稳定。它应该在智能体真正停止、请求输入或打印约定 marker 时响应。

让控制边界保持可见

安全模型是刻意设计的。MCP bridge 只读。paneflow read 会把 peer 输出视为不可信数据。默认情况下，paneflow send 只会预填 prompt，仍然由人按下 Enter。

Auto-submit 存在，但必须通过 scripting gate 或 AI free access mode 主动开启。这样，隔离 worktree 和可信 workflow 仍然可以使用强能力，但静默的跨面板写入不会成为默认行为。

这条边界就是重点：给智能体足够的共享上下文来协作，同时让终端保持可见，并让人随时可以接管。

从一支小队列开始

完整参考在 Conductor 文档。先从两个面板开始：一个实现智能体、一个 review 智能体，以及一个在发送下一个 prompt 前读取两者的 conductor。

如果你已经在并排运行多个 CLI 智能体，Paneflow Conductor 给它们的是一个共同操作面，而不是又一个私有协议。