在 Show HN 上发布 Paneflow
启动一个代码智能体已经很常见了。你打开终端，输入一条命令，Claude Code、Codex、OpenCode 或其他 CLI 就开始工作。
问题出现在你同时启动多个智能体之后。
一个智能体在修 bug。另一个在准备重构。第三个在 review diff。旁边还有开发服务器在跑，测试通过或失败，每个终端都在讲述项目状态的不同部分。到某个时刻，难点不再是启动智能体，而是知道哪个在做什么、哪个在等你输入、哪个已经完成、它们分别在哪个分支上工作。
Paneflow 就是从这个问题开始的：把多个代码智能体放进一个本地工作区里，让它们保持可见、可控、可理解。
完整演示也可以在 
YouTube 上观看。
发布讨论在 Hacker News 上：
Show HN: Paneflow。
只有终端并不总是够用
我喜欢终端。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，打开一个项目，在两个面板里启动两个智能体，看看这个工作区是否减少了你已经开始接受为正常的认知负担。