职贝云数AI新零售门户

标题: AI智能体的上下文工程:构建Manus的阅历教训 [打印本页]

作者: A6Qua4jMtW 时间: 昨天 06:23
标题: AI智能体的上下文工程:构建Manus的阅历教训
7月18日，Manus 结合创始人兼首席技术官 Yichao “Peak” Ji 在 Manus 官网发表了一篇blog，分享他们在构建AI Agent 过程中的阅历教训，深化讨论了“上下文工程”（Context Engineering）的技术实际。以下是原文翻译。

AI智能体的上下文工程：构建Manus的阅历教训by Yichao “Peak” Ji 2025/07/18在 Manus 项目之初，我和我的团队面临一个关键决策：我们应该运用开源基础模型来训练一个端到端的智能体模型，还是在顶尖模型的“上下文中学习”（in-context learning）才能之上构建一个智能体？在我从事 NLP 的第一个十年里，我们并没有这样的选择。在悠远的 BERT 时代（是的，曾经七年了），模型必须经过微调和评价，才能迁移到新义务上。这个过程每次迭代通常需求数周，虽然那时的模型比明天的 LLM 小得多。对于疾速迭代的运用，尤其是在找到产品市场契合点（PMF）之前，如此缓慢的反馈循环是致命的。这是我上一次创业的惨痛教训，当时我为开放信息提取和语义搜索从零末尾训练模型。然后 GPT-3 和 Flan-T5 出现了，我的自研模型一夜之间变得有关紧要。讽刺的是，正是这些模型标志着在上下文学习的末尾以及一条全新的行进道路。这个来之不易的教训让选择变得明晰：Manus 将赌注押在上下文工程上。这使我们能以小时为单位发布改进，而不是数周，并使我们的产品与底层模型正交：假如模型的提高是退潮，我们希望 Manus 是船，而不是固定在海床上的柱子。虽然如此，上下文工程远非好事多磨，它是一门实验迷信。我们曾经重建了我们的智能体框架四次，每次都是在发现塑造上下文的更好方法之后。我们亲切地将这个架构搜索、提示调整和阅历猜测的手动过程称为“随机毕业生下降”（Stochastic Graduate Descent）。它不优雅，但它有效。这篇文章分享了我们经过本人的“SGD”达到的部分最优解。假如你正在构建本人的 AI 智能体，我希望这些准绳能协助你更快地收敛。围绕 KV-Cache 停止设计假如我必须只选择一个目的，我会说 KV-cache 命中率是消费阶段 AI 智能体最重要的单一目的。它直接影响延迟和成本。要了解为什么，让我们看看一个典型智能体的运作方式：在收到用户输入后，智能体经过一系列工具运用来完成义务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作。该动作在环境中执行（例如 Manus 的虚拟机沙箱）以产生一个观察结果。动作和观察结果被附加到上下文中，构成下一次迭代的输入。这个循环持续到义务完成。可以想象，上下文每一步都在增长，而输入（通常是结构化的函数调用）保持相对较短。这使得智能体中预填充和解码的比例与聊天机器人相比高度倾斜。例如，在 Manus 中，平均输入输入令牌比例约为 100:1。侥幸的是，具有相反前缀的上下文可以应用 KV-cache，这大大减少了首个令牌生成工夫（TTFT）和推理成本。无论你是运用自托管模型还是调用推理 API。我们议论的不是大节省：例如，运用 Claude Sonnet，缓存的输入令牌成本为 0.30 美元/百万令牌，而未缓存的成本为 3 美元/百万令牌，成本相差 10 倍。从上下文工程的角度来看，提高 KV-cache 命中率触及几个关键实际：1.保持你的提示前缀波动。由于 LLM 的自回归特性，即便是单个令牌的差异也会使从该令牌末尾的缓存失效。一个常见的错误是在系统提示的扫尾包含工夫戳，特别是准确到秒的工夫戳。当然，它能让模型告诉你当前工夫，但它也扼杀了你的缓存命中率。2.使你的上下文仅追加。避免修正以前的动作或观察。确保你的序列化是确定性的。许多编程言语和库在序列化 JSON 对象时不保证波动的键顺序，这会悄然地毁坏缓存。3.在需求时明白标记缓存断点。一些模型提供商或推理框架不支持自动增量前缀缓存，而是需求在上下文中手动插入缓存断点。在分配这些断点时，要思索潜在的缓存过期，并至少确保断点包含系统提示的结尾。此外，假如你运用像 vLLM 这样的框架自托管模型，请确保启用了前缀/提示缓存，并运用会话 ID 等技术在分布式工作节点间分歧地路由央求。掩码，而非移除随着你的智能体承担更多才能，其动作空间自然变得更复杂。简而言之，工具数量爆炸式增长。最近 MCP 的盛行更是火上浇油。假如你允许用户可配置的工具，置信我：总会有人将数百个奥秘的工具插入你精心策划的动作空间。结果，模型更能够选择错误的动作或采取低效途径。简而言之，你全部武装的智能体变笨了。一个自然的反应是设计一个动态的动作空间，也许运用相似 RAG 的方式按需加载工具。我们在 Manus 中也尝试过。但我们的实验表明一个明白的规则：除非相对必要，否则避免在迭代中动态添加或移除工具。次要有两个缘由：1. 在大多数 LLM 中，工具定义在序列化后位于上下文的前部，通常在系统提示之前或之后。因此，任何更改都会使一切后续动作和观察的 KV-cache 失效。2. 当以前的动作和观察依然援用当前上下文中不再定义的工具时，模型会感到困惑。没有约束解码，这通常会导致形式违规或幻觉动作。为了处理这个成绩同时改善动作选择，Manus 运用上下文感知的形态机来管理工具可用性。它不是移除工具，而是在解码时期掩码令牌 logits，以根据当前上下文阻止（或强迫）选择某些动作。在实际中，大多数模型提供商和推理框架支持某种方式的呼应预填充，这允许你在不修正工具定义的状况下约束动作空间。通常有三种函数调用形式（我们以 NousResearch 的 Hermes 格式为例）：

