我要投稿

Burger's AI Note 12：上下文工程的解读（Manus & Langchain访谈）

发布日期：2025-10-21 20:50:07 浏览次数： 2272

作者：Burger AI Notes

微信搜一搜，关注“Burger AI Notes”

近期关于上下文工程，Manus和Langchain联合出品了一集连线访谈，系统地讨论了行业内主流应用的上下文工程构建。其中，Manus的分享尤为精彩，精细地描述了构建上下文的细节干货。我整理了核心观点作为这期笔记的内容。

随着大模型进入“长上下文”时代，我们发现窗口大小（Context Window）并非银弹。当上下文窗口膨胀到一定程度，模型会开始出现推理速度变慢、生成质量下降、甚至“忘记”关键指令等问题，这就是所谓的“上下文腐烂”（Context Rot）。

如何驾驭这匹“长上下文”的野马？答案直指一个关键领域：上下文工程（Context Engineering）。

Langchain与顶级AI Agent公司Manus的深度访谈，揭示了上下文工程的五大核心策略。这篇文章将结合访谈内容，为你系统拆解这些在生产环境中被反复验证的实用技术。

为什么我们需要上下文工程？

核心观点

上下文工程是连接通用大模型与复杂应用场景之间，最清晰、最实用的分界线。对于初创公司而言，与其过早投入资源去微调专用模型，不如先通过上下文工程技术，将通用模型的潜力发挥到极致。

详细阐述

Manus的经验告诉我们，过早地对大模型进行SFT（有监督微调）或RL（强化学习）可能会“踩坑”。原因在于，有效的RL需要固定的动作空间和大量基于现有产品行为的反馈数据。然而，AI Agent领域的发展日新月异，整个行业格局可能一夜剧变。

例如，一个颠覆性的MCP（Model-Controller-Platform）平台上线，就可能彻底改变原有的设计理念，从紧凑的静态动作空间，转变为几乎无限扩展的架构。在这种开放域问题上，训练自有模型的难度堪称登天。

因此，将应用逻辑与模型本身解耦，通过上下文工程来管理和优化输入给模型的信息，成为了当下最高效、最灵活的路径。

上下文工程的五大核心策略

上下文工程主要围绕五个维度展开：卸载（Offload）、减少（Reduce）、检索（Retrieve）、隔离（Isolate）和缓存（Cache）。

1. 卸载上下文（Offload Context）

核心观点

将长篇或非紧急的上下文信息从“上下文窗口”中转移到外部存储（如文件系统），仅在需要时调回，从而为更关键的即时交互保留宝贵的窗口空间。

详细阐述

想象一下，你正在让Agent执行一个复杂任务，它需要一份详细的计划书。这份计划书如果一直占据着上下文窗口，会迅速消耗大量Token。

“卸载”的思路就是，先把这份计划书存为一个外部文件。当Agent在后续步骤中需要参考时，再把它读取回来。这种方式在Claude Code等众多生产级Agent中非常流行。本质上，这是将信息“外置存储”，按需调用，避免了上下文窗口的拥堵。

2. 减少上下文（Reduce Context）

核心观点

通过“总结”或“压缩”两种手段，主动精简上下文信息，减少Token消耗，有效避免因上下文过长导致的“上下文腐烂”问题。

详细阐述

这是目前最主流的上下文优化方法。

总结（Summarization）：比如，Agent在执行了一系列网页搜索后，会产生大量的工具调用输出。我们可以让另一个模型或一个精心设计的Prompt，将这些冗长的输出总结成几句关键结论，再放回上下文中。

压缩（Compression）：将信息进行结构化、有损或无损的压缩，剔除冗余部分。

从Claude Code到OpenAI DeepResearch的众多案例中，我们都能看到这种策略的应用。例如，Claude模型在上下文达到特定比例时，会自动触发压缩机制。Cognition公司也提到了在Agent任务交接时，使用“摘要修剪”的理念，本质上也是一种上下文的“减少”。

3. 检索上下文（Retrieve Context）

核心观点

按需、精准地从外部存储中找到并调取相关信息，是构建高效Agent的核心能力之一，它与“卸载上下文”相辅相成。

详细阐述

当我们把大量上下文“卸载”到文件系统后，就需要一套高效的检索机制来确保Agent能随时找到它需要的信息。目前主流的检索方式包括：

索引（Indexing）与向量搜索（Semantic Search）：适用于大规模、非结构化数据的快速语义匹配。

文件系统（File System）与简单搜索工具：例如，通过`glob`（文件路径模式匹配）和`grep`（文本内容搜索）等命令，在代码库或日志文件中进行精准查找。

Cursor和Claude Code等知名项目都大量应用了这些技术。可以说，没有高效的检索，卸载就失去了意义。

4. 隔离上下文（Isolate Context）

核心观点

将复杂的任务分解，把不同的上下文分散到多个子智能体（Sub-agent）中。每个子智能体拥有独立的上下文窗口，实现“关注点分离”，从而提高任务处理的专注度和效率。

详细阐述

这是多智能体（Multi-agent）架构中的核心思想。当一个任务过于复杂时，让一个Agent处理所有事情会导致上下文混乱。更好的方法是进行拆分。

例如，一个主Agent负责规划，一个子Agent专门负责执行代码，另一个子Agent负责撰写报告。每个子Agent只关心自己的“一亩三分地”，拥有独立的、干净的上下文窗口。这种设计模式在Langchain的Deep Agents、Open DeepResearch以及Claude的Sub-agents中都有广泛应用。

