动态上下文发现 (Dynamic Context Discovery)
TL;DR
本文介绍了动态上下文发现（Dynamic Context Discovery）在AI智能体中的应用，通过减少初始上下文细节，让智能体自行抓取相关信息，提高Token使用效率和回答质量。Cursor在五个场景中应用此模式，如将工具结果转化为文件、引用聊天记录等，以优化编程智能体性能。
作者：Jediah Katz
AI 智能体（AI Agent）正在迅速改变软件开发的格局。它们的飞速进步，既得益于更强大的智能体模型，也归功于更出色的 Context Engineering（上下文工程，即如何通过构建更好的提示词和环境来引导模型）。
在 Cursor，我们会为每一个新接入的前沿模型单独优化“智能体交互框架”（即我们提供给模型的指令和工具）。但在 Context Engineering（上下文工程）方面，我们发现了一些通用的改进空间——比如在一个漫长的任务过程中，如何收集上下文以及如何优化 Token 的使用效率——这些改进适用于我们框架内的所有模型。
随着大语言模型（LLM）在充当“智能体”方面变得越来越强，我们发现了一个有趣的现象：少即是多。我们在最开始提供给模型的细节越少，效果反而越好，因为这让智能体能够更轻松地自行抓取相关的上下文。
我们将这种模式称为 Dynamic Context Discovery（动态上下文发现），这与通常那种不管用不用得上都一股脑塞进去的 Static Context（静态上下文）形成了鲜明对比。
既然文件是最好的接口，那就用文件做动态上下文发现
动态上下文发现在 Token 的使用上要高效得多，因为它只把真正需要的数据拉入 Context Window（上下文窗口，即模型一次能处理的信息量上限）。同时，通过减少上下文窗口中那些可能引起混淆或相互矛盾的信息，它还能提高智能体的回答质量。
以下是 Cursor 目前应用 动态上下文发现 的五个具体场景：
将冗长的工具返回结果转化为文件
在“总结”阶段引用聊天记录
支持 Agent Skills 开放标准
高效加载所需的 MCP 工具
将所有集成终端的会话视为文件
1. 将冗长的工具返回结果转化为文件
工具调用（Tool Calls）往往会返回巨大的 JSON 格式响应，瞬间撑爆上下文窗口。
对于 Cursor 的原生工具（比如编辑文件和搜索代码库），我们可以通过智能的工具定义和最小化的响应格式来防止上下文膨胀。但是，第三方工具（例如 Shell 命令或 MCP 调用）通常没有这种原生优化。
目前的编程智能体通常采取的简单粗暴做法是：截断那些过长的 Shell 命令或 MCP 结果。但这会导致数据丢失，而丢失的部分可能恰恰包含你所需要的关键信息。
在 Cursor 中，我们要么把输出写入一个文件，然后赋予智能体读取该文件的能力。智能体可以先调用 tail 命令查看文件末尾，如果需要更多信息，再继续读取。
这一改变大大减少了因达到上下文上限而触发的不必要的“对话总结”。
2. 在“总结”阶段引用聊天记录
当模型的上下文窗口被填满时，Cursor 会触发一个“总结”步骤，给智能体腾出一个新的上下文窗口，其中包含之前工作的摘要。
但是，智能体的知识会在这个过程中“退化”，因为“总结”本质上是对上下文的一种 有损压缩。智能体可能会忘记任务中的关键细节。在 Cursor 中，我们将聊天历史记录也作为文件处理，以此来提高总结的质量。
当达到上下文窗口限制，或者用户决定手动触发总结时，我们会给智能体一个指向“历史记录文件”的引用。如果智能体意识到摘要中缺少某些它需要的细节，它就可以通过搜索这份历史记录文件来找回这些信息。
3. 支持 Agent Skills 开放标准
Cursor 支持 Agent Skills，这是一种通过专业能力扩展编程智能体的开放标准。类似于其他类型的 Rules（规则），Skills（技能）也是通过文件定义的，它们告诉智能体如何在特定领域的任务上表现得更好。
Skills 包含名称和描述，这些信息可以作为“静态上下文”放入系统提示词（System Prompt）中。然后，智能体可以使用 grep（一种强大的文本搜索工具）和 Cursor 的 语义搜索 等工具，进行 动态上下文发现，从而拉取相关的技能细节。
Skills 还可以捆绑与任务相关的可执行文件或脚本。因为它们本质上就是文件，智能体可以轻松找到与特定技能相关的内容。
4. 高效加载所需的 MCP 工具
MCP（Model Context Protocol，模型上下文协议，一种标准化的连接 AI 模型与数据源的方式）非常适合访问那些受 OAuth 保护的资源，比如生产环境日志、外部设计文件或企业内部文档。
然而，一些 MCP 服务器包含大量工具，且往往带有冗长的描述，这会严重挤占上下文窗口。更糟糕的是，即使这些工具总是被包含在提示词中，绝大多数时候它们根本不会被用到。如果你使用了多个 MCP 服务器，情况会变得更糟。
指望每个 MCP 服务器都为此进行优化是不现实的。我们认为，减少上下文占用的责任在于编程智能体本身。在 Cursor 中，我们通过将工具描述同步到一个文件夹中，实现了针对 MCP 的 动态上下文发现。
现在，智能体只接收一小部分静态上下文（主要是工具名称）。当任务确实需要时，它才会去查找工具的详细信息。在一项 A/B 测试中，我们发现对于调用了 MCP 工具的运行任务，这种策略将智能体消耗的总 Token 数减少了 46.9%（该数据具有统计学显著性，但根据安装的 MCP 数量会有较大波动）。
这种基于文件的方法还解锁了一个新能力：向智能体传达 MCP 工具的状态。例如，以前如果一个 MCP 服务器需要重新认证，智能体可能会直接“忘记”这些工具的存在，让用户一头雾水。而现在，智能体可以主动告知用户去重新认证。
5. 将所有集成终端的会话视为文件
Cursor 不再需要你手动复制/粘贴终端会话的输出并喂给智能体，而是直接将集成终端的输出同步到本地文件系统。
这让询问“为什么我的命令失败了？”变得非常简单，智能体能够直接理解你指的是什么。由于终端历史记录可能很长，智能体可以使用 grep 仅搜索相关的输出内容，这对于分析服务器等长时间运行进程的日志非常有用。
这模仿了基于命令行界面（CLI）的编程智能体的体验——拥有之前的 Shell 输出作为上下文——但不同的是，它是动态发现的，而不是被静态注入的。
简单的抽象
对于基于大语言模型（LLM）的工具来说，文件是否是最终的交互接口尚无定论。
但随着编程智能体的快速进化，“文件”已被证明是一种既简单又强大的基元（Primitive）。相比于那些无法完全适应未来的新造抽象概念，文件是一个更安全的选择。请继续关注我们在这一领域更多激动人心的分享。
上述改进将在未来几周内面向所有用户上线。本文介绍的技术由众多 Cursor 员工共同完成，包括 Lukas Moller, Yash Gaitonde, Wilson Lin, Jason Ma, Devang Jhabakh 和 Jediah Katz。如果你有兴趣用 AI 解决那些最困难、最雄心勃勃的编程任务，我们非常希望能听到你的声音。请通过 [email protected] 联系我们。