前几天我写了一篇文章分享了Anthropic 上下文工程最佳实践，这篇文章分享达到了1109次，感觉大家对Context Engineering还是很感兴趣的，今天这篇文章更深入和细节一些，LangChain 的创始工程师 Lance Martin 和 Manus 的联合创始人 Yichao "Peak" Ji（季逸超《麻省理工科技评论》评选的 2025 年 35 岁以下创新者之一） 深入探讨了上下文工程，分享了他们在生产环境中管理上下文窗口、优化性能和构建可扩展代理的实战策略

核心论点是，随着 AI Agents 执行日益复杂的长期任务，其上下文窗口会因大量的工具调用而急剧膨胀，导致性能下降。因此，有效的上下文工程，即通过 offloading（卸载）、reduction（精简）、retrieval（检索）、isolation（隔离）和 caching（缓存）等一系列技术，将“恰到好处的信息”填入上下文窗口，是构建高效、稳定和智能代理的决定性因素。最终结论强调，优秀的上下文工程不仅是技术组合，更是一种“少即是多”的哲学，即通过简化架构、信任模型，而非过度工程化，才能实现代理性能的最大飞跃

强烈建议大家围观

上下文工程的兴起：为何它对 AI 代理至关重要

在人工智能领域，我们见证了一个重要的范式转变。随着 ChatGPT 的问世，Prompt Engineering（提示工程）在 2022 年底应运而生，成为与聊天模型交互的核心学科。然而，进入 2023 年，一个新的、更为关键的领域——Context Engineering（上下文工程）开始崭露头角

与简单的聊天机器人不同，AI Agents 的核心特征在于它们能够自主地、循环地调用一系列工具来完成复杂任务。这个过程带来了一个独特的挑战：上下文的无界爆炸

工作机制：一个 Agent 通常绑定了一个或多个工具。每当 Agent 调用一个工具，它会收到一个工具的观测结果，这个结果会作为一个新的消息被追加到对话历史中

规模问题：根据 Manus 的实践经验，一个典型的任务可能需要大约 50 次工具调用。而 Anthropic 的研究也指出，生产环境中的代理可能会进行长达数百轮的对话

性能悖论：这种工具的自由使用，导致了上下文信息的快速累积。然而，正如 Chrome 团队在一份关于“上下文腐烂 (context rot)”的报告中指出的，随着上下文长度的增加，模型的性能会显著下降

这就形成了一个核心矛盾：Agents 的强大功能依赖于利用大量上下文信息，但模型的性能却会因为上下文过长而受损

正是为了解决这个挑战，Context Engineering（上下文工程）的概念应运而生。Andrej Karpathy 将其精辟地定义为：一门将恰到好处的信息在下一步需要时填入上下文窗口的精妙艺术与科学。它的目标是抑制在 Agents 运行过程中因工具调用而产生的上下文爆炸，确保在任务的每一步，Agent 都能接收到做出正确决策所需的核心信息，不多也不少

为了实现这一目标，行业内涌现出了一系列共通的主题和策略，构成了上下文工程的支柱：

1.Context Offloading (上下文卸载)：将信息从核心的对话历史中移出，存放到外部系统（如文件系统），只在上下文中保留一个轻量级的引用

2.Reducing Context (上下文精简)：通过总结或压缩来减少信息量，例如修剪旧的工具调用记录

3.Retrieving Context (上下文检索)：在需要时，按需从外部系统将信息取回。实现方式包括基于索引的语义搜索，或更简单的基于文件系统的搜索工具（如 glob 和 grep）

4.Context Isolation (上下文隔离)：通过将任务分解给多个子代理（sub-agents），每个子代理拥有自己独立的、更小的上下文窗口，从而实现关注点分离和上下文管理

5.Caching Context (上下文缓存)：对上下文信息进行缓存，以提高效率（这一点在 Manus 的实践中被特别提及）

这些策略并非孤立存在，而是相互关联、协同工作，共同构成了现代 AI Agents 架构的基石

战略抉择：优先上下文工程，而非过早模型专业化

在深入探讨上下文工程的具体技术之前，一个更根本的问题值得思考：我们为什么需要它？尤其是在模型微调和后训练技术日益普及的今天。Manus 的联合创始人 Peak Ji 分享了他从多年实践中得出的深刻见解，认为上下文工程是应用层和模型层之间最清晰、最实用的边界

