近日，LangChain的创始工程师Lance Martin与Manus的联合创始人兼首席科学家Yichao "Peak" Ji（他因在AI智能体方面的工作被评为麻省理工科技评论“35位35岁以下创新者”之一）举行了一场深入的研讨会，探讨了AI智能体生产环境中至关重要的“上下文工程”（Context Engineering）。本次分享不仅概括了上下文工程的通用主题，更揭示了Manus在构建和优化其智能体框架过程中积累的实战经验和“新鲜教训”。

---

第一部分：理解上下文工程的诞生与核心挑战

上下文工程这一术语于今年（2023年）5月左右兴起，与“智能体之年”的理念同步。Lance Martin将其描述为一种精妙的艺术与科学，旨在用恰到好处的信息填充上下文窗口，以供智能体执行下一步操作。

上下文爆炸的悖论

构建智能体时，最大的挑战在于“上下文爆炸”（Context Explosion）。智能体通常被绑定到多个工具，并以循环的方式自主调用这些工具。每调用一次工具，就会返回一个工具观察结果，并附加到聊天消息列表中。由于生产级智能体可能涉及数百轮对话，典型的任务可能需要大约50次工具调用，这导致消息量随时间无限制地增长。

核心悖论在于： 智能体需要大量的上下文（通过工具调用积累），但经验观察表明，随着上下文的增长，性能反而会下降（Context Rot）。上下文工程的出现正是为了应对这一挑战。

LangChain概述的上下文工程五大主题

Lance首先总结了上下文工程的几个常见主题：

1. 上下文卸载 (Context Offloading): 将信息（如代币量很大的工具消息输出）移出上下文窗口，存储在外部（如文件系统），只在需要时检索。
2. 上下文缩减 (Context Reduction): 并非将上下文移出，而是压缩或总结信息。这包括总结工具调用输出、修剪旧的工具调用或压缩完整的消息历史。
3. 上下文检索 (Context Retrieval): 重点在于按需为智能体检索上下文的最佳方法。
4. 上下文隔离 (Context Isolation): 通过多智能体（子智能体）架构分割上下文，每个子智能体拥有自己的上下文窗口。
5. 上下文缓存 (Context Caching): Manus在此方面有深入实践。

---

