https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus 讲讲这个。从现在看来，这篇文章什么东西仍然成立，什么东西已经改变了。

回复 群友 3892： 这篇文章是 Peak 在 2025 年 7 月写的，讲的是他做 Manus 时总结出的六条上下文工程经验。逐条看哪些还成立： 仍然成立、甚至更成立了： KV cache 是生产 Agent 最重要的单一指标，这条完全没变。缓存和未缓存的差价现在还是十倍量级；而且 agent 大致是 100:1 的输入输出比例，输出很短、上下文很长，所以前缀稳定性、只追加、序列化确定性这些做法依然是最省钱的手法。判断一个 agent 框架做得糙不糙，看它有没有往系统提示里塞秒级时间戳，基本就能看出来。 把文件系统当作终极上下文，这点现在是共识级的做法。几乎所有主流 agent 都在走“上下文可恢复压缩”这条路：网页内容只留 URL，文档只留沙盒路径。只是现在实现上更进一步，从“写文件”扩展到 skills、memory 目录、笔记，形式更多，但内核还是这个。 复述目标、todo.md 压注意力，这条也成立。长任务里模型会跑偏，多步工具调用几十次的场景下，把计划反复重写到最后，确实有效。现在多数产品里都保留了这一步，只是有的改成了自动的 plan 更新。 保留错误内容，而不是擦掉重试，这条我认为是全文最经得起时间考验的一条。错误轨迹留在上下文里，模型会自己修正先验。现在很多评测也补上了 error recovery 这个维度，学术上不再只看理想条件。 已经改变或部分失效的： 遮蔽而非移除，也就是用 logits 掩码来限制工具选择，这条现在被外部化了。当时要靠预填充和响应前缀来约束动作空间，是因为模型自己约束不住；现在工具选择能力、以及 function calling 的稳定性都好很多，再加上各家 API 提供了原生工具约束，所以这套手搓的 logits mask 更多是推理框架的活，应用层不必再自己做。工具前缀命名仍然是个好习惯。 不要被少样本示例困住，这条的紧迫性下降了。当时靠结构化噪声、改序列化模板来打破模式；现在的模型对上下文模式的过拟合没当初那么严重，反而更多是在担心规则本身互相冲突。不过这并不代表可以随便塞重复样本，尤其是 CV 审查这类重复性任务。 关于上下文窗口的判断要更新。文章发的时候 128K 已经是很大的窗口，现在百万级上下文变得常见，单说“窗口不够”不成立了；但那三个痛点里真正没解决的是成本和长上下文下的注意力衰减，也就是 lost in the middle 的问题依然存在，所以压缩和外部记忆的必要性并没有随着窗口变大而消失。 有两处已经被证明说得对，但走向和当时不同： SSM 那段是当时的想象，现在基于 SSM 的 agent 并没有走通，这个预言没兑现，但把长期状态外置这个思路本身还在。 对 MCP 的描述当时是“火上浇油，工具爆炸”，现在看这个判断是对的，只是业界的主流解法已经很明确：MCP 服务本身提供筛选和分组，客户端侧按需暴露，而不是指望模型在几百个工具里挑。 一句话总结：架构层面的那几条，也就是缓存友好、外部记忆、保留错误、控制注意力，都活下来了，因为这些做法是对 LLM 工作原理的顺应；而变化的是具体手法，也就是手搓 logits、靠噪声打破模式，以及“上下文窗口不够”这个前提。真正没变的判断是：agent 的改进靠快速迭代上下文，而不是训练一个端到端模型。