在创办 Manus 之前，Peak 拥有超过十年的自然语言处理经验，他的上一个创业项目就是从零开始训练自己的语言模型。这段经历让他痛苦地认识到，过早地构建专用模型会带来巨大风险：

扼杀创新速度：产品的迭代速度完全被模型的迭代速度所限制。一个训练加评估的周期可能需要一到两周，这对于需要快速验证产品市场契合度的初创公司是致命的

优化目标错位：在产品方向尚未完全明朗时，团队可能会花费大量时间去提升一些对产品价值可能毫无意义的基准测试分数

因此，初创公司应该尽可能长时间地依赖通用模型和上下文工程。然而，随着产品成熟和开源基础模型的崛起，另一个陷阱也随之出现：用自有数据微调一个强大的基础模型，使其在特定用例上表现出色

Peak 指出这同样是危险的，因为强化学习通常需要固定一个行动空间，并围绕当前的产品行为设计奖励函数。但这在 AI 和 Agents 的早期阶段是极其脆弱的，因为底层技术可能一夜之间发生颠覆

一个典型的例子**：MCP的发布，彻底改变了 Manus 的设计，使其从一个紧凑、静态的行动空间，转变为一个几乎无限可扩展的系统。如果你已经训练了自己的模型，你会知道这种开放域问题极难优化

避免重复造轮子：虽然可以投入巨大努力进行后训练以确保模型的泛化能力，但这无异于在尝试成为一家语言模型公司，重复了基础模型公司已经完成的工作

综上所述，Peak 的核心观点是：要坚定地划清界限。在当前阶段，上下文工程为应用开发者提供了一个强大的杠杆，可以在不触碰底层模型训练的情况下，极大地影响和提升 Agent 的性能。它允许应用层保持灵活性和快速迭代的能力，同时充分利用日益强大的通用模型。因此，与其过早地投入到模型专业化的深渊，不如精通上下文工程这门艺术

上下文精简：压缩与总结

上下文精简是上下文工程的核心技术之一，但它并非一个单一的操作。Manus 在实践中将其细分为两种截然不同但相辅相成的方法：Compaction (压缩)和 Summarization (总结)，并建立了一套严谨的工作流程来协同使用它们

压缩 (Compaction)：一种可逆的信息外化

压缩的核心思想是一种可逆的信息缩减。它并非真正地“减少”信息，而是将信息的一部分外化（externalized）到上下文窗口之外的某个地方（如文件系统或外部状态），同时在上下文中保留足以重建完整信息的线索

工作原理：在 Manus 中，每一次工具调用和其结果都有两种格式：完整格式和紧凑格式。紧凑版本会剥离掉所有可以从外部环境中重建的信息

具体例子：假设一个工具的功能是向文件中写入内容，它可能包含两个字段：path (路径) 和 content (内容)。一旦这个工具执行成功，我们就可以确定该文件已经存在于环境中。因此，在紧凑格式中，可以安全地丢弃可能非常长的 content 字段，只保留 path。如果 Agent 后续需要再次读取该文件，它可以通过 path 轻松地检索到全部内容

为何可逆性至关重要：Agents 的决策是链式的，基于之前的行动和观察。我们永远无法预知过去的哪个动作会在十步之后突然变得至关重要。可逆的压缩确保了没有任何信息被真正丢失，只是被暂时移出了即时上下文

总结 (Summarization)：一种不可逆的谨慎精炼

当仅靠压缩已无法将上下文大小控制在阈值以下时，就需要动用更传统的总结方法。总结是不可逆的，意味着信息会有损失，因此必须非常谨慎地使用

执行时机：总结是最后的手段，只有在多轮压缩后，上下文长度仍然接近性能“腐烂”的临界点时才会触发

操作前的准备：在进行总结之前，一个最佳实践是先将上下文中的关键部分卸载到文件中。在更激进的情况下，甚至可以将整个待总结的上下文（pre-summary context）作为一个文本或日志文件转储到 file system 中。这样，即使总结丢失了细节，Agent 仍然有可能通过文件搜索（如 glob 或 grep）来恢复原始信息

总结的艺术：在 Q&A 环节中，Peak 补充了一个关键技巧来提升总结质量：不要使用自由格式的提示。相反，应该定义一个结构化的模式（schema）或表单，让模型去填充字段，例如“我修改了哪些文件”、“用户的目标是什么”、“我上次进行到哪一步”。这种结构化的输出比自由生成的文本更稳定、更可控，也更容易保证关键信息不被遗漏

一套基于阈值的工作流程

