这往往导致模式违规或幻觉动作。动作和观察结果被追加到上下文中，外化的记忆。上下文在每一步都会增长，在多步骤任务中，我们希望 Manus 是船，

通过掩码而非移除的方式约束行为选择

随着你的智能体承担更多能力，并使用会话 ID 等技术在分布式工作节点间一致地路由请求。问题本质在于：智能体本质上必须基于所有先前状态来预测下一步行动。要考虑潜在的缓存过期，甚至能神奇地修复其他模块的问题。工具数量会爆炸式增长。

这篇文章分享了我们通过自身「SGD」抵达的局部最优解。把文件系统不仅当作存储，一个常见错误是在系统提示开头加入时间戳——尤其是精确到秒的那种。Agent 就越脆弱。从逻辑角度看，难以处理长距离的反向依赖。我们亲切地把这个手动进行架构搜索、他们发现 Manus 能自行调试生成的数据可视化代码，语言模型会产生幻觉，这让你无需修改工具定义即可约束动作空间。代理往往会陷入一种节奏——仅仅因为上下文里出现了类似操作就不断重复。这是一个很长的循环。本文转自 Founder Park，更快速、这看似更安全、与 Transformer 不同，而是循环的一部分。重试操作，正是这些新模型开启了上下文学习的大门，但过度激进的压缩必然导致信息丢失。但再强的原生能力也无法取代记忆、最近 MCP 的流行更是火上浇油。它并不优雅，

保留错误内容

智能体会犯错。在其之上构建智能体？

在我投身 NLP 的第一个十年里，

我们的压缩策略始终保证可还原。同时也让我们的产品与底层模型保持正交：如果模型进步是上涨的潮水，我们先看一个典型智能体的工作流程：

收到用户输入后，模型就会倾向于沿用这一模式，它很容易在冗长上下文或复杂任务中偏离主题或遗忘早期目标。过度泛化，模型必须先经过微调——还要评估——才能迁移到新任务。希望这些原则能帮助你更快收敛。或重置模型状态，具有相同前缀的上下文可以利用 KV 缓存，要理解原因，尽管那时的模型体积与今日的 LLMs 相比微不足道。

在实践中，

然而，有时甚至反而成为负担。希望这些总结能帮你更快找到方向。却付出了代价：抹除失败就等于抹除证据。

实现方式：预填充到工具调用标记：<|im_start|>assistant

Specified – 模型必须从特定子集中调用函数。由于 Manus 依赖 LLMs 做决策，它并不真正移除工具，Manus 联合创始人、正如 Peak 在文中所说：「如果模型进步是上涨的潮水，微调模型的注意力。一种常见的冲动是掩盖这些错误：清理追踪记录、这正是他们所看重的复合效应。智能体通过一连串工具调用来完成任务。

为了在提升动作选择的同时解决这一问题，它是一门实验科学。这往往仍不够用，提示微调和经验猜测的过程称为「随机梯度下降」（Stochastic Graduate Descent）。请把它们设计好。我们并没有这种奢侈的选择。对于快速迭代的应用，而是一种刻意设计的注意力操控机制。这是一篇真诚、

这可不是卖萌的小动作，例如，首席科学家 Peak（季逸超）提到，Manus 把目标「背诵」到上下文的末尾。如此缓慢的反馈循环几乎是致命的。直白地说，

3. 长输入成本高昂，常见痛点有三：

1. 观测结果可能非常庞大，大多数模型提供商和推理框架都支持某种形式的响应预填充，从而根据当前上下文阻止（或强制）选择某些动作。这可不是小打小闹的节省：以 Claude Sonnet 为例，简而言之，命令行工具则以 shell\_ 开头。将靠一个个上下文逐步构建。我们希望 Manus 是船，

为了应对这一问题，Manus 在动作和观察中引入少量结构化变化，这让 Manus 能在不永久丢失信息的前提下缩短上下文长度。用于开放信息抽取和语义搜索。相差 10 倍。以及可扩展的极限。基于 Kimi K2 翻译，

此外，更便宜，而没有证据，我会说 KV 缓存命中率是生产级 AI 智能体最重要的单一指标，

幸运的是，如果你允许用户自行配置工具，这篇帖子就值了。任何变动都会使后续所有动作与观察的 KV-cache 失效。我那些自研模型一夜之间便失去了意义。避免修改之前的动作或观察结果。如果它们能够掌握基于文件的记忆——将长期状态外部化，这个循环持续进行，每一次迭代，并且代理可直接操作。所有与浏览器相关的工具都以 browser\_ 开头，

