启动一个代码智能体已经很常见了。你打开终端，输入一条命令，Claude Code、Codex、OpenCode 或其他 CLI 就开始工作。

问题出现在你同时启动多个智能体之后。

一个智能体在修 bug。另一个在准备重构。第三个在 review diff。旁边还有开发服务器在跑，测试通过或失败，每个终端都在讲述项目状态的不同部分。到某个时刻，难点不再是启动智能体，而是知道哪个在做什么、哪个在等你输入、哪个已经完成、它们分别在哪个分支上工作。

Paneflow 就是从这个问题开始的：把多个代码智能体放进一个本地工作区里，让它们保持可见、可控、可理解。

完整演示也可以在 <img src="/icons/youtube.webp" alt="" width={20} height={14} className="!my-0 mr-1 inline !h-4 !w-auto !rounded-none !border-0 align-[-2px]" />[YouTube](https://www.youtube.com/watch?v=hElqzB2XMn0) 上观看。

发布讨论在 Hacker News 上：<img src="/icons/y-combinator.webp" alt="" width={16} height={16} className="!my-0 mr-1 inline !h-4 !w-4 !rounded-none !border-0 align-[-2px]" />[Show HN: Paneflow](https://news.ycombinator.com/item?id=48735123)。

## 只有终端并不总是够用

我喜欢终端。tmux、Zellij、Ghostty、Kitty 和 WezTerm 都是很好的工具，尤其是在 SSH 或远程机器上工作时。

但当你在同一个项目里运行多个本地智能体时，问题会变。终端网格能显示进程，却不会真正告诉你哪个智能体正在思考、哪个在等你批准、哪个生成了值得看的 diff、哪个正在重复另一个智能体的工作。

窗口足够多时，你会开始在脑子里重建项目状态。你在终端之间切换，重新读 scrollback，找到正确目录，确认当前分支，再回到 diff。偶尔一次不是大问题。但当这成为主要工作方式时，成本就会变高。

Paneflow 不是要替代你的编辑器。它替代的是很多开发者手动搭出来的协调层：splits、窗口命名、分支约定，以及大量短期记忆。

## 每个任务一个工作区，而不只是每条命令一个面板

在 Paneflow 里，面板仍然是真正的终端。你可以运行 Claude Code、Codex、OpenCode、Grok Builder，或者任何能在 shell 里运行的 CLI。

区别在终端周围。

一个任务可能包含智能体、测试、开发服务器、git 分支、diff 和之前的会话。Paneflow 把这些部分放在同一个工作区里，这样你每次切换上下文时都不必重新寻找。

当你想隔离工作时，每个任务都可以运行在自己的 `git worktree` 里。Review 视图会把 diff 并排展示，一列对应一个 worktree。你不用切换窗口、分支或编辑器，就能看到每个智能体产出了什么。

当两个智能体在代码库中相邻的位置工作时，这种组织方式尤其有用。你可以保持它们的输出打开，比较它们的修改，然后决定保留、修正还是丢弃。

## 协调通过 CLI 界面完成

Paneflow 最重要的赌注不是显示，而是协调。

我把这一层叫做 Paneflow Conductor。现阶段，我暴露给智能体的能力会刻意通过 CLI 界面和本地 socket。GUI 仍然是你监督、阅读和接管任何面板的地方。

`paneflow ps` 会列出正在运行的面板和智能体，并带上它们的真实状态。`paneflow watch` 会以 JSONL 流式输出变化，这些变化来自 hooks 和 event bus，而不是反复轮询终端。智能体可以观察当前运行的内容，等待事件，为另一个面板准备 prompt，然后把最终发送留给你确认。

默认情况下，Paneflow 只会预填 prompt，按 Enter 的仍然是你。Auto-submit 存在，但需要主动开启。这个选择是有意的：当多个智能体能在同一个项目里行动时，人类控制必须保持可见。

## 智能体可以读取，但不能接管

另一个重要部分是内置的 MCP 服务器。它提供三个只读工具：`list_panes`、`read_pane` 和 `search_pane`。

实际使用中，一个面板里的 Claude Code 可以读取另一个面板里 Codex 刚刚产生的测试输出。智能体可以在相邻终端里搜索错误，然后再提出修复建议。你不再需要把一个工具的输出复制粘贴到另一个工具里。

边界很严格：这个桥不能写入面板，也不能替你操控智能体。终端输出会被当作不可信内容处理，因为智能体 transcript 或代码仓库里可能包含恶意文本。Paneflow 让上下文共享更明确，但不会把每个终端都变成开放的执行入口。

我关心的正是这条边界：给智能体足够的上下文，让它们不要盲目工作，同时不把整个会话的静默控制权交给它们。

## 为什么是原生应用

Paneflow 用 Rust 编写，使用 Zed 背后的 UI 框架 GPUI。这个选择来自一个很简单的约束：智能体可能运行很久，有时还会并行运行，承载它们的地方必须保持轻量。

我不想把已经在运行重进程的终端再包进 Electron 应用里。我也不想做成 macOS-only 工具，因为我自己的工作会在 Linux 和 Windows 之间切换。今天，Paneflow 提供 Linux、macOS Apple Silicon 和 Windows x64 构建。macOS Intel 和 Windows ARM64 还没有发布。

它的结果不是一个 IDE。它是一个本地、开源的工作区，给那些已经会使用 CLI 智能体、但不想再手动协调一切的开发者。

## 在下一次多智能体会话中试试 Paneflow

如果你只是偶尔启动一个智能体，现在的终端很可能已经够用。

如果你开始并行运行多个智能体，问题就会变成：如何让它们的状态可读、分支分离、diff 可审查、上下文可共享，同时不失去控制？

这正是 Paneflow 想解决的问题。

下载 Paneflow，打开一个项目，在两个面板里启动两个智能体，看看这个工作区是否减少了你已经开始接受为正常的认知负担。