最近一批 AI 编码工具有个很明显的分叉。

  • 一类继续把重点放在“单个 agent 怎么更聪明”；
  • 另一类开始认真面对“多个 agent 同时工作时，现场到底怎么管”。

如果你已经不是只开一个 Claude Code 或 Codex 窗口，而是会同时跑实现、审查、实验、对照几路任务，那么第二类问题会越来越真实：

  • 哪个 agent 还在思考，哪个已经卡住；
  • 哪个分支和哪个工作区对应哪一个终端；
  • 哪些输出值得你立刻接管，哪些可以继续后台跑；
  • 不同 agent 的 worktree diff 怎么放在一起看；
  • agent 之间如果要互相参考终端输出，边界应该放在哪里。

今天想记下的 ArthurDEV44/paneflow，就是专门处理这类问题的。

按 GitHub 仓库页、release 页和 README 在 2026-06-29 能看到的公开信息，这个项目当前约有 25 stars、0 forks，创建于 2026-04-01，最近公开更新出现在 2026-06-29。仓库主语言是 Rust，基于 Zed 的 GPUI 构建，许可证为 GPL-3.0-or-later。最新 release 是 v0.7.2，发布时间为 2026-06-26。

项目概览

属性详情
仓库ArthurDEV44/paneflow
定位本地原生的多代理编码工作台
Stars25
Forks0
主语言Rust
UI 技术GPUI
创建时间2026-04-01
最近公开更新2026-06-29
最新版本v0.7.2
版本发布时间2026-06-26
许可证GPL-3.0-or-later
支持平台Linux、macOS Apple Silicon、Windows x64

它的重点不是“把 agent 聊天框做得更漂亮”，而是把现场状态摊开

README 对 Paneflow 的一句核心描述很准确：它是一个 native GPUI workspace for running coding agents in parallel。

这句话里最重要的不是 native，也不是 parallel，而是 workspace。

Paneflow 不是把终端换一层壳，也不是再发明一个托管式 agent runtime。它做的是把已经存在的 CLI agent 拉回真实终端里，然后补上一层人类在并行开发时最缺的观察面：

  • 真实 PTY pane，而不是被 UI 抽象掉的“聊天卡片”；
  • agent 当前是 thinking、waiting、stalled、failed 还是 done；
  • 每个 pane 对应哪个 workspace、哪个 branch；
  • 哪个任务正在要你接手，哪个任务只是安静运行。

这和很多“可以运行 AI”的终端工具不太一样。

很多产品的默认视角仍然是“一次对一个 agent 发消息”，Paneflow 的默认视角则更像“同一个项目里同时监督一组 agent 进程”。

它保留原始终端，而不是把运行态藏起来

我觉得 Paneflow 最务实的一点，是它没有试图把 CLI agent 重新包装成黑盒助手。

README 明确写的是：

  • Claude Code、Codex、Gemini、opencode 这类 CLI agent 可以直接跑在真实终端 pane 里；
  • 你仍然能看到原始 terminal 输出；
  • 你可以中断、接管、继续，而不是只能盯着某个高层摘要。

这个选择看起来保守，但其实非常关键。

因为在多代理编码现场里，最怕的不是信息太少，而是界面替你“总结”之后，把真正决定问题的那几行 stderr、测试输出、git diff 线索藏掉了。

Paneflow 的策略是：

  • 不遮蔽终端；
  • 不伪装成托管式 agent 云服务；
  • 先保留可见性，再往上叠加状态语义和控制面。

这比纯聊天式入口更适合真正调试代码的人。

Attention Queue、Rosetta 和通知面板，本质上是在降低监督成本

一旦 agent 数量多起来，人最痛苦的不是启动，而是监督。

Paneflow 在 README 里给出的几块能力，都是围绕这个痛点设计的：

  • sidebar 和 tab dots 用来快速标记不同 pane 状态；
  • desktop notifications 提醒真正需要接手的事件；
  • Attention Queue 把等待输入、运行中、出错、完成这些状态汇总成队列；
  • Rosetta 作为 app 内的状态汇总面，减少你在 pane 之间来回扫视。

这说明作者抓到的问题很现实。

并行 agent 工作流的瓶颈，往往不是“不能再开一个 agent”，而是“人脑没法一直维护 8 个终端窗口的最新状态”。Paneflow 想做的，就是把这些零散信号整理成一套更容易判断优先级的监督界面。

它把 CLI、JSON-RPC 和 flow.toml 连起来，开始具备真正的编排味道

Paneflow 不只是一个 GUI。

README 里列出的 paneflow CLI 已经暴露出很强的 orchestration 倾向：

paneflow ps
paneflow read cargo-run --lines 100
paneflow watch --json
paneflow send codex-review "Review this branch and report risks"
paneflow wait --surface claude-impl --pattern "REPORT_DONE"
paneflow flow run examples/review-pipeline.flow.toml

