最近仔细看了 LangChain 的 Lance 和 Manus 的 Pete 的视频，主题是构建 AI 智能体中的上下文工程。这次分享没有那些空泛的理论，全是在生产环境中验证过的实战经验。

我结合自己的思考，整理了我认为 5 个最有价值的技术要点，每一个都直接影响着智能体的性能和可用性。

1. 上下文爆炸是智能体最大的瓶颈

Manus 统计显示，一个典型的智能体任务需要约 50 次工具调用。Anthropic 也提到，生产环境中的智能体对话可能持续数百轮。每次工具调用都会返回结果，这些结果会不断累积在消息历史中。

问题在于，随着上下文长度增加，模型性能会明显下降。Anthropic 把这个现象称为”上下文腐烂”（context rot）。具体表现是模型开始重复输出、推理速度变慢、回答质量下降。大部分模型在 200k Token 左右就开始出现这些问题，远低于它们宣称的上限。

这就形成了一个矛盾：智能体需要大量上下文来保持工作状态的连续性，但上下文太长又会导致性能下降。这是所有开发智能体的团队都会遇到的核心挑战。

Lance 在分享中展示了他们 Open Deep Research 项目的数据。这个开源项目在 Deep Research Bench 测试中排名前十，但即使是这样优秀的实现，也需要在三个阶段中不断地卸载和压缩上下文才能保持高效运行。

Pete 则分享了 Manus 的经验。他们发现，如果不做任何优化，上下文会在几十轮对话后就达到模型的处理极限。更糟糕的是，用户往往在这时才开始进入任务的核心部分。

解决这个问题没有捷径，必须从架构设计开始就考虑上下文管理。这也是为什么”上下文工程”这个概念在今年 5 月开始迅速流行的原因。它不是可选的优化项，而是构建生产级智能体的必要条件。

2. 上下文工程的五大组成部分

Lance 和 Pete 在分享中系统地总结了上下文工程的五个核心组成部分，这些部分相互关联，形成了一个完整的技术体系。

上下文卸载 是把部分信息移出主消息历史，存储到外部系统中。最常见的是使用文件系统。当搜索工具返回大量结果时，不是把完整内容放在消息队列里，而是写入文件，只在上下文中保留文件路径。Claude Code、Manus、Open Deep Research 项目都大量使用这种方法。

上下文缩减 包括压缩和摘要两种策略。压缩是去掉可以从外部重建的信息，摘要是对信息进行不可逆的精简。Claude 3.5 Sonnet 已经内置了修剪旧工具调用的功能。Cognition 在智能体交接时也会触发摘要。

上下文检索 解决如何按需获取被卸载的信息。有两派做法：Cursor 使用索引加语义搜索，Claude Code 和 Manus 只用文件系统加 grep、glob 这样的简单工具。两种方法各有优劣，选择哪种取决于具体场景。

上下文隔离 通过多智能体架构实现关注点分离。每个子智能体有自己的上下文窗口，避免信息混杂。Manus 的 Wide Agents、LangChain 的 Deep Agents、Claude 的多智能体研究员都采用了这种设计。

上下文缓存 利用 KV 缓存等机制减少重复计算。Anthropic 等服务商提供的缓存功能对长上下文智能体至关重要，特别是在输入远长于输出的场景下。

这五个部分不是独立的，而是相互影响的系统。卸载和检索让缩减更高效，稳定的检索让隔离变得安全。但隔离会减慢上下文传递，降低缩减频率。更多的隔离和缩减又会影响缓存效率。

Pete 特别强调，这种相互依赖意味着你不能只优化某一个方面，必须从整体考虑。比如，如果你的检索机制不够稳定，就不能激进地进行上下文隔离，否则子智能体可能无法获取必要的信息。

3. 上下文管理和数据库系统的对比

在分享中我个人的感觉是上下文工程的设计和数据库系统设计有比较多的相似性。

上下文卸载和数据库索引有很多相似之处，但它们的设计目标和实现机制存在本质差异。

展开来讲：相似性是都是为了解决容量与性能的矛盾

数据库索引解决的是「如何在海量数据中快速定位」的问题，而上下文卸载解决的是「如何在有限窗口中访问无限信息」的问题。两者都是通过建立某种间接引用机制，让系统能够处理超出直接处理能力的数据量。

数据库有内存中的索引页、磁盘上的索引文件、以及实际的数据页。上下文工程也有类似的层次：活跃上下文（相当于内存中的热数据）、文件路径引用（相当于索引）、文件系统中的完整内容（相当于磁盘数据）。

数据库索引针对不同的查询模式有不同类型：B 树索引适合范围查询，哈希索引适合等值查询，全文索引适合文本搜索。上下文卸载也有类似的分类：代码文件用路径索引，搜索结果用语义向量索引，对话历史用时间戳索引。

数据库的 buffer pool 会缓存频繁访问的索引页和数据页。上下文工程中的 KV 缓存也会保留频繁引用的上下文片段。两者都使用 LRU 或类似算法决定淘汰策略。

