前言

随着业务场景的复杂性, single-Agent 中token上限已成为难解的题, 而multi-Agent 能把 token 更合理地分配和消耗，从而避免长上下文的性能损耗，从而更有效地消耗token。

在单一 Agent 架构下，即使你给它 20 万 token 的预算，也常常因为上下文过长而导致效果下降。相比之下，多 Agent 架构能够把总预算拆分：比如主 Agent 分配 10 万 token，每个子 Agent 各自分配 2 万 token。这样每个子任务都在相对合适的上下文长度中完成，整体能更有效地利用 token 资源。

智能体架构

简单的single-Agent架构也称增强型大语言模型(augmented LLM)是Agent的基本构建单元，它集成了检索、工具和记忆等能力。现代模型能够主动使用这些功能，如生成搜索查询和选择适当工具。

2024年12月，Anthropic发布了一篇关于构建AI智能体的重要博客。Anthropic经过与数十个跨行业团队的合作，得出一个关键结论：最成功的AI Agent并非依赖复杂框架或专用库，而是采用简单、可组合的构建模式。Anthropic 把下述两种统称为 agentic systems：

• Workflows: 通过预定义代码路径协调LLMs和Tools。
• Agents: LLM自主决定过程和Tools的使用，控制任务完成方式

市场上大多数所谓的"智能体"(包括Manus)实际上是workflows。真正的agents相对较少，如OpenAI的Operator、Deep Research以及Cursor等产品。Anthropic提供了清晰的选择指南：

1. 从简单开始：为LLM应用选择最简单的解决方案，如一开始通过prompt 来解决，只在必要时增加复杂性
2. 根据任务特性选择：对于可预测、定义明确的任务，需要一致性时使用workflows；当需要大规模的灵活性和强大的模型来驱动决策时，使用真正的Agent
3. 避免过度设计：对许多应用来说，优化单个LLM调用(通过检索和上下文示例)已经足够

Agent的构建分为不同复杂度级别，从基础的增强型大语言模型Augmented LLM开始，逐步发展到预定义的workflow，最终形成自主的 agent。

Workflow: Prompt chaining

链式工作流就是将复杂任务分解为连续步骤，每步LLM调用处理前一步输出，可添加检查点（如下图的Gate）确保过程正确。适用于可清晰划分的任务，如营销文案生成后翻译或先创建文档大纲再撰写完整内容。

Workflow: Routing

路由工作流就是先给输入内容"分类"，然后根据这个分类标签把它送到最合适的专门处理流程去。这种方法在处理那些有明显不同类型的复杂任务时特别有用，比如可以把各种客服问题分类处理，或者根据问题难度路由到小模型或大模型来回答。

Workflow：Parallelization

并行工作流就是让多个大语言模型同时处理任务，可以分成两种方式：一种是"分子任务"，把大任务切成小任务同时处理；另一种是"投票"，让多个模型做同一件事然后综合结果。这种方法在需要提高处理速度或者想要多角度意见时非常有用，比如一个模型专注回答问题，另一个专门检查内容是否得当。具体应用例子包括代码安全审查、内容审核，或者让每个模型评估不同方面，这样比让单个模型同时兼顾所有方面效果更好。

Workflow: Orchestrator-workers

评估者-优化者工作流就像一个模型出方案，另一个当评委提意见，然后循环改进。适合那些有明确评价标准、需要反复打磨才能效果好的场景。有点像是我们写毕业论文，导师不断反馈，我们不断修改，直到达到要求。

端到端Agent

相比于 workflow，Agent 的设计反而是很简单。背后依靠强大的推理模型，让模型自己去理解复杂输入、进行推理和规划、使用工具以及从错误中恢复。

Agent在循环(loop)中工作，根据输入自己选择合适的工具，并能根据环境反馈调整策略——例如当代码执行失败时，能根据错误信息自动修正；或根据问题性质自主决定采用sequence还是Parallel的workflow方式解决。

智能体的核心在于模型主导全部决策过程，人类无需预先定义详细流程，只需在特定情况下提供少量干预，如在Deep Research中我们只需要确认关键的信息或在Operator中当输入账号密码等敏感信息需要人类干预。本质上，agent将复杂任务的规划和执行权交给模型，所谓模型即服务，采用端到端的优化来提升效果。

Deep ReSearch

在深入研究Deep Research前，我们必须理解：Deep Search是Deep Research的基石。 搜索的本质在于找到全面和直接的信息。根据需求和场景，我们可以采用不同的实现方式：

• 结构化数据查询：编写SQL语句查询公司内部数据库
• API调用：使用关键词调用外部搜索API（如Google、Bing）
• 虚拟浏览器：通过Operator等工具模拟人类浏览网页
• …

搜索任务的复杂度也呈不同等级递增，如单跳搜索"哪吒2的导演是谁"、多跳搜索"哪吒 2 的导演还导演过什么电影？“、偏向 deep research的搜索"研究《哪吒2》在国际市场的接受度与文化输出效果，分析其对提升中国文化软实力的贡献”。

多跳搜索和深度研究型搜索的关键在于模仿人的思维链搜索：

