上下文工程的艺术与科学：来自 LangChain 和 Manus 的前沿洞察

引言：从"提示工程"到"上下文工程"

在过去的一年里，AI 领域见证了从"提示工程"（Prompt Engineering）到"上下文工程"（Context Engineering）的重大转变。正如 LangChain 的创始工程师 Lance 所指出的，提示工程随着 ChatGPT 的发布而兴起，专注于如何与聊天模型进行有效交互。然而，随着 AI 智能体（Agent）的崛起，一个新的、更为复杂的挑战浮出水面。

智能体在一个循环中自主运行，频繁调用工具，并将结果（观察）追加到其聊天记录中。这种机制会导致上下文窗口的"无限制的爆炸式增长"。Anthropic 的研究指出，生产环境中的智能体对话可能持续数百轮，而典型任务也可能需要多达 50 次工具调用。

这就是悖论所在：智能体需要大量上下文来进行工具调用和推理，但随着上下文长度的增加，模型的性能会因"上下文腐烂"（context rot）而下降。

上下文工程，这个由 Andrej Karpathy 创造的术语，正是解决这一悖论的艺术与科学。它研究的是如何用恰到好处的信息填充上下文窗口，以满足智能体下一步任务的需求。在最近的一次线上研讨会中，LangChain 的 Lance 和 Manus 的 Pete 深入探讨了这一主题，分享了从一线实践中总结的核心原则和高级技巧。

第一部分：上下文工程的核心支柱

Lance 首先概述了业界为应对上下文爆炸而总结出的五大常见主题：

上下文卸载 (Context Offloading):
- 理念： 并非所有信息都需要保留在智能体的消息历史中。
- 实践： 将消耗大量 Token 的信息（如工具输出、搜索结果）转储到上下文窗口之外的地方，如文件系统或智能体状态。智能体只接收一个轻量的引用（如文件路径），在需要时才去检索完整内容。
上下文缩减 (Context Reduction):
- 理念： 对信息进行摘要或压缩，而不是完全卸载。
- 实践： 摘要工具调用的输出，或修剪（pruning）旧的消息。例如，Claude 3.5 Sonnet 已经将修剪旧工具调用的功能内置到其 SDK 中。
上下文检索 (Context Retrieval):
- 理念： 当智能体需要信息时，如何高效地将其取回。
- 实践： 存在两种主流方法：一种是经典的 RAG，使用索引和语义搜索；另一种是更简单的方法，仅依赖文件系统和基础的搜索工具（如 glob 和 grep）。
上下文隔离 (Context Isolation):
- 理念： 通过多智能体架构实现"关注点分离"。
- 实践： 每个子智能体（sub-agent）拥有自己独立的上下文窗口，专注于特定任务。这可以防止单个智能体的上下文变得过于臃肿和混乱。
上下文缓存 (Context Caching):
- 理念： 利用 KV 缓存等技术来优化重复的上下文处理。
- 实践： 这对于降低延迟和成本至关重要，尤其是在处理长上下文时。

第二部分：来自 Manus 的高级实战经验

Manus 的联合创始人兼首席科学家 Pete 分享了他们团队在生产环境中总结的最新、甚至有些"非共识"的经验。

1. 核心哲学：为什么选择上下文工程，而非微调？

Pete 提出了一个强有力的观点：上下文工程是应用和模型之间最清晰、最实用的边界。

在 AI 的早期阶段，过早地投入资源进行模型微调（fine-tuning）或强化学习（RL）是一个陷阱。这不仅会拖慢产品迭代速度，还可能让你在基础模型一夜之间发生颠覆性变化时措手不及。例如，Manus Code Playground (MCP) 的推出彻底改变了 Manus 的设计，使其从一个固定的行为空间转变为一个几乎无限扩展的空间。如果团队之前花费数月时间在固定空间上训练模型，那么所有的努力都将付诸东流。

因此，初创公司应尽可能长时间地依赖通用模型和上下文工程。

2. 上下文缩减："压缩"与"摘要"的精细艺术

Manus 将上下文缩减分为两种截然不同的操作：

压缩 (Compaction): 一种可逆的操作。它会剥离那些可以从外部（如文件系统）重建的信息。
- 示例： 一个"写入文件"的工具调用包含 path 和 content 两个字段。在压缩格式中，可以安全地移除超长的 content 字段，只保留 path。智能体如果需要内容，可以通过路径自行检索。
- 关键： 没有任何信息真正丢失，只是被外部化了。
摘要 (Summarization): 一种不可逆的操作，会真正丢失信息。

Manus 的缩减策略：

