多开 Claude Code 不等于并行协作：用 Shikigami 把每个 Agent 隔离进 Git worktree
当一个功能要改接口、补测试、查回归时，把几个 Claude Code 或 Codex 终端同时打开看起来很有效率。真正麻烦往往在十分钟之后：谁在等待你的确认？谁已经改了同一个文件？哪个会话明天还能接着跑？如果所有 Agent 共用当前分支，并行只是在把冲突和上下文切换提前。
Shikigami 是一款仍处于 Beta 的本地桌面应用，专门把这种「多个编码 Agent 同时工作」的场景做成可管理的工作台。它目前通过本机 CLI 运行 Claude Code 或 OpenAI Codex；每个 Agent 绑定独立的 Git worktree，并保留真实 PTY 终端。产品官网说明它面向 macOS 与 Linux，免费使用、无需账户或云端服务；HN 发布帖也明确表示源码目前不公开。因此更准确的称呼是免费本地桌面工具，而不是开源项目。
并行的关键不是多窗口，而是独立工作目录
Git worktree 让一个仓库同时拥有多个、指向不同分支或提交的工作目录。它们共用 Git 对象库，却不会把未提交改动混在同一棵工作树里。Shikigami 把这个隔离层放在每个 Agent 前面：同一个仓库可以派生若干独立工作区，每个会话只在自己的目录里读写。
例如，先在终端为三个明确的任务准备 worktree：
git fetch origin git worktree add ../app-auth -b agent/auth origin/main git worktree add ../app-tests -b agent/tests origin/main git worktree add ../app-docs -b agent/docs origin/main
这里的命令是 Git 原生命令，不依赖 Shikigami。启动应用后，应将这三项工作分别交给三个 Agent：认证改动、测试补齐和文档更新。任务边界仍然需要由人设计；worktree 解决的是文件改动相互覆盖，不会自动解决两个 Agent 对同一 API 做出不兼容设计的语义冲突。
把「正在跑什么」变成可见的调度面
Shikigami 的价值在于把 Agent 网格和代码审阅放进同一个桌面工作流。官网列出的能力包括：每个 Agent 一个真实 PTY、可在退出应用后重新连接的会话、完成或需要输入时跳回对应会话的桌面通知，以及带文件树、diff 视图和 Markdown 预览的内置编辑器。HN 作者还说明，Agent 在编辑器视图中继续运行；这比来回切换一排终端更适合做短周期监督。
一个实用的节奏是：先把需求拆为互不抢文件的任务；再为每个任务写出验收条件；最后只在 Agent 提交或等待决策时介入。不要把「修复全部问题」这类宽泛提示同时发给多个 Agent。相反，给每个任务限定范围，例如「只修改认证中间件并新增失败用例」「只评估迁移脚本的回滚路径」。这样在合并时，冲突更少，也更容易判断哪一个分支值得保留。
先用任务契约减少「看似独立、实际耦合」的问题
worktree 是文件层面的隔离，不是项目计划。并行之前，建议为每个 Agent 写一个很短的任务契约：允许修改哪些目录、不可触碰哪些共享接口、完成时必须给出什么证据。对于认证改动，证据可以是新增用例、失败路径说明和改动文件列表；对于文档任务，证据可以是链接校验与示例是否可复制。它比一段很长的提示词更容易审阅，也更适合在会话恢复后继续执行。
还应当把依赖关系显式排出来。下面三类工作通常适合并行：彼此独立的测试补充、只读排查与文档整理、不同模块内的局部重构。下面三类则应排队：数据库迁移与依赖它的业务代码、会同时改公共类型定义的两个功能、会改变构建或锁文件的任务。后一组即使放在不同 worktree，也会在合并时相遇；先完成设计决策，再派生实施任务，往往比让多个 Agent 各自猜一套方案更快。
Shikigami 的内置编辑器、diff 与 Git 视图适合承担「先看证据、再决定是否继续」的角色。看到 Agent 停在确认点时，不必立刻给它更多权限；先检查它的计划是否超出任务契约、当前改动是否已经触碰共享区域。对可能删除数据、修改权限或执行外部副作用命令的操作，继续沿用团队既有审批，而不是把桌面通知当成批准按钮。
审阅仍应回到 Git，而不是相信面板状态
当一个 Agent 声称完成时，先在其 worktree 内看改动，再合并。最小检查可以是：
cd ../app-auth git status --short git diff --check git diff --stat
git diff --check 能发现常见的空白错误，但不能替代测试、静态检查或人工审阅。尤其当两个任务都会改到公共类型、数据库 schema 或依赖版本时，应该先合并一个分支并重新基于最新主线验证另一个分支；不要因为 worktree 隔离就跳过集成测试。
给并行实验留出清理出口
并行任务的收尾也要有规则。已合并或明确放弃的分支，不应长期保留在临时目录里，否则下次打开项目时很难分辨哪些改动仍有价值。确认分支不再需要后，可从主仓库执行：
git worktree list git worktree remove ../app-docs git branch -d agent/docs
先用 git worktree list 确认路径与分支，再删除工作树；如果分支还有未合并提交，git branch -d 会拒绝删除，这正好给维护者一次复查机会。不要为了清理而直接强制删除仍可能需要的实验结果。把 worktree 的创建、审阅、合并或回收记录进 issue 或 PR，也能让下一位接手的人知道哪些 Agent 结论已被采纳。
适用边界：它是本地多 Agent 工作台，不是隔离沙箱
Shikigami 的 worktree 隔离主要针对 Git 工作目录，并不意味着每个 Agent 都获得操作系统级沙箱。官网提到它还提供 Docker Compose 面板、容器日志和容器 shell，以及只读的 MySQL、Redis 浏览；这些是开发环境观察与操作入口。涉及生产凭据、破坏性数据库命令或不可信代码时，仍应依赖团队现有的权限控制、容器隔离和审批流程。
另一个边界是平台和成熟度：目前官方只列出 macOS 与 Linux，并将产品标为 Beta。首次引入时，建议从一个非关键仓库、两三个边界清楚的任务开始，确认本机的 Claude Code 或 Codex CLI、Git 凭据和测试环境均按预期工作。
遇到 Agent 卡住时，也应先区分「模型正在推理」「CLI 等待交互输入」和「任务本身没有可执行下一步」。前两种情况可借助每个会话的 PTY、状态与通知快速定位；第三种则需要人补充约束、样例或决策，而不是再启动一个 Agent 反复尝试。保留每个任务的提示、关键选择和最终 diff，日后复盘时才能知道并行带来的是真实吞吐，还是只是把同一问题复制了几遍。
把它当作让并行任务更可见、更可审阅的协调层，而不是替你做架构决策的自动驾驶仪。最理想的结果不是屏幕上同时跑着更多会话，而是每一次变更都能追溯到清晰的任务边界、独立的工作目录与可重复的验证证据。对于小团队而言，这种可追溯性还会降低临时接手的成本：即使原来的操作者不在线，其他人也能从分支、diff 和验收条件判断下一步。
相关链接