5. 缓存上下文（Cache Context）

核心观点

这是一种巧妙的工程技巧，通过缓存重复计算的结果或上下文状态，避免资源浪费，提升系统响应速度。

详细阐述

虽然访谈中未详细展开，但“缓存”是所有复杂软件系统中通用的性能优化手段。在Agent的执行流程中，对于一些确定性的、高频的计算或工具调用，将其结果缓存起来，当再次遇到相同输入时直接返回结果，可以显著降低延迟和成本。Manus在其系统中就巧妙地运用了这一技巧。

实战案例：Langchain的Open DeepResearch项目

为了让大家更直观地理解，我们来看看Langchain的开源项目Open DeepResearch是如何协同运用这些策略的。该项目将一个深度研究任务分为三步：Scope（框定范围）、Research（执行研究）、Write（撰写报告）。

卸载（Offload）：在`Scope`阶段，Agent会先制定一份详细的研究计划纲要。这份纲要被立刻“卸载”并保存到外部文件中，而不是留在上下文中，因为它在`Research`阶段会不断被其他信息填充。当进入`Write`阶段时，这份计划纲要会被重新“检索”回来，作为撰写报告的核心指引。
减少（Reduce）：在`Research`阶段，Agent会进行多轮网页搜索和资料分析，产生大量消耗Token的观察结果。系统会运用“减少”策略，将这些冗长的搜索结果实时地总结成精炼的要点。
隔离（Isolate）：`Scope`、`Research`、`Write`这三个阶段可以由不同的子智能体负责，每个子智能体拥有独立的上下文，专注于自己的任务，互不干扰，这就是“隔离”思想的体现。

Manus深度实践：挑战与解决方案

作为AI Agent领域的领跑者，Manus对上下文工程有着更深刻的理解和更精细的实现。

1. 如何优雅地「减少上下文」？

核心观点

Manus将“减少”划分为可逆的“压缩”和谨慎的“总结”两大方向，并基于“上下文预腐烂阈值”智能触发，实现性能与信息保真度的平衡。

详细阐述

触发时机：Manus通过大量评估测试发现，模型的上下文窗口远在达到1M的上限之前（通常在128K到200K之间）就会开始“腐烂”。他们将这个“预腐烂阈值”作为触发“减少”操作的信号。

“压缩”优先，且可逆：触发后，系统首先启动“压缩”。例如，一个文件写入操作包含`路径`和`内容`两个字段，在压缩格式中，可以安全地舍弃超长的`内容`字段，仅保留`路径`。因为聪明的Agent后续可以通过路径重新读取文件，信息并未丢失，只是被外置了。这种可逆性至关重要，因为你永远不知道历史记录中的哪个细节会在未来变得关键。

谨慎“总结”，并备份：当多轮“压缩”后效果甚微时，系统才启动“总结”。但在总结前，会先将原始的、未压缩的上下文内容卸载备份到日志文件中，以便随时通过`grep`和`glob`检索恢复。同时，总结会特意保留最近几次完整的工具调用细节，以帮助模型理解中断位置，保持执行风格和语气的连贯性。

2. 如何智慧地「隔离上下文」？

核心观点

Manus完全认同Cognition的观点：不要轻易使用多智能体架构。因为信息同步是巨大挑战。他们通过“通信”模式处理简单任务，通过“共享上下文”模式处理复杂任务。

详细阐述

通过通信（Communicating）：适用于简单、独立的任务。主Agent向子Agent发送一个清晰的Prompt，子Agent的上下文仅包含该Prompt。主Agent不关心过程，只关心结果。这有点像任务外包，高效且隔离彻底。

共享上下文（Shared Context）：适用于需要完整历史记录的复杂任务（如DeepResearch）。子Agent可以看到主Agent的全部历史上下文（工具调用、观察结果等），但拥有自己独立的System Prompt和行为空间。这样做避免了让子Agent重新读取所有外部文件造成的延迟和Token浪费，但成本较高，因为无法复用KV缓存。

3. 如何彻底地「卸载上下文」？

核心观点

Manus将“卸载”思想从“数据”延伸到了“工具”本身，通过创新的三层分层动作空间，从根本上解决了“上下文混淆”问题。

详细阐述

当上下文中的工具（Function Calling）过多时，模型会感到困惑，可能调用错误的工具。Manus的解决方案是：

第一级：Function Calling：仅保留数量固定的原子级核心功能，如读写文件、执行Shell、搜索等。它们边界清晰，可组合性强。
第二级：沙箱实用工具（Sandbox Utilities）：在虚拟机沙箱中，预装大量实用程序（如格式转换器、语音识别工具）。Agent通过执行Shell命令来调用它们，完全不占用Function Calling的上下文空间。
第三级：软件包和API（Package & APIs）：对于需要大量计算或外部数据的任务（如分析全年股票数据），Agent可以在沙箱中运行Python脚本，调用各种库和API完成计算，然后仅将最终的总结结果返回到上下文中。

这套分层架构，从模型视角看，依然是标准的Function Call流程，既保持了上下文的简洁，又极大地扩展了Agent的能力，同时还对KV缓存非常友好。

融会贯通：上下文工程是一门平衡的艺术

核心观点

这五大策略并非相互独立，而是彼此关联、相互影响的系统。上下文工程的本质，就是在多重潜在冲突的目标间，寻求完美平衡的科学与艺术。

详细阐述