1. 模型首先根据问题进行初步推理，确定基础搜索方向
2. 执行初始搜索，获取第一批信息
3. 基于已获取的信息，进行下一轮推理，确定进一步的搜索方向
4. 执行细化搜索，获取更精准的信息
5. 不断迭代这个"推理→搜索→推理"的循环，直到收集足够信息 在这个过程中，每次搜索都建立在前一次搜索结果的基础上，形成一个连贯的推理链。

Deep Research 是掌握了这种迭代式、思维链式的搜索能力的Deep Search是的基石

论文 1: 《Search-o1: Agentic Search-Enhanced Large Reasoning Models》

Search-o1 是最近比较火的 WebThinker 项目的前身，它提出了一种新颖的方法，让大型语言模型在推理过程中能够主动进行网络搜索，从而增强其推理能力。与传统检索增强生成（RAG）系统相比，Search-o1 有两个关键创新点：

• 核心组件一: 主动式检索增强生成机制

  传统 RAG 通常是一次性的：在回答问题前进行一次检索，将检索结果放入上下文中。而 Search-o1 实现了动态的、多步骤的检索机制：

  • 模型在推理过程中可以识别自身知识的不足点
  • 当遇到知识不确定的情况时，模型会自动生成搜索查询，格式为 <|begin_search_query|>搜索词<|end_search_query|>
  • 系统检测到这一标记后，暂停模型推理，执行网络搜索
  • 搜索结果被包装在 <|begin_search_result|>检索到的内容<|end_search_result|> 标记中返回给模型
  • 模型继续推理，并可以根据需要多次重复这一过程。

• Search-o1的核心组件二:Reason-in-Documents模检索有一个很严重的问题，就是检索出来的内容可能很杂乱和很长，而现在的大模型处理长文本性能会下降，因此，论文剔除，用另外一个 Reason-in-Documents，把检索到的内容进行精炼，再放入到原有推理链中，从而缓解检索文档中存在冗余信息和LLM 处理长文档的局限性。

示例说明

以下图论文中的示例为例，详细说明整个工作流程：

1. 模型开始推理，遇到需要特定知识的环节
2. 模型生成：<|begin_search_query|> reaction of grignard reagent with aldehyde <|end_search_query|>
3. 系统暂停模型推理，调用搜索引擎获取结果
4. Reason-in-Documents 模块分析搜索结果，提取关键信息
5. 精炼后的内容被包装在 <|begin_search_result|>提炼后的检索内容<|end_search_result|> 中
   模型继续推理，可能进行多轮搜索-精炼循环
6. 最终生成完整且准确的答案 !

Search-o1与传统 RAG 的区别

• 检索触发机制：传统 RAG 是静态的、预先定义的；Search-o1 是动态的、由模型主动触发的
• 检索频率：传统 RAG 通常进行一次性检索；Search-o1 支持多次、迭代式检索
• 内容整合：传统 RAG 直接插入大量文档；Search-o1 经过精炼后仅保留关键信息
• 推理连贯性：Search-o1 保持了推理流的连贯性，避免了传统 RAG 可能导致的推理中断

论文 2: 《DeepRetrieval: Hacking Real Search Engines and Retrievers with Large Language Models via Reinforcement Learning》

用强化学习来训练query改写

query改写已被证实是检索流程中的关键步骤。当用户提交问题时，大型语言模型(LLM)通常会对其进行重新表述(称为增强查询)，然后再执行检索。DeepRetrieval采用创新方法，利用强化学习(RL)而非传统的监督式微调(SFT)来优化这一关键步骤。

DeepRetrieval的突出之处在于它能够通过"试错"方式直接学习，使用检索指标作为奖励，无需昂贵的监督数据。这种方法使模型能够针对实际性能指标进行优化，而不仅仅是模仿人工编写的查询。

论文 3: 《Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning》

结合交错式多轮搜索引擎调用的文本生成, Search-R1通过创新的五阶段交互流程实现知识检索与推理的深度融合：

1. 初始问题解析阶段
   当接收到用户问题时，模型首先在思考标签内进行初步推理分析，识别当前知识储备中的信息缺口。
2. 动态检索决策阶段
   若推理过程中发现知识不足，模型将自主触发检索机制，通过查询内容格式生成精准搜索指令。
3. 信息整合阶段
   搜索引擎返回的结果会被结构化封装在信息标签内，为后续推理提供可靠的外部知识输入。
4. 迭代优化机制
   系统支持多轮次检索-推理循环，模型可根据信息完备性动态决定是否发起新一轮检索，直至满足解答需求。
5. 最终响应生成阶段
   当判定信息充足时，模型直接通过答案标签输出简洁结论，无需附加解释说明。

与 Search-o1不同的是，Search-R1针对任务进行了强化学习的训练，Search-R1没有 Search-o1的 Reason-in-Documents模块，检索到的内容是直接完整放到思维链中的。Search-R1使用基于规则的奖励系统，只关注最终结果的正确性.

论文 4: 《R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning》

两阶段的强化学习增强检索能力, R1-Searcher引入了一个两阶段基于结果的强化学习方法，使LLM能够在推理过程中自主调用外部搜索系统：

