很多团队做 Agent 时都有一段快乐期：接上搜索，模型终于不再张口就来；再接个浏览器，感觉它已经能当研究员了。
然后线上开始出现另一种更难抓的错：它给了链接、写得很笃定、结论却不对。
这类错不一定是模型不会推理。更常见的现场是：用户的问题里混进一个错名字，搜索召回了一篇“看起来很像”的文章，模型又从里面摘出一句正确但不相关的话。三段都没有完全崩，但拼起来刚好把人带沟里。
DeepLearning.AI 在 7 月 24 日解读了一项关于新闻检索的测试。研究者让带网页搜索工具的模型回答当日新闻问题，并故意测试错误前提、多语言和无选项等场景。最扎眼的结论不是“某个模型赢了”，而是：错误通常卡在检索，不在生成。
研究解读：Web Retrieval Flusters LLMs
〇、别把“会搜索”误当成“会查证”
把一个 Agent 想成去档案馆查事故记录的人。
用户递来一张纸条：“昨天 A 公司在上海宣布了 B，对吗？”如果公司名写错、城市写错，档案管理员再勤快，也可能抱回一摞“差不多”的材料。接下来，他从材料里读出一句真话，再放回一张像模像样的答复。
模型接搜索也是一样。事实型任务至少有三道门：
- 问题是否可检索：人物、时间、地点、限定条件有没有写对。
- 材料是否能作证：召回页面是不是原始报道，是否包含回答所需的那一个事实。
- 模型有没有按材料作答：它是否读懂语言、时间线和否定条件，还是看见几个关键词就开始补全。
把这三道门压成一个“联网开关”，排错时会非常痛苦。你只会得到一句“模型偶尔不准”，却不知道该改 prompt、改召回、还是改引用机制。
经验一：检索增强不是一个能力点，而是一条事实供应链。
图：每条外部事实都应回到来源证据；缺证据时，系统必须允许输出“信息不足”。
一、第一段：先处理问题，再让搜索引擎干活
很多产品直接把用户原话丢进搜索框。这样做很省事，也很像让新实习生拿着一句模糊需求就去改生产库。
更稳的做法是先把问题拆成可检查的约束：
{
"subject": "谁或什么",
"claim": "需要核实的动作或属性",
"time_range": "事件发生在哪个时间窗",
"location": "地域是否影响答案",
"language": "优先检索语言",
"unknowns": ["哪些字段只是用户猜测"]
}
这不是为了把体验搞复杂，而是为了给“用户可能写错了什么”留位置。
例如用户问“某模型昨晚开源了吗”，不要默认“昨晚”和“开源”都是真的。系统可以并行构造两个检索方向：一个找发布公告，一个找仓库或许可证；如果两个方向都没有证据，就应该允许返回“不足以确认”，而不是把发布会预告改写成开源新闻。
把错误前提当成一等公民
普通问答喜欢把不确定性藏起来。事实型 Agent 应该反过来：把不确定性显式展示。
一个合格的中间结果至少应当包含：
- 哪些实体已经被确认；
- 哪些条件没有找到可靠证据；
- 系统为此改写过哪些查询；
- 回答是“确认”“反证”还是“信息不足”。
如果产品没有“信息不足”这个状态，模型迟早会拿“听起来最像”的答案凑满一个句号。
二、第二段：检索目标不是相似，而是可引用
向量相似度、关键词匹配、重排序，这些都很重要。但它们只解决“像不像”，不保证“能不能证明”。
新闻和实时信息特别容易出现这个陷阱：两篇文章都在谈同一家公司、同一周、同一产品，只有其中一篇包含你需要的数字、时间或原话。召回系统若只给模型一堆主题相近的页面，模型就会从中挑一个最顺眼的细节。
因此，检索阶段应把候选页分成三类：
| 候选类型 | 能做什么 | 不能做什么 |
|---|---|---|
| 一手材料 | 支撑发布、价格、版本、原始声明 | 不代表市场效果已经发生 |
| 高质量报道 | 补足背景、时间线、现场信息 | 不能替代原始条款与公告 |
| 二手汇总 | 帮你发现线索 | 不应作为最终断言的唯一证据 |
实际工程里，可以给每个证据片段加一个很朴素的字段：supports_claim。它不是让模型判断“这篇文章有没有价值”，而是回答更窄的问题：这段文字能否直接支持当前这一句？
问题：这个 API 是否已面向所有开发者开放？
证据：公告写的是“limited beta”。
结论：不能支持“全面开放”；它反而构成反证。
这一步会明显减少“链接是真的、结论是假的”这种最烦人的事故。
经验二：召回的 KPI 不该只有相关性，还要有证据覆盖率。
三、第三段：回答前做一次“逐句对账”
生成环节最容易被低估。模型读到了正确页面，也可能把不同日期的更新拼在一起，或者把英文里的条件句读成既成事实。
尤其是跨语言内容：研究中，英文的表现通常更好，而其他语言的检索与理解更容易掉链子。对中文产品来说，这不是“把英文搜索结果翻译一下”就能解决的事。中文查询、英文原文、中文答案之间至少存在三次转换，每一次都可能把限定词弄丢。
一个实用的答案生成协议可以很简单。
- 每个外部事实必须绑定一个证据片段。
- 证据不足的句子改成条件句，或直接删除。
- 时间、版本号、价格、人物关系必须单独复核。
- 对冲突材料，不做“平均”；明确写出来源之间的差异。
最终答复不必把推理过程全倒给用户，但应该让用户看见事实的落点：来源、日期、以及这条来源到底支持什么。
四、给 Agent 加四个测试，不要只测“答对率”
如果你正在做搜索型 Agent，下面四类 case 比“问十道百科题”更有用：
4.1 错一个字的实体
把公司名、人物名或产品名故意改错一个字。看系统会不会先纠错，还是一本正经地围绕错实体回答。
4.2 过期时间线
给出“今天”“昨天”“最新”这类词，再放入同主题但不同日期的页面。看它有没有把旧闻当突发。
4.3 有主题、没证据
检索到十篇都谈某个模型，但没有一篇能证明“已经 GA”。看系统能否说“没有找到足够证据”。
4.4 双语材料
问题用中文，证据用英文，再要求中文回答。检查限定条件、数字单位和否定表达有没有在翻译时丢失。
这四个测试有一个共同点：它们不在考模型会不会背知识，而在考你的事实链有没有断。
图：这四类 case 应进入检索型 Agent 的持续回归集，而不是只在上线前跑一次。
五、一个能直接落地的最小闭环
如果不想一上来做复杂的多 Agent 架构，先把下面四步做扎实：
用户问题
-> 结构化约束与不确定字段
-> 多路查询与候选来源分层
-> 证据片段对当前 claim 的支持检查
-> 带来源、时间和置信状态的回答
不要急着加更多搜索源。一个能说“我不知道，因为我缺少哪一块证据”的 Agent，通常比一个能从二十个网页里拼出漂亮段落的 Agent 更值得信任。
在中国使用这套方法
国内落地时，最容易被忽略的是数据授权和检索范围。不要把抓到的网页都当成可长期存储、可二次分发的知识库。
- 优先接入有授权的搜索或内容服务：让检索结果保留来源、抓取时间和可访问状态。
- 企业资料先做权限分层：内部文档、客户文件、公开网页不能进入同一个默认召回池。
- 模型和检索分开替换：无论后端是通义千问、智谱 GLM-5、文心一言还是本地 Ollama 模型，事实链的“问题—证据—回答”协议都应保持不变。
模型可以换，证据责任不能换。
参考资料
- DeepLearning.AI, Web Retrieval Flusters LLMs , 2026-07-24。本文关于多语言新闻检索、错误前提和检索失败模式的事实依据来自该研究解读。
- 本文的“三段式事实链”、测试用例和实现建议为梦兽编程的工程化分析，不代表来源方的产品结论。
关注「全栈之巅-梦兽编程」公众号，每周更新 Rust、AI 编程和 Agent 工程实践。
也欢迎了解 梦兽编程 AI 编程助手服务 ，把能验收的 AI 工作流接进日常开发。