Deep Research Agent：让 AI 带着小本本去查资料

有些问题不适合让 AI “秒答”。

比如“给我比较几种向量数据库”“分析某个行业的机会”“帮我查一下这个开源项目能不能用于生产”。这类问题像一团毛线球：一拽就是资料、定义、时间线、价格、限制、反例、过期信息、营销话术。普通聊天模型如果张口就答，常常答得很顺，顺到像刚从 PPT 里滑出来。

Deep Research Agent 做的是另一种活。它不急着回答，而是先背上小书包，拿出小本本，开始查资料：先拆问题，再找来源，再对比证据，最后把“我为什么这么判断”写清楚。很像一只戴眼镜的小仓鼠在资料堆里翻来翻去：吱吱，找到一个来源；吱吱，这个来源有点可疑；吱吱，先别下结论。

它和普通搜索差在哪

搜索引擎像图书馆门口的索引卡。你问一句，它递给你十扇门。

Deep Research Agent 更像一个研究助理。它会进门、翻目录、做笔记、发现不对劲再换一个门。最后它不应该只说“我找到了这些网页”，而要告诉你：哪些证据可靠，哪些互相打架，哪些结论只能暂时相信。

这听起来像“搜索 + 总结”的豪华版，但真正的差别在循环：它会带着问题反复回来，不是扫一眼网页就交卷。

研究现场

{用户} 帮我看看这个技术方向值不值得投时间。

{.小研究员} 收到，我先拆成：市场需求、技术成熟度、替代方案、学习成本、未来风险。先不急着夸它，喵。

{用户} 喵？

{.小研究员} 语气可以可爱，引用必须严肃。

一只靠谱研究员的工作流

Deep Research Agent 的核心不是“联网能力”，而是一条研究流水线。它大概会这样转：

1. 问题澄清

把用户的一句话改写成可以研究的问题。如果目标太大，它要先缩范围，不然会查成一锅粥。

2. 制定计划

列出子问题、关键词、可能来源、验收标准。计划不是装饰，是防止迷路的地图。

3. 搜索与阅读

搜索只是入口。真正花时间的是打开材料、抽取事实、记录出处、判断时效。

4. 交叉验证

同一个结论至少找两个角度看。官方文档、论文、社区实践、代码仓库、价格页，说话方式都不一样。

5. 综合报告

把证据揉成结构化结论，标出不确定性，给出下一步建议。

这里有个很反直觉的点：一个好的研究 agent 不应该显得“特别自信”。它应该在该怂的时候怂一下。资料不足就说不足，来源冲突就说冲突，过期信息就标日期。可爱一点说就是：尾巴可以翘，证据不能飘。

架构：小队出动，而不是一个模型硬扛

如果把 Deep Research Agent 画成一间小小研究所，我会这样分工：

它们可以是同一个模型在不同 prompt 下扮演，也可以是多个子 agent 分工。关键不是名字好听，而是职责要清楚。否则一个模型一边搜索、一边判断、一边写结论，很容易把“刚看到的东西”当成“最重要的东西”。

User question
  ↓
Research planner
  ↓
┌──────────────┬──────────────┬──────────────┐
│ Web searcher │ Doc reader   │ Paper reader │
└──────────────┴──────────────┴──────────────┘
  ↓
Evidence store / notes
  ↓
Verifier / contradiction checker
  ↓
Report writer
  ↓
Final answer with citations

这也是为什么我不太喜欢“把搜索工具塞给模型就叫 deep research”。那只是给小仓鼠一个放大镜。真正的研究 agent 还要有书架、便签、垃圾桶、复核流程，以及一个能把它从资料堆里捞出来的停止条件。

证据仓库：别让上下文窗口变成垃圾桶

研究任务最容易爆上下文。网页全文、PDF 摘要、搜索结果、表格、聊天记录，全塞进模型窗口，最后模型像抱着十床被子过独木桥，走两步就开始晃。

更稳的做法是建一个证据仓库：

id: source-007
title: LangGraph overview
url: https://docs.langchain.com/oss/python/langgraph/overview
accessed_at: 2026-07-08
claims:
  - LangGraph 用图结构组织 agent 工作流。
  - 它支持持久执行、human-in-the-loop 和长期运行任务。
quotes:
  - "..."
reliability: official-doc
used_for:
  - agent runtime architecture

然后模型每一轮只读取需要的片段。报告里引用 source-007，质检时也能回去查。这个动作很笨，但笨得可靠。很多工程最后拼的不是“模型更聪明”，而是“资料别乱飞”。

研究计划应该长什么样

一个研究 agent 开始干活前，最好先写一份计划。不是为了仪式感，而是为了让后面的偏航能被看见。