这意味着它的能力不只是“看”，而是开始覆盖：

  • 查询 pane 状态；
  • 读取 pane 输出；
  • 发送消息给指定 agent；
  • 等待某个状态或模式出现；
  • 运行声明式 flow。

尤其 flow.toml 这一层很值得关注。

一旦你能把 spawn、wait、send、capture、review 这些步骤放进 DAG 式流程，Paneflow 的角色就不只是多终端容器，而是一个 本地 agent orchestration runtime 的前端与控制面。

只读 MCP bridge 是一个很克制、也很聪明的边界设计

README 里另一个我很在意的点，是它提供了一个本地 read-only MCP bridge。

这个桥只暴露三类工具：

  • list_panes
  • read_pane
  • search_pane

也就是说，agent 可以读取别的 pane 的输出、理解现场信息，但不能通过 MCP 直接向别的 pane 注入命令或控制行为。

这个边界设计很成熟。

因为多代理协作里，真正有价值的往往是“上下文共享”，而不是“彼此拥有写权限”。Paneflow 把共享能力开放出来，却把控制能力继续留在更显式的路径上，这样既提升协作，又不至于把整个终端工作台变成一个权限边界混乱的黑箱。

README 还特别强调，返回给 agent 的终端输出会被包装成 untrusted data。这说明作者不只是想做联通，还在认真处理 prompt injection 和工具误用风险。

worktree diff review 让它不止是运行台，也开始靠近审阅台

另一个很实用的设计，是 Paneflow 会把不同 worktree 的结果并列展示，方便横向审阅。

这件事很重要，因为今天多代理开发越来越像这样：

  • 一个 agent 负责主实现；
  • 一个 agent 尝试更激进的重构；
  • 一个 agent 专门做 review 或补测试；
  • 人最后需要比较几份 branch/worktree 的差异，再决定保留什么。

如果工具只能帮你“同时跑”，却不能帮你“同时看结果”，那编排只完成了一半。

Paneflow 把 worktree diff、hunk navigation、review prompts、归属信息和成本估算放进同一套界面，等于承认了一件事：多代理开发的输出比较，本身就是第一等需求。

这不是 Electron，也不是云端平台，它刻意坚持本地优先

Paneflow 在 README 里多次强调几个取向：

  • Rust + GPUI；
  • Linux、macOS、Windows 原生构建；
  • No Electron；
  • No hosted agent runtime；
  • No WSL required。

这背后的产品判断很鲜明。

它不想和云端 agent 平台竞争，不想托管你的任务，也不想把原本熟悉的 CLI 工作流替换掉。它更像在说：

“你继续用自己熟悉的 agent、shell、workspace 和 branch；我只负责把并行现场变得可见、可监督、可编排。”

这个定位很清楚，也让它和一般的终端模拟器、单 agent AI IDE、以及云托管 agent 平台区分开来了。

它适合已经进入“多代理常态”的开发者

我觉得 Paneflow 最适合这些人：

  • 已经同时用 Claude Code、Codex、Gemini 或其他 CLI agent 的人；
  • 会认真用 branch / worktree 隔离不同任务的人；
  • 需要把 agent 输出、状态和 review 流程收进同一个窗口的人；
  • 想把 agent 协作进一步脚本化，但又不想把控制权完全交出去的人。

如果你还停留在“偶尔让一个 agent 帮我改个文件”的阶段，它可能显得偏重。

但如果你的日常已经变成：

  • 一个 agent 写实现；
  • 一个 agent 跑审查；
  • 一个 agent 验证回归；
  • 人在中间做调度、接管和最终判断；

那 Paneflow 的设计会显得非常合理。

也要承认，它还处在很早期的项目阶段

当然，这个项目目前也很新。

25 stars、0 forks、创建时间只有几个月，说明它仍然处在相当早期的公开阶段。好处是方向新、动作快、边界意识强；代价则通常是：

  • 交互细节可能继续快速变化；
  • 脚本接口和工作流还会收敛；
  • 文档与实际行为之间可能持续被打磨。

如果你需要的是一套已经高度稳定、被大规模组织验证过的工具，Paneflow 还不是那类产品。

但如果你正在寻找一个很认真地回答“多代理编码现场如何管理”的本地原生项目，它已经足够值得跟踪。

小结

ArthurDEV44/paneflow 最有意思的，不是它支持多少 agent 名字。

真正值得看的，是它对问题的定义：

  • 保留真实终端；
  • 给并行 agent 叠加可观察状态；
  • 用 CLI 和 flow 把编排能力开放出来；
  • 用只读 MCP 把跨 pane 协作限制在安全边界内；
  • 把 worktree review 也纳入同一套桌面工作台。

很多工具还在争论“agent 应不应该进 IDE”的时候，Paneflow 已经在认真处理另一个更实际的问题：

当你同时养着一群 agent 时，怎样不把自己先管理崩。