评估怎样驱动灰度、回滚与组织学习
一句话收获：持续改进是受控实验，不是 Agent 自行改写自己。
这个场景在解决什么问题
改进了 Agent、修复了 bug 之后，能不能直接上线？改进不是"改完就上线"那么简单，而是一个"受控实验"：从离线验证，到影子/灰度，到独立 Gate 把关，最后才沉淀成组织经验。
这个场景的目标（goal）是：展示候选修改从离线验证到正式沉淀。观察点（observation）是：一次改进经过回归、影子、灰度、准入或回滚——一个候选修改要一路过关，才能正式沉淀，否则就回滚。
它值得单独学，因为它点破一个危险倾向：持续改进是受控实验，不是 Agent 自行改写自己——不能让 Agent 自己改自己、自己放行自己，必须有一整套外部机制把关。
先理清这条判断链（文字版）
一次改进从"离线"到"沉淀"是一条受控链，先回归、再试跑、再过闸、最后归档：
- 先看运行回归集——正常、边界、异常、攻击、恢复任务同时跑，红线任务有否决权，不能因修复当前失败破坏已有边界。
- 再看影子与灰度——候选先只生成建议，再在低风险范围逐步执行，记录结果、过程和风险。
- 然后看独立 Gate——候选不能改冻结任务、验收器和自身准入规则，失败时回滚并保留证据。
- 最后看沉淀到正确载体——事实进知识、方法进 Skill、边界进程序、失败进回归集，经复用和回归后再正式沉淀。
逐层详解
第 1 步：运行回归集
原文：正常、边界、异常、攻击和恢复任务同时执行。
白话：改完一个东西，不能只测"刚才那个失败任务现在过了没"，要同时跑一整套回归集：正常任务、边界任务、异常任务、攻击任务、恢复任务，全都跑一遍。
类比：像改了一个零件，不能只测"这个零件装上了没"，要把整台机器重新过一遍全套质检——正常工况、极端工况、故障工况、安全测试、重启恢复，全过才行。
举例：修了订单 ID 映射后，回归集全跑：正常订单、边界订单（空值/超长）、异常（文件损坏）、攻击（注入）、恢复（中断后重启续跑），确认修了旧 bug 的同时没破坏别的。
为什么重要：修复当前失败不能破坏已有边界。修一个 bug 很容易"按下葫芦浮起瓢"，把别的边界搞坏，所以修复必须用完整回归集来确认"旧的没退化"。
怎么验证（证据点）：
- 目标任务改善：要修的那个任务确实改善了。
- 保护任务未退化：已有的保护性任务没有退化。
- 成本可接受：改动带来的成本（时间、资源）在可接受范围。
别踩的坑（边界）：总分提高可能隐藏红线失败。回归总分上去了，可能只是"普通题分高了"，但某条红线任务（绝对不能失败的）其实失败了——总分会掩盖红线失败。
落地检查：红线任务具有否决权。落地时红线任务要设成"一票否决"，红线失败则整体不通过，不管总分多高。
第 2 步：影子与灰度
原文：候选先只生成建议，再在低风险范围逐步执行。
白话：候选修改先做"影子模式"——只生成建议、不真正执行，跟线上基线并排跑、比一比；确认靠谱了，再"灰度"——在低风险的小范围里逐步放开执行。
类比：像新员工先"跟岗"（只提建议、不动手），看建议靠不靠谱，再让他"试岗"（小范围、低风险地实际做几单），逐步放权。
举例：候选修改先以影子模式跑，只产出"如果是它，会这么处理"的建议，与线上基线对比；结果不错，再灰度到 5% 的低风险订单上实际执行，观察真实表现，再逐步放大。
为什么重要：真实分布可能不同于离线任务。离线测试的数据分布，跟线上真实流量不一样，候选在离线测得好，不代表线上就好，所以要先影子、再灰度，用真实分布验证。
怎么验证（证据点）：
- 基线并存：候选和线上基线同时跑、可对比。
- 候选可比较：候选的结果能与基线对齐比较。
- 影响范围受控：灰度范围是受控的、逐步放大的。
别踩的坑（边界）：用户主观反馈不能替代外部状态。灰度时用户说"感觉不错"这种主观反馈，不能替代"外部系统状态到底对不对"的客观验证——主观好评不等于业务正确。
落地检查：同时记录结果、过程和风险。落地时灰度阶段要同时记录三样：结果（对不对）、过程（怎么做的）、风险（出没出问题），缺一不可。
第 3 步：独立 Gate
原文：候选不能修改冻结任务、验收器和自身准入规则。
白话：候选改进能不能上线，要过一道"独立的 Gate"（闸门/门禁）。关键是：这个候选本身不能去改"冻结的测试任务""验收器""自己的准入规则"——不能既当运动员又当裁判。
类比：像考试不能由考生自己出题、自己判卷、自己定及格线，这三样必须独立，否则他怎么都能"考过"。
举例：候选改进上线前，过独立 Gate：它不能修改用于评估它的冻结任务集、不能修改验收器逻辑、不能修改"它自己能否准入"的规则。这三样由独立的机制/人掌握，候选只能被评估、不能改评估标准。
为什么重要：执行链不能通过降低标准证明自己进步。如果让 Agent 一边改自己、一边又改验收标准，那它完全可以通过"把标准改低"来假装进步——所以评估标准必须独立于被评估对象。
怎么验证（证据点）：
- 基线冻结：用于评估的基线任务是冻结的。
- 验证器独立：验收器/验证器独立于候选。
- 权限独立：候选没有修改评估标准/准入规则的权限。
别踩的坑（边界）：Agent 能生成修改不等于有权发布。Agent 能写出修改代码，不代表它有权把这个修改发布上线——"会写"和"有权发"是两回事，发布权限必须独立。
落地检查：失败时回滚并保留证据。落地时过了 Gate 上线，如果后面失败，要能回滚到旧版本，并且保留这次失败的证据供复盘。
第 4 步：沉淀到正确载体
原文：事实进入知识，方法进入 Skill，边界进入程序，失败进入回归集。
白话：改进成功后，经验要"沉淀"到正确的载体里——不同类型的东西放不同地方：事实放知识库、方法放 Skill、边界规则写进程序、失败案例放进回归集。
类比：像公司复盘，不是把所有经验都写进同一本手册，而是分类归档：业务数据进数据库、工作方法进 SOP（标准流程）、红线规定写进制度、失败案例进培训案例库。
举例：这次"订单 ID 映射"的改进沉淀：订单 ID 的正确取法作为"方法"沉淀进 Skill；"ID 必须从上下文取"这条边界规则写进程序校验；"ID 映射错误导致订单状态不符"这个失败案例加进回归集，防止复发。
为什么重要：组织学习不是把所有经验写进 System Prompt。很多人一有经验就往 System Prompt 里塞，导致 Prompt 越来越臃肿。正确做法是分类沉淀到对应载体，而不是全塞进提示词。
怎么验证（证据点）：
- 载体匹配：经验放对了载体（事实/方法/边界/失败各归其位）。
- 版本明确：沉淀的内容有版本号。
- 责任人明确：每条沉淀有明确的责任人。
别踩的坑（边界）：一次成功修复不自动成为组织标准。这次修复成功了，不代表它就该自动变成"组织标准"——一次成功可能只是运气/个例，要经过复用验证才能转正。
落地检查：经过复用和回归后再正式沉淀。落地时经验先以"候选"形式沉淀，经过多次复用、回归验证后，才正式转成组织标准。
落地可行性小结
本场景涉及的核心技术栈：回归集（回归测试）、红线任务（一票否决）、影子模式（shadow）、灰度发布（gradual rollout）、独立 Gate（门禁）、回滚（rollback）、知识/Skill/程序/回归集四类载体。
真实落地要检查的事：
- 回归集要覆盖正常/边界/异常/攻击/恢复，红线任务一票否决。
- 改进先影子（只建议不执行）再灰度（低风险小范围逐步执行），记录结果+过程+风险。
- 独立 Gate 保证候选不能改冻结任务、验收器、自身准入规则，失败能回滚留证据。
- 经验分类沉淀：事实进知识、方法进 Skill、边界进程序、失败进回归集，经复用回归后再转正。
常见坑：
- 只测当前失败任务，没跑完整回归集，修好一个、坏掉一片。
- 只看总分，忽略红线失败。
- 用用户主观好评替代外部状态验证。
- 让 Agent 自己改自己、自己改准入规则，自己给自己放行。
- 把所有经验塞进 System Prompt，导致 Prompt 臃肿难维护。
回顾
- 持续改进是受控实验，不是 Agent 自行改写自己、自行放行自己。
- 修复要过完整回归集，红线任务一票否决，不能因修一个 bug 破坏边界。
- 上线前先影子（只建议）再灰度（低风险逐步执行），用真实分布验证。
- 独立 Gate 保证候选不能改评估标准，失败能回滚并留证据。
- 经验分类沉淀：事实→知识、方法→Skill、边界→程序、失败→回归集，经复用回归后转正。