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

[Paneflow 0.6.0](https://github.com/ArthurDEV44/paneflow/releases/tag/v0.6.0) 发布的 Paneflow Conductor 让这种协调变得明确。一个智能体可以通过公开的 `paneflow` CLI 发现其他智能体、读取它们的输出、发送下一个 prompt，并等待当前 turn 完成。

## 用一个 CLI 管理整支队列

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

```bash
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 文档](/zh-Hans/docs/conductor)。先从两个面板开始：一个实现智能体、一个 review 智能体，以及一个在发送下一个 prompt 前读取两者的 conductor。

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