运用这种方法，我们经过直接掩码令牌 logits 来约束动作选择。例如，当用户提供新输入时，Manus 必须立刻回复而不是采取举动。我们还特意设计了具有分歧前缀的动作称号——例如，一切阅读器相关的工具都以 `browser_` 扫尾，命令行工具以 `shell_` 扫尾。这使我们可以轻松地强迫智能体在给定形态下仅从某个工具组中选择，而无需运用有形态的 logits 处理器。这些设计有助于确保 Manus 智能体即便在模型驱动的架构下也能循环保持波动。运用文件系统作为上下文古代顶尖 LLM 如今提供 128K 甚至更多的令牌上下文窗口。但在理想世界的智能体场景中，这通常不够，有时甚至是一种负担。有三个常见的痛点：1. 观察结果能够非常宏大，特别是当智能体与非结构化数据如网页或 PDF 交互时。很容易超出上下文限制。2. 模型功能在超过一定上下文长度后往往会下降，即便窗口技术上支持。3. 长输入很昂贵，即便有前缀缓存。你依然为传输和预填充每个令牌付费。为了处理这个成绩，许多智能体系统完成了上下文截断或紧缩策略。但过于激进的紧缩不可避免地导致信息丢失。成绩是根本性的：智能体本质上必须根据一切先前的形态预测下一个动作，由于你无法牢靠地预测哪个观察结果在十步后能够变得至关重要。从逻辑角度看，任何不可逆的紧缩都带有风险。这就是为什么我们将文件系统视为 Manus 中的终极上下文：大小有限，本质上是持久的，并且可由智能体本人直接操作。模型学会按需写入和读取文件，运用文件系统不只作为存储，而且作为结构化的外化记忆。我们的紧缩策略总是被设计为可恢复的。例如，只需保留 URL，网页内容就可以从上下文中丢弃，只需其途径在沙箱中可用，文档内容就可以省略。这使得 Manus 可以在不永世丢失信息的状况下延长上下文长度。在开发此功能时，我发现本人想象着让形态空间模型（SSM）在智能体环境中有效工作需求什么。与 Transformer 不同，SSM 缺乏完全的留意力，难以处理长程向后依赖。但假如它们能掌握基于文件的记忆，即将长期形态外化而不是保留在上下文中，那么它们的速度和效率能够会解锁一类新的智能体。智能体 SSM 能够是神经图灵机的真正承继者。经过反复操控留意力假如你运用过 Manus，你能够曾经留意到一些奇异的事情：在处理复杂义务时，它倾向于创建一个 `todo.md` 文件并随着义务停顿逐渐更新它，勾选已完成的项目。这不只仅是心爱的行为，这是一种沉思熟虑的操控留意力的机制。Manus 中的一个典型义务平均需求大约 50 次工具调用。这是一个很长的循环，而且由于 Manus 依赖 LLM 停止决策，它很容易偏离主题或遗忘早期的目的，特别是在长上下文或复杂义务中。经过不断重写待办事项列表，Manus 将其目的反复到上下文的末尾。这将全局计划推入模型的近期留意力范围，避免"在中间迷失"成绩并减少目的错位。实践上，它是在运用自然言语来偏置其本身对义务目的的关注而无需特殊的架构更改。保留错误的东西智能体会犯错。这不是一个 bug，这是理想。言语模型会产生幻觉，环境会前往错误，外部工具会行为不当，不测的边缘状况会不断出现。在多步骤义务中，失败不是例外，它是循环的一部分。但是，一个常见的冲动是隐藏这些错误：清算痕迹，重试动作，或重置模型的形态并将其留给神奇的"温度"。这感觉更安全、更可控。但它有代价：抹去失败就移除了证据。而没有证据，模型无法顺应。在我们的阅历中，改善智能体行为最有效的方法之一出奇地简单：在上下文中保留错误的转机。当模型看到一个失败的动作以及由此产生的观察或堆栈跟踪，它会隐式地更新其外部决计。这将它的先验从相似的动作移开，减少反复异样错误的机会。理想上，我们以为错误恢复是真正智能体行为的最明晰目的之一。但是，在大多数学术工作和公共基准中，它依然代表不足，这些基准通常关注理想条件下的义务成功。不要被 Few-Shot 约束Few-shot 提示是改善 LLM 输入的常用技术。但在智能体系统中，它能够以巧妙的方式适得其反。言语模型是出色的模拟者；它们模拟上下文中的行为形式。假如你的上下文充满了相似的过去动作-观察对，模型将倾向于遵照该形式，即便它不再是最佳选择。这在触及反复决策或动作的义务中能够很风险。例如，当运用 Manus 协助审查一批 20 份简历时，智能体常常堕入一种反复相似的动作，仅仅由于那是它在上下文中看到的，这会导致漂移、过度泛化，或有时产生幻觉。处理方法是添加多样性。Manus 在动作和观察中引入大批结构化变化：不同的序列化模板、替代措辞、顺序或格式上的宏大噪音。这种受控的随机性有助于打破形式并调整模型的留意力。换句话说，不要让本人堕入 few-shot 的窠臼。你的上下文越一致，你的智能体就越脆弱。结论上下文工程依然是一门新兴迷信，但对于智能体系统来说，它曾经必不可少。模型能够越来越弱小、越来越快、越来越便宜，但没有任何原始才能可以取代记忆、环境和反馈的需求。你如何塑造上下文最终定义了你的智能体如何表现：它运转多快，恢复得多好，以及扩展多远。在 Manus，我们经过反复重写、死胡同和数百万用户的真实世界测试学到了这些阅历教训。我们在这里分享的都不是普适真理，但这些是对我们有效的形式。假如它们能协助你避免哪怕一次痛苦的迭代，那么这篇文章就完成了它的工作。智能体的将来将一次一个上下文地构建。好好地工程化它们。注：这篇blog发布在manus官网上，原文地址🔗 https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

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