把「达标判定」从大模型手里收回来：Graph Engineering 实践

这是2026年的第 61 篇文章

（ 本文阅读时间：约 30 分钟 ）

前言： 

先能管控验收，再谈自主迭代

最近这半年，AI 圈里的新词比能落地的系统还多；Loop Engineering 才刚出现，Graph Engineering 又火了一轮。

巧的是，我们团队的 AI 体检 Agent 演进的过程，几乎就是这两个词出现的先后过程：我们先认定了「让 AI 自己迭代自己」的方向，并给 Agent 较大的流程自主性：它可以自主调优 prompt、自主循环评测，也可以决定下一步往哪里走。最后踩了无数坑之后，我们并没有放弃 Loop，而是把可被代码验证的确定性决策权逐项从模型侧收回，只把语义理解、归因和方案生成留给模型。

因此，你可以把这篇文章当成一份从「Loop Engineering」走到「Graph Engineering」的“踩坑”探索实践。我们会看到：Agent 的单指标自我优化是怎么一步步走向过拟合甚至作弊的、一套让模型骗不过去的评测底座该怎么建、以及哪些权力必须从模型手里收回给工程。

当然要先说明一点：我们认为所谓的 Graph Engineering，重点不在于把 Loop 画成 LangGraph 那样的「点—边」结构，在于让整个 Agent 重新回答三个问题：谁产生候选、谁验证结果、谁对上线负责。后文的评测、失败路由、经验沉淀和多 Loop 拆分，都是这三个问题的工程化答案。

我们始终认可「让 AI 迭代自己」的思路：问题从来不是有没有 Loop，而是这个 Loop 处于什么样的工程管控之下。

去年，随着大模型能力的逐渐成熟，我们团队也在尝试将 新品业务 和 AI 结合，通过 Agent 来识别出不符合新品标准的商品，并给予去劣。

而每种 badcase 所归纳的场景，我们分别用不同的「体检项」来统称，每个体检项都有它所对应的规则（其实就是一小段 prompt，告知大模型要捉虫的商品有什么特征），然后让大模型基于体检项和规则，对每日的新发商品进行判断，判断它是否是我们所认定的「新品 badcase」。

结果跑出来后，业务小二会安排专门的同学对捉虫的结果进行标注，回收标注结果后就能得到每个体检项的准确率。高准确率的上线，低的去找原因、改规则、再等一轮产出。

靠着这套流程，上个财年一共落地上线了不到10个体检项：不是新品的问题就只有这么一点，关键在于产出一条能够落地的体检项的成本太高。

上个财年的运营流程是这样的：小二在新品池里发现 badcase → 小二定义体检项和规则prompt → 大模型离线产出捉虫结果 → 小二进行标注 → 小二分析模型错误的原因 → 修改体检项规则直到准确率达标。

这条链路光看一遍就有点力竭了，业务同学天天走一遍更累。这条链路上有两个具体的核心卡点：

• 第一个问题是小二很难提出新的体检项。 提规则本质上是一个归纳任务，要先看过足够多的新品badcase，才能总结出它们的共性。人的归纳带宽就是瓶颈。

• 第二个问题是小二对于体检项的修改不一定有效。我们前面说了「体检项」本质就是一类问题场景和它所对应的prompt，小二首先得纯人工一条一条的看完所有模型的错误case，然后归类、改 prompt、再等一轮离线产出标注验证，还不一定能让模型理解我们的要求。

试想一下，如果你是业务小二，你花了一个下午的时间，对某个体检项近几百条的 badcase 一个一个看完，然后高高兴兴的修改后，第二天来一看模型不仅没有把错误的 case 修复好，反而原先正确的 case 都识别不清楚了，那么一定是相当的崩溃的，这意味着这一轮活都得重新开始。

所以在这个业务里，AI 要解决的核心问题不是「多写几条规则」，而要把发现、归纳和验证这三件事自动化，人只保留对产出结果的「标注」以及最后的「上线决策」。

于是，我们给出的优化方案是：AI 主动发现 → 小二标注校准 → AI 自行迭代 → AI 多轮评测 → AI 持续观察 → 小二决策是否上线。

