AI Agent 中的上下文工程 (Context Engineering)

type

status

date

slug

summary

背景介绍

AI 智能体（AI Agents）的迅速发展带来了管理其处理海量信息的新挑战。其中最关键的一项是上下文工程（Context Engineering），这是一门专注于优化智能体系统中大型语言模型（LLM）信息流的技术。本文综合了 LangChain 的 Lance 和 Manus 联合创始人兼首席科学家 Peak 在一场网络研讨会上的关键见解，旨在全面解析上下文管理的高级技术，特别是 Manus 的创新方法。

Context Engineering：其他系统与大模型之间的沟通桥梁 — **Context Engineering**：其他系统与大模型之间的沟通桥梁

Context Engineering：跨越认知鸿沟的熵减工程

Context Engineering 2.0: The Context of Context Engineering 这篇论文把 Context Engineering 这个概念放在更大的背景下看待，很有意思。

人类智能与机器智能的发展轨迹持续存在 "Intelligence Gap"（智能鸿沟）。这条鸿沟的本质，是信息熵的不对称。人类在交流时拥有天然的"熵减能力"——我们能够通过共享的文化背景、情感线索、情境感知来主动补全对话中的缺失信息，将高熵的、模糊的意图转化为低熵的、清晰的理解。而机器，至少在目前，熵减这种能力还不够好。

Context Engineering 正是为了弥补这一熵减能力差距而存在的系统工程。 当我们与AI交互时，如果只是抛出一个简单的问题，AI面对的是一个高熵状态：缺乏背景、没有记忆、不了解你的意图偏好。Context Engineering 的核心工作，就是主动为机器进行熵减预处理——通过构建知识库、维护记忆系统、部署RAG检索、集成外部工具，我们将原本高熵的、碎片化的信息转化为结构化的、低熵的上下文表示，让机器能够"理解"。

上图展示了 Context Engineering 从1.0到4.0的演进路径，揭示了一个核心规律：随着AI智能水平的提升，其上下文处理能力不断增强，人机交互成本持续降低。

Context 1.0 - Context as Translation（上下文作为翻译）| Era 1.0: Primitive Computation (1990s-2020)

在这个阶段，机器仅能处理结构化输入和简单的环境线索，缺乏对意义和意图的深层理解。AI表现为"被动执行者"（Passive Executor），人机交互依赖于刚性的、预定义的格式——菜单选择、简单传感器数据等。虽然超越了二进制命令层面，但所有上下文仍必须由人类显式准备并"翻译"成机器可直接处理的格式。此时人机交互成本最高，人类需要投入大量精力来适应机器有限的理解能力。

Context 2.0 - Context as Instruction（上下文作为指令）| Era 2.0: Agent-Centric Intelligence (2020-Present)

2020年GPT-3的发布标志着 context engineering 的转折点。机器展现出中等智能水平，能够理解自然语言输入并推断部分隐含意图，成为"主动代理"（Initiative Agent）。上下文不再局限于显式定义的信号，可以包含模糊性和不完整信息。AI通过先进的语言理解和情境学习（in-context learning）主动推理上下文缺口，提供更自适应的交互。人类可以用对话方式表达需求，系统能解释大部分潜在含义，人机协作变得切实可行。

Context 3.0 - Context as Scenario（上下文作为场景）| Era 3.0: Human-Level Intelligence (Future)

随着预期的突破，智能系统将接近人类水平的推理和理解能力，AI进化为"可靠协作者"（Reliable Collaborator）。Context engineering 超越当前模式，使AI能够像人类一样感知上下文并吸收高熵信息。可解释上下文的范围显著扩展，包括社交线索、情绪状态和更丰富的环境动态。通过知识库、记忆系统和RAG检索，AI能够在复杂场景中持续协作，实现真正自然的人机协同，AI将作为知识丰富且高效的伙伴存在。我们目前正处于从Era 2.0向Era 3.0的过渡阶段。

