Suda：上下文工程：理解 Agent 的统一框架｜从 Manus 到 Anthropic 的工程实践

Suda：上下文工程：理解 Agent 的统一框架｜从 Manus 到 Anthropic 的工程实践 Suda：上下文工程：理解 Agent 的统一框架｜从 Manus 到 Anthropic 的工程实践 Modified January 7 • 核心机制 ： Hybrid Search（混合检索） 。 系统并不直接读取实时文件，而是查询预生成的 向量索引（查语义）和关键词索引（查精确字符） 。它试图通过预判，将数万个文件瞬间压缩为最相关的几十个片段。 • 工程哲学 ： Latency First（时延优先） 。 ◦ 这是典型的“空间换时间”。 ◦ 优势 ： 极速 。用户按下 Tab 的瞬间，Context 必须到位。 ◦ 代价 ： 滞后性 。索引只是代码的影子，如果文件变更后索引未及时刷新，检索结果就会过时。 (2) 技术流派 B：Agentic Search（代理式搜索） 这是 Claude Code、Cline 等 Agent 的选择。它的核心逻辑是 “查现场” ——直接让 LLM 拿着工具去探索。 • 核心机制 ： Native Tool Use（原生工具链） 。 • 完全摒弃外部数据库，Agent 像人类工程师一样，在终端执行 ls （看目录结构）、 grep （搜关键词）、 cat （读文件内容）。 • 降噪策略 ： 逻辑过滤 。 它不是靠“算”出来的相关性，而是靠“看”出来的逻辑。Agent 会根据文件名和目录结构，通过 Chain of Thought (CoT) 主动判断并忽略无关文件，一层层“摸”出核心代码。 • 工程哲学 ： Truth First（真相优先） 。 ◦ 这是典型的“时间换准确”。 ◦ 优势 ： 极高的一致性 。它读取的是磁盘上此时此刻的字节（Ground Truth）， 最大程度规避了 因索引滞后或切片错误导致的“检索性幻觉”。 ◦ 代价 ： 高昂 。每一次搜索都是多轮昂贵的 LLM 推理，速度慢且费钱。 (3) 辅助 (Assistance) vs. 自主 (Agency) • Cursor (Assistance) ： 目标是“补强人类” 。即使有偏差，用户就在光标旁，可以毫秒级修正。因此，它优先选择极速的索引，通过高频交互来弥补精度的不足。 • Claude Code (High Agency) ： • 目标是“代理任务” 。无论用户是否在环（甚至开启危险模式全自动运行），系统都需要维持极长的推理链条。在这种高自主性模式下，Context 的任何一点“幻觉”都会在推理链中被放大，导致任务失败。因此，它必须牺牲速度，使用笨重但最可靠的现场搜索。 (4) 趋势：殊途同归 值得注意的是， Agentic Search 正成为行业标配 。 就连“索引派”的代表 Cursor，在最新的 Agent 模式中也开始引入实时搜索能力。 • 混合模式 ： Cursor 不再单纯依赖数据库快照。当遇到索引匹配度低或需要高精度修改的任务时，它也会像 Claude Code 一样，调用 grep 等工具进行 二次确认 。 • 核心逻辑 ： 当 AI 从“回答问题”变成“修改代码”时，准确度变得压倒一切。这就是为什么连 Cursor 这种追求极速的 IDE，也不得不引入慢速的实时搜索 —— 因为在写代码这件事上，准比快更重要。 实战要点与演进 (1) Anthropic 的官方心法 XML 标签隔离： • Anthropic 强烈建议使用 <instructions 等标签。 • 价值 ：利用 LLM 对 XML 结构的敏感度，物理隔离指令与数据，减少混淆。 显式思考 (Explicit Thinking / CoT) ： • 原则 ：要求模型在调用工具前，先在 <thinking 标签中输出推理过程。 • 价值 ：强制模型“先想后做”，能显著降低工具参数错误和幻觉调用的概率。 Think Tool（草稿纸模式） ： • 最新实践 ：Anthropic 在 Claude 3.7 的最佳实践中推荐定义一个 不执行任何操作、只记录思考过程 的工具 think tool 。 • 核心机制 ： Hybrid Search（混合检索） 。 系统并不直接读取实时文件，而是查询预生成的 向量索引（查语义）和关键词索引（查精确字符） 。它试图通过预判，将数万个文件瞬间压缩为最相关的几十个片段。 • 工程哲学 ： Latency First（时延优先） 。 ◦ 这是典型的“空间换时间”。 ◦ 优势 ： 极速 。用户按下 Tab 的瞬间，Context 必须到位。 ◦ 代价 ： 滞后性 。索引只是代码的影子，如果文件变更后索引未及时刷新，检索结果就会过时。 ◦ 这是典型的“空间换时间”。 ◦ 优势 ： 极速 。用户按下 Tab 的瞬间，Context 必须到位。 ◦ 代价 ： 滞后性 。索引只是代码的影子，如果文件变更后索引未及时刷新，检索结果就会过时。 (2) 技术流派 B：Agentic Search（代理式搜索） 这是 Claude Code、Cline 等 Agent 的选择。它的核心逻辑是 “查现场” ——直接让 LLM 拿着工具去探索。 • 核心机制 ： Native Tool Use（原生工具链） 。 • 完全摒弃外部数据库，Agent 像人类工程师一样，在终端执行 ls （看目录结构）、 grep （搜关键词）、 cat （读文件内容）。 • 降噪策略 ： 逻辑过滤 。 它不是靠“算”出来的相关性，而是靠“看”出来的逻辑。Agent 会根据文件名和目录结构，通过 Chain of Thought (CoT) 主动判断并忽略无关文件，一层层“摸”出核心代码。 • 工程哲学 ： Truth First（真相优先） 。 ◦ 这是典型的“时间换准确”。 ◦ 优势 ： 极高的一致性 。它读取的是磁盘上此时此刻的字节（Ground Truth）， 最大程度规避了 因索引滞后或切片错误导致的“检索性幻觉”。 ◦ 代价 ： 高昂 。每一次搜索都是多轮昂贵的 LLM 推理，速度慢且费钱。 ◦ 这是典型的“时间换准确”。 ◦ 优势 ： 极高的一致性 。它读取的是磁盘上此时此刻的字节（Ground Truth）， 最大程度规避了 因索引滞后或切片错误导致的“检索性幻觉”。 ◦ 代价 ： 高昂 。每一次搜索都是多轮昂贵的 LLM 推理，速度慢且费钱。 (3) 辅助 (Assistance) vs. 自主 (Agency) • Cursor (Assistance) ： 目标是“补强人类” 。即使有偏差，用户就在光标旁，可以毫秒级修正。因此，它优先选择极速的索引，通过高频交互来弥补精度的不足。 • Claude Code (High Agency) ： • 目标是“代理任务” 。无论用户是否在环（甚至开启危险模式全自动运行），系统都需要维持极长的推理链条。在这种高自主性模式下，Context 的任何一点“幻觉”都会在推理链中被放大，导致任务失败。因此，它必须牺牲速度，使用笨重但最可靠的现场搜索。 (4) 趋势：殊途同归 值得注意的是， Agentic Search 正成为行业标配 。 就连“索引派”的代表 Cursor，在最新的 Agent 模式中也开始引入实时搜索能力。 • 混合模式 ： Cursor 不再单纯依赖数据库快照。当遇到索引匹配度低或需要高精度修改的任务时，它也会像 Claude Code 一样，调用 grep 等工具进行 二次确认 。 • 核心逻辑 ： 当 AI 从“回答问题”变成“修改代码”时，准确度变得压倒一切。这就是为什么连 Cursor 这种追求极速的 IDE，也不得不引入慢速的实时搜索 —— 因为在写代码这件事上，准比快更重要。 实战要点与演进 (1) Anthropic 的官方心法 XML 标签隔离： • Anthropic 强烈建议使用 <instructions 等标签。 • 价值 ：利用 LLM 对 XML 结构的敏感度，物理隔离指令与数据，减少混淆。 显式思考 (Explicit Thinking / CoT) ： • 原则 ：要求模型在调用工具前，先在 <thinking 标签中输出推理过程。 • 价值 ：强制模型“先想后做”，能显著降低工具参数错误和幻觉调用的概率。 Think Tool（草稿纸模式） ： • 最新实践 ：Anthropic 在 Claude 3.7 的最佳实践中推荐定义一个 不执行任何操作、只记录思考过程 的工具 think tool 。 • 机制 ：在执行复杂任务前，强制模型先调用这个工具把“检查清单”或“推理步骤”写下来。 • 对比 ：相比于 XML 标签， 工具调用 的形式能让模型进入更深层的“执行模式”，在处理复杂规则（如航空退改签）时，成功率提升了 54% 。 • 何时使用？ ◦ 工具输出分析 ：当模型需要仔细处理上一步工具返回的复杂结果（如长日志），甚至可能需要回溯时。 ◦ 政策密集型环境 ：当模型必须严格遵守复杂的合规指南（如金融风控、法律审核）时。 ◦ 高风险序列决策 ：当每一步都依赖上一步，且一旦出错代价高昂（如数据库迁移、线上环境操作）时。 ◦ 工具输出分析 ：当模型需要仔细处理上一步工具返回的复杂结果（如长日志），甚至可能需要回溯时。 ◦ 政策密集型环境 ：当模型必须严格遵守复杂的合规指南（如金融风控、法律审核）时。 ◦ 高风险序列决策 ：当每一步都依赖上一步，且一旦出错代价高昂（如数据库迁移、线上环境操作）时。 （注：这与 Manus 的 todo.md 异曲同工，但粒度更细——Manus 关注宏观的任务进度，Think Tool 关注微观的执行逻辑。） Prompt 颗粒度的黄金区间 ： • 原则 ：寻找“死板逻辑”与“模糊指令”之间的平衡点。 ❌ 太低 ：像写代码一样硬编码复杂的 if else 流程。 后果：脆弱且难维护。 ❌ 太高 ：只给模糊的高层指令（如“请按规范执行”）。 后果：模型无所适从，易产生幻觉。 ✅ 正解：启发式规则提供清晰的判断原则 和 验收标准 ，而非具体步骤。 • 示例：“修改前必须先运行测试”（原则） “第一步输入 pytest，第二步检查输出……”（步骤）。让模型在约束内自主推理。 工具设计的防错与截断 ： • 防错 ：通过参数枚举、类型限制，让模型“很难犯错”。 • 默认截断 ：工具不应默认返回全量数据（如 list files 返回 1000 个文件），而应默认返回摘要或分页（前 50 个）。 从源头控制 Token 噪音。 基于轨迹的迭代 ： • 正解 : Start Minimal（从最小 Prompt 开始），然后 深入阅读原始交互轨迹 (Raw Traces) 。观察模型在哪里犹豫、哪里死循环，针对性地打补丁。 Few shot 的选择 ： • 原则 ：典型示例 边缘示例。 ✅ 正解 ：精心筛选一组 多元化的典型示例 ，像教科书例题一样展示核心逻辑，一张图抵千言。 ❌ 误区 ：试图在 Prompt 里堆砌一长串边缘案例。这不仅浪费 Token，还会让模型过拟合于角落情况而忽略主干逻辑。 (2) Manus 的野战生存法则 对抗“Few shot 陷阱” ： • 问题 ：Few shot 是教学工具，但在长链路中会变成陷阱。模型会陷入“自动驾驶”的机械模仿。 • 解法 ：在 Output 中引入 结构化变化 （不同的序列化模板、替代性措辞、顺序或格式上的微小噪音），强制打破惯性。 数据工程：Line based 格式偏好 ： • 原则 ：优先使用 纯文本/代码 ，而非 Markdown. • 理由 ：这允许模型高效利用 grep 、 head 或 sed 进行按行切片读取。相比之下，使用 Markdown 很容易输出太多 Bullet Points。 反直觉认知：保留错误信息 ： • 真相 ： 擦除失败 = 移除证据 。保留错误能帮助模型修正先验分布，知道“此路不通”。 架构演进：Planning 的迭代 ： • 背景：目标漂移 。随着 Context 变长，Transformer 对中间信息的捕捉能力减弱 (Lost in the Middle)。 阶段1：注意力锚点 (todo.md) • 机制 ：强制 Agent 每轮复写 /workspace/todo.md 。 • 弊端 ：典型的 Prompt 技巧。 Token 浪费严重 （1/3 的 Action 都在复读），且频繁 I/O 增加延迟。 （注：Claude Code 仍在使用 Structured Note taking。Anthropic 认为它在具有明确里程碑的迭代开发中表现优异，适合用来“记账”和“防忘”。） 阶段2：架构解耦 (Planner Agent) 。 • 机制 ：升级为 Agent as Tool 范式。主 Agent 按需调用独立的 Planner。 • 优势 ： ◦ 外部审查 ：Planner 拥有独立 Context，不受执行细节干扰，能“清醒”地审视全局。 ◦ 模型异构化 ：规划可以用更强的推理模型（如 Grok 或 o1 ），执行用速度更快的模型。 ◦ 成本优化 ：不再占用主循环的 Token，只在关键节点介入。 ◦ 外部审查 ：Planner 拥有独立 Context，不受执行细节干扰，能“清醒”地审视全局。 ◦ 模型异构化 ：规划可以用更强的推理模型（如 Grok 或 o1 ），执行用速度更快的模型。 ◦ 成本优化 ：不再占用主循环的 Token，只在关键节点介入。 终极哲学：Less Structure, More Intelligence 无论是 Manus 还是 Anthropic，背后都指向同一个工程哲学： 去脚手架化 。 这不是某一家公司的特色，而是整个 Agent 工程领域正在形成的共识： 一个优秀的 Agent 架构，应该随着底层模型的变强而变得更简单。 如果你的系统随着时间推移，规则越来越多、Layer 越来越厚，说明你在用“堆砌代码”来对抗“智能不足”。这与 AI 的摩尔定律背道而驰。过去为弥补模型缺陷而发明的复杂流程，在强模型面前反而成了束缚。 那么，如何判断你的架构是在“顺应智能”，还是在“对抗智能”？ 唯一的验证标准：模型切换测试 有一个最简单也最有效的测试方法： 固定架构，切换模型。 • 明天的弱模型 = 今天的强模型 • 如果在不改代码的情况下，仅仅把模型升级，你的 Agent 表现显著提升，说明你的架构具有 未来适应性 。 • 如果换了更强的模型，效果反而没变甚至变差（因为被你的规则限制住了），说明你的架构在“对抗智能”。 Context Engineering 不是让模型的工作更难，而是更简单。 所以如果你今天只记住一件事： 少构建，多理解。相信模型，简化架构，让智能涌现。 写在最后：从 Manus 到行业标准 Context Engineering 不是某个产品的特性，它是 Agent 开发的底层范式。 Manus 的三层动作空间设计如此优雅，以至于 Anthropic 几乎是将这套 Context Offloading 理念直接产品化为了 Claude Skills 。 行业实证：Claude Skills 的核心机制 • 本质 ：一个 Markdown 文件 + 可选的预写脚本。 • 按需加载 ：Claude 启动时只读取每个 Skill 的简短描述（几十个 Token），只有在任务真正需要时，才加载包含数千 Token 的完整内容。 • 评价 ：这正是一种极其优雅的、受 Manus 架构理念启发的 Context Offloading 产品级实现。 趋势验证 ： 2025 年 12 月， OpenAI 也悄悄跟进了这一机制。开发者发现 ChatGPT 的 Code Interpreter 现在有了 /home/oai/skills 文件夹，且 Codex CLI 也新增了 skills.md 支持，实现方式与前两者几乎一模一样。 Manus 的工程实践 → Anthropic 的产品化 → OpenAI 的跟进。 这个演进路径清晰地证明了：上下文工程范式正在成为行业共识。Agent 落地的核心不只是模型能力，更是 Context Engineering 的工程范式。 我是Suda ，一名在探索 AI 产品边界的产品经理。 这篇文章是我试图解构 Agent 产品体验与工程边界的一次尝试。我认为，不懂 Context Engineering 的 PM 无法设计出真正可落地的 Agent 产品。 目前正在寻找 AI 产品经理的岗位 ，如果你的团队有合适机会，欢迎加我微信：Suda Lulu 如果这篇文章对你有帮助，欢迎交流～ 参考资料 1. Manus 官方博客：AI 代理的上下文工程——构建 Manus 的经验教训 2. LangChain x Manus 播客：Context Engineering for AI Agents 3. Anthropic 工程博客：AI 代理的有效上下文工程 4. Anthropic 工程博客：Think Tool — Claude 在复杂工具调用中的思考机制 5. Drew Breunig：上下文失效的原因与修复方法 🔗 Source link: https://mp.weixin.qq.com/s? biz=Mz... https://mp.weixin.qq.com/s? biz=Mz... Original Suda探险家 苏打气泡档案2025年12月17日 19:43 广东 这篇笔记是我对 Manus 官方博客、LangChain 播客访谈以及 Anthropic 技术博客等资料的系统性梳理。 之前对 Context Engineering（上下文工程） 的学习比较零散，这次试图将这些碎片拼凑起来，形成一个完整的认知框架。除了这篇整合笔记，也非常推荐大家去阅读文末的原始材料。 什么是 Context Engineering? Anthropic 将其定义为 “策划和维护最优 Token 集合的一系列策略”。 而 Andrej Karpathy 给出了更直击本质的描述：“ 上下文工程，是用恰到好处的信息填充上下文窗口以进行下一步的精妙艺术和科学。” 真实的困境：为什么你的 Agent 越跑越蠢？ 从 Cursor 到 Claude Code，从 Devin 到 Manus，Agent 正在重新定义软件开发。但当你真正开始构建生产级 Agent 时，会遇到一个残酷的现实。 你的 Agent 跑了一次任务，成本可能高达 5 美元，但这还不是最糟的。最糟的是，在第 45 轮工具调用时，它彻底忘记了第 1 步设定的核心目标，开始在一个错误的死胡同里打转；或者，当你加了第 31 个工具时，它开始疯狂调用根本不存在的 API。 这就是 Context Rot （上下文腐化） 。 Agent 需要大量上下文来决策，但上下文越多，模型表现越差。即使模型宣称支持 100 万 tokens，实际上到了 128K 200K，推理能力就会出现显著的“智商跳水”。 Manus 的战略选择：为什么不微调，也不用开源模型？ Manus 曾明确表示，他们在早期尝试过各种方向，最终做出了两个在当时看来颇为“反共识”的战略决定： 不进行模型微调，也不自建开源模型推理。 这不是妥协，而是基于极度理性的 ROI 计算。 (1) 拒绝 Fine tune：不要试图重建地基 Manus 发现，试图通过 Fine tune 来提升 Agent 能力，本质上是在对抗 AI 的摩尔定律。 • RL（强化学习） 的陷阱 ：强化学习需要固定的“动作空间”。但 MCP 标准发布后，工具生态变成了无限开放的宇宙。想用 RL 覆盖无限的工具？这是死路一条。 • 你卷不过巨头 ：如果你想训练一个能完美支持海量工具的模型，你实际上是在做 OpenAI 和 Anthropic 该做的事——重建 Foundation Model • 被锁死的创新 ：应用层公司的生死在于产品迭代速度。如果产品更新依赖模型重新训练，你的迭代周期将被拉长 10 倍，还没上线就过时了。 (2) 拒绝开源模型：“免费”的才是最贵的 在决定不训练模型后，Manus 紧接着做出了第二个反直觉的决定： 放弃自托管开源模型。 很多人认为开源模型没有 Token 费，所以更便宜。 然而在 Agent 场景下，却并非如此。 • Agent 的流量特征 (Input Output) ：Agent 任务的典型特征是输入远大于输出（Manus 实测约为 100:1）。每次迭代都在追加新的上下文，模型需要反复“阅读”之前的 99% 内容。 • 真正的成本公式 ：推理成本 ≠ Token 单价。单纯的生成 Token 确实便宜，但处理海量历史信息需要庞大的算力。 • 基础设施的隐形门槛 ：这里涉及到一个关键的成本因素—— KV Cache（键值缓存） 。 （注：关于 KV Cache 的技术原理，我们将在后文详细拆解） 自建一套能高效处理 200k+ 上下文的分布式缓存系统门槛极高。如果做不到极致优化，成本和延迟将呈指数级上升。而前沿 LLM 提供商已经通过规模效应均摊了这部分基建成本。 算一笔账 ：以 Claude Sonnet 4.5 为例，命中缓存的价格仅为未命中价格的 1/10 。这意味着，直接调用拥有成熟基建的旗舰模型，往往比你自己跑一个没有深度优化的开源模型 更便宜、更快 。 (3) 核心哲学 基于上述两个否定，Manus 得出了最终的战略定位： “Context Engineering 是应用和模型之间最清晰、最实用的边界。” 既然模型权重难以改变，那就把所有复杂的业务逻辑和工具调度，都内化为 Context 的管理艺术。 这不仅是技术选择，更是商业壁垒 ： • Context Engineering 是应用层公司目前 ROI 最高的手段。 • 模型能力会随着时间被拉平，但 如何高效利用这些能力 ，才是应用层公司真正的护城河。 理论基础：四种上下文失效模式 Context Poisoning（上下文中毒） 核心问题 ：幻觉或错误信息进入上下文后被反复引用。 典型表现 ：Agent 开始追求不可能或不相关的目标，陷入基于错误前提的执行循环。 Context Distraction（上下文分散） 核心问题 ：上下文过长导致注意力分散。 典型表现 ：Agent 倾向于重复历史行为而非制定新计划，这种现象在上下文超过 100K tokens 后尤为明显。模型会陷入"自动驾驶"模式，机械地模仿之前的操作。 Context Confusion（上下文混乱） 核心问题 ：多余内容导致模型生成低质量响应。 典型表现 ：常见于工具过多且描述重叠的场景。研究显示，当工具数量超过 30 个时，模型的决策质量开始显著恶化，出现"选择困难症"甚至调用不存在的工具。 Context Clash（上下文冲突） 核心问题 ：新信息或工具与已有上下文信息冲突。 典型表现 ：研究表明，分阶段输入信息比一次性输入效果差 39%。这是因为模型会基于早期不完整信息做出假设，而当后续信息与这些假设冲突时，模型很难自我修正，陷入认知僵化。 五大核心技术：从问题到解决方案 1️⃣ Context Caching（上下文缓存） 在深入具体技术之前，必须先理解一个底层约束： KV Cache 。 它就像你手机后台的“最近使用”列表，保存了之前处理过的内容。 通俗点说，就是让模型不要每次都从头读一遍《红楼梦》，而是直接从上次的书签接着读。 如果没有它，Agent 每走一步，都要把之前几十轮的对话、代码、文档重新计算一遍。在 Agent 系统中， 这个缓存是成本和延迟的核心决定因素 。 所有后续的技术决策——无论是上下文压缩、工具管理还是 Multi Agent 架构——都必须遵循一个最高准则： "Protect the KV Cache"。 “KV cache 命中率是生产阶段 AI Agent 最重要的单一指标 。" 核心工程实践：Design Around the KV Cache 为了最大化缓存命中率，Agent 的 Prompt 工程必须遵循以下三条铁律： 实践一：保持提示前缀稳定 由于 LLM 是基于 Token 顺序生成的， 即使前缀中变动了一个 Token，后面所有的缓存都会失效 。 ❌ 常见错误 ：把当前时间 ( datetime.now() ) 或变动的用户状态写在 System Prompt 里。这会导致每次请求的哈希值都不同，缓存全部失效，成本飙升 10 倍。 ✅ 正确做法 ： System Prompt 必须是静态常量 。动态信息通过工具获取，或放在 Context 最末端。 实践二：只追加，不修改 (Append only) 避免修改之前的操作或观察。一旦你为了“修正”某个历史记录而修改了第 5 轮对话的一个字，从第 5 轮到第 50 轮的所有缓存将全部作废。 ⚠️ 隐蔽陷阱 ： JSON 序列化的非确定性 . Python 的 dict 默认顺序可能不稳定，导致 {"a":1, "b":2} 和 {"b":2, "a":1} 被视为不同的 Token 序列。 ✅ 正确做法 ：始终使用 json.dumps(data, sort keys=True) 强制排序。 实践三：明确标记缓存断点 (Explicit Breakpoints) 某些模型提供商或推理框架（如 vLLM）不支持全自动的增量前缀缓存，或者需要显式声明“这里我想存个档”。 • 至少确保在 System Prompt 之后设置一个断点。 • 在加载完庞大的 Few shot Examples 之后设置一个断点。 Caching 的局限性 Context Caching 是一项伟大的工程优化，但它只解决了一半的问题： ✅ 解决 ：延迟（Latency）和成本（Cost)。 ❌ 未解决 ：上下文腐化（Context Rot）和模型推理能力的下降。 即使缓存了 200k tokens 且读取成本很低，模型在处理这 200k 信息时的 注意力分散 和 逻辑混乱 依然存在。因此，Caching 是基础，之后的 Offloading（卸载） 和 Reduction（压缩） 才是解决智能下降的关键。 2️⃣ Context Offloading （上下文卸载） Context 爆炸有两个层面的挑战： 工具输出 占满空间，以及 工具定义 本身占满空间。这两者需要截然不同的应对策略。 (1) 第一层挑战：工具输出 Agent 抓取一个网页可能包含 50K tokens 的 HTML，几次操作下来，Context 会瞬间挤爆窗口。 方案：文件系统即外挂显存 • 做法 ：将大块数据（网页、日志、API 响应）写入文件系统。 • 模型行为 ：模型学会按需调用 grep 、 head 或 Python 脚本读取文件。这不仅解决了空间问题，还将文件系统变成了一种结构化的、持久的外部记忆。 (2) 第二层挑战：工具定义 随着集成 MCP，工具数量迅速膨胀。30 个工具的定义可能占用 6K tokens，100 个工具则高达 20K。更糟的是 Context Confusion ：工具太多会导致模型出现“选择困难症”，甚至因为 Few shot 效应而在历史记录中模仿已下线的工具。 ❌ 传统误区：Dynamic RAG （动态检索） 直观的想法是：像检索知识库一样检索工具，只把当前任务相关的 5 个工具放入 Context。 但存在2个问题： • KV Cache 频繁失效 ：工具定义位于 Prompt 前端。每次根据任务换一批工具，前缀就变了，导致 缓存雪崩 。成本飙升 10 倍，延迟显著增加。 • 状态不一致与幻觉 ：历史对话中可能包含“已被移除工具”的调用记录。模型看到历史里用了 Tool A，但当前列表里没有 Tool A，这种冲突极易引发幻觉。 ✅ Manus 方案：两层互补策略 Manus 的思路不是“动态修改 Context”，而是 “架构减法 + 解码约束” 。 A. 架构层：三层行动空间 (Three Layer Action Space) 从源头减少暴露给模型的工具数量，将复杂性下沉。 1. Function Calls （原子层 模型可见） ◦ 定义 ：只保留最核心的 10 15 个原子工具（ read file , write file , shell exec , browser ）。 ◦ 适用场景 ： 结构化、强规范交互 。需要模型精确控制参数的任务（如填表单、点击特定网页元素）。 ◦ 核心优势 ： 最大化 KV Cache 命中率 。工具定义极度稳定，几乎不修改，从源头避免 Context Confusion。 ◦