在上文我们所阐述的方案里，很重要的一个点为「AI自行迭代」，所以在今年 5、6 月份的时候，我们在体检项上先走了一条最省事的路来实现所谓「自迭代」的能力，也就是用一个 ReAct 模型当大脑，把所有流程都做成 tool，让 Agent 自己发现新品 badcase，用 badcase 发现新体检项，然后让它自己改规则 prompt、自己评测验证、自己总结问题、自动循环优化，无人值守地变好。

那时的整条链路只有一个闭环，让Agent自由去发现体检项和优化体检项，跑评测、判达标、做总结都在一个环上，每一步下一步去哪都由模型自己决定，直到最终产出合格的结果给我们。

现在回头看，它就是社区所说的 Loop Engineering 形态：

设计时的理想很美好——小二只管标注，剩下全交给一个自我迭代的 Loop，完美的数据飞轮。但是，我们翻车了。

这版 Loop 很快就完成了问题的发现和体检项的优化，但是验收数据的时候，只看到了一地鸡毛，遇到的问题大致如下：

• 大部分优化循环都是同一个模式：badcase 修好了，上线后整体准确率反而掉几个点。翻开模型改出来的规则一看：作弊手段相当直白，它把 badcase 里的商品标题拆碎了直接贴进规则文本。规则退化成一张已知样本的查找表，甚至直接指名道姓的排除了某些商品，在这批 badcase 上百发百中，换一批商品立刻原形毕露。

• 我们又试过给它一份精心挑选的黄金评测集，每轮评测后让它分析错误原因再优化。几轮之后同样的事情发生了：它优化出来的 prompt 越来越贴近评测集里那些商品。多次重试达不成目标的时候，它学会的是怎么应付这套题，而不是怎么总结商品的共性，把规则写对。

• 最难处理的问题是自我总结流程。我们让它评估自己改得怎么样、分析自己错在哪，它每一轮总结时，拿着之前那些上下文，都告诉你"已完成优化"。只要判定还在模型手里，你拿到的就不是评测结论，而是一份自我陈述。

上一次 Loop 翻车后，我们得到了几条教训，后面整篇文章都是这三条的工程展开。

• 一是如果只给 badcase、只看 badcase 的评测指标，模型一定会用过拟合把指标做漂亮。这不是模型能力问题，是目标函数被输入单方面决定了。

• 二是“改得好不好”和“往哪里改”这两件事都不能全都留给生成者自己回答——判定要交给模型碰不到的环节，反思要交给另一个 Agent。如果生成方案和反思失败原因是同一个 Agent，它的总结永远是"再微调一下上一版"，而不是"这个方向本身就错了"。自己批自己，批判会被自己的原方案锚定。

• 三是自主权必须逐项分配，不能整包批发。“让 Agent 完全自主发挥”听起来先进，实际结果是应试而不是进化，出了问题想要追溯，也永远追溯不到原因。

接下来就讲一讲我们分别都是如何解决这几个问题的。

这几个问题的顺序是有讲究的：评测在最前面，因为它是其余问题解法的地基；判据不立，后面的自主权给多给少都无从谈起。

问题1：在评测上如何避免 AI 作弊？

第一个问题，我们想让 Agent 自己优化自己，很重要的一环就是能够客观地告诉 AI，如何评估它给出的优化方案是好是坏。

诱因：循环优化为什么会走向作弊

之前 Agent 在自己优化自己的时候，我们只评测了「发生问题的这部分 badcase」，这批错判的商品修好了几成，就是这一版方案的分数。AI 判命中、人工判未命中的那些商品，也就是误判、误伤。然后我们把 badcase 喂给 Loop 让其优化后，实际上是把目标函数整包交给了输入：模型看到的世界里只有做错的题，它最省力的解法当然是把这批样本背下来，把规则写对要难得多。翻车那一版把所有的商品标题贴进规则文本，与其说模型学坏了，不如说它精确地命中了我们给的目标。

问题在于同一个主体同时拥有生成权、评测权和达标判定权，当目标函数只观察固定样本时，循环优化很容易从“修正业务规则”滑向“迎合评测样本”。

这件事早就有名字，那就是Goodhart 定律：当一个指标变成目标，它就不再是个好指标。它最近在 Agent 圈被重新翻出来讨论。新系统里这个冲动依然存在，区别在于现在它可测量：6 月我们是事后人工对比才发现的，而现在，同样的方案在评测阶段就会被判成不合格。