Context 4.0 - Context as World（上下文作为世界）| Era 4.0: Superhuman Intelligence (Speculative)

当智能系统超越人类能力，它们将拥有"上帝视角"，比人类自己更深刻地理解人类意图，成为"深思熟虑的大师"（Considerate Master）。传统的主客体关系发生反转：机器不再被动适应人类定义的上下文，而是主动为人类构建新的上下文，发现隐藏需求，引导人类思维。这一转变的迹象已经出现——在围棋领域，职业棋手正在向AI学习超人类的新策略。此时，机器成为洞察和灵感的来源，从根本上重新定义了人机协作的本质。

这一演进过程的本质，是AI逐步接管人类原本需要承担的"上下文熵减工作"。随着 Context Engineering 能力的提升，人类可以用更自然、更高熵的方式表达意图，而将复杂的信息结构化、情境理解和知识整合工作交给AI系统来完成。这正是 Context Engineering 作为系统工程的价值所在：不是让人类学会如何更好地与机器对话，而是让机器学会如何更好地理解人类——最终，在Era 4.0，机器甚至能比人类更好地理解人类自己。

从1963年的 Sketchpad 到1999年的 Ubiquitous Computing，再到今天的 Langchain、Claude Code、Cursor 等工具，Context Engineering 一直在努力缩小智能鸿沟。下图中的紫色区域标注了 "Human = Machine" 的交汇点，那将是 Context Engineering 的终极目标：当我们成功将人类的高熵意图系统化地转化为机器可理解的低熵表示时，人机协作的效率将达到前所未有的高度。这不仅是技术的进化，更是一场持续的熵减革命。

在模型微调和后训练日益普及的今天，Context Engineering 是应用和模型之间最清晰、最实用的边界。Manus 认为，初创公司应避免过早陷入模型专门化的陷阱，因为这会将产品的创新速度与模型的迭代速度捆绑在一起。即使是使用强大的基础模型进行微调，也可能因为 AI 领域快速的技术颠覆而变得危险。例如，MCP（Manus Code Playground）的推出彻底改变了 Manus 的设计，从一个紧凑的静态行为空间转变为一个几乎无限扩展的开放域环境，这种变化对于已经专门训练过的模型来说是极难适应的。因此，坚定地依赖通用模型和上下文工程，是保持产品灵活性和未来适应性的关键策略。

<ins/>

Context Engineering 为什么有必要

接下来回到 AI Agents 架构中的上下文工程理解视角。为什么从 2025 年3月份开始，上下文工程越来越受到大家的重视？

AI 智能体通过自主与工具交互并积累观察结果，交互轮次变长后会导致“上下文腐烂（Context Rot）”现象。每次工具调用都会生成一个观察结果并附加到聊天历史中，导致消息数量不受限制地爆炸式增长。这种不断增长的上下文长度会降低 LLM 的性能，形成一个悖论：智能体需要大量的上下文，但更长的上下文会损害其效率和准确性。

Prompt Engineering

Prompt Engineering 是我们与AI交互的起点——通过精心设计静态的提示词结构（角色、任务、格式、约束、示例、输入），让AI理解我们的需求并给出准确答案。这种方法简单直接，但每次对话都是独立的"单次任务"，AI没有记忆，也无法访问外部知识。

常见的 Prompt 结构：

角色定义 - 设定身份

任务描述（整合了背景信息）- 说明要做什么

输出格式 - 规定输出形式

约束条件 - 硬性限制

示例 - 参考模板

输入数据 - 实际内容

一个示例：

从 Prompt Engineering 到 Context Engineering：从静态到动态的进化

Context Engineering 可以理解为 Dynamic Prompting 的系统化升级。它的核心思想是：不再手动编写固定的提示词，而是根据对话情境、历史记忆、知识库内容，动态组装最适合当前任务的上下文。当用户提出问题时，系统会自动从知识库检索相关信息（RAG）、调取历史对话记忆、整合外部工具的数据，然后将这些动态获取的上下文与用户的问题结合，形成一个"信息丰富、情境完整"的增强提示词。

