Manus关于Agent上下文工程的最新实践
笔者所在的Navi AI正在构建一个利用长上下文（如会议、访谈语料）来辅助用户进行分析决策的Agent应用，构建过程中Dogfooding自己的产品总会有些惊喜时刻，但可惜产品完整launch还需要一点时间，所以最近决定尝试先把一些“中间过程”的产物分享出来，也算是build in public的一种方式了。【AI大模型教程】
以下文章是在获得原始对谈语料（Youtube视频）的基础上我跟Navi AI共同“创作”的产物，enjoy～
上下文工程深度解析
Manus一直是我们构建AI Agent道路上的好老师，最近他们发布了1.5版本的更新，同时首席科学家Peak Ji（季逸超）和LangChain的创始工程师Lance之间进行了一次深度交流。（再上一次的公开分享是Peak在7月份发表的《AI Agent的上下⽂⼯程：构建Manus的经验教训》）本次交流中他们系统性地梳理了上下文工程的核心概念、主流技术框架，并深入分享了Manus AI在构建生产级AI Agent 过程中的前沿实践、创新方法和核心开发哲学。
完整视频可以在Youtube或B站搜索：“Context Engineering for AI Agents with LangChain and Manus”，以下是访谈内容的整理：
✦
KEY POINTS
核心要点
●
上下文工程是关键：上下文工程是为解决AI Agent在长时间自主运行中产生的“上下文爆炸”和“上下文腐烂”问题而生的核心学科，其重要性远超传统的提示工程。
●
分层缩减策略：Manus AI采用一种精细化的两阶段上下文缩减策略，优先使用无损、可逆的“紧凑化”（Compaction），仅在必要时才采用有损、不可逆但基于结构化模式（Schema）的“总结”（Summarization）。
●
创新的分层动作空间：为解决工具过载问题，Manus AI设计了三层动作空间：少量核心原子函数、通过Shell访问的沙箱实用程序、以及用于复杂计算的脚本与API。此举在保持核心接口简洁的同时，实现了近乎无限的能力扩展。
●
两种Multi-Agent协作模式：根据任务特性，Manus AI采用两种不同的Multi-Agent隔离与通信模式：“通过通信来共享内存”（适用于简单、独立的子任务）和“通过共享内存来通信”（适用于需要完整历史背景的复杂任务）。
●
结构化输出是稳定性的基石：无论是在上下文总结还是Agent 间通信中，Manus AI都广泛使用结构化输出（Schema）作为“契约”，以确保信息传递的稳定、完整和无损。
●
核心开发哲学——“少构建，多理解”：报告强调，最高效的Agent 架构源于简化而非复杂化。开发者应避免过度工程，更多地信任并理解模型本身，通过简化架构来构建更稳定、更智能的系统。
01
THE CHALLENGE
上下文工程：AI Agent时代的核心挑战
上下文工程被定义为一门精巧的艺术与科学，旨在用恰到好处的信息填充模型的上下文窗口，以确保模型能够正确执行下一步决策。它与侧重于单次交互优化的“提示工程”有本质区别，其核心是管理一个动态演变的上下文环境，以解决AI Agent面临的两个核心悖论。
这两个挑战形成了一个根本性矛盾：Agent 的有效运作依赖于丰富的历史上下文，但上下文的增长却直接侵蚀其性能。因此，上下文工程通过一系列精巧的技术来管理信息流，成为了推动AI Agent 走向实用化和稳定运行的基石。
02
THE FRAMEWORKS
五大主流上下文工程技术框架
为了应对上述挑战，业界涌现出五种主流的上下文工程技术。这些技术并非相互排斥，在生产级应用中常被组合使用，形成一个全面的管理工具箱。
03
THE PRACTICE
Manus AI的前沿实践与创新方法
Manus AI在生产实践中，对上述技术进行了深化与创新，形成了一套独特且高效的解决方案。
3.1. 上下文缩减：可逆紧凑化与结构化总结的协同策略
为在信息保真度与上下文长度之间取得最佳平衡，Manus AI设计了一套分层、审慎的上下文缩减机制。
1.识别“腐烂前阈值”：首先通过大量评估，确定模型性能开始下降的上下文长度（如128k-200k tokens），远低于其理论上限。该阈值是触发缩减操作的信号。
2.优先执行“紧凑化”（Compaction）：当接近阈值时，系统首先执行可逆的紧凑化操作。
定义：紧凑化是将工具调用历史中可以从外部状态（如文件系统）恢复的信息剥离的过程。例如，write_file操作的content字段在执行后可从文件路径path恢复，因此在紧凑格式中被移除。
优势：信息无损，保留了随时恢复完整细节的能力，这对于无法预知未来哪一步历史会变得至关重要的Agent 任务来说至关重要。
策略：通常只紧凑化最旧的50%历史，保留最新的部分以完整格式作为模型的few-shot示例，防止其错误模仿紧凑格式。
3.在必要时进行“总结”（Summarization）：当紧凑化带来的空间节省边际效益递减时，系统才启动不可逆的总结操作。
风险规避：在总结前，常将待总结的完整上下文卸载到日志文件中，以便有能力的Agent 后续通过grep等工具进行检索。
确保稳定性：总结过程不使用自由格式提示，而是要求模型填充一个预定义的结构化模式（Schema），包含“修改过的文件”、“用户目标”等关键字段，确保总结的稳定性和完整性。
3.2. 工具过载解决方案：分层动作空间
为避免过多工具（经验法则是不超过30个）导致模型混淆和KV缓存失效，Manus AI设计了创新的三层动作空间，将绝大部分能力“卸载”出核心上下文。
第一层
原子函数调用
约10-20个固定的、正交的核心函数，如read_file, write_file。稳定与缓存友好。
第二层
沙箱实用程序
预装在定制Linux虚拟机沙箱中的一系列命令行工具（如格式转换器、语音识别）。能力可扩展。
第三层
包和API
Agent 通过编写并执行Python脚本来调用预授权的第三方API或自定义库。高度可组合。
从模型的视角看，它始终通过第一层稳定、简洁的原子函数与世界交互，而其真实能力则通过后两层被无限扩展。
3.3. 多Agent 协作：两种隔离模式与通信契约
Manus AI借鉴了Go语言社区的智慧，将多Agent 协作模式清晰地划分为两种。
通过通信共享内存
Share Memory by Communicating
实现方式：主Agent 向子Agent 发送一个具体的指令提示，子Agent 在仅包含该指令的隔离上下文中工作。
适用场景：任务定义清晰、指令简短、仅关心最终输出的场景（如在代码库中搜索特定片段）。
成本与权衡：高效、低成本。
通过共享内存通信
Communicate by Sharing Memory
实现方式：子Agent 可以访问主Agent 的完整聊天历史。
适用场景：复杂、交织的任务，子Agent 需要完整历史背景才能有效工作（如撰写研究报告时需要所有中间笔记）。
成本与权衡：功能强大但昂贵。
此外，为了解决Agent 间通信的信息丢失问题，Manus AI再次引入Schema作为“契约”。主Agent 在委派任务时，会首先定义子Agent 必须遵循的输出Schema。子Agent 通过一个特殊的submit_result工具并结合约束解码，确保其返回结果严格符合该“契约”，从而实现可靠、无损的多Agent 信息同步。
04
THE PHILOSOPHY
核心开发哲学与战略洞察
对话的最终部分提炼了Manus AI在AI Agent 开发中的核心哲学与一系列战略层面的建议。
4.1. 核心哲学：“少构建，多理解”
避免上下文过度工程：Manus AI发现，产品性能的最大飞跃并非来自增加更复杂的上下文管理技术，而是来自简化架构、移除不必要的技巧，并给予模型更多信任。
工程的目标是简化：上下文工程的最终目标应是让大语言模型的工作变得更简单，而非更困难。
终极建议：开发者应“少构建，多理解”，花更多时间去理解模型本身的行为、能力与局限性，而非盲目堆砌工程技术来约束它。
4.2. 战略考量与实践建议
▪︎ 模型选择：对于输入远大于输出的Agent 应用，KV缓存至关重要。顶尖闭源模型提供商拥有成熟的全球分布式KV缓存设施，在规模化应用中可能比自行部署开源模型更具成本效益。应采用任务级模型路由策略，为不同子任务（如编程用Claude，多模态用Gemini）选择最合适的模型。
▪︎ 适应模型迭代：通过“固定架构，切换模型”的方法来评估架构的“未来性”。一个好的架构应该能在从弱模型切换到强模型时获得显著的性能提升，这也能为适应未来更强模型提供早期信号。
▪︎ 长期记忆实现：采用“用户在环（human in the loop）”的策略。通过一个显式的“知识”系统，要求用户明确确认是否将某个偏好存为长期记忆。同时，探索利用集体反馈（观察大量用户对同一错误的相同纠正）来实现系统的无参数化自改进。
▪︎ 安全护栏：安全是一个渐进过程。核心措施包括：通过沙箱机制严格控制信息外泄（检查出站流量），并对所有敏感操作（如执行代码、浏览器操作）要求用户手动确认，赋予用户最终控制权。
