Vibe Coding Agent 集成顺序与冲突验收：让多份补丁逐层收敛

三份补丁分别通过自己的测试，却可能无法组成一个正确结果：类型补丁基于合同 revision 2，服务端补丁已改成 revision 3，前端补丁又携带一次全文件格式化。按完成时间依次应用，最快返回者会意外决定公共接口；把冲突标记消掉，也只证明文件成为可解析文本。

Vibe Coding 的集成是一条有顺序的重新验收链，不是拼接 Agent 输出。多 Agent 结果合并讨论运行时候选结论的 provenance、仲裁与 canonical 发布；本文只处理同一代码任务中多份补丁怎样进入共享工作树，以及组合后哪些证据必须重跑。若已经进入 merge、rebase 或 cherry-pick 的 base/ours/theirs 三方裁决，则由合并冲突语义对账处理；这里关注进入该步骤前后的交付排序和整体验收。

集成前先做身份预检

每份交付物进入队列前核对任务 ID、基线 revision、工作树覆盖层、接口 revision、预计与实际写集、生成来源、验证结果和未决项。缺少任一关键 identity 时，不要通过“试着应用看看”反推它属于哪版代码。

Git apply --check 可以在不应用补丁的情况下检查补丁是否能落到当前文件；它不检查业务语义，也不证明调用方兼容。三方合并能利用共同祖先解决一部分文本变化，仍无法判断哪种错误码、默认值或权限规则正确。工具给出的是机械可组合性，接受决定必须回到任务合同。

若目标工作树本来就脏，先按脏工作树安全改码保护既有 hunk。集成者没有权把未知修改重置成某个 Agent 的基线，也不能为了简化冲突擅自格式化整个共享文件。

从依赖图推导集成层次

默认顺序不是“谁先完成谁先上”，而是：

1. 已接受的共享合同、schema 与正反夹具；
2. 公共适配层和必要生成产物；
3. 生产者实现；
4. 各消费者实现；
5. 跨边界测试、文档和最终用户验收。

这个顺序不是固定模板。若消费者测试负责定义合同，它可能在实现前以失败夹具进入；若数据库兼容要求应用先双读，迁移的物理执行又在后面。真正依据是任务依赖 DAG中的边和共享接口冻结的 active revision。

每完成一层就重新计算后续补丁是否仍基于有效输入。接口层有任何变化，消费者的旧编译结果和 mock 测试自动降级；不要等所有补丁应用后才一次性发现整批证据过期。

把冲突分成五类

TEXTUAL 是同一行或邻近上下文无法自动组合；CONTRACT 是字段、类型、错误或版本语义不一致；BEHAVIORAL 是文本能合并但两份代码对状态和副作用作出冲突决定；GENERATED 是产物来自不同源 revision 或有人手改生成文件；EVIDENCE 是补丁组合后原验证不再覆盖当前结果。

文本冲突最显眼，却往往最容易处理。真正危险的是无冲突合并：一份补丁新增 fallback，另一份补丁假设缺配置应 fail closed，文件可正常编译但行为互相抵消。集成者应把每个冲突映射到任务验收或接口条款；没有上位规则时暂停并请求决定，不能按代码更短的一侧选择。

生成冲突只回到 canonical 源解决，再运行批准的生成命令。行为冲突则准备能区分两个候选语义的最小用例。证据冲突不要求修改代码，可能只需让原 Agent 在组合快照上重跑；但重跑失败时必须重新打开对应节点。

每层都有独立接受门

接口层检查 schema、样例和消费者清单；生产者层检查正向、拒绝和副作用；消费者层检查真实响应而非只依赖 mock；最终层再跑跨边界用户路径和受影响回归。编程 Agent 的改动验证门给出通用分层检查，这里额外要求每个结果绑定“已集成到第几层”的内容摘要。

接受门的输出只有 accepted、rejected、blocked 或 stale，不要用“基本没问题”。blocked 说明缺什么决定或环境，stale 说明曾经有效但输入已变。一个后续补丁若扩大公共 API、修改共享资源或引入新生成输出，应退回所有权与依赖审查，而不是把它当普通冲突顺手吸收。

用冲突验收结束，而非用无标记结束

最终检查包括：所有实际路径都能追到任务 owner；共享合同只有一个 active revision；冲突分类都有裁决依据；生成产物来自同一源；针对性与跨边界验证覆盖最终组合；未运行项和人工决定仍可见。Git diff 用来核对最终变化形状，但不能替代这些语义条件。

集成合同边界测试可以验证双方组合后的可观察结果。只有当最终快照满足原任务验收，且任一局部绿色证据都已在必要处刷新，集成才完成。没有冲突标记只是编辑器状态，不是工程结论。

延伸阅读

• 任务依赖 DAG
• 共享接口冻结
• 编程 Agent 的改动验证门
• 集成合同边界测试