Manus：三大核心策略，破解AI Agent上下文膨胀难题 精华

当一个AI Agent完成一次任务平均要调用50次工具，海量工具结果不断涌入上下文窗口时，LLM的性能会不可避免地遭遇滑铁卢。Chroma的“上下文衰减”研究与Anthropic提出的“注意力预算耗尽”理论，都印证了这一痛点。

Manus作为当下热门的通用消费级AI Agent，其联合创始人兼首席战略官Yichao “Peak” Ji在 webinar 中，首次系统拆解了Manus的上下文工程核心逻辑。

以下是我整理出了这份能直接复用的实践指南。

一、为什么上下文工程是AI Agent的“生命线”？

在理解Manus的方案前，先要明确一个关键定义：Anthropic将AI Agent定义为“LLM自主引导流程、调用工具，掌控任务完成路径的系统”，本质是LLM循环调用工具的过程。

而这个过程中，最大的隐患藏在“上下文窗口”里：

1. 工具结果堆积：Manus单次任务平均触发50次工具调用，所有结果若全存进上下文，窗口会迅速被填满。
2. 性能持续衰减：随着上下文内容增多，LLM的注意力会被分散，就像人面对杂乱无章的书桌无法高效工作——Chroma称之为“上下文衰减”，Anthropic则解释为“注意力预算被耗尽”。
3. 行业共识明确：AI领域权威人物Karpathy直接点明，上下文工程的核心，就是“为Agent的每一步行动，精准填充上下文窗口所需的信息”。

二、Manus的3大上下文工程策略

Manus为每个会话分配独立虚拟机，让Agent拥有文件系统和终端工具。在此基础上，它通过“减少、卸载、隔离”三大策略，实现上下文窗口的高效管理。

策略1：Reduce（减少）——压缩与总结双管齐下

Manus为工具调用结果设计“完整版”和“精简版”两种形态：

• 完整版：存储原始工具结果（如完整搜索内容），但仅保存在沙盒文件系统中，不占用上下文窗口。

• 精简版：仅保留完整结果的引用（如文件路径“/home/ubuntu/foo.txt”），直接放入上下文窗口。

当Agent接近上下文窗口上限时，系统会自动触发压缩机制：

1. 将旧工具结果的“完整版”替换为“精简版”，释放窗口空间。
2. 新工具结果仍保留“完整版”，确保Agent能基于最新信息决策。
3. 当压缩效果达到瓶颈时，启动总结机制——按预设 schema 生成工具结果摘要，保证不同任务的摘要格式统一，进一步节省空间。

策略2：Offload（卸载）——构建分层行动空间

很多开发者会为Agent配置大量工具，但这会导致两个问题：工具描述占用大量 tokens，且工具间的重叠、模糊会让LLM confusion。 Manus的解决方案是“分层行动空间”：

• 函数调用层：仅保留不到20个“原子函数”，如shell（执行终端命令）、text editor（读写文件）、search（搜索）等。这些函数功能通用，能覆盖绝大多数任务需求。
• 沙盒层：将大量工具（如语音工具、MCP CLI命令）转移到沙盒中，以终端命令形式存在。Agent无需记忆这些工具的细节，只需通过“--help”命令即可随时查看用法。

这种设计不仅减少了上下文窗口中工具描述的占用，还降低了LLM的认知负担——无需在众多工具中做选择，只需调用通用函数，再在沙盒中执行具体命令。

策略3：Isolate（隔离）——用子Agent实现上下文隔离

Manus不采用“拟人化分工”（如设计“设计师Agent”、“工程师Agent”），而是仅保留3类核心子Agent，避免跨Agent通信的冗余：

• 规划者（Planner）：负责任务管理，决定何时调用其他子Agent。
• 知识管理者：梳理对话内容，判断哪些信息需要存入文件系统。
• 执行者（Executor）：接收规划者指令，完成具体任务。

子Agent与主Agent的上下文交互分两种场景：

• 简单任务：规划者仅向执行者发送任务指令，执行者完成后返回结果（类似Claude Code的任务工具）。
• 复杂任务：规划者向执行者共享完整上下文（如全部对话历史），但执行者仍拥有独立的工具库和提示词，确保任务执行的独立性。

无论哪种场景，规划者都会为执行者定义输出schema，并通过“约束解码”技术，保证执行者的结果符合格式要求，避免上下文混乱。

2.1 模型选择：成本优先，混合搭配

Manus的模型选择核心是“KV缓存效率”：

• 大量使用缓存技术（如缓存系统指令、重复内容），降低成本和延迟。
• 优先选择支持分布式KV缓存的前沿模型（如Claude、Gemini、OpenAI），这类模型虽看似昂贵，但缓存带来的成本节省，实际比开源模型更划算。
• 不绑定单一模型，而是按任务路由：编码用Claude，多模态任务用Gemini，数学推理用OpenAI，最大化不同模型的优势。

2.2 拥抱“痛苦教训”，设计可进化架构

Manus团队深受“Bitter Lesson”（痛苦教训）理论影响——AI的进步往往来自计算能力的提升，而非复杂的结构设计。

因此，他们的开发理念有两个核心：

1. 频繁重构：自2025年3月上线以来，Manus已重构5次，不断适配模型能力的提升。
2. 持续评估：定期用不同强度的模型测试Agent性能。如果更强的模型无法提升Agent表现，说明当前的架构（如Agent的“ harness ”框架）已成为瓶颈，需要及时调整。

三、最后总结AI Agent上下文管理的6条实践启示

从Manus的实践中，我们可以提炼出6条能直接复用的经验：

1. 上下文管理的核心是“精准”——只在窗口中保留Agent下一步需要的信息。
2. 工具设计宜“精”不宜“多”，通用原子函数+沙盒工具的组合，比大量专用工具更高效。
3. 子Agent的价值是“隔离上下文”，而非“拟人化分工”，过多子Agent会增加通信成本。
4. 缓存是降低模型成本的关键，优先选择支持分布式KV缓存的模型。
5. 架构设计要“留有余地”，避免过度结构化，以便适配模型能力的快速提升。
6. 定期用更强模型测试Agent，及时发现并打破架构瓶颈。

AI Agent的竞争，本质是“效率”的竞争——而上下文窗口的管理效率，直接决定了Agent的性能上限。Manus的实践证明，通过科学的策略，即使是平均50次工具调用的任务，也能让LLM始终保持高效运转。

本文转载自​​CourseAI​​，作者：CourseAI