当智能体自我改进时，没有一层机制判断这个改进能不能信

问题是什么

智能体自己改写提示词、接入新工具，把成功的轨迹存进记忆来影响下一次判断。这一步已经是现实。麻烦从紧接着开始：谁来判定这个「改进」真的是改进？就算新版本把账单类问题的准确率提上去了，它可能作为代价，悄悄把退款例外的处理弄坏了。更棘手的是智能体给自己打分的时候。它给自己一个「通过」，你分不清是能力上去了，还是它背下了打分标准，也就是奖励黑客。团队现在手上只有事后回放日志的可观测性工具。等东西坏了，才在仪表盘上发现。上线之前，没有一道门禁自动挡在部署前面问：这次自我改进到底该不该进生产？

为什么是现在

自我改进本身突然变得普及。从生产轨迹里挖失败样例、自动更新提示词的流水线，把成功轨迹累积进记忆的智能体框架，用强化学习打磨工具调用的循环，全都以开源形式涌出来。建造的一侧爆发了，控制的一侧却没动。DevOps 早就把金丝雀发布和自动回滚变成标准，智能体却没有对应物。代码回归靠测试能抓住；而「语气微妙地变得有攻击性」「只在某一类客户身上判断变差」这类能力回归，会直接穿过单元测试。再叠加监管，像 EU AI Act 对高风险系统提出的日志、人工监督、变更历史要求，智能体每一次自我变化，都要证明「什么变了、为什么变、怎么验证的」，压力越来越大。在中国大陆，BAT 和字节跳动把智能体推进金融、内容审核这些强监管场景时，第一个卡住的也是这个可追溯问题。建造变容易的速度和验证的速度之间的落差，那道缝就是市场。

怎么构建

核心动作是把自我改进当成代码部署来对待。智能体提出新版本时，不直接推上生产，而是让它过三道门。第一，held-out 门禁：隔离出一个智能体永远不能用于训练和自评的评测集，不让它看到打分标准，这样才能筛掉奖励黑客。第二，回归检测：把新版本和旧版本并排跑（shadow 或 A/B），按任务类型比较分数变化，一直算到统计显著性。总体均值上去了，但某个切片掉了，也能抓住。第三，eval-as-CI：把这套评测作为门禁嵌进开发者的流水线，没通过的自我改进自动被挡在晋升之外，回滚到上一个版本。把它定位成架在 Langfuse、Arize 这类可观测性工具之上的「判定、晋升、回滚」层，就能自然渗进那些已经在攒轨迹的团队。

flowchart LR
  A[Deployed Agent] --> B[Proposes Self-Improvement]
  B --> C{Held-out Eval Gate}
  C -->|Pass| D{Regression Check}
  C -->|Fail| E[Auto Rollback]
  D -->|Clean| F[Promote to Prod]
  D -->|Regression| E

成功条件

这东西一旦变成「又一个评测工具」就死了。跑离线基准的公司已经很多。要活下来，就得钉死在一个又窄又热的问题上：在生产环境里自我变化的智能体。差异点在于事前门禁和自动回滚，挡住部署的门，而不是事后去读的仪表盘。信任的核心是 held-out 集的完整性，所以证明评测集没有泄漏给智能体的那套机制，会成为产品的心脏。风险也很清楚：如果 LangChain、Langfuse 这类可观测性平台把这个功能吸收进去，市场就变窄。所以要先立住一条不绑死任何单一框架的横向标准，以及一个自动留下合规证据（什么变了、为什么变、怎么验证的）的合规角度。而且误报太多、连健康的改进也挡下，团队就直接把门关了。统计上的严谨和低误报率，就是生存线。