动态上下文发现：先给索引，再按需取正文

先说结论

对会用搜索和文件工具的 Agent，最有用的上下文常常不是“把所有内容预先塞进去”，而是告诉它内容在哪里、何时读取。文件是朴素但强大的中间层：可列目录、可 rg、可切片，也能在摘要丢细节后重新找回原记录。

原文解决什么

长 shell 输出、MCP 工具描述、终端历史和旧对话都可能在任务开始前就挤满窗口。直接截断会丢信息，全部常驻又浪费 token。Cursor 把这些对象转成文件或文件索引，只给 Agent 少量静态提示，让它在判断需要时自行检索。

核心机制

• 长工具结果先完整落到临时文件，上下文只返回路径和摘要；Agent 可先看尾部，再定向读取。
• 对话压缩后保留历史文件引用。摘要负责连续性，原记录负责补回遗漏细节。
• Skill 只把名称和描述放进静态上下文，详细 SKILL.md、脚本与参考资料按任务触发。
• MCP 工具描述按 server 分目录同步，Agent 先发现相关工具组，再读取具体 schema。
• 集成终端输出也视为文件，允许从长日志中搜索失败点，而不是整段复制。

Cursor 原文报告，在实际调用 MCP 的运行中，该策略使总 Agent token 减少 46.9%；这是其 A/B 测试结果，本站未独立复现。

和 Zero-to-AI 现有实践如何接上

Zero-to-AI 的教程目录、AGENTS.md 教程和按需 rg 已具备动态发现的教学材料，但独立站仓根目录尚未配置 AGENTS.md。手写 Markdown 是源真相，构建产物可以重建；因此 Agent 维护内容时应先查目标 Markdown，而不是预载整站或读取派生页面。长 npm run verify 输出也可先保留完整日志，再只提取首个失败与退出码。

指针本身也要可维护：路径改名后应有断链检查，临时日志要标明生命周期，避免“能发现”逐渐变成“发现过期信息”。

一个低成本实验

输入： 一次会产生长日志的 npm run verify，以及一个明确失败任务。

步骤：

1. 保存完整命令输出到临时日志，给 Agent 的初始上下文只含路径、退出码和末尾 30 行。
2. 要求 Agent 用 rg 搜错误标识，并只读取命中附近内容。
3. 修复后重跑同一命令，比较它读取的日志行数与定位是否准确。
4. 保留临时文件到验收结束，之后再清理。

成功证据： Agent 能从路径恢复完整证据，定位到首个可操作失败，且不需要把整份日志放进对话。

停止线： 日志含 token、个人信息或内部数据；不要落盘或继续实验，先做脱敏与访问控制。

常见误区

• 把“文件化”理解为无限落盘：临时输出仍需生命周期、权限和敏感信息边界。
• 只给路径却不给触发条件：Agent 不知道何时读取，索引就只是隐藏信息。
• 认为动态发现零成本：搜索会增加延迟，也可能走偏；稳定高频规则仍应短量预载。

原文与证据边界

46.9% token 降幅与产品体验改善均为 Cursor 原文报告，依赖其具体 Harness 和用户流量。本站能验证文件、搜索和构建命令存在；收益大小需要在本地任务上测量。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。