职贝云数AI新零售门户

标题: Manus花了几千万美元学费的阅历教训,且看且珍惜! [打印本页]

作者: QfICegVe 时间: 昨天 22:17
标题: Manus花了几千万美元学费的阅历教训,且看且珍惜!
这是一篇Manus外部花了几千万美元的实际分享，思索到很多用户如今无法访问manus所以帮忙将原文贴在这里，仅供学习参考。

在 Manus 项目的最末尾，我和我的团队面临了一个关键决策：我们应该运用开源基础来训练一个端到端的代理模型，还是基于前沿模型的上下文学习才能构建一个代理？

在我 NLP 范畴的第一个十年里，我们没有那种选择的朴素。在悠远的 BERT（是的，曾经过去了七年）的那些日子里，模型在转移到新义务之前必须停止微调——并停止评价。这个过程每个迭代都要花几周工夫，虽然与明天的 LLMs 相比，这些模型非常小。对于疾速发展的运用，尤其是 PMF 之前的运用，这种缓慢的反馈循环是致命的。这是我上一家创业公司的一个甜蜜教训，在那里我为开放信息提取和语义搜索从头训练模型。接着出现了 GPT-3 和 Flan-T5，我的外部模型在一夜之间变得有关紧要。讽刺的是，正是这些相反的模型标志着情境学习的末尾——以及一条全新的发展道路。

这个来之不易的教训让选择变得明晰： Manus 将押注于情境工程。这使我们可以在几小时内而不是几周内交付改进，并使我们的产品与底层模型保持正交：假如模型提高是退潮，我们希望 Manus 成为船，而不是固定在海底的柱子。

但是，上下文工程却远非易事。它是一门实验迷信——我们重建了四次智能体框架，每次都是在发现更优的上下文构建方法后。我们亲昵地将这种架构搜索、提示词调试和阅历性猜测的过程称为" 随机梯度下降法 ". 它并不优雅，但有效。

本文分享了我们在本人的"SGD"过程中达到的部分最优解。假如你正在构建本人的 AI 智能体，希望这些准绳能助你更快收敛。
围绕 KV 缓存停止设计

假如必须选择一个目的，我会以为 KV 缓存命中率是消费阶段 AI 代理最重要的目的。它直接影响延迟和成本。要了解缘由，让我们看看典型代理是如何运转的：

在接收到用户输入后，智能体经过一系列工具运用来完成义务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作。然后在该动作在环境中执行（例如 Manus 的虚拟机沙盒），以产生一个观察结果。该动作和观察结果被追加到上下文中，构成下一次迭代的输入。这个循环会不断持续到义务完成。

你可以想象，随着每一步的停止，上下文会不断增长，而输入——通常是一个结构化的函数调用——则相对较短。这使得在智能体与聊天机器人之间，预填充与解码之间的比例严重失衡。例如，在 Manus 中，平均输入与输入的 token 比例约为 100:1。

侥幸的是，具有相反前缀的上下文可以应用 KV 缓存，这能大幅降低初次获取 token 的工夫（TTFT）和推理成本——无论你是运用自托管模型还是调用推理 API。而且我们议论的不是宏大的节省：以 Claude Sonnet 为例，缓存的输入 token 成本为 0.30 美元/百万 token（MTok），而未缓存的成本为 3 美元/MTok——相差 10 倍。

(, 下载次数: 0)

从上下文工程的角度来看，提高 KV 缓存命中率触及几个关键实际：

1.保持你的提示前缀波动。由于 LLMs 的自回归特性，即便是一个 token 的差异也能够使从该 token 末尾的一切缓存失效。一个常见的错误是在系统提示的扫尾包含工夫戳——尤其是准确到秒的工夫戳。当然，它允许模型告诉你当前工夫，但它也会使你的缓存命中率降低。

2.让你的上下文只追加不修正。避免修正先前的动作或观察结果。确保你的序列化是确定性的。许多编程言语和库在序列化 JSON 对象时不能保证键的波动顺序，这能够会无声地毁坏缓存。

3.需求时明白设置缓存断点。某些模型提供者或推理框架不支持自动增量前缀缓存，而是需求在上下文中手动插入缓存断点。设置这些断点时，要思索潜在的缓存过期成绩，至少要确保断点包含系统提示的结尾。

