最近读到 Cursor 官方博客的一篇文章：Dynamic context discovery。
这篇文章不长，但我觉得它讲中了 Coding Agent 进化里非常关键的一点：Agent 变强，当然离不开模型能力提升，但同样重要的是 Context Engineering，也就是如何给模型提供上下文。
过去我们很容易有一个直觉：上下文窗口越大越好，信息塞得越多越好。
但 Cursor 提出的思路恰好相反：不要一开始就把所有东西都塞进上下文，而是让 Agent 在需要时自己去发现、检索、读取相关信息。
他们把这种模式称为 Dynamic Context Discovery，动态上下文发现。
一句话概括就是：
好的上下文管理，不是把世界装进 Prompt，而是给 Agent 一张可靠的地图。
为什么不能继续"把信息全塞进上下文"
Coding Agent 工作时会不断调用工具：搜索代码、执行命令、读取文件、访问 MCP 服务、分析终端输出。
这些工具一旦返回大量内容，就会快速吞掉上下文窗口。更麻烦的是，上下文里混入太多暂时无关的信息之后，模型不仅会变"贵"，还可能变"笨"。
因为上下文不是免费仓库。
它既是模型的工作记忆，也是模型下一步决策的依据。里面的信息越杂，越容易干扰推理。
所以 Cursor 的核心判断是：静态上下文应该尽量少，动态上下文应该足够好找。
这篇文章里，他们列了 5 个具体做法。
1. 长工具输出：别直接塞进上下文，先写成文件
有些工具会返回很长的 JSON、日志或命令输出。如果直接把这些内容放进上下文，代价非常高。
很多 Coding Agent 的常见处理方式是截断：内容太长，就只保留一部分。
这个方案看起来简单，但问题也很直接：截断不是压缩，而是丢数据。 你并不知道被截掉的那部分里，有没有真正关键的信息。
Cursor 的做法是把长输出写入文件。Agent 只需要先用 tail 看末尾，再根据需要读取更多内容。
这有点像我们自己调试程序：不会把整份日志背下来，而是先看尾部错误，再按关键字往前追。
对 Agent 来说也是一样。文件提供了一个可检索、可追加、可局部读取的外部记忆层。
2. 总结历史：不是让 Agent 遗忘，而是留下回去查的入口
当上下文窗口快满时，Agent 通常会触发总结，把之前的工作压缩成一段新的摘要。
但总结本质上是有损压缩。
它能保留主线，却很容易丢掉细节：某个用户约束、一次失败尝试、一个已经排除过的方向，都可能在总结后消失。
Cursor 的处理方式是：把聊天历史也保存成文件。
这样，摘要不再是唯一记忆。Agent 如果发现摘要里的信息不够，就可以回到历史文件里搜索细节。
这点我很喜欢。
真正可靠的记忆，不是永远不忘，而是知道忘了以后去哪找。
3. Skills：能力说明也应该按需加载
Cursor 还提到他们支持 Agent Skills 开放标准。
我理解，Skill 解决的是一个很实际的问题：在特定领域里，Agent 不只是要"会做"，还要知道"应该按什么流程做"。
比如写论文、处理表格、做前端设计、润色公众号文章，这些任务都有自己的方法论和质量标准。如果每次都把所有 Skill 的完整说明塞进系统提示词，显然会浪费上下文。
更合理的做法是：系统提示词里只保留 Skill 的名称和描述。当任务需要时，Agent 再用搜索或读取文件的方式加载对应 Skill。
这就是动态上下文发现的一个典型场景：
先让 Agent 知道"有哪些能力入口"，再让它按需展开"能力细节"。
4. MCP 工具：不要让所有工具描述常驻 Prompt
MCP 很有价值，因为它能让 Agent 访问很多受保护的外部资源，比如生产日志、设计文件、企业内部文档和业务系统。
但 MCP 也带来一个新问题：很多 MCP Server 会暴露大量工具，每个工具又有很长的描述。
如果这些工具描述全部常驻 Prompt，上下文窗口会被迅速腐蚀。更糟的是，大多数工具在一次任务里根本不会被用到。
Cursor 的方案是把 MCP 工具描述同步到文件夹里。系统提示词只放一小段静态信息，比如工具名称列表；当 Agent 判断某个任务需要 MCP 时，再去对应文件里读取工具说明。
这件事带来的收益很明显。原文提到，在一次 A/B 测试里，对于实际调用了 MCP 工具的运行，这种策略让 Agent 的总 token 使用量下降了 46.9%。
我觉得这个数据很有意思，因为它说明上下文优化不是"体验细节"，而是实打实影响成本和质量的工程问题。
另外，把 MCP 状态也作为文件同步给 Agent，还有一个额外好处：如果某个 MCP Server 需要重新认证，Agent 不会像以前那样直接忽略它，而是能主动告诉用户需要重新登录。
这就是文件抽象的妙处。它不只是存内容，也能存状态。
5. 终端会话：让命令输出变成可检索的上下文
最后一个做法也很贴近开发者日常：Cursor 会把集成终端的输出同步到本地文件系统。
这样用户就不需要手动复制粘贴终端内容给 Agent。
当你问"为什么我的命令失败了？"时，Agent 可以自己去终端历史文件里查找相关输出。如果日志很长，它还能用 grep 搜索关键错误。
这其实模拟了 CLI Coding Agent 的优势：命令行 Agent 往往天然能看到之前的 Shell 输出。
区别在于，Cursor 不是把所有终端历史静态注入上下文，而是让 Agent 在需要时动态发现。
这 5 个方法背后，其实是同一个抽象
把这 5 点放在一起看，会发现 Cursor 做的事情非常统一：
长工具输出是文件。
历史聊天是文件。
Skills 是文件。
MCP 工具描述和状态是文件。
终端会话也是文件。
文件，就是 Agent 最朴素、也最强大的动态上下文接口。
为什么是文件？
因为文件系统已经足够通用。Agent 天然知道怎么用 grep、tail、read、jq 这些工具去处理文件。它可以局部读取，可以搜索关键字，可以按需展开，也可以在不污染主上下文的前提下保存大量信息。
相比重新设计一套复杂的上下文管理 API，文件反而更简单、更稳定，也更贴近 LLM 已经掌握的操作方式。
对我们做 Agent 应用有什么启发
读完这篇文章，我最大的感受是：上下文工程的重点，正在从"塞什么进去"转向"让 Agent 去哪里找"。
这背后有三个启发。
第一，上下文窗口不是越大越好，信息入口才是关键。
大窗口能缓解问题，但不能替代结构化的上下文组织。把所有东西都塞进去，只会让模型在噪声里工作。
第二，外部记忆不一定要复杂，文件系统可能就是最好的起点。
很多时候，我们不需要一开始就做复杂的向量库、记忆系统或专用上下文协议。先把关键过程沉淀成文件，让 Agent 能查、能读、能追溯，已经能解决大量问题。
第三，好的 Agent 不是"知道一切"，而是"知道如何继续获得信息"。
这也是我觉得动态上下文发现最有价值的地方。
它把 Agent 从一个被动接收上下文的模型，变成一个会主动探索环境的工作者。
当工具输出、聊天历史、Skill、MCP、终端记录都变成可发现的文件，Agent 的行为会更接近真实开发者：先看线索，再查资料，必要时回溯历史，最后基于证据行动。
所以，这篇文章真正让我记住的不是某个单点优化，而是它背后的工程哲学：
不要试图让 Agent 记住整个世界。给它一个清晰的文件系统，让它自己找到世界。