8分钟了解Deep Research与上下文工程

显示全部楼层

一句话总结全文：介绍了Deep Research的概念，Spring Ai Alibaba的Deep Research实现以及为什么需要Mem0这种记忆管理框架增强其性能。

本文主要以Spring Ai Alibaba的Deep Research项目展开。

开源地址：

MCP0llxxx2io">
https://github.com/alibaba/spring-ai-alibaba/tree/main/spring-ai-alibaba-deepresearch
Spring Ai Alibaba

关于Mem0和Graph RAG请参考我的上一篇文章：

5分钟了解GraphRAG和Mem0

下期预告：Java如何使用Mem0增强你的智能体或者Mcp相关的东西

什么是Deep Research

Deep Research是由OpenAI于2025年推出的AI驱动的研究型智能体系统，旨在通过多步骤推理、自动化工作流和跨领域知识整合，高效生成专业级研究报告。

一、核心定义与功能

研究自动化

系统通过AI技术自动化传统研究中耗时的手动流程，包括文献检索、假设生成、数据分析、结论综合等环节，在5-30分钟内生成结构化的研究报告。
区别于通用AI助手（如ChatGPT），它具备端到端的研究编排能力，能动态规划任务、交叉验证信息并调整研究方向。

多模态处理能力

支持文本、图像、PDF等多格式数据解析，整合互联网实时信息与专业数据库资源（如ArXiv、PubMed）。

二、技术架构

基础模型与推理引擎

基于OpenAIo3强化学习模型优化，结合思维链（Chain-of-Thought）和思维树（Tree-of-Thought）技术，实现复杂问题的多步骤推理。

包含四大协同模块：

模块	功能
信息检索模块	全网实时数据抓取与筛选
多模态分析模块	处理文本、图像、PDF等格式
逻辑推理模块	执行动态规划与矛盾检测
报告生成模块	输出带引用和结构化结论的专业报告

记忆与上下文管理

采用分层记忆机制（工作记忆+长期知识库），支持百万级Token上下文窗口，保留跨任务连续性。

三、应用场景

领域	典型用例
学术科研	文献综述、跨学科研究关联发现、研究假设生成
金融分析	上市公司风险评估、市场趋势预测、投资策略报告
政策与商业	政策影响评估、竞品分析、市场进入策略制定
消费决策	高价值商品（如汽车、家电）的对比分析与购买建议

四、局限性与挑战

准确性争议

对权威信息识别存在偏差，尤其在科学领域可能忽略最新研究，需人工验证引用来源。

访问限制

用户权限分层：Pro用户每月250次深度研究任务，免费用户仅限5次轻量级任务。

伦理与风险

涉及敏感数据隐私、生成内容版权归属，以及技术资源不平等导致的“科研鸿沟”。

五、与传统工具的区别

特性	Deep Research	传统AI助手/工具
任务复杂度	端到端研究流程自动化	单次问答或独立功能（如文献管理）
推理能力	多步骤动态规划与自我修正	依赖预设提示或简单检索
输出形式	结构化报告+完整引用	碎片化答案或无来源信息

六、未来方向

多模态扩展：整合实验数据、视频等非文本信息。
领域专用化：针对生物、材料等学科定制推理逻辑。
开源生态：项目如OpenManus支持本地部署，降低技术门槛。

Spring Ai Alibaba Deep Reseach

项目架构图（如果图小，就去看一下Github的Readme文件）

流程图

第一个Node，查询的重写和扩展

首先，运行起项目，跑一下示例。

用户问题：请为我分析泡泡玛特现象级爆火的原因

Spring Ai Alibaba Deep Research（之后简称为deep research）进行的第一个Node，对问题进行重写和扩展。

查询重写结果

分析泡泡玛特现象级爆火的关键原因

扩展查询

分析泡泡玛特现象级爆火背后的商业模式与市场策略

解析泡泡玛特在潮流玩具市场中迅速走红的文化和社会因素

探讨泡泡玛特成功打造“盲盒经济”并引发消费热潮的核心驱动力

有没有发现什么问题？

只有宽度（而且不够宽），最严重的是没有深度

按照人类思维，最近网络上爆火的wakuku，是不是应该作为扩展的一个点？但是目前似乎只是换了2个问问题的方式。没有我们期待的结构化扩展，缺乏深度。或者可以说，缺乏泛化能力？

