上下文工程：AI Agent落地的核心方法论！

文章介绍了上下文工程(Context Engineering)作为AI编程中管理AI推理时上下文窗口的系统化方法论。通过对比Anthropic、Manus和LangChain三家公司的实践经验，文章详细探讨了KV缓存优化、动作空间管理、文件系统外部记忆和注意力操纵等关键技术，强调上下文工程是有效管理AI有限注意力资源的关键，对提升AI Agent生产力具有重要意义。

全栈大佬！

794人浏览 · 2025-11-04 16:33:39

全栈大佬！ · 2025-11-04 16:33:39 发布

AI编程目前应该是AI Agent落地最好的方向，也是最能带来生产力的方向。通过对Claude Code、Codex、Qoder等工具的深度使用，最近一段时间对上下文工程（Context Engineering）有了更深度的理解。

Anthropic和Manus，前者逐渐分化深耕到AI编程赛道，后者是今年新兴的通用AI Agent公司，前段时间刚好都发布了关于Context Engineering经验总结文章，非常值得拿来仔细阅读揣摩。

Context Engineering，简单说就是管理AI推理时的上下文窗口。它不是Prompt Engineering的简单升级，而是一套系统化的工程方法论，一种关于有效构建信息环境的科学。当你的AI应用从简单的对话，升级到需要多轮交互、调用工具、处理长时程任务的Agent时，Context Engineering就变得非常重要了。

除了Anthropic和Manus，LangChain团队也在讨论这个话题。这三家公司虽然视角不同，但核心观点惊人一致。今天就专门对三家公司关于Context Engineering的经验技术进行摘录和总结。

Context Engineering的定义

Anthropic给出的定义很清晰：Context Engineering是Prompt Engineering的自然演进，核心是管理推理时的整个token生态系统。

LangChain的类比更形象：上下文窗口就像CPU的RAM，容量有限，需要精心管理。你不能把所有数据都塞进去，得有选择、有策略。

最关键的观点是：上下文是有限资源。

这取决于Agent所使用的大模型上下文窗口，是LLM在一次推理中能看到并利用的最大文本长度上限，比如DeepSeek-V3.1上下文窗口是128K，Claude Sonnet 4.5是200K。

Anthropic团队的文章中认为，上下文存在边际效益递减现象。token越多，模型的准确率反而会下降。这是因为训练数据中长序列的经验较少，而且位置编码插值也有权衡。说白了，上下文其实是一种注意力预算。

Manus团队给出了更具体的数据：一个典型的AI Agent任务，平均需要50次工具调用，输入输出token的比例达到100:1。这意味着绝大部分token都在输入，如果不做优化，成本会非常高。

从管理的角度看，上下文主要包含三类内容：

Instructions（指令）：系统提示、工具描述、行为规范等。这部分相对稳定，变化不大。
Knowledge（知识）：事实信息、历史记忆、领域知识等。这部分可能非常庞大，需要检索和过滤。
Tools（工具反馈）：工具调用的结果、错误信息、中间状态等。这部分会随着任务推进不断增长。

明白了这三类上下文，就能理解为什么简单的Prompt Engineering不够用了。对话类应用主要是Instructions的优化，而Agent类应用需要动态管理所有三类内容。

Manus的工程实践：KV-cache优化为核心

Manus作为年初以来爆火的通用Agent产品，在Agent研发过程中积累了大量的上下文工程经验。他们团队在实践中发现了一个关键指标：KV-cache命中率是生产阶段AI代理最重要的单一指标。

这个发现的背后是一个惊人的数据：缓存成本仅为未缓存的1/10。

Manus团队选择的技术路线是：基于前沿模型的上下文学习，而不是训练专有模型。这样做的好处是迭代速度快，从数周降到数小时。但代价是必须把Context Engineering做到极致。

Manus关于Context Engineering的经验总结原文：

https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

技术方案1：KV缓存优化

KV-cache的原理是，如果提示的前缀部分保持不变，模型可以复用之前计算好的键值对，大幅降低计算成本。

但实际操作中，有很多细节会破坏缓存。

比如说，很多开发者喜欢在系统提示里加上当前时间戳，类似这样：“Current time: 2025-11-03 14:32:15”。这样每次请求的提示前缀都不一样，缓存就完全失效了。

Manus的做法是：

保持提示前缀绝对稳定，把动态内容后置
确保上下文只追加，不修改之前的内容
保证序列化过程的确定性（比如JSON对象的key顺序）

这三个原则看起来简单，但实际落地需要在架构层面统一约束。Manus的经验表明，做好缓存优化后，生产环境的成本直接降低了10倍。

技术方案2：动作空间管理

AI Agent通常会配备很多工具，比如搜索、写文件、执行代码等。工具一多，模型选择起来就容易混淆。

传统的做法是动态调整工具列表，根据当前任务只提供相关工具。但这样会破坏KV-cache。

Manus采用了一个巧妙的方案：logits遮蔽。

简单说，就是始终提供完整的工具列表（保证提示前缀稳定），但在模型输出时，通过遮蔽logits来约束选择范围。这样既不影响缓存，又能引导模型做出正确选择。

配合这个方案，Manus还制定了工具命名规范：使用一致的前缀，比如所有浏览器操作都是browser_开头，所有命令行操作都是shell_开头。这样模型更容易理解工具的分类。

最重要的是，避免动态修改工具定义。一旦工具的描述或参数发生变化，缓存又会失效。

技术方案3：文件系统外部记忆

AI Agent在执行长时程任务时，会积累大量的中间信息。比如访问过的网页内容、读取过的文件、执行的命令输出等。这些信息如果都保留在上下文里，很快就会撑爆窗口。

Manus提出了可恢复压缩策略。

