证据优先
本文总结结论、来源和实际读过的范围要存在一起，谁想核对都能翻到原文。
最小约定
观点可以先写，但要和实验事实、引用来的结论、个人假设分开放。引用外部资料时，保留原始链接，也写清实际读了多少。
只读了摘要，就别写“全文证明”。关系图上连了一条线，也代替不了出处。程序能检查字段齐不齐，但字段齐全不代表证据为真。比如一条记录写着 "span": "第 4.2 条"，格式完全合法，可第 4.2 条讲的也许是住宿，跟打车无关。检查“引用是否支持结论”是另一件事。
为什么它是一个设计模式，而不只是写作习惯
模型生成的是“像真的”文本，写得流畅和写得正确之间没有必然联系。证据优先把“可不可信”的判断从语气挪到了结构上：结论和依据一起存、一起展示、一起被检查。这样做有三个直接的好处：
- 可核查：用户和审核的人能点开原文，自己判断引用支不支持结论。
- 可评测：引用支不支持主张可以逐条核验，幻觉率也就有了能算的口径。比如一次回答里有 5 句带事实的陈述，其中 4 句能在引用原文里找到支撑，这次的引用精度就是 4/5。
- 可归因：结论错了，能分清是证据本身错了、证据没找到，还是模型读错了证据。
三类陈述分开存放
| 类型 | 含义 | 要求 |
|---|---|---|
| 有据事实 | 能在某个来源中找到原文支撑 | 附来源 ID、版本、片段位置 |
| 推断 | 由若干事实推出的结论 | 写出依据了哪些事实，推理链可复查 |
| 假设 / 待核验 | 尚无证据或证据不足 | 明确标记，不得包装成事实 |
放到报销案例里：“第 4.2 条规定市内交通超标需说明事由并经审批”是有据事实；“INV-102 超标 38.5 元，所以这张单需要审批”是推断，依据是发票金额 118.5 元、标准 80 元和第 4.2 条；“这趟行程应该算出差而不是市内通勤”如果制度里没写清楚，就是待核验，要标出来，别包装成事实。
一条主张的记录可以是下面这样（示意，不是固定协议）：
{
"claim": "超出市内交通标准的打车费，说明事由并经审批后可以报销",
"kind": "fact",
"evidence": [
{ "source_id": "travel-policy", "version": "2026 版", "span": "第 4.2 条", "read_scope": "条款全文" }
],
"status": "supported"
}
status 只有三种取值：支持、矛盾、未核验。read_scope 要照实写，只看了检索返回的片段就写“片段”，别写“全文”。
证据不只来自文档
报销主线里的证据有两种来源。一种是知识：结论“能报”必须附上制度条款的 ID、版本和原文片段，也就是《差旅费管理办法》2026 版第 4.2 条。另一种是执行：回复“已提交工单”必须附上工具返回的工单号 R-55821。后一种是任务层面的证据，防的是模型说自己做了某件事、实际上没做成。比如 create_reimbursement_ticket 超时了，模型却回复“已为您提交”，这时候运行时手里没有工单号，就不该放这句话出去。两种证据都由运行时记录，不让模型自己转述。
证据不足或冲突时
- 不足：标成待核验，回复降级为“没找到依据，建议咨询财务”。补一个看着可靠的引用是最糟糕的做法。
- 冲突：两版制度说法不一样时，把冲突本身摆出来，说明以哪个生效日期为准，必要时交给人确认（见 人在回路）。比如 2024 版和 2026 版的第 4.2 条标准不同，回复里应该写“按 2026 版（现行）为 80 元”，而不是悄悄挑一个。
- 核验成本：逐条核验会拖慢响应，可以按风险分级。涉及金额、权限和对外承诺的主张必须核验；解释性的话展示来源就够了。
和评测的关系
评测 负责检查证据到没到位：引用精度（引的片段支不支持这句话）、引用召回（该带引用的句子是不是都带了）、执行声明和实际副作用是否一致（说建了一张单，系统里是不是真的只有一张 R-55821）。证据优先提供能检查的结构，评测负责真的去查。少了任何一边，带了引用也只是做做样子。
待落地
在 研究 Agent 里把主张和证据分开存。没有出处的输出一律标成待核验，不能偷偷补一个看起来可靠的引用。