我最近看 AI 编程工具的更新，越来越少关注“它又支持了什么模型”，反而更关注一个不太显眼的方向：它们开始认真处理上下文成本了。

GitHub Copilot 在 2026 年春季的一些更新里提到语义搜索、跨仓库 grep、prompt caching、deferred tool loading、面向 Agent 的专用工具。这些词听起来像产品细节，但背后其实是一个很现实的工程问题：AI 编程不是模型越强越好，而是谁能更稳定、更便宜、更少误读地把正确上下文喂给模型。

上下文不是越多越好

开发者第一次用 AI 编程工具，通常会希望它“理解整个项目”。但项目越大，这句话越危险。一个中型仓库里，真正与当前任务相关的代码可能只有 5 个文件，模型却可能被 README、旧实现、测试 fixture、生成代码、历史迁移脚本一起淹没。

上下文多，会带来三个问题：

• 成本上升，尤其是长会话和多轮修复；
• 注意力被稀释，模型更容易抓错重点；
• 错误上下文会显得“很有证据”，导致错误方案更难被发现。

所以 prompt caching 和 deferred tool loading 这类能力，本质不是锦上添花。它们是在把 AI IDE 从“把东西全塞进去”推进到“按任务组织上下文”。

语义搜索有用，但不能替代工程索引

语义搜索适合找“不知道关键词但知道意图”的代码。比如你想找“创建订单后扣库存的逻辑”，但项目里函数名叫 reserveSku，传统 grep 可能不容易找到。语义检索在这里能明显节省时间。

但语义搜索不是万能的。它容易找到“看起来相关”的代码，却不一定知道调用链、运行时依赖和边界条件。一个真实的改动通常还需要这些信息：

rg "reserveSku|inventory|stock" src tests
pnpm test -- --runInBand inventory
pnpm typecheck
git diff -- src/domain/order.ts src/domain/inventory.ts

我的经验判断是：语义搜索应该负责扩大候选范围，grep、类型系统、测试和调用图负责收口。只靠语义搜索，很容易把 Agent 带进“相似但不相关”的文件。

deferred tool loading 说明工具本身也成了上下文噪音

很多人设计 Agent 时喜欢一次性暴露很多工具：查数据库、跑测试、发请求、读文档、开 PR、发 Slack。问题是，工具说明本身也占上下文。工具越多，模型越需要先判断“我该用哪个工具”，这一步也会出错。

deferred tool loading 的思路很朴素：不要一开始就把所有工具塞给模型，而是在任务需要时再加载。这个方向对小团队尤其重要，因为大多数团队没有能力维护一个庞大但干净的工具目录。

如果自己做内部 Agent，我会把工具目录拆成几层：

tools/
  readonly/
    search_docs
    grep_repo
    read_logs
  safe_write/
    create_branch
    update_draft_pr
  dangerous/
    deploy_prod
    delete_record
    merge_pr

默认只加载 readonly。safe_write 需要任务进入实现阶段后再开放。dangerous 永远不要自动开放，至少要有人工确认和审计记录。

真正该建设的是项目上下文层

很多团队会把 AI 编程工具当成一个外部应用来用：开发者自己装插件，自己写 prompt，自己复制错误日志。短期没问题，长期会变成混乱。因为每个人喂给 AI 的上下文不同，得到的代码风格、边界判断、测试习惯也不同。

我更建议把一部分上下文沉淀到项目里，而不是散落在聊天记录里：

.github/copilot-instructions.md
AGENTS.md
docs/architecture.md
docs/testing.md
docs/decisions/ADR-0001-auth-boundary.md

这些文件不需要写成公司级规范，越短越好。重点是告诉 Agent：这个项目的边界在哪里，测试怎么跑，哪些目录不要碰，哪些历史包袱不要误删。

个人开发者怎么做才不亏

个人开发者最容易犯的错，是为了“让 AI 更懂我”不断加上下文，最后每次任务都变成一次昂贵的长会话。我的建议是反过来：先减上下文，再加工具。

• 给项目写一个不超过 200 行的 AGENTS.md；
• 把常用命令固定下来，比如 test、lint、typecheck；
• 把生成代码目录、迁移脚本、第三方复制代码标记为低优先级；
• 每次任务前先让 AI 列出它认为相关的文件，再允许它修改。

一个很实用的 prompt 是：

先不要修改代码。请只做三件事：
1. 找出与这个 bug 最相关的 5 个文件；
2. 说明每个文件为什么相关；
3. 给出你打算运行的验证命令。

这句话看起来慢，但能显著减少“AI 上来就改错地方”的情况。

我的判断

AI 编程工具下一阶段的竞争，不只是模型能力，而是上下文供应链。谁能更便宜地找到正确文件，谁能更晚加载不必要工具，谁能把团队约定变成可读上下文，谁就能让 Agent 少犯低级错。

个人开发者现在不需要重仓某一个插件，但应该开始整理自己的项目上下文。半天时间足够做一件事：给最常维护的项目补一个 AGENTS.md，写清楚启动、测试、目录边界和禁止事项。这个投入比追最新模型更稳。

资料依据：GitHub Copilot for VS Code 2026 年 4 月更新、JetBrains Copilot CLI agent 和全局 agent 配置更新。本文没有做真实 token 成本对比，后续最好补一组同任务在不同上下文策略下的调用成本和失败率。