给 Agent 接上搜索之后，怎么核对答案

在一个工具里搜不到的资料，换到 DeepSeek 后找到了。第七期提到过这样的体验，但没有给出统一题集和对照结果。它足以让人想接上新接口试试，还不能据此判断所有中文搜索任务的优劣。

已经做过的事，是把 DeepSeek 搜索 API 包成 Skill，接进自己的项目。节目随后提出，还可以扩展关键词、并行搜索，再汇总结果。这部分是进一步组织搜索流程的想法。

接入以后，开发者会遇到一个很实际的问题：返回了几十条链接，哪些值得读，读到什么程度可以给出答案？

摘要缺的那一句，可能正好影响结论

DeepSeek 文档介绍了 Search 和 Fetch：前者寻找网页并返回结构化结果，也可请求附带正文；后者读取指定网页，返回 Markdown。应用可以按需要安排检索与正文读取，无需固定成两个步骤。

假设要查一款软件能否导出数据。搜索摘要提到支持导出，正文却说明只支持某个付费档位，且只能导出部分字段。若答案停在摘要那一句，用户可能购买之后才发现不适用。

一项有用的核对方式，是先写清具体问题：需要导出哪些字段、用什么格式、使用哪个版本。再到官方说明中逐项寻找。页面读不到时，可以换官方帮助页或更新记录；始终找不到，就明确留下缺口。

查导出功能时，产品名加格式名称，可以找到操作说明；加版本号，可以找到功能何时加入；加限制条件，可能找到不支持的情况。这几组搜索各有用途。

如果只是把同一句话换十种措辞，很可能反复命中相同页面。并行请求让它们更快返回，却仍要为重复材料付出调用和阅读成本。

可以保留几道过去答错或找不到的真实问题，每次更换搜索入口后重新检查。除了有没有找到，还看是否找到当前版本、正文能否读取、答案有没有漏掉条件。返回条数最多的那次，不一定最适合使用。

旧评测说没有导出功能，新文档说已经提供，可能是版本更新。官方文档写支持，用户却报告某种文件失败，可能是格式限制。先查清这些关系，比统计赞成和反对的页面数量更有用。

答案应把条件写在结论附近。例如支持导出，但仅包含用户自行创建的数据；导出路径适用于当前桌面版，移动端另有入口。读者需要这些区别来做决定。

来源链接也应指向支撑这句话的具体页面。产品首页只能证明产品存在，不能证明某项功能已经上线。如果材料只有转述，就继续寻找原始说明，或把未确认之处保留下来。

查到明确的操作说明、适用版本和限制后，这个问题就可以结束。若用户要比较长期可靠性，那是另一项调查，需要使用记录和故障材料。搜索范围应随问题调整，不必每次都做成一份长报告。