职贝云数AI新零售门户

标题: Manus 撤出中国后的第一课:AI Agent 的上下文工程实际 [打印本页]

作者: mFs 时间: 前天 17:27
标题: Manus 撤出中国后的第一课:AI Agent 的上下文工程实际
3月6日，Manus 正式发布，作为中国团队开发的通用 AI Agent 产品，主打自动完成复杂义务，包括代码调试、网页抓取等功能。7月11日，Manus 加入中国市场，并屏蔽其网站，删除了微博、小红书等平台上的一切国内官方社交媒体账号。该团队将总部迁至新加坡，这一动作背后，不只是地缘政策和市场战略的调整，更折射出一个更深层次的趋向：AI Agent 已从实验室的技术探求，进入了需求疾速迭代和产品化落地的时代。此前，《The Information》也报道 Butterfly Effect（Manus 背后团队）已关闭中国团队，作为对中美紧张关系的战略应对措施。7月19日，Manus 结合创始人季逸超发布博客《Context Engineering for AI Agents: Lessons from Building Manus》，深度分析其在构建 AI Agent 时的上下文工程方法论。

这篇博客既是对本身技术沉淀的总结，也是一次向全球开发者传递研发价值观与方法论的重要表达。以下是原文内容（内容有点干，但诚意满满）：面向 AI Agent 的上下文工程：构建 Manus 的阅历教训在 Manus 项目的最后阶段，我和团队面临一个关键选择：我们终究是基于开源模型训练一个端到端的 agentic 模型，还是在前沿大模型的才能之上构建一个智能体？回想我在 NLP 范畴的前十年，当时根本没有这种“朴素”的选择。在那个悠远的 BERT 年代（没错，曾经过去七年了），模型必须先经过微调（fine-tuning）——并在转移到新义务之前完成评价。这个过程往往每次迭代就要耗费数周工夫，哪怕当时的模型体量远小于明天的 LLM。对于那些需求疾速迭代的运用，尤其是还未找到 PMF 的运用，这样的反馈周期几乎是致命的。这也是我上一个创业项目中学到的一个惨痛教训：当时我们从零末尾训练模型用于引荐系统和语义搜索，但后来 Flan-T5 和 GPT-3 的出现，让我辛劳打造的自研模型在一夜之间变得毫无价值。讽刺的是，正是这些模型开启了上下文内学习的新时代，也为我们指明了另一条可行的道路。这段用血泪换来的阅历让我们在 Manus 的选择变得明白：押注上下文工程。这种策略让我们能在数小时内发布改进，而不是数周，同时让我们的产品与底层模型解耦：假如说模型的提高是潮水下跌，我们希望 Manus 是那艘随潮坎坷的船，而不是被固定在海床上的柱子。但是，上下文工程并非易事。这更像是一门实验迷信。我们在开发过程中曾经四次重写智能体框架，每次都是由于发现了更优的上下文塑造方法。我们戏称这一过程为“随机研讨生下降法（Stochastic Graduate Descent）”——它不够优雅，但的确有效。本文将分享我们经过 SGD 探求出的部分最优解。假如你正在构建本人的 AI Agent，希望能协助你少走弯路。围绕 KV 缓存停止设计假如让我只选一个目的，我会说 KV 缓存命中率是消费级 AI Agent 的关键目的。它直接影响延迟和成本。为什么说 KV 缓存很重要？在 Manus 中，Agent 的运转逻辑是这样的：接收到用户输入后，Agent 经过一系列工具调用（tool calls）逐渐完成义务。每次迭代，模型会基于当前上下文，从预定义的动作空间（action space）中选择一个动作。该动作在环境中执行（例如 Manus 的虚拟机沙盒），产生一个观察结果（observation）。动作和观察结果会追加到上下文中，构成下一次迭代的输入。这个循环持续停止，直至义务完成。随着每一步的停止，上下文长度不断添加，而输入（通常是结构化的函数调用）相对较短。这导致预填充（prefill）和解码（decode）之间的 Token 比率严重失衡。在 Manus 中，输入到输入的 Token 比约为 100:1。侥幸的是，对于具有相反前缀的上下文，可以应用 KV缓存分明降低首个 Token 的呼应工夫和推理成本——无论是在自托管模型还是调用推理 API 时。这种优化的效果极其分明：以 Claude Sonnet 为例，缓存的输入 Token 成本约为 0.30 美元/百万 Token，未缓存的成本则高达 3 美元/百万 Token——足足相差 10 倍。
(, 下载次数: 0)
从上下文工程角度看，提高 KV 缓存命中率触及到几个关键实际：保持提示词前缀波动由于 LLM 的自回归特性，即便一个 Token 的差异，也会使后续的缓存有效。一个常见错误是在系统提示词扫尾包含工夫戳——尤其是准确到秒的工夫戳。虽然这样可以让模型告诉你当前工夫，但也会完全毁坏缓存命中率。上下文应追加式（append-only）避免修正之前的动作或观察结果。确保序列化过程是确定性的。许多编程言语和库在序列化 JSON 对象时并不保证键的顺序分歧，这能够会悄然毁坏缓存。必要时显式设置缓存断点部分模型或推理框架不支持自动增量缓存，需求你手动在上下文中设置缓存断点。设置时要思索缓存过期，至少确保断点包括系统提示词的结束部分。此外，假如你在运用如 vLLM 之类的框架自托管模型，确保启用了 KV缓存功能，并运用 session ID 等技术确保央求在分布式环境中分歧路由。屏蔽，而非移除随着 Agent 功能日益丰富，其动作空间（即可用工具列表）自然会变得复杂——工具数量能够激增。最近插件机制（Plugin）的盛行更是火上浇油。假如你允许用户自定义工具配置，总会有人将上百个奥秘工具塞进你的动作空间。这会让模型更容易做出错误选择或采取低效途径。简而言之，你“全部武装”的 Agent 反而变“笨”了。一种自然反应是设计动态动作空间——也许经过相似 lazy-loading 的方式按需加载工具。我们在 Manus 中也尝试过，但实验表明：除非相对必要，避免在迭代过程中动态添加或移除工具。为什么？工具定义通常位于上下文的前部，任何改动都会使后续一切步骤的缓存失效。之前的动作和观察结果假如援用已移除的工具，模型会困惑。这通常导致形式违例或幻觉行为。Manus 的处理方案
(, 下载次数: 0)
我们运用一个上下文感知的 logits 屏蔽机制来管理工具可用性。不是移除工具，而是在解码阶段屏蔽某些 Token 的概率，使模型无法选择特定动作。例如，我们经过为工具命名时添加一致前缀（如一切阅读器工具以 browser_ 扫尾，命令行工具以 shell_ 扫尾），让模型在不同形态下只选择特定工具组，而无需更改工具定义。这种设计保证了 Manus 智能体循环的波动性，即便在模型驱动架构下也是如此。将文件系统视作上下文如今前沿大模型的上下文窗口可达 128K Token 甚至更多。但在真实的 Agent 场景中，这往往依然不够，甚至能够成为负担：观察结果能够非常庞大，尤其是处理网页或 PDF 等非结构化数据时。很容易打破上下文长度限制。即便模型支持超长上下文，功能通常也会随着长度添加而下降。即便启用了前缀缓存，传输和预填充大量 Token 依然成本高昂。很多 Agent 系统尝试经过上下文截断或紧缩策略来处理。但过度紧缩不可避免地导致信息丢失。成绩在于：Agent “生来”就需求基于残缺的历史形态预测下一步举动——你无法牢靠地预测哪条观察结果在十步之后会变得关键。任何不可逆的紧缩都存在风险。我们的策略：
(, 下载次数: 0)
文件系统容量有限、持久化存储、且可被 Agent 操作。模型可以按需读写文件——将文件系统视作结构化的外部记忆。我们的紧缩策略也设计为可恢复的。例如，网页内容可以从上下文中删除，只需保留 URL；文档内容可以省略，只需途径信息仍在沙盒中可用。这让 Manus 能在不丢失信息的前提下，延长上下文长度。经过“复述”操控留意力假如你运用过 Manus，能够留意到它在处理复杂义务时会生成一个 todo.md 文件，并在义务推进时逐渐更新、勾选完成的事项。这不只仅是个“心爱”的功能，而是一种有意设计的留意力操纵机制。
(, 下载次数: 0)
Manus 平均每个义务要停止大约 50 次工具调用。在这么长的循环中，模型容易跑题或遗忘早期目的，尤其是在长上下文或复杂义务中。经过不断重写 todo 清单，Manus 相当于把义务目的“复述”到上下文的尾部，将全局计划推送到模型的短期留意力范围内。这有助于避免“中间遗忘”成绩，减少目的偏离，无需改变模型架构。保留错误信息Agent 会犯错。这不是 bug，而是理想。言语模型会幻觉，环境会前往错误，外部工具能够失灵，不测的边缘案例也会随时出现。在多步义务中，失败是循环的一部分，而不是例外。很多开发者的天分反应是隐藏这些错误：清算上下文、重试动作或重置模型形态，让 Agent 看起来像是“无所不能”。但这样做的代价是擦除了失败的证据。没有证据，模型就无法调整其外部决计。
(, 下载次数: 0)
我们的阅历表明，一种极其有效的改进方法就是：保留错误信息。当模型看到失败的动作及其观察结果或堆栈跟踪时，它会隐式更新本人的外部决计，降低反复同类错误的概率。理想上，我们以为错误恢复才能是衡量“真正智能体行为”最明晰的目的之一。但目前大多数学术研讨和公共基准测试对此关注不足，它们往往只关注理想条件下的义务成功率。避免 Few-shot 圈套Few-shot 提示是提升 LLM 输入质量的常用技巧。但在 Agent 系统中，它能够以巧妙的方式适得其反。言语模型天生擅长模拟。假如上下文中充满了相似的“动作-观察”对，模型也会倾向于反复这种形式，即便它已不再最优。这种现象在触及反复决策或操作的义务中尤为风险。例如，当 Manus 用于批量审查 20 份简历时，Agent 往往堕入一种“节拍”——由于上下文中都是相似的操作，它便机械地反复，导致偏离、过度泛化，甚至产生幻觉。
(, 下载次数: 0)
处理办法是引入多样性。Manus 在动作和观察结果中加入了却构化的宏大变化：不同的序列化模板、交换表达、次序和格式的细微扰动。这种“可控随机性”协助模型打破反复形式，调整留意力。换句话说：不要让 Few-shot 让你堕入套路。上下文越单一，Agent 就越脆弱。结论上下文工程依然是一门新兴迷信，但对于 Agent 系统而言，它曾经成为核心。即便模型变得更弱小、更快、更便宜，也无法取代对记忆、环境和反馈机制的需求。你如何塑造上下文，最终决议了你的 Agent 的行为：运转速度、恢复才能和可扩展性。在 Manus，我们是经过不断重写、走入死胡同和真实世界中数百万用户的测试，才总结出这些阅历的。这些并非“普适真理”，但它们是我们验证有效的形式。假如它们能帮你避免哪怕一次痛苦的迭代，那这篇文章就达到了目的。将来的智能体世界，将是一段段上下文堆积起来的。请用心设计它们。博客链接：
https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

欢迎光临职贝云数AI新零售门户 (https://www.taojin168.com/cloud/)