Context Engineering Notes

---

是什么

别再迷信 Agent 框架了，Context Engineering 才是王道！

Context Engineering = Memory + Execution Control + Context Management

Context Engineering 是一种系统化的工程方法，通过 Memory、Execution Control 和Context Management 三大核心组成部分为 Agent 提供相关且高质量的上下文信息。

具体来说：

• Memory 包含对长期记忆（通过工具存储或用户写入的持久化信息）和短期记忆（LLM当前接收的消息历史或上下文）的有效利用。
• Execution Control 负责编排 LLM 的任务执行流程，例如 ReAct、Plan and Execute 等框架。
• Context Management 专注于动态地组装、过滤和优化输入到 LLM 的上下文信息。

维度	提示词工程（Prompt Engineering）	上下文工程（Context Engineering）
定义	设计和优化给模型的文本提示词	管理和构造模型输入的整体上下文信息
范围	仅限于文本提示词内容的设计和调整	包含提示词设计及更广泛的上下文数据管理和利用
输入内容类型	纯文本提示词，包括指令、示例、格式引导	文本提示词、历史对话、多轮上下文、外部知识库、工具调用
技术手段	Few-shot、Chain-of-Thought、零样本、指令调优	长上下文管理、检索增强（RAG）、embedding索引、多模态融合
关系	是上下文工程中的一个重要组成部分	是包含提示词工程的更大范畴

Tips from Manus

AI代理的上下文工程：构建Manus的经验教训

围绕KV缓存进行设计

相比Chatbot，Agent的预填充比解码更多，好在具有相同前缀的上下文可以利用KV缓存（如vLLM等框架即可启用），这大大减少了首个token的生成时间(TTFT)和推理成本。几个关键实践：

1. 保持提示前缀稳定。如不要在System的Prompt的开头包含时间戳
2. 让上下文append-only。避免修改之前的操作或观察结果
3. 需要的时候标记缓存的断点

屏蔽工具而不是移除

工具数量增长会使Agent产生决策疲劳。RAG等按需加载工具的方法被尝试，但是实验表明避免在迭代过程中动态添加或移除工具：工具定义位于上下文的前部，容易导致KV缓存失效；先前的动作用到了当前上下文不定义的工具时模型会感到困惑。

为了解决这个问题，在解码时掩蔽token的logits（概率），从而基于当前上下文阻止（或强制）选择某些动作。具体做法通过response prefix（预先生成回复的前缀）实现，如指定function calling的三种模式：

• 模型可以选择调用或不调用函数。通过仅预填充回复前缀实现：<|im_start|>assistant
• 模型必须调用函数，但选择不受约束。通过预填充到tool_call到实现：<|im_start|>assistant<tool_call>
• 模型必须从特定子集中调用函数。通过预填充到函数名称的开头实现：<|im_start|>assistant<tool_call>{"name": "browser_

比如当前的场景是Agent处理浏览器调用，那么通过第三种模式，模型的后续token会接着browser_生成，保证了强制调用browser_开头的函数。

使用文件系统作为上下文

当上下文过长会出现性能和金钱的损失，一些Agent系统通过截断或压缩解决但会导致信息丢失。Manus把文件系统作为上下文，模型只需要读写文件即可，相当于把文件内容可逆地压缩为一个URL。

通过复述操控注意力

一次任务中有很多次的工具调用，通过不断重写待办事项列表，Manus将目标复述到上下文的末尾。这种机制有效避免了"丢失在中间"的问题，确保全局计划始终保持在模型的近期注意力范围内。

保留错误的内容

错误的尝试要保留在上下文中，从而改变其先验，避免重复的错误。事实上，错误恢复是真正的代理行为最明确的衡量指标之一。

不走寻常路

和Few-Shot的原理一样，Agent会模仿上下文中的行动模式，当涉及到重复决策的任务时，模型会陷入偏离、过度泛化甚至产生幻觉。解决办法是增加多样性，在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。