Worktrunk：并行工作树、生命周期控制与源码分析
Worktrunk 性能与成本：怎样测并行收益，而不是编造节省比例
把工作树准备、依赖构建、模型请求和人工审阅分别记账，再判断更多智能体是否真的带来更多已验收成果。
你将学会
- 测量完成任务，而不是启动更多助手的速度
- 区分共享资源与每个工作树新增的开销
- 控制实验条件，再解释真正的瓶颈
开始前需要
- 基础 Git 分支和命令行导航知识
- 可用于选做练习的一次性仓库
解释工作树边界，核对首次检出结果，并在采用自动化前审阅配置命令。
先看结论
- 统计已验收修改，不统计启动的助手数。
- 本地资源与模型费用分别测量。
- 未知测量值不是零延迟或免费资源。
测量完成任务，而不是启动更多助手的速度
Worktrunk 可以降低管理并行检出目录的操作负担，但同时启动更多任务，不等于完成更多可接受的修改。先定义完成单位：代码已经审阅、规定检查通过、冲突处理完毕，而且相关服务完成清理。以这个单位记录总耗时，再比较单任务与多任务流程。
把检出准备、依赖安装、构建测试、模型请求和人工审阅分别记录。切换命令很快，也可能只是一个整体很慢的流程中的短步骤。本系列没有测量 Worktrunk 延迟、构建吞吐或开发者用时，因此这里提供可执行的测量设计，而不是未经测量的提升百分比。
区分共享资源与每个工作树新增的开销
Git 工作树共享仓库基础设施，但依赖目录、构建产物和开发服务器仍可能随工作树数量增加。应测量实际配置下的磁盘和内存占用。共享缓存可能减少下载，也可能引入锁竞争或产物污染；不能因为分支同属一个仓库，就认为所有生成目录都可以安全共用。
AI 任务另行记录提供方、模型、输入输出用量和重试次数，不要混进本地资源账本。可选的提交信息生成又增加了外部命令，可能进一步调用模型。缓存与计费取决于实际服务，未取得的价格和 token 数保持未知，不能把 null 改写成免费或零消耗。
控制实验条件，再解释真正的瓶颈
挑选可比较的任务，固定仓库与工具版本、验收检查，并记录并行数。进行足够多的重复案例以观察波动，同时列出失败与放弃的任务。两个任务的演示只能证明流程可展示，不能成为可靠的统计基准；也不要同时修改钩子和模型，再把全部差异归因于 Worktrunk。
如果瓶颈是构建内存，就减少同时构建的数量；如果审阅积压，减少同时工作的助手反而可能更快得到成果；如果准备依赖最耗时，应先研究这个阶段。采用结论应带条件：在你的环境中，测得的协作收益是否超过配置和维护负担，而不是“并行越多一定越快”。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
定义一种完成任务及固定验收条件。
- 2
分别记录准备、构建、模型与审阅阶段。
- 3
用重复任务比较受控的并行数。
- 4
先处理瓶颈，再决定是否增加并行。
可复制示例
{
"taskId": "example-only",
"workers": 2,
"setupSeconds": null,
"buildSeconds": null,
"peakMemoryBytes": null,
"inputTokens": null,
"outputTokens": null,
"retries": null,
"reviewMinutes": null,
"accepted": null,
"measured": false
}常见问题
Worktrunk 到底能快多少？
本系列没有独立测得的加速比例，不能给出保证。
模型生成提交信息免费吗？
取决于实际外部命令与提供方；本文没有测量这项费用。
资料来源
- Worktrunk / README.md来源核查 2026-09-14
- Worktrunk / docs/src/content/docs/llm-commits.md来源核查 2026-09-14
- Worktrunk / docs/src/content/docs/hook.md来源核查 2026-09-14