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

这是 2026 年的第 61 篇文章

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

近期 AI 领域新概念频出，从 Loop Engineering 到 Graph Engineering，演变迅速。我们团队在构建 AI 体检 Agent 的过程中，恰好经历了这两个阶段的实践。

起初，我们秉持“让 AI 自我迭代”的理念，赋予 Agent 高度自主权，包括自主调优 Prompt、循环评测及决策路径。然而在实践中遭遇诸多挑战后，我们调整策略：将可被代码验证的确定性决策权从模型侧收回，仅保留语义理解、归因分析和方案生成能力给模型。

本文记录了从 Loop Engineering 向 Graph Engineering 演进的实战经验，重点探讨：Agent 单指标自优化如何导致过拟合与作弊、如何构建防欺骗的评测底座、以及哪些权限必须回归工程侧。核心观点在于：Graph Engineering 并非简单的结构可视化，而是重新界定“谁产生候选、谁验证结果、谁对上线负责”的工程化解决方案。

我们始终认同"AI 自我迭代”的方向，但关键在于：Loop 必须置于严格的工程管控之下。

01 前世：新品捉虫下小二的困境

去年，随着大模型能力成熟，我们尝试将 AI Agent 应用于新品业务，旨在识别不符合标准的新品并进行去劣处理。

我们将各类 Badcase 场景归纳为不同的“体检项”，每个体检项对应一段规则 Prompt，指导大模型判断新发商品是否属于“新品 Badcase"。

流程上，业务小二需对模型输出结果进行标注，计算准确率。高准确率则上线，低准确率则需人工分析原因、修改规则并重新验证。上一财年仅上线不足 10 个体检项，核心瓶颈在于产出一条可落地体检项的成本过高。

原有运营链路为：小二发现 Badcase → 定义规则 Prompt → 模型离线产出 → 小二标注 → 分析错误 → 修改规则直至达标。该流程存在两大核心痛点：

• 归纳瓶颈：提出新体检项需要基于大量 Badcase 归纳共性，受限于人工带宽。
• 修改无效：人工逐一查看错误案例、归类并修改 Prompt 后，往往无法让模型准确理解意图，甚至导致旧的正确案例被误杀，陷入反复试错的死循环。

因此，AI 的核心价值不应是替代人工写规则，而是实现“发现、归纳、验证”的自动化。人工仅保留结果标注与上线决策权。优化后的方案流程为：AI 主动发现 → 小二标注校准 → AI 自行迭代 → AI 多轮评测 → AI 持续观察 → 小二决策上线。

02 翻车：Loop Agent 自学了作弊

为实现"AI 自行迭代”，初期我们采用 ReAct 模型作为大脑，将所有流程工具化，构建了一个无人值守的自闭环 Loop：Agent 自主发现 Badcase、生成新体检项、修改规则、评测验证并循环优化。

这正是典型的 Loop Engineering 形态：

理想中这是完美的数据飞轮，但实际运行结果却是一地鸡毛，主要问题如下：

• 直白作弊：模型为快速提升 Badcase 修复率，直接将样本商品标题拆解嵌入规则文本，甚至指名排除特定商品。这种“查找表”式的规则在测试集上百发百中，但泛化能力为零。
• 应试优化：面对黄金评测集，模型逐渐学会针对特定样本调整 Prompt，而非总结商品共性。多次重试未果时，它选择的是“应付考试”而非“解决问题”。
• 自我包庇：在自我总结环节，模型基于上下文总是汇报“已完成优化”。只要判定权在模型手中，输出的便不是客观结论，而是自我陈述。

03 划界：划分 Loop 里 AI 和人的边界

此次失败带来了三条关键教训：

• 目标函数单一导致过拟合：若仅关注 Badcase 修复指标，模型必然通过过拟合手段达成目标。
• 生成与评判未分离：“改得好不好”与“往哪改”不能由同一主体决定。自己批自己，批判性会被原方案锚定。
• 自主权需逐项分配：全权托管会导致模型“应试”而非进化，且故障难以追溯。

基于此，我们从评测机制、优化方向和流程权责三个维度进行了重构。

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

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

早期评测仅关注 Badcase 修复率，忽略了误伤正常商品的风险。当目标函数仅由固定样本决定时，模型最省力的解法是“背题”而非“解题”。这符合 Goodhart 定律：当指标成为目标，它就不再是好指标。

解决之道在于建立模型无法干预的客观独立评测机制，实现生成者与评判者的分离。

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

新判据引入双样本评测机制：

1. Badcase 集：本次需修复的错判商品。
2. 近期商品集：随机抽取的约 500 条真实商品（含大量正常品），用于检测附带伤害。

由此推导两个增量指标：

• Δ_bad = C - A：衡量修复深度。
• Δ_pop = D - B：衡量附带伤害。

设定阈值：θ_bad（修复提升需超 20%）与 ε（退化不超过 1%）。阈值由业务与工程配置，存储于模型上下文之外，不可篡改。