1. 第一阶段(检索学习训练)：通过检索奖励激励模型学习如何正确调用外部搜索，不关注答案准确性。
   • 检索奖励 (Retrieval Reward):
     0.5分：当模型至少执行一次检索操作
     0分：未进行任何检索
   • 格式奖励 (Format Reward):
     0.5分：完全符合规定的输出格式标准
     0分：格式不符合要求
     • 格式规范要求：
       思考过程必须封装在…标签内
       最终答案必须封装在…标签内
       检索查询必须使用<begin_of_query>…</end_of_query>标签标记
       严格禁止未调用检索系统直接生成文档内容
   • 阶段总奖励：Rretrieval + Rformat (最高1.0分)

• 第二阶段(检索结果集成训练)：在确保格式规范的基础上，提升模型有效利用检索信息解决问题的能力
  第二阶段删除了检索奖励，引入了答案奖励，同时保留格式奖励但调整了惩罚力度

  • 格式奖励 (Format Reward):
    0分：格式完全正确
    -2分：格式出现任何错误
    (注：相比第一阶段，显著提高了格式错误的惩罚力度)
  • 答案奖励 (Answer Reward):
    使用F1分数作为答案奖励：Ranswer = 2 * IN / (PN + RN)
    其中：
    • PN: 预测答案的词数
    • RN: 参考答案的词数
    • IN: 预测答案与参考答案的交集词数

• 阶段总奖励：Format Reward + Answer Reward 这种两阶段设计通过分离关注点，先确保模型掌握正确的检索行为规范，再专注于提升答案质量，实现了检索能力与信息整合能力的阶梯式提升。

总结

Search-o1、 Search-R1、R1-Searcher 的研究方向基本一致：构建长的搜索推理思维链，在思维链中不断调整搜索策略。一个重要共识是，强化学习比监督微调(SFT)能带来更好的泛化性。 DeepRetrieval虽然关注查询改写，但范围过窄，难以形成完整思维链。理想的查询改写应是思维链中的自然产物，而非单独训练的任务。 所以 Deep Research 是基于推理思维链的Deep search.完整的Research涉及更多挑战，如并行搜索、超长下文管理、研究目录编写、结论调整等。即先把Search做好，才能做好Research。

Jina 项目

Jina是一个优质的开源项目，其公众号Jina AI分享了许多干货。原版是TypeScript 实现,网友实现了python版：python-node-deepresearch

实例分析：京东为什么要做外卖？它到底能如何利用现有优势来挑战美团的老大地位？
让我们以这个问题为例：“京东为什么要做外卖？它到底能如何利用现有优势来挑战美团的老大地位？”。来具体解析Jina是如何实现"Deep"的。

对问题建立对应的评估标准

当研究问题进入agent系统后，首先会由一个专门的Prompt，让 LLM 来判断该问题需要通过哪些评估标准，prompt 如下：

包含四种核心评估维度：

• Definitive（明确性）：判断问题是否需要明确的答案，而非模糊表述。例如：“谁发明了微积分？”—需要明确的答案
• Freshness（时效性）：判断问题是否需要最新信息。例如：“当前美国的利率是多少？”—需要最新经济数据
• Plurality（多样性）：判断问题是否需要多个项目或示例。例如：“请列出五个最著名的莎士比亚悲剧”—需要列出多个项目
• Completeness（完整性）：判断问题是否包含多个需要全面解答的元素。例如：“赤壁之战的历史背景、参与者、战略意义及影响是什么？”—需要全面回答多个方面

对于我们的京东外卖问题，LLM 判断需要满足"明确性"和"完整性"两个评估标准：

这些评估标准背后各自对应不同的Prompt。例如，"明确性"评估的Prompt如下：

这些评估标准将在最终答案生成后使用，即在得到答案之后，系统会通过这些评估标准来检查答案。如果答案满足所有评估标准，系统才会输出最终结果。如果不满足标准，系统会持续优化答案，直到预设的token额度消耗完或答案通过所有必要的评估。

本质上，不同问题必须根据其本质通过特定评估，才算真正解决。如果不满足标准，系统会持续优化答案。这就是 “deep” 的一个体现。

四大核心动作的抽象与实现

在确定了问题需要的评估标准之后，我们才进入真正的工作流程。 Jina将深度研究抽象为四个核心动作（action）的不断选择。具体来说，系统会让LLM基于当前的记忆（包括之前的步骤和已获取的知识）通过Prompt来决定采取哪一个核心动作。

这四个核心动作分别是：搜索（Search）、阅读（Visit）、思考（Reflect）和回答（Answer）。

Action 1: Search

当系统选择Search动作时，它不仅仅是用原始问题进行直接搜索，而是让大模型生成多个相关的search query（搜索查询），以获取全面的信息。

例如，对于京东外卖问题，模型第一步决定，采用 search action，并生成了以下search query：

search_requests问题会分别调用s.jina.search的搜索API获取结果。搜索结果包含有初步的信息，包含title、description、url 、 date等，注意，这里的 description 只是这个 url 内容的一个概述，并不是完整内容。如下图是 jina 官网中的测试示例，跟用 api 调用返回结果是一样的