此外，假如你运用 vLLM 等框架自托管模型，请确保前缀/提示缓存已启用，并运用会话 ID 等技术来在分布式工作节点间分歧地路由央求。
遮盖，而非移除

随着你的智能体具有更多功能，其行为空间自然会变得愈加复杂——用直白的话来说，就是工具的数量呈爆炸式增长。近期 MCP 的盛行更是火上浇油。假如你允许用户可配置的工具，我向你保证：总有人会不可避免地将数百个奥秘工具接入你精心构建的行为空间。结果，模型更有能够选择错误的行为或采取低效的途径。简而言之，你武装到牙齿的智能体反而变得更笨了。

自然的反应是设计一个动态动作空间——也许经过某种 RAG 相似的技术按需加载工具。我们在 Manus 中也尝试过这种方法。但我们的实验表明有一个明白的规则：除非相对必要，避免在迭代过程中动态添加或删除工具。这次要有两个缘由：

1.在大多数 LLMs 中，工具定义在序列化后位于上下文的前部，通常位于系统提示之前或之后。因此，任何更改都会使后续一切操作和观察的 KV 缓存失效。

2.当先前的行为和观察依然指向当前上下文中不再定义的工具时，模型会感到困惑。假如没有约束解码，这种状况通常会导致形式违规或幻觉行为。

为了处理这个成绩同时还能改进动作选择，Manus 运用了一种上下文感知的形态机来管理工具的可用性。它不是移除工具，而是在解码过程中掩盖 token logits，以防止（或强迫）根据当前上下文选择某些动作。

(, 下载次数: 0)

实践上，大多数模型提供程序和推理框架都支持某种方式的呼应预填充，这允许您在不修正工具定义的状况下限制操作空间。函数调用通常有三种形式（我们将运用 NousResearch 的 Hermes 格式作为示例）：

•自动 – 模型可以选择调用函数或不调用。经过仅预填充回复前缀完成：<|im_start|>assistant

•必须 – 模型必须调用函数，但选择不受约束。经过预填充到工具调用标记完成：<|im_start|>assistant<tool_call>