第二部分：Manus的实战策略与深刻洞察 (Peak's Insights)

Manus的联合创始人Peak分享了他们基于生产环境的“实战经验”，特别是那些未在先前博客中深入探讨的“非共识想法”。

1. 为什么选择上下文工程？

Peak认为，初创公司应尽可能依靠通用模型和上下文工程，避免过早投入于模型微调或后期训练。在AI和智能体的早期阶段，一切都可能一夜之间发生变化（例如Meta Codec的推出彻底改变了Manus的设计）。

深刻洞察： 上下文工程是当前应用层与模型层之间最清晰、最实用的界限。通过强大的上下文工程，应用可以更好地利用通用模型的进步，避免重复构建基础模型能力的努力。

2. 上下文缩减：可逆与不可逆的操作

Manus将上下文缩减分为两种操作，并严格区分了它们的特点：

• 压缩 (Compaction) - 可逆：

  • Manus对每个工具调用结果提供“完整”和“紧凑”两种格式。
  • 紧凑格式会剥离任何可以从文件系统或外部状态中重构的信息。例如，写入文件的工具结果只保留文件路径，而删除内容字段。这种可逆性至关重要，因为智能体需要依赖历史操作进行链式预测。
  • 在进行缩减时，Manus会首先尝试压缩较旧的工具调用（例如最老的50%），以保持较新的工具调用细节完整，防止模型模仿错误的行为。

• 总结 (Summarization) - 不可逆：

  • 总结操作需要非常谨慎。在总结之前，Manus可能会将关键的上下文部分甚至整个总结前的上下文转储为日志文件到文件系统中，以便将来恢复。
  • 关键技巧： 为了确保总结的质量和稳定性，Manus不使用自由形式的提示，而是定义一个结构化模式（Schema），让AI填写字段。这种结构化输出有助于确保关键信息（如修改的文件、用户目标、中止点）始终被总结。
  • 缩减触发机制： 模型性能通常在硬上下文限制之前（如100万个代币）的“腐烂阈值”（Pre-rot threshold，通常在128K到200K之间）开始下降。Manus使用此阈值作为触发器，首先启动压缩操作，只有当压缩效果不佳时（增益很小）才进行总结。

3. 上下文隔离：两种通信模式

Peak同意在多智能体设置中，信息同步是一个经典难题。Manus借用了并发编程的智慧，区分了两种隔离模式：

1. 通过通信 (By Communicating): 适用于指令简短清晰、只关注最终输出的任务。主智能体发送提示，子智能体的上下文只包含该指令。例如，在代码库中搜索特定片段。
2. 通过共享内存/上下文 (By Sharing Memory/Context): 适用于需要完整历史记录的复杂场景，例如深度研究，最终报告依赖大量中间搜索和笔记。子智能体可以看到完整的先前上下文，但拥有独立的系统提示和行动空间。

洞察： Manus采用极简的多智能体设计，避免像人类组织架构那样按角色划分智能体（如设计者、程序员、管理者）。Manus只有极少数的智能体：通用执行者、规划者和知识管理器。其他子任务则通过**“智能体即工具”（Agent as Tool）**的范式实现。

智能体间通信： Manus使用约束解码来确保子智能体返回的结果严格遵循主智能体定义的输出模式（Schema），Schema充当了智能体之间的“契约”。

4. 上下文卸载：分层行动空间

工具本身也会占用大量上下文，可能导致**“上下文混淆”（Context Confusion）。Manus通过引入分层行动空间**来卸载工具，而非使用动态RAG（检索工具描述）：

1. 第一层：函数调用 (Function Calling)
   • 仅使用固定数量（约10到20个）的原子函数（如读写文件、执行Shell命令、搜索互联网）。
   • 这些函数边界清晰，并且架构简单，对缓存友好。
2. 第二层：沙盒实用工具 (Sandbox Utilities)
   • Manus的每个会话都在完整的虚拟机沙盒（定制的Linux系统）中运行。
   • 模型可以通过Shell命令运行预装的实用工具（如格式转换器、MCP CLI）。
   • 这一层可以添加新能力而无需更改模型的功能调用空间。
   • 优点：对于大型输出，结果可以写入文件或分页返回，使用grep、cat等Linux工具处理。
3. 第三层：包和API (Packages and APIs)
   • 智能体可以编写Python脚本来调用预授权的API或定制包（如3D设计库或金融API）。
   • 这适用于需要大量内存计算但不需要将所有数据推入模型上下文的任务（如分析一整年的股票价格数据，脚本计算后只返回摘要）。

核心见解： 计算机是图灵完备的。通过Shell工具和文本编辑器，智能体具备了完整的行动能力。分层行动空间成功地将大量工具能力卸载到沙盒中，保持了模型接口的简单性。

---

第三部分：深入洞察与Q&A精选

检索与内存（文件系统 vs. 向量存储）

Manus不使用索引数据库（如向量存储）进行即时上下文检索。这是因为Manus的每个沙盒会话都是新的，没有时间在运行时构建索引。Manus与Claude Code类似，依赖于文件系统和简单的搜索工具（如glob和grep）。

对于长期内存（跨会话），Manus有“知识”（Knowledge）的概念，这是一种显式内存，需要用户确认接受或拒绝才能存储，以避免自动插入内存可能导致的混乱。

模型选择与成本

Manus不使用开源模型，主要是出于成本考量，而非质量。在智能体场景下，输入通常远长于输出，分布式KV缓存（Distributed KV Cache）至关重要。旗舰LLM提供商（如Anthropic）在分布式缓存基础设施方面更强大，使得它们在Manus的规模下有时比开源模型更具成本效益。

Manus利用了不同模型的优势：Anthropic模型最适合代理任务，Gemini适合多模态，OpenAI擅长复杂的数学和推理。Manus进行任务级别甚至子任务级别的模型路由。

规划与RL

Manus最初使用to-do.md进行规划，但这会消耗大量轮次和代币。目前，Manus采用结构化规划，引入一个独立的规划者智能体（作为Agent as Tool实现），拥有不同的视角和模型选择，进行外部审查和计划管理。

至于强化学习（RL），Peak认为，鉴于模型基础能力的快速提升和像MCP这样不断变化的行为空间，应用公司现在进行RL过于昂贵且难以优化。Manus更倾向于探索无需参数的在线学习方法，例如通过收集集体用户反馈来改进智能体。

评估（Evals）

Manus的评估体系分为三部分：

1. 黄金标准： 用户评分（1到5星），即用户对每个已完成会话的平均评分。
2. 自动化测试： 使用内部数据集和可验证结果的自动化测试，专注于执行任务（而非像Gaia那样偏重只读任务）。
3. 人工评估： 依赖大量实习生对主观结果（如网站生成、数据可视化）进行评估，因为很难设计一个能判断视觉吸引力的奖励模型。

---

第四部分：总结与深刻反思

上下文工程是平衡多个潜在冲突目标（卸载、缩减、检索、隔离和缓存）的科学与艺术。

Peak为智能体开发者留下了最重要的建议，即避免上下文过度工程化（Avoid context over-engineering）。回顾Manus的成长，最大的飞跃并非来自添加花哨的上下文管理层，而是来自简化或移除不必要的技巧，并更多地信任模型。

核心原则： 上下文工程的目标是让模型的工作更简单，而不是更困难。“少构建，多理解。” (Build less and understand more)。

---

原始视频：https://youtu.be/6_BcCthVvb8?si=4NL6q_uzNjLgFApF

中英文字幕：