一个团队把AI放进新品审核，跑了大半年，得出一个反直觉的结论。想让Agent更能干，得先把它手里的一些决定收回去。

去年大模型能力上来之后，他们想把新品审核交给模型。做法是让模型挑出不符合新品标准的商品，挑出来做处理。每一类问题场景配一段规则，规则其实就是一小段提示词，写明要盯的商品有什么特征，内部把这套东西叫一个体检项。模型拿着体检项，把每天新发的商品逐个过一遍，判断它是不是一个badcase。

跑完之后，业务小二安排同学逐条标注，算出准确率。过线的留在线上，没过线的拉回来重改，改完再看下一轮。

这套流程跑了一个财年，上线的体检项不到10个。不是新品的问题只有这么多，是产出一个能上线的体检项，成本太高。

卡点有两个。头一个是新体检项从哪来。写规则其实是在做归纳，badcase攒得不够多，共性就浮不出来，而人同时能装下的样本就那么多。另一个是改了不一定有效。改之前得人工把几百条错误case一条条看完，归类、改提示词、再等一轮验证。有人花一下午改完，第二天回来一看，原来错的照旧，原来对的认不准了，这一轮活白干。

所以要自动化的不是多写几条规则，是发现、归纳和验证。人只留标注和上线决定。

PART 01

第一次全自主尝试：翻车了

最重的一环是自行迭代。用一个ReAct模型当大脑，把每个流程都做成工具，让它自己发现badcase、归纳新体检项、改规则、跑评测、做总结，无人值守地一轮轮变好。

当时整条链路只有一个环，发现和优化都在环上，判达标和做总结也在环上，每一步往哪走由模型自己决定。现在回头看，2026年上半年社区把这种形态叫做循环工程，而他们做的是最天真的那一版。

刚上线那阵子大家都挺乐观，觉得小二只要管标注，剩下的全交给这个环就行。然后翻车了。

翻车的头一类表现很典型，错题是修好了，可上线之后整体准确率反着往下掉几个点。打开它改出来的规则一看，手法一点不绕弯子，badcase里的商品标题被它拆成碎片抄进了规则文本，规则变成一张记住答案的清单，个别版本索性把某几个商品直接排除在外。在这批badcase上它百发百中，换一批商品立刻现形。

另一类出在评测集上。他们后来换成一份挑得很细的黄金评测集，每轮评测完先让它复盘错因再改。跑了几轮，老毛病又犯，它写出的提示词跟评测集里那批商品越贴越紧。几次都够不到目标之后，它练出来的是怎么把这张卷子做对，而不是把商品的共性总结出来。

最难处理的一处出在它给自己的总结上。他们让它复盘自己的改动，它每次都带着前几轮的记录回来，交一句优化已经完成。判定权不交出去，交到手上的东西就变味了，不是结论，是它的说法。

PART 02

翻车的根源：自我优化一定会「作弊」

为什么必然走到这一步。当时的评测只看那批出了问题的badcase，错题修好几成，这一版就算几分。等于把要追的目标整个交给了输入，它看得见的世界里只有做错的题，背下来就是最省力的解法，把规则真正写对反而更难。生成方案、跑评测、判达标又握在同一个主体手里，优化就会从修正业务规则滑向迎合评测样本。

古德哈特定律早就说过，一个指标一旦变成目标，它就不再是好指标。

过去这条定律只能算提醒，如今它可测量了。ICLR 2026有篇投稿专门量化了迭代式代码优化里的作弊行为，arXiv上有篇论文讲迭代自省时的自发作弊，说的是同一件事，自我改良的循环没有任何外部诱导，也会自己学会对付评分器。arXiv上那篇LLM评委自我偏好偏差的研究讲得更直接，自己批自己，批判会被原来的方案锚定。

PART 03

第一刀：把评测权从Agent手里收回来

第一刀落在评测上。老办法只看这批错判商品修好了多少，新办法要把另一半补上，一批没挑过的真实商品会不会被顺手弄坏，也得看。他们在提示词里叮嘱过一句别过拟合，没用，它手上只有badcase，这句叮嘱它没法验证。

于是一次评测手里跑两份东西。一边是这轮要解的错判商品，另一边从最近几个批次随手抽，凑成大约500条真实商品，大半是正常商品。