设置"腐烂前"阈值： 不要等到模型的最大上下文限制（如 100 万 Token）才行动。通过评估确定模型性能开始下降的实际阈值（如 128k-200k Token），并将其作为触发缩减的信号。
先压缩，后摘要： 当接近阈值时，首先对最旧的 50% 工具调用进行压缩。这通常能释放足够的空间。
谨慎摘要： 只有当压缩的增益变得微乎其微时，才启动摘要。
摘要的技巧：
- 摘要时，应使用原始的完整版数据，而不是已压缩的数据。
- 始终保留最后几次的完整工具调用记录，不要摘要它们。这能让模型知道它上次停在哪里，保持工作的连续性。
- 使用结构化提示： 不要用"请帮我总结"这样的自由形式提示。而是定义一个模式（Schema） ，让 AI 像填表一样输出结构化摘要（例如：{ "modified_files": [...], "user_goal": "...", "last_action": "..." }）。这能确保输出的稳定性和完整性。

3. 上下文隔离："通信模式" vs "共享内存模式"

多智能体系统的一个核心噩梦是信息同步。Pete 借鉴了 Go 语言的名言，提出了两种截然不同的隔离模式：

通信模式 (Communicate to Share Memory):
- 类比： 经典的子智能体。
- 机制： 主智能体编写一个简短、清晰的指令，发送给子智能体。子智能体在一个全新的、隔离的上下文中执行任务，只返回最终结果。
- 适用： 任务简单明确，且主智能体不关心执行过程（例如："在代码库中搜索所有使用了 xyz API 的地方"）。
共享内存模式 (Share Memory to Communicate):
- 类比： 在 Manus 中称为"通过共享上下文"。
- 机制： 子智能体可以看到整个先前的上下文历史，但它被赋予了自己专属的系统提示和行为空间（工具集）。
- 适用： 复杂的、依赖大量历史信息的任务（例如：撰写深度研究报告，需要参考所有中间的搜索和笔记）。
- 权衡： 成本更高（每个子智能体都需要预填充大量上下文）且无法重用 KV 缓存。

Pete 还强调，Manus 避免了按人类组织架构（如"设计师智能体"、"程序员智能体"）来划分智能体，因为这种划分源于人类的局限性。相反，Manus 的系统由少数几个核心智能体组成：一个庞大的通用执行器 、一个规划器 和一个知识管理器。

4. 上下文卸载：革命性的"分层式行为空间"

这是 Manus 最具创新性的见解之一。当工具数量过多时，工具定义本身就会塞满上下文，导致"上下文混淆"，并频繁破坏 KV 缓存。

Manus 的解决方案是卸载工具本身，将其划分为三个层次：

第一层：函数调用 (Atomic Functions)
- 内容： 10-20 个固定的、原子的函数，如 read_file, write_file, shell_exec, search, browser_op。
- 优势： 数量固定，对缓存友好。模型天生擅长组合这些原子操作。
第二层：沙盒工具 (Sandbox Utilities)
- 内容： 预装在 Manus 虚拟机沙盒（一个定制的 Linux 系统）中的大量命令行工具（如格式转换器、语音识别工具等）。
- 访问： 智能体通过调用第一层 的 shell_exec 函数来使用它们。
- 优势： 可以在不修改第一层（不破坏缓存）的情况下无限扩展新功能。模型可以通过运行 tool_name --help 来自主学习如何使用新工具。
第三层：软件包与 API (Packages & APIs)
- 内容： 通过编写和执行 Python 脚本来调用各种第三方 API（如金融数据）或复杂的本地库（如 3D 建模）。
- 访问： 智能体通过第一层 的 write_file（写入脚本）和 shell_exec（运行脚本）来使用它们。
- 优势： 极其强大的可组合性。非常适合需要大量内存计算的任务（如分析全年股票数据），智能体只将最终的摘要结果返回到上下文中。

这个三层架构的精妙之处在于，从模型的角度来看，所有三个层次最终都通过第一层的少数几个原子函数来执行。这保持了接口的绝对简洁、对缓存极其友好，同时提供了几乎无限的行为空间。

结论：少做加法，多做理解

在研讨会的最后，Pete 分享了一个与直觉相反的深刻感悟：请避免上下文过度工程（context over-engineering）。

回顾 Manus 的发展，最大的性能飞跃并非来自增加了更多巧妙的上下文管理技巧，而是来自简化------来自移除不必要的技巧，以及每一次都对模型多一点信任。

上下文工程的目标是让模型的工作变得更简单，而不是更难。正如 Pete 所说："如果今天你只能从我的分享中带走一件事，我希望是：少做加法，多做理解（build less and understand more） 。"

随着模型变得越来越强大，我们的许多辅助性结构（scaffolding）都可以被移除。一个真正具有未来适应性（future-proof）的智能体架构，是那种当你把模型从一个弱版本切换到一个强版本时，性能能获得巨大提升的架构。

上下文工程的未来，在于如何在卸载、缩减、检索和隔离之间找到那个微妙的平衡点，构建一个既能赋能模型、又不对其造成负担的简洁工作空间。