聊聊 Deep Research、思考模型和 Agentic 技术

大模型 · 5/14/2025, 10:25 AM

前言

2025 年，Deep Research 功能的爆发式流行成为大模型应用领域最引人注目的趋势之一，OpenAI 于 2 月推出的同名产品尤其受到关注。与以往主要提供简单答案的 AI 搜索引擎及类似应用不同，Deep Research 赋予了 AI 主动探索未知、独立执行复杂研究并产出深度报告的能力。这标志着搜索工具正经历一场范式革新。

面对这场革新，许多人心中可能有一些疑问：为何此前的大模型仅限于浅层搜索与简单回答，而不能进行深度研究？当前的大模型应用又经历了怎样的演进，才使其具备了这样的能力？

本文接下来会先回顾 Deep Research 的技术演进与产品探索历程，通过审视早期产品的局限与挑战，我们能更清晰地把握 OpenAI 是如何克服这些障碍，并实现当前在质量上的飞跃的。之后，本文将剖析 OpenAI 的 Deep Research 功能背后的两大关键支撑：思考模型和 Agentic 技术。

Deep Research

早期产品和项目

事实上，早在 2022 年 ChatGPT 刚刚问世时，市面上就已经陆续出现了一些具备初步 Deep Research 雏形的产品和项目。虽然这些早期尝试在功能和深度上与今天的 Deep Research 还有明显差距，但它们为后续技术的演进和用户认知的转变奠定了基础。接下来，我们将梳理这些先行者的技术路线和局限，看看 Deep Research 真正带来了哪些突破性变化。

  • Perplexity

    2022 年成立的平台，最初定位为「答案引擎（answer engine）」而非传统搜索引擎。早期的 Perplexity 主要专注于信息收集和整理，并不具备真正的研究能力。其核心流程是：用户输入问题后，系统会将其转化为搜索词，采用类似传统搜索引擎的方式一次性召回相关网页片段，然后用大模型对这些片段进行一次总结，并给出来源引用。

    也就是说，Perplexity 的典型工作方式是「一次搜索，一次总结」，整个过程是单轮、线性的。虽然这样能够产出可靠性较高的总结文本，但在面对需要深入分析和多层次推理的复杂问题时，结果往往流于表面，缺乏深度和系统性。这种方式和我们日常上网查资料的习惯并不相符——现实中，遇到复杂问题时，我们往往会多次搜索、不断调整关键词、查阅不同来源、反复比对和归纳，才能逐步深入理解问题本质。而 Perplexity 早期的线性流程，恰恰缺少了这种多轮探索和动态调整的能力，因此难以胜任真正的深度研究任务。

    Perplexity 于 2025 年 2 月时也推出了自己的 Deep Research 功能，大家可以去体验一下。

  • Co-STORM

    斯坦福大学开发的开源项目，前身是 2024 年 2 月发表的论文 Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models，后者提出了名为 STORM 的基于大模型的研究报告生成框架，Co-STORM 在其基础上做了许多改进。

    Co-STORM 是一个多智能体（Multi-Agent）协作系统。它的核心理念是：通过模拟多位专家之间的协作与对话，推动 AI 不仅仅停留在表层的信息检索和总结，而是能够主动发掘、分析和结构化新知识，从而实现真正意义上的 Deep Research。

    与传统的 AI 搜索工具不同，Co-STORM 并不是让用户与单一模型对话、逐步推动研究流程，而是让多个具备不同角色的 Agent 围绕研究主题自主展开对话和推理。用户可以像旁观专家讨论一样，看到这些 Agent 如何提出问题、检索信息、分析证据、相互辩论，并在需要时介入、引导或补充观点。这种机制不仅显著提升了研究的深度和广度，也更贴近真实的学术或专业研究场景。此外，这些 Agent 会主动利用搜索引擎等工具获取信息，能够帮助用户探索那些自己可能未曾意识到的「未知的未知（unknown unknowns）」。

    Co-STORM 中关键的 Agent 角色包括：

    • 领域专家 (Experts)：这些 Agent 从不同视角出发，针对研究主题进行提问、回答和深入讨论，推动知识的挖掘。
    • 协调者 (Moderator)：作为讨论的引导者，协调者不一定是特定领域的顶尖专家，但具备足够的知识广度来提出有价值的引导性问题，确保讨论的连贯性和全面性，并帮助讨论聚焦于关键信息点。

    Co-STORM 的简要工作流程如下：

    1. 用户设定研究主题。
    2. 多个 AI Agent（专家与协调者）围绕主题展开对话，主动提问、搜索网页、分析结果并讨论信息。
    3. 用户可旁观学习，也可随时插入问题或引导讨论。
    4. 系统实时将讨论内容整理为动态的思维导图，便于理解和回顾。
    5. 讨论结束后，系统可生成基于讨论和导图的结构化研究报告，包含引用来源。
    Co-STORM 的架构图，来自其论文

    Co-STORM 的架构图，来自其论文

这两类产品分别代表了 Deep Research 出现前 AI 搜索应用的两个阶段：一类是以 Perplexity 为代表，通过大模型对传统搜索引擎进行增强，实现「一次检索，一次总结」的线性流程；另一类则以 Co-STORM 为代表，引入 Multi-Agent 系统，让不同角色的 AI 协作，借助人为设计的框架推进研究进程。

然而，这些探索虽然推动了技术进步，但都未能真正解决深度研究的核心难题——让大模型能够自主、端到端地理解和执行 Deep Research 任务，具备自主制定研究策略和多步骤推理的能力。OpenAI 的 Deep Research 正是在这一点上实现了突破：它不再依赖预设的工作流，而是让 AI 真正「学会」如何闭环地完成复杂研究。

智能体应用的突破

