Agent 工程实战手记 #001：Deep Research 是什么，为什么值得你认真学

这是「Agent 工程实战手记」系列的第一篇。这个系列没有固定顺序，每篇独立成篇------你可以从任何一篇开始读。我会写工程实战、也会写底层原理，两者交替出现，因为我相信理解原理是做出好工程决策的前提。

关于我：从医疗行业转行，现在是一家 AI 创业公司的技术负责人。这个系列记录的是我在真实项目里踩过的坑、做过的选择、得出的结论。

熟悉我的老朋友都知道，我在医疗行业待过，现在带团队做 AI 应用落地。这两段经历有一个共同点：我待过的两家公司，都在很早的时候认真评估并实践了 Deep Research 的商业价值。

不是 demo，不是内部实验，是真实跑在业务流程里的东西。

所以当我看到网上有人说"Deep Research 要被全自主 agent 取代了，还有没有必要学"，我的第一反应是：这个问题问错了。

今天这篇文章，我想把 Deep Research 讲清楚------它是什么、怎么工作、为什么在 2025 年仍然值得认真对待，以及如果你想把它变成简历上真实的工程经验，该怎么做。

"AI 搜索"和"Deep Research"不是一回事

先把概念理清楚，因为这个混淆非常普遍。

我们日常用的 AI 搜索------Perplexity、各种带搜索功能的 AI 助手------工作方式基本是这样的：

你提问 → 搜几条结果 → 把摘要喂给模型 → 模型总结给你

速度快，十几秒出结果。但它实际上只做了"搜索"和"总结"两步，跳过了中间最关键的部分：真正去读内容、判断够不够、再决定要不要继续找。

Deep Research 做的事情更接近一个研究员在工作：

拆解问题 --- 把你的大问题分解成几个子问题
搜索 --- 对每个子问题分别去查
阅读 --- 真的打开网页读内容，不是只看摘要片段
反思 --- 读完之后问自己：够了吗？还差什么？
再搜索 --- 如果不够，继续找
综合 --- 把所有来源的信息整合成一份有条理、有引用的报告

关键词是迭代。它在循环：搜 → 读 → 想 → 再搜，直到问题被回答清楚，或者达到设定的资源上限为止。

这就是为什么跑一次 Deep Research 要 10 到 30 分钟------它不是在等模型生成，它是在真的做调研。

一个数字说明问题