•指定 – 模型必须调用一个特定子集中的函数：经过在函数名扫尾预填充完成： <|im_start|>assistant<tool_call>{"name": “browser_

应用这一点，我们经过直接遮盖 token logits 来约束动作选择。例如，当用户提供新的输入时，Manus 必须立刻回复而不是采取举动。我们还特意设计了具有分歧前缀的动作称号——例如，一切与阅读器相关的工具都以 browser_扫尾，而命令行工具则以 shell_扫尾。这使我们可以轻松地强迫代理在特定形态下仅从一组特定的工具中选择，而无需运用形态 logits 处理器。

这些设计有助于确保 Manus 代理循环保持波动——即便在模型驱动架构下也是如此。
运用文件系统作为上下文

古代前沿 LLMs 如今提供 128K 个 token 或更多的上下文窗口。但在实践代理场景中，这通常不够，有时甚至是一个缺陷。有三个常见的痛点：

1.观察结果能够很大，尤其是在代理与网页或 PDF 等非结构化数据交互时。很容易超出上下文限制。

2.模型功能往往会在某个特定的上下文长度之外下降，即便窗口技术上是支持的。

3.长输入依然很昂贵，即便有前缀缓存。你依然需求支付传输和预填充每个标记的成本。

为了处理这个成绩，许多代理系统完成了上下文截断或紧缩策略。但过于激进的紧缩不可避免地会导致信息丢失。成绩是根本性的：代理本质上必须根据一切先前的形态来预测下一步举动——而你无法牢靠地预测哪个观察结果能够在十步之后变得关键。从逻辑上讲，任何不可逆的紧缩都存在风险。

这就是为什么我们将文件系统视为 Manus 中的终极上下文：容量有限、天生持久，并且可以直接由代理本身操作。模型学会按需写入和读取文件——运用文件系统不只作为存储，更作为结构化、外化的内存。

(, 下载次数: 0)

我们的紧缩策略一直设计为可恢复。例如，只需保留 URL，网页内容可以从上下文中移除，假如文档途径在沙盒中依然可用，文档内容也可以被省略。这允许 Manus 在不永世丢失信息的状况下延长上下文长度。

在开发这个功能时，我发现本人在想象一个形态空间模型（SSM）要在代理环境中有效工作需求什么。与 Transformer 不同，SSM 缺乏残缺的留意力机制，并且难以处理长间隔的逆向依赖。但假如它们可以掌握基于文件的记忆——将长期形态外部化而不是在上下文中持有——那么它们的速度和效率能够会解锁一类新的代理。代理式 SSM 能够是真正的《神经图灵机》的承继者。Neural Turing Machines.
经过吟诵来操控留意力

假如你运用过 Manus，能够留意到一个风趣的现象：在处理复杂义务时，它倾向于创建一个 todo.md 文件——并且随着义务的停顿逐渐更新它，勾选已完成的项。

这不只仅是心爱行为——它是一种刻意机制来操纵留意力 .

(, 下载次数: 0)

在 Manus 中，一个典型的义务需求大约 50 次工具调用。这是一个漫长的循环——由于 Manus 依赖 LLMs 停止决策，它容易偏离主题或遗忘早期目的，特别是在长上下文或复杂义务中。

经过不断重写待办事项列表，Manus 将其目的重述到上下文的末尾。这使全局计划进入模型的近期留意力范围，避免了" 中间丢失 "成绩，并减少了目的错位。实践上，它正在运用自然言语来使其本身留意力倾向义务目的——而无需停止特殊的架构变更。
保留错误信息

智能体能够会犯错。这不是一个 bug——这是理想。言语模型会胡言乱语，环境会前往错误，外部工具会表现异常，而意想不到的边缘状况总是出现。在多步骤义务中，失败不是例外；它是循环的一部分。

但是，一个常见的冲动是隐藏这些错误：清算痕迹，重试操作，或重置模型形态，然后将其交给神奇的“ 温度 ”。这感觉更安全，更可控。但它是有代价的：抹去失败会消弭证据。而没有证据，模型就无法顺应。

(, 下载次数: 0)

根据我们的阅历，改进智能体行为最有效的方法之一出奇地简单：在上下文中保留错误的操作。当模型看到一个失败的举动——以及由此产生的观察结果或堆栈跟踪——它会隐式地更新其外部决计。这使其先验概率偏离相似举动，从而降低反复相反错误的能够性。理想上，我们置信错误恢复是真正智能体行为的分明目的。但是，它依然在大多数学术研讨和公开基准中代表性不足，这些基准往往专注于理想条件下的义务成功。
不要被多数样本击倒

少样本提示是一种常见的改进 LLM 输入的技术。但在智能体系统中，它能够以巧妙的方式适得其反。

言语模型是出色的模拟者；它们模拟上下文中的行为形式。假如你的上下文中充满了相似的过去举动-观察对，模型会倾向于遵照该形式，即便它不再是最优的。

这在触及反复决策或举动的义务中能够很风险。例如，当运用 Manus 来协助审阅一批 20 份简历时，智能体常常堕入一种节拍——仅仅由于上下文中看到的行为而反复相似的举动。这会导致漂移、过度泛化，有时甚至产生幻觉。

处理方法是添加多样性。Manus 内行为和观察中引入了大批的结构化变化——不同的序列化模板、替代性措辞、顺序或格式中的细微噪声。这种可控的随机性有助于打破形式并调整模型的留意力。换句话说，不要让本人堕入多数样本的困境。你的上下文越一致，你的智能体就越脆弱。
结论

上下文工程依然是一门新兴的迷信——但对于智能体系统来说，它曾经至关重要。模型能够越来越弱小、疾速且便宜，但无论原始才能有多大，都无法替代记忆、环境和反馈的需求。你如何塑造上下文最终决议了你的智能体的行为：它运转的速度、恢复的才能以及扩展的范围。

在 Manus，我们经过反复重写、走死胡同以及数百万用户的实践测试中学到了这些教训。我们在这里分享的任何内容都不是普遍真理——但这些是我们行之有效的形式。假如它们能协助您避免一次痛苦的迭代，那么这篇帖子就完成了它的义务。

智能体的将来将是一次次经过上下文构建起来的。把上下文工程好。
-END-

参考文献：Yichao 'Peak' Ji《AI 代理的上下文工程：从构建 Manus 项目中的阅历教训》（2025-07-18）

原文链接和源文件我都打包到公众号里了有需求的小伙伴回复Manus自取即可，有播种的话可以分享给身边有需求的人。

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