OpenAI 的 Deep Research 之所以备受关注，除了其报告质量令人印象深刻，更核心的突破在于：它不是基于传统的工作流（Workflow）设计，而是以智能体（Agent）为核心，让 AI 能够自主规划和执行多步复杂任务。OpenAI 通过对 o3 模型的微调，让模型真正「学会」了如何利用多种工具进行长时间、深入的研究：

Deep Research 通过端到端强化学习在各个领域的复杂浏览和推理任务上进行训练。通过这种训练，它学会了规划和执行多步骤路径来找到所需数据，在必要时回溯并对实时信息做出反应。该模型还能够浏览用户上传的文件，使用 Python 工具绘制和迭代图表，在回答中嵌入生成的图表和网站图片，并引用其来源中的特定句子或段落。由于这种训练方式，它在多项专注于现实世界问题的公开评估中达到了新高度。

通过对 OpenAI 的 Deep Research 的体验，我发现它背后的 o3 模型展现出了下面这些令人惊叹的能力：

  • 规划能力

    模型能够主动规划和调整研究路径。它不再依赖于人为预设的流程，而是能够根据用户目标和实时获取的信息，自主制定研究计划、拆解子任务、动态调整步骤。整个研究过程像人类专家一样，先设定目标、再分解问题、再逐步推进，遇到新线索时还能灵活调整策略。

    例如，用户想要研究「2024 年全球电动汽车市场的主要趋势」。模型会先拆解为「市场规模变化」、「主要厂商动态」、「政策影响」等子问题，分别检索和分析，然后根据检索到的新数据动态调整研究重点，比如发现某地区政策变化显著后，自动深入分析该地区的影响。

  • 反思与自我修正

    模型具备强大的反思能力。在研究过程中，它会不断自我检查当前进展，发现信息不足、推理链断裂或假设有误时，能够主动回溯、补充证据、修正思路。这种「自我批判」机制让 Deep Research 能够持续优化研究结果，避免陷入思维定势或遗漏关键环节。

    例如，在分析某款网络游戏的年营收时，模型发现公开数据存在缺口或部分年份数据不全，便会主动回溯，查找更多权威渠道（如财报、行业报告等）补充信息，并在最终报告中修正和完善原有结论。

  • 边界处理与适应性

    传统 AI 搜索系统在遇到未预设场景或复杂边界问题时往往表现不佳，而 Deep Research 展现出极强的适应性。它能够识别出问题的模糊地带或未知领域，主动提出澄清问题、调整研究方向，甚至在缺乏现成答案时探索新的信息路径。这种能力让其在面对开放性、复杂性极高的现实任务时依然能够给出高质量的研究输出。

    比如，当 Deep Research 在某个网站上找不到所需数据时，它不会就此止步，而是会主动寻找其它方式，比如查找相关领域专家的预测、历史趋势数据，或者询问用户更具体的需求，最终通过多种方式补全信息，给出全面的推理和结论。

对于开发者而言，这种以智能体为核心、解决复杂问题的突破，其意义远远超越了 Deep Research 产品本身。它标志着一种新的大模型应用范式：AI 不再只是执行单一功能或遵循预设流程，而是能够理解用户目标，自主规划行动路径，并在执行过程中动态调整，在无需过多人类预设知识的前提下自行找出能够满足用户需求的解法。

OpenAI Deep Research 之所以能够实现这样的突破，离不开其背后的 o3 思考模型的支撑。这引出了我们接下来要讨论的话题：什么是思考模型？为什么说思考模型代表了 AI 发展的新方向？下一节我们将深入探讨这些问题。

思考模型

OpenAI 在 2024 年 9 月发布的 o1-preview 模型，可以看作是对大模型发展瓶颈的一种突破性回应。当时，随着公开可用的训练数据几乎被耗尽，Scaling Law 已经面临明显的增长天花板。与此同时，研究者们也逐渐意识到，仅靠大规模数据和参数扩展，模型在面对「未知问题」时的泛化能力依然有限，尤其是在解决数学题等超出训练分布的任务上，传统模型往往表现不佳。

Scaling Law 是指大语言模型性能随着计算资源、训练数据量和模型参数量增加而提升的规律。这一法则表明，只要持续增加这些要素，模型性能就会按照可预测的曲线提升。然而，当高质量训练数据逐渐耗尽，或计算资源达到物理极限时，单纯依靠扩展规模的方法就会遇到瓶颈，需要寻找新的突破方向。

为此，人们提出了一个新的发展方向：除了在训练阶段让模型学习和模仿人类经验外，还可以在推理阶段赋予模型「思考」的能力，使其能够解决超出已有人类经验范围的问题。这就是「思考模型」的由来，它在 Agentic 技术发展中扮演着核心角色，其能力直接决定了 Agentic 技术的性能上限。我们会在之后一节继续讨论 Agentic 技术。

思考模型是什么

思考模型（Reasoning Model）是一类专门优化用于执行复杂推理任务的大语言模型。与非思考模型不同，思考模型具备更强的逻辑分析、多步骤思考和问题解决能力。它的核心特点是能够自发地执行思维链（Chain-of-Thought）推理，即通过清晰的中间推理步骤来解决问题，而不是直接给出答案。

假设我们向模型提问「一个水池有两个进水管，单独使用第一个管道需要 5 小时装满水池，单独使用第二个管道需要 3 小时装满水池。如果同时使用两个管道，需要多长时间装满水池？」

传统的非思考模型的回答可能是这样的：

同时使用两个管道需要约 1.875 小时（或 1 小时 52 分 30 秒）装满水池。

而思考模型会先进行思考，再去给出最终的答案：

