GridBash：把多个 coding agent 放进同一个终端网格
多 agent 工作流最容易变乱的地方，不是“能不能同时开几个终端”，而是同时开了以后谁在跑什么、哪个 pane 能安全接着改、哪段输出值得转给另一个 agent。普通 terminal multiplexer 可以把窗口切开，但它不理解 Codex、Claude、Gemini 这类 CLI agent 的启动、认证、项目目录、工作区隔离和恢复需求。
今天推荐的 jasonsuhari/gridbash 就是围绕这个问题做的一个小工具。它是一个本地 terminal grid，用真实 PTY pane 并排运行多个 CLI coding agents，目标不是取代 tmux，而是把 agent workspace 的常见操作做成专门入口：选择 profile、分配项目、启动 2x3 或更多 pane、给每个 pane 建独立 git worktree、保存 session，必要时再恢复。
按 GitHub repository page、README、releases/tags 页面、公开 git history、LICENSE、Cargo.toml、package.json 和 scout 返回的 GitHub 搜索字段在 2026-07-20 能核验的公开信息，jasonsuhari/gridbash 当前有 137 stars、5 forks。GitHub 显示主要语言为 Rust，许可证是 MIT。GitHub embedded data 中的仓库创建时间是 2026-07-05 22:46:52 UTC；公开 git history 的首个提交是 92f1bbb，提交时间 2026-07-05 21:43:36 UTC，提交信息为 feat: build rust agent multiplexer。默认分支 main 的当前提交是 6be3817，提交时间 2026-07-20 00:26:27 UTC，提交信息为 Merge pull request #281 from jasonsuhari/feat/agent-port-inspector；scout 从 GitHub 搜索结果记录到的 latest pushed 时间是 2026-07-20 00:26:29 UTC。GitHub releases 页面顶部是 v0.3.0-nightly.20260719.21.g6463f7a7c702，tag 时间为 2026-07-18 17:03:21 UTC；当前 npm/Cargo 稳定版本是 0.2.0，README 也提示 npm 版本可能暂时落后于最新 GitHub release。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | jasonsuhari/gridbash |
| 定位 | 本地多 CLI agent 终端网格和协调工作区 |
| Stars | 137 |
| Forks | 5 |
| 主要语言 | Rust |
| 许可证 | MIT |
| GitHub 创建时间 | 2026-07-05 22:46:52 UTC |
| 公开 Git history 起点 | 2026-07-05 21:43:36 UTC，首个提交 92f1bbb |
| 当前 main 提交 | 6be3817，2026-07-20 00:26:27 UTC |
| latest pushed | 2026-07-20 00:26:29 UTC |
| 最新 GitHub release/tag | v0.3.0-nightly.20260719.21.g6463f7a7c702，tag 时间 2026-07-18 17:03:21 UTC |
| 稳定包版本 | 0.2.0 |
| 关键词 | terminal grid、CLI agents、PTY、worktrees、session restore、local-first |
它解决的是“并行以后怎么管”
很多人已经在手动跑多 agent：一个终端让 Codex 看测试，一个终端让 Claude 重构，一个终端自己跑 pnpm test，旁边再放一个 shell 查日志。这个办法能用，但规模稍微扩大就会有问题。你需要记住每个 pane 的目录、状态、认证 profile、是不是已经改了同一批文件，以及哪个输出是可以复制给另一个 agent 的事实。
GridBash 把这个流程前移到启动阶段。README 里的直接例子是 gridbash 2x3 --profile codex，可以启动一个六 pane 的 Codex grid；也可以用 --count 12 --layout auto --profile claude 让它自动排布更多 pane。更关键的是 --worktrees：它要求当前 git repo 至少有一次提交且没有 tracked modifications，然后给每个 pane 建独立 repo-local worktree，降低多个 agent 写同一个工作区时互相踩文件的概率。
这不是一个花哨 UI 点子，而是很实际的工作流约束。多 agent 真正麻烦的地方通常不是 terminal split，而是并行写代码时的文件边界和状态恢复。GridBash 选择把 worktree isolation 做进 launch path，说明它理解 agent 并行的主要风险在哪里。
profiles 让它更像 agent launcher
README 列出的 agent profiles 很宽：Codex、Claude、Gemini、Aider、OpenCode、Goose、Amp、Cursor、Copilot，也支持 shell 和 custom commands。它不会把这些 agent 自己打包进去，也不会替换系统里的 codex 或 claude 命令；GridBash 做的是发现 profile、选择认证配置、设置项目目录，然后用真实 PTY 启动它们。
这点很重要。terminal multiplexer 只知道进程和窗口，通常不知道“这是某个 agent 的一个受管 pane”。GridBash 至少把启动流程做成了 agent-first：你可以先选兼容的 managed auth profile，再选项目、layout、worktree policy。对经常在多个代码库、多个模型工具之间切换的人来说，这比手写一堆 tmux 脚本更容易维护。
安装路径也比较轻。README 要求 Node.js 18+，npm install -g gridbash 后运行 gridbash，npm package 会安装当前平台对应的 native binary。release 覆盖 Windows x64、glibc Linux x64/arm64、macOS 13+ Apple Silicon 和 Intel。源码层面它是 Rust 2024 edition，Cargo.toml 里用到 ratatui、portable-pty、crossterm、vt100、tokio 等依赖，这也符合它“终端 UI + PTY 管理”的定位。
session 恢复比看起来更有用
Agent 任务经常不是五分钟就结束。你可能让一个 pane 跑迁移计划，让另一个 pane 查历史 issue，第三个 pane 修测试，自己中途关了终端或换了网络。GridBash 的 README 里把 resume、background panes、crash recovery 放得比较靠前，这说明它不只是启动器。
gridbash resume 可以选择保存过的 session，gridbash resume --latest 可以恢复最近一次。设置里也可以让 GridBash 关闭 UI 后保持 terminal processes 继续跑，稍后再 reconnect。意外关闭时，下一次普通 gridbash 启动会尝试恢复未完成的 agent sessions，并按 working directory 分组到 tabs。
这个能力适合长跑任务。对 agent 来说，连续性很脆弱：一旦 terminal 丢了，很多现场信息也没了。即使最终仍然要靠 git diff、日志和测试来确认结果，能把 pane 和输出恢复回来，已经能少掉很多重复解释。
本地 control API 是值得观察的部分
GridBash 还有一个可选的 agent control API。README 里的用法是 gridbash --agent-api 2x3 --profile codex，再让 agent MCP server 运行 gridbash --mcp。这个 API 可以提供轻量 grid snapshot、读取特定 pane 的有界近期输出、发送命令、capture 或持续记录 pane、更新 status bar 等。
这里的边界写得比较谨慎：API 是 localhost-only、token-authenticated、默认关闭；discovery metadata 不包含 bearer token；ctl list 和 ctl panes 是只读，send、capture、status、focus 需要 token 或 GRIDBASH_CONTROL_TOKEN。README 也强调返回给 agent 的 peer context 是不可信上下文。
这比“让每个 agent 盲目读其他 agent 的输出”更合理。多 agent 协作最危险的地方之一，是把另一个 pane 的草稿、错误推理或未验证日志当成事实。GridBash 的 pull-based 设计至少给了一个明确边界：agent 在需要协调时请求快照，人类或 manager 决定何时让它读取和行动。
为什么值得 Gumi 记录
Gumi 最近写过不少 agent memory、code search、MCP server。GridBash 和这些工具不同，它不试图让 agent 更聪明，而是整理 agent 的运行现场。换句话说，它处理的是“多个 agent 在同一台机器上怎么有秩序地工作”。
这个方向会越来越重要。单 agent 的体验成熟以后，下一步自然是把任务拆给多个 agent：一个查文档，一个改代码，一个写测试，一个做 review。但如果底层仍然只是随机开六个 terminal，效率提升很容易被状态混乱吃掉。GridBash 的价值在于把这些低层摩擦做成了专门工具，而不是要求每个人自己拼 tmux、shell script 和记忆力。
它也足够小众。137 stars、5 forks，仓库刚创建半个月左右，却已经有稳定包、nightly tags、Windows/Linux/macOS binary、README、reference docs、release flow 和 community links。这个阶段很适合观察：项目还没有大到成为“显而易见的趋势”，但已经有真实可试的形态。
需要注意的地方
第一，项目非常年轻。GitHub 创建时间是 2026-07-05，当前 main commit 到 2026-07-20 仍然在快速变化，release 页面顶部也是 nightly。README 写到 npm badge 显示的是 registry 当前版本，如果暂时落后于 GitHub release，可以使用对应 native artifact。这意味着安装和版本选择上要留意稳定版与 nightly 的差异。
第二，GridBash 不安装 agent 本身。Codex、Claude、Gemini、Aider 等 CLI 仍然需要你自己在系统里准备好。它负责 profile 和 pane，不负责解决每个 agent 的账号、权限和模型配置。
第三，worktree isolation 不是自动合并策略。每个 pane 分到独立 worktree 可以减少互相覆盖，但最后仍然需要人来 review diff、跑测试、决定合并顺序。多 agent 并行不是把冲突消失，而是把冲突推迟到更可控的位置。
第四，它依赖现代终端能力。README 写到目标是 UTF-8、ANSI/xterm-compatible terminals，SSH 或 tmux 下也能工作，但 remote session 需要 color-capable TERM；TERM=dumb 和 Linux kernel console 不支持。鼠标事件转发不好的环境还需要 --no-mouse。
总结
GridBash 的有趣之处，不在于“终端里又多了一个 grid”，而在于它把 agent 并行的几个真实问题放到了一起：启动 profiles、真实 PTY、worktree 隔离、session restore、background panes，以及可选的本地 control API。
如果你的日常已经从“让一个 agent 改代码”变成“同时让几个 agent 分工”，jasonsuhari/gridbash 值得试一下。它不保证多 agent 一定更聪明，但它能让并行现场更可见、更可恢复，也更不容易变成一堆没人记得状态的终端窗口。