接下来看一段源码，项目中使用了spring ai rag的expend方法。

privatestaticfinalPromptTemplateDEFAULT_PROMPT_TEMPLATE=newPromptTemplate("""Youareanexpertatinformationretrievalandsearchoptimization.Yourtaskistogenerate{number}differentversionsofthegivenquery.Eachvariantmustcoverdifferentperspectivesoraspectsofthetopic,whilemaintainingthecoreintentoftheoriginalquery.Thegoalistoexpandthesearchspaceandimprovethechancesoffindingrelevantinformation.Donotexplainyourchoicesoraddanyothertext.Providethequeryvariantsseparatedbynewlines.Originalquery:{query}Queryvariants:""");

翻译：

你是信息检索和搜索优化方面的专家。您的任务是生成给定查询的{number}个不同版本。每个变体必须涵盖主题的不同透视图或方面，同时保持原始查询的核心意图。目标是扩大搜索空间，提高找到相关信息的机会。不要解释你的选择或添加任何其他文字。提供以换行符分隔的查询变体。原始查询：{query}查询变体：

假如，我们现在的问题如果是关于篮球，并且可以从Graph RAG中搜索到相关的知识

那么我们的问题扩展是不是就有深度了？所以只需要限制宽度和深度进行Graph RAG的检索。大概率可以解决查询扩展缺乏深度的问题。

所以，这是Deep Research需要Mem0这种记忆管理框架的原因之一。

第二个Node，RAG

这是项目源码：

logger.info("rag_node is running.");
String query = state.value("query", String.class)
  .orElseThrow(() ->newIllegalArgumentException("Query is missing from state"));

// Use the advisor to get the RAG-enhanced response directly
String ragResult =chatClient.prompt().advisors(this.retrievalAugmentationAdvisor).user(query).call().content();

logger.info("RAG node produced a result.");

Map<String, Object> updated =newHashMap<>();
updated.put("rag_content", ragResult);

returnupdated;

我们可以看到，就是使用了advisors查询了一下用户问题。这步跟第一步其实一样，也是缺乏结构化数据。

如果单看这个Node，也仅仅是这样而已，使用一个Graph RAG就解决了。但仅仅如此吗？我们可以看到下一个Node是Planner，计划的规划人。那么这个RAG Node就并不简单了。如果每个用户都问相同的问题，是不是可以加快输出或者降低召回率？也就是智能体可以不可以有记忆？这可能也是大模型的魅力所在，我们在想问题的时候，往往都要把智能体看成一个人。你来安排一个人如何工作，这个人要有什么样的工作记忆，问题貌似会更简单些？

所以，这个时候，Mem0的Agent长期记忆和短期记忆就要生效了。agent_id + run_id是短期记忆，agent_id搜索知识库是长期记忆。

此处RAG Node显然应该给Planner提供长期记忆搜索结果作为上下文参考。

第三个Node，Planner

终于到了一个重要的角色，Planner。整个任务流程最重要的一个人。负责制定完成用户要求的步骤规划人。

这是运行时Planner的上下文

planner_content: {

"has_enough_context": false,

"steps": [

{

"description": "收集泡泡玛特现象级爆火的市场数据，包括销售增长、用户画像、市场份额等关键指标。",

"executionRes": "",

"executionStatus": "",

"need_web_search": true,

"step_type": "RESEARCH",

"title": "市场数据与用户画像分析"

},

{

"description": "研究泡泡玛特的商业模式和市场策略，包括产品设计、营销手段、品牌合作等内容。",

"executionRes": "",

"executionStatus": "",

"need_web_search": true,

"step_type": "RESEARCH",

"title": "商业模式与市场策略解析"

}

],

"thought": "分析泡泡玛特现象级爆火的关键原因",

"title": "泡泡玛特现象级爆火的原因分析"

}

这个上下文其实就可以作为某一次运行的记忆了。也就是智能体的短期记忆。然后就该有人想问了，直接传给下一个Node不就好了吗？为什么要写进短期记忆？

因为本次任务的核心是什么？解决用户问题。用户A问了篮球，用户B问了足球。这是一件事儿吗？不是。