让我一步步思考这个问题：

  1. 第一个管道每小时填充水池的 1/5，也就是 20%。
  2. 第二个管道每小时填充水池的 1/3，也就是约 33.3%。
  3. 当两个管道同时工作时，每小时填充率为 1/5 + 1/3 = (3+5)/(5×3) = 8/15 ≈ 53.3%。
  4. 要填满整个水池，需要的时间 = 1 ÷ (8/15) = 15/8 = 1.875 小时。
  5. 转换为时分秒格式：1 小时 52 分 30 秒。

因此，同时使用两个管道需要 1.875 小时（或 1 小时 52 分 30 秒）装满水池。

在这个例子中，两个模型都答对了问题，但在实际的一些复杂问题特别是困难的数学问题中，思考模型往往有着远远优于非思考模型的表现。我们会在后文进一步介绍两种模型的区别。

下面是目前常见的一些思考模型：

  • OpenAI o3 和 o4-mini
  • Gemini 2.5 Pro Preview 和 2.5 Flash Preview
  • DeepSeek R1
  • Claude 3.7 Sonnet
  • Qwen 3

下面是目前常见的一些非思考模型（Non-reasoning Model）：

  • OpenAI GPT-4.1、GPT-4.5
  • Gemini 2.5 Pro Preview 和 Gemini 2.5 Flash Preview
  • DeepSeek V3 0324
  • Claude 3.7 Sonnet
  • Qwen 3

你会发现部分模型既是思考模型，也是非思考模型。这是因为它们往往支持开发者手动禁用思考过程。

与非思考模型的对比

在实际应用中，思考模型在诸如数学推理和编程等复杂任务上展现出了远超非思考模型的能力。例如：

  • 数学推理：在 AIME 2024 数学竞赛测试中，DeepSeek R1 的准确率高达 79.8%，而 Claude 3.5 Sonnet 仅为 16.0%；在 MATH-500 测试中，DeepSeek R1 达到 97.3%，而 GPT-4o 仅为 74.6%。
  • 编程能力：在 LiveCodeBench 测试中，DeepSeek R1 的 pass@1 得分为 65.9%，而 Claude 3.5 Sonnet 仅为 38.9%；在 Codeforces 评分中，DeepSeek R1 获得 2029 分，而 Claude 3.5 Sonnet 仅为 717 分。

这些性能上的巨大差异，主要得益于思考模型具备「思维链」机制。可以把思考模型比作一个善于解题的学生，遇到复杂问题时，会把大问题拆解成若干小问题，每一步都清晰地写在草稿纸上，推理过程一环扣一环。这样不仅能帮助模型及时发现和修正中间的错误，也让它能够像人类一样，循序渐进地解决复杂任务。

进一步来说，这种逐步推理的方式，相当于为模型配备了一本「工作笔记」。在面对需要多步推理或长链条任务时，模型能够持续记录和追踪中间结果，减少信息遗漏。如果遇到困难，还可以尝试不同的推理路径，甚至回头检查和修正，从而更好地整合和利用已有知识，提升解决复杂问题的能力。

要更好地理解思考模型和非思考模型之间的根本差异，可以从它们的训练方式入手：

  • 监督微调（Supervised Fine-Tuning，简称 SFT）

    非思考模型主要依赖 SFT 训练，基于大量的「问题-答案对」。这里的「问题-答案对」指的是：人类标注者给模型出一道题（比如一道数学题或一个问答），并提供一个标准答案，模型通过大量这样的例子来学习如何模仿人类的解题方式。

    假设我们要求模型生成一个关于「猫如何拿到高处架子上的鱼」的简短故事：一个主要通过 SFT 训练的模型，可能会生成猫尝试跳跃、喵喵叫寻求帮助，或者推倒旁边某个东西来够到鱼的故事。这些都是人类标注者在提供「问题-答案对」时，基于对猫常见行为的观察或简单直接的解决思路。SFT 训练让模型在遇到常见问题时能很快给出答案，但如果碰到没见过的新问题，模型往往只能「套用模板」或者「背答案」，缺乏灵活应变和创新的能力。换句话说，SFT 难以让模型超出人类的思维方式。

  • 强化学习（Reinforcement Learning，简称 RL）

    思考模型则在 SFT 的基础上进一步采用大量的 RL 训练，基于大量的「问题-奖励函数对」。所谓「奖励函数」，可以理解为：模型尝试不同的解题方法，每当它找到一个更好的答案或更合理的推理过程时，就会获得「奖励分数」；反之，如果答案不理想，则得不到奖励。

    还是以「猫如何拿到高处架子上的鱼」为例，经过 RL 训练的思考模型，可能会构思出一个更曲折、更有创造力的方案：猫观察到可以通过一系列连锁反应（比如，推下一个小球，小球滚动击中杠杆，杠杆撬动木板，最终使鱼缸滑下来）来达成目标。这种复杂的、非显而易见的策略，人类标注者很难预先想到并包含在训练数据中，但模型却可能在以「拿到鱼」为目标的强化学习过程中自主地「发现」它。

    RL 的引入让大模型不仅能学会标准答案，更能在面对复杂或陌生问题时，展现出超越人类经验的创造力和解决问题的能力。它促使模型主动探索多种解题路径，尝试创新方法，从而在未知领域找到更优的答案。

正因为在训练方式上的显著差异，思考模型和非思考模型在提示词工程（Prompt Engineering）上存在许多明显的差异，一些过去在非思考模型上常用的提示词技巧可能在思考模型上不起作用，甚至伤害到模型的正常发挥。关于这个话题我在《提示词工程指北：从第一性原理出发》一文中有详细的讨论。也可以参见 OpenAI 的相关指南和 Anthropic 的 Extended thinking tips。

思考模型与系统二

诺贝尔经济学奖得主丹尼尔·卡尼曼在《思考，快与慢》中提出了著名的双系统理论，将人类的思维分为两种系统：系统一（System 1）和系统二（System 2）。系统一代表快速、自动、情感化的直觉思考，能够在日常生活中迅速做出反应；而系统二则是慢速、有意识、需要付出努力的逻辑推理，主要用于处理复杂、不熟悉或高风险的问题。