有趣的是，Jina不会在第一轮搜索后就停止search 这一步。而是根据初步搜索结果，对 search query 进行改写，以进一步细化搜索问题。

query 改写的 prompt 很有趣，如下，让 llm 扮演一个专家怀疑者、细节分析师、历史研究院等等等等，根据初步 search query和搜索出来的内容，去进一步挖掘新一轮的 search query：

如这里生成了新的search query 如下：

• 京东在外卖市场的最新动态和市场份额
• 京东与美团外卖市场份额历史变化
• 京东外卖的创新与服务质量

因为一个复杂的研究问题必然需要拆分成多个搜索子问题，全面收集相关信息，才能形成深度报告的基础，这里，search query改写 的目的也是通过迭代搜索的策略，更细粒度地找到更详尽的信息。

Action 2: Read

当有Search结果后，模型可以选择Visit(阅读)动作，进一步深入分析搜索结果中的部分url链接，以便获取更准确的信息。 在这个例子中，模型在第二步决定从第一步搜索到的URL中，精读四个最相关的url。

阅读这一步调用的是 jina 的 r.jina.ai接口，背后采用的是jina自研的ReaderLLM V2.0模型来处理网页内容（readerLM v2.0是一个小 size 的 LLM，输入HTML，输出结构化的Markdown格式或json）如下图所示

阅读阶段的关键在于如何从大量候选URL中选择最值得阅读的几个。这一步骤对最终报告的质量有着决定性的影响。Jina采用了多种启发式方法来优化这一选择过程，主要包括以下四个加权因子：

1. 频率因子（freq_boost）：根据URL出现频率加权，多次出现的URL获得更高权重。比如，某个 URL 在不同的search query中返回多次，它比只在一个查询中出现的URL得分更高。
2. 域名因子（hostname_boost）：根据 URL 的hostname出现频率加权，频繁出现的hostname会获得更高的加权。
3. 路径因子（path_boost）：根据 URL 的路径部分（域名后的部分）出现频率进行加权，路径越常见的 URL 会获得更高的加权。
4. 语义重排序因子（jina_rerank_boost）：调用 jina 的 rerank API，背后是专门针对query 和 passage语义排序训练过的 embedding 模型，这个因子通过评估搜索内容与当前问题的相关性，进一步优化URL的排序。

通过这四个因子，模型为每个候选阅读的URL赋予了权重，然后用 llm 参考这些权重，根据当前的上下文选择最合适的 url 进行阅读。除了这些主要因素外，Jina还对许多细节进行了优化，例如：

• 设置最小和最大权重范围，防止某些URL的权重过高或过低，确保选择的URL具有合理的分布。
• 限制同一域名下的URL数量不超过两个，以保证来源的多样性，避免依赖单一来源。
• 通过白名单和黑名单机制，增强对权威来源的倾斜，并屏蔽不可靠的站点。

这些精细的设计让大模型能够高效地阅读和提取与当前问题最相关的内容，为深度报告的编写提供有力的依据支持。

Action 3: Answer

当系统认为已经收集到足够的信息后，它会生成答案，并附上答案的引用（即通过“阅读”步骤（visit）得到的详细文章内容）。例如在这个例子中，第三步中，模型认为根据当前的搜索结果和阅读得到的资料，已经能够生成完整的回答，因此模型在这里对我们的原始问题进行了回答。然而，生成答案并不意味着流程就此结束。系统会对答案进行进一步的检查：

• 当前回答的是否为原始问题，而非reflect 得到的子问题。假如只是回答了 reflect 出来的子问题，那代表原始问题还没回答，继续进入 loop 中。
• 答案是否通过了所有必要的评估标准，例如这个问题中，我们要通过"明确性"和"完整性"两个评估标准。

这这个例子中，模型是回答了原始问题，但并没有通过评估标注。
如果评估未通过，系统会使用专门的Prompt来分析失败原因，这个 prompt 长这个样子：

evaluation 失败原因的分析结果会作为补充到上下文，指导agent系统进一步改进答案，直到满足所有评估标准。这一过程确保了最终的回答不仅准确，还符合高质量标准。

Action 4: Reflect

Reflect阶段是实现"Deep"的关键环节。在这一阶段，系统会维护一个gaps问题列表，并不断识别出知识的缺口，从而生成子问题，假如到这个列表中。例如，这这个例子中，第四步，模型认为当前需要通过Reflect阶段，生成需要进一步研究的子问题。

需要特别注意的是，Reflect问题与Search查询（search query）是有本质区别的：

• Reflect问题：是对原始问题的深入分析与分解，目的是产生可以独立研究的子问题。每一个子问题都与原问题相关，且待解决后将成为进一步回答原始问题的上下文知识。
• Search查询：是为了解决当前子问题而查询搜索引擎使用的查询语句。Search查询本身不需要被解答，它的目的是获取有用的信息来帮助回答当前的问题。

例如，现在加上原 question，目前的gaps 列表就应该长这个样子

[“京东为什么要做外卖？它到底能如何利用现有优势来挑战美团的老大地位？”, “京东的外卖市场策略如何与其现有业务模式相结合？”, “京东的供应链与物流优势具体是如何在外卖业务中体现的？”, “在竞争中，京东有哪些独特的服务将帮助其在外卖市场中脱颖而出？”, “京东如何通过市场营销策略吸引并留住用户？”]

