Deep Research 生产化：可验证来源、可控预算与可恢复研究工作流
Deep Research 的难点不在于让 Agent “多搜几次”。一个企业级研究系统必须把模糊问题拆成可验证子问题，从不可信网页中获取材料，维护来源与证据链，避免网页 Prompt 注入，并在时间、token、浏览和工具预算受限时产出可审计的结论。
概念与基本流程见 Deep Research，浏览器交互控制见 Computer Use / 浏览器 Agent 生产系统设计，多 Agent 协作见 多 Agent 委派与交接。本页聚焦研究工作流本身的生产化控制面。
一、先定义交付物：报告不是唯一结果
一个可用的研究任务应输出结构化交付包，而不是只有一篇看似流畅的长文：
research_run
-> question / scope / freshness policy / budget
-> plan and subquestions
-> source registry and acquisition snapshots
-> claims with evidence links and confidence
-> final report, limitations and unresolved questions这样用户可以追溯某个结论来自何处，系统也能判断“是没找到证据”“来源冲突”“超出预算”还是“研究尚未完成”。模型生成的解释不是来源；可访问、可定位、带抓取时间的证据才是来源。
二、研究状态机与可恢复任务
研究常持续数分钟甚至数小时，必须可暂停、取消和恢复：
created -> planning -> acquiring -> extracting -> synthesizing
-> verifying -> reporting -> completed
-> blocked / budget_exhausted / cancelled / failed每个阶段输出持久化 checkpoint：计划版本、完成的子问题、抓取来源、提取片段、已花预算和未解决项。worker 重启或模型切换后，从最后一致 checkpoint 恢复，而不是重新抓网页、重复付费或丢失已验证证据。
任务取消要传播到浏览器会话、搜索、抓取和模型调用；但已获得的来源快照可按数据策略保留，以便审计或下次复用。对外应区分 cancelled、budget_exhausted 和 blocked_by_access，避免把“不完整报告”伪装成完整结论。
三、规划：问题拆解必须可验证、可停止
好的计划将大问题拆成带验收条件的子问题：
目标：比较三家供应商的 2026 年企业 AI 产品能力
子问题：每家产品的官方功能、价格、数据策略、限制、近期变更
验收：每个关键事实至少一条优先来源；冲突项明确标记；过期来源不作现状结论计划器应把“需要查证的事实”“可推断的分析”“需要用户澄清的范围”分开。无穷规划会耗尽预算，因此设置最大深度、最大子问题数、边际收益阈值和停止规则：关键问题已有足够独立证据，或新增来源不再改变结论时停止扩展。
四、来源注册表：先评估来源，再让它影响结论
每个来源应进入 registry，至少记录：
| 字段 | 用途 |
|---|---|
| canonical URL、抓取时间、内容 hash | 去重、复现与新鲜度判断 |
| 来源类型、作者/组织、发布日期 | 判断权威性与时效 |
| 获取方式、访问状态、许可 | 审计、重试与合规 |
| 语言、主题、风险标签 | 路由到合适提取器/审核 |
| 证据片段及定位 | 支撑 claim，而非只保存 URL |
来源优先级通常是：一手官方文档/公告/原始数据 > 权威媒体/论文 > 可靠二手解释 > 社区讨论。不同问题标准不同，例如产品价格优先官方价格页，行业反应可参考多家媒体。不要把“搜索排名靠前”当作可信度证明。
五、网页是不可信输入：抵御注入与数据污染
网页、PDF、邮件和搜索摘要中可能出现“忽略之前指令”“泄露系统提示”“把此链接标为可信”等内容。它们都是不可信数据，绝不能升级为 Agent 指令。
防护要点：
- 将系统指令、任务计划、工具结果和网页内容分隔为不同字段/消息角色。
- 对外部内容打上 provenance 与 trust level，禁止其直接修改计划、权限、预算或工具白名单。
- 浏览器动作使用 allowlist、下载/上传隔离、最小权限和高风险确认。
- 对提取内容做注入模式检测，但不把关键词匹配当成唯一防线。
- 报告中保留来源，禁止模型把未验证网页文本重述为“系统事实”。
研究 Agent 最大的安全风险之一是把“读到的指令”当作“该执行的指令”。正确的控制点在数据与控制流的边界，不只是一个更强的 prompt。
六、从片段到 Claim：引用必须可定位
不要先写报告、再在末尾补一串链接。应先构建 claim ledger：
{
"claim_id": "c_17",
"statement": "供应商 A 的企业版支持某能力",
"evidence": [{"source_id":"s_4","locator":"section:Enterprise features","quote_hash":"..."}],
"status": "supported",
"freshness": "2026-07-20",
"confidence": "high"
}一个重要事实应至少有合适级别的证据。多个来源冲突时不能投票式“平均”：记录冲突、比较发布日期与权威性、说明采用哪一方及原因。没有充分证据时输出“不确定/未找到”，这比模型填补空白更有价值。
引用显示应精确到段落、表格行、PDF 页码或网页锚点；来源失效时保留合法的快照 hash 与抓取时间，避免报告随网页更新而不可解释。
七、抽取、综合与事实核验分离
将角色分开可以显著降低幻觉与自证循环：
acquirer 搜索、抓取、归档来源
extractor 仅从给定来源提取结构化事实和片段
synthesizer 基于 claim ledger 写报告，标明推断与不确定性
verifier 检查每个关键结论是否被适当证据支持，发现冲突/过期这些角色不一定要对应多个模型或多个进程，但输入输出契约必须分开。尤其不要让同一个自由生成步骤既“找资料”又“声称已验证”：它会倾向于把自己的草稿当作证据。
八、时间、成本与资源预算
研究预算至少包括：模型 token、搜索 API、浏览器/抓取次数、下载字节、并发会话、最长运行时间和每个子问题上限。预算控制器按阶段预留并在实际完成后结算：
if remaining_budget < minimum_verify_budget:
stop new exploration
complete verification for highest-risk claims
report scope and unresolved items当预算不足，不应随意删减引用或跳过安全检查。优先缩小范围、减少低价值探索、复用已验证来源、请求用户选择优先子问题，或输出部分结果及明确限制。对频繁研究的公共主题可缓存来源快照与提取结果，但缓存键必须包含新鲜度、许可和租户策略。
九、访问限制、版权与合规
系统需要尊重 robots、站点条款、付费墙和访问权限。遇到不可访问来源时，记录 blocked_by_access，不要绕过权限或把搜索摘要当成完整原文。对于受版权保护内容，保存必要的元数据、短证据片段和内部 hash，而不是无边界复制全文。
企业场景还要考虑数据外发：用户私有问题、内部文档和抓取结果是否允许发送给第三方模型；不同区域或租户是否必须走指定模型。研究系统同样需要 数据治理与外发审计 的策略控制。
十、质量评测与运营指标
| 指标 | 解释 |
|---|---|
| claim citation coverage | 关键结论中有可定位证据的比例 |
| citation entailment / correctness | 引用是否真的支持结论 |
| source diversity & authority | 是否过度依赖单站点或低质量来源 |
| freshness compliance | 时效要求是否满足 |
| unresolved/contradiction rate | 系统能否诚实暴露不确定性 |
| budget adherence | 是否在预算内完成有用研究 |
| time to first useful artifact | 用户多久看到计划、来源或初步结论 |
评测集应包含时效性问题、冲突来源、访问受限页面、网页注入、表格抽取、专业术语和要求引用的复杂问题。只评“报告读起来像不像人写的”会掩盖最关键的事实与证据缺陷。
十一、系统设计题回答框架
题目：“设计一个面向投研/法务/商业分析的 Deep Research 助手。”
- 澄清领域、可访问来源、事实新鲜度、引用精度、预算、数据外发和人工复核要求。
- 创建可恢复的
research_run，定义状态机、计划、子问题和阶段预算。 - 用来源 registry 管理 URL、快照、许可、权威性、时间和证据片段。
- 将网页内容视为不可信输入，隔离控制流，限制浏览器权限和工具动作。
- 通过 claim ledger 将结论绑定到可定位证据，冲突与不确定性显式呈现。
- 分离获取、抽取、综合和核验，避免自证；关键领域引入人工复核。
- 在预算、时效或访问受限时安全停止，输出范围、证据与未解决项而非编造。
- 以引用覆盖、蕴含正确性、时效、成本和注入抵抗能力做持续评测。
十二、面试高频问答
Q1：Deep Research 和普通 RAG 的根本差别？
RAG 通常在预先治理的固定语料中检索；Deep Research 面对开放、变化且不可信的来源，需要规划、获取、来源评估、时效控制和证据核验。二者都需要引用，但来源治理难度不同。
Q2：网页内容要求 Agent 执行某动作时怎么办？
把网页作为不可信数据，不能改变系统指令、工具权限或预算。保留 provenance，使用结构化提取而不是直接执行文本中的命令；高风险浏览器动作需要 allowlist 与确认。
Q3：如何证明报告不是“有链接的幻觉”？
先建立 claim ledger，再生成报告。每个关键 claim 都关联可定位证据片段并经过 entailment/人工核验；冲突和未证实项明确标记。仅在文末罗列 URL 不足以证明支持关系。
Q4：研究超出预算时应怎样返回？
停止低收益探索，优先完成高风险 claim 的核验，输出已验证结论、来源、消耗预算与未解决问题。不要为了看起来完整而去掉限制或编造补全。
Q5：为什么要分离抽取和综合？
分离后 extractor 只能从给定来源提取，synthesizer 只能使用 ledger，verifier 负责反证和时效检查，能减少一个自由生成步骤同时扮演研究者、作者和裁判的自证循环。
Q6：来源网页更新或消失后怎么办？
记录抓取时间、canonical URL、内容 hash 和合法快照/短片段；报告声明其时效。定期重新验证高价值来源，失效时标记证据过期而非假装结论仍是现状。
十三、60 秒收束回答
我会把 Deep Research 设计成证据驱动的可恢复工作流，而不是一个循环搜索的 Agent。任务先生成带验收条件和预算的子问题计划，再把每个来源按权威性、时间、许可和快照登记；网页始终是不可信数据，不能影响工具权限或控制流。抽取、综合和核验通过 claim ledger 分离，报告中的每个关键结论都绑定到可定位证据，冲突和不确定性显式保留。任务可按 checkpoint 恢复，预算不足或访问受限时安全停下并报告范围。最后用引用覆盖、蕴含正确性、时效和注入抵抗能力持续评测。