这延续了 Paneflow 0.8.0 在 Linux 上发布的终端引擎迁移。Paneflow 现在默认在 Linux x86_64、Linux ARM64 和 Windows x64 MSVC 上使用同一个 Ghostty VT 核心。Alacritty 仍在每个平台上作为显式恢复后端提供，并继续作为 macOS 和不受支持目标上的默认选择。

Ghostty 引擎现在运行在 ConPTY 上

Paneflow 在 VT 引擎层集成 Ghostty。libghostty-vt 解析终端序列，维护网格和光标状态，处理字素、换行和重排，并对键盘与鼠标输入进行编码。窗口、窗格、会话、进程生命周期、持久化和 GPUI 渲染仍由 Paneflow 管理。

Windows 移植为该引擎增加了原生主机。Paneflow 通过 portable-pty 打开伪终端，它在 Windows 上使用 ConPTY，然后将 UTF-8 输出交给 libghostty-vt。在 GPUI 绘制之前，Ghostty 状态会被复制到拥有所有权的 Rust 快照中。Paneflow 没有嵌入 Ghostty 应用、它的界面或渲染器。

这种边界划分在 Windows 上很重要。ConPTY 负责 Shell 连接和操作系统的进程约定，Ghostty 负责解释终端，Paneflow 负责产品和最终像素。因此，同一个与后端无关的渲染器可以显示 Alacritty 或 Ghostty 会话，无需增加 Windows 专用渲染路径。

移植需要完整的 Windows 生命周期

能在 Windows 上编译静态库只是第一步。终端会话还需要为 PowerShell、命令提示符、TUI 和编码智能体确定性地处理启动、调整大小、输出排空、关闭以及后代进程清理。

Windows Ghostty 主机会合并 ConPTY 的尺寸调整，在关闭会话前排空最终输出，在退出前等待读取线程结束，并在多个窗格同时产生输出时限制背压。Paneflow 0.8.1 还会批量处理 Windows Ghostty 的重绘，避免不必要的渲染工作。

输入也通过同一个边界。该集成覆盖 Ghostty 键盘编码、AltGr、死键、IME 提交、粘贴、剪贴板、鼠标、焦点和链接。0.8.1 中最后两个修复会保留通过 ConPTY 的多行 Shift+Enter 输入，包括使用该快捷键插入换行的编码智能体提示词。

Paneflow 内置固定版本的静态 MSVC 构件

官方 Windows x64 构建包含固定版本的 ghostty-vt-static.lib 归档。其源代码提交、Zig 工具链、头文件、生成的 Rust 绑定、符号、构建元数据、许可证和校验和都在仓库中跟踪。

用户无需安装 Ghostty、Zig、DLL 或其他运行时。标准 MSI 在 Paneflow 构建期间使用经过验证的归档，最终可执行文件会静态链接该引擎。原生重建与消费该归档的 Windows 构建保持分离，使 CI 能在发布前发现源代码、ABI 或构件漂移。

Paneflow 将原始 C ABI 限制在 -sys crate 内，并在其上提供安全的 Rust 所有权。原生句柄由对应的 Ghostty 分配器释放，回调 panic 被限制在 FFI 边界内，借用的 Ghostty 行或单元格不会越过终端锁的生命周期或帧边界。

Ghostty 自动启用，Alacritty 只需一项设置即可恢复

Windows 上的 terminal.backend 接受三个值：auto、ghostty 和 alacritty。在 Paneflow 0.8.1 官方 x64 构建中，auto 和 ghostty 都会选择 Ghostty 引擎。若要为新建会话强制使用之前的后端，请在 paneflow.json 中设置 alacritty：

{
  "terminal": {
    "backend": "alacritty"
  }
}

该设置只适用于新会话。如果 Ghostty 在 Shell 进程创建前失败，Paneflow 可以回退到 Alacritty 一次。进程启动后，会话不会切换后端，Paneflow 也不会在后台再启动第二个 Shell。

这条恢复路径让终端故障保持局部且可逆。你可以在不重新安装 Paneflow、不更改工作区数据的情况下回到 Alacritty，并在问题查明后重新切换到 auto。

Linux 与 Windows 共用一个终端核心

