两个子代理报告电动车市场份额。一个说 35%，另一个说 42%。协调器取了平均值：38.5%。审阅者发现 38.5% 在任何来源文档中都不存在。这是一个编造的数字——数学推导出来的，无法归因于任何来源，无法用任何来源验证。
正确的输出：“Source A 报告 35%（2023 行业联盟），Source B 报告 42%（2024 政府统计）。“两个值都保留，两个来源都标注。读者可以自行判断冲突。
这就是核心原则：当来源冲突时，保留双方并标注归属。不要悄悄通过取平均、选一个或编造折中值来解决冲突。
冲突为什么发生——以及为什么这很正常
来自可信来源的数据冲突不是需要修复的错误，而是需要保留的信号。来源冲突的原因：
- 不同时间段： 2023 年 35% vs 2024 年 42% 是趋势，不是矛盾
- 不同方法论： 一个基准测试用 4 核，另一个用 8 核——两个结果都是真实的
- 不同上下文： 用 async/await（Node 16+），用回调（Node 12），热路径避免 async（低延迟）——每个在其上下文中都是正确的
- 不同范围： 一个子公司只算直接收入，另一个包含渠道收入
悄悄解决这些冲突会摧毁信息。读者需要知道冲突的存在，才能在自己的上下文中做出正确决策。
反模式
取平均
最常见也最危险的解决方式。35% 和 42% 变成 38.5%。$4.2M 和 $5.1M 变成 $4.65M。10,000 ops/sec 和 15,000 ops/sec 变成 12,500 ops/sec。每一个平均值都是编造的数据，无法追溯到任何来源。
一个研究系统的审计发现 25% 的冲突解决使用了取平均。加上 45% 悄悄选了较新的值和 10% 随机选了一个来源，只有 20% 的冲突被正确处理（保留双方并标注归属）。包含冲突的报告中 35% 的用户投诉率与 80% 的错误解决率直接相关。
时间偏好
“用更新时间更近的那个值。“一个客服系统把这条规则应用于定价：促销价格被录入后，每晚的目录更新用更晚的时间戳刷新了标准价格。时间偏好规则系统性地用标准价格覆盖了有效的促销价格。60% 的定价投诉追溯到了这个模式。
更新不等于准确。最近的更新可能是自动批量刷新、错误、或不同的数据范围。它告诉你某个东西是什么时候写入的，不能告诉你它是否正确。
选择”权威”来源
当两个数据库都声称自己是权威的——产品数据库和保修数据库都声称持有确定的保修期——选一个就是在赌。产品数据库可能已经更新了保修数据库还没收到的政策变更。反过来也一样。代理没有能力判断哪个是正确的。
使用”保守”值
有人提议始终使用较高的收入数字”以示保守”，这搞反了。保守的收入报告使用较低的数字。但更深层的问题是，系统性地选择冲突的某一方会制造方向性偏差。始终用高值会虚增收入。始终用低值会低估收入。两个都是错的。
正确模式
展示两个值，附带：
- 值本身
- 来源（文档、数据库、URL）
- 上下文，解释为什么值可能不同（时间段、方法论、范围）
- 标记，指示冲突需要人工解决
对面向客户的系统，这意味着升级到人工客服：“我们的系统显示您的产品有两个不同的保修期——一个数据库显示 12 个月，另一个显示 24 个月。让我帮您转接到可以核实正确条款的人员。”
对研究报告，这意味着对比呈现：
电动车市场份额：
- 35%（2023 行业联盟报告，基于销量）
- 42%（2024 政府统计局，基于注册数据）
注：不同时间段和方法论。对技术文档，这意味着展示所有相关建议及其上下文，而不是筛选成一个可能不适用于读者情况的”最佳”答案。
上下文相关的差异不是矛盾
四个来源对 async 模式给出了不同建议：
- “用 async/await”（Node.js 16+ 指南）
- “用回调”（Node.js 12 遗留文档）
- “用 Promise.all 并行”（性能博客）
- “热路径避免 async”（低延迟系统指南）
这些不是冲突——而是上下文相关的。每个在其上下文中都是正确的。综合成单一统一建议会强制一个虚假共识，无法正确覆盖所有上下文。按时间过滤会丢失遗留和性能特定的建议。正确的呈现方式是附带上下文展示全部四个，让开发者选择匹配其场景的方案。
财务数据：更高风险，同样的原则
当两个子公司对同一产品线报告了不同的收入时，悄悄解决的风险更大。选高值会在收入数据中制造上偏。选低值制造下偏。取平均产生编造数字。对不同受众使用不同规则（内部用高值，监管用低值）制造不一致。
唯一安全的做法：保留两个值及其来源，标记差异供人工对账。根本原因可能是合理的会计差异（不同的收入确认方法），需要人的判断来解决。
依赖冲突
一个 CI/CD 代理交叉引用 npm、GitHub Advisories、Snyk 和内部审计日志。npm 说 package v2.1 是安全的。Snyk 说它有一个 critical CVE。平均严重性评分毫无意义。只用 npm 作为唯一权威会制造安全盲区。始终使用最严格的评估会因误报导致告警疲劳。
展示所有评估及其来源。开发团队根据自己的上下文来评估——Snyk 标记但 npm 未标记的 critical CVE 可能反映不同的检测时间线，团队的风险容忍度决定应对方式。
一句话总结： 当来源冲突时，保留双方的值及其来源和上下文——取平均是编造数据，选一个是丢失信息，只有保留双方才能给读者做决策所需的一切。