在每个 step 中，通过轮询的方式决定当前 step 解决 gaps 列表中的哪个问题，这个过程确保了系统在处理问题时，能够逐步深入探索每个子问题，最终为回答原始问题提供全面而深刻的知识支持。

总结

在这个例子中，第一步模型使用search进行信息检索，第二步使用visit阅读网页内容，第三步生成answer作为回答，第四步进入reflect阶段进行深度分析，之后根据需要可能继续进行其他步骤。 每个步骤中，模型会根据当前的上下文信息决定使用哪种动作。也就是说，模型可以选择在visit阅读后继续进行search搜索，或者在search搜索后进入reflect反思阶段。四种动作（search、visit、reflect、answer）的选择完全由模型根据上下文灵活决定，而不是按照固定顺序进行。

那如何进行上下文管理呢？Jina的实现方式很简单，在整个过程中，模型会通过system message和message来进行上下文管理。 通过这两种方式，模型能够有效地维护每个步骤和所获得的知识，从而确保在最新的 step 中，能根据最新的完整上下文信息做出action。

• System Message: 将先前步骤的结果概括放入System Message，如下：
• Knowledge Message: 每个动作（如read、search、reflect等）产生的详细中间结果，会作为独立的“知识消息”进行封装。这些知识消息会被存储，并在后续步骤中供模型参考和利用。如下

终止条件通常有两种：

• 答案通过所有评估标准：即模型认为当前的答案已经足够准确、完整，并且符合预设的质量标准。
• 消耗完预设的令牌预算：为了避免无限制地消耗资源，Jina通常会设置一个令牌预算，确保在有限的时间和资源内生成最佳质量的报告。

推理来分解任务

Jina 构建了一个循环的任务处理流程，其中维护一个 gaps 问题列表

gap 翻译成中文为"缺口"，这这里可以理解成，为了研究一个课题，会有很多子问题需要先解决，而且随着研究得越深，会有更多的缺口问题出现，不断补充到这个 gaps 列表中

在一个由模型自主判断的处理闭环中，每个 step，系统从gaps 列表中抽取一个问题，每个 step 由模型自主根据上下文信息，采取几种 action. 这样一步步循环推进，直到 gaps 列表清空，或达到 token 限制。整个过程中，依靠系统 system message 和 knowledge message 来进行上下文管理。这种机制理论上已经能完成非常复杂的调研任务，但实际应用时会面临两个主要问题：

• 效率低：如果一个调研任务涉及的隐含问题很多，可能需要很多个 step 才能完成，速度慢。
• 上下文能力受限：当前大模型虽然有长上下文能力，但仍在记忆和生成长文本方面存在挑战。

那有没有办法解决呢。当然有，秘诀就是拆分 + 套娃。

我们可以把 Jina 的工作流当成一个“最小单元”。这个“最小单元”可以理解为：输入一个问题，经历搜索-阅读-反思-回答的闭环，得到一个高质量回答。

面对一个复杂问题，比如“写一篇关于 XXX 的长报告”，我们首先调用一个擅长规划的模型，将其拆解为多个章节、子问题：比如生成：第一章、第二章、第三章、第四章，接下来，每个章节都调用上面那个最小单元，独立完成自己的部分，最后由一个擅长总结信息和写作的模型生成长报告。 不仅可以按照一级目录拆分，我们还可以多层套娃：章节 1.1.1、1.1.2、 1.2、 2.1… 先把 3 级问题解决，再解决 2 级问题…，最后完成整个报告的写作。

这个策略的好处是

• 局部优化效果：每个“最小单元”任务简单、明确，模型能更精准处理。
• 效率更高：并行处理每个子问题，整体速度加快。
• 模型能力解耦：可以将任务拆给不同擅长的模型 —— 有的擅长写报告，有的擅长搜索推理，各司其职。

再看看不同厂家的 deep research, 它们的主要差异体现在一些细节和执行流程上：

• Genspark：该模型的特点是首先进行“计划”阶段，但在执行过程中似乎没有进行“反思”或“回答并评估回答”这两个步骤。
• Grok：与Genspark相似，Grok同样缺乏“反思”及“回答并评估回答”这两个环节。
• Gemini：作为一个更为成熟的产品，Gemini在执行时会先进行“计划”阶段，并且能够判断哪些子任务可以并行处理，哪些需要串行执行。在写作过程中，Gemini采用批判性写作方法：可能是在完成一个篇章后，使用另一个prompt来评估写作质量。如果生成的内容不符合预期，Gemini会重新生成。换句话说，Gemini将“尝试回答并评估回答”的步骤放在了最后写作过程中。此外，从谷歌的UI来看，Gemini不会实时渲染写作内容，而是在完成后一次性渲染，应该就是这个原因。

从整体来看，虽然这些模型在细节上有所差异，但它们都依靠推理来分解任务并执行多个步骤。目前不少厂商推出的Deep Research功能，其实更偏向于端到端和固定工作流的中间形态。