Paneflow 0.8.0 在 Linux 上建立了引擎边界。0.8.1 表明，即使 PTY 和进程模型差异很大，这条边界也能跨平台工作，而无需将平台细节带入渲染器或工作区模型。

Windows ARM64 不在本次发布范围内，仍使用 Alacritty。macOS 在单独评估 Ghostty 路径期间也继续使用 Alacritty。在受支持的 Linux 和 Windows 构建上，auto 现在含义一致：Ghostty 负责终端核心，GPUI 负责渲染，Paneflow 负责其周围的多智能体工作区。

安装 Paneflow 0.8.1，打开一个新窗格，然后运行你日常使用的 PowerShell、WSL Shell、TUI 或编码智能体。如果终端行为出现回归，请将新会话的 terminal.backend 设置为 alacritty，并报告 Shell、Windows 版本、命令以及最短复现步骤。

这次迁移更换的是解释 VT 数据并维护终端状态的引擎，不是外围工作区。PTY、进程生命周期、GPUI 渲染器、面板、会话、智能体状态、diff 和持久化仍由 Paneflow 管理。macOS 和 Windows 继续使用 Alacritty。

Ghostty 作为 VT 引擎加入 Paneflow

在 Paneflow 0.7.x 及更早版本中，终端会话基于 Rust crate alacritty_terminal 0.26。这个引擎负责转义序列、网格、回滚缓冲区、输入模式、搜索以及一部分渲染模型。

新的 Linux 路径使用 Ghostty 的可嵌入终端引擎 libghostty-vt。它解析 VT 序列，维护光标与屏幕状态，处理字素、自动换行和 reflow，编码键盘与鼠标输入，并向宿主应用公开增量渲染状态。

Paneflow 没有嵌入 Ghostty 应用、GTK 界面或渲染器。Ghostty 提供终端核心，Paneflow 将其状态转换为自有的 Rust 快照，再通过现有 GPUI 渲染器绘制。因此，产品界面和多智能体工作流仍由 Paneflow 控制。

使用 Paneflow 自有边界分离引擎与产品

替换解析器只是部分工作。Alacritty 类型已经进入 PTY 循环、渲染、搜索、选择、链接、回滚缓冲区恢复和会话生命周期。如果不先解除耦合，只替换依赖，就会把同一个问题转移到新引擎。

Paneflow 现在公开自有的终端会话边界。Alacritty 和 Ghostty 都会生成相同的 Paneflow 命令、事件、模式、搜索结果和渲染快照。渲染器不再需要知道某个单元格来自哪个引擎。

这条边界是迁移中更持久的成果。Linux 可以先行切换而不改变 macOS 或 Windows，未来更新引擎时，应用其他部分也不必采用引擎的内部类型。

将不稳定的 C API 限制在小型 Rust 封装中

Ghostty 将 libghostty-vt 描述为功能成熟，但其 API 签名仍在变化。因此，Paneflow 固定了 Ghostty 的准确提交 ae52f97d，以及 C header、生成的 bindings、Zig 版本、构建配置和归档校验和。

原始 C ABI 被隔离在单独的 -sys crate 中。第二层安全封装拥有每个原生 handle，在创建终端前验证 API 版本与 C layout，拦截 callback panic，并通过匹配的 allocator 释放 Ghostty 分配的内存。

所有权规则在渲染期间尤其重要。libghostty-vt 公开借用的行与单元格，后续终端变更可能使其失效。Paneflow 在终端锁定期间复制所需数据，再向 GPUI 提供自有的 Rust 快照。任何 C 指针或借用 slice 都不会跨越锁或帧边界。

这套策略比跟随未固定的依赖需要更多维护。每次 Ghostty 更新都必须为两种 Linux 架构重新生成并审查 header、bindings、静态归档、校验和、符号及许可证。这项成本保持明确且范围可控，不会变成运行时的不确定性。

Alacritty 继续作为差异测试基准和回滚路径

用户可见的目标是保持连续性。shell、编码智能体、全屏 TUI、搜索、选择、剪贴板操作、回滚缓冲区、OSC 事件、调整大小、reflow 和进程退出，都应在引擎更换后保持原有行为。

