随着 Agent 能力不断提升，如何高效管理上下文成为关键挑战。Cursor 团队近期发布的"动态上下文发现"工程博客，给出了一套系统性的解法——用文件系统作为外部存储，让 Agent 按需发现、渐进加载。

01 从"提前灌输"到"按需发现"

Cursor 的核心判断是：预先提供更少的细节，反而能让 Agent 更容易自主地按需提取相关上下文。这正是动态上下文发现与传统静态上下文之间的根本区别。

静态上下文的思路，是在任务开始之前，把所有的 API 文档、数据库 Schema 都常驻在 System Prompt 里。这就像去旅行时把锅碗瓢盆全塞进后备箱，车重得跑不动。 动态上下文发现则不同。一开始，系统只提供一个干净、最小化的上下文起点，把大量信息放在外部。当 Agent 执行任务时意识到缺某类信息，再主动去发现、去加载。这就像经验丰富的背包客，出门只带护照和信用卡，真正需要什么到现场再获取。

动态上下文发现的价值，不仅是节省 token，更重要的是减少信息噪音、降低认知负载，让 Agent 在更干净的上下文中推理，反而更容易给出高质量结果。

那这个理念在工程上如何实现？Cursor 给出了五个具体实践：

02 实践一：将长工具响应转换为文件

想象这样的场景：你让 Agent 运行一个数据库迁移脚本，终端瞬间吐出 5000 行日志。其中前 4999 行都是"进度 10%"、"进度 20%"这样的信息，只有最后一行写着"Error: 数据库连接超时"。

传统做法是"截断"——只保留前 2000 个字符。但这会导致灾难性后果：关键报错信息往往藏在截断的部分里。Agent 拿着正常的日志，会一本正经地告诉你"任务执行成功了"，或者茫然地说"我不知道发生了什么"。

Cursor 的做法是把工具输出完整写入文件，不立刻塞进上下文，只告诉 Agent：结果在这里，需要时自己去读。

但文件这么大，Agent 从哪里开始读？Cursor 使用 tail 工具——查看文件末尾内容，默认是最后十行。这就像先翻到长报告的最后一页看结论。很多工程输出的关键信息确实出现在末尾：最终报错摘要、测试是否通过、退出状态等。

关键在于，tail 只是第一步探针策略，而非全部。它让 Agent 用极小成本"摸一下水温"。如果末尾信息够决策就到此为止；如果不够，Agent 会继续扩大读取范围，用关键词定位，把真正需要的片段引入上下文。整个过程是先探测、再展开，直到信息刚好够用。

03 实践二：摘要时引用对话历史

模型都有上下文上限，对话太长时必须进行"摘要"压缩。但压缩必然有损——摘要可能保留"用户修改了代码"这个大意，却丢掉"用户把超时时间从 10秒改成了 5秒"这个关键细节。这导致 Agent 越聊越笨、越聊越不精准。

Cursor 的解法是给 Agent 一本"历史书"。

即使对话被摘要了，原始完整的对话记录并没有被扔掉，而是转存成文本文件。在新一轮对话中，Agent 脑子里虽然只有简短的摘要，但手里握着对话历史文件的路径。

当 Agent 写代码时发现摘要里的信息不够用，比如"我记得用户提过一个 S3 存储桶名字，但摘要里找不到了"，它不会瞎猜，而是立刻暂停手头工作，去搜索那个历史文件，从几十轮之前的对话里把具体的桶名字精准捞回来。

这就像考试：传统摘要机制是"闭卷考试"，复习完就把书收走；而 Cursor 的机制是"开卷考试"，脑子里只记重点脉络，但允许随时翻书查细节。这让 Agent 拥有了近乎无限且高保真的长期记忆。

04 实践三：Skills 的按需加载

Cursor 支持 Agent Skills 开放标准。Skill 像一份用文件写成的操作手册，告诉 Agent 如何执行特定领域的任务。它包含名称和描述，可以作为静态上下文放进系统提示词，但只放目录级信息，不放全文。Agent 通过 grep 和语义搜索等工具自动引入相关 Skills。

• grep（关键词搜索）
  ：确定性强、速度快、结果可解释。比如 Agent 要做数据库迁移，就用 grep 在 skills 文件夹搜索 migration 或 schema，快速定位相关技能文件。