这不仅仅是提示词的动态化，更是整个交互架构的升级：

知识库提供领域专业知识和事实依据

记忆系统维护对话历史和用户偏好

RAG检索按需获取最相关的上下文片段

工具集成连接数据库、API等外部资源

系统级设计确保一致性和可扩展性

简单说，Prompt Engineering 是"手工制作每一个提示词"，而 Context Engineering 是"搭建一个能自动生成最优提示词的智能系统"。这就是从手动到自动化、从静态到动态、从单次任务到系统工程的进化。

上下文工程的核心原则与实践

上下文腐烂（Context Rot）是指在长上下文场景中，当上下文窗口超过某个"腐烂阈值"（Pre-rot threshold）后，AI模型对远端信息的理解和利用能力急剧下降的现象。如图所示，在0-128K token范围内（绿色区域），模型能够有效处理上下文信息；当进入128K-200K范围（橙色区域）时，性能开始衰减，这就是"腐烂阈值"；而超过200K之后的大部分上下文（白色区域）则几乎被模型"忽略"，无法有效利用。

这一现象揭示了上下文过程面临的核心挑战：即使模型声称支持百万级token的上下文窗口，实际可用的有效上下文往往远小于这个数字。因此，上下文过程不仅要构建丰富的知识环境，还必须通过智能检索（RAG）、上下文压缩、记忆管理等技术，确保关键信息始终处于模型的"有效感知区域"内，避免重要上下文在长对话中"腐烂"而失效。

面对上下文腐烂的挑战，Context Engineering 形成了几大核心原则：上下文优化 —— 通过缩减与检索技术，提取最相关信息而非盲目堆砌；上下文隔离 —— 借助多智能体设计，为不同任务建立独立上下文空间，避免信息混杂；上下文分层 —— 通过卸载与分层行动空间，将系统知识、历史记忆、当前任务按生命周期分层管理。这些原则通过四大核心技术得以落地实践。

1. 上下文缩减：压缩与摘要的艺术

上下文缩减（Context Reduction） 旨在压缩或总结信息。Manus 将其细分为两种形式：

压缩（Compaction）：一个可逆的过程，将可以从外部状态（如文件系统）重建的信息（例如，用文件路径代替完整文件内容）从上下文中剥离。这样，没有任何信息真正丢失，只是被外部化了。这种可逆性至关重要，因为智能体可能在后续步骤中需要依赖早期的精确行为。Manus 的工具调用和工具结果都存在完整和紧凑两种格式，紧凑版本会剥离可从文件系统或外部状态重建的信息，例如，一个文件写入操作在执行后，其内容字段可以被安全移除，只保留文件路径。当智能体需要时，可以通过路径再次检索。

摘要（Summarization）：一个不可逆的过程，用于浓缩信息。Manus 对此非常谨慎，通常在摘要前会将关键上下文部分卸载到文件中，并始终保留最后几次工具调用的完整细节以保持连贯性。

为了使摘要过程更可靠，Manus 避免使用自由形式的提示，而是采用结构化模式 (Schema)。通过定义一个包含特定字段（如“修改的文件”、“用户目标”、“上次停止的位置”）的表单让 AI 填写，可以确保输出的稳定性和一致性。这种方法强制 AI 概括特定信息，而非随意生成，从而提高摘要的质量和可控性。

Manus 通过跟踪上下文长度阈值来管理这两种方法。当上下文接近“腐烂前”阈值（通常为 128k-200k Token）时，首先触发压缩。只有当压缩的收益变得微乎其微时，才会转向摘要。在压缩时，Manus 可能会选择压缩最旧的 50% 工具调用，同时保留较新的调用记录的完整细节，以确保模型仍有新鲜的少样本示例来学习如何正确使用工具。在进行摘要时，Manus 总是使用完整版本的数据，并保留最后几次工具调用和结果的完整细节，以帮助模型平滑地继续工作，避免风格和语气上的突然变化。

