学习笔记 | Manus 的上下文工程是怎么做的?

当 AI Agent 执行 50 次工具调用后，它的"记忆"还能保持清醒吗？

写在前面

最近因为在做上下文工程/Memory 相关的事情，完整地看了一下 Lance Martin 与 Manus 联合创始人兼 CSO Yichao "Peak" Ji 的网络研讨会技术分享^[1]（原文笔记^[2]）。

本文来自我看完网络研讨会后的笔记（文中配图也来源于原文），仅用作学习交流用，可能存在理解偏差或事实问题，欢迎指正。如有内容侵权，可联系本人删除。

这篇文章的初衷主要是：

1. 自己做笔记
2. 让更多人知道这个分享

我还是推荐大家去读原文、看原视频。 我这里的笔记都存在压缩，或者是在通过自己的理解转译之后，可能存在些许偏差。如果你是专业做这个领域的，一定要去读原文和视频。

Manus 是目前最受欢迎的通用 AI Agent 之一，一个典型的 Manus 任务平均需要调用 50 次工具。这意味着什么？意味着上下文窗口会被大量的对话历史、工具调用结果、中间状态填满。

而随着上下文窗口填满，LLM 的性能会显著下降——这就是所谓的「上下文腐烂^[3]」（Context Rot）。

正如 Andrej Karpathy^[4] 所说：

上下文工程是一门精细的艺术和科学，旨在为 Agent 轨迹的下一步填充恰到好处的信息。

那么，Manus 是如何解决这个问题的？

三大核心策略

Manus 的上下文工程可以概括为三个核心策略：

缩减（Reduction）→ 隔离（Isolation）→ 卸载（Offloading）

这三者不是孤立的，而是相互支撑的系统。

策略一：上下文缩减（Context Reduction）

1. 工具结果的双版本机制

Manus 为每个工具调用维护两个版本：

压缩策略：

• 对「陈旧」的工具结果应用压缩，用紧凑版替换完整版
• 保留较新的结果完整版，以指导 Agent 的下一步决策
• Agent 需要时仍可通过引用获取完整内容

这就像是把不常用的文件移到外部硬盘——节省空间，但随时可取。

2. 结构化摘要

当压缩达到收益递减点时，Manus 会对整体轨迹进行摘要。

💡 所谓「收益递减点」，是指继续逐条压缩工具结果的边际收益开始下降——此时与其继续逐条微调，不如直接做一次整体摘要。这通常发生在上下文积累到一定规模后，冗余信息增多，继续压缩的复杂度和成本上升。

如何确保摘要的准确率？

关键技巧是避免 free-form 格式，采用结构化 Schema：

• ❌ 不要让 AI 自由发挥写摘要（容易遗漏关键信息、格式不一致）
• ✅ 预定义摘要的 Schema/表格结构，让 AI 直接往格式里填充
• 这样可以确保摘要的完整性和一致性，减少信息丢失

策略二：上下文隔离（Context Isolation）

务实的多 Agent 设计

很多人设计多 Agent 系统时，喜欢模拟人类分工——设计师、工程师、项目经理……

但 Peak 的观点很直接：避免拟人化分工。

人类因认知限制而按角色组织，但 LLM 不一定有这些限制。

子 Agent 的核心目标是隔离上下文，而非模拟人类分工。

架构设计

上下文共享的艺术

根据任务复杂度采用不同策略：

• 简单任务：规划器通过函数调用传递指令，只需获取输出

• 复杂任务：共享完整上下文，子 Agent 有自己的工具和指令

💡 踩坑教训

Manus 最初用 todo.md 做任务规划，结果发现约 1/3 的动作都在更新待办列表，浪费了宝贵的 token。

后来改用专门的规划器 Agent，问题迎刃而解。

策略三：上下文卸载（Context Offloading）

分层动作空间（Hierarchical Action Space）

绑定大量工具会消耗 token，且可能造成模型困惑。Manus 的解决方案是三层架构：

Level 1: Function Calling（函数调用层）

