一个会自我改进的系统，听起来只需要一件事：让它读自己的运行记录，然后改自己。
真做起来会发现，让它改很容易，让它只在边界内改才是全部难点。
闭环长什么样
一条完整的自改进闭环有五段，缺一段就不成立：
运行时诊断 → 可逆的修复 → 把结论写进长期记忆 → 下一轮自动继承 → 一本账追踪「这条建议到底生效了没有」。
大多数团队做到第三段就停了：系统发现了问题，写了条规则，然后就没有然后了。没有下一轮继承，规则就是死的；没有账本，你永远不知道这条规则是真的起作用了，还是只是躺在那里让人安心。
有些东西永远不许它自己改
这是边界里最硬的一条。系统可以改提示词、改规则、改权重、改工作流。但有四样东西，它碰不得：
- 它自己的目标函数。 一个能改目标的系统，会把目标改成它已经能达到的样子。
- 评价器。 同理。让考生出题，分数一定会涨。
- 权限。 尤其是读写分级——一个能给自己升权限的 Agent 不是自改进，是事故。
- 安全红线与数字口径。 评分标准、指标定义、单位换算，这些是所有判断的地基。地基会自己动的话，上面所有的改进都无从比较。
写下来像是废话，但实际系统里这几条特别容易被无意破坏：你把「评分规则」也放进了那份会被自动更新的记忆文件，一个月后它就漂了，而且你查不出是哪一轮漂的。
规则要自带测试上岗
系统生成的每条规则，不能写完就装上。
我的做法是：每条规则必须携带自己的样例——应该被它拦下的，和不应该被它拦下的。加载时先拿这些样例自检一遍，通不过就自动停用，并且报出来。
这一条解决的是一类很隐蔽的故障：规则写得太宽，把正常的东西也拦了。没有反例样本的话，你只会看到「拦截率上升」，还以为它在努力工作。
账本要有人读
系统每一轮都能正确报出该修什么。但如果没有任何东西定期去读这些报告，等于没报。
所以给每项自检打状态：新发现的、已修复的、反复出现的、长期不愈的。
**长期不愈的那一类最值钱。**它意味着这一层的修复建议是无效的——你一直在提示词层反复劝说一件应该在代码层解决的事。它不是提醒你再努力一次，是提醒你换个层。
记忆需要垃圾回收
只增不减的记忆会自己毒化。
低置信度的规则、只出现过一次的模式、已经过时的洞察——它们不会主动消失，但会持续稀释有用信号，让每一轮的上下文里真正重要的那几条越来越难被看见。
**不维护的记忆是干扰源，不是助力。**所以要定期回收：这条规则最近命中过吗？这个洞察对应的业务还存在吗？删掉一条过期规则的收益，常常高于新增一条。
产物要盖指纹
每条对外产物，记录下当时的代码版本、提示词版本和规则版本。
这件事平时没用，出事那天是唯一有用的东西。当有人指着三周前的一份报告问「这个结论怎么来的」，你需要能还原出它是在哪一套约束下生成的——而那套约束今天已经不存在了。
没有指纹的自改进系统，是一个每天都在变、但无法解释自己任何一次历史行为的黑箱。
改进的信号从哪来
最后一个问题，也是最容易被跳过的：系统凭什么知道自己变好了？
埋点能告诉你用户点了什么，但告诉不了你那次输出到底对不对。所以除了常规埋点，我们在关键环节请行业专家在早期做人工标注打分——哪些结论站得住，哪些是看起来对，哪些直接错了。
这批标注量不大，但质量极高，它是喂出评价器的那份种子数据。
**没有可信的评价器，自我改进就只是自我循环。**系统会朝着它自己认为好的方向一路狂奔，而那个方向从来没有人校准过。