🤖 Manus：Context Engineering for AI Agents

🤖 Manus：Context Engineering for AI Agents 🤖 Manus：Context Engineering for AI Agents Modified October 17, 2025 No access bfd617bab9824f6bb4b24f67da1bcede 00:00 • 主 agent 定义输出 schema • Sub agent 有特殊工具 "submit result" • 使用 constrained decoding 确保符合 schema • 类似 MapReduce 操作，生成类似电子表格的结构化输出 🔄 架构演进的智慧 00:36:35 如何应对模型快速迭代 "Manus 在 3 月发布，到 10 月已经重构了 5 次。你不能停止，因为模型不仅在改进，而且在变化。" Peak 的评估理论 核心方法：固定 agent 架构，在不同模型间切换 • 如果架构能从切换到更强模型中获得很多收益，说明架构更具未来适应性 • 明天的弱模型可能和今天的强模型一样好 • 在弱模型和强模型之间切换，可以获得明年会发生什么的早期信号 • 每 1 2 个月做一次 review • 使用开源模型和专有模型的早期访问权限来准备下一个版本 💎 金句："不关心静态基准测试的静态性能。通过在不同模型间切换来测试架构的未来适应性。" 🔐 安全与 Guard Railing 00:53:20 Manus 的安全策略 有一个连接到互联网的 sandbox，一切都是危险的，需要多层防护： • 信息隔离：不让信息离开 sandbox • 出站流量检查：确保没有 tokens 会离开 sandbox • 移除机制：用户从 sandbox 打印内容时的安全检查 • 浏览器安全： ◦ 可以持久化登录状态（用户选择） ◦ 网页内容可能包含恶意 prompt injection ◦ 与 Anthropic、Google 等模型提供商密切合作 • 手动确认机制：敏感操作需要用户手动确认或接管 这是一个渐进的方法：现在让用户更频繁地接管，但如果模型本身的 guardrail 变得更好，可以做得更少。 📊 实际案例：Open Deep Research 00:08:05 LangChain 的开源 Deep Research 实现 一个性能与最佳实现相当的开源项目，展示了 context engineering 的综合应用。 三个阶段架构 1. 研究 Scoping： ◦ 创建 brief 来规划研究计划 ◦ 使用 Offloading：将 brief 保存到 LangGraph state 或文件系统 2. 研究阶段（Multi Agent）： ◦ 使用 Reduction：总结 token 很重的搜索工具调用 ◦ 使用 Context Isolation：sub agents 之间隔离上下文 3. 写作阶段： ◦ 将 offload 的 brief 拉回消息列表末尾 ◦ Agent 可以访问并使用它来执行写作 这个案例完美展示了 Offloading、Reduction 和 Isolation 三种技术的协同应用。 🎯 工具选择策略 00:46:05 如何避免工具过载 经验法则 • 工具数量上限：不超过 30 个（取决于模型） • Manus 的做法：只有 10 20 个原子化函数 • 关键原则：确保原生函数是超级原子化的 图灵完备的优势 "为什么我们如此自信地称 Manus 为通用 agent？因为它运行在计算机上，而计算机是图灵完备的。有了 shell 工具和文本编辑器，它已经是图灵完备的了。" 混合方法的优势： • 直接工具调用：用于需要 constrained decoding 的场景 • 脚本执行：用于处理大量数据、复杂计算 • Sandbox 工具：用于可扩展的能力 🧠 记忆管理 00:34:15 Manus 的"知识"系统 显式记忆（需要用户确认）： • 用户可以告诉 Manus 记住某些偏好 • 弹出对话框让用户确认是否接受 • 示例："记住，每次我要求某些东西时以 Excel 格式交付" 自动化记忆（探索中）： • 利用用户纠正的集体反馈 • 示例：中文/日文/韩文可视化的字体问题 • 目标：通过在线学习实现自我改进，但以 parameter free 的方式 有趣的现象：与聊天机器人相比，用户更频繁地纠正 agent。这种集体反馈是宝贵的学习资源。 🔬 Context Engineering 的哲学 为什么需要 Context Engineering？ Peak 的三个认识阶段 阶段 1：从头训练模型的痛苦 • 在前一家公司从头训练语言模型 • 产品创新速度完全受限于模型迭代速度 • 单个训练加评估周期需要 1 2 周 • 在达到 PMF 之前就把时间花在改进 benchmark 上 阶段 2：Fine tuning 的陷阱 • 需要固定 action space • 围绕当前产品行为设计 reward • 生成大量 on policy rollouts • 但 AI 和 Agent 仍在早期，一切可能一夜之间改变 • MCP 的发布就完全改变了 Manus 的设计 阶段 3：找到正确的边界 💎 金句："要坚定你划定界限的地方。现在，context engineering 是应用和模型之间最清晰、最实用的边界。" 📚 核心要点总结 Context Engineering 的五大支柱 🎓 最重要的经验教训 1️⃣ "少构建，多理解" —— 避免过度工程化 2️⃣ "Context engineering 的目标是让模型的工作更简单，而不是更难" 3️⃣ "坚定你划定界限的地方。Context engineering 是应用和模型之间最清晰的边界" 4️⃣ "通过在不同模型间切换来测试架构的未来适应性" 5️⃣ "Compaction 是可逆的，Summarization 不是。选择合适的时机使用" 6️⃣ "不要按人类组织架构来设计 Multi Agent 系统" 7️⃣ "使用结构化输出（schema）而不是自由形式的 summarization" 8️⃣ "最大的飞跃来自简化，来自移除不必要的技巧并更多地信任模型" 🛠️ 实践建议清单 开始构建 Agent 时的检查清单 1. ✅ 设置 Context Threshold：识别你的 pre rot threshold（通常 128K 200K） 2. ✅ 实现分层 Reduction：先 Compaction，再 Summarization 3. ✅ 选择合适的 Offloading 策略：文件系统 vs 外部状态 4. ✅ 决定 Retrieval 方法：根据场景选择语义搜索或简单工具 5. ✅ 设计 Multi Agent 架构：明确何时用通信模式，何时用共享内存 6. ✅ 限制工具数量：保持原子化函数在 10 30 个 7. ✅ 使用结构化输出：定义 schema 而不是自由形式 8. ✅ 优先基于行的格式：便于 grep 和按行读取 9. ✅ 保留最近的完整上下文：避免 summarization 后的风格变化 10. ✅ 建立评估体系：用户反馈 + 自动化测试 + 人工评估 11. ✅ 定期重构：每 1 2 个月审查架构，跟上模型进化 12. ✅ 测试跨模型性能：在不同强度的模型间切换验证架构 🔮 未来展望 Context Engineering 的演进方向 • 模型原生支持：Claude Sonnet 4.5 已内置 pruning 功能 • 更长的上下文窗口：但 context rot 问题依然存在 • 更好的 guardrails：模型提供商在加强安全机制 • Parameter free 学习：通过集体反馈实现自我改进 • 标准化协议：MCP 等协议改变 action space 设计 • 任务级路由：不同模型擅长不同子任务 Peak 的观察：前沿实验室的方向并没有趋同。Anthropic 擅长 coding，Gemini 擅长多模态，OpenAI 擅长复杂数学推理。应用公司的优势在于可以做任务级路由。 📖 延伸阅读 推荐资源 • 📝 Manus Context Engineering 博客（2024年7月） • 📊 Gretel Context Rot 报告 • 🎥 Cursor 的 Lee Robinson 在 OpenAI Demo Day 的演讲 • 📄 Anthropic 的 Computer Use 研究 • 📄 Cognition 关于 Devin 的博客 • 📄 CodeAct 论文（关于代码的可组合性） • 🔧 LangChain Open Deep Research（开源实现） • 🔧 Claude Code 文档 💬 Q&A 精选 关于工具命名的讨论 问：能否通过使用与 Claude Code 相同的工具名称来解锁同样的能力？ Peak：我们实际上尝试不使用相同的名称。如果你设计自己的函数，可能对该函数有不同的需求，输入参数可能会不同。你不想让模型混淆。如果模型在大量 post training 数据上训练过某些内部工具，你不想让模型产生困惑。 关于 Agent as Tool Lance：Agent as tool 这个想法非常有效。对于复杂搜索，你会使用 sub agent，从模型角度看它仍然是一个函数，但触发的是另一个 sub agent workflow，有固定的输出 schema。 关于开源 vs 专有模型 Peak：对于达到 Manus 规模的 Agent，输入远长于输出，KV Cache 超级重要。如果使用开源方案，分布式 KV Cache 很难实现。使用前沿 LLM 提供商的全球分布式基础设施，有时甚至比使用开源模型更便宜。 🎬 结语 Context Engineering 不是一次性的工程决策， 而是一个持续演进的过程。 随着模型能力的提升， 最好的架构往往是最简单的架构。 记住：少构建，多理解。 感谢观看 Lance Martin LangChain 创始工程师 Peak Manus 联合创始人兼首席科学家 No access bfd617bab9824f6bb4b24f67da1bcede 00:00 No access bfd617bab9824f6bb4b24f67da1bcede 00:00 • 主 agent 定义输出 schema • Sub agent 有特殊工具 "submit result" • 使用 constrained decoding 确保符合 schema • 类似 MapReduce 操作，生成类似电子表格的结构化输出 🔄 架构演进的智慧 00:36:35 如何应对模型快速迭代 "Manus 在 3 月发布，到 10 月已经重构了 5 次。你不能停止，因为模型不仅在改进，而且在变化。" Peak 的评估理论 核心方法：固定 agent 架构，在不同模型间切换 • 如果架构能从切换到更强模型中获得很多收益，说明架构更具未来适应性 • 明天的弱模型可能和今天的强模型一样好 • 在弱模型和强模型之间切换，可以获得明年会发生什么的早期信号 • 每 1 2 个月做一次 review • 使用开源模型和专有模型的早期访问权限来准备下一个版本 💎 金句："不关心静态基准测试的静态性能。通过在不同模型间切换来测试架构的未来适应性。" 🔐 安全与 Guard Railing 00:53:20 Manus 的安全策略 有一个连接到互联网的 sandbox，一切都是危险的，需要多层防护： • 信息隔离：不让信息离开 sandbox • 出站流量检查：确保没有 tokens 会离开 sandbox • 移除机制：用户从 sandbox 打印内容时的安全检查 • 浏览器安全： ◦ 可以持久化登录状态（用户选择） ◦ 网页内容可能包含恶意 prompt injection ◦ 与 Anthropic、Google 等模型提供商密切合作 ◦ 可以持久化登录状态（用户选择） ◦ 网页内容可能包含恶意 prompt injection ◦ 与 Anthropic、Google 等模型提供商密切合作 • 手动确认机制：敏感操作需要用户手动确认或接管 这是一个渐进的方法：现在让用户更频繁地接管，但如果模型本身的 guardrail 变得更好，可以做得更少。 📊 实际案例：Open Deep Research 00:08:05 LangChain 的开源 Deep Research 实现 一个性能与最佳实现相当的开源项目，展示了 context engineering 的综合应用。 三个阶段架构 1. 研究 Scoping： ◦ 创建 brief 来规划研究计划 ◦ 使用 Offloading：将 brief 保存到 LangGraph state 或文件系统 ◦ 创建 brief 来规划研究计划 ◦ 使用 Offloading：将 brief 保存到 LangGraph state 或文件系统 2. 研究阶段（Multi Agent）： ◦ 使用 Reduction：总结 token 很重的搜索工具调用 ◦ 使用 Context Isolation：sub agents 之间隔离上下文 ◦ 使用 Reduction：总结 token 很重的搜索工具调用 ◦ 使用 Context Isolation：sub agents 之间隔离上下文 3. 写作阶段： ◦ 将 offload 的 brief 拉回消息列表末尾 ◦ Agent 可以访问并使用它来执行写作 ◦ 将 offload 的 brief 拉回消息列表末尾 ◦ Agent 可以访问并使用它来执行写作 这个案例完美展示了 Offloading、Reduction 和 Isolation 三种技术的协同应用。 🎯 工具选择策略 00:46:05 如何避免工具过载 经验法则 • 工具数量上限：不超过 30 个（取决于模型） • Manus 的做法：只有 10 20 个原子化函数 • 关键原则：确保原生函数是超级原子化的 图灵完备的优势 "为什么我们如此自信地称 Manus 为通用 agent？因为它运行在计算机上，而计算机是图灵完备的。有了 shell 工具和文本编辑器，它已经是图灵完备的了。" 混合方法的优势： • 直接工具调用：用于需要 constrained decoding 的场景 • 脚本执行：用于处理大量数据、复杂计算 • Sandbox 工具：用于可扩展的能力 🧠 记忆管理 00:34:15 Manus 的"知识"系统 显式记忆（需要用户确认）： • 用户可以告诉 Manus 记住某些偏好 • 弹出对话框让用户确认是否接受 • 示例："记住，每次我要求某些东西时以 Excel 格式交付" 自动化记忆（探索中）： • 利用用户纠正的集体反馈 • 示例：中文/日文/韩文可视化的字体问题 • 目标：通过在线学习实现自我改进，但以 parameter free 的方式 有趣的现象：与聊天机器人相比，用户更频繁地纠正 agent。这种集体反馈是宝贵的学习资源。 🔬 Context Engineering 的哲学 为什么需要 Context Engineering？ Peak 的三个认识阶段 阶段 1：从头训练模型的痛苦 • 在前一家公司从头训练语言模型 • 产品创新速度完全受限于模型迭代速度 • 单个训练加评估周期需要 1 2 周 • 在达到 PMF 之前就把时间花在改进 benchmark 上 阶段 2：Fine tuning 的陷阱 • 需要固定 action space • 围绕当前产品行为设计 reward • 生成大量 on policy rollouts • 但 AI 和 Agent 仍在早期，一切可能一夜之间改变 • MCP 的发布就完全改变了 Manus 的设计 阶段 3：找到正确的边界 💎 金句："要坚定你划定界限的地方。现在，context engineering 是应用和模型之间最清晰、最实用的边界。" 📚 核心要点总结 Context Engineering 的五大支柱 🎓 最重要的经验教训 1️⃣ "少构建，多理解" —— 避免过度工程化 2️⃣ "Context engineering 的目标是让模型的工作更简单，而不是更难" 3️⃣ "坚定你划定界限的地方。Context engineering 是应用和模型之间最清晰的边界" 4️⃣ "通过在不同模型间切换来测试架构的未来适应性" 5️⃣ "Compaction 是可逆的，Summarization 不是。选择合适的时机使用" 6️⃣ "不要按人类组织架构来设计 Multi Agent 系统" 7️⃣ "使用结构化输出（schema）而不是自由形式的 summarization" 8️⃣ "最大的飞跃来自简化，来自移除不必要的技巧并更多地信任模型" 🛠️ 实践建议清单 开始构建 Agent 时的检查清单 1. ✅ 设置 Context Threshold：识别你的 pre rot threshold（通常 128K 200K） 2. ✅ 实现分层 Reduction：先 Compaction，再 Summarization 3. ✅ 选择合适的 Offloading 策略：文件系统 vs 外部状态 4. ✅ 决定 Retrieval 方法：根据场景选择语义搜索或简单工具 5. ✅ 设计 Multi Agent 架构：明确何时用通信模式，何时用共享内存 6. ✅ 限制工具数量：保持原子化函数在 10 30 个 7. ✅ 使用结构化输出：定义 schema 而不是自由形式 8. ✅ 优先基于行的格式：便于 grep 和按行读取 9. ✅ 保留最近的完整上下文：避免 summarization 后的风格变化 10. ✅ 建立评估体系：用户反馈 + 自动化测试 + 人工评估 11. ✅ 定期重构：每 1 2 个月审查架构，跟上模型进化 12. ✅ 测试跨模型性能：在不同强度的模型间切换验证架构 🔮 未来展望 Context Engineering 的演进方向 • 模型原生支持：Claude Sonnet 4.5 已内置 pruning 功能 • 更长的上下文窗口：但 context rot 问题依然存在 • 更好的 guardrails：模型提供商在加强安全机制 • Parameter free 学习：通过集体反馈实现自我改进 • 标准化协议：MCP 等协议改变 action space 设计 • 任务级路由：不同模型擅长不同子任务 Peak 的观察：前沿实验室的方向并没有趋同。Anthropic 擅长 coding，Gemini 擅长多模态，OpenAI 擅长复杂数学推理。应用公司的优势在于可以做任务级路由。 📖 延伸阅读 推荐资源 • 📝 Manus Context Engineering 博客（2024年7月） • 📊 Gretel Context Rot 报告 • 🎥 Cursor 的 Lee Robinson 在 OpenAI Demo Day 的演讲 • 📄 Anthropic 的 Computer Use 研究 • 📄 Cognition 关于 Devin 的博客 • 📄 CodeAct 论文（关于代码的可组合性） • 🔧 LangChain Open Deep Research（开源实现） • 🔧 Claude Code 文档 💬 Q&A 精选 关于工具命名的讨论 问：能否通过使用与 Claude Code 相同的工具名称来解锁同样的能力？ Peak：我们实际上尝试不使用相同的名称。如果你设计自己的函数，可能对该函数有不同的需求，输入参数可能会不同。你不想让模型混淆。如果模型在大量 post training 数据上训练过某些内部工具，你不想让模型产生困惑。 关于 Agent as Tool Lance：Agent as tool 这个想法非常有效。对于复杂搜索，你会使用 sub agent，从模型角度看它仍然是一个函数，但触发的是另一个 sub agent workflow，有固定的输出 schema。 关于开源 vs 专有模型 Peak：对于达到 Manus 规模的 Agent，输入远长于输出，KV Cache 超级重要。如果使用开源方案，分布式 KV Cache 很难实现。使用前沿 LLM 提供商的全球分布式基础设施，有时甚至比使用开源模型更便宜。 🎬 结语 Context Engineering 不是一次性的工程决策， 而是一个持续演进的过程。 随着模型能力的提升， 最好的架构往往是最简单的架构。 记住：少构建，多理解。 感谢观看 Lance Martin LangChain 创始工程师 Peak Manus 联合创始人兼首席科学家 完整视频：YouTube 链接 YouTube 链接 📅 播客日期：2025年10月14日 🏷️ 标签：AI Agent · Context Engineering · LangChain · Manus · LLM · Multi Agent Systems 整理时间：2025年10月 | 内容来源：YouTube 播客访谈 播客嘉宾：Lance (LangChain) & Peak (Manus) 日期：2025年10月14日 来源：观看完整视频 观看完整视频 🎯 核心主题 本次播客深入探讨了 AI Agent 开发中的 Context Engineering（上下文工程）——一门精妙的艺术与科学，旨在用恰当的信息填充上下文窗口以支持 Agent 的下一步操作。 📖 背景介绍 00:00:06Lance (LangChain 创始工程师)： 今天和我一起的是来自 Manus 的 Peak。Manus 是一个很酷的产品，几个月前他们发布了一篇关于 context engineering 的博客文章，对我影响很大。 Peak (Manus 联合创始人兼首席科学家)： 我负责设计 Manus 的 agent 框架。今天我会分享一些博客文章中没有涵盖的新想法和经验。 什么是 Context Engineering？ Context engineering 在 2023 年 5 月左右开始兴起，与"Agent 之年"的概念相关联。它是在 Prompt Engineering 之后出现的新学科，专门应对 Agent 系统中上下文无限增长的挑战。 🔥 核心挑战：Context 爆炸 Agent 面临的悖论 当我们构建 Agent 时，会观察到一个特殊现象： • 工具调用累积：Agent 每次调用工具都会得到 tool observation 返回，追加到消息列表中 • 无限制增长：Manus 的典型任务需要约 50 次工具调用，生产环境的 Agent 可能进行 数百轮对话 • 性能下降：Gretel 报告指出，随着 context 增长，性能会下降（Context Rot） "Agent 因为工具调用而使用大量 context，但我们知道随着 context 增长性能会下降。这就是我们面临的悖论。" 🛠️ 五大解决方案 00:03:45 1️⃣ Context Offloading（上下文卸载） 核心思想 不需要所有 context 都存在于 agent 的消息历史中。可以把信息 offload 出去，发送到别处，在需要时检索。 最流行的方法：使用文件系统 • 将 token 很重的工具消息输出 dump 到文件系统 • 只向 agent 返回必要的最小信息 • Agent 可以在需要时引用完整 context 应用案例：Manus、LangChain Dev Agents、OpenDevin、Claude Code 2️⃣ Context Reduction（上下文缩减） 00:15:00Peak 深度解析： 两种不同的操作方式 A. Compaction（压缩） 可逆操作 • 每个工具调用有 full format 和 compact format 两种格式 • Compact 版本剔除可以从文件系统或外部状态重建的信息 • 示例：写文件工具有 path 和 content 字段，compact 后只保留 path，因为文件已存在于环境中 • 关键优势：可逆性——没有信息真正丢失，只是外部化了 B. Summarization（总结） 不可逆操作 • 当 compaction 收益变小时才触发 • 在 summarization 之前，将关键部分 offload 到文件 • 有时将整个 pre summary context 作为日志文件 dump 到文件系统 • 总是使用数据的 full 版本，而不是 compact 版本 最佳实践：保持最后几个工具调用的完整细节，让模型知道它在哪里停下来，避免 summarization 后风格和语气的改变。 Context Threshold 管理 • 硬限制：模型的 context 上限（如 100 万 tokens） • Pre rot threshold：通常在 128K 200K，模型开始出现重复、推理变慢、质量下降 • 触发策略：接近 pre rot threshold 时触发 reduction • 操作顺序：先 compaction（压缩最旧的 50%），再 summarization 💎 金句："Compaction 是可逆的，Summarization 不是。两者都减少了 context 长度，但行为非常不同。" 3️⃣ Context Retrieval（上下文检索） 两种主流方法： 方法 A：Indexing + Semantic Search • 使用向量数据库和语义搜索 • 适合长期记忆和企业知识库 • Cursor 使用此方法 方法 B：文件系统 + 简单搜索工具 • 使用 glob、grep 等工具 • Claude Code 采用此方法 • Manus 也使用此方法（因为每个 session 都是新沙箱，没有时间动态构建索引） Peak 的建议：优先考虑基于行的格式（而非 Markdown），因为这允许模型使用 grep 或按行范围读取。 4️⃣ Context Isolation（上下文隔离） 00:19:22 Multi Agent 的两种模式 "不要通过共享内存来通信。相反，通过通信来共享内存。" —— Go 语言社区 模式 A：By Communicating（通过通信） • 经典的 sub agent 设置 • Main agent 写一个 prompt 发送给 sub agent • Sub agent 的整个 context 只包含那个指令 • 适用场景：任务有简短清晰的指令，只有最终输出重要 • 示例：在代码库中搜索特定片段 模式 B：By Sharing Memory（通过共享内存） • Sub agent 可以看到整个之前的 context • 包含所有工具使用历史 • 但 sub agent 有自己的 system prompt 和 action space • 适用场景：复杂场景，需要完整历史 • 示例：Deep Research——最终报告依赖大量中间搜索和笔记 权衡：Sharing context 有点昂贵，每个 sub agent 都有更大的输入要 prefill，且由于 system prompt 和 action space 不同，无法重用 KV cache。 Manus 的 Agent 架构 Manus 不按角色划分 Agent（如设计师、编程师、经理），而是按功能： • 通用执行器 Agent：巨大的通用执行器 • Planner Agent：独立管理计划（不再使用 todo.md） • Knowledge Manager Agent：审查对话，提取长期记忆 • 数据 API 注册 Agent 💎 金句："我们不按角色划分 Agent，因为那是人类公司的运作方式，是由于人类上下文的局限性。" 5️⃣ Context Caching（上下文缓存） 利用模型提供商的 KV Cache 功能（如 Anthropic 的 input caching）来提高效率和降低成本。 Peak 指出：对于 Manus 的规模，使用前沿 LLM 提供商的分布式 KV Cache 基础设施，有时甚至比使用开源模型更便宜。 🚀 Manus 的创新：分层 Action Space 00:22:18 问题：工具太多导致 Context Confusion 工具本身会占用大量上下文，导致模型可能调用错误的工具，甚至调用不存在的工具。 解决方案：三层架构 Level 1: Function Calling（函数调用） • 只使用 固定数量的原子函数（10 20 个） • 包括：读写文件、执行 shell 命令、搜索文件和互联网、浏览器操作 • 优势：Schema 安全，通过 constraint decoding 保证 • 特点：原子函数有清晰边界，可组合成复杂工作流 Level 2: Sandbox Utilities（沙箱工具） • 每个 Manus session 运行在完整的虚拟机沙箱中 • 通过 shell 命令运行预装工具 • 示例：格式转换器、语音识别、Manus MCP CLI • 优势：可以在不触及 function calling 空间的情况下添加新能力 • 特点：对大量输出很好，可写入文件或分页返回 Level 3: Packages & APIs（包和 API） • 编写脚本调用预授权的 API 或自定义包 • 示例：3D 设计库、金融 API • 优势：代码高度可组合，可在一步中串联很多操作 • 适用场景：需要大量计算和内存，但不需要把所有数据推入模型上下文 • 权衡：不是 schema 安全的 💎 金句："从模型的角度看，这三个层级仍然通过标准的 function calls 进行。接口保持简单、对 cache 友好，并且函数之间正交。" 🎓 关键洞察与最佳实践 00:28:24 五个维度的相互关系 Offload、Reduce、Retrieve、Isolate、Cache 不是独立的： • Offload 和 Retrieve 能实现更高效的 Reduction • 稳定的 Retrieval 使 Isolation 安全 • Isolation 减缓上下文增长，降低 Reduction 频率 • 更多的 Isolation 和 Reduction 会影响 Cache 效率和输出质量 "Context engineering 是一门科学和艺术，需要在多个潜在冲突的目标之间找到完美平衡。" ⚠️ 终极建议："避免 Context 过度工程化。Manus 最大的飞跃并非来自添加更多花哨的 context 管理层，而是来自简化，来自移除不必要的技巧并更多地信任模型。" 🎯 如果只记住一件事："少构建，多理解。Context engineering 的目标是让模型的工作更简单，而不是更难。" 💡 实战经验分享 00:30:49 01:00:00 关于模型选择 • Manus 不使用开源模型——不是因为质量，而是成本 • 对于 Agent（输入远长于输出），KV Cache 超级重要 • 前沿 LLM 提供商的全球分布式基础设施更可靠 • 任务级路由：Coding 用 Claude，多模态用 Gemini，复杂数学用 OpenAI 关于 Fine tuning 和 RL "创业公司应该尽可能长时间地依赖通用模型和 context engineering，而不是过早构建专门的模型。" • MCP 是重大变革：不再是固定 action space，难以设计 reward • 如果要支持 MCP，你实际上是在构建 foundation model • 现在不建议在 RL 上花太多时间 • 探索 parameter free 的在线学习，如集体反馈 关于评估（Eval） Manus 的三种评估方式： 1. 用户反馈（金标准）：每个完成的 session 请求 1 5 星评分 2. 自动化测试：内部数据集 + 公开 benchmark（重点是执行任务） 3. 人工评估：使用实习生评估网站生成、数据可视化等需要品味的任务 发现：在 GAIA 等学术 benchmark 上得高分的模型，用户并不一定喜欢。 关于 Planning • 早期使用 todo.md 范式，但浪费了 1/3 的 actions • 现在使用 结构化 planning，通过独立的 Planner Agent 管理 • 使用 agent as tool 范式实现 • 好处：不同视角、外部审查、可为 planning 使用不同模型 关于 Summarization Peak 的技巧：不要用自由形式的 prompt，而是定义一种 schema（像表单），有很多字段让 AI 填写。例如：修改的文件、用户目标、停下的地方等。这样输出稳定，可以迭代。 关于数据存储格式 • 优先考虑 基于行的格式 • 允许模型使用 grep 或按行范围读取 • Markdown 有时会导致模型输出太多 bullet points • 更倾向于使用纯文本 关于 Agent 间通信 Manus 的 Agentic MapReduce 方法： • 共享同一个 sandbox，通过传递路径来共享文件系统