这两个系统并不是彼此独立、互不干涉的，而是会根据情境动态切换和协作。人在面对熟悉、简单、重复性的任务时，往往会自动启用系统一，凭借直觉和经验迅速做出判断；而当遇到陌生、复杂或者需要深思熟虑的情境时，比如解一道难题、做重要决策、发现直觉可能出错时，系统二就会被激活，投入更多的注意力和认知资源进行分析和推理。实际上，很多时候系统一会先给出一个初步答案，只有当我们意识到需要更谨慎时，才会让系统二介入进行校正和深入思考。

在人工智能领域，这一理论也被广泛借鉴。非思考模型可以类比为系统一，擅长快速给出答案，但在面对复杂任务时往往依赖模板和直觉；而思考模型则更像系统二，能够模拟人类的深度推理过程，通过逐步分析和逻辑推导来解决难题。因此，思考模型的出现可以被视为 AI 对人类系统二的思维方式的探索和实现。

目前，思考模型和非思考模型之间的关系是相当有趣的。它们并非简单的替代或竞争关系，而是在不断融合、相互借鉴、共同进化。接下来，我们将具体探讨两者之间的互动与边界如何被打破，以及业界在提升模型能力和效率方面做出的多种探索。

  • 思考模型蒸馏

    提升代表系统一的非思考模型能力的常见方法，是通过从思考模型中蒸馏知识。具体做法是，先让强大的思考模型生成详细的推理过程，再用这些过程去训练体量更小的模型，使其能够模仿思考模型的推理结果。这样得到的「混合模型」虽然不具备完整的思维链，但在准确率上有明显提升，同时还能保持较快的响应速度和较低的资源消耗。

    以 DeepSeek 团队为例，他们在 2025 年初发布了多款基于 Qwen 和 Llama 架构的蒸馏模型。这些模型在继承了原模型部分的推理能力的同时，大幅降低了硬件资源需求。主要包括：

    • DeepSeek-R1-Distill-Qwen-1.5B：基于 Qwen2.5-Math-1.5B
    • DeepSeek-R1-Distill-Qwen-7B：基于 Qwen2.5-Math-7B
    • DeepSeek-R1-Distill-Qwen-14B：基于 Qwen2.5-14B
    • DeepSeek-R1-Distill-Qwen-32B：基于 Qwen2.5-32B
    • DeepSeek-R1-Distill-Llama-8B：基于 Llama-3.1-8B
    • DeepSeek-R1-Distill-Llama-70B：基于 Llama-3.3-70B-Instruct

    这些蒸馏模型在数学和编程等评测集上表现明显优于原始模型，准确率和推理能力都有显著提升。同时，业内有许多人认为，当下许多最新的非思考模型在训练时也引入了自家思考模型的蒸馏技术，DeepSeek V3 0324 就是一个例子。

  • 思考模型可以调整「思考时间」：

    Anthropic 在 2025 年初推出的 Claude 3.7 Sonnet，首次在模型层面引入了「思考」与「不思考」两种模式的切换能力，这种模式被官方称为 Extended Thinking（扩展思考）。这并非单一功能，而是模型本身支持用户根据实际需求，选择让模型进入深度推理（思考模式）或直接给出答案（不思考模式）。

    在思考模式的基础上，用户还可以通过设置「思考预算」等参数，灵活控制模型在生成答案前允许进行多少 token 的内部推理，从而实现两种模式的自由切换。通过调整这个参数，用户能够在答案的质量和响应速度之间灵活权衡，手动选择更适合当前场景的平衡点。

    与之类似，阿里巴巴在 2025 年四月底发布的 Qwen3 模型则采用了更为直接的方式：用户可以通过在提示词中添加「/think」或「/no_think」命令，动态切换模型的思考模式。根据 Qwen 官方博客，Qwen3 默认开启思考模式，此时模型会先生成详细的思考内容，再给出最终答案；而使用「/no_think」命令则可以跳过推理过程，直接输出结果，从而显著提升响应速度。

    此外，AaronFeng753 在 Better-Qwen3 项目中设计了一个前置的大模型调用，用于自动判断用户请求是否值得「思考」，即是否需要为当前请求添加 /think 指令，实现了更智能的思考模式切换。

  • 让模型思考自己要不要思考

    更进一步，业界正在探索让模型能够自主、端到端地判断何时需要「思考」。未来的模型或许能够根据具体任务或每个输入，自动决定是否进入深度推理模式，实现「思考自己是否需要思考」。这种能力将使模型在面对不同复杂度的问题时，灵活切换推理深度，更加贴近人类的双系统思维方式。

    这些探索表明，AI 研究正逐步模拟人类在日常生活中灵活切换直觉与逻辑分析的能力：熟悉、简单的问题用直觉快速应对，复杂、陌生的情境则启动更慢、更深度的推理。随着相关技术的不断进步，我们有望见到更加高效、智能、能够根据任务自动调整思考方式的 AI 系统。

总的来看，思考模型与非思考模型的界限正在逐渐模糊，二者不再是泾渭分明、各自为政。越来越多的技术创新正在两者之间搭建桥梁，推动模型融合高效响应与深度推理的优势。这样的发展趋势不仅加速了模型本身的演进，也为下文将要介绍的 Agentic 技术奠定了坚实的基础。

Agentic 技术

除了前面介绍的 OpenAI Deep Research，我们在日常生活中可能也会注意到越来越多的应用或产品宣传自己是「基于 Agent」或者「Agentic」的，甚至有些功能页面直接标榜「智能体驱动」。那么，这里的「Agent」或「Agentic」究竟指的是什么？它和我们熟悉的传统大模型应用、自动化工具、工作流系统又有什么不同呢？

