多数 agent 工作流事故，不是发生在节点执行，而是发生在合并点。多个分支都“成功”，最终结果却互相冲突：字段覆盖、结论不一致、状态先后颠倒。
这类问题最麻烦的地方在于：分支看起来都正确，只有到了合并阶段才暴露“语义冲突”。
合并策略必须先于并行设计
| 合并模式 | 适用场景 | 风险 |
|---|---|---|
| last-write-wins | 低风险展示字段 | 关键字段被误覆盖 |
| priority-merge | 多来源证据整合 | 优先级配置错误 |
| quorum-merge | 多模型一致性判断 | 成本高、时延高 |
| human-merge | 高风险审批输出 | 吞吐受限 |
默认策略不应是 last-write-wins，而应按字段风险分级。
冲突分级模型
建议至少分三档：
- L1（可自动）：展示字段冲突
- L2（需策略）：业务字段冲突
- L3（需人工）：合规/审批字段冲突
没有分级，系统会把所有冲突都推给人工，吞吐会迅速崩溃。
合并器设计要点
合并器应包含以下能力：
| 能力 | 说明 |
|---|---|
| field policy table | 字段级优先级和覆盖规则 |
| provenance tracking | 记录每个字段来源分支 |
| conflict artifact | 冲突证据包供人工处理 |
| deterministic output | 同输入同策略得到同结果 |
如果没有 provenance tracking，后续很难解释“为什么是这个合并结果”。
失败案例：并行分支覆盖高优先级结论
某系统在“合规审查”和“业务建议”并行后，低优先级分支覆盖了合规限制，导致违规建议外发。
修复动作：
- 引入字段级优先级表。
- 合规字段设为只读合并目标，不允许低级覆盖。
- L3 冲突自动转人工并附冲突证据包。
发布前验证建议
至少做两类测试：
- 合并确定性测试：同输入重复执行，结果必须一致。
- 冲突覆盖测试：核心冲突类型都有样本。
很多线上事故都来自“合并器无确定性回归测试”。
关键指标
- 冲突发生率（按 L1/L2/L3）
- 自动合并成功率
- 人工合并平均时长
- 合并后回滚率
人工合并时长上升通常意味着冲突证据包质量不足，不一定是人手不够。
字段级合并策略示例
一个可执行的合并策略应该长这样：
| 字段 | 来源优先级 | 冲突动作 |
|---|---|---|
| complianceBlockReason | compliance_review > all | 禁止覆盖 |
| customerSummary | evidence_branch > draft_branch | 自动覆盖 |
| finalRecommendation | policy_branch + business_branch | 需合并器生成 |
| publishAllowed | compliance_review only | L3 冲突转人工 |
这张表的价值在于让合并器可测试，而不是靠模型临场判断“哪个更重要”。
人工合并不是让人读两大段文本
如果 L3 冲突进入人工队列，界面至少要展示：
- 冲突字段
- 各分支来源
- 每个值的证据来源
- 系统推荐合并结果
- 接受/拒绝/改写后的审计记录
否则人工合并会退化成“重新读一遍所有上下文”，效率很低，也不可追责。
什么时候宁可串行也不要并行
并行不是默认更好。以下场景适合串行：
- 下游强依赖上游风险结论
- 合并冲突成本高于并行节省时间
- 节点输出会改变后续策略范围
如果合规审查结果会决定业务方案能否继续生成，就不要为了省几秒把两者盲目并行。
Checklist
- 合并策略按字段和动作分级
- 关键字段禁止默认覆盖
- provenance 可追溯到分支级别
- 冲突结果进入独立队列并附证据包
- 高风险合并支持人工兜底
- 发布前通过确定性与冲突覆盖测试
延伸阅读：
