干货满满，Manus 在 Context Engineering 上的实践和经验｜通用 Agent 的生存指南

干货满满，Manus 在 Context Engineering 上的实践和经验｜通用 Agent 的生存指南 干货满满，Manus 在 Context Engineering 上的实践和经验｜通用 Agent 的生存指南 Modified January 4 刚用 Manus 有个印象觉得它特别像人，就是会记 todo.md 文件，并在任务进行中不断更新、勾选已完成的项目。 这其实是一种非常有效的操控注意力的刻意机制，使用自然语言来使 Agent 的注意力偏向任务目标，而不需要特殊的架构变更。 现在在更多的 Agent 产品中，尤其 Vibe Coding 类，被普遍使用。 一个典型的 Manus 任务平均需要 50 次工具调用。在这么长的循环中，模型很容易偏离主题或忘记早期目标，尤其是长上下文中的“中间丢失”（lost in the middle）现象。 通过不断更新待办事项列表，Manus 将其目标复述到上下文的末尾，将全局计划推入模型的近期注意力范围内。 最新 Manus 将有效但浪费较多 token 的 TODO 文件方式，换成单独的规划器来管理计划，也是一种“Agent as a Tool”的设计。 另一个反直觉的经验， 将错误的尝试保留在上下文中，是改善 Agent 行为最有效的方法之一。 常见的产品设计上遇到报错的本能是隐藏错误，清理痕迹、重试操作、重置状态。但代价就是，擦除失败会移除证据，模型永远学不会错误恢复。 Manus 的实践是，错误是最好的学习材料，当模型看到失败的动作和堆栈跟踪时，会隐式更新内部“先验”，降低重复犯错的概率。比人工设计的纠错机制更有效。 错误恢复是真正 Agent 行为的最明显指标之一。 真实世界什么情况都有， Agent 必须学会在迷雾中前行。大多数学术基准测试的都是“理想状态”，完全忽略了错误恢复能力。 Few Shot 是提高 LLM 输出的常用技术，但在 Agent 系统中可能适得其反。它教会模型“怎么做”，但也可能让模型“只会这么做”。 大语言模型是优秀的模仿者。如果你的上下文充满了类似的过去动作 观察对，模型会倾向于遵循该模式，即使这不再是最优的。上下文越单调，Agent 越脆弱。 举例审查 20 份简历时，Agent 通常会陷入一种僵化节奏，仅仅因为这是它在上下文中看到的，就重复类似的动作。 Manus 的实践是 增加可控随机性和多样性，逼模型根据当前状态决策，而不是照搬历史，在动作和观察中引入少量的结构化变化，不同的序列化模板，替代性措辞，顺序或格式上的微小噪音 ，这种受控随机性打破模式，调整注意力 Manus 早期用 Gaia 等公开学术基准，结果发现与用户偏好严重错位。在 Gaia 得分高的模型用户不喜欢。 Manus 的三种评估， 1. 用户反馈（金标准），每个完成会话后请求 1 5 星评分，这是唯一获取真实品味的指标 2. 内部自动化测试，可验证结果的任务，创建更专注执行的数据集而非推理题（因为大多数基准偏推理任务） 3. 真实人类评估，雇佣实习生评估网站生成、数据可视化等，无法用自动化指标评估 “很难设计好奖励模型判断输出是否视觉吸引，这关乎品味。” 有趣的是，Peak 最后说了一个跟上面分享的 Context Engineering 工程技巧相反的实践经验， Manus 推出后的六七个月，经历了五次重构。最大的飞跃不是来自添加更多花哨的上下文管理层，而是来自简化、移除不必要技巧，更多信任模型。 分享了一个测试 Agent 方法： 固定架构，切换模型，用“模型能力梯度”来评估架构质量。如果换成更强的模型性能大幅提升，说明架构未来可期。 没有过拟合当前模型的局限性 好架构应该让模型发挥全力，而不是设置障碍。每次简化都是在尽可能移除障碍，让模型更自由地表达能力 过度工程的诱惑永远存在，但克制是更高级的能力。Manus 刚推出的时候提出设计理念上的“ Less structure，More intelligence”，而现在是一脉相承的实践指引“Build Less，Understand more” 再回顾下上下文工程的五个维度， 1. 卸载（Offloading）：把数据移到文件系统 2. 缩减（Compaction/Summarization）：压缩历史 3. 检索（Retrieval）：按需读取 4. 隔离（Isolation）：子 Agent 管理 5. 缓存（Caching）：KV Cache 优化 这五个维度不是独立的，寻找动态平衡 • 卸载和检索让缩减更高效 • 稳定检索让隔离更安全 • 但隔离也减缓上下文增长，降低缩减频率 • 然而，更多隔离和缩减也会影响缓存效率和输出质量 “上下文工程是需要在多个可能冲突目标间找到完美平衡的科学与艺术。真的很难。” Peak 最后说，“如果你今天只记住一件事，我希望是：Build Less， Understand More”，“请避免上下文过度工程。” 看之前会认为 Context Engineering 是对 Agent 加更多层、更多技巧、更多控制。但 Manus 的经验告诉我们：上下文工程的目标是让模型工作更简单，而不是更难。 这需要对模型能力的信任，相信它能做到，会越来越强，而不是处处设护栏 。更需要我们克制对“我能替它做得更好”的诱惑，而专注在模型能力正交的事情上。 刚用 Manus 有个印象觉得它特别像人，就是会记 todo.md 文件，并在任务进行中不断更新、勾选已完成的项目。 这其实是一种非常有效的操控注意力的刻意机制，使用自然语言来使 Agent 的注意力偏向任务目标，而不需要特殊的架构变更。 现在在更多的 Agent 产品中，尤其 Vibe Coding 类，被普遍使用。 一个典型的 Manus 任务平均需要 50 次工具调用。在这么长的循环中，模型很容易偏离主题或忘记早期目标，尤其是长上下文中的“中间丢失”（lost in the middle）现象。 通过不断更新待办事项列表，Manus 将其目标复述到上下文的末尾，将全局计划推入模型的近期注意力范围内。 最新 Manus 将有效但浪费较多 token 的 TODO 文件方式，换成单独的规划器来管理计划，也是一种“Agent as a Tool”的设计。 另一个反直觉的经验， 将错误的尝试保留在上下文中，是改善 Agent 行为最有效的方法之一。 常见的产品设计上遇到报错的本能是隐藏错误，清理痕迹、重试操作、重置状态。但代价就是，擦除失败会移除证据，模型永远学不会错误恢复。 Manus 的实践是，错误是最好的学习材料，当模型看到失败的动作和堆栈跟踪时，会隐式更新内部“先验”，降低重复犯错的概率。比人工设计的纠错机制更有效。 错误恢复是真正 Agent 行为的最明显指标之一。 真实世界什么情况都有， Agent 必须学会在迷雾中前行。大多数学术基准测试的都是“理想状态”，完全忽略了错误恢复能力。 Few Shot 是提高 LLM 输出的常用技术，但在 Agent 系统中可能适得其反。它教会模型“怎么做”，但也可能让模型“只会这么做”。 大语言模型是优秀的模仿者。如果你的上下文充满了类似的过去动作 观察对，模型会倾向于遵循该模式，即使这不再是最优的。上下文越单调，Agent 越脆弱。 举例审查 20 份简历时，Agent 通常会陷入一种僵化节奏，仅仅因为这是它在上下文中看到的，就重复类似的动作。 Manus 的实践是 增加可控随机性和多样性，逼模型根据当前状态决策，而不是照搬历史，在动作和观察中引入少量的结构化变化，不同的序列化模板，替代性措辞，顺序或格式上的微小噪音 ，这种受控随机性打破模式，调整注意力 Manus 早期用 Gaia 等公开学术基准，结果发现与用户偏好严重错位。在 Gaia 得分高的模型用户不喜欢。 Manus 的三种评估， 1. 用户反馈（金标准），每个完成会话后请求 1 5 星评分，这是唯一获取真实品味的指标 2. 内部自动化测试，可验证结果的任务，创建更专注执行的数据集而非推理题（因为大多数基准偏推理任务） 3. 真实人类评估，雇佣实习生评估网站生成、数据可视化等，无法用自动化指标评估 “很难设计好奖励模型判断输出是否视觉吸引，这关乎品味。” 有趣的是，Peak 最后说了一个跟上面分享的 Context Engineering 工程技巧相反的实践经验， Manus 推出后的六七个月，经历了五次重构。最大的飞跃不是来自添加更多花哨的上下文管理层，而是来自简化、移除不必要技巧，更多信任模型。 分享了一个测试 Agent 方法： 固定架构，切换模型，用“模型能力梯度”来评估架构质量。如果换成更强的模型性能大幅提升，说明架构未来可期。 没有过拟合当前模型的局限性 好架构应该让模型发挥全力，而不是设置障碍。每次简化都是在尽可能移除障碍，让模型更自由地表达能力 过度工程的诱惑永远存在，但克制是更高级的能力。Manus 刚推出的时候提出设计理念上的“ Less structure，More intelligence”，而现在是一脉相承的实践指引“Build Less，Understand more” 再回顾下上下文工程的五个维度， 1. 卸载（Offloading）：把数据移到文件系统 2. 缩减（Compaction/Summarization）：压缩历史 3. 检索（Retrieval）：按需读取 4. 隔离（Isolation）：子 Agent 管理 5. 缓存（Caching）：KV Cache 优化 这五个维度不是独立的，寻找动态平衡 • 卸载和检索让缩减更高效 • 稳定检索让隔离更安全 • 但隔离也减缓上下文增长，降低缩减频率 • 然而，更多隔离和缩减也会影响缓存效率和输出质量 “上下文工程是需要在多个可能冲突目标间找到完美平衡的科学与艺术。真的很难。” Peak 最后说，“如果你今天只记住一件事，我希望是：Build Less， Understand More”，“请避免上下文过度工程。” 看之前会认为 Context Engineering 是对 Agent 加更多层、更多技巧、更多控制。但 Manus 的经验告诉我们：上下文工程的目标是让模型工作更简单，而不是更难。 这需要对模型能力的信任，相信它能做到，会越来越强，而不是处处设护栏 。更需要我们克制对“我能替它做得更好”的诱惑，而专注在模型能力正交的事情上。 🔗 原文链接： https://mp.weixin.qq.com/s/soPWgibg... https://mp.weixin.qq.com/s/soPWgibg... 彬子 AI Agent 新手村2026年1月4日 13:18 浙江 作为一个在 Agent 里摸爬滚打的开发者，这两天重温了 Manus 科学家 Peak 的之前关于 Context Engineering 的实践分享 一个是油管上 LangChain 大佬 Lance 和 Peak 的对谈 《Context Engineering for AI Agents with LangChain and Manus》 一篇是 Manus 博客里的 《Context Engineering for AI Agents: Lessons from Building Manus》 两个放一起去看，互为补充，常读常新，会对 Context Engineering 在 Agent 中的运用有更具象的理解，整理的笔记分享给大家 Context Engineering 火起来是 Andrej Karpathy 在 X 上给出一段阐述： People associate prompts with short task descriptions you'd give an LLM in your day to day use. When in every industrial strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step . Science because doing this right involves task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting... Too little or of the wrong form and the LLM doesn't have the right context for optimal performance. Too much or too irrelevant and the LLM costs might go up and performance might come down. Doing this well is highly non trivial. And art because of the guiding intuition around LLM psychology of people spirits. 这套“ 精妙的艺术和科学，它需要用恰到好处的信息填充上下文窗口，以支持下一步操作 ”的方法论与 Manus 的实践不谋而合， Context Engineering 构建起 Manus 里 应用与模型之间最清晰、最实际的边界。 Peak 的前一家创业公司从零训练语言模型，一次训练+评估周期要一两周，产品创新速度完全被拖死。更惨的是，还没找到 PMF，就把时间都花在优化可能对产品用户体验无关的基准上。 所以到了 Manus，从一开始就决定，在没找到 PMF 之前，不自己训练模型，押注通用大模型加上下文工程。这样能几小时内迭代，而不是几周。基础模型进步是涨潮，Manus要做船，能随之水涨船高，而不是柱子，在随时可能被水淹没的焦虑中。 创业公司应该尽可能长时间依赖通用模型和上下文工程，而不是过早构建专用模型。 在 Manus 中，平均输入输出的 token 比例是 100:1。每执行一个工具，上下文就长一截，平均一个任务要 50 次工具调用，上下文像滚雪球一样越滚越大。 理论上模型能处理 100 万 token，但实际 200k 左右就开始渐进式退化，开始重复、推理变慢、质量下滑 Agent 多数是长程任务，任何一步的退化都会被放大。所以必须在退化之前主动干预 Manus 团队通过大量测试来探究使用的模型的“预腐烂阈值”， 通常在 128k 200k 之间。 这个阈值才是 Agent 犯蠢的红线，在触发红线前就开始着手解决 。 这是 Manus 架构中我认为最反直觉、也最聪明的设计， 把文件系统当作无限，终极上下文。 信息没有真正丢失，只是外部化了，但常规想到的也是向量数据库，RAG，知识图谱这类信息有损的外部化方案。 而Manus 就用最朴素的文件系统，文件系统有三个自带 buffer：无限容量，天然持久化，命令行直接操作。 最关键的点在于是“可逆性”，Context 不是不压缩，而是压缩要可恢复。URL 在，网页内容可以重新 fetch。文件路径在，内容可以重新 read。与其猜测 10 步后什么信息会重要，不如让 Agent 有能力按需取回。 Peak 还提出一个设想，如果 SSM（状态空间模型）能掌握基于文件的记忆，它可能成为 Transformer Agent 的真正继任者 紧凑化的关键是可逆，就不是“压缩数据”，而是“外部化状态”。 常见压缩是把大数据变小数据，几乎是有损的。紧凑化是把数据从上下文移到环境里文件系统中。 比如写文件的工具调用，执行后 content 字段可以安全删除，因为数据已经在沙盒文件系统里了，只需保留 path 这个“指针”。 这个技巧的神奇在于，从模型上下文视角信息没了，但从 Agent 系统视角信息仍可访问。 当紧凑化也扛不住了，才轮到摘要出场。因为摘要是有损的，无法很好的做到“可逆”，Manus 中这一步会非常谨慎。 Manus 的做法很细节，摘要前先把关键部分卸载到文件，有时甚至把整个预总结上下文当日志文件存起来，留个后路。 摘要时用结构化 Schema，不是让 AI 自由发挥写总结，而是定义一张表单，很多字段，让 AI 填空。 比如“修改了哪些文件”，“用户目标是啥”，“做到哪了”。这样输出稳定，可以迭代优化，不会一次摘要就把关键信息搞丢。 摘要后，仍然保留最近几条工具调用/结果的完整版本，这样模型知道自己做到哪了，能更顺畅地继续 通用 Agent 需要强大能力，但模型无法处理太多工具，工具太多 Agent 会“选择困难症”，甚至调用不存在的工具，也会破坏缓存，就是一种“上下文混乱”。Manus 的解法是分层动作空间：核心层只有 10～20 个原子函数（读写文件、执行 shell 等），边界清晰，可组合，直接调用；中间层是预装在沙盒中工具（格式转换器、语音识别、MCP CLI 等），这样添加新能力不触碰模型的函数调用空间，通过命令行访问；外层是各类预授权 API（金融数据、3D 设计库等），写 Python 脚本执行，比如获取城市名 → 获取城市 ID → 获取天气一个脚本搞定。 精妙之处在于从基础模型视角， 这三层仍然通过标准函数调用，所以接口清晰、缓存友好、函数间正交。 MCP（Model Context Protocol）上半年特别火，Demo 效果也非常好。但很快就发现工具数量的极具膨胀，工具功能的同质化等都造成大模型在实际决策和调用效果上并那么美好。 Manus 的做法谨慎且高效，开发了一个 mcp cli 工具，预装在沙盒中，通过命令行接口调用 MCP，而不是注入到函数调用空间，输出可以直接写文件或分页返回，用 grep 、 cat 等 Linux 工具实时处理 这个设计有两个妙处， 一是保持了函数调用空间的稳定（保护 KV Cache），二是利用了 Linux 生态的可组合性。 信任 Agent 可以运行 help 自学新工具，而不需要在系统提示里硬编码每个工具的用法。 Peak 原话“ 如果我必须选择一个指标，我认为 KV Cache 命中率 是生产阶段 AI 代理最重要的单一指标。 ” Agent 的输入输出比是 100:1，以 Claude Sonnet 为例，缓存命中的 token 是 0.3 美元/百万，不命中是 3 美元，成本差 10 倍。同时 Agent“流畅”与否的关键是预填充速度，每一轮都要重新阅读巨长的上下文会又贵又慢。 优化 KV Cache 的技巧看似琐碎，但魔鬼藏在细节里 1. 保持前缀稳定，比如不要在系统提示开头放时间戳 2. 确保序列化确定性，比如 JSON 键顺序不稳定会悄无声息地破坏缓存 3. 只追加，不修改，避免修改之前的操作或观察历史 4. 明确标记缓存断点，如果提供商不支持自动增量前缀缓存，手动插入断点 减少模型选择困难第一想到的解法是根据场景增删工具，但 Manus 有一个反常识的发现，动态添加或移除工具会摧毁 KV Cache（工具定义在上下文的前部分中）。 Manus 的解法也非常有脑洞，Logit Masking，不移除工具定义，而是在解码过程中遮蔽 token 的 logits，阻止模型选择某些动作。 通过响应预填充实现三种模式： • 自动模式，模型可选择调用或不调用函数 • 必需模式，模型必须调用函数，但选择不受约束 • 指定模式，模型必须从特定子集中调用函数 Manus 中的工具还有意设计了一致的前缀（比如所有浏览器工具以 browser 开头），这样可以约束模型只从特定工具组中选择。 Peak 明确反对按角色划分的 Multi Agent 架构（比如设计师 Agent、程序员 Agent、管理者 Agent 这类“拟人化”团队），认为“那是人类公司的运作方式，源于人类的上下文限制”。 Manus 只有很少几个 Agent，一个通用执行 Agent，一个规划器 Agent，一个知识管理 Agent，可能还有数据 API 注册 Agent 等，每个都是功能性的而非角色性的。 更多时候，Manus 把子 Agent 实现为 “Agent as a Tool”。子 Agent 不是独立个体，而是主 Agent 的工具调用，有明确的输入输出 Schema。 通过通信共享内存，而非通过共享内存通信 ，这两种隔离模式， 1. 通过通信（适合简短清晰的任务），主 Agent 写提示，发送给子 Agent，子 Agent 的上下文只包含该指令，比如在代码库中搜索特定片段 2. 通过共享内存（适合需要完整历史的任务），子 Agent 可以看到完整的之前上下文，但有自己的系统提示和动作空间，比如深度研究场景，最终报告依赖大量中间搜索和笔记 3. 后者意味着更大的输入预填充和更高的成本，且无法重用 KV Cache