为了让压缩和总结能够和谐共存，Manus 设计了一套基于多层上下文长度阈值的自动化流程：

1.确定阈值：

硬性限制 ：模型支持的最大上下文长度，例如 100 万 token

预腐烂阈值：模型性能开始显著下降的实际阈值。这需要通过大量评估来确定，通常在 128K 到 200K token 之间。当模型开始出现重复、推理变慢、质量下降等“上下文腐烂”现象时，就接近这个阈值了

2.触发压缩：当上下文大小接近“预腐烂阈值”时，系统会首先触发压缩操作。这个操作不是全局性的，而是有选择性的。例如，可以只压缩历史记录中最旧的 50% 的工具调用，同时保持最近的调用记录为完整格式。这样做的好处是，模型仍然可以看到新鲜的、完整的工具使用范例（few-shot examples），从而避免模仿紧凑格式输出不完整的指令

3.评估增益并触发总结：压缩后，系统会检查获得了多少空闲的上下文空间。如果在多轮压缩后，每次的增益都变得微乎其微，这意味着上下文即使在紧凑形态下也已非常庞大。此时，系统才会触发总结操作

4.执行总结：进行总结时，应使用未经压缩的完整版数据作为输入，以确保总结的质量。同时，与压缩类似，始终保留最后几次的工具调用和结果为完整细节，不进行总结。这能帮助模型清晰地知道它在哪个节点被打断，从而更平滑地继续任务，避免因总结导致的行为或风格突变

通过这套精细的流程，Manus 在最大化信息保留和控制上下文成本之间取得了微妙的平衡

管理Agent复杂性：上下文隔离的两种模式

当任务变得异常复杂时，单一 Agent 的上下文管理压力会变得巨大。此时，将任务分解给多个子代理（sub-agents）的上下文隔离策略就显得尤为重要。Cognition AI 在他们的博客中曾警示过多代理设置的风险，因为在它们之间同步信息可能成为一场噩梦。然而，这并非一个新问题，它与计算机科学早期多进程/多线程协调的挑战异曲同工

Peak Ji 借鉴了 Go 语言社区的一句名言来阐释解决这个问题的两种核心模式：Do not communicate by sharing memory; instead, share memory by communicating. (不要通过共享内存来通信；相反，通过通信来共享内存。)

将这里的“内存 (memory)”类比为 AI Agents 的“上下文 (context)”，我们可以得到两种截然不同的多代理协作模式：

模式一：通过通信 (By Communicating)

这是最经典、最直观的子代理设置。它适用于那些可以被清晰地分解和委派的任务。

工作流程：

1.主代理（main agent）将一个任务封装成一个清晰、自包含的指令，就像一个函数调用

2.这个指令被发送给一个子代理

3.子代理的上下文窗口是干净的，几乎只包含来自主代理的这条指令。它在自己独立的上下文中完成任务

4.子代理将最终结果返回给主代理

适用场景：当任务指令简短明确，且主代理只关心最终产出，不关心实现过程时，这种模式是最佳选择

例子：在一个代码库中搜索特定的代码片段。主代理只需要告诉子代理“找到包含函数 xyz 的文件”，它不关心子代理是用了 grep 还是其他方法，只需要最终的文件路径和代码内容。Claude Code 的 task 工具就是这种模式的典型应用

优点：简单、隔离性好、上下文开销小

模式二：通过共享上下文 (By Sharing Context)

与前一种模式相反，这种模式适用于那些子任务严重依赖整体历史背景的复杂场景。

工作流程：

1.子代理能够看到主代理完整的、之前的全部上下文历史，包括所有的工具使用记录和观察结果

2.但是，这个子代理拥有自己独特的系统提示和行动空间 。它是在共享的背景知识上，以一个新的“身份”或“能力集”来执行任务

适用场景：当任务的最终产出质量取决于对大量中间过程和发现的理解时，共享上下文是更高效的选择

例子：进行一项深度研究（deep research）并撰写报告。最终的报告质量依赖于所有中间的搜索、笔记和分析。如果使用“通信”模式，主代理需要将所有这些中间产物打包成文件，再让子代理去读取和理解，这会浪费大量的延迟和 token。而共享上下文模式则让子代理直接拥有完整的历史视图

成本与权衡：这种模式的成本更高

预填充成本：每个子代理都需要处理一个非常大的输入上下文，这会消耗更多的输入 token