接下来，我们将结合业界的主流观点和我所在的团队最新的技术实践，深入探讨 Agentic 技术的定义、核心特征以及它与传统工作流系统的区别，并分析它为何会成为 2025 年大模型应用领域的一个重要趋势。

Agentic 的定义

事实上，「Agent」（或「Agentic」）的具体含义在今天是存在不少争议的，有人说 Agent 就是给大模型配备一些工具，也有人说 Agent 是像 Coze 和 Dify 那样用各种节点串联大模型调用构成的工作流。本文会使用并讨论 Anthropic 在其 Building effective agents 一文中给出的定义。

Anthropic 将这些不同类型的系统统称为 Agentic Systems，并对其核心架构作了重要区分，具体分为两类：

  • 工作流（workflow）：这类系统通过预定义的代码路径来编排大语言模型和工具。其核心特点是任务流程由开发者预先定义和编排，因此更具可预测性和一致性。
  • 智能体（agent）：相对而言，智能体系统则赋予大语言模型更大的自主权，使其能够动态地指导自身的流程和工具使用。模型在智能体系统下对如何完成任务拥有主导控制权，能够根据任务的实时进展和环境反馈，灵活调整策略并自主决策。

简而言之，如果说工作流是严格按照预设脚本执行的程序，那么智能体则更像是一位被赋予了目标和工具的自主行动者，它会自行规划路径并应对途中的各种变化。

智能体在执行任务时，能够从其所处的环境中获取「真实情况（ground truth）」。这通常通过工具调用结果（如搜索工具或代码工具返回的结果等）来实现。通过感知环境的反馈，智能体能够评估自身进展，判断当前策略对于完成任务是否有效，并在必要时进行调整，然后进行后续的工具调用，如下面的架构图所示。

智能体系统的架构图，来自 Anthropic 的文章

智能体系统的架构图，来自 Anthropic 的文章

下面的时序图展示了智能体与人、交互界面及外部环境协作解决复杂问题的例子。

  1. 用户先通过交互界面提出任务。然后，大模型与用户进入一个任务澄清与优化的循环：大模型向用户追问以明确需求，用户则相应地细化任务。一旦任务明确，交互界面会将相关上下文信息发送给大模型。
  2. 接着，大模型开始与外部环境交互，执行如「搜索文件」（环境返回文件路径）、「编写代码」及「运行测试」（环境返回测试结果）等一系列工具调用，其中编码与测试的过程会持续直至大模型认为所有测试通过。
  3. 最终，当大模型根据环境反馈判断任务已完成时，它会通过交互界面向用户展示结果并结束任务。
智能体与环境交互的时序图，来自 Anthropic 的文章

智能体与环境交互的时序图，来自 Anthropic 的文章

工作流和智能体

本节内容总结自我之前写的《DeepSearch 技术沙龙参会笔记与个人思考》。

自 OpenAI 推出 Deep Research 功能以来，开源社区如雨后春笋般出现了大量的开源项目，但是这些项目绝大多数都是以上述的工作流的方式实现的。以 Jina AI 的 Deep Research 为例，它使用了下图所示的工作流去串联起不同的大模型调用节点。

Jina AI 的 Deep Research 设计，来自其官网文章

Jina AI 的 Deep Research 设计，来自其官网文章

Jina AI 的 Deep Research 的工作流程大致如下：

  1. 生成大纲 (Generate TOC)：系统首先根据用户输入的研究问题，利用大语言模型生成一份结构化的研究报告大纲。

  2. 分项深度搜索 (For Each Section in TOC)：针对大纲中的每个章节或子主题，系统会执行「深度搜索循环」（DeepSearch Loop），由下述环节构成：

    1. 查询生成与执行 (Search)：通过语义扩展将当前研究点转化为多个搜索查询，并进行去重，然后执行网络搜索获取相关页面信息。
    2. 内容提取与处理 (Read)：访问选定的网页链接，提取主要内容并转换为适合大模型处理的文本格式（如 Markdown）。
    3. 信息分析与问题发掘 (Reason)：大语言模型分析收集到的材料，识别存在的「知识空白问题」（Gap Questions），这些新问题会被加入处理队列。

  3. 汇总与生成 (Consolidate Sections)：完成大纲中所有项目的深度搜索后，系统汇总所有信息、分析结果和洞见，生成最终的研究报告。

相比之下，OpenAI 的 Deep Research 采用了智能体方案。虽然具体实现未公开，但我认为至少在「深度搜索循环」环节，它完全依赖大模型自主探索：模型会根据任务自动决定搜索词并调用搜索工具，然后判断是否需要使用浏览工具获取网页内容，直到确认收集到的信息充足并返回报告。这似乎预示着大模型应用正走向以智能体为核心的新范式。

智能体和工作流两种范式，体现了模型研究者和应用开发者的不同思路。前者通过训练模型让其学会复杂任务，后者则通过拆解任务、设计流程和多智能体系统等工程手段，通常无需微调模型。令我感到迷茫的是：Deep Research 反映了当今的大模型仍处于早期阶段，模型研究者和应用开发者的分工还不清晰，常常在解决类似问题。由于模型研究者能够决定模型的能力边界，开发者的各种工程创新（尤其是工作流）很容易被新模型淘汰，我将这种情况称为「角色冲突」。

早在去年，我就开始使用 Claude 3.5 Sonnet 模型开发基于智能体的 Deep Research 应用：给模型配备搜索和浏览工具，让其自主决策完成信息获取的任务。但当时出现了一个相当棘手的问题：模型总是觉得自己第一次搜索得到的信息已经足以输出报告，结果这些报告缺乏细节、遗漏要点、相当平庸。 我不得不转向了工作流方案，向实现中融入预设的人类知识：先让模型生成研究计划，再手动用代码解析为步骤列表，逐项调用大模型去搜索和总结，整体上类似 Jina AI 的 Deep Research。

