大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



在爆火仅四个月后，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 通过引入结构化变化（如不同措辞或顺序），避免模型在长任务中陷入复制粘贴式幻觉。

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

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

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

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

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

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

如果我必须选择仅一个指标，我认为 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-缓存命中率涉及几个关键实践：

1.

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

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,"type":31,"fromMid":14}); return false;” class=“news_list_item_inner”>