AI Agent 的制胜之道：上下文工程深度解析

👋 大家好，我是十三

最近在 Vibe Coding 的过程中，尝试了很多款 AI IDE，遇到了一个让我很疑惑的问题：为什么同样是 Claude 4，在 Claude Cli 或者 Cursor 中使用要比在 Trae 中使用的体验要好？比如更准确的理解上下文、生成的代码更符合业务逻辑、修复问题的速度更快，这背后究竟是为什么？

最开始我想过是不是模型差异——各个厂商对模型就行了微调。但最近 Manus 团队出了一篇博客《Context Engineering for AI Agents》，让我有了一些理解：AI Agent 的时代已经从“模型为王”悄然转向了“上下文为王”。

这篇文章，就是我对这篇博客的读书笔记和思考沉淀。

一、两种路径的抉择：微调 vs. 上下文工程

微调（Fine-tuning） 就像是为 AI 量身定制一套昂贵的西装。

• 优势：理论上可以达到更高的性能上限，让模型更理解我们的特定任务。

• 劣势：成本高昂、开发周期漫长（几周甚至更久）、迭代缓慢。更致命的是，当辛苦微调的模型刚刚上线，基础模型可能已经更新换代，让之前一切的努力付诸东流。Manus 团队在上一家创业公司就踩了这样的坑。

上下文工程（Context Engineering） 则更像是为 AI 提供一套功能强大的模块化装备，即用即取。

• 优势：迭代速度极快（以小时为单位，而非周）、成本低廉、与基础模型解耦、灵活性极高。

• 劣势：应用的性能天花板受限于基础模型本身，对提示词（Prompt）设计、工作流编排等能力要求更高。

Manus 团队的选择非常明确：押注上下文工程。这让他们能以小时级的速度发布改进，使他们的产品“正交于”底层模型的发展。用他们的话说：“如果模型进步是上涨的潮汐，我们希望 Manus 是船，而不是被固定在海床上的柱子。”

对于绝大多数追求快速迭代和市场验证的 AI 应用来说，当下上下文工程无疑是最具性价比和敏捷性的路径。

二、上下文工程的六大黄金原则

以下是 Manus 团队通过四次重构 Agent 框架、无数次实验总结出的六大上下文工程原则：

原则一：像守护生命线一样守护 KV-Cache

如果只能选一个指标，KV-Cache 命中率 将是衡量生产级 AI Agent 性能（延迟和成本）最重要的指标。

• 什么是 KV-Cache？ 简单来说，当语言模型处理一个序列时，它会为每个 Token 计算并存储 Key 和 Value（即 KV-Cache）。当处理后续 Token 时，它可以直接复用之前算好的缓存，而无需重复计算。这极大地加快了生成速度（降低 TTFT，即首个 Token 生成时间），并节省了成本。

• 为什么对 Agent 至关重要？ Agent 的典型工作模式是“长输入，短输出”。上下文（包含历史记录、工具定义等）越来越长，而模型的输出（通常是一个函数调用）却很短。Manus 提到他们的平均输入输出 Token 比例高达 100:1。在这种情况下，KV-Cache 的复用变得至关重要。以 Claude Sonnet 为例，缓存命中的 Token 成本仅为未命中的十分之一！

实战技巧：

1. 保持 Prompt 前缀稳定：任何一个 Token 的改变都会让后续的缓存全部失效。一个常见的错误是在 System Prompt 里包含精确到秒的时间戳，这会是缓存的“致命杀手”。

2. 上下文只增不减：避免修改历史记录，并确保你的序列化逻辑是确定性的（例如，JSON 对象的 key 顺序要固定）。

原则二：屏蔽而非移除——优雅地管理动态工具集

随着 Agent 能力增强，工具（Tools）数量会爆炸式增长。一个常见的误区是根据任务动态地在上下文中“增删”工具定义。

• 错误的做法：动态修改工具集。这会带来两大问题：

• 工具定义通常在 Prompt 靠前的位置，修改它会直接破坏 KV-Cache。

• 历史记录中可能包含了对“已被移除”工具的调用，这会让模型感到困惑，导致行为异常。

• 正确的做法：屏蔽（Masking）。工具定义保持不变，但在解码（Decoding）阶段，通过技术手段“屏蔽”掉当前状态下不应该被选择的工具。

实战技巧：

• 很多模型服务商都支持通过 function calling 的特定模式来约束模型的输出。