<ins/>

2. 上下文检索：文件系统工具的回归

上下文检索（Context Retrieval） 侧重于高效地获取相关信息。与依赖索引和语义搜索的系统不同，Manus 在其瞬时沙盒会话中优先使用更简单的基于文件的搜索工具，如 glob 和 grep。Peak 解释说，由于会话的瞬时性，动态构建索引是不切实际的，因为每次会话都是一个全新的环境，没有时间去动态构建索引。因此，依赖于对基于行的文本格式（如纯文本而非 Markdown）进行操作的成熟命令行工具，是更高效的选择。Manus 倾向于使用纯文本，因为 Markdown 有时会导致模型输出过多的项目符号，且基于行的格式更利于 grep 和按行范围读取。

然而，对于需要长期记忆或访问大型企业知识库的场景，外部向量索引仍然是必要的。

对于简单的搜索，Manus 会直接将完整的搜索结果附加到上下文中，并依赖压缩机制来管理。但对于需要整合多个查询结果的复杂搜索，Manus 会启动一个子智能体（即“智能体即工具”），由该子智能体负责处理、整合信息，并以主智能体预定义的固定输出模式返回结果。

3. 上下文隔离与多智能体设计

上下文隔离（Context Isolation） 通过多智能体架构实现。Manus 借鉴了 Go 语言的并发哲学，提出了两种不同的隔离模式：

通信模式（Communication Mode）：适用于简单的、指令清晰的任务。主智能体向子智能体发送指令，子智能体的上下文仅限于该指令。这种模式适用于主智能体只关心最终输出，不关心中间过程的任务。

共享上下文模式（Shared Context Mode）：适用于复杂的、依赖历史的任务。子智能体可以访问完整的先前上下文，包括所有的工具使用历史。这种模式在需要完整历史记录的场景下避免了信息检索的延迟和成本，但代价是每次子智能体调用都需要预填充更大的输入，且由于系统提示和行为空间不同，无法重用 KV 缓存。

Manus 的多智能体系统设计避免了基于角色（如设计师、程序员）的划分，认为这种拟人化类比效率低下。相反，系统由少数几个专业智能体组成：一个庞大的通用执行器、一个规划器和一个知识管理器。知识管理器智能体的作用是回顾用户和智能体之间的对话，并判断哪些内容应该被存入长期记忆。大多数子任务通过“智能体即工具”的范式实现，即一个子智能体被封装成一个工具供主智能体调用。在这种模式下，主智能体通过定义输出模式来确保从子智能体获得结构化、可靠的结果，而子智能体则使用一个特殊的“提交结果”工具，通过约束解码来强制执行该模式。这种设计在 Manus 的“Wide Research”（内部称作“智能体版 MapReduce”）功能中得到了应用，通过共享同一个沙盒，文件系统在主子智能体之间共享，信息传递仅需传递不同的文件路径。这种“智能体即工具”的设计使得主智能体向子智能体传递信息变得容易，更重要的是，通过定义输出模式和子智能体的“提交结果”工具，确保了从子智能体获得的输出是结构化且可靠。这种模式解决了多智能体通信中的信息同步难题，尤其适用于复杂任务，它利用共享沙盒和文件系统，通过传递文件路径实现主子智能体间的信息共享。

<ins/>

4. 上下文卸载与分层行动空间

上下文卸载（Context Offloading） 的核心思想是：并非所有信息都需要保留在智能体的消息历史中，而是可以将其存储到上下文窗口之外，在需要时再检索回来。另外，随着系统变得越来越复杂，特别是如果集成了 MCP，工具本身会占用大量上下文。上下文中工具过多会导致混乱，出现“上下文混淆”(Context Confusion)，模型可能会调用错误的工具，甚至是不存在的工具。

