AI agent 一旦开始多步执行、并发调用工具、接收人工修改或者多 agent 协作，系统就迟早会遇到一个问题：最后到底应该以哪份结果为准。冲突可能来自多个 draft 同时修改同一段内容，也可能来自不同工具对同一个状态给出相反结果。
如果没有 merge 与 conflict 设计，系统最常见的表现不是报错，而是默默用最后一次写入覆盖前面的结果，直到后续有人发现“为什么这段刚改过又变回去了”。
建议先结合 AI agent Artifact 设计、AI agent Workspace 状态分层、AI agent Run Ledger 审计模型 和 AI agent 人工审批控制台设计 一起看。
先给结论：不要直接 merge 最终结果，先 merge proposal
| 合并对象 | 风险 |
|---|---|
| 直接改最终状态 | 最容易覆盖正确结果 |
| 直接改当前 draft | 人工和 agent 修改会互相踩踏 |
| 先产出 merge proposal | 可以先判断冲突再决定如何落地 |
真正稳的系统，通常先让不同来源产出 proposal，再由 merge gate 决定哪部分可以自动合并，哪部分必须人工确认。
一、先把冲突分层，不要所有冲突都当成文本 diff
更常见的冲突其实至少有三类：
| 冲突类型 | 例子 |
|---|---|
| 文本冲突 | 两份 draft 改了同一段文案 |
| 字段冲突 | 一个工具说 status=approved，另一个说 status=rejected |
| 顺序冲突 | 某一步结果基于旧版本 artifact 继续生成 |
如果系统只会做文本 diff，它根本无法覆盖最危险的状态冲突。
二、Merge proposal 最好带来源和意图，不只带 diff
一个更有用的 proposal 结构通常会长这样：
{
"proposalId": "merge_001",
"targetArtifact": "draft_004",
"source": "review_agent",
"changeType": "field_update",
"intendedImpact": "replace call_to_action",
"baseVersion": 4
}
这样系统不只是看到“改了什么”，还能看到“谁提议改、准备影响什么”。
但 proposal 有了还不够，系统最好再把冲突严重级别单独分层：
| severity | 典型场景 | 默认动作 |
|---|---|---|
| low | 纯文本局部改动 | 自动 merge |
| medium | 字段值不同但无副作用 | 先校验再 merge |
| high | 审批、权限、外发状态冲突 | 强制进入 human gate |
| critical | 已有副作用且结果互斥 | 阻断并先对账 |
这样 merge gate 看到的就不只是“有冲突”，而是系统已经先判断了这类冲突该不该自动推进。
三、自动合并适合低风险字段，不适合高风险状态
一个简单但有效的原则是：
- 文本说明、低风险元数据：可自动 merge
- 权限、审批、外发、资金相关状态：默认不自动 merge
- 冲突字段涉及副作用：必须进入 human merge gate
系统不是越自动越好，而是越知道哪些东西不该自动越好。
四、状态冲突要优先于文本冲突处理
很多实现会先把文字合并好，最后才发现底层状态已经互相矛盾。更健康的顺序通常是：
- 先检查状态冲突
- 再检查字段冲突
- 最后才处理文本冲突
原因很简单：状态冲突一旦没被挡住，后面的文本再漂亮也可能建立在错误前提上。
五、人工 merge gate 最少要展示 4 类信息
当系统决定不能自动合并时，审批台最好直接展示：
- base version 和当前 version
- 各 proposal 的来源与意图
- 哪些字段可自动合并，哪些字段冲突
- 合并后会触发什么副作用
这会比给审核者一个纯文本 diff 稳定得多，因为很多冲突本来就不是纯文本问题。
进一步说，审批台最好还能输出一份 merge decision record，而不是只保留最终稿：
{
"targetArtifact": "draft_004",
"acceptedProposalIds": ["merge_001"],
"rejectedProposalIds": ["merge_007"],
"conflictSeverity": "high",
"sideEffectGate": "blocked_until_review"
}
这份记录的价值在于，后续一旦有人问“为什么选了这一版而不是那一版”，系统能回到具体决策，而不是只看到最终文本。
六、上线后要看 merge 质量，而不是只看冲突次数
建议至少记录：
| 指标 | 用途 |
|---|---|
| auto-merge success ratio | 看自动合并边界是否合理 |
| human merge required ratio | 看冲突是否过多依赖人工 |
| human merge turnaround time | 看人工 gate 是否成为瓶颈 |
| post-merge rollback rate | 看合并质量是否稳定 |
| side-effect conflict blocked count | 看关键冲突是否被成功拦下 |
| stale base version conflict rate | 看 proposal 是否常基于旧版本生成 |
如果 auto-merge 很高，但 post-merge rollback 也高，说明系统在“快合并”，不是在“稳合并”。
七、失败案例：人工已经改过 CTA，Agent 后续生成又把它覆盖掉
某个营销内容 agent 在人工修改 CTA 之后，另一个 review agent 仍然基于旧 draft version 继续生成“优化后的最终版”，系统直接按最后一次写入覆盖，结果人工改动消失。
修复后，团队把所有后续 proposal 都必须携带 baseVersion，只要发现 proposal 基于旧版本，就进入 conflict gate 而不是直接落地，覆盖问题才消失。
八、输出合并与冲突解决 Checklist
- 是否先把不同来源的修改变成 merge proposal，而不是直接落最终状态
- 是否区分文本、字段和顺序三类冲突
- 是否为冲突显式定义 low / medium / high / critical 等级
- 自动合并边界是否避开高风险状态字段
- 是否先检查状态冲突，再处理文本冲突
- human merge gate 是否展示 base version、来源、意图和副作用
- merge decision 是否被记录，而不是只留下最终结果
- proposal 是否都带 baseVersion 防止旧版本写回
- 是否监控 auto-merge 成功率和 post-merge rollback rate
结语
AI agent 的多路输出问题，本质上不是“怎么把几段文本拼起来”，而是怎么让不同来源的修改在同一套版本、责任和风险边界内收口。只有 merge proposal、conflict class 和 human merge gate 同时存在，系统才不会在最后一步把前面所有工程治理都冲掉。
延伸阅读：