两份样本交叉出四个数。优化前后各测一次，得到两个差值。badcase集准确率的变化记成Δbad，衡量修复深度；近期商品集的增减记成Δpop，衡量附带伤害。一正一反两个检查能同时成立，前提是两边各算各的，样本不重叠。

两个差值各配一个阈值。修复这一侧，提升要超过20个百分点才认；伤害这一侧，退化压在1个百分点以内才算没事。这两个数由业务和工程一起拍，落在模型的上下文外面，它改不了，也覆盖不了判定。

四个数放进一张两行两列的格子，每个格子对应一个动作：

错题修好、正常商品没伤的放行

两边都没伤的判无效

两边都坏的判失败

最关键的处置在第四个：错题修得很好、却伤了正常商品的那一版，判为危险，直接拒掉，不当成没效果放一放。它比两边都坏更难防。两边都坏一眼看得出，而这一版放进只看badcase的报表里，漂亮得像一个成功案例。

PART 04

第二刀：把优化方向和调度从Agent手里收回来

判据挡得住进门的坏方案，挡不住它一路上慢慢跑偏。方案一版接一版，每版只动一点边角，指标纹丝不动，它每次都说照着上一版继续优化了。

定好不能动的业务靶心

先给优化定一个不许动的靶心。有个真实体检项叫“素材更新中”，指商品信息还没搭完，不具备面向消费者的完整决策信息，这种链接不具备真实可售卖能力。规则怎么写可以商量，但业务定义不能为了涨分被改成认某几个词。

比如一批符合这个定义的商品被放过了，有两条路可以走。一条路是把预售也算进命中范围，漏判可能找回一些，代价是那些展示、规格、价格、交付说明都齐全、能正常下单的预售商品被一起误伤。这一改，规则判的东西从信息搭没搭完，变成了用没用预售。哪怕Δ_bad涨上去，方向已经错了。另一条路是盯着链接的真实状态写规则，主图只有占位预告、商品本体还没露面的，跟信息齐全能下单的预售商品分开处理。方向对只说明这条路可以继续，候选还是得过双侧评测。

失败按病因分路由，不要只说一句不通过

然后是失败路由。以前评测没过，动作只有一个，下个周期重新生成一版。四象限本来已经给出了病因，修好错题却打坏正常商品的，和两边都坏的，成因完全不同，当时却走同一条路，诊断信息被压成一句“不通过”。病因是花钱算出来的，最后递到手上的只有一根体温计。

现在失败分四路走。过拟合归过拟合，错题没修好归错题没修好，规则形态作弊单独一路，还有一路是没修好也没打坏的无效。走哪条靠四项分析定，四项互相不看对方的上下文。错题的共性、被误杀商品的原因归类，这两项得把商品原文摊开给模型看。规则里有没有商品标题碎片、具体SKU、硬编码枚举，靠规则形态扫描；前几轮修好的有没有被这版打回去，靠历史评测记录比对，这两项只读规则文本和判定结果，正则加集合运算就够了，纯代码，零token。四项要是塞进同一个提示词，里头最讲规矩的两项会被满屏商品描述淹没，两份商品数据再一摞，上下文先撑爆。

起手选哪版，也交给代码来定

还有一件小事，藏着大决定。每一轮从哪份规则起手，一开始也让模型自己挑。可一版规则往往同时挂着好几处毛病，选哪版起手，就是在定这一轮先治哪一处。它排序看的是哪儿最容易涨分，不是哪儿最根本。捡回两条漏掉的badcase不难，删掉里头堆成山的硬编码就难了，删了Δ_bad会往下掉。这一步也收了回来，落成一个由代码算的取底函数。

经验要沉淀，不要只传给下一轮

还有一条容易被忽略，经验要沉下来。失败反馈只喂给紧接着的那一轮，写清这轮为什么没过，用完就扔；经验沉淀先存进库，下一轮改方案之前再取回来，把可选的动作一点点收窄。

写经验的活儿放在评测之后的复盘那一步，只有那一步同时看得到前后两组指标和四个格子的结果。出方案的那一方不许给自己的方案写评语存库，不然只是把自评挪了个地方。原始记录也不能原样跨周期倒进去，中间得走一层提炼，反复出现、有证据撑着的结论才留下，召回时再挑与本轮最相关的部分注入。原始记录里夹着很多只在那一轮成立的东西，比如商品类目的分布、聚类碰巧凑出的形状。拿它们当结论往下传，下一轮就是对着噪声下注。