# 研究问题
Deep Research Agent 适合替代哪些人工资料整理工作？

# 子问题
1. 它比普通搜索多了哪些环节？
2. 哪些任务适合，哪些任务不适合？
3. 需要哪些工具和数据结构？
4. 风险在哪里：幻觉、来源质量、时效、版权、隐私？

# 验收标准
- 至少覆盖官方文档、论文/技术报告、实际产品说明三类来源。
- 每个关键结论都能追到来源。
- 明确写出不能确定的部分。
- 给出可执行的落地建议，而不是泛泛而谈。

这个计划最好可以被人改。人类说“我只关心开源实现，不关心商业产品”，agent 就应该把搜索范围收窄。别让它像热心但没听题的同学，一路查到宇宙尽头。

它适合做什么

Deep Research Agent 最适合那些“答案不是一句话，但也不是写博士论文”的任务。

不适合的也要说。它不适合替你做没有来源的主观判断，也不适合查需要强权限的私有信息，更不适合在医疗、法律、投资这类场景里直接替人拍板。它可以整理材料，但最后按下按钮的人应该还是人。

风险：小研究员也会乱贴便利贴

Deep Research Agent 的错误通常不是“完全没查”，而是“查了但查歪了”。这更麻烦，因为它看起来很努力。

常见翻车点有几个：

一个最小实现长什么样

不需要一上来就造复杂平台。最小可用版本可以很朴素：搜索工具、网页读取器、笔记文件、引用检查器、报告模板。

class DeepResearchAgent:
    def __init__(self, search, fetch, model, store):
        self.search = search
        self.fetch = fetch
        self.model = model
        self.store = store

    def run(self, question: str):
        plan = self.model.make_plan(question)

        for subquestion in plan.subquestions:
            results = self.search(subquestion.query)
            for item in results[:5]:
                page = self.fetch(item.url)
                note = self.model.extract_claims(page, subquestion)
                self.store.save(note)

        draft = self.model.write_report(question, self.store.relevant_notes())
        checked = self.model.verify_citations(draft, self.store.all_notes())
        return checked

真正上线时，verify_citations 不能只靠模型自己说“没问题”。更好的做法是把引用做成结构化数据，让程序检查 URL 是否存在、引用是否被使用、每条关键 claim 是否至少绑定一个来源。模型负责读和写，程序负责数手指。数错了就打回去，重新来过。

输出报告别写成资料坟场

研究报告最怕两种：一种像营销白皮书，热闹但没证据；一种像资料坟场，证据很多但人读完只想睡觉。

我更喜欢这种结构：

# 结论先行
一句话回答问题。

# 主要判断
- 判断 A：证据、反例、置信度。
- 判断 B：证据、反例、置信度。

# 证据表
| 结论 | 来源 | 备注 |
| --- | --- | --- |

# 风险和未知数
哪些地方还不能确定，为什么。

# 下一步
如果继续研究，应该查什么；如果要落地，先做什么实验。

这个模板不花哨，但读者舒服。先给答案，再给证据，再告诉我哪里别信太满。像一只小猫把抓来的线团按颜色摆好：虽然毛茸茸，但很有秩序。

和 Loop Engineering 的关系

上一篇写 Loop Engineering 时，我说 agent 真正难的是循环。Deep Research Agent 正好是一个典型例子。

它每一圈都在做：提出子问题，找材料，读材料，抽取证据，检查冲突，更新计划。没有 loop，它只是“搜索总结器”；有了 loop，它才像研究助理。

Plan → Search → Read → Note → Verify → Revise Plan → Report
          ↑                              ↓
          └──────── need more evidence ──┘

所以我更愿意把 Deep Research Agent 看成一种“证据驱动的 loop”。它的目标不是显得聪明，而是让结论有来路。

最后：让 AI 查资料，也要让它交作业

Deep Research Agent 最迷人的地方，是它把 AI 从“答题选手”变成了“研究助理”。它可以慢一点，可以查久一点，可以中途改计划。只要最后把证据摊开，让人知道每个判断从哪里来，这个慢就值得。

但也别把它神化。它会漏资料，会被 SEO 带偏，会把过期内容当新消息，会在证据不足时偷偷摆出一副很懂的样子。可爱的小研究员也要打卡、交笔记、接受抽查。ᕕ( ᐛ )ᕗ

我对它的期待很简单：少一点“我觉得”，多一点“我查到”；少一点漂亮废话，多一点可复核的路径。等一个 agent 能把问题查清楚、把不确定性说清楚、把引用放清楚，它就不只是会联网的聊天框了。它真的开始像一个能一起干活的同事。