所以，如果拿着一份考卷作为目标让 AI 不断优化，不用多久它就会把它变成一份作弊集。

因此，Loop 翻车是因为生成者与评判者没有分离，后续改造的第一步是要建立模型碰不到的客观独立的评测机制。

判据：两份样本、两个阈值、四个象限

所以新判据的第一件事，是给评测补上原来缺的那半边：不只看这批错判商品修好了多少，也看一批没挑过的真实商品会不会被顺手弄坏。这半边只能补在样本里，补不进提示词——我们在生成方案的提示词里加过一句"注意不要过拟合"，没有用；模型手上只有 badcase，这句话对它就是一条无从验证的自我要求。

所以在我们的设计中，一次评测跑的是两份样本。一份是「badcase 集」，本次要解的那批错判商品；另一份是「近期商品集」，从最近几个批次里抽的约 500 条真实商品，含大量正常商品，不是线上全量流量。

时间节点	badcase修复率	近期500商品准确率
优化前	A	B
优化后	C	D

由此推出 2 个 Δ 指标：

• Δ_bad = C - A

• Δ_pop = D - B

解释一下，Δ_bad 是优化后 badcase 集准确率减去优化前，衡量「修复深度」；Δ_pop 是优化后近期商品集准确率减去优化前，衡量「附带伤害」。

两个数各算各的样本，互不重叠，这是"两个方向相反的检查"能成立的前提。

这两个指标各配一个阈值：θ_bad 取 20 个百分点，badcase 集准确率提升超过 20 个百分点才算有修复；ε 取 1 个百分点，近期商品集退化不超过 1 个百分点视为无伤害。这两个阈值由业务与工程共同配置，存放在模型上下文之外；模型既不能修改阈值，也不能覆盖判定结果。

再把每个方案按这两个差值落到四个象限，每个象限对应一个确定的决策：

象限	Δ_bad	Δ_pop	含义	决策
Q1 双赢	> θ_bad	≥ −ε	修好了 badcase 且没伤近期商品集	Pass
Q2 过拟合	> θ_bad	< −ε	修好 badcase 但伤了近期商品集	Reject
Q3 无效	≤ θ_bad	≥ −ε	没修好也没伤害	No-op
Q4 双输	≤ θ_bad	< −ε	没修好还倒退了	Fail

这个设计里最关键的一个决策是 Q2 被判 Reject，而不是 No-op。一个把 badcase 修得很好、但伤了近期商品集的方案，被判定为危险。因为它比 Q4 更阴——Q4 一眼就能看出失败，而 Q2 在任何只看 badcase 的报表里都是漂亮的成功案例。

问题2：在优化上如何避免 AI 跑偏？

第二个问题。判据只解决了"坏方案进不来"，解决不了"它一直朝着奇怪的方向努力"。

这两件事的区别在于：判据是事后的闸门，跑偏是过程里的漂移——方案一版一版交上来，每版都在改一点边角，指标一动不动，而模型每次的自述都是"已按上一版继续优化"。

我觉得核心就两个：给 Agent 划定最终目标，以及区分不同场景下的优化回路。在这两条之上还有一件事——优化的经验要长期沉淀，不要做重复的失败尝试。前两条管的是单轮不跑偏，第三条管的是下一轮比这一轮更聪明，缺了它，跑偏这件事会以同样的形态持续重演。

最终目标：让 Agent 为之努力的靶心

在让AI 进行优化时，我们需要给它指定一个最终目标形态。可以先看一个真实的目标长什么样：

「素材更新中类」是我们今年在跑的一个体检项，它的广泛定义如下：

商品信息尚未搭建完整，处于准备阶段，不具备面向消费者的完整消费决策信息。该状态下链接不具备真实可售卖能力，与新品"可购买商品"前提冲突。

这个体检项判断的是链接是否仍处于信息搭建的准备阶段，缺少支撑消费者决策的信息，并因此不具备真实可售卖能力。规则 prompt 可以一版版修改，但不能为了涨分，把业务定义改成识别某几个词。预告文字可以提供线索，最终仍要结合商品信息判断实际状态。

以修复漏判为例：一批符合“素材更新中”定义的商品被模型放过了。针对这些错例，可以比较两条优化路径。以下为机制说明，不代表新增的生产实验结果。

