我构建了一个能重写自身系统提示词（system prompt）的智能体。最惊艳的部分不是重写本身，而是拒绝。

重写提示词，让AI自己优化自己——听起来很酷，但这恰恰是错误的第一步。真正让这套系统稳定运转的，不是那个负责提建议的"分析器"，而是一道冷酷无情的"门"。

打开网易新闻 查看精彩图片

这道门必须是确定性的、可验证的、保守的。如果门错了，系统就会漂移失控；如果门是对的，哪怕分析器提出的是垃圾建议，系统也依然安全。

经过4,150次LLM调用、716,580个token、4个领域、4个模型、12/12个Docker测试、489个通过测试、26个已关闭的v0.2.0问题，这里是我验证过的真正有效的方案——以及花了2个版本才证明它的原因。

核心设计：分析器零权限

整个系统的关键设计决策是：分析器没有任何决定权。它只负责提议。每一个提议都必须经过A/B测试和那道门。LLM永远不能自己判断自己的修改好不好——代码说了算。

流程是这样的：智能体执行任务，轨迹存入SQLite数据库；反馈分析器（LLM）审查轨迹并提出修改建议；A/B测试引擎在40个任务的测试集上对比候选提示词和当前提示词；然后进入晋升门（6项确定性检查）；最后决定：晋升、接近命中、还是拒绝。

整个循环跑在一台MacBook上，用的是本地Qwen 4B模型（通过MLX框架）。没有云API密钥，没有按token计费。整个现场测试的4,150次LLM调用，成本：0美元。总耗时：37分钟。

这很重要，因为它改变了调试的经济学。当每次迭代不花一分钱、42秒就能跑完时，你会毫不犹豫地跑、检查、修复、再跑。而在云端，每次迭代要等3分钟以上。你会等待，你会批量调试，你会失去最容易发现bug的快速循环。

六道检查：快速失败，确定性，无LLM参与

晋升门由六个确定性检查组成，按顺序执行，任何一个失败就立即停止：

  • 样本下限：A/B测试最少完成次数，默认5次。防止在2-3个数据点上就做晋升决定。
  • 效应量：改进必须超过5%。这是v0.2.0中最常见的拦路虎。分析器的修改通常只让40个任务中的1-3个有变化。有真实变化，但提升不够。
  • 置信度：p值小于alpha（alpha=0.05）。这项检查抓住了有史以来最隐蔽的bug。
  • 冻结区域：是否触碰了受保护的内容。
  • 编辑距离：是否把整个提示词都重写了。
  • 漂移检测：修改后的提示词是否还能被识别为原来的样子。

快速失败的价值：一个bug暴露下一个

快速失败意味着第一个失败就停止整个链条。修复一个bug，就会暴露下一个。这正是v0.2.0能发现v0.1.0漏掉的bug的原因——当置信度检查本身出错时（p<0.95而不是p<0.05），它掩盖了冻结区域检查的bug。修复置信度后，冻结区域问题暴露出来；修复冻结区域后，漂移校准问题又浮出水面。每一次修复都引出下一个问题。

这套系统的真正教训是：让AI自我改进的关键，不是让AI更聪明，而是让门槛更严格。分析器可以是一个LLM、一个启发式算法、甚至随机猜测——只要门是可靠的，系统就不会失控。

当每次迭代成本为零、每轮只需42秒时，你就能以最快的速度找到bug。而那道拒绝坏建议的门，才是让这一切成为可能的真正功臣。