被曝裁员、清空社交账号后，Manus 首度发布技术博客总结经验教训

前段时间，AI智能体平台Manus被曝裁员、清空国内多平台账号等消息。北京时间今天早些时候，Manus 联合创始人季逸超通过官方博客发布了上千字的技术解析长文，复盘公司从今年年初爆火至今历经“起起落落”的开发思路与教训。

此前，在今年 3 月，由国内Monica团队研发推出的Manus在海外社交平台推出，Manus 号称是全球首款通用智能体（Agent），可独立解决复杂任务。在通用 AI 助手基准测试 GAIA 的全部难度级别中的评分甚至远远超越 OpenAI 的 DeepResearch。Manus 放出的演示视频中展现出的惊艳表现，瞬间引爆用户热情，但是 Manus 仅限邀请体验，渴望第一时间体验 Manus 的用户在海内外各大社区平台纷纷留言“求邀请码”，这也让 Manus 一炮而红，刷屏社交平台。

附博客文章大意如下：

在 Manus 项目的最初阶段，我和我的团队面临着一个关键的决定：我们应该使用开源基础来训练一个端到端的 Agentic 模型，还是在前沿模型的上下文学习能力之上构建一个 Agent？

回想我在 NLP 领域的第一个十年，我们没有这种选择的余地。在遥远的 BERT 时代（是的，已经七年了），模型必须经过微调和评估，才能转移到新的任务。即使与今天的 LLMs 相比，当时的模型非常小，但这个过程通常每次迭代都需要几周时间。对于快速发展的应用，尤其是在达到 PMF 之前，如此缓慢的反馈循环是不可接受的。这是我上次创业时的一个惨痛教训，当时我从头开始训练模型，用于开放信息提取和语义搜索。后来出现了 GPT-3 和 Flan-T5，我的内部模型一夜之间变得无关紧要。具有讽刺意味的是，这些模型标志着上下文学习的开始，以及一条全新的前进道路。

那次来之不易的教训让我们明确了选择：Manus 将押注于上下文工程。这使我们能够在几个小时内交付改进，而不是几周，并使我们的产品与底层模型正交：如果模型进步是涨潮，我们希望 Manus 成为船，而不是卡在海底的柱子。

尽管如此，上下文工程的结果远非简单。这是一门实验科学 —— 我们已经重建了四次 Agent 框架，每次都是在发现塑造上下文的更好方法之后。我们亲切地将这种架构搜索、提示调整和经验猜测的手动过程称为“随机梯度下降”。它并不优雅，但它有效。

这篇文章分享了我们通过自己的“SGD”达到的局部最优解。如果您正在构建自己的 AI Agent，我希望这些原则能帮助您更快地收敛。

围绕 KV 缓存进行设计

如果我必须选择一个指标，我会认为 KV 缓存命中率是生产阶段 AI Agent 最重要的指标。它直接影响延迟和成本。要理解为什么，让我们看看一个典型的 Agent 是如何运作的：

在收到用户输入后，Agent 会通过一系列工具的使用来完成任务。在每次迭代中，模型都会根据当前上下文从预定义的动作空间中选择一个动作。然后，该动作在环境（例如，Manus 的虚拟机沙箱）中执行，以产生一个观察结果。动作和观察结果被附加到上下文中，形成下一次迭代的输入。这个循环一直持续到任务完成。

正如你可以想象的那样，上下文随着每一步的进行而增长，而输出 —— 通常是一个结构化的函数调用 —— 则相对较短。这使得与聊天机器人相比，Agent 中的预填充和解码之间的比例高度倾斜。例如，在 Manus 中，平均输入与输出的 token 比例约为 100:1。

幸运的是，具有相同前缀的上下文可以利用 KV 缓存，从而大大减少首个令牌生成时间 (TTFT) 和推理成本 —— 无论您使用的是自托管模型还是调用推理 API。而且我们说的不是小幅节省：例如，使用 Claude Sonnet，缓存的输入令牌成本为 0.30 美元 / 百万令牌，而未缓存的令牌成本为 3 美元 / 百万令牌 —— 相差 10 倍。

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

1. 保持提示前缀的稳定。由于 LLMs 的自回归特性，即使是单个令牌的差异也会使从该令牌开始的缓存失效。一个常见的错误是在系统提示的开头包含一个时间戳 —— 尤其是精确到秒的时间戳。当然，它可以让模型告诉你当前时间，但它也会扼杀你的缓存命中率。