那么如何去掉每次规划任务的“噪声”？短期记忆，可以锁定任务的核心内容。如果仅仅是传递给下一个Node，那么在这种循环的场景下很有可能就出现最后输出的结果可能不是你问的问题相关的。。

所以我们需要对参与整个流程的每一个智能体，都设置长期、短期记忆，来作为真正的上下文，才能把持住边界(Edge)。

后面的节点不分析了，如果大家有兴趣，之后抽空再讲。要不然跑题太多啦。

说了这么多废话，终于讲到了本文真正的核心（以下总结为Ai生成，比我写的好。。。）

上下文工程

上下文工程（Context Engineering）是近年来在AI领域迅速崛起的关键技术范式，尤其在大型语言模型（LLM）驱动的智能体（Agent）开发中成为核心架构。它通过动态构建系统，为模型提供精准的上下文信息与工具，从而显著提升智能体的推理能力、执行效率和鲁棒性。以下从定义、核心原理、重要性及实践策略展开说明：

一、核心定义与技术原理

本质与目标
上下文工程是设计动态系统的学科，旨在在正确的时间、以正确的格式，为LLM提供完成任务所需的信息和工具，使其能够合理决策并执行复杂任务。其核心隐喻来自Karpathy的比喻：
“将LLM视为CPU，上下文窗口则是RAM，而上下文工程就是管理内存（RAM）的操作系统。”
即通过动态调度信息流，优化有限上下文窗口（如128K token）的利用率。
与传统提示工程的区别
提示词工程

聚焦静态指令设计（如优化提问措辞），适用于单轮简单任务

上下文工程：

系统化
整合多源动态数据（用户历史、工具输出、长期记忆等）；
动态性
实时生成上下文，非固定模板；
工具集成
提供外部工具（如API、数据库）并规范其调用格式

二、为什么成为AI智能体的关键？

解决LLM的固有瓶颈

“垃圾进，垃圾出”原则
LLM无法主动获取未提供的上下文，错误或缺失信息直接导致低质输出。
上下文失败即模型失败
研究表明，智能体80%的失误源于上下文管理不当（如信息缺失、格式混乱），而非模型能力不足。

支撑复杂任务的核心能力

能力需求	上下文工程的作用
多轮推理	通过短期记忆（对话历史）和长期记忆（用户偏好）维持状态连续性。
工具协同	定义工具模式（如JSON Schema），规范LLM调用外部API的逻辑。
抗干扰性	避免“上下文中毒”（错误信息循环引用）或“上下文干扰”（冗余信息淹没关键数据）。

效率与成本优化

减少Token浪费
：通过压缩（如摘要）和选择策略，仅加载必要信息，降低计算开销。
动态预取
：根据任务预测所需数据，提前加载减少延迟。

三、核心组件与架构设计

上下文窗口需结构化组织，包含五大类组件：

指令性上下文

系统提示（角色定义）、用户查询、少样本示例（引导输出格式）。

状态上下文

短期记忆（当前对话历史）、长期记忆（跨会话用户数据）、暂存区（中间计算结果）。

外部知识上下文

RAG检索结果
：从知识库/API动态获取实时数据（如股票行情）。

工具上下文

工具定义（功能描述）、工具响应（API返回的JSON数据）。

结构化上下文

输入/输出格式约束（如强制JSON响应），提升模型解析可靠性。

案例：医疗诊断智能体需整合患者病史（长期记忆）、最新论文（RAG）、检查工具定义，并输出结构化诊断报告。

四、四大核心实践策略

针对上下文管理失效风险（如中毒、干扰），需采用系统化策略：

写入（Write）

草稿本
：临时存储中间步骤（如数学计算过程）；
记忆库
：持久化关键数据（如用户习惯）。

选择（Select）

从记忆库/RAG中检索相关性最高的信息，过滤噪声。

压缩（Compress）

摘要长文本（如将10页报告浓缩为3点结论）；
修剪冗余token（删除重复描述）。

隔离（Isolate）

多智能体架构
：任务拆分至独立子智能体，避免上下文污染；
沙盒环境
：隔离高风险操作（如代码执行）。

本文最后：Deep Research需要一个上下文工程系统来增强多智能体长期、短期记忆边界的能力以及用户长期、短期记忆来生成更符合预期的结果。那么，Spring Ai Alibaba + Mem0是个不错的选择。