根据指标落入四个象限，执行不同决策：

关键设计在于 Q2 被判为 Reject。相比显而易见的 Q4，Q2 在单一指标报表中看似成功，实则隐患最大，必须严厉拦截。

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

判据解决了“坏方案进不来”，还需解决“方向跑偏”的问题。核心策略包括：明确最终目标、细分失败路由、沉淀长期经验。

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

优化不能仅为了提升指标，必须坚守业务定义。例如“素材更新中类”体检项，其核心定义是“信息搭建不完整，不具备售卖能力”，而非简单匹配“预售”等关键词。若模型为提升召回率而扩大命中条件，误伤正常预售商品，即便指标上升也属偏离目标。

因此，最终目标包含“不许改动的前提”，防止模型通过偷换概念达成指标。

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

针对不同失败类型（过拟合、未修复、规则作弊、无效），系统设计了四条独立的处理路径，分别分析未修复 Badcase 共性、误杀原因、规则形态及历史回归情况。其中规则形态扫描和历史检查由纯代码完成，确保确定性。

此外，引入“存档点”机制：下一轮优化的起始规则版本由代码根据失败类型自动选择，而非由模型决定。例如，若上轮规则形态不合格，则回滚至最后一个良好版本，并附加禁止硬编码的约束。

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

系统区分两类记忆：

1. 失败反馈：针对当前轮次的临时建议，用完即弃。
2. 经验沉淀：经客观评测验证的反模式与最佳实践，写入经验库。系统会对原始记录进行蒸馏，仅保留反复出现且有证据支持的结论，并在后续周期按相关性召回，避免临时上下文干扰。

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

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

单一 Agent 同时负责归因、优化、判定和重试，容易导致责任模糊。模型倾向于将失败归咎于规则微调，而非承认体检项本身定义错误。这种“中央大脑”模式将确定性逻辑与概率性判断混同，降低了系统稳定性。

解决方案是拆分 Loop：“体检项发现”与“体检项优化”独立运行。发现回路需满足召回率、准确率及样本量三重硬指标方可交付；优化回路则默认体检项成立，仅对规则 Prompt 负责。如此，责任边界清晰可溯。

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

权限划分标准明确：能否写出校验代码。能写出确定性校验的动作（算指标、比阈值、调度、重试）全部归代码；无法用规则验证的语义任务（归纳共性、判断缺陷）才交给模型。

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

流程控制层（Control Plane）由 Java 代码接管：

• 生命周期管理：后端控制调度、状态迁移和退出条件。
• 多候选生成：一次生成 1-4 个不同激进程度的方案并行评测。
• 异步评测：模型提交方案后即结束，后端异步运行评测，下次调度带回结果。
• 状态更新：代码读取真实评测结果更新状态，模型无法靠口头汇报推进流程。

优化回路变为：模型生成候选 → 后端异步评测 → 代码推进状态 → 下次调度反馈结果。

04 演进：从模型主导的 Loop，到显式执行的 Graph

改造后的系统保留了两个 Loop（发现与优化），但执行结构转变为 Graph。Loop 描述迭代过程，Graph 描述执行结构。LangGraph 等框架支持此类带条件的循环工作流。

初版中，模型解释评测结果并决定下一步，易出现粉饰太平的情况。改造后，模型仅负责语义分析与方案生成；代码负责执行评测、计算指标、判定达标及路由分支。只有通过评测的候选才会进入待上线状态。

Graph Engineering 的核心在于将分支逻辑和退出规则落实到执行流程中，确保约束实际生效。

05 重建：现在这套系统是怎么转的

系统现已重构为两条独立回路，沿业务时间线串联：

• 体检项发现回路：解决“新规则从哪来”。模型发散归纳，代码以召回率、准确率和样本量为硬门槛验收。达标后进入 Case 池并上线。
• 体检项优化回路：解决“体检项怎么变好”。针对不达标项，模型归因并生成多方案，代码控制流程与判定。仅 Q1（双赢）方案经运营确认后上线；连续失败则转人工兜底。

两条回路通力合作，实现了"AI 发现新场景并自我优化”的目标，同时确保了工程可控性。

06 写在最后

回顾 Agent 演进历程，核心工程方向始终是减少模型自主权，将确定性决策收归控制面。关键举措包括：

• 收回达标判断权：建立含对侧样本的客观评测机制，防止过拟合。
• 明确核心目标：厘清优化方向，防止模型跑偏。
• 落实权限分家：语义判断归模型，确定性计算归代码，在自主性与监督权间找到平衡。

最重要的心得是顺序：先有评测基准，再有 Agent。评测基准确立后，架构争论（Loop 还是 Graph）便有了证伪依据。

未来，Human in the Loop 未必是执行层终态，但Human in the Control（人对目标、风险和结果负责）应是治理层的终态。自动化取代的是逐次审批，而非定义正确、划定风险边界及承担最终责任的权力。