强模型时代，如何给智能体上下文做减法

一、旧经验为什么开始失效

过去一段时间，编程智能体的能力提升很快，但早期版本有一个明显短板：它不太会主动查阅项目文档。团队只能用强制规则补位，比如“每次修改前先读完所有架构文档”。在当时，这类规则确实有用，它至少保证智能体看过关键背景。

新一代模型的指令遵循能力明显更强。规则写得越具体、越绝对，模型执行得就越彻底。原本为弥补能力不足而写的保险条款，现在变成了性能负担。变化的核心在于：规则的执行方式从“偶尔漏读”变成了“每次全读”。

同一份上下文配置，在旧模型上是安全网，在新模型上可能是拖累。定期清理这些配置，应当成为项目维护的日常工作。

二、问题一：触发条件过宽，技能说明被误加载

技能说明模块通常带有一段触发描述，告诉智能体什么时候应该使用它。如果这段描述很宽泛，例如“适用于数据库、查询、模型或持久化相关工作”，模型会把许多普通任务也归入这一类。

设想一个场景。你只是调整了某个 ORM 模型的字段默认值，或者优化了一条查询语句。这些操作和数据库迁移无关，但模型可能判断迁移相关的技能与当前任务有关，于是把迁移规则、检查步骤和参考资料全部载入上下文。任务本身很小，上下文却被大量无关内容占满。

修正方法是把触发条件收紧到具体动作，对比如下：

写法	触发范围	实际效果
适用于数据库相关工作	很宽，涵盖读写、建模、查询	普通任务频繁误触发
新增或修改数据库迁移，或审查其上线过程	窄，对应明确动作	只在需要时加载

判断标准很简单：触发描述应当回答“用户正在做哪一个具体动作”，而不是“用户处于哪个领域”。

三、问题二：每次编辑都强制全量读取

更常见的问题出在项目指令文件里。下面是一条典型的低效规则：

# 低效写法
每次编辑前，必须完整阅读 architecture.md、database.md、deployment.md。

按这条规则，哪怕只是修改一个报错提示文字，智能体也会先读完三份文档。当天若要编辑十次，它就重复读十次。代价体现在四个方面：

1. Token 消耗：文档越长，每次读取越贵，重复读取叠加后很快超出预期。
2. 响应延迟：读取和理解大段文本需要时间，小改动也被拖慢。
3. 上下文膨胀：无关内容长期占据上下文窗口，模型对真正相关的约束关注度下降。
4. 幻觉风险增加：文档之间可能存在过时或矛盾的描述，全部塞进上下文后，模型更容易混淆细节。

“每次都读”看似稳妥，实际是把成本分摊到了每一次操作上。

四、设计上下文路由表

更合理的做法，是把“什么任务加载什么上下文”写成明确的映射关系，并放在项目指令文件中：

# 上下文加载规则
- 修改服务边界或模块职责：读取 architecture.md
- 修改数据表结构或索引：读取 database.md
- 准备或执行部署：读取 deployment.md
- 普通界面样式或文案问题：无需读取上述文档

设计路由表时，可以遵循以下原则：

• 每一行对应一类可观察的任务，而不是一个宽泛的领域。
• 每份文档只在少数几个场景中被引用，避免多处重复指向同一文档。
• 明确写出“无需加载”的情形。这一行能有效阻止模型对小任务过度反应。
• 把硬性约束与参考信息分开。例如“禁止直接修改生产配置”属于必须遵守的红线，应单独列出，而不是藏在长文档里等待被读取。

路由表的价值在于，智能体不需要记住全部文档，只要根据任务类型查表即可。上下文规模由任务复杂度决定，而不是由项目文档总量决定。

五、一次规则大扫除的执行步骤

第一步，盘点现有规则。列出所有项目指令文件和技能说明模块，记录每条规则的作用、触发条件和引用的文档。

第二步，标记高风险条目。重点关注三类内容：

• 含“每次”“所有”“任何”等绝对词的条目；
• 触发描述中包含大类名词（如“数据”“前端”“配置”）的条目；
• 引用了长文档，却没有说明何时需要读取的条目。

第三步，改写触发条件。把宽泛描述替换为具体动作，并补充反例，说明哪些常见任务不应触发。

第四步，合并重复内容。同一约束如果出现在多处，只保留一处权威来源，其他位置改为引用。

第五步，删除过时规则。有些规则是为旧模型的弱点设计的。如果当前模型已能稳定完成相应工作，可以移除，或降级为建议。

第六步，验证效果。选取一组代表性任务，例如修改一个字符串、修复一条查询、调整一次迁移、准备一次部署。对每项任务记录加载了哪些文件、消耗的 token 数量、完成耗时，以及是否出现不必要的暂停或提问。对比改动前后的数据，判断调整是否有效。

六、需要注意的取舍

大扫除不等于把规则删得越少越好。删除过度会带来另一类问题：该读文档的时候智能体没有读，导致架构或数据库变更出现偏差。

因此，每次调整后应做两类检查。第一，关键场景是否仍然加载正确的文档，例如涉及表结构的修改是否仍然读取数据库文档。第二，高风险操作是否仍受约束，例如部署前的确认步骤是否保留。

路由表也需要维护。文档改名、拆分或废弃时，表格必须同步更新，否则失效的引用会让智能体基于错误的依据工作。建议把路由表的更新纳入文档变更的检查清单，与代码评审一起完成。

规则数量没有固定标准。判断依据始终是：这条规则能否帮助智能体在当前任务中做出更好的决策。如果答案是否定的，它就不应占用上下文的位置。