维护 Agent 时，最容易留下的是过去有效的一条指令，最容易丢失的是它当时为什么有效。模型不善于设计，于是限定组件；容易漏步骤，于是要求固定顺序。每次失败加一条，系统会越来越像旧模型的使用手册。本期设计 Agent 的经验给出另一种可能：能力升级后，一部分曾经帮助完成任务的规则，开始减少可选择的方案。
我们的判断是，更新规则时应同时问“它还在防止哪种失败”与“它挡住了什么新做法”。知识库此前关于规则回归的想法，关注改动后别破坏旧的成功案例；现在需要补上另一侧：保护成功结果，不必等于保护当时那条实现路径。LangChain 放开组件选择但保留品牌要求，正好把这两者分开。不过它是团队复盘，不能据此声称所有约束越少越好。
Charles Miller 的提醒解释了为什么这项维护会越来越重要。某些技巧的价值来自模型暂时做不到，产品一旦吸收这项能力，继续学习或执行旧技巧便可能只剩成本。评论者的反驳又阻止我们走向另一个极端：判断边界本身需要实践。值得保留的经验不是永远照着某个提示写，而是知道原先失败在哪里，并愿意在条件变化后重新检查。
Simon 的游戏让退出条件更难、也更清楚。生成代码和画面变容易，并不意味着“好玩”这个目标也该撤掉。作者与试玩评论者对同一成品的评价不同，说明验收不能只问它有没有运行。对创作任务，规则可以放松，但应保留外部体验反馈；对结构化工作，则可保留明确的格式、计算与交付检查。不同目标需要不同证据，不能让一张成功截图替代所有判断。
一种可尝试的做法，是为重要规则留下最初的失败例子和它要保护的结果。模型升级后，在少量代表任务上比较保留与撤除的效果，同时检查旧成功、新机会和返工成本。若只改善外观却增加流程故障，便不能算退役成功；若输出稳定满足目标而做法更多样，也没必要强迫它回到旧模板。这是由本期材料推导的工作方法，尚未做过这样的对照试验。
这个判断的边界也很实际：权限、事实准确性和必要交付条件，往往来自工作本身，不是旧模型能力不足。它们不能因为一次漂亮演示就被当成过期补丁。真正值得追踪的是，同一任务目标下，哪些临时安排已经没有收益，以及使用者能否说明删去它们后为什么仍然放心。这样，模型进步才会改变工作的可选路径，而不是只让原来的流程跑得更快。
另一种解释
团队体验变化也可能来自模型和平台同期更新，并非删规则单独造成。
接下来观察什么
撤除限制后，旧任务质量与新方案空间能否同时改善。