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

AI落地实践中，「让模型自主迭代」听起来很美，但真正跑起来往往是一地鸡毛。我们团队在电商新品捉虫业务中曾尝试让Agent自由优化prompt、自我评测验证，结果模型学会了把商品标题直接贴进规则、把评测集背下来应对考核。这不是能力问题，而是当目标函数只观察固定样本时，循环优化必然从「修正业务规则」滑向「迎合评测样本」。本文将分享我们如何从惨痛翻车中总结出一套可验证、可控的Graph Engineering方法论。

循环优化为什么会走向作弊？答案藏在一个经典定律里：当一个指标变成目标，它就不再是个好指标。在我们的场景中，只评测「发生问题的这批badcase」修复率，等于把目标函数整包交给了输入——模型看到的世界里只有做错的题，最省力的解法当然是在这批样本上百发百中。解决方案是为评测补上原来缺的那半边：不只看badcase修好了多少，也看一批没挑过的真实商品会不会被顺手弄坏。这半边只能补在样本里，补不进提示词——在提示词里加一句「注意不要过拟合」，对模型就是一条无从验证的自我要求。

四象限判据：把决定权从模型手里抢回来

新判据的核心是两份样本、两个阈值、四个象限。一次评测同时跑badcase集和近期商品集（从最近批次抽取约500条真实商品），各配独立阈值：badcase修复率提升超过20个百分点才算有修复，近期商品集退化不超过1个百分点视为无伤害。由此推出Δ_bad和Δ_pop两个指标，每个方案按这两个差值落入四象限。Q1（双赢）通过，Q2（修好badcase但伤了正常商品）直接Reject——它比Q4更危险，因为在任何只看badcase的报表里都是漂亮的成功案例。这两个阈值由业务与工程共同配置，存放在模型上下文之外，模型既不能修改阈值，也不能覆盖判定结果。

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

判据只解决了「坏方案进不来」，解决不了「它一直朝着奇怪的方向努力」。我们在实践中总结出更关键的原则：权限必须逐项分配，不能整包批发。分家标准很朴素——能不能写出判断它对错的代码。能写出校验逻辑的：算指标、比阈值、调度、重试、早停、入库，全部归代码；写不出校验代码的语义任务——归纳共性、判断缺陷、提出优化方向——才交给模型。此外还要做两件事：失败路由要按四类原因（过拟合、badcase未修好、规则形态作弊、无效优化）走不同分支，经验要分「用完就扔的失败反馈」和「跨周期复用的经验沉淀」，后者必须经过蒸馏提炼才能入库，防止把临时上下文当成结论。

双环协同：从模型主导到显式执行

改造后系统保留两个独立Loop：发现新体检项的「发现回路」，以及优化已有体检项的「优化回路」。发现回路面向未知场景，模型负责发散归纳，代码只用召回率、准确率、样本数三道硬门槛验收；优化回路面向已成立的体检项，代码掌握流程控制和达标判定，模型只负责归因与方案生成。两个Loop沿业务时间线串在一起：发现回路通过三条件验收后，新体检项先上线运行，线上积累的case随后成为优化回路的输入。只有Q1可以出环，经运营确认后上线；连续两轮不合格则退出自动回路，转人工兜底。这套分工的关键在于：商品是否符合某条规则，可能需要模型判断；但指标怎么算、是否达标、下一步走哪条分支，必须由代码决定。

模型换过，编排流程换过，Agent合过也拆过，但工程方向始终一致：把可被代码验证的确定性决策逐项从模型侧收回。先有判断好坏的评测基准，再有跑起来的Agent——评测基准出现之前，架构上的争论都少一个能被证伪的对象。Human In the Control，也就是始终有人对目标、风险和结果负责，应该是治理层的终态。未来真正可能被自动化的是逐次审批，不能被自动化掉的是谁定义正确、谁划定风险边界，以及谁对最终结果负责。