AI Agent做调研时如何留下证据链
把 AI Agent 调研讲成可复核的证据链工作流：从研究问题、检索计划、来源台账、证据摘录、主张卡片、冲突记录、运行 trace、引用输出到人工复核，让每个结论都能回到来源、过程和责任边界。
很多人第一次让 AI Agent 做调研时，最关心的是速度：能不能十分钟读完二十篇资料，能不能把英文文档变成中文摘要，能不能直接给出一份报告。等把报告拿去给同事、客户或老板看，另一个问题才会冒出来：这些结论到底从哪里来？
如果答案只有一串链接，仍然不够。链接可能打不开，页面可能已经改版，引用可能并不支撑那句话，多个来源之间可能互相冲突。更麻烦的是，Agent 的最终输出通常很顺滑，顺滑到人很难看出哪一句是事实、哪一句是推断、哪一句只是模型把几个概念连在一起的类比。
所以，调研 Agent 的关键能力不是“会搜”，而是“能留下证据链”。证据链的意思，是把一个答案从最终段落拆回一组可检查对象：它为了什么问题而搜，搜过哪些词，打开了哪些页面，采纳了哪几段材料，生成了哪些中间判断，哪些结论有来源，哪些只是建议，哪里存在冲突，最后由谁复核。
本文讨论的是面向外部读者的工程方法，不是某一家厂商的唯一标准。官方文档能确认的事实包括：OpenAI 的 Agents SDK 可以记录模型调用、工具调用、handoff、guardrails 和自定义 span；OpenAI 的 Web search 工具会返回搜索调用、引用和来源字段；Claude 的 citations 与 search results 功能强调把回答锚定到来源内容；W3C PROV 把 provenance 理解为与数据或事物生成有关的实体、活动和人，用于评估质量、可靠性或可信度。基于这些事实，本文给出一套可落地的调研证据链设计。
证据链不是“参考资料列表”
很多报告最后都会附一个“参考资料”列表，但这不是完整证据链。参考资料列表只说明“我看过这些东西”，不能说明“哪条结论来自哪一段材料”。
一个 Agent 说“某公司在 2026 年推出了新产品”，这句话至少需要回答四个问题：来源是谁？来源发布时间是什么？页面里具体哪一段支撑这个说法？这个说法是官方公告、媒体报道、第三方评论，还是社区传言？
如果报告只在末尾放了五个链接，读者仍然要自己重新打开所有页面，猜哪一个链接对应哪一句话。对小任务来说这只是麻烦；对商业、技术、安全、医疗、财经、政策类调研来说，这会变成真实风险。
证据链要解决的不是“看起来专业”，而是三个实用问题。
第一，能复核。读者能从每个关键结论回到原始来源，看到上下文，而不是只能相信 Agent 的总结。
第二，能追责。出现错误时，团队能判断是检索没找到一手资料、来源本身过期、摘录理解错了，还是最终写作时把事实和推断混在一起。
第三，能迭代。下一次调研不是从零开始，而是继承已有来源、排除已判定无效的材料、补充新的证据。
把调研拆成九个对象
要让 Agent 留下证据链，最稳妥的办法是把“写一份报告”拆成九个对象。
第一个对象是研究问题。它要说明本次调研到底要回答什么，不回答什么。比如“比较三种开源 RAG 框架的生产可用性”比“调研 RAG”更容易留下证据。
第二个对象是检索计划。它记录关键词、搜索范围、排除条件、语言、时间窗口和需要优先看的来源类型。一个好计划会先找官方文档、论文、GitHub 仓库、标准组织、公司公告，再看媒体解读和社区讨论。
第三个对象是来源台账。每个来源都要有编号、标题、URL、作者或机构、发布时间、访问时间、来源类型、可信等级、是否采纳、采纳原因。来源台账的价值在于，它也记录“为什么没有用某个来源”。
第四个对象是证据摘录。摘录不是整页复制，而是把与问题相关的关键段落、表格、参数、版本号、发布日期或定义保存下来，并附上所在页面位置。为了版权和可读性，公开报告通常不需要长篇引用，但内部证据包可以保留短摘录、摘要和定位信息。
第五个对象是主张卡片。报告里的每个关键判断都应该变成一张主张卡：主张是什么，证据编号有哪些，是否有反例或冲突，可信等级如何，是否需要人工确认。
第六个对象是冲突记录。调研中经常出现官方文档和博客不一致、旧版本和新版本不一致、公司说法和用户反馈不一致。成熟的 Agent 不应该把冲突抹平，而应该写明“哪里冲突、暂按哪个来源、为什么”。
第七个对象是运行记录。Agent 什么时候调用了搜索工具、打开了哪些页面、调用了哪些内部工具、得到了什么返回、哪些步骤失败、哪些工具需要人工批准。OpenAI Agents SDK 的 tracing 文档强调，trace 可以记录模型调用、工具调用、handoff、guardrails 和自定义 span，这正是运行记录的工程基础。
第八个对象是引用输出。最终文章或报告里的关键事实要带可点击来源，或者至少能映射到包内的来源编号。OpenAI Web search 文档也提醒，使用网页结果展示给用户时，inline citations 应该清晰可见并可点击。
第九个对象是复核记录。它记录谁看过这份报告，复核了哪些高风险主张，改掉了哪些表述，哪些问题仍然不确定。没有复核记录，证据链就少了最后一道人的判断。
这九个对象听起来多，但实现时不一定复杂。哪怕只是一个 Markdown 表格加一个 JSON manifest，也比一份没有来源映射的漂亮报告可靠得多。
来源分级：不是所有链接都一样
调研 Agent 最常见的错误，是把所有链接都当成同等证据。一个官方 API 文档、一篇二手教程、一条社交媒体帖子、一篇过期博客，不能用同一个权重支撑同一句结论。
可以把来源分成五级。
L1 是一手来源：官方文档、公司公告、标准规范、论文原文、GitHub 仓库、监管披露、数据发布机构。这类来源优先用于定义、版本、参数、发布日期、政策口径。
L2 是权威解释：大学、研究机构、标准组织、主流开发者文档、官方 cookbook、专业机构报告。它适合解释机制、方法和边界。
L3 是专业媒体和行业分析：它适合了解事件背景、采用情况、产业解读，但不应单独支撑高风险事实。
L4 是社区经验：GitHub issue、论坛、Reddit、X、博客、测评。它很适合发现问题、场景和真实使用痛点，但需要交叉验证。
L5 是未知或低可信来源：转载站、无作者页面、带强营销目的的软文、没有日期和出处的图文。它可以作为线索，不应作为主要依据。
来源分级不是为了显得严苛，而是为了让 Agent 在写作时知道“这句话能说到什么程度”。如果只有 L4 社区讨论，就应该写“有用户反馈”“社区讨论中出现过”，而不是写成“行业已经证明”。如果只有二手教程，就应该继续追到官方文档或原始论文。
每条主张都要能回到证据
证据链有用的地方，是把最终报告里的“主张”逐条挂到来源上。
比如一份关于某个 AI 框架的调研报告，可能有这些主张：
- 该框架支持工具调用。
- 该框架提供运行 trace 或 observability。
- 该框架的某个功能仍在 beta。
- 社区经常反馈某类集成问题。
- 团队可以优先试用，但不建议立刻用于高风险生产流程。
前四条偏事实，必须有来源。第五条是建议，也需要说明建议基于哪些事实，但不能伪装成官方结论。
一个实用模板是：
C-001：主张文本 证据：S-003#p2、S-005#section-tracing 类型：事实 / 推断 / 建议 / 类比 可信度：高 / 中 / 低 冲突：无 / 与 S-009 有版本差异 复核：待人工确认 / 已复核
这个模板的重点不是格式，而是让 Agent 不能偷懒。它必须告诉读者：这句话到底靠什么站住。
同时，证据链要避免“一个来源包打天下”。技术功能可以用官方文档支撑；真实使用问题最好再看 GitHub issue 或社区讨论；市场采用情况需要公司公告、客户案例或可信行业资料；安全风险要优先看官方安全文档、标准、报告或漏洞公告。
记录检索过程，而不是只保存结果
很多团队只保存 Agent 的最终报告，不保存检索过程。这样一来，报告一旦出错，就很难知道错误从哪里开始。
OpenAI 的 Web search 文档里提到，工具输出会包含 web_search_call，并且 sources 字段可以展示模型形成回答时咨询过的完整 URL 列表；OpenAI Agents SDK 的结果对象也能区分工具调用、工具输出、需要批准的工具项和 handoff 项。这类结构给了我们一个启发：调研不是一段文本，而是一串事件。
一个最小运行记录可以包含：
query：本次检索词。time：检索和访问时间。tool：调用的搜索、浏览、数据库或内部工具。input：工具输入，不包含密钥或敏感凭据。output_ref：工具返回的结果编号或摘要。selected_sources：被采纳的来源编号。rejected_sources：被排除的来源及原因。error：失败、超时、页面不可读、权限不足。
注意，这里不要求公开所有内部 trace。对外报告可以只展示必要引用；内部审计包再保存更完整的运行记录。关键是系统自己不能只有最终答案。
冲突比结论更值得保留
调研 Agent 很容易被训练成“给我一个确定答案”。但真实世界里，资料经常不确定。
比如官方文档显示某功能支持 Python SDK，GitHub issue 里用户说某平台还不稳定；公司博客说功能已经上线，开发者文档仍标 beta；一篇媒体报道说市场规模很大，但原始报告的统计口径只覆盖某个地区。
这种时候，差的报告会把冲突消化成一句顺滑结论：“该功能已成熟可用”。好的证据链会写成：“官方文档显示该功能可用；但社区反馈显示某类环境下仍有兼容性问题。本文将其归为可试用、需验证，不归为默认生产可用。”
冲突记录至少包含三项：冲突来源、冲突内容、暂定处理方式。处理方式可以是“以官方最新文档为准”“以发布日期更新者为准”“保留不确定，不下结论”“需要实测验证”。这比强行给出一个单点答案更诚实。
引用不是装饰，而是用户界面
对读者来说，引用最好是可点击、可定位、可理解的。OpenAI Web search 文档要求当网页结果信息展示给终端用户时，inline citations 应清晰可见并可点击。Claude 的 citations 文档也强调，引用应帮助用户追踪和验证每个回答背后的来源。
这说明引用不是报告末尾的装饰，而是一种用户界面。读者看到一个关键事实时，应该能立刻点回来源；看到一个建议时，应该能知道这是作者判断，不是官方原话；看到一个不确定结论时，应该能看到冲突依据。
中文报告里可以用三种方式呈现引用。
第一种是正文脚注：适合长文章和白皮书。
第二种是段落后来源编号：适合内部调研报告，比如 [S-003, S-007]。
第三种是结论表格：每一行一个主张，后面列证据、可信度和复核状态。
不建议把引用全塞到最后。读者最需要证据的时候，往往就在读到那一句判断的当下。
用 PROV 思路设计调研记录
W3C PROV 的价值在于，它给“来源从哪里来、谁生成了什么、经过了什么活动”提供了通用语言。PROV 的核心不是 AI 专用，但非常适合启发 Agent 证据链。
在调研场景里，可以把三类对象映射出来。
实体：网页、PDF、论文、代码仓库、数据表、截图、摘录、最终报告。
活动：搜索、打开网页、下载文件、抽取段落、比较版本、生成摘要、人工复核。
主体：Agent、工具、人工审稿人、来源发布机构。
这样一来，最终报告就不是凭空出现的文本，而是由一组实体经过一组活动生成，并由某些主体负责。哪怕不用完整 PROV 标准落库，只要借用这个思路，调研系统就会更清楚：每个结论都应该有输入、过程、输出和责任边界。
一个很小的例子：
S-001是 OpenAI Web search 文档。A-004是 Agent 在 2026-07-03 打开并摘录该文档。E-008是“Web search 输出包含引用和来源字段”的证据摘录。C-003是文章里“引用应该可点击可见”的主张。R-002是人工复核记录，确认该主张未夸大官方口径。
这就是一条简单证据链。
高风险调研要有人在环
不是所有调研都需要同样强的复核。写一篇工具入门文章，和写一份投资、医疗、法律、生产安全、客户承诺相关报告，不应使用同一套门槛。
OpenAI Agents SDK 的 human-in-the-loop 文档描述了一种机制：当敏感工具调用需要批准时，Agent 可以暂停，等待人批准或拒绝，再继续运行。这个思想也可以用于调研本身。高风险主张不是让 Agent 自己一路写到底，而是进入人工复核。
可以把主张分成三类。
低风险主张：一般背景、定义、功能说明，只要有来源即可。
中风险主张：涉及版本、价格、兼容性、可用性、市场趋势，需要至少两个来源或一个一手来源。
高风险主张：涉及法律义务、医疗建议、金融判断、安全漏洞、生产操作、客户承诺，必须人工确认，并且要在正文里写清楚边界。
人不需要审核每一句话，但必须审核会产生后果的结论。这样 Agent 既能提高速度，又不会把责任甩给模型。
一份可执行的证据链清单
如果你正在设计一个调研 Agent，可以从下面这份清单开始。
第一，任务开始时写清楚研究问题、范围和不回答的问题。
第二，先列来源优先级：官方、论文、仓库、标准、公告、监管或数据机构，再看媒体和社区。
第三，保存检索词、访问时间和工具调用记录。
第四，每个来源都给编号、类型、发布日期、访问时间、采纳状态。
第五，摘录关键证据时保留位置、摘要和采纳原因，不要只存整页链接。
第六，把关键结论拆成主张卡，标记事实、推断、建议或类比。
第七，每张主张卡至少挂一个证据编号；高风险主张优先挂一手来源。
第八，遇到冲突时保留冲突，不要用圆滑文字糊过去。
第九，最终报告里的关键事实要有可点击引用或来源编号。
第十，保存复核记录：谁复核、改了什么、哪些仍待确认。
结论：好调研不是更会写，而是更可追溯
AI Agent 会让调研速度变快，但速度越快，越需要证据链。没有证据链的 Agent 报告，看起来像知识产品，其实仍然是一段很难复核的生成文本。有证据链的 Agent 报告，才更接近可协作的研究资产。
更值得追求的不是“让 AI 一次写对”，而是让每个结论都能回到来源、过程和复核记录。官方文档确认的能力，例如工具调用、Web search 来源字段、trace、citation、human-in-the-loop，都在提醒我们同一件事：Agent 的价值不只在最终答案，也在它能把工作过程变成可检查的结构。
如果一份调研报告能回答“我为什么这样说、我从哪里知道、我哪里不确定、谁复核过”，它就已经比多数漂亮但空心的 AI 文本可靠。证据链不是给 Agent 增加负担，而是让它进入可以被团队使用的工作流。