ManusAI使用揭秘：上下文工程如何提升智能体性能

说实话，ManusAI 与传统 AI 最大的差异并不在于底层模型有多“聪明”——真正的核心竞争力藏在上下文工程（Context Engineering）中。它并非那种需要你一步一步喂指令的“被动工具”，更像一个自带工作流的小型自动化团队：自主规划、自动调用工具、独立读写文件，最终将成品完整交付。而决定这个“团队”能否稳定产出、不中途掉链子的核心，正是背后那套精密的上下文工程机制。以下直接给出几个关键判断：

把上下文当运行内存管理，而非聊天记录

传统 AI 助手有一个通病：每次对话就像往抽屉里随意堆杂物，上下文越长越混乱。Manus 的解决方案是将上下文视为一块有限的运行内存，进行精细化调度：

• 只保留当前决策所必需的关键信息。旧的工具执行结果会被自动压缩成一条路径引用（例如 /sandbox/output_12.json），实际内容存储在外部，绝不占用宝贵的上下文空间。
• 当上下文窗口接近满载时，系统会优先将早期完整日志替换为摘要，但最近三次调用的完整数据始终保留，确保推理链条不会断裂。
• 所有系统提示均使用固定前缀，屏蔽时间戳、随机 ID 等干扰项，使 KV 缓存命中率稳定维持在 90% 以上。

借助文件系统突破“记忆”容量瓶颈

即便上下文窗口高达 128K，也难以应对数十步任务的累积消耗。Manus 的做法非常直接：将外部文件系统当作一块“外置硬盘”来使用。

• 网页抓取结果不会回填到上下文中，而是写入 fetched_page.html，并记录路径供后续调用。
• 代码执行日志存储到 /log/run_20260523_01.log，上下文中仅保留一句“已执行并保存日志”的结论。
• 即便任务失败，错误信息也会原封不动存入 /error/attempt_7.txt，既不删除也不隐藏，方便后续步骤复盘与修正。

目标锚定与动态卸载，防止注意力漂移

长链任务最怕“中途跑偏”。Manus 通过两种轻量级机制，牢牢锁定核心意图：

• 每轮操作结束时，系统会自动将待办事项清单（todo.md）的最新版本最后一行复述，并放置在上下文最底部，形成一个自然语言锚点。这相当于反复提醒“我们当前的任务是什么”，有效避免注意力分散。
• 工具调用采用分层处理：像原子函数这类轻量级操作（少于 20 个 token），留在模型可直接调用的层级；而语音转写、PDF 解析等重载工具，则下沉到沙盒命令行中，通过 shell("mcp pdf-parse input.pdf") 间接调用，大幅节省描述所需的 token 开销。

不微调模型，只优化上下文，实现快速迭代

Manus 团队在过去六次架构重构中，从未依赖微调模型来解决问题，所有精力都集中在上下文工程的打磨上：

• 采用“只追加不修改”策略，保证序列化的确定性，避免缓存失效。
• 引入可控的随机性——在少样本模板中微调措辞顺序或标点风格，打破可能出现的固化行为模式。
• 混合调度不同模型：Claude 处理代码逻辑、Gemini 解析截图、OpenAI 进行数学验证，按需路由，不强行将所有任务塞给单一模型。