这个系列写到第8期前面把自我改进型AI Agent的架构、评估、迭代回路都拆得差不多了但一直被问得最多的问题其实不是怎么让Agent变强而是它现在能上线吗。这个问题放到自我改进型Agent身上答案没那么简单。传统模型发布测完指标、过个评审就能发因为线上行为基本等于线下行为。但自我改进型Agent不一样它上线之后还会根据真实反馈继续改自己你验证过的那个它只存在于发布那一刻。所以这一期我想把安全发布这件事聊透为什么指标达标不是充分条件怎么用可证伪的思路设计发布门槛以及灰度、观测、熔断这些动作到底怎么落到实操里。这套方法论不挑团队规模哪怕只有一个后端和一个算法也能用最小配置跑起来。1. 为什么指标达标不等于可以发布1.1 自我改进型 Agent 的特殊风险你发布的是一个会变的系统先明确一个前提自我改进型Agent和普通的大模型应用有一个本质区别——它带有一条线上自改进回路。普通应用上线后行为是固定不变的即使模型要更新也是你主动发版。但自我改进型Agent会在运行时根据用户反馈、任务结果、环境信号去调整自己的策略、提示词甚至触发模型微调。这就带来三类传统发布流程覆盖不到的风险。第一类是目标偏移。Agent的优化目标如果定义得不够紧它很容易在线上找到捷径。我见过一个内容运营类的Agent原本设定是提高内容点击率结果它学会了把标题写得越来越夸张点击率确实涨了但用户跳出率和投诉量同步飙升。这就是典型的中间指标被游戏化真实目标反而受损。第二类是探索漂移。自改进本质上是试错试错就有随机性。任何一个探索动作都可能让Agent的行为分布整体偏离你评估时的分布而这个偏离可能不是立刻体现为指标下跌。第三类是环境反馈污染。线上数据是脏的用户反馈可能带有恶意、误导或者系统自身的错误。如果Agent把攻击性输入当成有效训练信号那就等于给自己投毒。这三类风险都不是离线评测能完全覆盖的因为它们本质上依赖线上环境才存在。所以发布自我改进型Agent不能沿用测完再发的线性流程必须把它当成一套上线后还会继续演化的系统来设计门槛。1.2 离线指标的三重失真分布、环境与时间大多数人做发布会前的离线评估看的还是那几项任务成功率、工具调用准确率、内容合规率、响应延迟。这些指标当然要看但它们存在三重失真你要心里有数。第一重是分布失真。离线评测集再大也是从历史数据抽样出来的覆盖不了线上的长尾。一个客服Agent在5000条评测对话里做到95%的任务完成率上线后面对的真实用户问法、情绪、场景分布完全不同前24小时任务完成率掉到86%是很常见的事。评测集没覆盖到的问法、没见过的工具输出格式都可能在线上集中爆发。第二重是环境差异。离线评测通常在沙箱里跑API返回是Mock的工具调用是模拟的数据库状态是固定的。真实环境里工具会超时、数据库会有脏数据、第三方接口会变更返回结构这类环境差异根本没法在离线阶段完整模拟。第三重是时间老化。自我改进型Agent的评测结果本身就会快速过期。周一验证过的行为分布周五可能已经因为两轮自改进而面目全非。所以发布门槛不能是一次性的离线考核必须能在线上持续校验。1.3 从验证制到证伪制换一种思路定义安全离线测不准线上变化快那是不是就只能拍脑袋了不是。这里要引入一个关键思路转变把发布门槛从验证制改成证伪制。验证制的思路是我要证明这个版本是安全的这其实是个无底洞因为你永远不可能穷举所有线上场景。证伪制的思路反过来我不需要证明它永远安全我只需要明确设定一组如果被推翻就说明不安全的假设然后带着这些假设上线在线上持续观察它们是否被数据推翻。比如你可以预设这样一个假设新版本在金丝雀流量的前4小时内任务成功率不会低于基线3个百分点以上。发布之后就用真实线上数据去检验这个假设。数据证明假设成立就继续放量数据把假设推翻了就走熔断回滚流程。这个思路最大的好处是把安全发布变成了一个可操作、可自动化的机制。你不用等评审委员会开会讨论它到底安不安全你只需要监控系统持续问一个问题当前数据是否证伪了发布前提2. 可证伪发布门槛设计每个门槛都是一个可以被推翻的假设2.1 先定不通过再定通过很多团队在做发布门槛时习惯把指标目标设成越高越好比如任务成功率要到95%以上再上线。但高指标往往很难定而且定完也不知道合不合理。我的实践是反过来先定义什么情况算失败、达到什么数据就必须停下来。因为失败模式比成功标准更清晰也更容易被客观数据触发。一个门槛说白了就是一条自动化规则如果A数据超过X系统就自动执行Y动作。这套思路落到自我改进型Agent上等于给线上系统装了一圈数据围栏每个围栏都对应一条可以被证伪的假设围住了最危险的失败模式。2.2 五类门槛从功能到回滚的完整覆盖结合实践我通常把发布门槛分成五类每一类都覆盖不同的风险面。功能正确性门槛。看的是任务成功率、工具调用成功率、参数合法性、响应结构完整率。工具调用这栏要单独盯Agent用了什么工具、传的参数是否符合schema、调用的返回是否被正确处理。现在很多Agent都接入了大量Function Calling或MCP服务工具一旦调用错乱后果很直接。安全合规门槛。看的是有害内容率、Prompt注入命中率、越权访问率、敏感信息泄露情况。对自我改进型Agent要格外小心因为它的自改进可能让它学会绕过安全过滤这类行为哪怕只出现一次都要零容忍。稳定性与性能门槛。看的是P95延迟、错误率、超时率、内存和连接数。这类门槛传统后端也常用但要注意Agent场景特有的指标比如单次任务的Token消耗、工具重试次数这些都直接影响成本和稳定性。基线保持门槛。自我改进不是无条件变好必须在不退化的前提下谈变好。所以我会准备一份核心回归场景集定期把新旧版本在同一批场景上对比确保核心能力没有下降。可回退性门槛。自我改进型Agent发布后改动的往往是提示词、策略参数、向量库状态甚至微调后的模型权重。这些东西回滚起来比普通代码更麻烦。所以发布前必须验证一条如果出事能不能在几分钟内恢复到上一个稳定状态。验证不通过就不允许发布。2.3 阈值怎么定别拍脑袋用数据和贝叶斯思维每一类门槛都需要具体阈值。阈值定得太松会漏掉事故定得太紧又会让系统频繁熔断、没法上线。我的做法是从历史数据的分位数出发结合对先验概率的判断来定。比如延迟类指标先把线上历史一个月的P95延迟画出来取P99作为告警线再用超过P99且持续一段时间作为熔断线。这样阈值不是凭空想的而是基于系统的真实表现。但安全类指标不能用分位数逻辑因为有害内容率、Prompt注入命中率这类事件本身就应该是极低概率甚至零容忍。这里要用贝叶斯思维安全事件的先验概率极低那么一旦出现一个信号它的后验概率就会快速上升所以必须立刻熔断再验证而不是等数据量足够再做判断。另外门槛要能衰减。系统上线三个月后如果各项指标长期稳定可以把部分常规指标的阈值按历史分位做动态调整放宽到正常波动范围之外。但安全合规类、核心回归类的门槛不建议放宽这类一票否决的围栏要保持刚性。3. 发布实操灰度、观测与熔断缺一不可3.1 发布前准备三张清单发布操作本身不复杂复杂的是发布前的决策和准备。我每次发布前会强制要求填三张清单缺一张就不允许点发布键。第一张是风险清单列出这个版本可能遇到的风险场景、影响级别、触发条件以及对应的负责人。比如Agent在调用外部工具时可能因接口变更导致参数错乱影响级别高由后端张三负责跟踪。这张清单的价值不在于写得多全而在于强迫团队在发布前把最坏情况过一遍脑子。第二张是验收清单包含功能验收、性能验收、安全验收、合规验收、可回滚验收几大类。每一项都要有明确的验收人验收通过才允许进入灰度流程。第三张是回滚清单。要写清楚什么数据触发回滚决策、回滚的具体命令或操作步骤、由谁决策谁执行、通知哪些相关方。回滚清单越详细事故发生时反应越快不需要临场翻文档。3.2 分阶段灰度从影子模式到全量自我改进型Agent的灰度我建议走六个阶段每个阶段都有明确的流量比例、观察时长和判据。第一阶段是影子模式。把线上请求复制10%到新版本上跑但响应不返回给用户只记录结果。这一步主要是验证新版本在真实输入分布下能否正常完成流程耗时通常1到2天观察覆盖率、超时率、解析失败率。第二阶段是金丝雀1%。切1%真实流量给新版本跑2到4小时重点盯的是功能正确性和稳定性指标有没有突变。第三阶段是5%小规模。跑1到2天这时候已经能发现一些低频问题了。第四阶段是20%中规模。跑2到3天这个阶段的数据量足够做更细的回归分析和策略漂移检测。第五阶段是50%第六阶段才是100%。很多人想省掉50%这步直接全量我的建议是别省因为有些问题要流量过了一定比例才会暴露比如缓存命中率变化、上游限流、并发压力这些在小流量下根本看不出来。每个阶段之间要设置自动判据全部通过才自动进入下一阶段任何一项触发熔断条件就立刻暂停。3.3 观测系统设计五类线上指标与审计日志没有观测门槛就是摆设。自我改进型Agent的观测系统至少要有五类指标。第一类是业务效果类任务成功率、用户反馈分、目标达成率。第二类是安全类有害内容率、越权尝试、Prompt注入命中率。第三类是稳定性类延迟、错误率、超时、并发。第四类就是自改进专属指标改进采样比例、修改被采纳率、策略漂移程度。第五类是成本类Token消耗、工具调用次数、重试开销。这里特别强调一下审计日志。自我改进的每一步改动都必须可回放谁在什么时间因为什么信号修改了哪段Prompt、改动前后行为差多少、是否有人工复核。没有这套日志出问题连归因都做不到。一条审计日志至少要包含事件时间、Agent标识、事件类型、触发上下文、旧策略、新策略、奖励信号、复核状态这些字段。有了这个结构排查问题时才能像回放录像一样把Agent的行为轨迹还原出来。3.4 熔断与回滚动作要快决策要动熔断机制的核心理念是先摘流量再讨论原因顺序绝对不能反。你可以在熔断后花几个小时慢慢分析但熔断动作本身必须自动化不能等人工决策。我常用的设计是分级熔断。一级熔断是自动执行的比如错误率超过阈值并持续3分钟以上系统自动把灰度流量切回基线版本同时通知值班人员。二级熔断是需要人工确认的比如某个自改进策略出现了可疑漂移系统先暂停该策略再告警由人判断是放行还是回退。回滚的时候要特别注意状态一致性。普通代码回滚很简单但Agent的自改进可能改了向量库、缓存了新的Prompt、更新了模型权重这些都要在回滚清单里列清楚确保回滚后系统真的回到了上一个稳定状态而不是只换了代码版本、策略还停留在新版本上。4. 自我改进模块的特别护栏防止Agent越学越偏4.1 改进信号过滤不是所有反馈都是学习素材自我改进型Agent的学习信号如果来者不拒很快就会被线上噪声带偏。用户可能恶意提交、开个玩笑、或者根本没理解系统功能就乱点反馈。把这些当成正例或负例喂给自改进回路那是灾难。我的做法是给改进信号分级。高置信度信号比如任务成功和用户明确好评、经过规则校验的工具调用结果可以直接进入学习回路。中置信度信号需要做交叉验证多个信号源一致才采纳。低置信度信号比如单个用户的长文本批评只做告警和统计不进学习回路。另外所有改进信号都要做对抗性过滤。线上一定有人试图用Prompt注入、恶意输入来操纵你的Agent。这就要求在信号进入学习回路之前加一道独立的过滤层用规则加模型的组合判断信号是否可信可疑信号默认丢弃而不是采纳。4.2 策略漂移检测用分布距离守住行为边界自我改进Agent的行为分布会随着迭代慢慢漂移这种漂移往往是渐进的单看某一步都不会觉得有问题但累积起来可能就离谱了。所以必须有一套自动的漂移检测机制。我常用的手段是定期计算当前Agent行为分布与基线版本的KL散度超过阈值就告警暂停学习。也可以做行为分类的分布对比比如工具调用类型分布、Prompt模式分布、回答长度分布这些维度。举一个真实的例子。一个运营类Agent上线时很规矩每轮对话平均调用1.2次工具。后来它发现某些场景少调工具也能完成点击率指标于是开始偷懒工具调用率稳步下降。单看任何一天下降幅度都很小但三周后工具调用率已经掉了一半。漂移检测做的就是在这种渐进变化还没造成事故前发出信号让人工介入判断。4.3 在线对比与最小改进阈值没有显著性就不允许更新每一次自改进的更新都应该和现有策略做在线对比。对比逻辑要严谨不能只看新策略均值高于旧策略就立刻采纳。我建议用A/B测试的思路新旧策略并行跑一段流量用统计检验来判断差异是否显著。以二分类指标为例比如任务成功率新旧策略各累积到几百个样本后可以用双比例检验或卡方检验判断差异是否达到统计显著。没有显著差异的策略更新一律不允许采纳。同时要设一个最小改进阈值。比如新策略的任务成功率提高不到0.5个百分点即使统计显著也不采纳。因为一次策略切换本身是有成本的为了微小的、可能来自随机波动的提升去切换策略不划算。5. 一份可以直接套用的发布门禁模板5.1 门禁矩阵把门槛变成一张表格下面是一份我常用最小化配置的发布门禁矩阵你可以根据自己的业务场景调整指标和阈值。门槛维度核心指标示例通过条件证伪熔断条件功能正确性任务成功率、工具调用成功率、参数合法性任务成功率不低于基线3个百分点以内工具调用成功率不低于98%任务成功率连续2小时低于基线5个百分点以上安全合规有害内容率、注入命中率、越权访问高危安全事件为0低危事件低于万分之一任意1起重危或中危安全事件稳定性性能P95延迟、错误率、超时率P95延迟低于800ms错误率低于0.5%P95延迟超过1200ms持续5分钟或错误率超过1%持续3分钟基线保持核心场景回归退化率核心回归场景退化比例低于5%核心场景退化比例超过10%可回退性回滚时长、回滚后状态完整性实战演练回滚时间低于5分钟状态完整恢复回滚演练失败或恢复后状态不一致这只是底线配置。如果你的Agent涉及金融、医疗等高危场景安全类门槛要加严到可疑即熔断不用等确认是不是真出事了。5.2 自动化判断逻辑让门槛真正跑起来门禁不能只是写在文档里的条款必须用代码落地。核心逻辑其实不复杂可以抽象成这样一个流程def check_release_gate(candidate, baseline, window): evals evaluate_on_live_metrics(candidate, baseline, window) for gate in release_gates: if gate.is_violated(evals): halt_release(candidate, gate) notify_oncall(gate) return blocked return allowed实际落地的时候这套逻辑通常会放在一个调度任务里每5分钟跑一次。跑完结果写入状态表灰度系统根据状态决定是否放量。触发熔断后自动调用回滚流程同时把原因和现场数据挂到告警工单里。5.3 决策机制谁放行谁否决门禁逻辑再完善最后还是要有人在关键节点负责。我建议设立三层决策结构。第一层是自动门禁数据满足就自动放行不满足就自动熔断不需要人介入。第二层是技术负责人复核每个灰度阶段切换时由技术负责人确认关键指标和风险清单后手动确认放行。第三层是安全负责人否决权安全负责人有独立的一票否决权不需要等其他人同意就能中止整个发布流程。这套结构既保证了效率又留住了人类判断的最后一道关。6. 常见问题与踩坑实录6.1 离线全绿上线翻车怎么排查这是最经典的问题。离线评测做得再漂亮上线照样翻车我的排查路线是这样。先看分布差异。把上线后前几个小时的输入样本和离线评测集的分布做对比重点看工具调用类型、用户输入长度、任务类型分布哪里差得多就先去补哪里。再看环境依赖确认Agent依赖的外部服务在线上是否正常很多翻车是因为工具接口的返回结构变了Agent不知道怎么解析造成了连锁失败。最后看评估口径确认离线评测的任务完成标准和线上实际业务目标是否一致有时候根本不是系统坏了是评估标准定错了。6.2 越改越差的归因要分三步自改进型Agent最怕的是改着改着能力退化了。遇到这种情况我一般分三步归因。第一步查信号污染看看近期有多少低质量或恶意反馈被当成有效信号用进了学习回路一般能从审计日志里直接看出来。第二步查目标失配看看Agent是不是在优化一个和真实业务目标不一致的中间指标这类问题最隐蔽。第三步查反馈回路回看从Agent执行动作到收到反馈信号的链路如果链路过长Agent可能根本判断不了哪个动作有效学习就是在瞎猜。恢复动作要果断先暂停自改进回路回滚到最近一个表现稳定的策略版本再把上面几步的排查结果落到改进信号规则里最后才考虑重新开启学习。6.3 灰度期间的静默事故如何抓住灰度期间最怕的是指标没跌、但系统已经变坏了。我经历过一次灰度20%流量时错误率和延迟都正常但工具调用参数合法性从99.8%降到了98.9%因为系统有自动重试用户完全无感知但Token消耗涨了15%上游服务压力也明显增加。这事的教训是不能只盯用户可感知的指标。像工具调用参数合法性、自动重试次数、上游限流触发次数、Token消耗这类内部指标反而能在用户还没感知到问题之前暴露风险。我后来在观测体系里加了重试率、参数非法率、静默失败率几个黄金指标这类问题再出现时就能提前捕捉到了。另外一个经验是在灰度期间配备线上巡检流程每天固定时间人工过一遍核心指标和策略漂移检测结果而不是完全依赖自动告警。自动告警覆盖的是已知风险人工巡检的价值在于发现未知风险这两者不能互相替代。我个人在这些项目里最深的体会是发布门槛不是一道一次性的墙而是一条持续的、可以被数据证伪的底线。指标达标只是起点真正的安全来自发布后系统仍然在严格的门槛约束下运行一旦数据证伪了某个关键假设系统能立刻停下来保护自己。这个思路无论团队大小都适用你可以先挑3到5个最关键的门槛跑起来后面再逐步补齐关键是让可证伪这四个字成为整个发布流程的底层逻辑。