【转载】多 Agent 并行开发工作流

引言

过去几个月，作者的工作流（workflow，开发流程）已经高度依赖 coding agents（代码代理）。真正的变化出现在 12 月：他深度使用 Opus 4.5 后，开发方式发生了根本变化。

他同时强调，自己并不完全认同 vibe coding（凭感觉写代码）。Agent 产出的代码必须逐段 review（人工审查），因为它们常见的问题是走捷径（shortcuts）或过度工程化（overengineering，过度设计）。如果想得到可靠结果，必须花时间和 Agent 反复对齐计划；而这件事本身需要足够深的技术判断。

这篇短文的核心，就是介绍他如何在同一个仓库里，用 worktrees（Git 工作树）来编排多个 Agent 并行执行。

为什么使用 Worktree

在社区里，这件事存在明显分歧：

1. 一派选择完全独立的 Git checkout（代码检出目录）；
2. 另一派使用 Git 内建的 worktrees（工作树机制）。

作者认可第一派的一个观点：原生 Git worktree 命令用起来有点粗糙。但他通过 worktrunk 解决了这个体验问题。可以理解为，worktrunk 把 Git worktree API（应用接口）打磨成了更适合日常高频使用的形态。

我的配置

作者的工作流核心是 tmux（终端复用器），用于管理 session（会话）、window（窗口）和 pane（分栏）。多数时候每个 pane 都运行一个 OpenCode；也会按需使用 Claude Code 或 Codex。

他强调自己的核心依赖是 worktrunk，并给出 macOS 的安装命令：

brew install worktrunk && wt config shell install

在 AI 协作环节，他会先进行大量 plan（方案）往返沟通，再开始执行。为了提速，他会用 Handy 做 dictation（语音输入转文本）。最近他大量使用 GPT-5.3 Codex 做计划研究，而这恰好适合并行拉起多个 worker（工作 Agent）。

开始一个新功能时，他会先创建新的 worktree：

wt switch <branch_name> --create

接着通过 .config/worktrunk/config.yml 的 post-create hook（创建后钩子）自动复制 .env 和 node_modules：

[post-create]
copy = "wt step copy-ignored"

随后进入 OpenCode 的 Plan mode（计划模式）。他有一套自己的 custom skills（自定义技能配置）来约束计划结构。第一个 Agent 吃完上下文后开始工作，他会再拉起第二个 Agent，来回切换推进。

他的经验是：同时管理约 3 个 Agent 是 sweet spot（效率与认知负担的平衡点）。虽然 X 上有人一次管理 10 到 15 个 Agent，但他认为那会产生过高的 context switching（上下文切换）成本。

功能完成后，他运行自定义命令 /ship，利用 commit + PR 技能自动创建 GitHub pull request（拉取请求）。即便如此，最终发布前仍会执行测试并快速验证功能。

最后，清理本地 worktree 的命令是：

wt remove <branch_name>

总结

作者最后表示，希望这篇文章有帮助；如果有问题或反馈，可以通过 Twitter 联系他。

原文作者：Oskar Kwaśniewski
原文标题：Agentic workflow with worktrees
原文链接：https://www.okwasniewski.com/blog/agentic-workflow-with-worktrees
原文发布日期：2026-02-24