2. 使你的上下文仅追加。避免修改之前的操作或观察。确保你的序列化是确定性的。许多编程语言和库不保证在序列化 JSON 对象时保持稳定的键顺序，这可能会悄无声息地破坏缓存。

3. 在需要时显式标记缓存断点。某些模型提供商或推理框架不支持自动增量前缀缓存，而是需要手动在上下文中插入缓存断点。在分配这些断点时，请考虑潜在的缓存过期，并且至少要确保断点包含系统提示的结尾。

此外，如果您使用 vLLM 等框架自行托管模型，请确保已启用前缀 / 提示缓存，并且您正在使用会话 ID 等技术来跨分布式工作器一致地路由请求。

屏蔽，不要移除

随着您的 Agent 承担更多的能力，其行动空间自然会变得更加复杂 —— 简单来说，工具的数量会爆炸式增长。最近 MCP 的流行只会火上浇油。如果您允许用户配置工具，请相信我：不可避免地会有人将数百个神秘工具插入到您精心策划的行动空间中。因此，模型更有可能选择错误的行动或采取效率低下的路径。简而言之，您全副武装的 Agent 变得更笨了。

一个很自然的反应是设计一个动态动作空间 —— 也许可以使用类似 RAG 的方法按需加载工具。我们在 Manus 中也尝试过。但我们的实验表明了一个明确的规则：除非绝对必要，否则避免在迭代过程中动态添加或删除工具。这主要有两个原因：

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

2. 当之前的操作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。如果没有约束解码，这通常会导致模式冲突或幻觉动作。

为了解决这个问题，同时仍然改进动作选择，Manus 使用上下文感知的状态机来管理工具的可用性。它不是删除工具，而是在解码期间屏蔽 token logits，以防止（或强制）基于当前上下文选择某些动作。

在实践中，大多数模型提供商和推理框架都支持某种形式的响应预填充，这允许您在不修改工具定义的情况下约束动作空间。通常有三种函数调用模式（我们将使用 NousResearch 的 Hermes 格式作为示例）：

自动 – 模型可以选择是否调用函数。通过仅预填充回复前缀来实现：< im_start >assistant

必需 – 模型必须调用一个函数，但选择不受约束。通过预填充到工具调用令牌来实现：< im_start >assistant

指定 – 模型必须从特定子集中调用一个函数。通过预填充到函数名称的开头来实现：< im_start >assistant{"name": “browser_

通过这种方式，我们通过直接屏蔽令牌 logits 来约束动作选择。例如，当用户提供新的输入时，Manus 必须立即回复，而不是采取行动。我们还特意设计了具有一致前缀的动作名称 —— 例如，所有与浏览器相关的工具都以 browser_ 开头，而命令行工具以 shell_ 开头。这使我们能够轻松地强制 Agent 仅从给定状态下的特定工具组中进行选择，而无需使用有状态的 logits 处理器。

这些设计有助于确保 Manus Agent 循环保持稳定 —— 即使在模型驱动的架构下也是如此。

将文件系统用作上下文

现代前沿 LLMs 现在提供 128K 令牌或更多的上下文窗口。但在实际的 Agent 场景中，这通常是不够的，有时甚至是一种负担。有三个常见的痛点：

1.观察结果可能非常庞大，尤其是在智能体与非结构化数据（如网页或 PDF）交互时。很容易超出上下文限制。

2.即使窗口在技术上支持，模型性能也往往会随着上下文长度的增加而下降。

3.即使使用前缀缓存，长输入也很昂贵。您仍然需要付费传输和预填充每个令牌。

为了解决这个问题，许多智能体系统都实现了上下文截断或压缩策略。但过度激进的压缩不可避免地会导致信息丢失。问题是根本性的：智能体本质上必须根据所有先前的状态来预测下一个动作 —— 而且您无法可靠地预测哪个观察结果可能在十步之后变得至关重要。从逻辑角度来看，任何不可逆的压缩都带有风险。

这就是为什么我们将文件系统视为 Manus 中的终极上下文：大小不受限制，本质上是持久的，并且可以直接由 Agent 操作。模型学习按需写入和读取文件 —— 不仅将文件系统用作存储，还用作结构化的外部化内存。

我们的压缩策略始终被设计为可恢复的。例如，只要保留 URL，网页的内容就可以从上下文中删除；如果文档的路径在沙箱中仍然可用，则可以省略文档的内容。这使得 Manus 能够在不永久丢失信息的情况下缩短上下文长度。

在开发此功能时，我发现自己想象着状态空间模型（SSM）如何在 Agent 环境中有效工作。与 Transformer 不同，SSM 缺乏完全的注意力，并且难以处理长期的向后依赖关系。但是，如果他们能够掌握基于文件的内存 —— 将长期状态外部化而不是将其保存在上下文中 —— 那么它们的速度和效率可能会开启一类新的 Agent。Agent SSM 可能是神经图灵机的真正继承者。

通过背诵来操纵注意力

如果你使用过 Manus，你可能已经注意到一些奇怪的现象：在处理复杂的任务时，它倾向于创建一个todo.md文件，并在任务进行过程中逐步更新它，勾选已完成的项目。

这不仅仅是可爱的行为，而是一种有意的操纵注意力的机制。

Manus 中的一个典型任务平均需要大约 50 个工具调用。这是一个很长的循环 —— 而且由于 Manus 依赖 LLMs 进行决策，因此它很容易偏离主题或忘记早期的目标，尤其是在长上下文或复杂的任务中。

通过不断重写待办事项列表，Manus 会将它的目标复述到上下文的末尾。这会将全局计划推送到模型的近期注意力范围内，避免“迷失在中间”的问题，并减少目标错位。实际上，它是在使用自然语言来使其自身的注意力偏向于任务目标 —— 而无需特殊的架构更改。

保留错误信息

智能体会犯错。这不是漏洞，而是现实。语言模型会产生幻觉，环境会返回错误，外部工具会运行异常，意想不到的极端情况也总是会出现。在多步骤任务中，失败不是例外，而是循环的一部分。

然而，一种常见的冲动是隐藏这些错误：清理痕迹，重试操作，或者重置模型的状态，并将其交给神奇的“温度”。这感觉更安全，更可控。但这是有代价的：消除失败会移除证据。没有证据，模型就无法适应。

根据我们的经验，改进智能体行为最有效的方法之一出奇地简单：将错误的转弯留在上下文中。当模型看到失败的操作 —— 以及由此产生的观察或堆栈跟踪 —— 它会隐式地更新其内部信念。这会使其先验概率偏离类似的操作，从而减少重复相同错误的可能性。事实上，我们认为错误恢复是真正智能体行为最清晰的指标之一。然而，它在大多数学术工作和公共基准测试中仍然代表性不足，这些工作和测试通常侧重于理想条件下的任务成功。

别被速杀了

少样本提示是提高 LLM 输出的常用技术。但在 Agent 系统中，它可能会以微妙的方式适得其反。

语言模型是优秀的模仿者；它们模仿上下文中行为的模式。如果你的上下文充满了相似的过去行动-观察对，模型就会倾向于遵循该模式，即使它不再是最优的。

这在涉及重复决策或行动的任务中可能很危险。例如，当使用 Manus 帮助审查一批 20 份简历时，Agent 通常会陷入一种节奏 —— 重复类似的操作，仅仅是因为它在上下文中看到了这些操作。这会导致漂移、过度概括，有时甚至会出现幻觉。

解决方法是增加多样性。Manus 在行动和观察中引入少量结构化的变化 —— 不同的序列化模板、不同的措辞、顺序或格式上的细微噪声。这种受控的随机性有助于打破模式并调整模型的注意力。换句话说，不要用少量样本把自己逼入困境。你的上下文越统一，你的 Agent 就越脆弱。

结论

上下文工程仍然是一门新兴的科学 —— 但对于 Agent 系统来说，它已经至关重要。模型可能变得更强大、更快、更便宜，但再多的原始能力也无法取代对记忆、环境和反馈的需求。你如何塑造上下文最终决定了你的 Agent 的行为方式：它运行的速度、它恢复的程度以及它的扩展程度。

在 Manus，我们通过反复的重写、死胡同以及数百万用户的真实世界测试中吸取了这些教训。我们在这里分享的都不是普遍真理 —— 但这些是对我们有效的模式。如果它们能帮助你避免哪怕一次痛苦的迭代，那么这篇文章就完成了它的使命。

能动的未来将通过一个个场景构建。好好设计它们。

本文源自：IT之家

作者：清源