HuggingFace 做过一个实验：同一个前沿模型，一个直接调用，一个套上 Deep Research 的 agentic 框架，在 GAIA 基准测试上跑。结果差了高达 60 个百分点^[[1]](#[1])。

模型没变，只是换了工作方式。

OpenAI 自己也公布过类似数据：裸模型在 GAIA 上得分不到 7%，套上 Deep Research 框架之后跳到了 67%^{[[1:1]](#[1:1])}。

这说明一件事：对于需要多步推理、跨来源对比的复杂问题，框架设计比模型本身更重要。

普通 AI 搜索------搜一次、综合一次------适合答案就在某一篇文档里的情况。一旦你的问题需要：

对比多个来源里互相矛盾的信息
第一轮搜完才知道下一步该搜什么
验证一个说法是否成立，而不只是找到它

它就不够用了。Deep Research 解决的正是这类问题------市场分析、竞品调研、文献综述、合规检查......这些原本要人花几小时甚至几天的工作。

这也是为什么哪怕到了 2025 年，大部分真实落地的 autonomous agent 应用场景仍然是 research。全自主 agent 令人兴奋，但在需要可控性、可解释性、结果可验证的企业场景里，Deep Research 这种半自主、有明确步骤的架构反而更实用、更容易上生产。

它内部是怎么跑的

理解架构不只是为了满足好奇心------它直接影响你之后做工程决策时的判断。

最常见的设计叫规划者-执行者模式（planner-executor pattern），大多数开源实现都是这个骨架：

规划者（Planner） 拿到你的问题，生成一批子问题，形成研究框架。比如你问"2025 年向量数据库市场格局"，它会拆成：主流产品有哪些、各自性能对比、定价模式、近期融资情况......

执行者（Executor） 针对每个子问题分别搜索、打开页面、提取关键内容。多个执行者可以并行跑，大幅缩短总时间------这是整个架构里最关键的性能杠杆。

综合步骤 把所有执行者收集到的内容过滤、去重，交给模型写出最终报告。

LangChain 在构建自己的 Open Deep Research 时踩过一个坑，值得记住：他们早期让子 agent 分别写报告的各个段落，再拼在一起。结果很糟糕------各段之间前后矛盾、内容重复、逻辑不连贯。最终的解法是：研究阶段可以并行，写报告必须由一个模型一口气完成 ^[[2]](#[2])。这个细节挺反直觉的，但想想也合理------综合需要全局视角，不能切片处理。

另一个值得理解的设计是 CodeAgent ，这是 HuggingFace smolagents 团队的创新点。普通 agent 用 JSON 格式描述"我要调用什么工具"，CodeAgent 直接写 Python 代码来执行动作。实验数据显示，相同配置下从代码方式切换到 JSON 方式，GAIA 得分从 55% 直接跌到 33%^{[[1:2]](#[1:2])}。原因不复杂：模型训练时见过的代码远比 JSON schema 多，用代码表达意图更自然、更可靠。

这些架构细节，在你之后读 RAG、读 multi-agent 系统的时候会反复遇到。现在理解清楚，后面省很多力气。

为什么不直接用现成的

既然有 OpenAI Deep Research、各种 AI 搜索产品，为什么要自己搭？

我试了一圈托管服务之后，有几个问题绕不开。

数据安全：全栈本地化才是真正的安全。 在医疗行业待过之后，我对数据合规格外敏感------它不是可以之后再考虑的事，是上线前必须解决的事。托管服务的问题在于，数据泄露点不只一个：你的查询发给了搜索 API，页面内容发给了 LLM API，研究结果存在对方的服务器上。真正的安全需要三层全部本地化------本地搜索引擎（比如 SearXNG 自建实例）、本地 LLM（Ollama 跑本地模型）、加上自建的 Deep Research agent。三层都在自己的服务器上，数据从头到尾不经过任何外部节点。这个项目三层都支持，开箱即用。

国内可用性是硬约束。 大部分好用的托管服务------Tavily、Perplexity------国内直连不稳定。不稳定不等于不能用，但对一个内部服务来说，不稳定就是不可用。自建可以直接接国内的搜索 API 和模型服务，稳定性完全自己掌控。

模型合规不是小事。 国内企业使用 AI 服务涉及数据出境合规要求，调用境外 LLM API 在某些行业和场景下存在合规风险。自建 + 国内合规模型（通义、DeepSeek 等）是目前最稳妥的解法，这个项目的模型层用 LiteLLM，国内主流 API 都可以直接接入。

Vendor lock-in 是慢性风险。 今天用得好的托管服务，明天可能改定价、改 API、或者直接下线某个功能。你的产品和工作流建在别人的基础上，对方的每一个决策都能影响你。自建就是把控制权拿回来------模型换了、搜索引擎换了，都是你自己决定的事。

定制搜索源是企业用例的关键差异。 托管服务只能搜公开网页。自建可以接入内部知识库、私有数据库、行业专属数据源------对于真正的企业调研场景，这往往才是最有价值的信息所在。

可观测性在生产环境里不是加分项，是必须项。 托管服务是黑盒------你不知道 agent 每一步做了什么、为什么得出这个结论、哪一步出了问题。自建可以全程 logging、追踪、审计。需要合规的行业尤其如此：你不只需要结果，你需要能解释结果是怎么来的。

成本会叠加得很快。 Deep Research 是 token 密集型的，一次研究可能消耗 5 万到 20 万 token。按托管服务定价长期跑，成本很可观。自建可以按需选模型------国内主流模型 API 价格通常比境外服务低得多，这个差距在规模上去之后非常显著。

开源实现：我怎么选的

OpenAI Deep Research 发布之后，开源社区反应很快------HuggingFace 团队在发布后第二天就跑出了第一个开源复现版本，发起了一场 24 小时冲刺^{[[1:3]](#[1:3])}。之后社区里冒出了一批实现，我把主要的都研究了一遍。

主要的候选项大概是这些：

GPT-Researcher --- 开源里功能最完整的，star 数最高。规划者-执行者模式做得很细，支持 PDF、Word 导出、JavaScript 页面渲染、MCP 集成......但对我们的用例来说太重了：8 个 skill manager 类、三级 LLM 策略、内部还依赖 LangChain 做上下文压缩。我们需要的只是搜索+综合，用不上这些，出了问题反而难排查。

LangChain Open Deep Research --- 架构设计上很好，三阶段拆分清晰，建在 LangGraph 上^{[[2:1]](#[2:1])}。但我们团队对 LangChain 的开发体验有顾虑------AI 测试工具 Octomind 在生产环境用了 LangChain 超过一年后将其完整移除，总结是：高层抽象一旦需要定制，就要扒好几层源码才能找到问题所在，移除之后"我们只需要写代码就好了"^[[3]](#[3])。LangGraph 比早期的 LangChain 好很多，但团队的共识是能不用就不用。

HuggingFace smolagents --- 最后选了这个。核心逻辑大约 1000 行，一个 agents.py 文件可以直接读完，出了问题能直接调试。CodeAgent 架构有实验数据支撑，GAIA 55%^{[[1:4]](#[1:4])}，Apache 2.0 license 商业使用没有风险。唯一的问题是它只是一个库------没有界面、没有任务管理、没有部署方案。

这就是我们自己做的部分。

我们在 smolagents 上面加了什么

库有了，但要变成一个真正可用的内部服务，还差很多。我们把这部分做成了开源项目：

👉 extracurricular-ai/open-deep-research-with-web-ui

设计上有几个核心考量：

Deep Research 很慢，不能让 UI 锁住。 一次研究跑下来 10 到 30 分钟。大部分工具的做法是锁住界面让你盯着转圈------这对生产力是很大的浪费。我们的做法是后台并行：提交问题后 UI 立刻解锁，你可以继续提交第二个、第三个，每个任务跑在独立子进程里，结果写入 SQLite。侧边栏随时切换查看各个任务进度，关掉浏览器回来结果还在。这个功能在现有所有开源 Deep Research 实现里是独有的。

配置门槛是很多人放弃的真正原因。 很多开源工具代码质量很好，但跑起来要改配置文件、装依赖、还要单独构建前端。我们做了几件事：Docker 一行命令起服务，GHCR 上有预编译镜像；前端用 Preact + htm 写，完全不需要 Node.js、不需要 npm、不需要任何构建步骤；默认搜索引擎用 DuckDuckGo，不需要额外 API key，装完只需要一个模型 key 就能跑。

模型和搜索引擎应该自由换。 模型层用 LiteLLM，OpenAI、Claude、DeepSeek、本地 Ollama 都测试过。搜索支持 DuckDuckGo、SerpAPI 和 MetaSo（MetaSo 对中文查询覆盖更好），多个引擎可以配 fallback 顺序。除了文本网页，还支持 PDF、图片、音频转录、YouTube 字幕------现实里的调研经常要读 PDF 报告，这个不做就是缺口。

为什么学"不是最新"的东西仍然值得

这是我想认真说的一点，因为这个问题确实存在。

全自主 agent------各种 computer use 应用------确实在快速发展。但在真实的企业场景里，"全自主"意味着不可控，不可控意味着不可解释，不可解释意味着出了问题没法追责。这在需要合规审计的行业（医疗、金融、法律）几乎是一票否决项。

Deep Research 这种半自主、步骤明确、每步可追溯的架构，在这些场景里反而是最实用的选择。不是因为技术不够先进，是因为它匹配了业务的真实约束。

更重要的是，底层原理是共通的。今天学规划者-执行者模式，明天换一个全自主 agent 框架，你会发现核心逻辑是同一套东西的变体。理解了这一层，跟上新技术的速度会快得多。

还有一点：有一个真实运行的开源项目，比任何 side project 都更有说服力。 如果你想把 agent 工程变成简历上真实的筹码，读懂这个项目的代码、提一个 PR、解决一个真实的 issue------这些比你写一百个 demo 都有用。真实的代码贡献在面试里是可以拿出来讲的东西，而且很少有人有。

最后

Deep Research 是我接触的第一个让我觉得"这个东西改变了我处理信息的方式"的 AI 应用形态。

这个系列接下来会继续写------RAG、embedding、token 的本质、agent 的评估......没有固定顺序，有想法了就写。如果某篇你觉得有帮助，或者有你想看的话题，欢迎来告诉我。

如果你对这个项目有想法------一个 bug、一个功能建议、或者你想动手改点什么------GitHub 上见。

👉 github.com/extracurricular-ai/open-deep-research-with-web-ui

我们想做的是一个真正帮到人的工具。如果你也认同这件事，欢迎你成为这个项目的一部分。

参考资料

Roucher, A., Villanova del Moral, A., Merve, Wolf, T., & Fourrier, C. (2025, February 4). Open-source DeepResearch -- Freeing our search agents . HuggingFace Blog. https://huggingface.co/blog/open-deep-research ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
LangChain. (2025). Open Deep Research . LangChain Blog. https://blog.langchain.com/open-deep-research/ ↩︎ ↩︎
Both, F. (2024). Why we no longer use LangChain for building our AI agents . Octomind Blog. https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents ↩︎