多个信息源互相矛盾：信任环与裁决规则

你开始系统性地外化隐性知识，把架构决策、已知约束、历史教训都写进了文档体系。但一个新问题浮出水面：信息源变多之后，它们之间开始互相矛盾。

架构文档说这个服务应该使用 REST API，但最近一次设计讨论的记录中提到团队决定迁移到 gRPC。代码注释中标注了一个已废弃的数据格式，但规约中仍然引用了这个格式。产品需求文档说"支持批量操作"，技术方案文档说"第一期只做单条操作"。

当 Agent 遇到这些矛盾时，它的处理方式和人类截然不同。人类工程师会停下来问同事，或者根据对项目的整体理解判断哪个信息更可信。Agent 会从矛盾的信息中选一个继续执行。它选择的依据可能是哪段信息在上下文中出现得更晚，可能是哪段信息的措辞更具体，也可能是其他不可预测的因素。结果是：每次执行可能产生不同的选择，产出中多了一个隐性的随机源。

信任环是解决这个问题的机制。它的核心思路是按优先级对信息源分层，当信息冲突时，高优先级来源覆盖低优先级来源。

Ring 0 是规约本身。它是单一事实来源，所有其他信息源发生冲突时以规约为准。规约中写了什么，Agent 就执行什么。

Ring 1 是架构文档和 API 契约。它们定义了系统的结构性约束。如果规约中没有涉及某个技术决策，以架构文档为准。

Ring 2 是设计讨论记录、技术方案和会议纪要。它们提供了决策的背景和上下文，但可能包含过时的或被否决的方案。

Ring 3 是其他来源：代码注释、个人笔记、外部参考资料。它们的可靠性最低，仅作为补充信息。

信任环的规则需要在 Agent 的工作指令中显式声明。例如："当多个信息源对同一个决策有不同描述时，按以下优先级裁决：规约 > 架构文档 > 设计讨论 > 其他来源。如果你发现信息冲突，在产出中标注冲突点和你采用的信息源。"

最后一条规则特别重要：要求 Agent 标注冲突点。这将隐性的随机决策转化为显式的、可审查的选择。人类审查时不需要逐行看代码，只需要检查 Agent 标注的冲突点和它的裁决依据。

信任环也需要维护。当设计讨论中的决策被最终确认，它应该被提升为架构文档或规约的一部分。当旧文档被新决策取代，旧文档应该被标注为废弃或删除。信息源的层级会随项目演进而变化，信任环的维护是规约维护的一部分。