本文内容源自Cursor团队的文章《动态上下文发现》
现在，代码代理正在以一种全新的方式改变我们开发软件的方式。它们的进步不仅源于更强大的代理模型，也得益于更精细的上下文处理，帮助它们更好地运作。
我们在Cursor的代理框架（就是给模型的指令和工具）会针对每个新模型进行专门优化。不过，我们也在努力改善一些适用于所有模型的上下文处理方法，比如如何收集上下文信息，及如何在长时间的互动中更好地使用token。
随着模型在代理角色上的能力不断提升，我们发现，少给一些细节反而能让代理更灵活地提取需要的上下文。我们把这种方式称为动态上下文发现，与传统的静态上下文形成了鲜明对比。
动态上下文发现的文件应用
动态上下文发现在使用token上非常高效，因为它只会引入必要的数据到上下文窗口中。同时，这也能减少那些可能造成混淆或冲突的信息，从而提高代理的回复质量。
在Cursor中，我们是这么实现动态上下文发现的：
- 把较长的工具响应转换为文件
- 在摘要的时候引用聊天记录
- 支持Agent Skills的开放标准
- 高效加载所需的MCP工具
- 将所有集成终端会话视为文件
1. 把较长的工具响应转成文件
当工具调用返回的JSON响应特别庞大时，可能会显著增加上下文窗口的大小。
对于我们自己开发的工具，如文件编辑和代码搜索，我们可以通过合理的工具定义和简洁的响应格式来控制上下文膨胀，但对于第三方工具（比如shell命令或MCP调用）就不一定了。
常见的做法是，代码代理会截断过长的shell命令输出或MCP结果，但这可能会导致一些重要信息的丢失。在Cursor中，我们采取的方式是把这些输出写入文件，并让代理能够读取这些文件。代理会调用tail来检查文件的末尾内容，如果需要的话，再继续读取更多。
这样一来，当接近上下文的限制时，就能避免不必要的额外总结。
2. 摘要时引用对话历史
当模型的上下文窗口被填满时，Cursor会启动一个摘要步骤，为代理提供一个全新的上下文窗口，里面包含了它之前工作的总结。
不过，这种方式会对上下文进行有损压缩，摘要后的代理可能会忽视一些关键细节。在Cursor中，我们将对话历史作为文件提供，以提升摘要的质量。
当达到上下文窗口的上限，或者用户手动要求摘要时，我们会给代理一个指向历史文件的引用。如果代理发现摘要中缺少它需要的细节，就可以在历史记录中搜索来找回这些信息。
3. 支持Agent Skills的开放标准
Cursor支持Agent Skills，这是一种开放标准，用于扩展编码代理的专用能力。和其他类型的规则一样，Skills是通过文件来定义的，这些文件告诉代理如何完成特定领域的任务。
Skills还包括名称和描述，可以作为“静态上下文”包含在系统提示中。接下来，代理可以进行动态上下文发现，利用grep和Cursor的语义搜索等工具，自动引入相关的Skills。
此外，Skills还可以与任务相关的可执行文件或脚本打包。由于它们本质上只是文件，代理能够轻松找到与某个特定Skill相关的内容。
4. 高效加载必要的MCP工具
MCP帮助访问受OAuth保护的资源，比如生产环境日志、外部设计文件或企业内部的上下文和文档。
有些MCP服务器可能包含很多工具，并且描述通常很长，这会显著增加上下文窗口的大小。即便这些工具总是被包含在提示中，但实际上大多数并不会被使用。如果你在多个MCP服务器之间切换，这个问题会更加严重。
期待每个MCP服务器都进行优化是没那么现实的。我们认为，减少上下文占用是编码代理的责任。在Cursor中，我们通过将工具描述同步到一个文件夹，为MCP提供了动态上下文发现的能力。
现在，代理只会接收到一小段静态上下文（包括工具名称），需要时再去查找具体工具。在一次A/B测试中，我们发现，这一策略使代理的总token消耗减少了46.9%（这个结果在统计上显著，但会因已安装的MCP数量而波动）。
这种基于文件的方案还有个好处，就是可以向代理传达MCP工具的状态。以前如果某个MCP服务器需要重新认证，代理会完全“遗忘”这些工具，让用户很困惑。而现在，它可以主动提示用户进行重新认证。
5. 将所有集成终端会话视为文件
过去，你可能需要手动将终端会话的输出复制粘贴到代理的输入中，而现在Cursor会自动将集成终端的输出同步到本地文件系统。
这样一来，当你问“为什么我的命令失败了？”时，代理就能准确理解你在问什么。由于终端历史可能非常长，代理可以只对相关输出进行grep，尤其对于像服务器这种长时间运行的进程生成的日志，这个功能特别有用。
这跟基于CLI的编码代理的情况类似：它们同样可以访问之前的shell输出，但这里的上下文是动态发现的，而不是静态注入的。
简单总结
目前还不清楚，文件是否会成为基于LLM的工具的最终接口形式。