KV 缓存失效：由于每个子代理的系统提示和行动空间都不同，无法复用之前的 KV 缓存，这意味着每次切换到子代理都需要支付全额的计算成本

在 Q&A 环节，Peak 进一步阐述了 Manus 如何在实践中实现这两种模式，尤其是 agent 间的通信：

共享沙箱作为媒介：Manus 的每个会话都运行在一个独立的虚拟机沙箱中。主代理和子代理可以共享同一个沙箱。因此，信息传递可以通过共享文件系统来完成，主代理只需传递文件路径即可

Schema 作为合约：为了解决子代理输出格式不统一的问题，Manus 采用了一种“合约”机制。当主代理要启动一个或多个子代理时，它会首先定义一个输出模式 (output schema)。子代理则有一个特殊的工具叫做 submit_result，通过约束解码技术，确保子代理提交回主代理的结果严格符合主代理预先定义的模式。这就像一个 MapReduce 操作，最终会生成一个格式规整的“电子表格”

通过这两种模式的灵活运用，可以在保持任务隔离性的同时，高效地处理不同依赖度的复杂协作任务。

超越数据：通过分层行动空间卸载工具

上下文卸载（Context Offloading）通常被理解为将工作数据（如文件内容、搜索结果）移出上下文窗口。然而，随着 Agent 系统变得越来越复杂，尤其是在集成了像 MCP 这样的可扩展工具系统后，一个新问题浮现了：工具本身也成为了上下文的主要消耗者

当上下文中存在过多的工具定义时，会导致“上下文混淆 (context confusion)”，模型可能会调用错误的工具，甚至是根本不存在的工具。一个常见的解决方案是根据当前任务动态地对工具描述进行 RAG（检索增强生成），按需加载工具。但这种方法存在两个弊端：

1.破坏 KV 缓存：工具定义通常位于上下文的开头。每次更换工具集，都意味着 KV 缓存失效，增加了计算成本

2.误导模型：即使某个工具被移除了，模型在历史记录中仍然能看到对该工具的过往调用。这可能会误导模型去调用一个当前无效的工具或使用错误的参数

为了解决这个问题，Manus 创新性地设计了一种分层的行动空间 (Layered Action Space)。这种架构将 Agent 的能力分解为三个抽象层次，从模型的视角看，所有操作最终都归结为少数几个核心函数调用，从而实现了极高的稳定性和可扩展性

第一层：函数调用 (Function Calling)

这是最底层、最核心的一层，也是与模型直接交互的接口。

特点：

原子性与固定性：只包含一小组（在 Manus 中约 10-20 个）固定的、原子性的函数。例如：读写文件 (read/write file)、执行 Shell 命令 (execute shell command)、搜索文件和互联网 (search)，以及一些浏览器操作

模式安全：得益于约束解码，函数调用的格式和参数是严格受控的

缓存友好：由于这个函数列表是固定的，KV 缓存可以被长期保持和复用

作用：这些原子函数边界清晰，并且可以组合起来完成更复杂的工作流。它们是所有上层能力的基础

第二层：沙箱工具集 (Sandbox Utilities)

这一层将大量的功能从函数调用层卸载到了 Agent 所在的虚拟机沙箱环境中。

特点：

预装命令行工具：Manus 在其定制的 Linux 系统中预装了大量为 Agent 开发的命令行工具。例如，格式转换器、语音识别工具，甚至一个特殊的 MCP CLI（用于调用 MCP 功能的命令行接口）

通过 Shell 调用：Agent 不是通过新的函数来使用这些工具，而是通过第一层的 execute_shell_command 函数来运行它们

优势：

无限扩展：可以在不修改模型函数调用空间（action space）的情况下，不断增加新的能力

符合模型心智：对于熟悉 Linux 的模型来说，通过 ls /usr/bin 发现新工具，或者通过 tool_name --help 查看用法，是一种非常自然的行为

处理大数据：这些命令行工具可以处理非常大的输出，它们可以将结果写入文件，或进行分页返回，Agent 可以使用 grep, cat, less 等标准 Linux 工具来处理这些结果

第三层：软件包与 API (Packages & APIs)

这是最高层的抽象，Agent 通过编写和执行代码来与外部世界进行更复杂的交互。

特点：

编写脚本：Agent 可以编写 Python 脚本来调用预授权的第三方 API 或自定义的软件包。例如，使用一个 3D 设计库进行建模，或调用一个金融 API 获取市场数据

通过文件和 Shell 执行：Agent 使用第一层的 write_file 函数创建脚本，然后使用 execute_shell_command 函数来运行它