• 语义搜索
  ：解决关键词不一致的问题。任务里说"财务异常排查"，技能文件写的是"revenue irregularities investigation"，关键词不重合但语义接近，语义搜索能找出来。

技能发现不是靠单一魔法，而是靠一套可控的发现手段：能用关键词就用关键词，不够再用语义匹配。最终目的是按需发现后再加载。

05 实践四：仅加载所需的 MCP 工具

现在的 Agent 往往集成成百上千种工具，传统做法是把所有工具"说明书"全部塞进 System Prompt 里。这造成了"说明书膨胀"：100 个工具的参数定义可能占 5 万个 Token，Agent 还没开始干活，脑容量就被占满一半。而且工具太多容易混淆，不知道该用哪个。

Cursor 的做法是把工具说明书卸载到文件系统。Agent 的初始 Prompt 里只保留一个极简的"菜单"——只含名称和简短描述，不含具体说明书。

当用户说"帮我把代码推送到 GitHub"，Agent 看到菜单里有"GitHub 工具包"，意识到需要这个能力，才会主动去读取对应的说明书文件，学习 API 怎么调用、参数怎么填，学完立马执行。

仅这一项改动，就将 Token 消耗减少了 46.9%，推理成本直接减半。

还有一个意外收获：以前工具不可用时，系统直接把工具从 Prompt 里拿掉，Agent 会告诉你"我不会用 GitHub"。现在工具列表作为文件存在，即使工具不可用，文件还在。Agent 读取时发现状态是"需重新认证"，就能智能地告诉用户："我有 GitHub 的能力，但现在需要重新登录，请提供新的 Token。"

从"我不会"变成"我需要权限"，这个微小转变让 Agent 更像专业的合作伙伴，而不是随时会出 Bug 的程序。

06 实践五：将终端会话视为文件

回想一下传统的 AI 结对编程：终端跑命令报错了，得手动选中那一大段红色报错信息，右键复制，切到 AI 对话框粘贴发送。报错太长还得往上翻好几页找头。这个过程非常打断心流，而且容易复制漏了。

Cursor 的做法是把集成终端里的所有输出都写入本地日志文件。这个过程用户无感。但当你对 Agent 说"修好它"或"刚才为什么报错了"时，Agent 不需要你提供任何上下文，它会自己读取最近的终端日志，用 grep 快速定位最近一次 Error 关键字，分析堆栈信息，给出修复建议。

整个过程不需要任何一次"复制粘贴"。这种流畅的交互体验，正是得益于底层那个默默工作的"文件流"。

07 行业趋势：文件系统成为 Agent 的外部大脑

总结来看，Cursor 做的不是几个零散小技巧，而是在系统层面统一改变了上下文的进入方式。动态上下文发现的核心不是让模型背更多，而是让模型在更少、更干净的上下文里思考，同时保留一套可访问的外部信息空间。

系统负责把信息完整落到文件里，并提供清晰的指针和工具；Agent 负责在任务推进中自己判断信息需求，通过搜索、定位和渐进读取，把真正需要的片段带入上下文。这既提高 token 效率，也降低认知负载，最终提升输出质量。

回看 Manus 关于文件系统与上下文的讨论、PeakJi 提到的工具卸载实践、以及 Anthropic 在 Skill 机制里强调的渐进式披露，会发现 Cursor 的动态上下文发现并非孤立出现。不同团队在不同产品形态下，正在独立收敛到一套相似的工程思路：

• 把上下文视作稀缺内存
• 把文件系统视作几乎无限的外部存储
• 把卸载视作缓解上下文压力的基本手段
• 把渐进式披露视作信息进入工作空间的默认策略

这种顶层设计的趋同，说明在 AI Agent 领域，顶级团队正在形成一套隐性的工程共识。虽然文件未必是 AI 交互的终极形态，但它证明了一个现实判断：在当下模型能力、成本和可靠性都仍受约束的阶段，最稳妥的路线往往不是发明更复杂的抽象层，而是选择更简单、更可控、更可演化的原语作为"外部大脑"的底座。

它让 Agent 把智能从"记住更多"迁移到"找到更准"，把能力从"生成答案"扩展到"管理信息流"。