这些系统会先将任务抽象成若干个action，再依据预设的 plan 和上下文记忆，让llm自己决定当前step应该采取的 action。从架构上看，这其实更像是“多轮对话系统”——每个 step 类似于一轮对话，由模型决定下一步要采取的行动。

从工程实践的角度，这种“折中式”方案反而更加可控和高效，原因有以下几点：

• 提高效率与资源利用率：将任务拆解后，不同模型可以分工协作，各司其职。

  • 例如：专门针对规划任务训练过的小模型负责规划，推理模型负责处理复杂推理，擅长写作的模型负责总结写作等生成任务。就像一个项目团队，有实习生、初级工程师和高级工程师，要把任务拆分，协同作业，更容易做成一个 big project，而不是把所有活都交给最厉害的人干，一个人干完当然可以，但再厉害的人也无法面面兼顾，且会效率低下。

• 适当抽象和任务拆分，适合 scaling：通过将任务中常见操作抽象为有限的 action（例如：调用外部工具、读取结果、反思规划、尝试回答等），模型只需根据上下文动态选择合适的 action。这种抽象之后，系统的可扩展性大大提升

  • 在广度上：只需新增各类 MCP（工具接口），如文献搜索、Google 查询、Markdown 自动生成等，就能不断拓展系统能力。
  • 在深度上：可以通过强制执行多轮反思、设定 token 使用下限、对回答进行不同维度的评估等策略，确保模型深入思考、避免浮于表面。

Context Engineering

多智能体架构对任务的合理拆解,本质上还想让 token 更合理地分配和消耗，从而避免长上下文的性能损耗，从而更有效地消耗token。所以在多智能体架构运行中向各subAgent 向模型传达适当的上下文

Prompt Enineering是Context Enigneering的一个子集。

我们常看到prompt的组成，包括有

• 系统提示/指令（System Prompt/Instructions）
• 用户输入（User Input）
• 短期记忆或聊天历史（Short-term Memory or Chat History）
• 长期记忆（Long-term Memory）
  -从知识库中检索的信息（Information Retrieved from a Knowledge Base / RAG）
• 工具及其定义（Tools and their Definitions）

Context Engineering 要解决的是动态问题 —— 不只是写一个 prompt.

假设你在设计一个Agent系统，上图每个绿色方框代表一个sub-Agent执行独立任务。当红色框的sub-Agent需要处理任务时，我们要考虑

1. 如何将其它sub-Agent 获取的信息有效地加入当前sub-Agent的上下文中。
2. 如何根据当前sub-Agent要处理的任务，把合适的外部的知识库/记忆/工具用合理的格式放到当前sub-Agent中。
3. 如果当前sub-Agent上下文过长，还需合理选择或压缩这些信息。
4. 如何把当前 Agent 对其它子任务有帮助的信息保存下来，以便其它子 Agent 能利用这些信息更好地完成它们的任务。

在电商客服场景中，一个中枢 Agent 会协调多个子 Agent（个性化、网页浏览、数据库查询、代码执行、回答、质检等），每sub-Agent 都需要不同的上下文，我们要从更系统更整体的角度去考虑怎么组织这些context。

所以，Context Engineering当然不等同Prompt Engineering了。Context Engineering 即为 智能体运行中memory管理

为什么需要上下文工程Why Context Engineering

Context Engineering 要解决的痛点在于：上下文太长或太短都会出问题，本质是信噪比的平衡。

长度太长不行

有人曾提出:把当前sub-agent之前所有上游agent的输出，用messages的方式拼接作为当前sub-agent的上下文不就完事. 就不需要Context Engineering了.但实际上，这种简单粗暴的方法会效果爆炸。

现在很多模型号称支持百万级上下文，但实际表现并不好。24年时，我做个一个观点聚类的任务，把成千上万调条网民评论放到 Kimi 里让它总结网民观点。输入不超过32K时，效果很不错，归纳提炼效果很棒；但一旦超过 32K，就明显退化，例如前面的十条观点会被过度关注后面的观点被忽略，总结的提炼程度降低。超过 100K 甚至直接出现乱码、重复。

主要原因，在《How Long Contexts Fail》里提到四种上下文损坏的情况。这里分别举一个Context Distraction和Context Clash的例子让大家代入：

• Context Distraction（上下文干扰）：模型被一堆历史信息拖住，忽视新的目标。

  例子：我平时用 Cursor/Trae 这类 AI 工具写代码时，经常遇到一个问题：当对话里积累了太多历史报错记录，模型就会被干扰。比如，我只是问个简单问题：“写个数组反转函数”，它却仍然沉迷在之前的报错修复里，回答完全跑题，大部分原因是模型误以为新问题依旧和那些报错修复相关，结果回答时跑题，模型会纠结这个简单的query是不是跟之前的报错有关系。现在我的经验是，只要连续出现 3 次以上报错，我就会直接新开一个对话，否则继续在原窗口聊，代码质量会明显下降。这就是 Context Distraction——无关的噪音上下文拖住了模型，让它无法专注新任务。# 实战/哲学/理念