开发基于工作流的实现花了我不少时间。但当支持思考模式的 Claude 3.7 Sonnet 发布后，我惊讶地发现：只需把原本基于智能体的实现直接切换到新模型，效果就能媲美甚至超越工作流版本。 这让我深刻体会到应用开发者的局限，也为 Jina AI 这类工作流方案感到惋惜——模型开发者通过工程积累提升性能，但模型研究者总能用一次范式变革实现超越。这简直就是 Richard Sutton 的 The Bitter Lesson（苦涩的教训）的现实写照。

The Bitter Lesson 大致讲了这样的事情：在 AI 发展历史上，依靠规模化计算能力的通用方法最终总是战胜了基于人类专业知识和精心设计的特定方法。这篇文章指出，尽管研究者们不断尝试将人类领域知识注入 AI 系统，但随着时间推移，利用更多计算资源和更简单、更通用算法的方法总能取得更好的长期成果。专家级的领域知识工程虽然可以带来短期优势，但最终常被可扩展的计算方法所超越。

拥抱智能体

我认为，作为大模型应用开发者，我们应理性看待苦涩的教训：这本是写给研究者的警示。面对当前模型在某些场景下能力尚未达到预期，我们不应因此停滞不前、被动等待，而应积极发挥自身作用，做力所能及的改进。我们需要在大模型快速发展的阶段，寻求开发者与研究者之间的平衡，缓解角色冲突。以我所在项目为例，我的选择是：充分发挥模型潜力，优先提升用户体验。

所谓「充分发挥模型潜力」，指的是：倾向于以智能体为中心构建应用。 这里并不是说所有的应用都应该放弃工作流而转向智能体，工作流和智能体并非二元对立的关系，而是一个复杂系统在架构上展现出的倾向。

正如 Langchain 在 How to think about agent frameworks 一文中所说：「我们在生产环境中看到的几乎所有 agentic 系统其实都是工作流和智能体两者的结合体……与其非黑即白地判断某个系统是不是 agent，我认为更有意义的是把系统看作在「智能体化」程度上有所不同。与名词 agent 不同，形容词 agentic 让我们能够思考这些系统，并将它们都纳入这个不断发展的浪潮之中。」

Langchain 还在在这篇文章中表示：工作流的下限和上限都比端到端来得更高，而且能提供更强的确定性，而端到端则能带来更好的自主性（或者说面对大量边界情况时的灵活性），如下图所示：

image

尽管工作流能够凭借人类知识的介入，以及大模型基础能力的不断提升，在复杂任务上获得相比端到端更好的上限（深度搜索就是这样的例子），但它需要我们投入大量的精力开发。如今，思考模型已成为研究热点，未来一段时间大模型的自主能力还会持续提升，逐步取代许多原本依赖工作流的场景。对于一些基于工作流的应用来说，由于它们的流程节点主要依赖大模型在特定子任务上的表现，整体效果往往受限于开发者在设计流程时所引入的人类知识，这也使得它们难以像基于智能体的应用那样充分利用模型自主能力提升所带来的红利。

所谓「优先提升用户体验」，就是大模型应用开发者应将主要精力投入到优化用户体验上。当前大模型研究的进步速度远超应用层面的创新，而开发者们却还在争论「聊天对话式 UI 是否适合现阶段的大模型应用」。从去年 8 月 Anthropic 推出的 Artifacts 到今年 OpenAI 的 Deep Research，我注意到，大家大多在努力还原和复刻这些功能本身，却很少真正从用户视角出发，思考并提升实际的使用体验。

顺应模型的发展趋势，让我们更倾向于以智能体（agent）为核心来构建应用，这不仅节省了大量设计和维护工作流的精力，也让我们能够将更多关注点放在如何优化用户体验上。当应用性能相近时，真正能打动用户、留住用户的，往往是那些在细节和体验上做得更好的产品。我甚至认为，随着未来模型能力的持续提升，「工作流 vs 端到端」的争论会逐渐变得无关紧要，因为底层技术架构带来的性能差异会越来越小，届时应用之间的核心竞争力将更多体现在对不同用户群体的深度理解和差异化的体验设计上。

在梳理了智能体范式的演进与开发者角色的转变之后，我们可以看到，智能体的能力边界很大程度上受限于其可访问的外部世界。正所谓「巧妇难为无米之炊」，为了让智能体真正成为「行动者」而不仅仅是「对话者」，应用层还需要有机制让模型能够安全、标准化地访问各种数据源和工具，进而帮助用户完成复杂的任务。为此，业界正在推动一项新的开放协议——Model Context Protocol（MCP），它为智能体扩展能力、连接外部世界提供了统一的接口。接下来，我们就来了解 MCP 这一应用层的重要进展，以及它如何进一步拓展智能体的能力边界。

Model Context Protocol

根据规范文档，Model Context Protocol（MCP）是一个开放协议，旨在实现大模型应用与外部数据源及工具的无缝集成。无论开发者是在构建 AI 驱动的集成开发环境（IDE）、增强聊天界面，还是开发自定义的 AI 工作流，MCP 都为 LLM 提供了一种标准化的方式，便于其获取所需的上下文信息。可以把 MCP 想象成 AI 应用领域的 USB-C 接口。正如 USB-C 为各种设备与外部配件、外设之间的连接提供了统一标准，MCP 也为 AI 模型与不同数据源和工具之间的连接提供了标准化的方式。

MCP 的整体架构示意图，来自其官方文档

MCP 的整体架构示意图，来自其官方文档

