从 Cursor 的「Dynamic Context Discovery」谈起：AI Agent 真正的护城河，是上下文工程而不是 Prompt

你真正需要的，不是一个为你思考的 AI，
而是一个让你无法停止思考的 AI。

2025 年，AI 工具的竞争正在悄然发生转向。

模型在进步、参数在增长、上下文窗口越来越长，但真正拉开差距的，已经不再是模型本身，而是围绕模型构建的工程系统。

最近 Cursor 发布了一篇技术博客《Dynamic Context Discovery》，系统性地讲述了他们在 AI Agent 中是如何管理“上下文”的。这篇文章看似讲的是 token 优化、文件系统、工具加载，但如果你站在系统工程和长期演进的角度去看，会发现它揭示的是一个更深层的趋势：

AI Agent 的竞争，已经从 Prompt Engineering，进入 Context Engineering 时代。

本文将围绕 Cursor 的这篇文章，结合 Manus 等 Agent 产品的实践经验，从工程视角出发，系统拆解：

• 什么是动态上下文发现

• 为什么“把一切变成文件”是必然选择

• 上下文工程背后的设计哲学

• 以及这对 2025–2026 年 AI Agent 发展的启示

---

一、为什么“上下文”正在成为 AI 的核心问题？

在早期使用大模型时，很多人的直觉是：

给 AI 的信息越多，它就越聪明。

于是出现了大量“上下文堆叠式”的使用方式：

• 把整个项目 README 塞进去

• 把历史对话全部拼进去

• 把工具说明、接口文档、约定规则一次性写进 prompt

这种做法在模型能力较弱时，确实能提高成功率。但随着模型变得越来越聪明，这种方式开始暴露出明显问题。

1️⃣ 上下文不是越多越好

上下文窗口永远是有限的，即便是 200K token，也终究会被耗尽。更重要的是：

• 冗余信息会干扰模型判断

• 模型注意力被迫分散

• 真正关键信息反而被淹没

这就像你给一个经验丰富的工程师分配任务，却把公司十年的制度文档全丢到他桌上——不是帮助，而是干扰。

---

2️⃣ 模型变强之后，问题发生了本质变化

当模型能力提升到一定水平后，问题不再是：

“模型会不会理解我给的信息？”

而是：

“模型什么时候需要什么信息？”

这正是 Cursor 提出“Dynamic Context Discovery”的背景。

---

二、什么是 Dynamic Context Discovery？

一句话概括 Cursor 的核心思想：

不要急着把所有信息塞给模型，而是让模型在需要的时候，自己去找。

这听起来简单，但在工程上，意味着一次根本性的设计转变：

传统方式	Dynamic Context Discovery
人类预判上下文	模型自主发现
静态 prompt	动态加载
信息一次性注入	按需拉取
容易溢出	上下文可控

Cursor 在文章中分享了他们在真实产品中落地的 5 个具体场景，这不是概念，而是已经在线上运行的工程实践。

---

三、五个真实场景：上下文工程如何落地？

场景一：把“长输出”变成文件

问题
AI 调用外部工具（shell、MCP、网页抓取）时，经常返回极长的结果。

传统处理方式：

• 截断

• 只保留前 N 行

问题是：
👉 你永远不知道被截掉的部分是不是后面正好需要的关键信息。

Cursor 的做法

• 把完整输出写入文件

• 给模型“读文件”的能力

• 模型可以先 tail，再决定是否深入读取

📌 工程意义：

• 上下文不再承载“数据本体”

• 只承载“访问入口”

---

场景二：聊天历史 = 摘要 + 原始记录

当对话变长，超出上下文窗口时，Cursor 会进行一次 summary reset：

• 模型只拿到压缩后的摘要

• 原始完整对话被存成文件

如果模型在后续推理中发现：

“这里好像少了什么细节”

它可以主动回溯原始聊天记录。

📌 这不是“遗忘”，而是可恢复的压缩。