• 统一工具命名前缀：Manus 将浏览器相关工具命名为 browser_*，命令行工具命名为 shell_*。这样就可以通过简单的前缀匹配，轻松地将 Agent 的行为限制在某一类工具中，而无需复杂的逻辑。

原则三：把文件系统当作无限上下文

即便是百万级的上下文窗口，在真实的 Agent 场景中也常常捉襟见肘。而且，长上下文还会带来性能下降和成本激增的问题。

• 困境：网页、PDF 等非结构化数据的观测结果可能非常巨大，轻松撑爆上下文。你无法预知十步之前的哪个信息会在关键时刻派上用场，因此任何不可逆的压缩都有风险。

• 破局思路：将文件系统作为 Agent 的外部记忆体。它容量无限、持久化，并且能被 Agent 直接操作。

实战技巧：

• “可恢复的压缩”：这是核心思想。例如，网页内容可以被丢弃，只要在上下文中保留其 URL；文件内容可以被省略，只要保留其在沙箱中的路径。这样，Agent 可以在不丢失信息的前提下，极大地缩减上下文长度。

原则四：用“复述”对抗遗忘

当下一些强大的 Agent 在执行复杂任务时，会创建一个 todo.md 文件，并一步步更新它。比较典型的是 Claude 的 TodoList 和 Kiro 的 Spec。这是一种精巧的注意力操控机制。

• Agent 的“注意力缺陷”：在长达几十步的任务链中，Agent 很容易“迷失在中间（Lost-in-the-middle）”，忘记最初的目标。

• 解决方案：“复述”。通过不断重写 todo.md 这样的计划文件，Agent 相当于在每一轮迭代的末尾，把全局目标和任务计划“复述”了一遍。

• 本质：这种行为将最重要的全局信息（任务目标）“推”到了上下文的最末端，使其处在模型注意力的“高光区域”，从而有效对抗遗忘，确保 Agent 不偏离航道。

原则五：拥抱错误，让失败成为养料

这是一个反直觉但极其深刻的洞察：不要隐藏 Agent 的失败尝试。

• 常见的误区：当 Agent 执行出错时，我们倾向于清理掉错误日志，然后重试，试图给模型一个“干净”的上下文。

• 错误之处：这样做等于剥夺了 Agent 从失败中学习的机会。模型看不到失败的尝试和返回的错误堆栈，就无法更新其内部的“世界模型”，很可能会在同一个地方反复犯错。

最佳实践：

• 保留完整的操作轨迹，包括所有失败的尝试和环境返回的错误信息。当模型看到“这个动作失败了，这是错误原因”时，它会自然地降低再次尝试该动作或类似动作的概率。

错误恢复能力是衡量 Agent 智能水平和鲁棒性的关键指标，但这在当前的学术研究和基准测试中往往被忽视了。

原则六：打破常规，避免“少样本陷阱”

Few-shot Prompting 是提升 LLM 能力的常用技巧，但在 Agent 场景中，它可能成为一个陷阱。

• 风险：“路径依赖”。语言模型是强大的模仿者。如果上下文中充满了大量相似的、重复的“动作-观察”对，模型会倾向于陷入这种模式，即使当前情况需要改变策略。

• 现象：在处理一批相似任务时（如审核 20 份简历），Agent 可能会变得越来越“机械”，不断重复之前的动作，导致效率低下甚至产生幻觉。

应对策略：

• 引入可控的、结构化的“随机性”和“多样性”。例如，在序列化时轻微改变模板、变换措辞、调整格式顺序等。这种“小噪音”可以打破上下文的单调重复，迫使模型在每一步都进行更“主动”的思考，而不是“惯性”地模仿。

三、成为一名优秀的“上下文工程师”

读完 Manus 的分享，我最大的感触是，上下文工程是一门实践的科学，更是一门将 AI 从“玩具”变为“工具”的艺术。它要求我们不仅要理解模型，更要理解任务、环境和 Agent 本身。

基础模型的能力就像奔涌向前的潮水，它决定了我们能到达的水域有多广。而我们精心设计的上下文工程，则是我们赖以航行的船。潮水越高，对我们造船的技艺要求也越高。

👨‍💻 关于十三 Tech

资深服务端研发工程师，AI 编程实践者。专注分享真实的技术实践经验，相信 AI 是程序员的最佳搭档。希望能和大家一起写出更优雅的代码！