最近有人问我，日常工作用 Agent，最头疼的就是它会编。闲聊时错一句还好，碰上要核对数据、写严谨结论的工作，就不敢直接用了。
我的第一反应是：让它验算，再让它溯源。人做题会检查，写文章会查出处，AI 也可以这样做。再找一个 Agent，从另一个角度挑错，应该还能更稳一些。
顺着这个想法查了一圈研究，我发现，这个方向值得坚持，但里面有两个容易忽略的前提。
验算得有办法发现原来的错误。来源得真的支撑眼前这句话。
否则，我们可能只是给一个错误答案，补齐了审校意见和参考链接。
最容易让人放下戒心的，是一个带出处的错误
想象一个工作场景：你让 Agent 整理某家公司的经营情况，它给出营收、同比增速、业务拆分，还附上财报链接。
看起来很完整。可点进去一查，发现它把上一年的数字当成了今年的数据。
再问它检查过没有，它回复已经核实。
这时，问题已经超出一个数字写错了。连它描述的核验过程，都需要再核验。
我们通常把这些问题统称为幻觉。美国国家标准与技术研究院 NIST 在 2024 年发布的生成式 AI 风险管理配套文件中，把自信呈现错误或虚假内容列为一类风险。它也明确提出，应在部署前评估和持续监测中核验模型输出的来源与引用。NIST 原文
但到了具体工作里，必须继续拆：它是凭空编了一个数，读错了表格，拿了过期资料，算错了增速，还是根本没有打开链接？
这些错误需要不同的修法。换一个更强的模型可能改善一部分；如果问题出在过期的数据源，模型再强，也可能认真地处理一份已经失效的材料。
大语言模型按概率生成内容，这提醒我们不能把流畅表达直接当作事实。不过，单凭概率模型这个标签，也推不出所有错误都无法控制。
需要管理的，是错误怎样进入工作流程，以及它有没有机会在交付前被拦住。
验算有用，前提是多出了一点新东西
人检查一道题，通常有几种办法：重算一遍，换个公式，把答案代回去，或者拿计算器核对。
这些办法有效，是因为检查有具体对象，也有可能推翻原答案的依据。
只给 AI 加一句「请认真检查，确保没有错误」，约束就弱得多。
一项发表于 ICLR 2024 的研究专门考察了没有外部反馈的自我纠错。在它测试的推理任务中，模型难以可靠地自行纠错，有时检查之后反而变差。这个结论有模型、任务和年代边界，不能据此断言今天所有模型都不会自我纠错；它提醒我们，增加一轮反思并不自动等于增加可靠性。研究原文
放回工作场景，差别就很直观了。
假设某业务收入从 800 万增长到 1000 万，Agent 写同比增长 25%。复核时，可以从原始表重新取出两个数字，用计算器算一次，再确认单位、年度和业务范围一致。
计算器能验证这道算式。它无法替你发现 800 万是去年的全年收入，1000 万却是今年的半年收入。数据口径仍然要回到原表检查。
所以，复核最好能拿到原始材料、工具结果或明确的检查规则。让模型把自己的解释再读一遍，也可能发现问题，但效果并不稳定，不该承担全部核验责任。
多找几个 Agent，为什么还会一起错？
多 Agent 交叉验证有研究支持。Du 等人在 ICML 2024 发表的论文中，让多个模型实例提出答案并进行讨论，在所测试的一些推理和事实性任务上取得了改善。研究原文
不过，后续研究给出了更克制的判断。2025 年一项研究用 4 个基础模型，在 9 个基准上评估了 5 种多 Agent 辩论方法，发现它们经常无法超过较简单的单 Agent 基线，却消耗更多计算资源；使用不同模型有助于改善其测试中的效果。研究原文
这两组发现放在一起，比较合理的理解是：多 Agent 能带来收益，具体怎么组织、拿什么作比较，很重要。
比如，三个 Agent 都搜索同一个问题，分别找到了三篇文章。三篇文章又都引用同一份错误的网帖。
看起来做了三路核验，证据其实只有一路。
或者三个 Agent 用相同模型，拿着同一份摘要讨论。它们有机会发现遗漏，也可能共享同一个盲区。换个角色名称，并不能保证判断独立。
我更愿意把这种协作安排成具体分工：一个提取原始数字，一个从原文复核时间和口径，一个专门寻找足以推翻结论的证据。能独立取证的部分，先各自完成，再对照分歧。
这是基于上述研究的工作设计建议，效果还需要在自己的任务上检验。它的价值在于增加了不同的核验路径。
几个 Agent 都同意，只能证明它们达成了一致；还得看它们分别拿出了什么证据。
来源是真的，也不等于结论是真的
我最初想到，要求 AI 列出真实来源，数据就不容易凭空编了。
这句话需要补全：必须打开来源，核对原文。
2023 年的 ALCE 研究把回答正确性和引用质量分开评估。它发现，在当时的 ELI5 测试中，即使表现最好的模型，也有约一半的回答缺少完整引用支持。注意，这不等于一半答案都是错的，更不代表今天所有产品的表现；它说明，附带引用和获得充分证据支持，是两个需要分别检查的问题。研究原文
仍然拿公司数据举例。官网可能确实写了某项业务增长 30%，Agent 却把它改写成整家公司增长 30%。链接真实，发布者也没问题，错误发生在转述里。
溯源因此至少包含几件事：页面是否存在，内容是否真正读到，原文说的是谁、哪个时期、什么指标，以及它究竟能支持多强的结论。
尤其要小心最后一步。原文说两件事同时发生，不能直接写成一件事导致了另一件事；报告只覆盖受访企业，也不能顺手推广到整个行业。
所谓把资料检索出来再交给模型回答，也就是常说的 RAG，可以让答案获得外部依据。但从检索、阅读到转述，每一环仍然可能出错。知识库更新不及时、关键段落没被搜到，都会影响最终判断。
这也是为什么我倾向于先整理证据，再生成结论。每条重要事实保留原文位置、日期、口径和必要摘录，后续写作尽量据此展开。这样复核的人不用从一篇漂亮的成稿里，倒着猜每个数字从哪来。
判断权威，也要问他凭什么知道
这让我想到，我们平时判断一个人的话可信不可信，也会看他的身份。
身份有价值。负责某项业务的人，通常比旁观者更接近现场；在一个领域长期做研究的人，通常更了解其中的争议。
但身份能提供的信用有范围。
公司官网适合核对它公布的产品规格；要判断它是否优于所有竞争对手，只看它自己的宣传显然不够。一位专家熟悉本专业，也不意味着他的跨领域判断同样可靠。
所以，来源的分量要和具体问题一起看：说话者离事实有多近，采用什么方法，有没有公开原始材料，是否存在影响其表述的利益关系。
再加一个常被忽略的问题：有没有独立的支持？
十家媒体转载同一篇新闻稿，并不会自动变成十份独立证据。另一方面，一手材料也可能有遗漏或错误，需要核对更正记录，并在重要结论上寻找独立支持。
我们可以因一个人的专业背景更认真地听他说话，但对某个具体结论的信任，仍然需要落到证据上。
严谨工作的 Agent，还得允许自己交不齐答案
如果要求 Agent 每次必须给出完整答案，表格里每一格都必须填满，那么找不到证据时，流程就缺少一个合理出口。
允许它写尚未查到，看起来像少完成了一点工作，却保留了一个非常重要的事实：这里还不知道。
这种许可需要落实到系统行为。来源打不开，就记录未核验；资料相互冲突，就保留分歧和各自口径；缺关键数据，就暂停依赖该数据的结论。对于后果较大的操作，还要有人工复核和权限边界。
可以把上述判断整理成一张工作中的核验表。它是我的归纳，用来识别缺口，并非一个能计算可信度的科学公式。
| 要检查的事 | 足够具体的核验依据 | 常见缺口 |
|---|---|---|
| 这句话从哪来 | 原始页面或文件，以及对应段落 | 只有链接，没有读到内容 |
| 材料能否支持结论 | 对象、时间、单位、范围一致 | 把局部数据扩成整体判断 |
| 有没有独立检查 | 重新取数、工具复算、反证材料 | 几个 Agent 复述同一份摘要 |
| 证据不够时怎么办 | 标记缺口，停止相关推断或操作 | 为了交付完整答案而补猜 |
对于会执行动作的 Agent，还要多看一步：实际结果是否发生。
Anthropic 在 2026 年的 Agent 评估文章中专门区分了执行记录与环境中的最终结果，并建议结合代码、模型和人工等不同评估方式。沿着这个思路，如果 Agent 说已更新客户资料，验收就应去读取系统里更新后的字段。工程文章原文
它说完成了，和系统里确实完成了，需要分别确认。
当然，核验也有成本。找午餐灵感和核对经营数据，没必要用同样的审核强度。把每句话都交给多个模型反复辩论，可能只是让工作更慢。
我会把核验资源优先放在会改变判断的事实，以及一旦执行就难以撤回的动作上。再把实际出过的错留下来，作为下一次换模型、改提示词、改流程时的测试题。评价改善时，也要一起看漏错、误报、拒答和耗时，防止系统靠什么都不回答来显得可靠。
回到最初的问题，我依然赞成验算、交叉验证和溯源。只是现在，我会把每个词都问得更具体一点：拿什么验，谁在独立查，来源能支持到哪一步，查不到怎么办。
在人类协作中，一个靠谱的人未必什么都知道，但通常能说清哪些是亲眼所见，哪些是听来的，哪些还拿不准。
当 Agent 也能留下这些区别，我们才有依据决定，把多少工作交给它。