AI 代理的上下文工程：构建 Manus 的经验教训 • Peak
本文是 Manus 首席科学家 季逸超 ‘Peak’ 在 2025 年 7 月 19 日发表的博客，主要介绍了 Manus 在构建 AI 代理过程中的一些经验教训，深入探讨了“上下文工程”的核心理念与方法。作者认为，对于现代 AI 代理而言，精心设计和管理上下文，比微调模型本身更为关键，它直接决定了代理的性能、成本和可扩展性。 主要观点 上下文工程优于模型微调：在产品快速迭代的背景下，依赖前沿大语言模型的上下文学习能力，通过“上下文工程”来构建 AI 代理，比耗时数周的模型微调更具优势。这使得产品能快速迭代，并与底层模型的进步保持同步。 上下文是代理行为的核心：代理的效率（速度和成本）、鲁棒性（错误恢复能力）和扩展性，最终都取决于上下文的构建方式。如何塑造记忆、环境和反馈，是决定代理智能水平的关键。 构建过程是实验科学：不存在一劳永逸的完美框架。构建高效的代理需要通过不断的实验、试错和迭代（作者称之为“随机研究生下降”），逐步找到最优的上下文管理策略。 关键细节 1. 围绕 KV 缓存进行设计 核心指标：KV-cache 命中率是影响代理延迟和成本的最重要指标。由于代理任务中输入与输出的 token 比例极高（Manus 中约为 100:1），有效利用缓存能带来巨大收益（成本可降低 10 倍）。 实践方法： 保持提示前缀稳定：避免在系统提示的开头加入时间戳等易变内容。 上下文只追加：避免修改历史记录，并确保 JSON 等格式的序列化顺序是确定的。 明确标记缓存断点：在必要时手动插入缓存标记，以优化缓存策略。 2. 工具管理：遮蔽而非移除 问题：在迭代过程中动态增删工具定义，会使 KV-cache 失效，并可能让模型对不再存在的工具感到困惑。 解决方案：使用“遮蔽”策略。通过上下文感知的状态机，在解码时约束模型的输出（logits），阻止或强制其选择特定工具，而不是从上下文中移除工具定义。例如，通过预填充回复来强制模型调用某个或某类工具。 3. 将文件系统作为外部上下文 挑战：即使有 128K 的上下文窗口，在处理网页、文档等大型观测数据时，也容易超出限制、导致性能下降且成本高昂。 解决方案：将文件系统视为一种无限大、可持久化的“终极上下文”。训练代理按需读写文件，将长期记忆和大型数据外部化存储。这种压缩是可恢复的（例如，保留 URL 而非网页全文），既能缩短上下文长度，又不会永久丢失信息。 4. 通过复述操控注意力 问题：在执行包含数十个步骤的复杂任务时，代理容易偏离最初目标（即“迷失在中间”问题）。 解决方案：通过刻意操控注意力来解决。Manus 会创建一个 todo.md 文件，并在任务过程中不断更新它。这种“复述”行为将全局计划推到上下文的末尾，使其处于模型近期注意力的焦点，从而保持任务目标的一致性。 5. 保留错误以促进学习 错误观念：许多开发者倾向于隐藏或擦除代理犯下的错误。 正确做法：将失败的尝试、错误信息和堆栈跟踪保留在上下文中。这为模型提供了宝贵的学习证据，使其能够隐式地更新内部认知，从而避免重复犯错。错误恢复是衡量真正代理能力的关键指标。 6. 避免少样本提示的陷阱 风险：如果上下文中充满了相似的成功案例（少样本示例），模型会倾向于模仿这些模式，即使当前情况已不适用，导致行为僵化或出错。 解决方案：在上下文中引入受控的多样性。通过在行动和观察的序列化模板、措辞或格式上引入微小变化，打破单一模式，帮助模型更好地泛化和适应。 原文： AI代理的上下文工程：构建Manus的经验教训 2025/7/18 – Yichao ‘Peak’ Ji...