关键差异：索引是查询优化，卸载是容量管理

数据库索引的主要目标是加速查询，即使没有索引，全表扫描也能得到结果，只是慢一些。而上下文卸载是为了突破硬性限制，没有卸载机制，超出窗口的信息就完全无法访问。这是「优化」与「必需」的区别。

数据库索引是冗余信息，删除索引不会丢失数据，只会影响查询性能。但上下文卸载中，如果文件系统中的内容丢失，而上下文中只有路径引用，信息就永久丢失了。这就是为什么 Pete 强调卸载必须配合可靠的检索机制。

数据库索引需要随数据更新而维护，这是 ACID 事务的一部分。而上下文卸载通常是单向的：信息从上下文移到外部存储，很少需要反向更新。即使文件内容被修改，上下文中的引用通常保持不变。

数据库可以选择性地为某些列建立索引，基于查询模式和数据分布做决策。而上下文卸载往往是强制的：当接近 Token 限制时，必须卸载某些内容，没有”不建索引”的选项。

就像数据库有内存、磁盘、缓存的层次结构，上下文工程也有类似的分层：活跃上下文（内存）、文件系统（磁盘）、KV 缓存（缓存层）。数据库的查询优化对应着上下文检索，事务隔离对应着智能体隔离，数据压缩对应着上下文压缩。

Pete 提到的”通过通信”和”通过共享内存”两种模式，实际上对应着数据库中的消息传递和共享存储两种架构。当子智能体需要完整历史记录时，使用共享上下文模式，这就像数据库中的共享存储架构。当任务相对独立时，使用通信模式，类似于分布式数据库的消息传递。

智能体间的状态同步问题，本质上就是分布式系统的一致性问题。

Manus 的解决方案也借鉴了数据库的设计思想。他们使用结构化的模式（schema）来定义智能体间的通信接口，确保数据的一致性。他们的分层行为空间设计（函数调用、沙盒工具、软件包与API）类似于数据库的存储引擎分层。

这种类比不仅仅是理论上的相似。在实践中，你可以直接应用数据库系统的很多优化技术。比如，使用 LRU 策略决定哪些上下文应该被压缩或摘要；使用预写日志（WAL）的思想，在摘要前先把完整上下文写入日志文件；使用索引来加速文件系统中的信息检索。

我们可以借鉴数据库领域几十年的研究成果和工程实践，而不是从零开始摸索。

3. 上下文工程的核心是做减法，而不是加法

Pete 在分享最后强调的这一点可能是最重要的：避免上下文过度工程（context over-engineering）。

他提到，Manus 上线六七个月以来，最大的性能提升不是来自增加更复杂的上下文管理机制，而是来自简化架构、移除不必要的功能、对模型给予更多信任。他们已经重构了 Manus 五次，每次都是在做减法。

比如，早期的 Manus 使用 todo.md 文件来管理任务列表，结果发现约三分之一的操作都在更新这个列表，浪费了大量 Token。后来他们改用更简单的结构化规划器，效果反而更好。

另一个例子是工具选择。他们没有使用复杂的语义搜索来动态加载工具，而是固定使用 10-20 个原子功能，其他所有功能都通过沙盒中的命令行工具或 Python 脚本来实现。这种分层的行为空间设计，让系统既灵活又简单。

Pete 还提到了一个评估架构的方法：在强弱模型之间切换测试。如果你的架构从弱模型切换到强模型后能获得明显提升，说明架构有较好的未来适应性。因为明年的弱模型可能就和今天的强模型一样好。

关于是否要训练专门的模型，Pete 的观点也很明确：初创公司应该尽可能长时间地依赖通用模型和上下文工程。训练专门模型不仅成本高，而且在产品快速迭代的阶段，很可能在优化错误的指标。MCP（Model Context Protocol）的推出就是个例子，它彻底改变了 Manus 的设计，如果之前投入大量资源训练专门模型，这些投入就浪费了。

他们现在也不使用开源模型，不是因为质量问题，而是成本问题。对于输入远长于输出的智能体应用，KV 缓存至关重要。大型云服务商有更好的分布式缓存基础设施，算下来使用他们的 API 反而更便宜。

这些经验告诉我们：上下文工程的目标是让模型的工作变得更简单，而不是更复杂。不要为了优化而优化，每个设计决策都要基于实际的性能数据和用户反馈。

4. 压缩与摘要的本质区别决定了使用策略

Pete 详细解释了压缩和摘要这两种看似相似实则截然不同的策略，这个区分对实际应用至关重要。

压缩是可逆的。在 Manus 中，每个工具调用都有完整格式和紧凑格式。比如写文件操作，完整格式包含路径和内容，紧凑格式只保留路径。因为文件已经存在于文件系统中，通过路径可以随时恢复完整信息。这种可逆性至关重要，因为你永远不知道哪个历史操作会在后续变得重要。