Paneflow 以多种分块大小向 Alacritty 和 Ghostty 输入相同的确定性 VT 流，然后比较标准化快照和有序事件。独立 fuzzing 目标覆盖格式错误或截断的序列、输入编码、调整大小、reflow，以及一个序列被拆分到多次 PTY 读取中的边界。包检查还会拒绝运行时依赖 libghostty.so、构建身份错误或缺少已审查原生声明的 Linux 构建产物。

Alacritty 并未被移除。要在新建 Linux 会话中使用它，请在 paneflow.json 中设置 backend：

{
  "terminal": {
    "backend": "alacritty"
  }
}

运行中的会话不会在内存中切换引擎。更改设置后，请关闭该会话并打开新面板。auto 在标准 Linux 构建中选择 Ghostty，在 macOS、Windows 或使用 --no-default-features 编译的 Linux 构建中选择 Alacritty。

静态链接，无需安装 Ghostty

官方 Linux 包含有针对 x86_64 或 ARM64 固定的静态 libghostty-vt 归档。机器上无需安装 Ghostty、Zig 或共享库。从干净的 Paneflow checkout 执行普通 cargo build 时，也会使用仓库内经过验证的归档，build.rs 不会下载原生源代码。

Linux 是首个启用此 backend 的平台。扩展到 Windows 或 macOS，以及未来是否移除 Alacritty，都是独立决策。Paneflow 0.8.0 将影响范围控制在较小范围：1 个新默认值、2 个受支持引擎，并且新会话可以立即回滚。

更新到 Paneflow 0.8.0，打开新面板，然后运行常用的 shell、TUI 或编码智能体。如果终端行为出现回归，请将新会话切回 Alacritty，并在报告中注明命令、Linux 发行版以及使用的是 Wayland 还是 X11。

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

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

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

Demo video: /videos/paneflow-landing-demo.mp4

完整演示也可以在 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，打开一个项目，在两个面板里启动两个智能体，看看这个工作区是否减少了你已经开始接受为正常的认知负担。

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

Demo video: /videos/paneflow-conductor-demo-linkedin.mp4

用一个 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 给它们的是一个共同操作面，而不是又一个私有协议。

Demo video: /videos/paneflow-diffview.mp4

审查分支的全部改动

从侧边栏打开 Diff 视图，或按 Ctrl+Shift+G。Paneflow 会显示自与基线分支分叉以来所有改动过的文件，包括尚未提交的改动。

可以逐个浏览改动块，对比新增与删除，在统一视图和左右并排视图之间切换。文件头在滚动时保持吸顶，语法高亮使用 Tree-sitter，也就是 Zed 和 GitHub 所用的同一个解析器。

对比多个分支，无需切换 worktree

项目视图显示当前任务的 diff。Multi-project 视图把打开的仓库汇集到各个标签页中。Worktree 视图把相邻分支并排摆放，每个分支对应一个 git worktree，让你对比它们的进展，而无需逐个检出。

请多个智能体审查

每个分支都有一个 Review 按钮。选择 Claude Code、Codex、OpenCode 或 Pi，Paneflow 就会为每个智能体打开一个真正的终端，直接位于 diff 下方，工作目录也正确无误。

Paneflow 会准备好审查提示词，但未经你同意绝不发送。你可以在按下 Enter 之前先核对一遍。智能体随后分析 diff，回报与相关文件和行号关联的意见。

启动两个智能体，就能对同一处改动得到两种不同的解读。第二个会拿到一份更挑剔的指令，以减少过于雷同的回答。

也可以把某一行或某个改动块单独发给智能体，向它提出针对性的问题。

在 Paneflow 中审查你的下一个分支

Diff 视图和智能体审查自 Paneflow 0.3.7 起提供，是智能体会话之后的下一个版本。下载最新版本，打开一个项目，然后在侧边栏中选择 Diff。

Demo video: /videos/sessions-agents.mp4

找回正确项目的会话

Paneflow 会检测与当前工作目录关联的 Claude Code、Codex 和 OpenCode 会话。它们按智能体分组，不会混入其他项目的对话。

选中一个会话，Paneflow 就在当前面板中恢复它，历史记录完好无损。

回到任务，无需从头开始

一个会话承载着与智能体的交流、做出的决策，以及已经搭建好的计划。能够离开再恢复它，意味着可以在任务之间切换，既不丢失上下文，也不必重复同样的说明。

