指令是否进入，取决于违反代价#

我会先判断不写某条指令会发生什么：

• 涉及安全、数据损失或不可逆操作：必须进入稳定约束，并尽可能由代码校验；
• 涉及项目固定规范：放在项目级说明，保持简短且可复用；
• 只对当前任务有效：放在任务描述或临时计划；
• 只是偏好或低概率建议：按需提供，不进入全局提示。

这比“规则是否正确”更有区分度。许多规则本身没有问题，但命中率很低，长期占据全局上下文只会稀释真正重要的约束。

还需要区分行为要求与确定性机制。权限、格式校验和结果验证若能由程序强制，就不应只写成 Prompt。Prompt 适合表达语义目标，不适合承担必须每次成立的不变量。

材料选择取决于能否压缩全貌#

任务材料有两种进入方式：

• Push：调用方预先检索并放入请求，往返少，但在模型理解任务前就决定了相关性；
• Pull：模型通过工具逐步读取，相关性更高，但会增加调用次数和历史重传。

选择标准不是数据规模，而是任务是否需要完整内容。总结一份文档时，目录不能替代正文，应直接提供必要全文；在大型代码库中定位登录逻辑时，可以先给目录或查找结果，再按需读取少量文件。

因此更实用的问题是：能否把全貌压缩成足以指路的低分辨率版本？

• 不能压缩：直接 Push 完成任务所需的完整材料；
• 可以压缩：先提供目录、索引或查找结果，再通过 Pull 获取局部细节；
• 高频必读材料：预先 Push，减少每次都会发生的探索；
• 低频大材料：保留为工具或文件引用，避免默认占用上下文。

上下文污染需要可治理#

探索过程中会积累无效查找、长日志、过期文件内容和失败尝试。这些内容不仅持续重传，还可能与新状态冲突。模型看到旧版本并据此推理，并不是无视事实，而是输入中没有标记旧信息已经失效。

我会采用四种处理方式：

1. 大输出落盘，上下文只保留路径和摘要；
2. 工具结果携带来源，便于精确清理；
3. 早期历史在明确边界压缩，并接受摘要有损；
4. 大范围探索放入子任务，只把结论带回主上下文。

长期记忆也不应自动注入全部历史。它应当先检索、再选择，并与当前会话状态区分；具体边界在四类记忆中单独讨论。

我的选择：保留最小稳定核心#

我会让全局上下文只包含高违反代价、高命中率的规则，把项目事实放在可检索文档，把任务材料按“低分辨率全貌 → 局部细节”逐步加载。

这套方案的代价是需要维护索引、清理和压缩机制，也会增加部分工具往返。若任务范围很小、材料固定且能够一次放入，直接 Push 反而更简单；只有当上下文会持续增长、材料存在版本变化或任务需要探索时，分层加载才有明显收益。