核心思路是：删除可以重新获取的信息，但保留索引。

举个例子，Agent访问了一个网页，抓取了完整的HTML内容。这个内容可能有几千个token。但其实，只要保留URL，需要的时候可以重新访问。所以可以把HTML内容删掉，只保留URL和提取出的关键信息。

类似的，读取文件后，可以删除文件内容，只保留文件路径和摘要。

这个策略的前提是，外部信息源是稳定的。如果网页可能更新，或者文件可能被修改，就需要更谨慎的处理。

技术方案4：注意力操纵

即使做了前面的优化，长时程任务还是会积累大量上下文。这时候会出现丢失在中间（Lost in the Middle）现象：模型对上下文开头和结尾的内容记得清楚，但中间部分容易被忽略。

Manus的解决方案是：自动生成todo列表，并重复纳入上下文。

具体做法是，在系统提示里要求Agent维护一个任务清单，每完成一步就更新。这个清单会被放在上下文的显著位置，比如紧跟在系统提示之后。

这样做的好处是，任务目标始终在模型的"注意力焦点"上。即使上下文很长，模型也不会偏离主线任务。

这有点像人类工作时列的待办事项。你可能会被各种细节打断，但只要时不时看一眼待办清单，就不会忘记最终目标。

Anthropic的认知架构：系统化设计

Claude团队的视角更偏向认知架构。他们把上下文比作注意力预算，强调系统化设计的重要性。

Anthropic关于Context Engineering的经验总结原文：

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

实践方法1：系统提示设计

Anthropic总结了一个原则：使用简单直接的语言，避免两个极端。

一个极端是写得像代码一样，充满if-else逻辑。比如：“如果用户问天气，就调用weather工具；如果用户问新闻，就调用news工具；如果…”。这种提示非常脆弱，稍微遇到没覆盖的情况就崩了。

另一个极端是写得过于模糊，只给无关紧要的宏观指导。比如：“你是一个聪明的助手，请根据用户需求灵活应对”。这种提示看似灵活，但实际啥也搞不定。

正确的做法是：最小化信息集，完整概述预期行为。

在结构化方面，Anthropic推荐使用XML标签或Markdown标题。比如：

<system>
你是一个代码审查助手。
</system>
<guidelines>
- 关注代码可读性和可维护性
- 指出潜在的性能问题
- 提供具体的改进建议
</guidelines>
<examples>
...
</examples>

这种结构清晰，模型容易解析。而且不同部分可以独立更新，不影响其他部分。

实践方法2：工具设计原则

Anthropic提出了工具设计的三大原则：自包含、健壮容错、意图清晰。

自包含是指，工具的描述和参数定义应该足够完整，模型不需要依赖外部文档就能理解如何使用。

健壮容错是指，工具应该能处理各种边界情况，而不是遇到意外输入就报错。比如搜索工具，应该能处理空查询、过长查询、特殊字符等情况。

意图清晰是指，工具的命名和描述应该精确传达其功能和适用场景。

特别重要的一点是：最小化工具重叠。

Anthropic的工程师观察到，人类能区分两个相似工具的差异，但AI往往会混淆。比如你提供了search_web和search_documents两个工具，人类一眼就能看出区别，但模型可能会在两者之间犹豫不决。

解决方案是，要么合并为一个工具，要么通过命名和描述让差异更明显。比如web_search和local_search，从命名上就清楚了作用域。

另一个技巧是，让工具返回token高效的信息。比如数据库查询工具，不要返回原始的SQL结果集，而是返回格式化的摘要。这样既节省token，又便于模型理解。

实践方法3：JIT上下文检索

JIT（Just-In-Time）上下文检索是Anthropic提出的一个重要策略。

核心思路是：在上下文里只维护轻量的标识符（比如文件路径、URL、数据库记录ID），需要详细信息时，通过工具动态加载。

Claude Code就是一个典型应用。它不会把整个代码库加载到上下文里，而是维护文件列表和目录结构。当需要查看某个文件时，才通过Read工具读取内容。

这样做的好处是，上下文始终保持精简，只包含当前任务相关的信息。

实现JIT检索的关键是，设计好标识符和索引系统。标识符要足够稳定（不能频繁变化），同时要包含足够的语义信息（便于模型理解）。

长时程任务技术

对于特别长的任务，Anthropic提供了三种技术：

压缩：定期总结对话历史，删除细节，保留关键决策和未解决的问题。Claude Code的做法是，当上下文达到窗口的95%时，自动触发总结。

结构化笔记：把重要信息写入文件系统或数据库，作为上下文窗口外的持久化记忆。这些笔记可以通过工具随时读取。

Subagents架构：把复杂任务分解给多个专业化的subagent，每个子代理完成自己的部分后，返回精简的摘要（通常1000-2000 tokens）。Agent不需要关心子任务的细节，只需要整合摘要。

这三种技术可以组合使用。比如Agent维护结构化笔记，Subagent负责具体任务，完成后压缩结果返回给Agent。

总结

Context Engineering的本质，是有效管理AI的有限注意力资源。

Manus和Anthropic虽然视角不同，但核心观点高度一致：缓存优化、工具设计、压缩策略，这三个方面都是必须做好的基础工作。

差异在于，Manus更偏向工程优化，关注KV-cache命中率、logits遮蔽这些底层技术；Anthropic更偏向认知架构，强调JIT检索、注意力预算这些系统化设计。

但两者是互补的。工程优化能立刻降低成本，认知架构保证长期可扩展性。

Context Engineering作为今年以来一个新兴的技术，目前还处于快速发展阶段。三家公司的文章都是最近几个月发布的，说明Context Engineering正在从零散的经验，走向系统化的方法论，值得我们持续跟进。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

在这里插入图片描述