企业官网建设流程全解析

Agent 写的代码出 bug 算谁的？并行开发验收责任，是 2026 年最难回答的问题之一

【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk

2026 年，Claude Code 与 Codex 这类 AI 编码代理已经能连续数小时独立作业，一个开发者同时管理 5 到 10 个并行 Agent 成了常态。工作区倒是被 Git Worktree 物理隔离开了——每个 Agent 拥有独立目录，不再互相踩文件。可真正让人头疼的问题浮出水面：当 Agent 提交的代码在生产环境炸了，责任归谁？是写下那几行代码的 Agent，是给 Agent 下指令的人，还是按下合并键的人？这个问题在团队里比技术选型更难达成共识，而 worktrunk 这类工具恰好踩在了答案的边缘：它不写代码，却把"谁提交了什么、在什么上下文里提交、合并前有没有人看过"这些事实，变成了可审计、可查证的工程证据。

多 Agent 并行下的责任界定困局

先说清责任为什么难界定。传统 Git 协作里，责任链条是清晰的：谁写的代码，谁的 commit 署名，谁 review 的 PR，谁合并的——每一步都有记录，出事能回溯到人。但 Agent 化之后，这条链断了几环：

• 提交者不是人：worktrunk 官方文档（docs/src/content/docs/worktrunk.md）开篇就说它专为"parallel AI agent workflows"设计。当一条分支从创建、编码到提交全程由 Agent 完成，git log里的 author 变成了 Agent 的名字或执行它的用户，代码的"作者"不再对应某个具体人类；
• 指令与执行分离：写 prompt 的人、审核 diff 的人、执行合并的人常常不是同一个人，甚至不同时在场。Agent 的产出物在无人值守时可能已被合并；
• 上下文污染：多个 Agent 若共享一个工作区，A 的环境变量、缓存、依赖状态会被 B 改动，最后出问题时归因混乱——这也是社区情报里反复提到的痛点：多 Agent 共享仓库会导致文件覆盖、分支切换灾难和上下文污染。

Git Worktree 解决了物理隔离，但这只是第一步。把任务绑定到隔离工作区，让"哪个任务改了哪些文件"有据可查，才把问题从"抓不到责任人"推进到"至少有完整的变更事实"。这正是 worktrunk 的切入点：它以分支名为工作树地址，把任务、分支、目录一一映射，让并行 Agent 的产出物天然具备可归属的边界。

元数据可审计给问责提供了什么

责任界定依赖一个前提：有可靠的事实记录。worktrunk 的整个设计都服务于把 Agent 的动作变成可查证的元数据。

首先是命令与配置的可审计性。项目的钩子、别名、--execute命令都是任意 shell 代码，可能随仓库一起克隆进来。worktrunk 的处理原则写在 AGENTS.md：项目钩子必须经用户显式批准才能执行，批准记录保存在~/.config/worktrunk/approvals.toml，命令模板一旦变更就需重新批准。更关键的是实现层面：src/commands/hook_plan.rs 中的ApprovedHookPlan专门封死了"审批后配置被改"的 TOCTOU 漏洞——审批一旦通过，被批准的钩子集合被冻结成不可变快照，执行器只能消费这个快照，从结构上杜绝"批了 A 却执行了 B"。这份源码注释直白地写道：在一个刚克隆的仓库上，这等价于远程代码执行风险。换句话说，Agent 产出的代码可以出错，但"谁批准了哪些命令运行"这件事，必须无歧义。

其次是合并管线全程留痕。wt merge不是一句git merge，而是一条完整流水线：commit → squash → rebase → pre-merge 钩子 → merge → 清理（见 docs/public/merge.md）。其中pre-merge钩子在 rebase 之后、合并之前运行，失败即中止合并。开发者可以把测试、lint、构建验证都挂在这里，让"Agent 的代码能不能进主干"由可重复的机器检查说了算，而不是凭感觉。wt step diff（docs/public/step.md）还能一次性展示分支自创建以来的全部变更——包括已提交、已暂存、未暂存、未跟踪的，这是人工审核 Agent 产出物的事实底座。

最后是状态可观测。wt list --full在表格里直接展示每个分支的 CI 状态（绿蓝红黄灰对应通过/运行中/失败/冲突/无 CI）与 LLM 生成的分支摘要（docs/public/list.md）；交互式 picker 甚至能在切工作树前预览 diff、log、PR 与评论线程（docs/public/switch.md）。对 10 个并行 Agent 的分支逐一打开看，人力不可行；但把这些信号压缩进一张表、一个预览面板，人就可以在合并前快速扫视全局。

这些元数据不直接回答"bug 算谁的"，但它把问责的前提补齐了：产出物归属清晰（哪个分支/任务）、执行过程可查（谁批准了什么命令）、合并时机受控（pre-merge 门禁）。责任最终落到人，但工具保证了人做判断时有完整事实。

人机协作的验收流程该谁拍板

工具能把事实摆齐，但"拍板"这个动作必须留在人这边。worktrunk 在这一点上设计得非常克制，甚至可以说它是少数主动把权力交还给人的 Agent 编排工具。

看它的渐进式验证配方（docs/public/tips-patterns.md）：快速检查（lint、typecheck）挂在pre-commit，昂贵的完整测试与构建挂在pre-merge。这是典型的人机分工——机器负责"可自动验证的部分"，人只在真正需要判断的地方出现。社区情报里对 worktrunk 的主流评价也印证了这一点："CLI 可嵌入 Agent 调用链""兼容 CI/测试网关集成"——它被当作 Agent 与主干之间的一道闸门，而非让 Agent 全自动直达生产的通道。

再看审批权的归属。worktrunk 的官方 Agent 技能文档（plugins/worktrunk/skills/worktrunk/SKILL.md）写得非常明确：

When invoked as an agent, stop and escalate to the user. Approving a project's hooks is a security decision... that decision belongs to the user, not the agent.

"批准项目的钩子属于安全决策，这个决策属于用户，不属于 Agent。"甚至要求 Agent 不得擅自用--yes替用户跳过审批。这不是技术限制，而是明确的产品立场：信任边界必须由人划定，Agent 永远无权代表用户扩大自己的权限。

至于合并这一最终动作，wt merge的文档给出了一个人机协作的典型闭环：启动一个 Agent 干活，人去忙别的，回来后 review diff，跑wt merge，pre-merge 钩子验证通过即合入并自动清理工作树。机器负责执行与验证，人负责最后的审阅与拍板。代码出 bug 之后，"算谁的"依然需要团队文化去裁决，但至少流程保证了：没有经过人审阅的代码不该被合并，没有经过机器验证的代码不该进主干——这两条底线，工具替团队守住了。

回看开头的问题：Agent 写的代码出 bug 算谁的？worktrunk 给出的不是答案，而是让答案成立的前提。它通过物理隔离的工作树让产出物可归属，通过审批冻结与合并门禁让过程可审计，通过把拍板权显式保留给人来守住最后的责任节点。工具能压缩的，是"找不到谁改的、说不清何时合的、没人看过就上线"这些责任黑洞；不能压缩的，是那个最终按下合并键的人必须承担的判断与后果。2026 年最难回答的问题，答案也许不在工具里，但工具至少让追问变得有据可依。

【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk