7月19日，IT之家披露了AI智能体平台Manus传出裁员以及在国内多个平台账号被清空的消息。今日凌晨，Manus的联合创始人季逸超在官方博客上发表了一篇长达上千字的技术分析文章，回顾了公司自年初走红以来所经历的种种起伏，以及开发过程中的种种思路与经验教训。
今年三月，Monica 团队在国内研发的 Manus 在海外社交平台上正式亮相。这款产品被誉为全球首款通用智能体（Agent），具备独立处理复杂任务的能力。在通用 AI 助手基准测试 GAIA 的所有难度级别中，Manus 的评分甚至超过了 OpenAI 的 DeepResearch。Manus发布的演示视频中所呈现的惊人效果，立刻激起了用户的极大兴趣。然而，Manus的体验仅限于受邀用户。因此，渴望尽早体验Manus功能的用户，纷纷在国内外各大社区平台上留言，希望能获得邀请码。这一现象也使得Manus迅速走红，成为社交平台上的热门话题。
IT之家附博客文章大意如下：
在Manus项目的初期阶段，我和我的团队遇到了一个至关重要的抉择：我们是要依托开源的底层技术来培育一个全流程的自主模型，还是基于先进模型的上下文学习能力来打造一个智能体？
在我投身于自然语言处理领域的最初十年里，我们并无此等选择空间。那时，遥远的 BERT 时代（是的，已经过去了七年），模型必须经过细致的调整与评估，方可被应用于新的任务。即便与如今的 LLMs 相较，当时的模型规模较小，但这一过程往往需要数周时间才能完成每一次迭代。快速发展的应用，尤其是在进入PMF阶段之前，这种反馈循环的缓慢程度是无法容忍的。这成为了我上一次创业过程中的一段深刻教训。当时，我需要从头开始训练模型，目的是为了实现开放信息提取和语义搜索。然而，随后GPT-3和Flan-T5的问世，使得我之前所训练的内部模型在一夜之间变得不再重要。颇具讽刺意味的是，这些模型不仅标志着语境学习的起点，同时也开辟了一条全新的发展路径。
那次艰辛获得的经验使我们深刻认识到决策的重要性：Manus 将把赌注下在上下文工程上。这一决策让我们得以在短短数小时内完成优化，而非漫长的数周，同时也确保了我们的产品与基础模型保持独立：若模型的进步如同涨潮，我们期望Manus成为一艘航船，而非陷入海底的支柱。
尽管如此，上下文工程的结果并非轻易可得。这实际上是一门实验性的科学——我们已成功重构了四次Agent框架，每一次都是在找到优化上下文构建方法的基础上。我们习惯性地将这种涉及架构搜索、提示调整以及经验推断的繁琐过程称作“随机梯度下降”。虽然过程并不流畅，但它的效果却是显著的。
本文向我们展示了我们运用自家的“SGD”算法所取得的局部最优解。若您正着手打造个人的人工智能代理，我衷心希望这些核心理念能够助力您加速实现收敛。
围绕 KV 缓存进行设计
若需挑选一项关键指标，我坚信KV缓存命中率在生产环节中对AI Agent而言至关重要。此指标对系统延迟与运营成本有着直接的影响。为了阐明其重要性，不妨观察一下一个典型的AI Agent运作机制：
在接收到用户输入信息后，Agent将运用一系列工具来执行任务。在每一次迭代过程中，模型会依据当前的上下文信息，从预设的动作集合中挑选一个动作。接着，这个动作将在特定的环境（比如Manus的虚拟机沙箱）中实施，从而产生相应的观察结果。随后，这个动作及其观察结果会被添加到上下文中，成为下一次迭代的输入依据。这一过程会持续进行，直至任务最终完成。
正如你所预期的那样，随着每一步的推进，上下文信息量逐渐增加，而输出部分——通常表现为一个结构化的函数调用——相对而言较为简短。这种情况下，Agent 中的预填充和解码环节在整体处理过程中占据了更大的比例。以 Manus 为例，其平均输入与输出的 token 比率大约为 100 比 1。
庆幸的是，对于拥有相同前缀的文本内容，我们可以借助 KV 缓存功能，这显著缩短了生成首个令牌所需的时间（TTFT）以及推理所需的成本——无论是自行托管模型，还是通过调用推理 API 进行操作。我们谈论的并非微小的节约：以 Claude Sonnet 为例，缓存后的输入令牌费用仅为 0.30 美元每百万令牌，相较之下，未缓存的令牌费用高达 3 美元每百万令牌——两者之间相差竟达十倍之多。
从工程实践的角度审视，提升 KV 缓存的成功访问率，主要依赖于以下几项核心策略：
确保提示的前缀保持一致。鉴于 LLMs 具备自回归的特性，即便是单个字符的变动也可能导致从该字符起始的缓存失效。一个常犯的错误是在系统提示的开头加入了时间戳——特别是精确到秒的时间戳。虽然这能让模型告知你当前的具体时间，但它也会显著降低你的缓存命中率。
确保你的文本内容仅进行追加，不得对先前的操作或观察进行任何改动。务必保证序列化的过程是确定的。众多编程语言及其库在序列化 JSON 对象时，并不保证键的顺序保持一致，这种情况可能在不经意间损害缓存功能。
在必要时，需明确标注缓存中断点。有些模型供应商或推理框架不支持自动增加前缀的缓存功能，因此需要手动在相关上下文中加入缓存中断点。在分配这些中断点时，要考虑到缓存可能过期的风险，并且至少要保证中断点包含系统提示的结尾部分。
此外，若您自行托管基于vLLM等框架的模型，务必保证已激活前缀/提示缓存功能，同时采用会话ID等技术手段，以确保在分布式工作器间对请求进行一致的路由处理。
屏蔽，不要移除
随着您的智能代理不断获得更多功能，其操作范围无疑将变得更加繁复——用通俗的话说，可用的工具种类将呈指数级增加。近期MCP的普及更是加剧了这一趋势。假如您允许用户自行配置工具，那么请相信我的话：在您精心设计的操作领域内，难免会有用户擅自添加数百种难以捉摸的工具。这导致模型更倾向于选择错误的行动方案，或者走上效率低下的路径。简而言之，您全副武装的 Agent 变得更笨了。
设计一个动态的动作区域似乎是一个自然而然的选择——或许可以借鉴RAG的方法，根据需求动态引入工具。在Manus项目中，我们也进行了此类尝试。然而，我们的实验结果揭示了一条明确的准则：除非万不得已，否则在迭代过程中应尽量避免对工具进行动态的增减。这主要基于两个方面的考虑：
在多数大型语言模型中，工具的设定通常在序列化处理之后置于上下文的前端，这通常发生在系统提示的前方或后方。因此，一旦进行任何调整，都会导致所有后续的操作和观察所依赖的键值对缓存失效。
若模型在执行先前步骤和观察时，仍依赖那些在当前语境中未明确定义的工具，它可能会感到迷茫。若缺乏解码约束，这种情况往往会导致模式间的冲突，或者产生错误的动作感知。
为解决这一问题并进一步优化动作的选取，Manus采纳了上下文感知型的状态机来操控工具的可用状态。其做法并非直接移除工具，而是在解码过程中对token logits进行屏蔽，以此避免（或强制）在当前语境下对特定动作的选择。
在实践应用中，多数模型供应商及推理工具框架普遍采纳了响应预填充的机制，这一机制使得用户能够在不改变工具既定定义的前提下，对动作选择范围进行限制。通常，存在三种不同的函数调用方式（以下以 NousResearch 公司的 Hermes 格式为例进行说明）：
通过此方法，我们采取直接遮挡令牌logits的策略来限制动作的抉择。比如，当用户输入新的信息后，Manus需迅速作出回应，而非执行其他动作。此外，我们特别制定了带有统一前缀的动作名称规则——比如，所有与浏览器相关的工具均以browser_为前缀，而命令行工具则采用shell_作为前缀。这让我们得以简便地确保 Agent 只能从既定状态下的特定工具集中作出挑选，并且无需借助带有状态信息的 logits 处理器。
这些设计旨在保障Manus Agent循环的稳定性——即便是在模型驱动的架构中亦然。
将文件系统用作上下文
现代前沿的LLMs已能支持高达128K令牌的上下文窗口。然而，在实际的Agent应用场景中，这样的窗口大小往往不足以满足需求，有时甚至会成为负担。具体而言，存在三个主要问题：
观察到的数据量可能相当巨大，特别是在智能体与未结构化数据（例如网页或PDF文件）进行交互的情况下。这种情况很容易导致信息超出其原有的上下文范围。
即便技术层面允许，模型的表现往往也会因为上下文长度提升而出现下滑趋势。
即便采用前缀缓存机制，处理较长的输入数据依旧成本高昂，因为您还得为传输和预先填充每一个令牌支付费用。
为了应对这一挑战，众多智能体系统纷纷采纳了上下文截断或压缩的应对策略。然而，这种策略过于激进的话，信息丢失的问题便难以避免。根本性的问题在于，智能体在本质上需要依据所有先前状态来预测后续动作，而预测在十步之后哪个观察结果可能变得至关重要却并非易事。从逻辑上讲，任何不可逆的压缩都伴随着一定的风险。
这就是我们之所以把文件系统看作是Manus中的最高层级环境：其容量没有上限，本质上具有持久性，且能够被Agent直接进行操作。模型通过学习实现了按需的文件读写——它不仅将文件系统作为存储空间，同时也将其作为结构化的外部存储内存使用。
我们的设计原则确保了压缩策略的可恢复性。比如，仅需保留网址，网页内容便可以从相关文本中移除；若文档路径在安全环境中依旧有效，文档内容同样可以被省略。这样的设计让 Manus 在不造成信息永久丢失的前提下，有效缩减了上下文的长度。
在开发这一功能的过程中，我心中浮现出关于状态空间模型（SSM）在Agent环境中如何高效运行的设想。与Transformer相比，SSM并未具备全面的注意力机制，且在处理长期的后向依赖关系方面存在一定的困难。然而，若他们能驾驭基于文件的内存管理——即实现长期状态的外部化而非在上下文中保存——那么其速度与效能有望开启一个全新的Agent时代。Agent SSM或许将成为神经图灵机的正宗传人。
通过背诵来操纵注意力
若你曾体验过Manus，或许你会察觉到一些不寻常的情况：面对繁杂的任务，它往往会有创建一个todo.md文件的倾向，并在任务执行的过程中，持续对文件进行更新，对已完成的任务进行勾选。
这不仅仅是可爱的行为，而是一种有意的操纵注意力的机制。
在Manus中，一个典型的任务平均涉及约50次工具调用。这样的循环过程相当漫长——加之Manus在决策上依赖于LLMs，因此它极有可能在处理过程中偏离主题，或者遗忘初始目标，尤其是在面对长篇上下文或复杂任务时。
通过反复修改待办事项清单，Manus能够将目标不断复述至上下文尾部。这样做将使整体规划进入模型近期关注焦点，有效防止“迷失方向”的问题，同时降低目标偏差的可能性。实际上，它通过自然语言处理，引导自身注意力集中于任务目标，而无需对架构进行特殊调整。
保留错误信息
智能系统在操作过程中难免会犯错误。这并非缺陷，而是客观存在的现实。语言模型可能产生错觉，外部环境可能反馈错误信息，外部工具可能出现运行异常，甚至还会遭遇一些始料未及的极端状况。在进行多步骤任务时，失败并非偶然，而是整个流程中不可或缺的一部分。
人们往往倾向于掩盖这些失误：清除痕迹、再次尝试操作，亦或是将模型状态归零，交由那神秘的“温度”来处理。这样做似乎更为稳妥，易于掌控。然而，这种做法的代价是：抹去失败意味着失去了证据。没有了证据，模型便无法进行适应。
依据我们的实践，优化智能体行为的最有效途径之一竟出人意料地简便：保留错误操作在上下文中的记录。模型在目睹失败的操作——以及随之而来的观察或堆栈追踪——后，会自动调整其内在信念。这一过程会导致其对类似操作的先验概率发生偏移，进而降低重复犯相同错误的风险。实际上，我们坚信，错误恢复能力是衡量智能体行为智能程度的最显著标志之一。尽管如此，它在众多学术研究和公共标准测试中仍显得代表性不够充分，而这些研究和测试往往更关注在理想环境下的任务完成情况。
别被速杀了
在提升大型语言模型输出质量方面，少样本提示法是一种普遍采用的方法。然而，在 Agent 系统的应用中，这种方法可能会以不显眼的方式产生相反的效果。
语言模型擅长于模仿；它们会复制上下文中行为出现的规律。当你的上下文中充斥着大量相似的过往行为与观察的对应关系时，模型便会倾向于继续遵循这一规律，即便这样做可能并非最佳选择。
在处理需要重复做出决策或采取行动的任务时，可能会存在风险。比如，当运用Manus来审核一组20份简历时，Agent往往会陷入一种模式——反复执行相似的操作，仅仅是因为它们在特定情境下感知到了这些动作。这种现象可能引发认知偏差、过度泛化，甚至有时会出现错觉。
应对策略在于丰富多样性。Manus 通过在行为和观察中引入些许结构性的变动——诸如变换序列模板、措辞、顺序或格式的细微差异。这种有控制的随机性能够有效打破常规，并调整模型的关注点。换言之，不应仅凭少量样本就陷入局限。若你的上下文过于单一，你的智能体将显得更为脆弱。
结论
上下文工程虽然仍属于新兴学科领域——但对于 Agent 系统，其重要性已不容忽视。即便模型可能变得更加强大、运行速度更快、成本更低，但任何超乎寻常的原始能力都无法完全替代对记忆、环境以及反馈的依赖。你塑造上下文的方式，将直接决定你的 Agent 的行为模式：它执行任务的效率、它从失败中恢复的能力，以及它所能拓展的边界。
在Manus，我们经过多次修改、陷入困境以及来自数百万真实世界用户的测试，总结出了这些经验。我们在此分享的并非放之四海而皆准的真理——但它们对我们来说却是行之有效的规律。只要这些内容能助你规避哪怕一次痛苦的迭代，这篇文章便已实现了它的价值。
能动的未来将通过一个个场景构建。好好设计它们。