可以关闭一个面板、重启 Paneflow，或稍后再回到项目。需要时，有用的会话依然在那里。

在 Paneflow 中恢复下一个会话

智能体会话自 Paneflow 0.3.6 起提供，与 Files 侧边栏同属一个版本。下载最新版本，在项目中运行一个智能体，然后在 Paneflow 中找回它的会话。

Demo video: /videos/paneflow-dock.mp4

浏览当前项目

从 Files 按钮打开侧边栏，显示项目的文件夹和文件。文件树会自动跟随当前工作区，磁盘上的文件发生变化时同步更新。

被 .gitignore 忽略的条目仍然可见，但会变暗，让有用的文件更突出。Paneflow 还会跨重启记住已展开的文件夹。

在面板中阅读 Markdown

点击一个 README、PRD 或其他 Markdown 文件，它会渲染后在一个面板中打开。这样就能把说明、计划，以及使用它们的智能体放在同一套布局里。

其余文件也会列出，让你快速了解项目结构，而不会把 Paneflow 变成一个完整的文件管理器。

让文档贴近你的智能体

Files 侧边栏自 Paneflow 0.3.6 起提供，与智能体会话同属一个版本。下载最新版本，打开一个项目，用 Files 按钮浏览它的内容。

Paneflow 正是从这个问题出发：多个智能体需要一个为保持它们可理解而设计的工作区。

一个任务不止是一个终端

一个任务可能汇集一个智能体、一个 git 分支、一个开发服务器、一些测试、一份 diff，以及多个会话。如果这些东西四散各处，那么每次切换窗口，你都得重建它们的上下文。

Paneflow 把它们集中到同一个工作区，并在你回来时恢复这套环境。你找回的不只是一个打开着的终端，而是你离开时的那个任务原样。

智能体可以互相协助，而不接管彼此

Paneflow 的 MCP 服务器暴露三个只读工具，list_panes、read_pane 和 search_pane，让一个智能体能读取另一个面板的输出。它可以核对一个测试、搜索一处报错，或查看另一个智能体的工作，而你无需复制粘贴它的内容。

这条通道刻意保持只读。智能体之间可以共享上下文，却无法相互输入命令。决策和操作的控制权始终在你手中。

一个你能理解的本地工具

Paneflow 在本地运行，没有账户，也没有遥测。它的代码在 GPL-3.0-or-later 许可证下提供。

这个选择很简单：运行你的智能体、承载你工作上下文的那个空间，理应保持快速、透明，并由你掌控。

在你的下一个项目上试试这套思路

下载 Paneflow，把你下一个任务的智能体、终端和工具集中到一个工作区里。

Paneflow 把你的编码智能体、它们的终端，以及围绕它们的一切，集中到一个本地优先的工作区里。

每个任务一个工作区

让 Claude Code、Codex、OpenCode 和另外 13 个 CLI 智能体在并排的面板中运行。加入任务需要的测试、开发服务器或命令，再把这个工作区绑定到它的 git 分支。

每个工作区都保留自己的布局、终端和会话。可以在任务之间切换，或重启 Paneflow，而无需重建你的环境。

上下文始终可见

• 智能体与终端： 看到一切正在运行的内容，用键盘在面板之间切换。
• 分支与 diff： 让每个任务都绑定到它的分支，审查它的改动，无需离开 Paneflow。
• 智能体会话： 为当前项目找回并恢复 Claude Code、Codex 和 OpenCode 会话。
• 面板间上下文： 借助内建的 MCP 服务器，一个智能体可以读取另一个面板里的测试输出或搜索其中的报错，无需复制粘贴。
• 本地环境： 没有账户、没有遥测，也不强加任何远程服务。

一个为持久而生的原生应用

Paneflow 用 Rust 编写，使用 Zed 的渲染引擎 GPUI。面板和终端由应用直接渲染，没有嵌入式浏览器去包裹那些可能要运行数小时的进程。整个应用的下载体积为 14 到 19 MB。

项目在 GPL-3.0-or-later 许可证下开源，可在 Linux 和 macOS 上运行。原生 Windows 版本也在计划之中。

在 Paneflow 中启动你的下一个智能体

下载 Paneflow，打开一个项目，为你想要推进的任务创建一个工作区。