MCP 协议中有两类核心角色：MCP 主机（MCP Hosts）和 MCP 服务器（MCP Servers）。MCP 主机通常指大模型应用，它们通过协议调用 MCP 服务器所提供的各类能力。对于主机而言，MCP 服务器主要提供三类内容：

  • 资源（Resources）：可供主机读取的数据资源，比如飞书文档、本机的文件等
  • 提示词（Prompts）：预设的提示词模板，辅助用户完成特定任务
  • 工具（Tools）：可被大模型直接调用的工具，比如查询天气等

在我看来，MCP 并没有引入任何新的东西，而是将一些过去就存在于大模型应用的一些最佳实践给规范化了。接下来，我会介绍我对 MCP 的两种解读方式：

  • MCP 是一种「分工」

    MCP 明确划分了大模型应用开发者与服务提供者的职责边界。以 Tavily Search 为例，过去这类搜索 API 服务商仅提供底层搜索接口，开发者不仅要负责构造具体的搜索词和参数，还要处理结果的序列化，并在提示词中详细教会大模型如何正确调用该工具。例如：

    // 来自 Tavily Search 官方文档
const options = {
  method: 'POST',
  headers: { Authorization: 'Bearer <token>', 'Content-Type': 'application/json' },
  // 需在提示词中向大模型介绍这些参数
  body: JSON.stringify({
    query: 'who is Leo Messi?',
    topic: 'general',
    search_depth: 'basic',
    chunks_per_source: 3,
    max_results: 1,
    time_range: null,
    days: 7,
    include_answer: true,
    include_raw_content: false,
    include_images: false,
    include_image_descriptions: false,
    include_domains: [],
    exclude_domains: [],
  })
};
 
fetch('https://api.tavily.com/search', options)
  .then(response => response.json())
  .then(response => console.log(response))
  .catch(err => console.error(err));

    这种模式下，开发者往往需要深入理解服务方的实现细节，分工并不清晰。而有了 MCP，Tavily Search 官方推出的 MCP 服务器已经将工具的提示词、API 调用方式和结果序列化等全部标准化封装。开发者只需安装相应软件包，将大模型接入 MCP 服务器即可，无需再关心底层细节，极大提升了开发效率和可维护性。

    因此，作为一种对「分工」的共识，MCP 在大模型应用和下游服务之间扮演了桥梁的角色，正如下面的图示。

    来自 MCP 官方文档的图示

    来自 MCP 官方文档的图示

  • MCP 是一种「生态」

    在过去，许多实用的提示词模板和工具往往以非结构化的方式在博客、社交媒体等渠道中流传，开发者通常通过复制粘贴的方式获取和使用。这不仅导致了维护上的困难，也难以实现版本管理和高效复用。

    MCP 的出现正在改变这一局面。通过将各类能力封装为标准化的 MCP 服务器，它催生了一个日益繁荣的组件生态。例如，根据 awesome-mcp-servers 的收集，现在有专门的 MCP 服务器用于：

    • 访问本地文件系统与环境：让 AI 安全地与用户的本地文件交互
    • 操作数据库：如直接查询 SQLite 等数据库，无需为每个应用编写特定的集成代码
    • 集成开发者工具：允许 AI 调用 Git 命令来管理代码仓库
    • 提供基础工具：像 whattimeisit-mcp 这样简单的服务器，能让 AI 标准化地获取当前时间
    • 聚合多种服务：像 MetaMCP 这样的聚合器，能将多个不同的 MCP 服务器统一管理和调用，方便集成

    这种标准化的封装意味着，无论是复杂的文件操作、数据库交互，还是简单的信息查询，都可以通过统一的 MCP 接口接入大模型应用。开发者不再需要为每种工具或数据源编写定制化的集成逻辑和提示词，只需引入相应的 MCP 服务器软件包即可。

    同时，各种编程语言（如 Java 的 spring-ai-mcp、C# 的 ModelContextProtocol.NET、Python 的 langchain-mcp）的 SDK 和框架也相继涌现，进一步降低了构建和使用 MCP 服务器的门槛。这不仅极大地提升了开发效率和应用的可维护性，也促进了工具和资源的共享与复用，推动了整个 AI 应用生态的可持续发展。

  • MCP 是一种「趋势」

    我认为，MCP 的出现与前文所讨论的「以智能体为核心」的大模型应用理念是高度契合、互为补充的。随着思考模型能力的持续提升，大模型本身的自主性和智能化水平不断增强，它们能够以更灵活、更高效，甚至超出人类预期的方式自主组合和调用 MCP 提供的各类工具与资源。在这一过程中，模型不仅能够根据任务需求动态编排工具调用链，还能在执行过程中持续自我反思和优化，最终为用户交付更高质量、更贴合需求的结果。正如前文所强调，这种能力的提升更多依赖于模型自身的演化，而非开发者对人类知识的繁琐注入。

    基于此，我们可以预见未来大模型应用的演进方向：开发者的主要精力将从繁重的系统提示词工程，逐步转向对 MCP 工具和数据源的有机整合与优化。大模型则以先进的思考模型为核心，围绕 MCP 协议所聚合的一方和三方能力，面向特定用户群体提供定制化服务。这样一来，开发者与模型的分工更加清晰，应用开发的门槛和复杂度大幅降低，同时也为 AI 应用生态的繁荣和可持续发展奠定了坚实基础。

Agentic 技术的现状

