AI agent 最容易让人误判的地方，是它可以把不确定的东西说得非常顺。

在普通问答里，这会造成错误答案。在 agent workflow 里，这会造成更严重的问题：流畅解释可能压过真正的 source evidence，然后触发错误工具调用。

所以运行治理必须回答一个问题：当用户文本、模型推理、结构化数据、工具输出和系统状态互相冲突时，谁说了算？

这就是 source authority。

流畅文本是最弱证据

自然语言很适合表达意图，但它不是天然的事实来源。

用户可能记错。项目文档可能过时。AI 总结可能遗漏边界。聊天上下文可能已经失效。模型推理更不应该被当成原始证据。

在工程 workflow 中，应该把来源分层：

runtime state：当前系统状态、工具返回、数据库查询、测试结果、文件内容。

structured source：配置、schema、manifest、frontmatter、API response、trace。

reviewed document：经过维护的规范、决策记录、产品真相页。

raw material：网页、截图、会议记录、用户输入、未整理文档。

model inference：AI 的解释、归纳和推断。

层级不是绝对的，但必须显式存在。否则 agent 会倾向于相信最容易嵌入上下文、最流畅、最接近当前指令的文本。

Evidence-carrying action

有副作用的 agent 动作，应该携带 action-critical evidence。

不是所有步骤都需要长篇证据。但只要动作会改变代码、数据、发布状态、外部账号、项目规则或长期知识，就不能只靠一句“我检查过了”。

一个最小的 evidence payload 应该说明：

  • 这个动作基于哪个来源？
  • 来源是什么时间、什么路径、什么查询或什么工具输出？
  • 哪些假设是确定的，哪些只是推断？
  • 有没有冲突来源？
  • 如果结果被审查，别人如何复现或验证？

在代码任务里，证据可能是测试命令、日志、截图、API 输出或 diff。
在知识发布里，证据可能是 source page、publication manifest、双语 sibling 和 site route 检查。
在金融或交易系统里，证据必须区分预测、策略、执行、账户状态和风控约束。
在多模态建模里，证据可能是原始户型图、结构化设计状态、bridge trace 和视觉审阅。

不同项目的证据形式不同，但原则一致：没有证据的副作用动作，不应该被视为完成。

冲突时不要自动合并

agent 很喜欢调和冲突。两个来源不一致时，它会写出一个看似合理的折中解释。

这在治理上很危险。

如果产品文档说 A，代码显示 B，agent 不应该自动写成“系统支持 A/B 两种模式”。如果用户说“已经部署了”，但 GitHub、Cloudflare 或本地 build 状态不能证明，agent 不应该把这句话当成事实。如果网页标题说一个结论，但原文、数据表或发布时间不支持，agent 不应该只引用标题。

正确动作通常是：

mark conflict -> identify higher authority source -> ask or verify -> then act

如果无法判断来源权威，就应该停止在分析阶段，而不是把冲突包装成确定结论。

对知识库和 publication 的含义

中心知识库尤其需要 source authority。

wiki 概念页可以包含推理，但必须能追溯到来源页、项目证据或明确的推断边界。publication 可以更有表达性，但不能把尚未证实的猜测包装成事实。site 只是发布节点，不应该成为事实源头。

这也是为什么 publication adapter 不能只是复制文本。它应该保留来源身份、source hash、translationKey、review 状态和生成路径。公开文章可以写得自然，但背后必须能回到知识库的 source trace。

核心判断

agent 的语言能力越强，越需要降低语言本身的证据权重。

真实流程里，流畅文本应该服务于证据，而不是替代证据。能说明“我为什么这么说、依据在哪里、冲突如何处理”的 agent，才有资格进入高信任 workflow。