之前研究过一篇LangChain的工程师Lance Martin和Manus的联合创始人Peak（季逸超）关于上下文工程的研讨，博文见这里，最近Cursor的工程师Jediah Katz也分享了一篇关于Cursor中关于上下文工程的优秀实践，这里对该文章进行翻译学习：Cursor原文在这里
发布时间：2026 年 1 月 6 日
作者：Jediah Katz
来源：Cursor 官方博客（Research）
编码 Agent（智能体）正在快速改变软件构建的方式。它们的快速进步既来自模型本身能力的提升，也来自更优的上下文工程设计，用以更好地引导其行为。
Cursor 的 agent harness（即我们为模型提供的指令集与工具体系）会针对所支持的每一个最新前沿模型进行单独优化。但与此同时，仍然存在一类对所有在该 harness 中运行的模型都通用的上下文工程改进空间，例如：我们应如何收集上下文，以及如何在长时间交互过程中更高效地使用 token。
随着模型作为 agent 的能力不断增强，我们发现，预先提供更少的细节，反而能让 agent 更容易在需要时主动拉取相关上下文。我们将这种模式称为动态上下文发现（Dynamic Context Discovery），以区别于传统始终被注入的静态上下文（Static Context）。
用于动态上下文发现的文件
动态上下文发现具有极高的 token 使用效率，因为只有在确有必要时，相关数据才会被拉入上下文窗口。同时，它还能减少上下文中可能引入的噪声、冲突或无关信息，从而提升 agent 的响应质量。
在 Cursor 中，我们主要通过以下方式实践动态上下文发现：
- 将冗长的工具响应转化为文件
- 在摘要阶段允许引用完整聊天历史
- 支持 Agent Skills 开放标准
- 仅在需要时加载 MCP 工具
- 将所有集成终端会话视为文件
将冗长的工具响应转换为文件
当工具调用返回体量巨大的 JSON 响应时，会显著推高上下文窗口的占用。
对于 Cursor 内部的一方工具（例如文件编辑、代码库搜索），我们可以通过精心设计的工具接口和最小化的响应格式来避免上下文膨胀。然而，对于第三方工具（如 shell 命令或 MCP 调用），默认情况下并不具备这种控制能力。
多数编码 agent 的常见做法是直接截断过长的 shell 或 MCP 输出，但这种方式可能导致关键信息丢失，而这些信息往往正是后续推理所必需的。
在 Cursor 中，我们选择将这些冗长输出写入文件，并赋予 agent 读取这些文件的能力。agent 可以通过 tail 查看文件末尾内容，并在需要时继续向前读取更多内容。
这种策略显著减少了在接近上下文窗口上限时触发不必要摘要的情况。
在摘要过程中引用聊天历史
当上下文窗口被填满时，Cursor 会触发一次摘要步骤，为 agent 提供一个新的上下文窗口，其中包含截至当前工作的整体摘要。
然而，摘要本质上是一种有损压缩。一旦完成摘要，agent 可能会遗忘部分关键细节，从而影响后续任务的正确性。
为此，Cursor 将完整的聊天历史以文件形式保存，并在摘要完成后将该历史文件的引用提供给 agent。
在达到上下文上限或用户手动触发摘要后，agent 可以在需要时主动搜索聊天历史文件，以找回摘要中未包含但仍然重要的细节信息。
支持 Agent Skills 开放标准
Cursor 支持 Agent Skills，这是一种用于通过专门能力扩展编码 agent 的开放标准。
类似于规则配置，Skills 通过文件进行定义，这些文件描述了 agent 在特定领域任务中应如何执行操作。
Skills 文件本身包含名称与简要描述，这部分内容会作为“静态上下文”注入系统提示中。随后，agent 可以通过动态上下文发现机制，使用诸如 grep 或 Cursor 的语义搜索工具，按需查找并加载相关 Skills 的具体内容。
此外，Skills 还可以打包与任务相关的可执行文件或脚本。由于它们本质上都是文件，agent 能够非常自然地发现并理解与某一 Skill 相关的全部资源。
高效地仅加载所需的 MCP 工具
MCP（Model Context Protocol）用于访问受 OAuth 保护的资源，例如生产日志、外部设计文件，或企业内部的上下文与文档。
一些 MCP 服务器包含大量工具，并附带冗长而详细的描述。这些描述如果被全部注入上下文，会显著占用 token，但其中大多数工具在实际任务中并不会被使用。随着同时接入多个 MCP 服务器，这一问题会被进一步放大。
我们认为，指望每个 MCP 服务器自行优化其上下文占用并不现实。降低上下文成本应当由编码 agent 本身来承担。
在 Cursor 中，我们通过将 MCP 工具的描述同步到一个目录中，从而实现对 MCP 的动态上下文发现支持。agent 在初始阶段只接收到极少量的静态信息（例如工具名称），并在确有需要时再主动查找对应工具的完整描述。
在一次 A/B 测试中，我们发现，在涉及 MCP 工具调用的场景下，这种策略将 agent 的总体 token 消耗降低了 46.9%。这一结果具有统计学显著性，且具体节省幅度会随已安装 MCP 数量的不同而有所变化。
这种基于文件的设计还使 agent 能够感知 MCP 工具的状态。例如，过去当某个 MCP 服务器需要重新认证时，agent 会“完全遗忘”这些工具，从而让用户感到困惑；现在，agent 可以主动提醒用户需要重新进行认证。
将所有集成终端会话视为文件
传统上，用户需要将终端会话的输出手动复制粘贴到 agent 的输入中。现在，Cursor 会自动将集成终端的输出同步到本地文件系统。
这使得用户可以直接提出诸如“为什么我的命令失败了？”之类的问题，而 agent 则能够准确理解其所引用的终端输出内容。由于终端历史往往非常冗长，agent 可以通过 grep 等工具仅检索相关片段，这在分析长期运行的进程日志（例如服务器日志）时尤为有用。
这种模式与基于 CLI 的编码 agent 所面对的环境非常相似：它们同样能够访问历史 shell 输出，只不过这里采用的是动态发现，而非静态注入。
简单抽象
目前尚不清楚，文件是否会成为基于 LLM 的工具交互的最终接口形式。
但可以确定的是，随着编码 agent 能力的快速演进，文件作为一种抽象原语，既简单又强大，并且相比于设计一种可能无法适应未来需求的新抽象层，更加稳妥可靠。
未来我们还将分享更多在这一方向上的进展。这些改进将在接下来的几周内逐步向所有用户推出。
本文中描述的成果来自多位 Cursor 员工的共同努力，包括 Lukas Moller、Yash Gaitonde、Wilson Lin、Jason Ma、Devang Jhabakh 和 Jediah Katz。如果你有兴趣使用 AI 解决最困难、最具挑战性的编码问题，我们非常期待与你交流。