---

场景三：Agent Skills 的按需加载

Cursor 支持所谓的 “Agent Skills”，本质上是领域任务说明书。

传统方式：

• 每次都把完整说明塞进上下文

Cursor 的方式：

• 系统提示里只放 技能目录

• 真正需要某个技能时，模型再加载完整说明

这就像你不会随身携带整本百科全书，而是带一个索引。

---

场景四：MCP 工具的极限瘦身

这是数据最硬的一部分。

MCP 服务往往提供几十个工具，每个工具都有很长的描述。如果全部放进上下文：

• token 消耗巨大

• 大多数工具根本用不到

Cursor 的做法：

• 上下文中只保留工具名

• 完整描述同步到文件系统

• 需要时再查

结果：

MCP 场景下 token 消耗减少了 46.9%

这是实打实的工程收益。

---

场景五：终端会话也是文件

Cursor 把集成终端的输出自动同步到文件系统。

于是模型可以：

• 查看历史命令

• grep 错误日志

• 分析长时间运行的服务输出

用户不再需要手动复制粘贴。

---

四、一个共同点：为什么一切都变成了“文件”？

你会发现，上面五个场景，无论是：

• 聊天历史

• 工具输出

• 技能说明

• MCP 文档

• 终端日志

最终都落在同一个抽象上：文件系统。

这不是巧合。

1️⃣ 文件是最稳定的工程抽象

Cursor 在文中说了一句非常重要的话：

我们不确定未来 LLM 工具的最佳接口是什么，但文件是一个简单、强大的基础单元。

文件系统具备几个无可替代的优势：

• 容量近乎无限

• 天然持久化

• 可索引、可回溯

• 模型天然理解（read / grep / diff）

---

2️⃣ Manus：把文件系统当作“终极上下文”

这点与 Manus 创始人 Peak 在其技术博客中的观点高度一致。

他们把文件系统视为：

AI Agent 的长期记忆与外置上下文

一个网页内容可以被从 prompt 中删除，只要 URL 还在；
一个文档可以被省略，只要路径存在。

这是“可恢复压缩”，而不是粗暴截断。

---

五、这不是抄袭，而是工程最优解的收敛

有人调侃说，Cursor 的这篇文章“印证了 Manus 早就在做的事情”。

但从工程角度看，这并不是抄袭，而是最优解的自然收敛。

当你真正构建一个长期运行、可扩展的 AI Agent 系统时，会被同样的约束逼到同样的方向：

• 上下文有限

• 成本敏感

• 行为可解释

• 系统必须长期演进

👉 最终都会走向：
动态上下文 + 文件系统 + 按需加载

---

六、从 Prompt Engineering 到 Context Engineering

这篇文章真正的分水岭在于：

Prompt 不再是核心竞争力，上下文工程才是。

未来的差异点将不在于：

• 你写的 prompt 多漂亮

而在于：

• 你如何组织信息

• 如何让模型“找得到”信息

• 如何在不打扰模型的情况下提供能力

---

七、对未来 1–2 年 AI Agent 的几个判断

1️⃣ 模型会越来越“懒”，但系统更聪明

不是笨，而是策略性懒：

• 不提前加载

• 不提前记忆

• 不提前理解

等需要时再找。

---

2️⃣ 工具会退化为“文件接口”

真正高效的 Agent，最终用得最多的不是复杂 API，而是：

• read file

• search

• diff

• grep

---

3️⃣ 简单抽象会胜过复杂设计

文件系统这种“老掉牙”的抽象，反而成了 AI 时代最稳妥的基石。

---

八、结语：Less is More

Cursor 的这篇文章，并没有发明什么全新的技术。

但它清晰地揭示了一个趋势：

当模型足够聪明时，
少给一点上下文，让它自己去找，
反而比硬塞一堆信息效果更好。

AI Agent 的未来，不在于塞满上下文，而在于构建一个让模型自由探索的信息世界。