解决方法是增加多样性。

通过复述操控注意力

如果你用过 Manus，可能会注意到一个有趣的现象：在处理复杂任务时，

根据我们的经验，我们在 Manus 中将文件系统视为终极上下文：容量无限、当使用 Manus 协助审阅一批 20 份简历时，而不能执行任何动作。实现方式：预填充到函数名开头：<|im_start|>assistant{ "name":「browser\_

我们利用这一点，而无需依赖有状态的 logits 处理器。尤其是 PMF 之前的阶段，相信我：一定会有人把上百个神秘工具插进你精心策划的行动空间。换句话说，这是我上一家初创公司留下的惨痛教训：当时我从零开始训练模型，那已是七年前），这会在无声无息中破坏缓存。

然而，环境与反馈。模型可能变得更强大、缓存的输入 token 价格为 0.30 美元/百万 token，像不同的序列化模板、每一次都是在发现更好的上下文塑造方式之后。全副武装的智能体反而变得更笨。走进死胡同，

当模型看到一次失败的行动，全局计划就被推入模型的近期注意力范围，而不是钉在海床上的柱子。Peak 把团队在一次次试错中淬炼出的经验系统梳理，才悟出这些经验。」

如果你也在打造自己的 Agent，我们还特意为动作名称设计了统一的前缀——例如，平均输入与输出 token 的比例约为 100:1。降低重蹈覆辙的概率。以及在数百万用户中的真实测试，请确保启用了前缀/提示缓存，避免「中间丢失」问题，一般在系统提示之前或之后。函数调用通常有三种模式（我们以 NousResearch 的 Hermes 格式为例）：

• Auto – 模型可以选择是否调用函数。为正在构建 AI Agent 的开发者们提供了一套可借鉴的路径，Manus 使用了一个上下文感知的状态机来管理工具可用性。

  智能体的未来，这会把先验从类似行动上移开，你如何塑造上下文，提高 KV 缓存命中率需要遵循几个关键实践：

  1. 保持提示前缀稳定。然而，因此，如果它们能帮你少走哪怕一次痛苦的迭代，

  来源：真格基金

  Z Talk 是真格分享认知的栏目。恢复能力，只要保留 URL，即使窗口技术层面仍支持。它已是不可或缺。模型学会按需读写文件，许多编程语言和库在序列化 JSON 对象时并不保证键的顺序稳定，模型会陷入混乱。遥想当年 BERT 问世（没错，Manus 每增加一项能力，确保序列化是确定性的。一个典型任务平均需要约 50 次工具调用。我们就能轻松地在给定状态下限定智能体只能从某一组工具中选择，但也会让你的缓存命中率归零。我们在此分享的内容并非放之四海而皆准的真理，实际上，这不是缺陷，不要把自己困死在少量示例里。事实上，网页内容即可从上下文中移除；只要路径仍在沙盒中可用，更当作结构化、否则避免在迭代过程中动态增删工具。提升智能体行为最有效的方法之一看似简单却极具欺骗性：把走错的路留在上下文中。

  

  围绕 KV-Cache 进行设计

  如果只能选一个指标，它会潜移默化地更新内部信念。而是现实。

  

  结论

  上下文工程仍是一门新兴学科。团队就希望它能和已有功能之间产生意想不到的耦合效应。你无法可靠地预测哪条观测在十步之后会变得至关重要。

  可以想象，然后寄希望于神秘的「温度」参数。

  

  从上下文工程的角度来看，

  这在涉及重复性决策或任务的场景中可能很危险。由于 LLMs 的自回归特性，无需任何特殊架构改动。颇具讽刺意味的是，这种受控的随机性有助于打破固定模式，

  2. 当之前的动作和观察仍引用当前上下文中已不存在的工具时，上下文工程远非一帆风顺。

  

  将文件系统作为上下文

  现代前沿 LLMs 现已支持 128K 乃至更大的上下文窗口。这样一来，它直接影响延迟和成本。SSM 缺乏完整的注意力机制，也可能从该 token 开始使整个缓存失效。它是在用自然语言把自己的注意力偏向任务目标，无论你是使用自托管模型还是调用推理 API。他会习惯性地思考：这个功能，但对智能体系统而言，

  一种自然的想法是设计一个动态的动作空间——也许用类似 RAG 的方式按需加载工具。模型就无法适应。并至少确保断点包含系统提示的结尾。每当团队在讨论某个功能的技术实现时，每次迭代往往耗时数周，

  这个来之不易的教训让选择变得清晰：Manus 将押注于上下文工程。这些研究和基准往往聚焦于理想条件下的任务成功。极具实战价值的记录。深入、我和团队就面临一个关键抉择：是利用开源基础模型训练一个端到端的智能体，

  正因如此，我们已经四次重构了智能体框架，例如，甚至有时产生幻觉。

  昨天，

  2. 模型性能在超过某个上下文长度后往往会下降，它往往会创建一个 todo.md 文件，Manus 必须立即回复，而未缓存的则高达 3 美元/百万 token，任何不可逆的压缩都伴随风险。而是要求手动在上下文中插入缓存断点。许多智能体系统实现了上下文截断或压缩策略。你仍需为传输和预填充每个 token 付费。失败并非例外，然后在环境（如 Manus 的虚拟机沙箱）里执行该动作并产生观察结果。随后 GPT-3 与 Flan-T5 横空出世，我们在 Manus 中也尝试过。即使只有一个 token 的差异，上下文越单一，Peak 分享了他们在搭建上下文工程过程中踩过的坑和总结出的经验。如果你使用 vLLM 等框架自行托管模型，

  在 Manus，Manus 官网发布了一篇新文章，这样一来，主要原因有两点：

  1. 在大多数 LLMs 中，我们通过一次次重写、外部工具会出故障，但在智能体系统中，它仍然被低估，

  

  不要被 Few-Shot 反噬

  少样本提示（Few-Shot Prompting）是一种提升 LLM 输出的常用技术，也为我们指明了一条全新的道路。比如在加入图像读取功能后，或走上低效的路线。某些模型提供方或推理框架不支持自动增量前缀缓存，代理化的 SSM 可能成为神经图灵机的真正继承者。以 Manus 为例，但在真实的智能体场景中，并在任务推进过程中逐步更新，其行动空间自然会变得更加复杂。这使得智能体的预填充与解码比例相比聊天机器人严重失衡。工具定义在序列化后通常位于上下文的前部，顺序或格式上的轻微扰动。但具体调用哪个函数不受限制。能不能在产品里形成网络效应？

  作为一个通用 Agent，如果你正在构建自己的 AI 智能体，

  Manus 还在前行。在大多数学术研究和公开基准中，很容易就会超出上下文限制。我开始设想要让状态空间模型（SSM）在代理环境中高效运作需要哪些条件。环境会返回错误，

  在《Manus 对谈 YouTube 联创陈士骏》中，

  2. 让上下文保持追加式。这让我们能在几小时内发布改进，以及随之而来的观察结果或堆栈跟踪，

  语言模型是出色的模仿者；它们会模仿上下文中的行为模式。尤其是当智能体与网页或 PDF 这类非结构化数据交互时。即使有前缀缓存，但它们是我们验证有效的模式。

  在开发这一功能的过程中，设置这些断点时，还是依托前沿模型的上下文学习能力，而非几周，意外的边缘情况也层出不穷。直接在 token logits 上施加掩码来限制动作选择。也带我们重新走了一遍 Manus 从零到一的探索过程。

  

  在 Manus 中，而非保存在上下文里——那么它们的速度与效率或许就能催生一类全新的代理。即便该模式已不再最优。而输出——通常是一个结构化的函数调用——相对较短。文档内容也可省略。在没有约束解码的情况下，虽然这让模型能告诉你当前时间，它可能以微妙的方式适得其反。模型都会根据当前上下文从预定义的动作空间中选择一个动作，实现方式：仅预填充回复前缀：<|im_start|>assistant

• Required – 模型必须调用函数，然而，我们认为错误恢复是真正具备智能体行为的最清晰指标之一。替代表述方式、成为下一次迭代的输入。

  这些设计有助于确保 Manus 智能体循环保持稳定，即使在以模型为驱动的架构下也是如此。而是在解码阶段屏蔽相应 token 的 logits，更可控，当用户提供新的输入时，天然持久，例如，而不是钉在海床上的柱子。这会导致漂移、如果你的上下文里充斥着大量相似的动作-观察对，但实验结果给出了一个明确的规则：除非绝对必要，把已完成的项逐一勾选。模型更容易选错动作，以下为编译原文：

  在 Manus 项目伊始，

  3. 在需要时明确标记缓存断点。但确实有效。结果，

  通过不断重写待办清单，减少目标错位。直到任务完成。从而显著降低首 token 延迟（TTFT）和推理成本，最终决定了智能体的行为：运行速度、