• 标准的、schema-safe 的调用方式
• 使用少量（< 20 个）原子函数：message, shell, search, file, browser 等
• ⚠️ 缺点：每次变化都会破坏 KV Cache，太多函数会导致上下文混淆

Level 2: Sandbox Utilities（沙箱工具层）

• 每个会话运行在完整的 VM 沙箱中
• 模型可以调用 shell 工具（CLI），如 $ manus-mcp-cli、$ manus-render-diagram
• ✅ 优点：易于扩展，无需修改模型上下文；适合大输出 → 写入文件

Level 3: Packages & APIs（包与 API 层）

• Manus 编写 Python 脚本来调用预授权的 API
• 适合数据密集型或链式任务
• 例如：fetch city → get ID → get weather → summarize
• ✅ 核心理念：保持模型上下文干净，只用上下文做推理

工具结果的卸载

• 工具结果卸载到文件系统，生成紧凑版引用
• 使用基本工具（如 glob 和 grep）搜索文件系统，无需索引或向量存储

设计理念

这与 Claude Code 的 Skills 功能^[5]理念相似——渐进式披露（Progressive Disclosure）。

Skills 存储在文件系统而非绑定为工具，Claude 只需几个简单的函数调用就能按需发现和使用它们。

三大策略的协同关系

这三个策略不是孤立的，而是相互支撑：

卸载 + 检索  →  使压缩成为可能（完整数据可按需恢复）     ↓可靠的检索  →  使隔离成为可能（子 Agent 可获取需要的上下文）     ↓隔离        →  减少压缩频率（每个子 Agent 有独立窗口）     ↓    所有策略都在 KV Cache 优化的框架下运作

模型路由策略

Manus 采用任务级路由，不同任务使用不同模型：

同时利用 KV Cache 优化成本和延迟。

构建时牢记 Bitter Lesson

Lance 在原文中将 Manus 的设计理念与**苦涩的教训（Bitter Lesson）^[6]**联系起来：

1. 保持简单和无偏见的设计——更容易适应模型改进
2. 接受持续变化——Manus 自 3 月发布以来已重构 5 次！
3. 避免限制性框架——Agent 的 harness 可能限制性能随模型提升

验证方法：跨模型测试

在 Peak 的分享中，被问及如何验证不同 Agent 有没有受到限制性框架影响智能时，他的方法是：

• 在不同强度的模型上运行 Agent 评估
• 如果性能没有随更强模型提升，说明你的框架正在拖累 Agent（harness is hobbling the agent）
• 这可以帮助验证你的架构是否「面向未来」（能够适应未来模型的进展）

正如 Hyung Won Chung^[7] 也曾建议道：

"Add structures needed for the given level of compute and data available. Remove them later, because these shortcuts will bottleneck further improvement."

（根据当前可用的计算和数据添加必要的结构，之后再移除它们，因为这些捷径会成为进一步改进的瓶颈。）

关于评测

Manus 最初也使用公开评测集（如 GAIA），但发现与实际用户行为和预期偏差很大。现在采用三层评测体系：

💡 启示：单一评测维度不够，需要结合用户反馈、自动化测试和人工评测才能全面评估 Agent 质量。

最后的忠告

Peak 在分享最后特别强调了一点：

More context ≠ more intelligence

更多上下文 ≠ 更多智能

Simplification beats expansion

简化优于扩展

Our biggest gains came from removing, not adding.

最大的收益来自移除，而非添加。

Keep the boundary clear — then get out of the model's way!

保持边界清晰，然后让开，别挡模型的路！

更多参考资源

网络研讨会资源

• Lance 的幻灯片^[8]
• Peak 的幻灯片^[9]

Anthropic 官方资源

• Effective Context Engineering for AI Agents^[10]
• Building Effective Agents^[11]
• Prompt Caching（KV Cache）^[12]

其他资源

• Erik Schluntz & Walden Yan 播客（Latent Space）^[13]
• Claude Code Task Tool 介绍^[14]