摘要是不可逆的。一旦执行摘要，原始信息就永久丢失了。因此必须非常谨慎。Manus 的做法是在摘要前将完整上下文转储为日志文件，作为最后的保险。而且摘要时要保留最新几次工具调用的完整信息，让模型知道当前的工作状态。

关于阈值的确定，Pete 分享了具体数据：大多数模型在 200k Token 左右开始出现性能下降，他们将 128k-200k 设定为”腐烂前”阈值。这不是随意设定的，而是通过大量评估得出的。他们测试了不同长度下模型的重复率、推理速度、输出质量等指标。

触发策略是渐进式的：

• 接近 128k 时，开始压缩最旧的 50% 工具调用
• 压缩后检查实际释放的空间
• 如果压缩效果不明显（因为即使紧凑格式也占用空间），才考虑摘要
• 摘要时使用完整版本而非压缩版本的数据
• 始终保留最新的几次完整工具调用

尽可能保留信息的完整性，只在必要时才接受信息损失。这就像数据压缩算法中的无损压缩和有损压缩，你总是先尝试无损方案。

不同类型的内容有不同的压缩潜力。搜索结果、API 响应这类内容压缩效果好，因为大部分信息可以通过查询重新获取。而用户的指令、模型的推理过程压缩空间有限，因为这些信息往往都是必要的。

5. 隔离策略的选择取决于任务特性而非直觉

多智能体隔离是个老话题，但 Pete 分享的经验推翻了很多常见做法。

首先是反模式的识别。很多团队喜欢按人类角色划分智能体：设计师智能体、程序员智能体、经理智能体等。Pete 明确指出这是个陷阱。这种划分源于人类组织的局限性（个人能力和注意力有限），而不是 AI 系统的最优设计。Manus 只有极少的几个功能性智能体：通用执行器、规划器、知识管理器。

关于隔离模式的选择，Pete 区分了两种场景：

通信模式适合结果导向的独立任务。主智能体发送明确指令，子智能体独立完成，返回结果。整个过程主智能体不关心细节，只要最终输出。比如”在代码库中搜索特定函数”、”将这段文本翻译成中文”。这种模式的优势是上下文干净、成本低、易于调试。

共享上下文模式适合需要完整历史信息的复杂任务。子智能体能看到所有历史对话和工具调用，但有自己的系统提示和工具集。比如深度研究任务，最终报告需要参考大量中间搜索和笔记。这种模式成本高（需要预填充大量上下文，无法复用 KV 缓存），但对某些任务是必要的。

判断使用哪种模式的关键是从结果推理过程的依赖性。如果最终输出强依赖于中间步骤的细节，就需要共享上下文。如果只需要最终结果，通信模式就足够了。

Pete 还提到了一个实用技巧：”智能体即工具”（agent as tool）。从主智能体视角，调用子智能体就像调用普通工具，有明确的输入输出接口。这简化了系统设计，也让调试更容易。Manus 的”高级搜索”功能就是这样实现的，表面上是个工具，实际是个完整的子智能体工作流。

他们解决通信问题的方法是强制使用结构化输出。主智能体调用子智能体前必须定义输出模式，子智能体通过专门的”提交结果”工具返回数据，系统用约束解码确保格式正确。这避免了自由格式通信带来的解析问题和信息丢失。

6. 一些额外的技术洞察

除了这五个核心经验，还有一些值得记录的技术细节。

信息的局部性。使用基于行的格式意味着每行都是独立的信息单元，读取第 100 行不需要解析前 99 行。这对于大文件的随机访问至关重要。

结构化不等于复杂格式。Pete 强调，他们优先使用基于行（line-based）的纯文本格式，而不是 JSON 或 XML。原因很简单：模型可以用 grep 搜索特定行，用 sed 修改特定内容，用 head/tail 读取部分数据。这些都是模型已经掌握的基础工具。

关于 Markdown 的使用要特别谨慎。虽然模型都接受过 Markdown 训练，但过度使用会带来副作用。某些模型会因此输出过多的项目符号和格式化标记，浪费 Token 还影响可读性。Manus 的经验是：在需要结构时用 Markdown，在存储数据时用纯文本。

关于模型切换的评估方法。Pete 提到，他们会在强弱模型间切换来评估架构的未来适应性。如果一个架构在弱模型上也能工作（虽然效果差一些），说明它不是过度依赖特定模型能力的脆弱设计。

关于工具数量的上限，他们的经验是不超过 30 个。这不是任意数字，而是基于大量测试。超过这个数量，模型开始频繁调用错误的工具，甚至调用不存在的工具。解决方案不是动态加载工具，而是设计分层的行为空间：少量原子工具 + 沙盒命令 + 代码执行。

关于评估体系，Manus 的三层评估值得借鉴：用户评分是北极星指标，自动化测试覆盖可验证的任务，真人评估处理主观性强的输出。学术基准测试只是参考，不能作为主要依据。

上下文工程不是一些零散的技巧，而是一个需要系统思考的工程领域。每个设计决策都会影响到其他部分，没有放之四海而皆准的最佳实践，只有基于具体场景的权衡取舍。

以上。