第一条是扩大命中条件：除了“新品预告”“勿拍”等准备阶段的线索，还把“预售”直接纳入命中条件。这样可能找回一部分漏判，却也会误伤商品展示、规格、价格和交付说明完整、可正常下单的预售商品。规则从判断“信息是否尚未搭建完整”，偏移成了判断“是否采用预售方式”。即使 Δ_bad 上升，这种修改也偏离了业务定义。

第二条是围绕链接的实际准备状态组织规则，结合商品展示和可获得的商品信息，判断是否缺少影响消费者决策的信息、是否具备真实可售卖能力。主图只有占位预告、商品本体未展示的链接，与信息完整且可正常下单的预售商品，需要分别判断。符合业务定义只说明方向可以继续，候选仍须通过双侧评测，不能因方向正确就直接放行。

所以最终目标不只是"把指标做上去"，还包括"哪些内容是不许改动的前提和目标"。前提一旦也交给模型，它就会用换题的方式达成目标。

失败路由：四个分支、三个存档点

最早评测不通过时只有一个动作：下个周期把这个体检项重新丢回规则迭代 Agent，重出一版。但是这明显是不够的。评测不通过时不能只压成一句“重出一版”就结束了。

四象限判定其实已经产出了带原因的分型——Q2 是"修好了 badcase 但打坏了正常商品"，Q4 是"两边都坏"——但这两种失败当时走的是同一条路，诊断信息在响应环节被抹平成一句"不通过"。等于花钱算出了病因，最后只把体温计读数递给医生。

现在失败被分成四类，每一类接一条不同的路：四类分别是过拟合、badcase 未修好、规则形态作弊，以及既没修好也没打坏的无效。

判断该走哪条路，依据来自四项分析，四路各自独立、互不共享上下文：未修复 badcase 的共性、被误杀商品的原因归类、规则形态扫描（规则文本里有没有商品标题片段、具体 SKU、硬编码枚举）、历史回归检查（对比历史评测记录里各 case 的判定结果，看本轮规则有没有把前几轮修好的又打坏）。

拆开的理由是这四项的上下文需求完全不同：前两项要把商品原文摊开给模型看，后两项一个只吃规则文本、一个只吃历史评测记录里的判定结果，都不碰商品原文；而后两项根本不该走大模型，正则匹配、集合比对加长度趋势统计就够，纯代码、零 token、结果确定。四项混在一个 prompt 里，最确定的那两项会被泡在商品文本里漏掉，而两份商品数据叠起来会先把上下文顶爆。

评测不通过之后还有第二件事：按失败原因决定这一轮从哪份规则出发，我们把它叫「存档点」。

也就是这一轮从哪份规则出发。这件事我们最初是交给模型的：把历史上的几版规则连同各版的评测结果一起给它，让它自己挑一份当基础。

收回来的原因是，这个挑选动作里藏着另一个决定。一份规则上通常同时挂着好几处毛病，条件缺失、判定写得太宽、文本里塞了一堆硬编码枚举，挑哪一版当起点，等于挑了这一轮先修哪一处。

而模型对「先修哪处」的排序依据是「哪处最容易让指标变好」，不是「哪处最根本」。补两条没修好的 badcase 很容易，删掉规则里那堆硬编码枚举很难——因为删完 Δ_bad 会掉下去，而它的目标函数就是 Δ_bad。判决权我们已经收回来了，执行权如果还在被告手里，判决就只是建议。

因此，最后落成了一个硬约束，形态是一个 base 选取函数：这一轮从哪份规则出发，由代码算，不由模型选。

历史状态	base 取哪份	附加约束	Δ 基线
无历史方案	线上规则	无	线上规则
上轮通过	上轮方案	无	上轮方案
上轮规则形态不合格	最后一个良好版本	带上具体证据、禁止枚举、Δ_bad 只记录不判定	同 base
连续两轮不合格	终止本轮	上报人工	—

经验沉淀：一份用完就扔，一份每轮都用

让下一轮真正不同的东西有两条。控制流那条是失败反馈：这一轮为什么不达标、下一轮该往哪个方向调，随重出一起注入，只对紧接着的那一轮有效，用完即弃。数据流那条是经验沉淀，走的路完全不同：它不跟着重出走，而是先落库，再在下一轮生成方案之前被读回来。这一条值得摊开讲，因为让循环真正变好的是它——它把动作空间一轮一轮收窄。