优势：

处理内存密集型计算：非常适合需要大量计算但又不需要将所有中间数据都塞入模型上下文的任务。例如，分析一只股票一整年的价格数据，脚本可以在运行时内存中完成计算，只将最终的总结（如平均值、波动率）返回给模型

高组合性：代码和 API 本身具有极强的组合性，可以在一个步骤内完成一系列复杂的操作，这与 CodeAct 等研究论文的思想不谋而合

通过这个三层架构，Manus 巧妙地解决了工具过载的问题。从模型的角度来看，无论它是在使用一个沙箱工具，还是在调用一个复杂的 API，最终都只是在调用那几个固定的、底层的原子函数。这使得接口保持了极度的简洁、缓存友好和正交性，为构建一个既强大又稳定的通用 Agent 奠定了基础

统领全局的设计哲学与一线实战

在分享了所有精妙的技术细节之后，Peak Ji 提出了一个或许是本次分享中最重要的观点，它看似与之前所说的背道而驰：请避免上下文过度工程化 (context over-engineering)。

他回顾了 Manus 发布以来的发展历程，发现那些带来最大性能飞跃的时刻，并非来自增加了更花哨的上下文管理层或更聪明的检索技巧，而是来自简化——来自移除不必要的技巧，并给予模型多一点信任。每一次简化架构，系统都会变得更快、更稳定、也更智能

这引出了一条核心的设计哲学：上下文工程的目标是让模型的工作变得更简单，而不是更复杂。构建得更少，理解得更多 (Build less, understand more)。

在最后的 Q&A 环节，这一哲学思想通过一系列具体的实践经验得到了进一步的印证，这些来自一线的智慧为构建高效 Agents 提供了宝贵的参考：

关于评测：

用户反馈是黄金标准：对 Manus 而言，最重要的评测指标是每次会话结束后用户给出的 1-5 星评分

内部自动化测试为辅：他们创建了自有数据集，包含可验证结果的执行型任务，弥补了现有公开基准测试大多为只读任务的不足

人类评估不可或缺：对于网站生成、数据可视化这类难以用自动化指标衡量的、涉及“品味”的任务，必须依赖大量的人类实习生进行主观评估。公开的学术基准（如 GAIA）可能与真实用户需求严重脱节

关于模型选择与架构设计：

优先选择旗舰模型：尽管开源模型看似成本更低，但对于输入远长于输出的 Agent 任务，KV 缓存至关重要。旗舰模型提供商拥有更成熟的分布式 KV 缓存基础设施，在规模化部署时可能反而更具成本效益

利用模型差异进行路由：不同的顶尖模型各有千秋（例如 Claude 擅长编码，Gemini 擅长多模态）。应用层的优势在于无需绑定单一模型，可以进行任务级甚至步骤级的智能路由

测试架构的“未来兼容性”：一个好的 Agent 架构，应该在从一个较弱模型切换到一个较强模型时，性能有显著提升。这种测试可以作为架构是否“未来兼容”的早期信号

关于 Agent 设计：

避免角色拟人化：不要强行将人类的组织架构（如设计师、程序员、经理）套用在 Agent 设计上。这种分工是人类上下文限制的产物

采用功能性划分：Manus 的多代理系统并非按角色划分，而是按功能。只有少数几个核心 Agent，如一个通用的“执行者 (Executor)”、一个“规划者 (Planner)”和一个“知识管理器 (Knowledge Manager)”，以最大限度地降低通信复杂性

从 todo.md 到规划者 Agent：早期的 Agent 普遍使用 todo.md 文件进行任务规划，但这会浪费大量 token 在文件的反复读写更新上。更优的模式是将其升级为一个独立的规划者 Agent，使用“Agent as Tool”的范式进行交互

关于强化学习 (RL) 与工具调用：

谨慎对待 RL：对于一个需要支持开放、可扩展行动空间（如 MCP）的通用 Agent，进行 RL 的难度极高。这相当于在自己构建一个基础模型。目前阶段，将这项工作交给模型公司，而应用层专注于上下文工程是更明智的选择

总而言之，成功的上下文工程是一场在多个潜在冲突目标（如信息保真度、成本、延迟、可扩展性）之间寻求完美平衡的艺术。它要求开发者不仅要掌握精湛的技术，更要拥有一种化繁为简、信任模型的深刻洞察力

参考：

Context Engineering for AI Agents with LangChain and Manus