最近一次模型升级之后，我们做了一个以前很少做的动作：把线上跑了很久的几个 Agent 的 system prompt 拉出来，逐条过一遍，看哪些规则可以删了。
起因很朴素。新模型的底层能力强了一截，很多过去必须反复叮嘱的事情，它现在本来就能做对。继续让那些规则留在每次调用的热上下文里，看似只是多付一点 token，无伤大雅。
但真正过的时候，问题来了：没有人能完整说清，那份越来越长的 prompt 里，每一段到底还在保护什么。
有些规则能找到当时的讨论记录，对应某一次真实的线上事故。有些只记得“大概以前出过问题”。还有一些，连当初为什么加进去都说不清了。大家只知道它在那里待了很久，所以最好别碰。
那一刻我意识到一件事：这些 prompt 不是被设计出来的，是长出来的。
输出宽泛了，加一句“必须具体”。工具调用错了，加一段工具选择原则。某次漏了风险，再加一份检查清单。每一次修改单独看都有道理，都来自一次真实失败。但时间一长，system prompt 就不再是一套指令，而变成了一份历史事故档案。每次失败留下一层疤痕，没有人知道哪些疤痕还在保护系统，哪些只是遗迹。
我们很擅长让系统记住，却不擅长让系统忘记。
为什么规则只会变厚，不会变薄
这不能怪工程师缺乏减法意识，而是组织的责任结构自然导向的结果。
新增规则是一种低风险的可见行动。线上出了故障，我加上防护规则，就代表我采取了行动，复盘会上这就是交代。即使新规则没起效，或者带来了轻微的副作用，这种代价也是隐蔽的，分摊在每次调用的 token 费里。
删除规则完全是另一回事。删完没出事，没人会觉得是你的功劳；一旦类似事故重新发生，责任划分会非常清晰：谁让你删的？
在没有客观证据支撑时，最理性的选择就是只增不减。Prompt 膨胀的本质，不是团队记住了太多，而是团队没有建立安全遗忘的能力。
Prompt 不是免费的保险
留着不删就当买保险，这个账算错了。Prompt 里的每条规则都像一份自动续期的保单：它可能保护某一类风险，但每次调用都在重新支付保费，而且保费远不止 token 一种。
第一是直接成本。Token、延迟、上下文窗口占用，每次调用都在付。在每天千万级调用的系统里，这不是小数目。
第二是注意力成本。上下文变大，不等于信息能被同等使用。有团队拿十八个主流模型做过系统的实测：输入越长，模型表现越差，任务越复杂掉得越明显。模型能读到一条规则，和这条规则能在正确的时机真正约束行为，是两件事。我在《Skill 不该越写越重》里写过类似的判断：东西越杂，重点越容易被稀释，规则堆多了不是补齐，是往系统里注入竞争注意力的噪声。
第三是冲突成本。不同时期、针对不同事故留下的规则，局部都正确，放在一起未必是一套一致的策略。模型要在互相打架的指令之间妥协，输出质量就会漂移。
第四是行为固化。大语言模型不是逐条执行规章制度的解释器。在代码里加一个 if，是增加一个明确的分支；在 prompt 里加一句话，是在重新调整模型的整个行为分布。过去为旧模型准备的详细步骤，放到新模型上，可能不再是帮助，而是束缚。模型本来已经能根据情境灵活处理，旧规则还在要求它按固定路径走。
所以每次模型升级，除了跑一遍回归确认能力没退化，还应该算另一笔账：原来为旧模型准备的补偿，还有多少是必要的？哪些已经没价值了？哪些虽然不再必要，却开始产生负作用？这笔账，大多数团队从来没算过。
Eval 改变的，是“删除”的性质
这就需要 Eval。
很多团队把 Eval 理解成一个分数：成功率多少，准确率多少，证明这个版本可以发布。但严格说，任何有限的测试集都无法证明一个开放式 Agent 已经足够好。通过一千个案例，不能保证第一千零一个不失败。
Eval 真正回答的是一个更具体的问题：在我们已知的任务分布、风险边界和失败样本下，这次修改让系统变好了、变坏了，还是没变？
这样，Eval 就不是一张成绩单，而是一种变更管理机制。尤其是，它让“删除”第一次变得可以被管理。
删掉某段规则，过去保护的严重事故会不会重现？成功率、人工纠正率、工具调用次数、延迟怎么变？这些问题能被重复回答之后，删除就不再是“凭感觉”，而是一次有边界、可回滚、可比较的工程实验。
这也是我维护几个长期运行的 Agent 过程中确立的闭环：Trace 负责记录事故到底怎么发生；Eval Dataset 把一次事故从聊天记录变成可以反复重放的案例；Regression 验证修改之后重要边界还在不在；Release Gate 把这种验证变成发布条件。
过去我主要把 Gate 理解成阻止系统变坏的机制。现在我觉得它还有另一个同样重要的作用：Gate 不只挡坏东西进来，也应该批准不再必要的复杂性离开。
有了这套闭环，举证责任就可以反过来。以前是提出删除的人必须证明这段规则绝对没用了。现在应该问的是：模型已经升级，这条规则还值得每次调用都携带吗？它保护的是哪组真实失败样本？删掉以后这些 case 退化了吗？对那些为了弥补旧模型能力而加的补丁，举证责任应该从删除者转移到保留者身上：不是别人要证明它无用才准删，而是它要持续证明自己有价值，才有资格常驻在运行时上下文里。
减法不是遗忘
有人会担心：删 prompt，会不会把过去踩坑的教训也丢了？
恰恰相反。真正的减法不是忘记历史，而是把历史放到正确的位置。
一次失败不该被压缩成一句脱离上下文的警告，永远塞在每次运行的热上下文里。它更应该被完整保留：Trace 记录事故发生在哪一步，失败样本进入 Eval Dataset，修复方式写进回归案例。团队仍然记得当初为什么加这条规则，仍然能在新模型退化时恢复它，但系统不需要在每一次无关的任务里都重新背负这段历史。
代码侧我刚写过姊妹判断。在《当写代码开始免费，删代码才成了工程师的正职》里，我提出工程的目标是用最少的长期承诺，换取足够且可验证的业务能力。这次轮到 prompt 侧。删除 prompt 不是删除组织记忆，而是把记忆从最昂贵、最容易互相干扰的地方，迁到更适合长期保存的位置。
不是所有值得保存的信息，都值得每次被模型读取。成熟的系统不是存得少，而是分得清：什么该常驻，什么该按需检索，什么只该存在于 Eval 和 Trace 里。
不是所有规则都该删
当然，“模型变强就删 prompt”如果被当成普遍原则，会走向另一个极端。Prompt 里的规则不是同一种东西，至少分四层。
最底是宪法层：合规、安全、身份、授权，不可逾越的红线。往上是契约层：业务口径、输出格式、责任边界。这两层不是因为模型不够聪明才存在的。模型再强，也不会自动知道一家公司的业务口径，更无权替组织决定愿意承担什么风险。合规不是能力补丁，是系统目标本身。这两层必须坚固常驻。
真正需要经常翻出来审视的，是启发层和补丁层：那些为了帮助模型完成任务给的方法步骤，和针对某个模型版本弱点加的临时补偿。它们天然应该有适用范围和退出条件。
所以一份成熟的 prompt 负债表，每条规则至少要能回答：它因为什么失败而存在？保护哪组 Eval case？适用于哪个模型和工具环境？每次调用的成本是什么？什么条件下可以删？
回答不了这些问题的规则，不再是工程知识，更像一种组织迷信。
说回每个人自己
这套逻辑放到个人使用 AI 上，同样成立。
现在很多人开始攒自己的 prompt 模板，写文章的、做研究的、写周报的。但我越来越觉得，prompt 很可能不是最值得积累的那部分。它高度依赖模型，一个在某代模型上精心调出来的长 prompt，换一代模型可能就大半作废。模型越进化，历史 prompt 折旧越快。
Eval 不一样。一个人判断什么是好文章、好方案、可信的数据结论，这些标准也会进化，但不会因为底层模型更换而失效。
prompt 是你和当前这一代模型签的临时合同，Eval 是你和未来的自己签的长期合同。前者记录“现在该怎么做”，后者记录“为什么这个结果值得接受”。
AI 可以一次给你十个标题、十种方案。生成得越多，稀缺的就越不是“还能做出什么”，而是“什么值得留下”。如果一个人没有自己的 Eval，他得到的不是十倍的创造力，是十倍的平均答案。
所以我不认为，未来最成熟的 Agent 会拥有最长的 system prompt。
它可能只有一组很稳定的目标、身份、合规和责任边界，大量过去的事故和经验放在 Trace、Eval Dataset 和回归体系里，而不是永远堆在热上下文中。
每次模型升级，团队除了问“新模型又能让我们多做什么”，还应该问一个过去很少被认真提出的问题：这一次，我们终于可以删掉什么？
一个没有 Eval 的系统，只有记忆，没有新陈代谢。
一个真正成熟的系统，不是从不遗忘，而是知道什么必须被记住、什么可以离开运行时，以及决定遗忘之前需要什么证据。
从这个意义上说，真正该越积越厚的，从来不是 prompt。
是 Eval。