回路里有两类记忆。第一类是失败反馈：记录这一轮为什么不达标、下一轮应避开什么，只注入紧接着的一轮，用完即弃。第二类是经验沉淀：把经过客观评测支持的反模式、最佳实践和策略成功率写入经验库，在后续周期按相关性召回。

经验由评测完成后的“总结分析”步骤生成，因为只有这里同时拿到优化前后两组指标和四象限结果。产出方案的 Agent 不能给自己的方案写入库评价，否则只是把自评换了一个位置继续循环。

原始记录也不能直接跨周期注入。系统先做经验蒸馏，只保留反复出现且有证据支持的结论；召回时再按相关性选择与当前体检项最相关的内容。这样沉淀的是可复用经验，而不是上一轮的临时上下文。

这里有一条边界必须画清楚：原始经验和可复用的经验不是一回事。原始记录里混着大量只在当次成立的临时判断（这一批商品的类目分布、这一轮聚类的偶然形态），把它们原样跨周期召回，等于把上一次的临时上下文当成结论传给下一次。所以中间隔了一层提炼：经验蒸馏只把反复出现、拿得到支持证据的结论从原始记录里收上来写进经验库；召回时也不全量灌入，而是按相关性挑与本轮最相关的精炼后注入。

问题3：在流程上如何避免 AI 甩锅？

第三个问题。前两条一条管方案好不好、一条管方向跑没跑偏，这一条管的是不达标的时候，账该记在谁头上。

中央大脑：设计过，落地时又删除

在原先那个完整环里有一处说不清：如果 Agent 发现了一个体检项，迭代优化 N 轮之后怎么都不达标，那这一次到底是体检项本身归纳错了，还是规则 prompt 一直没优化对？

这个问题在单环形态下是无解的，因为归因和优化共享同一个失败。你只能看到"这个体检项一直不达标"，看不到责任落在哪一段。更麻烦的是模型会自己给出一个解释，而它的解释几乎总是指向更容易改的那一段——通常是规则 prompt，因为改文字比承认"这个体检项本身就不该存在"便宜得多。

这不是提示词能补的。一个 Agent 同时管流程、管重试、管判定、管归因，它每一步的中间结论都只存在于自己的自述里，外部拿不到任何可核对的凭据。甩锅是这种形态的默认产物，跟模型的态度没关系。

原来我们以为，让 AI 更自主就等于让一个 Agent 承担更多决策。实际是反过来的：它承担的决策越杂，能自主的空间越小。因为那些本不该由它做的决策，最后都得靠提示词去兜底——提示词越写越长，它在真正需要判断的地方反而越动不了。

根源在于它把两类性质完全不同的东西打包进了同一个执行体。一类是要模型去理解、归纳、下判断的事，做十次可能有九次一样；另一类是重试、调度、判定、编排，本来每次都该一模一样。打包之后，确定性那部分的可靠性会被拉到概率性那部分的水平上，整个系统的稳定性就挂在了最不稳定的一环上。

所以「中央大脑」式的 Agent 是个反模式，毛病不在于它管得多，在于它管的两类事性质不同。真要提升自主性，得先把确定性决策搬走，剩下的语义决策才敢放开。

删掉它之后，「体检项发现」和「体检项优化」被放进两个独立的 Loop，各自拥有各自的生命周期和各自的出口判据。要的就是一条：Agent 交付出去的结果，必须是在它自己的判据下已经验过的。

拆开之后责任是这样落地的：「发现回路」的出口是一道硬判据：召回率不低于 0.95、准确率不低于 95%、样本数大于 0，三个条件同时成立才允许交付。召回率管「别漏捉」，准确率管「别乱捉」，第三个条件挡的是零样本造成的假信号；优化回路的入口假设"体检项本身是成立的"，它只对规则 prompt 负责。于是 N 轮不达标不再是一笔糊涂账，一个从发现回路进来的体检项如果在优化回路里连续不达标，那就是规则侧的问题，因为它进门时已经拿到过发现回路的达标凭据；如果它在发现回路就锁不住，它根本不会流到下游去消耗优化预算。

权限分家：语义判断归模型，确定性计算归代码

这里还有一个比较有意思的问题可以讨论一下，很多同学在设计 Agent 的时候，常常在考虑一个问题：什么东西可以托管给模型？其实就是在工程管控的应用里，要给 AI 分多少“家产”的问题。