卸载最流行的实践是利用文件系统——将工具输出、搜索结果等消耗大量 Token 的完整内容转储到文件中，只向智能体返回必要的摘要信息，这样既保持了信息的可访问性，又避免了上下文窗口的持续占用。

Manus 正在试验新颖的分层行动空间（Layered Action Space）方法处理工具过多的情况。在分层行动空间设计中，上下文卸载不仅体现在工作内容的外部存储，更延伸到对工具本身的分层管理：通过将大量命令行工具和 API 能力卸载到第2层和第3层，保持核心函数调用层（第1层）的简洁和稳定，从而避免因工具过多导致的"上下文混淆"问题。

分层行动空间（Layered Action Space）具体思路：

第 1 层：原子函数调用（Atomic Function Calls）：Manus 仅使用一小组（10-20个）固定的原子函数，如读写文件、执行 shell 命令、在互联网和文件中搜索，以及一些浏览器操作。这些函数因约束解码而模式安全，且数量有限，避免了缓存失效和混淆。Manus 刻意避免使用与现有模型训练中工具名称相同的命名，以防止模型混淆不同工具的参数和预期行为。如果自定义函数与现有模型训练中学习到的工具具有相同的名称，可能会导致模型混淆参数和预期行为，从而影响其性能。

第 2 层：沙盒实用工具（Sandbox Utilities）：在完整的 VM 沙盒中，Manus 可以执行预装的命令行工具。LLM 通过系统提示得知这些工具的存在，并被鼓励使用 -help 标志来查询用法。例如，Manus 会被告知在 /usr/bin 目录下有许多命令行工具。对于最常用的工具，其名称会以紧凑格式注入到系统提示中。这极大地扩展了智能体的能力，而无需修改其核心函数调用空间。这些工具的好处在于，它们可以直接处理大输出（例如写入文件或分页返回结果），并可利用 Linux 工具（如 grep、cat、less）进行即时处理。

第 3 层：软件包和 API（Packages and APIs）：此层允许编写并执行 Python 脚本来调用预授权的 API 或自定义软件包。这对于内存密集型计算（如分析大量股票数据）是理想的，因为计算过程在 Python 运行时内存中完成，只有最终的摘要结果返回给模型。Manus 预装了大量的 API 密钥，用户无需单独购买和配置。这种方式虽然不具备模式安全性，但代码的高度可组合性允许在单一步骤中链接多个操作，例如在一个 Python 脚本中完成获取城市名称、城市 ID 和天气等多个任务。

从模型的角度来看，所有三个层的操作最终都通过少数几个核心的原子函数（如 shell 和 file）来执行，从而为 LLM 维护了一个简单、缓存友好且正交的接口。这种混合模式，即结合了直接的工具调用和沙盒中的代码执行，平衡了约束解码的安全性与代码执行的灵活性。Peak 认为，只要是可以在编译器或解释器运行时内部处理的事情，都应该用代码来做；否则，就使用沙盒工具或函数调用。

<ins/>

5. More: 长期记忆、规划与模型适应性

长期记忆：Manus 采用一种显式的“知识”概念，需要用户确认才能将信息（如偏好设置）存入长期记忆。例如，用户可以告诉 Manus 每次都以 Excel 格式交付结果，系统会弹窗询问是否接受此项作为长期知识。这种“知识”系统类似于一种显式记忆，用户可以主动选择接受或拒绝 Manus 从对话中学习到的偏好。同时，系统也在探索利用集体用户反馈进行无参数的在线学习，以实现自我改进，例如通过识别用户对字体问题的共同修正来提升数据可视化能力。这种无参数的学习方式，旨在利用用户对智能体行为的纠正（如数据可视化中的字体问题），实现智能体的自我改进，而非依赖传统的参数化训练。

