Manus 昨晚发布了一篇非常好的内容#ai创造营#

总结了他们关于 AI Agent 上下文工程上的经验教训。

除了了解如何做以外 Peak 还清晰的解释了为什么这么做,非常适合作为入门引导文章。

我手动整理一下,强烈推荐看原文:manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

首先需要围绕 KV 缓存进行设计

KV 缓存命中率是生产阶段 AI 代理中最重要的指标,它直接影响延迟和成本。

在 Agent 任务中预填充和解码之间的比例在代理中相比聊天机器人显得极为不平衡。

相同前缀的上下文可以利用 KV-cache,这大大减少了首次生成标记时间(TTFT)和推理成本,比如 Claude Sonnet 可以相差 10 倍。

简单解释一下 KV Caching:

KV Caching(Key-Value 缓存)是指在生成式 Transformer(如 GPT、T5 等模型的解码器部分)中,将每一步生成时计算得到的 Key(K)和 Value(V)矩阵保存下来。这样,在生成下一个 token 时,模型只需要计算新 token 的 Key 和 Value,并与之前缓存的内容一起用于注意力计算,而不必每次都重复计算所有历史 token 的 Key 和 Value。

提高 KV-cache 命中率涉及几个关键做法:

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

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

3️⃣在需要时明确标记缓存断点。一些模型提供商或推理框架不支持自动增量前缀缓存,而是需要在上下文中手动插入缓存断点。设置这些断点时,要考虑潜在的缓存过期问题,至少确保断点包含系统提示的结尾部分。

屏蔽而非移除工具

随着你的 Agent 功能越来越多,他的工具数量激增。最近 MCP 的流行更是火上浇油。模型更可能选择错误的动作或采取低效的路径。简而言之,你的重装代理反而变得更笨了。
 
 
Back to Top