分家这一“刀”落在哪儿，口径其实很朴素：能不能写出判断它对错的代码。写得出来，说明这件事是确定的；写不出来，才轮到模型。与其去想「能让模型做什么」，不如先想想「这件事必须发生哪些动作」，「哪些动作是只有模型才能做的」。

能写出校验逻辑，说明它是确定的；写不出来，才轮到模型。拿重试、调度、入库这几样过一遍就清楚——重试要不要继续（看指标过没过阈值）、调度什么时候触发（看周期到没到）、方案要不要入库（看落在哪个象限），判断对错的代码都写得出来，所以全归代码；而“这批 badcase 的共通原因是什么”写不出校验代码，只能归模型。按这个口径分完，两边拿到的是这些：

分家的判断标准是“能不能写出校验它对错的代码”。能写出确定性校验的动作——算指标、比阈值、调度、重试、早停、入库——全部归代码；无法用规则验证的语义任务——归纳共性、判断缺陷、提出优化方向——才交给模型。人则提供抽样真值、处理灰区，并承担最终上线责任。

流程决策：如何避免下一步的决策被概率污染

回路拆开后，我们把流程控制单独做成一层“控制面”：凡是能够写成确定规则的调度、重试、判定和入库动作，都由 Java 代码执行。模型只提交候选，不直接推动状态迁移。

• 第一，Java 代码接管生命周期。 外层管理体检项，内层管理候选方案，调度、状态迁移和退出条件都由业务后端控制。单项失败不必让整批重新开始，模型提交候选和分析结果，不直接决定流程成功结束。

• 第二，一次生成多个候选。 从一次只生成一个方案，改为一次生成 1 到 4 个方案。多于一个时，在保守、均衡、激进的修改方向之间拉开差异，再分别接受评测。这样可以比较不同修法，每个候选仍然遵守相同门槛。

• 第三，评测异步执行。 一次评测需要跑一批商品的 AI 识别，耗时较长。Agent 生成并提交方案后结束本次执行，后端批处理运行评测，下一次调度再带回结果和失败反馈。模型不必在执行体里等待一个长任务。

• 第四，代码读取真实结果形成状态。 Agent 在本次生成执行里拿不到最终验收结论，无法靠一句“优化完成”推进流程。后端计算指标并更新状态，后续调度据此继续。

因此，一次业务上的优化可能跨越多个调度周期。本文所说的重试，不是让模型在一次调用中同步跑完整条链，而是后端带着状态与证据，推动下一次生成和验证。

因此，优化回路不是一个模型在同步地跑完整条链，而是模型生成候选、后端异步评测、代码推进状态、下一次调度再把结果带回。

改造后，系统仍然保留着两个 Loop：一个发现新体检项，一个优化已有体检项。生成、评测、反馈、再优化的过程没有变。我们改的是每一步由谁执行，以及谁有权决定继续、停止和上线。

Loop 描述迭代过程，Graph 描述执行结构。前者关注这一轮的反馈如何用于下一轮；后者用节点表示执行步骤，用边连接步骤，并根据状态和条件选择下一步。Graph 里也可以有回路，两者可以同时使用。LangGraph 就支持循环工作流，节点和路由逻辑可以由模型或普通代码实现。

初版中，模型生成候选、调用评测工具，再解释结果、选择下一步，最后决定是否结束。问题出在后半段：工具已经返回失败证据，模型仍可能解释成“基本达标”，或者继续沿着错误方向修改。

改造后，模型继续负责理解业务语义、分析失败原因和生成候选。评测流程运行候选规则，代码对照人工标注结果计算指标、判定是否达标，再按既定条件处理：需要重新生成方案的，带着失败证据返回模型；本轮不立即重新生成方案的，等待下一周期；触发退出条件的，停止自动迭代，转人工兜底。通过评测的候选交给运营确认是否上线。

这里要区分两件事：商品是否符合某条规则，仍可能需要模型判断；指标怎么算、是否达标、下一步走哪条分支，由代码决定。评测必须实际执行，指标必须来自评测结果，模型不能靠改写结论让未达标的候选进入待上线状态。

在这套系统里，Graph Engineering 对应的是这些具体工作：记录候选版本、评测结果、失败类型和迭代次数，把分支和退出规则落实到执行流程中。只有这些约束实际生效，才谈得上控制住流程。拆成多个 Agent、画出节点和连线，都不能代替这部分工作。