• Context Clash（上下文冲突）：上下文里有矛盾信息，模型不知道听谁。

  例子：家装顾问对话里，用户一开始说“我喜欢北欧极简风，最好白色为主，线条干净。”，后来又说“喜欢中式红木家具，古色古香的那种”。AI 此时会非常矛盾，这两条信息在同一上下文里互相冲突，模型不知道该听谁的，结果很可能生成一个四不像的设计。

长度太短不行

太长不行，那就做减法呗。但做加法容易，做减法难啊～
例如,开发一个自动回复邮件的agent，有人发邮件问：“明天有空快速聊一下吗？”

• 一个过度减法的agent：只有用户请求，没有额外上下文。于是机械式回复：“明天可以。请问几点？”
• 一个优秀的agent：有丰富上下文，能访问日历（显示你已排满）、能访问过往邮件（决定语气要随意）、能访问通讯录（确认对方是重要合作伙伴）、有发邮件的工具（可直接发邀请）。于是它能生成更自然的回复：“嘿 Jim！我明天排满了，周四早上有空，已经发了邀请，看看是否合适？”。

Context Eningeering实战

太长不行，太短有不行，因为我们需要有一个系统的方法去设计我们Agent的context设计.
Lance Martin (LangChain、LangGraph的一位很核心很核心的开发者) 在6月23日的博客里《Context Enigneering for Agents》里，他把 Context Engineering 分为四个模块：Write Context、Select Context、Compress Context、Isolate Context。

当然，这只是其中一种划分方式。比如近期那篇热门论文《A Survey of Context Engineering for Large Language Models》就提出了另一种分类体系。本质上，不同的分类只是不同作者做的一种抽象.

Write Context

写作上下文指的是把当前上下文保存到上下文窗口之外，以帮助其它agent更好地执行任务。
主要有Long-term memories、Scratchpad、State三种模式

• Long-term memories: 长期记忆是智能体跨越会话边界存储信息的“外部硬盘”，通过结构化数据库或向量存储实现持久化，确保关键信息不会因上下文窗口限制而丢失。

  OpenAI 在 2024 年推出了memory 功能，能够基于用户的聊天记录回答问题。这点很有意思，我日常常把 GPT 当作一个零散的知识库，随时记录和讨论一些琐碎的问题。有时候，我会直接让它帮我做一些过去一段时间零散思维的提炼归纳，比如问：“上周我都问过你什么？” 这正是 长期记忆（Long-term memory） 的价值。

• Scratchpads: 智能体在单一会话中处理复杂任务的“草稿纸”，用于临时存储中间推理结果、待办事项或工具调用记录，避免上下文窗口被冗余信息挤占。其核心价值在于隔离思考过程与最终输出，提升推理清晰度和Token使用效率。

  Manus在7月份的博客里就提到。《AI代理的上下文工程：构建Manus的经验教训》
  其中描述系统一开始会写一个计划（并把这个计划写下来成todo.md），在后续执行过程中不断重写调整。这与人类处理复杂任务的方式类似：人们先将计划写在草稿纸上，在执行任务时再进行修改。这个 todo.md 不一定固定在messages中，而是根据需求导入，可以通过 RAG 检索本地文件，也可以预定义工具（如 Retrieve_plan）读取 todo.md 文件。

• State:我们完全可以把Agent运行过程中一些有价值的中间变量写下来保存为贯穿整个 Agent 内部工作流的一些变量。它与Scratchpad的区别在于：State聚焦任务状态的宏观把控，而Scratchpad侧重具体步骤的细节记录(临时变量和会话变量的区别)

  用API调过LLM的同学们都知道，传入的是 messages，这是我们与 LLM 对话的主线。
  我们可以定义一个名为 todo的 State 变量，在整个 Agent 系统中流转，按需更新或在某些sub-Agent中纳入其到当前messages中使用。这些变量，与主线对话消息message是独立的。

Long-term memories、Scratchpad和State并非孤立存在，而是通过“检索-处理-存储”循环形成有机整体：

• 初始化：任务开始时，系统从Long-term memories检索用户偏好、历史交互等信息，结合当前State（如“新会话”）构建初始上下文；
• 任务执行：智能体将中间结果写入Scratchpad（如“暂存搜索关键词”），并实时更新State（如“搜索中→分析中”）；
• 记忆更新：任务结束后，Scratchpad中的关键信息（如用户新需求）经压缩总结后存入Long-term memories，State重置为“待新任务”状态

Select Context

选择上下文意味着在某些时刻，召回内外部的信息拉入当前LLM的上下文窗口中，以帮助当前的agent更好执行当前的任务。

• Retrieve relevant tools: 工具检索聚焦于识别并调用外部功能模块，使AI能执行超越自身能力边界的任务。其核心挑战在于理解工具间的依赖关系与使用时机

  大家做过tools调用的时候，可能就对以下的经历感同身受了。在工具调用中，当工具数量不多且功能明确时，模型的调用效果较好。但一旦工具增多，问题便会放大。尤其是随着MCP的涌现，很多工具的参数和描述不够严谨，容易导致混乱。例如，多个工具都使用“date”作为变量名，但期望的格式不同：tool1期望“2025年9月19日”，tool2期望“20250919”。这种情况容易造成上下文混乱（Context Confusion）。
  解决方法相对直观：

  • 使用RAG召回与当前消息相关的前10个工具。
  • 也可以像 Manus 提到的，建立统一命名体系，例如浏览器相关工具以browser_开头，命令行工具以shell_开头。这样模型可以在正确的工具组中选择，而不依赖复杂的logits控制。