PART 05

第三刀：把流程权限从Agent手里收回来

第三刀落在权限上。不达标的时候，账该记在谁头上，这是原来那个环最说不清的地方。一个体检项迭代若干轮还是不过，到底是它归纳错了，还是规则一直没调对。一个环里这件事没法算清，归因和优化绑在同一个失败上，你只看到一直不达标。而且它会主动送来一个解释，解释通常落在最好改的那一段上，改几句文字，总比承认这个体检项本来就不该存在要容易。

这里有个结论跟他们一开始的直觉相反。他们原以为更自主就是让一个Agent多担决策，实际是反的，担的决策越杂，真正能自己作主的空间越小。本来不该它拍板的事，最后都得写进提示词里托住。提示词越堆越长，它在该拿主意的地方反倒束手束脚。毛病出在把两种完全不是一路的活，塞给了同一个执行体。头一种要理解、要归纳、要判断，十次能对上九次；后一种是重试、调度、判定、编排，按规矩就该次次一样。两样装在一起，本该稳稳当当的那部分被拖到看运气的水平上，整套系统的稳定性就吊在最不稳的那一环。

所以切分的那把尺子很简单，看这件事的对错能不能写成代码。能写出来的归代码，写不出来的，才是模型的地盘。重试要不要继续、调度什么时候触发、方案要不要入库，判断对错的代码都写得出，全归代码。这批badcase的共通原因是什么，写不出校验代码，归模型。人管的是抽样给出真值、处理说不清的灰区，以及最后上不上线的责任。

落到实现上，流程控制被单独做成一层，调度、重试、判定、入库都由Java代码跑，模型只交候选，推不动状态。生命周期由代码管，单项失败不必让整批重来。一次生成1到4个候选，在保守、均衡、激进之间拉开差异，各测各的。评测异步跑，模型交完方案本次执行就结束，后端算完，下一次调度带结果回来。状态由代码读真实结果形成，模型拿不到最终结论，也就没法靠一句优化完成推下去。

一件事的优化常常要跨过好几个调度周期。这里说的重试，也不是让模型一口气跑完全程，是后端拎着状态和证据，把下一轮的生成和验证推起来。

PART 06

改完之后：两个前后咬合的环

改完之后，系统里留着两个环。一个管新体检项从哪来，出门要过三道硬门槛，召回率不低于0.95，准确率不低于95%，样本数大于0，三条一起成立才放行。召回率管别漏捉，准确率管别乱捉，样本数挡的是零样本的假信号。另一个优化已有体检项，进门就默认它成立，只对规则负责，代码掌握流程和达标判定，模型只管归因和出方案。

这两个环不是并排摆着的两张流程图，它们沿着业务时间线前后咬合。发现环过了门槛，新体检项先落到case池上线跑起来，线上攒下的case和badcase再喂给优化环。优化环里只有修好错题又没伤正常商品的那一版能出环，交运营确认后上线，结果再回流进case池。错题没修好的那类不着急重出，等下一周期回到归因；连着两轮没过，就退出自动回路，交回人工。

PART 07

真正不变的三件事

一路走下来，模型换过，编排换过，Agent合过也拆过。方向始终没动，凡是能写成代码去验的决策，一项项从模型手里回到控制面。社区给这类实践起过两个名字，先叫循环工程，后叫图工程，名字换来换去，真正管用的还是那三件事，谁产生候选，谁验证结果，谁对上线负责。

还有一句更值得记。先有判断好坏的评测基准，再有跑起来的Agent。基准没立起来的时候，Loop还是Graph、单Agent还是多Agent、接不接框架，这些争论连个能被证伪的靶子都没有，比到最后只是谁的直觉更响。基准立起来之后，这些问题反而松弛了，形状可以换，模型可以换，跑一遍评测就知道是亏是赚。

至于人，执行层未必以Human in the Loop收场，治理层大概会收在Human in the Control上。风险低、证据够的变更，系统完全可以自己在划定的圈里跑完，人用不着一件件签字。但责任跑不掉，人会从盯每一个答案，转到定什么叫正确、划系统能错多大，手里留着暂停、接管和回滚的权力。

能自动化掉的是逐次审批。剩下的是三件跑不掉的事，谁定义正确，谁划定边界，谁背最后的结果。

首发于公众号：AI驱动数字化转型