Manus AI撤出中国：上下文工程重塑AI Agent的未来

在风靡市场仅仅四个月后，Manus AI 突然全面撤出中国市场，不仅清空了所有社交账号内容，而且国行版本的 Manus 也似乎暂停了推进。

早在上个月，Manus 联合创始人张涛便宣布公司已将全球总部迁至新加坡，并在东京和加州设有办公室。尽管官方未正面回应，只称是「基于经营效率的调整」，但出海引发的裁员等一系列争议问题，也让外界普遍猜测其是否正在「跑路」。

在风波之中，今天凌晨，Manus 联合创始人季逸超发布了一篇技术博客，试图将外界关注点重新拉回产品技术本身。

经过四次重构和数百万真实交互，他在文中坦诚地总结了团队在构建 Manus 过程中积累的经验教训。内容既有实操干货，也不乏反思，对业内同行与普通用户来说，都不失为一份值得一读的参考材料。

技术博客地址：https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

省流版：

1. 押注上下文，不再训练模型 与其耗时训练，不如围绕大模型构造「记忆」和流程。上下文工程让你在几小时而不是几周内发布产品更新。

2. KV-Cache 命中率至关重要 输入越稳定，缓存命中率越高，成本和延迟越低。三条实战建议： - 避免提示中使用时间戳； - 只追加上下文，避免修改历史记录； - 手动标记缓存断点，保障前缀一致性。

3. 工具不要动态添加，而是用「遮蔽」法控制选择 动态修改工具列表会让缓存失效、模型混乱。Manus 使用「遮蔽 token logits」的方法，让模型「看不见」不应调用的工具。

4. 用文件系统承载持久上下文 大模型上下文再长也会被打满。Manus 让模型把长期记忆写入虚拟文件系统，按需读写，实现「外部记忆」，规避信息丢失。

5. 重写 ToDo 清单，是操控注意力的重要方法 模型容易「中途忘记目标」。Manus 会不断用自然语言更新并重述 todo.md 文件，把全局目标拉回注意力焦点，防止任务跑偏。

6. 错误不是要掩盖，而是要保留 失败是构建 Agent 过程中的一部分。保留错误日志（如失败的操作、堆栈信息），能帮助模型更新内部信念，减少重复错误。

7. 少样本提示不是灵丹妙药，要防「同质化陷阱」 模型会盲目模仿上下文中的行为模式。Manus 通过引入结构化变化（如不同措辞或顺序），避免模型在长任务中陷入复制粘贴式幻觉。

AI Agent 的上下文工程：从构建 Manus 中学到的经验

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

在我从事 NLP 的第一个十年，我们没有这种选择的奢侈。在遥远的 BERT 时代（是的，已经过去七年了），模型必须先进行微调——并评估——才能转移到新任务。这个过程通常每次迭代需要数周时间，即使与今天的 LLM 相比，这些模型都很小。对于快速发展的应用，特别是在产品市场契合度（PMF）之前，这种缓慢的反馈循环是一个致命问题。

这是我上一个创业公司的惨痛教训，我从头开始为开放信息提取和语义搜索训练模型。然后 GPT-3 和 Flan-T5 出现了，我的内部模型一夜之间变得无关紧要。讽刺的是，这些相同的模型标志着上下文学习的开始——以及一条全新的前进道路。

这个来之不易的教训使选择变得明确：Manus 将押注于上下文工程。这使我们能够在几小时内而非几周内推出改进，并使我们的产品与底层模型保持正交：如果模型进步是上涨的潮水，我们希望 Manus 成为那条船，而不是固定在海床上的柱子。

然而，上下文工程证明并非那么直截了当。它是一门实验科学——我们已经重建了我们的 Agent 框架四次，每次都是在发现了更好的塑造上下文的方式之后。我们亲切地将这种手动架构搜索、提示调整和经验猜测的过程称为「随机研究生下降法」。它不够优雅，但很有效。

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

围绕 KV-Cache 进行设计

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

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

正如你可以想像，上下文随著每一步而增长，而输出——通常是结构化的函数调用——保持相对简短。这使得Agent 程序中的预填充和解码比例与聊天机器人相比高度倾斜。例如，在 Manus 中，平均输入与输出 token 比率约为 100:1。

幸运的是，具有相同前缀的上下文可以利用 KV-cache，这大大减少了首个 token 的时间 (TTFT) 和推理成本——无论你使用的是自托管模型还是调用推理 API。我们谈论的不是小额节省：以 Claude Sonnet 为例，缓存的输入 token 成本为 0.30 美元/MTok(每百万 token)，而未缓存的成本为 3 美元/MTok——相差 10 倍。

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

5. 保持提示前缀稳定。由于 LLM 的自回归特性，即使单个标记的差异也会使该标记之后的缓存失效。一个常见的错误是在系统提示的开头包含时间戳——尤其是精确到秒的时间戳。没错，它可以让模型告诉你当前时间，但它也会降低你的缓存命中率。

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

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

遮蔽，而非移除

...