规划：Manus 已经从最初使用 todo.md 文件（被证明 Token 效率低下，浪费了大量交互轮次和 Token）演变为使用一个独立的、结构化的规划器智能体。还有一个独立的智能体作为“外部审查员”，能够从不同视角审视计划，甚至可以利用不同模型（如 Claude Haiku）的独特见解，从而显著节省 Token 并提高规划质量。它通过“智能体即工具”的范式实现，作为一个独立的工具供主智能体调用，不再像早期那样通过频繁更新 todo.md 文件来浪费 Token。

适应模型演进：为了应对 LLM 的快速迭代，Manus 采取了一种独特的评估策略：固定其智能体架构，然后在不同的模型（从弱到强）之间进行切换。如果一个架构从较弱的模型切换到较强的模型后能获得巨大提升，那么在某种程度上，该架构就更具未来适应性。Manus 通常每隔一两个月就会进行一次这样的架构审视，并经常在内部使用开源模型或提前试用专有模型，以便为下一个版本的模型发布做好准备。

模型选择与成本：Manus 目前没有使用开源模型，主要是因为在 Manus 的规模下，分布式 KV 缓存的实现难度和成本。与前沿 LLM 提供商合作，利用其强大的基础设施，有时反而比自建开源方案更经济。Manus 不仅使用 Anthropic 模型（认为其最适合智能体任务），也关注 Gemini 和 OpenAI 的进展，并进行任务级别的路由，根据子任务的特性选择最合适的模型（例如，Claude 擅长编码，Gemini 擅长多模态，OpenAI 擅长复杂数学和推理）。Manus 会利用模型提供商的输入缓存（Input Caching）功能，以优化 KV 缓存管理。

6. 安全与评估

安全与防护：Manus 在沙盒环境中投入大量精力进行防护，例如阻止信息泄露（如 Token）到沙盒之外，并对出站流量进行检查。Peak 强调，如果用户被提示注入，系统会对出站流量进行检查，确保敏感信息如 Token 不会离开沙盒。对于浏览器内的敏感操作（如登录持久化）或沙盒内的敏感操作，Manus 会要求用户手动确认或接管，因为网页内容本身可能存在提示注入的风险。Manus 与模型提供商紧密合作，共同增强防护措施。Peak 承认，设计一个完美无缺的解决方案非常困难，这是一个循序渐进的过程，目前 Manus 倾向于让用户在敏感操作时接管，并期待模型本身的防护能力增强。

评估策略：Manus 采用多维度的评估方法。首先是用户评分（1-5星），这是衡量实际用户体验的黄金标准。其次是自动化测试，包括内部创建的、带有可验证结果的数据集，以及侧重于执行性或交易性任务的定制基准。最后，也是最重要的是真人评估，通过实习生评估网站生成、数据可视化等涉及品味和美观的任务，因为这些难以通过奖励模型进行自动化评估。

强化学习与工具调用智能体：Peak 认为，对于支持 MCP 这种非固定行为空间的智能体，难以设计有效的奖励函数进行强化学习。他指出，如果行为空间不固定，就很难设计好的奖励函数，生成的部署和反馈也会不平衡，这实际上是在重复构建基础模型提供商已经完成的工作。因此，Manus 倾向于无参数的在线学习方式，例如利用集体用户反馈进行自我改进，而不是投入大量资源进行强化学习，因为模型公司已经在基础模型层面做了类似的工作。

结论：简化胜于过度工程

尽管上下文工程的技术多种多样，但 Manus 最大的进步往往来自于简化——移除不必要的复杂性，并给予底层 LLM 更多的信任。上下文工程的真正艺术在于，在多个可能相互冲突的目标（如性能、成本、延迟、可逆性）之间找到微妙的平衡，并始终追求更简单、更稳定、更智能的智能体架构。他总结道：“少做加法，多做理解 (build less and understand more)。”

<ins/>