• Retrieve from scratchpad / long-term memory: scratchpad和memory都是write context中保存的有价值的内部内容。其实这就联系上了，把其它agent有用的信息保存下来，召回给到当前agent用。

  比如，当用户要求“推荐菜单”时，如果在记忆中发现用户是“素食主义者”，就应该召回这一信息。

• Retrieve relevant knowledge: 最常见的Rag, 现在用搜索API根据query召回合适的内容做grounding可以使用以下因素进行筛选： 频率因子（用不同query搜索，URL多次出现得分更高）、域名因子（频繁出现的host name加权更高）、路径因子（常见路径得分更高）、语义重排序因子（embedding粗排精排那套）。黑名单/白名单要做好大概率要有，还能开发很多小模型例如（水文模型）过滤。

Compress Context

跟之前说的，虽然现在很多大模型号称能处理一百万token，单当任务一复杂，可能100K token效果就爆炸了。所以需要压缩上下文涉及当上下文过长时，仅保留执行当前任务所需的标记。

• Summarize context:上下文摘要, 是大语言模型处理长文本或多轮交互时的核心技术，通过提炼关键信息减少Token消耗，同时保留任务所需的核心逻辑。

  这里以Claude Code举例，上下文窗口满了／接近满时，Claude Code 会 自动压缩（summarize / “compact” 对话历史），以释放空间。 官方提到：当上下文用量达到 95% 时，会自动触发压缩功能。

• Trim context remove irrelevant tokens:（修剪上下文以移除无关tokens）是大模型上下文工程的核心技术，通过精准筛选信息，在控制token消耗的同时维持关键信息完整性。

  • 最简单的裁剪方法是 直接截掉对话轮数，例如已有 10 轮消息，就丢弃一部分。
  • 更精细的方式如 Provence（Pruning and Reranking Of retrieVEd relevaNt ContExts），会在原文中去除语气词和无关词，只保留与任务相关的核心内容，这同样是一种 trim，如下

Isolate Context

隔离上下文涉及将其拆分，以帮助当前agent更好执行任务。

• Partition context in state: 跟之前的write context的state对应。除了主线的 messages，我们还能保存一系列 状态变量，供不同的 subagent 使用，而不要一股脑把什么东西都塞到与大模型直接交互的message里。

• Hold in environment/sanbox:"沙箱隔离"技术, 指将程序、代码或进程限制在隔离的测试环境中运行，防止其对真实系统造成意外影响。

  Hugging Face 的 smolagents 框架以 “Code as Actions” 为核心理念，通过让大模型直接生成可执行 Python 代码来驱动智能体（Agent）行为，彻底颠覆了传统框架依赖 JSON 格式工具调用的模式。解决了在传统 Agent 流程里可能需要反复多轮调用工具。

• Partition across multi-agent: (多智能体任务划分）是多智能体系统（Multi-Agent System）的核心设计理念，指通过系统性拆分复杂任务，让多个智能体（Agent）并行处理子任务，最终协同完成目标。

  例如:我这里设计一个检索每天新闻大事的agent，由一个管理者supervisor控制怎么流转，里面有搜索agent，回答agent，回答agent后一定要经过一个做评估的judge agent。假如不通过eval，就回到supervisor中，要是通过，就结束。当我们流转到judge时，这时候，你还要输入前面所有的搜索信息吗？ 当然是不需要的，这只会干扰它当前完成eval这个任务的效果，你只需要输入当前模型的回答，以及你的评估标准。
  以上就是Parition across multi-agent，那么问题来了, judge后的输出怎么write context，给到supervisor作为有效信息呢？

  1. 全部放到system prompt里。这样supervisor就变成全是单轮对话了。
  2. 放到messages里进行管理
  3. 写出到外部文件，后续按需rag。
     
     

  怎么选择：选择的标准很多，

  • 用测试集效果来决定，哪种方法在测试集效果好就用哪种。
  • 从训练的角度来考虑，假如方法一能拿到75分，方法二能拿到70分，但从训练来说，方法二的格式更好训，那选方法二未尝不可。
  • 使用第三种的情况, 如Manus的围绕KV缓存进行设计, 目标是解决AI智能体在循环执行任务时的高推理成本与长响应延迟问题.其本质是存储Transformer注意力计算的中间结果（键值对），当输入文本存在重复前缀时可直接复用这些结果.

站在巨人的肩膀上

《为什么我们需要 Context Engineering？》
《25年什么样的 Agent 会脱颖而出：简单胜于复杂》
《端到端的训练，怎么复现 Deep ReSearch（上） ：先从 Deep Search 做起》
《端到端的训练，怎么复现 Deep ReSearch（中） ：围绕着"Deep"，解构 Jina 项目的实现》
《端到端的训练，怎么复现 Deep ReSearch（下） ：前沿的产品形态》