在本文结尾，让我们简要回顾和分析一下当前 Agentic 技术的发展现状。

  • 推理模型不够强大

    尽管AI在许多领域取得了显著进展，但当前的推理模型在面对真正需要深度抽象和泛化能力的复杂任务时，其能力仍然显得不足。

    ARC-AGI 由 François Chollet 于 2019 年提出，是一个专为考察 AI 抽象推理能力而设计的基准测试。它包含一系列对人类来说通常很简单、但对当前最先进 AI 系统却极具挑战性的视觉推理任务，核心在于测试 AI 是否能理解抽象概念、学习新规则并灵活应用于未知情境，这正是迈向通用人工智能（AGI）的关键。

    正如 ARC Prize 官网所言，ARC-AGI 是「唯一未被攻克的基准测试，对人类来说很容易，但对 AI 来说却很难」。尽管 AI 技术飞速发展，非思考模型在 ARC-AGI 上的得分几乎为零，即便是当下最为强大的推理模型，得分也仅为个位数百分比。例如在最新的 ARC-AGI-2 评测集上，当下最为强大的推理模型 OpenAI 的 o3 模型得分只有 4% 左右，DeepSeek R1 更低，仅为 0.3%，而人类平均水平为 60%。

    ARC-AGI-2 的结果凸显了当前 AI 推理模型的几个核心短板：仅靠扩大模型规模远远不够，模型在符号理解、规则组合和灵活应变等方面依然存在明显不足。

  • 上下文的组织和呈现仍较困难

    目前，多数大模型的上下文窗口上限在 100～200K tokens 之间，极少数甚至能达到 100M，但即便如此，实际应用中仍常常捉襟见肘。以 Deep Research 应用为例，开发者需要将模型要浏览的网页内容写入上下文，而许多网页本身就非常冗长，比如 DeepSeek 的英文维基百科页面就足足有约 12K token 的文字内容。对于需要长时间、多网页探索的调研任务，模型很快就会因为需要处理过多内容而超出上下文容量限制。

    面对这种情况，开发者不得不对上下文内容进行裁剪和组织，比如截取不重要的内容、总结摘要等。但这些处理方式对不同模型的影响往往既细微又难以预测。此外，许多大模型应用还会在用户界面上展示一些常驻的信息（例如任务的执行状况），如何让模型能够感知和利用这些信息也是一个棘手的问题。

  • 大模型应用的交互设计仍显初级

    当前，大模型应用在人机交互设计方面普遍还比较原始，尤其是在 Deep Research 这类场景下表现得尤为明显。大多数应用采用的都是「用户一次性输入需求，大模型全程自动处理，用户等待最终结果」的单向流程。用户在发出请求后，往往只能被动等待，等到模型「埋头苦干」结束后再回来查看报告。这种设计虽然简单，但存在明显的局限性。

    一方面，Deep Research 往往被当作一个独立的功能开关，用户需要自己判断需求是否适合用这个模式。这对许多对大模型应用不熟悉的用户来说是一个负担，有时候用户自己也无法在主观上判断自己的需求是否需要深入研究。

    另一方面，Deep Research 的这种「一锤子买卖」式的交互缺乏灵活性和普适性。。而实际上，许多深度调研的需求与用户的个人偏好、关注点密切相关。如果整个过程完全交由大模型自主完成，用户无法在中途介入或调整方向，最终产出的报告很可能与用户的真实需求存在偏差，甚至完全不符合预期，导致用户白白浪费了等待时间。

    以 OpenAI Deep Research 为例，我在实际使用过程中最直观的感受就是：整个研究过程对用户来说是「黑箱」的。我无法在中途看到任何进展，也无法及时发现模型是否理解了我的意图，或者是否遗漏了重要的调研对象。等到十几分钟后拿到最终报告，才发现模型可能早早就走偏了方向。这种体验令人沮丧，但目前主流的 Deep Research 应用似乎都默认采用了这种「一遍过」的交互范式，甚至鼓励用户在发出请求后离开，等研究完成再回来查看结果。

    这种设计思路忽略了人机协作的巨大潜力。实际上，深度调研本应是一个动态、迭代、可交互的过程。用户在调研过程中往往会有新的想法、补充或修正，理想的交互方式应当允许用户随时介入、调整方向、查看阶段性进展，甚至与大模型进行实时对话和反馈。只有这样，才能真正发挥大模型与人的协同优势，提升调研的效率和结果的相关性。

    其实，大模型应用的演进，不只是让模型独自奔跑，更像是一场人与智能的双人舞。我们需要让用户能够以自然、轻盈的步伐参与其中，在舞步的交错中展现自己的独特风采。毕竟，大模型应用的终极意义，是让技术与人的灵感在共舞中彼此成就，携手探索更广阔的可能。

    因此，我认为未来的大模型应用，尤其是在复杂任务和深度研究场景下，亟需在交互设计上进行创新。如何让用户能够更好地参与到模型的推理和决策过程中，如何设计出支持多轮互动、实时反馈和动态调整的交互机制，将是推动大模型应用走向成熟的关键一步。

结语

回顾 Deep Research、思考模型与 Agentic 技术的演进，我们可以看到，大模型应用正处于一场深刻的范式转变之中。大模型不再只是被动的工具，而是逐步成长为能够自主规划、动态决策、与人协作的智能体。思考模型的崛起，让模型具备了更强的推理与创新能力；MCP 等开放协议的出现，则为智能体连接外部世界、实现能力扩展提供了坚实的基础。

然而，技术的进步也带来了新的挑战。推理模型的能力边界、上下文的组织与呈现、以及人机交互的设计，依然是制约 Agentic 技术落地的关键因素。开发者与模型研究者之间的角色分工、工作流与智能体范式的平衡，也需要在实践中不断探索和调整。

面对这些挑战，我们既要拥抱模型能力的快速提升，充分发挥智能体的自主性，也要关注用户体验的优化，让人机协作真正释放出更大的价值。未来，随着模型能力的持续进化和生态的日益繁荣，大模型应用的核心竞争力将越来越多地体现在对用户需求的深度理解和体验创新上。

Deep Research 只是一个起点。真正的智能体时代，属于那些能够将技术与人性、创新与体验深度融合的探索者。