这套分工最终落在体检项发现和体检项优化两条回路里，下面展开看它们如何运行。

依次解决了上述问题后，我们重新设计了「体检项发现」和「体检项优化」的Agent流程。两条回路各自成环，各有自己的入口和出口，中间靠业务时间线衔接，不再由模型在一个环里自己跳。

体检项发现核心解决「新规则从哪来」：用宽泛口径实时捞出疑似有问题的商品，小二抽样标注确认，从这批已标注的问题商品里做特征聚类、归纳出新的体检项候选，真跑评测取回混淆矩阵，达标的锁定成入库建议。

体检项优化核心解决「体检项怎么变好」：拉出准确率不达标的体检项，取它近期 badcase，归因定性，一次生成多个激进程度不同的优化方案，每个方案独立提交评测，落库成优化记录，最后汇总成运营周报推给小二。

两条 Agent 流程各自成环，但权限配置不同。发现回路面向未知场景，模型负责发散归纳，代码只用召回率、准确率和样本数三道硬门槛验收；优化回路面向已经成立的体检项，代码掌握流程控制和达标判定，模型只负责归因与方案生成。换句话说，发现回路解决“找到什么”，优化回路解决“怎么改好”。

两个 Loop 不是并列的两张流程图，而是沿业务时间线串在一起。发现回路通过三条件验收后，生成的新体检项先进入 case 池并上线运行；线上持续积累的 case 与 badcase，随后成为优化回路的输入。

优化回路只有 Q1 可以出环，经周报交给运营确认后上线；上线结果继续回流到 case 池，进入下一轮发现与优化。Q3 不在本轮立即重出，而是在下个周期回到 badcase 归因；连续两轮不合格则退出自动回路，转人工兜底。

而下面这张图就是我们目前的设计形态：两个环通力合作，实现我们「让AI 发现新的场景，并能自己优化自己」的目标。

回看整个 Agent 的演进过程，模型换过，编排的流程换过，Agent 合过也拆过，但工程方向始终一致：我们在不断地减少模型的自主权，把可被代码验证的确定性决策，从模型侧逐项收回到控制面。

支撑这条线的东西整理完后比想象中的要简单：

• 首先是把「达标判断」从模型手里收回：给予客观的评测手段，并在评测里加入对侧样本，防止过度优化走向过拟合。

• 其次是把「核心目标」给模型解释清楚：先理清楚优化的最终目标是什么，可以从什么方向进行优化，要解决的是过拟合还是无效优化。才能保证模型的方向不会跑偏。

• 最后是把「权限分家」实打实的给做好：先切分「语义判断」与「确定性计算」，再决定给模型多少自主权。让模型负责产生判断（归纳共性、定位缺陷、择优推理），代码负责确认事实（算指标、比阈值、处理边界、保证事务）。在Agent的自主性和人类的监督权之间找到平衡。

再额外多聊一点过程中的感受，我认为Agent的设计思路里最重要的是顺序：先有判断好坏的评测基准，再有跑起来的 Agent。

评测基准出现之前，架构上的争论——Loop 还是 Graph、单 Agent 还是多 Agent、要不要接框架——都少一个能被证伪的对象，到最后比的只是谁的直觉更响；评测基准出现之后，这些问题反倒松弛下来：形状可以换，模型可以换，换完跑一遍评测就知道是亏是赚。

同时，Human in the Loop 也不一定是执行层的终态，但 Human In the Control，也就是始终有人对目标、风险和结果负责，应该是治理层的终态。

随着评测、监控和回滚能力逐渐成熟，人未必需要永远审批每一次上线。对于低风险、证据充分的变更，系统完全可以在明确的边界内自动运行。

但这不意味着人的责任消失了。人会从“判断每一个答案”，转向更上层的工作：定义什么叫正确，划定系统可以自动行动的风险边界，并保留暂停、接管和回滚的权力。

所以，未来真正可能被自动化的是逐次审批；不能被自动化掉的，是谁定义正确、谁划定风险边界，以及谁对最终结果负责。

也许未来不是把人从 Loop 里拿掉，是让人从“判断每一个答案”，转向“定义什么叫正确，以及系统可以承担多大的错误”。