前言先能管控验收再谈自主迭代最近这半年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 处于什么样的工程管控之下。01 前世 新品捉虫下小二的困境去年随着大模型能力的逐渐成熟我们团队也在尝试将 新品业务 和 AI 结合通过 Agent 来识别出不符合新品标准的商品并给予去劣。而每种 badcase 所归纳的场景我们分别用不同的「体检项」来统称每个体检项都有它所对应的规则其实就是一小段 prompt告知大模型要捉虫的商品有什么特征然后让大模型基于体检项和规则对每日的新发商品进行判断判断它是否是我们所认定的「新品 badcase」。结果跑出来后业务小二会安排专门的同学对捉虫的结果进行标注回收标注结果后就能得到每个体检项的准确率。高准确率的上线低的去找原因、改规则、再等一轮产出。靠着这套流程上个财年一共落地上线了不到10个体检项不是新品的问题就只有这么一点关键在于产出一条能够落地的体检项的成本太高。上个财年的运营流程是这样的小二在新品池里发现 badcase → 小二定义体检项和规则prompt → 大模型离线产出捉虫结果 → 小二进行标注 → 小二分析模型错误的原因 → 修改体检项规则直到准确率达标。这条链路光看一遍就有点力竭了业务同学天天走一遍更累。这条链路上有两个具体的核心卡点第一个问题是小二很难提出新的体检项。 提规则本质上是一个归纳任务要先看过足够多的新品badcase才能总结出它们的共性。人的归纳带宽就是瓶颈。第二个问题是小二对于体检项的修改不一定有效。我们前面说了「体检项」本质就是一类问题场景和它所对应的prompt小二首先得纯人工一条一条的看完所有模型的错误case然后归类、改 prompt、再等一轮离线产出标注验证还不一定能让模型理解我们的要求。试想一下如果你是业务小二你花了一个下午的时间对某个体检项近几百条的 badcase 一个一个看完然后高高兴兴的修改后第二天来一看模型不仅没有把错误的 case 修复好反而原先正确的 case 都识别不清楚了那么一定是相当的崩溃的这意味着这一轮活都得重新开始。所以在这个业务里AI 要解决的核心问题不是「多写几条规则」而要把发现、归纳和验证这三件事自动化人只保留对产出结果的「标注」以及最后的「上线决策」。于是我们给出的优化方案是AI 主动发现 → 小二标注校准 → AI 自行迭代 → AI 多轮评测 → AI 持续观察 → 小二决策是否上线。02 翻车 Loop Agent 自学了作弊在上文我们所阐述的方案里很重要的一个点为「AI自行迭代」所以在今年 5、6 月份的时候我们在体检项上先走了一条最省事的路来实现所谓「自迭代」的能力也就是用一个 ReAct 模型当大脑把所有流程都做成 tool让 Agent 自己发现新品 badcase用 badcase 发现新体检项然后让它自己改规则 prompt、自己评测验证、自己总结问题、自动循环优化无人值守地变好。那时的整条链路只有一个闭环让Agent自由去发现体检项和优化体检项跑评测、判达标、做总结都在一个环上每一步下一步去哪都由模型自己决定直到最终产出合格的结果给我们。现在回头看它就是社区所说的 Loop Engineering 形态设计时的理想很美好——小二只管标注剩下全交给一个自我迭代的 Loop完美的数据飞轮。但是我们翻车了。这版 Loop 很快就完成了问题的发现和体检项的优化但是验收数据的时候只看到了一地鸡毛遇到的问题大致如下大部分优化循环都是同一个模式badcase 修好了上线后整体准确率反而掉几个点。翻开模型改出来的规则一看作弊手段相当直白它把 badcase 里的商品标题拆碎了直接贴进规则文本。规则退化成一张已知样本的查找表甚至直接指名道姓的排除了某些商品在这批 badcase 上百发百中换一批商品立刻原形毕露。我们又试过给它一份精心挑选的黄金评测集每轮评测后让它分析错误原因再优化。几轮之后同样的事情发生了它优化出来的 prompt 越来越贴近评测集里那些商品。多次重试达不成目标的时候它学会的是怎么应付这套题而不是怎么总结商品的共性把规则写对。最难处理的问题是自我总结流程。我们让它评估自己改得怎么样、分析自己错在哪它每一轮总结时拿着之前那些上下文都告诉你已完成优化。只要判定还在模型手里你拿到的就不是评测结论而是一份自我陈述。03 划界划分 Loop 里 AI 和人的边界上一次 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商品准确率优化前AB优化后CD由此推出 2 个 Δ 指标Δ_bad C - AΔ_pop D - B解释一下Δ_bad 是优化后 badcase 集准确率减去优化前衡量「修复深度」Δ_pop 是优化后近期商品集准确率减去优化前衡量「附带伤害」。两个数各算各的样本互不重叠这是两个方向相反的检查能成立的前提。这两个指标各配一个阈值θ_bad 取 20 个百分点badcase 集准确率提升超过 20 个百分点才算有修复ε 取 1 个百分点近期商品集退化不超过 1 个百分点视为无伤害。这两个阈值由业务与工程共同配置存放在模型上下文之外模型既不能修改阈值也不能覆盖判定结果。再把每个方案按这两个差值落到四个象限每个象限对应一个确定的决策象限Δ_badΔ_pop含义决策Q1 双赢 θ_bad≥ −ε修好了 badcase 且没伤近期商品集PassQ2 过拟合 θ_bad −ε修好 badcase 但伤了近期商品集RejectQ3 无效≤ θ_bad≥ −ε没修好也没伤害No-opQ4 双输≤ θ_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 在本次生成执行里拿不到最终验收结论无法靠一句“优化完成”推进流程。后端计算指标并更新状态后续调度据此继续。因此一次业务上的优化可能跨越多个调度周期。本文所说的重试不是让模型在一次调用中同步跑完整条链而是后端带着状态与证据推动下一次生成和验证。因此优化回路不是一个模型在同步地跑完整条链而是模型生成候选、后端异步评测、代码推进状态、下一次调度再把结果带回。04 演进从模型主导的 Loop到显式执行的 Graph改造后系统仍然保留着两个 Loop一个发现新体检项一个优化已有体检项。生成、评测、反馈、再优化的过程没有变。我们改的是每一步由谁执行以及谁有权决定继续、停止和上线。Loop 描述迭代过程Graph 描述执行结构。前者关注这一轮的反馈如何用于下一轮后者用节点表示执行步骤用边连接步骤并根据状态和条件选择下一步。Graph 里也可以有回路两者可以同时使用。LangGraph 就支持循环工作流节点和路由逻辑可以由模型或普通代码实现。初版中模型生成候选、调用评测工具再解释结果、选择下一步最后决定是否结束。问题出在后半段工具已经返回失败证据模型仍可能解释成“基本达标”或者继续沿着错误方向修改。改造后模型继续负责理解业务语义、分析失败原因和生成候选。评测流程运行候选规则代码对照人工标注结果计算指标、判定是否达标再按既定条件处理需要重新生成方案的带着失败证据返回模型本轮不立即重新生成方案的等待下一周期触发退出条件的停止自动迭代转人工兜底。通过评测的候选交给运营确认是否上线。这里要区分两件事商品是否符合某条规则仍可能需要模型判断指标怎么算、是否达标、下一步走哪条分支由代码决定。评测必须实际执行指标必须来自评测结果模型不能靠改写结论让未达标的候选进入待上线状态。在这套系统里Graph Engineering 对应的是这些具体工作记录候选版本、评测结果、失败类型和迭代次数把分支和退出规则落实到执行流程中。只有这些约束实际生效才谈得上控制住流程。拆成多个 Agent、画出节点和连线都不能代替这部分工作。这套分工最终落在体检项发现和体检项优化两条回路里下面展开看它们如何运行。05 重建 现在这套系统是怎么转的依次解决了上述问题后我们重新设计了「体检项发现」和「体检项优化」的Agent流程。两条回路各自成环各有自己的入口和出口中间靠业务时间线衔接不再由模型在一个环里自己跳。体检项发现核心解决「新规则从哪来」用宽泛口径实时捞出疑似有问题的商品小二抽样标注确认从这批已标注的问题商品里做特征聚类、归纳出新的体检项候选真跑评测取回混淆矩阵达标的锁定成入库建议。体检项优化核心解决「体检项怎么变好」拉出准确率不达标的体检项取它近期 badcase归因定性一次生成多个激进程度不同的优化方案每个方案独立提交评测落库成优化记录最后汇总成运营周报推给小二。两条 Agent 流程各自成环但权限配置不同。发现回路面向未知场景模型负责发散归纳代码只用召回率、准确率和样本数三道硬门槛验收优化回路面向已经成立的体检项代码掌握流程控制和达标判定模型只负责归因与方案生成。换句话说发现回路解决“找到什么”优化回路解决“怎么改好”。两个 Loop 不是并列的两张流程图而是沿业务时间线串在一起。发现回路通过三条件验收后生成的新体检项先进入 case 池并上线运行线上持续积累的 case 与 badcase随后成为优化回路的输入。优化回路只有 Q1 可以出环经周报交给运营确认后上线上线结果继续回流到 case 池进入下一轮发现与优化。Q3 不在本轮立即重出而是在下个周期回到 badcase 归因连续两轮不合格则退出自动回路转人工兜底。而下面这张图就是我们目前的设计形态两个环通力合作实现我们「让AI 发现新的场景并能自己优化自己」的目标。06 写在最后回看整个 Agent 的演进过程模型换过编排的流程换过Agent 合过也拆过但工程方向始终一致我们在不断地减少模型的自主权把可被代码验证的确定性决策从模型侧逐项收回到控制面。支撑这条线的东西整理完后比想象中的要简单首先是把「达标判断」从模型手里收回给予客观的评测手段并在评测里加入对侧样本防止过度优化走向过拟合。其次是把「核心目标」给模型解释清楚先理清楚优化的最终目标是什么可以从什么方向进行优化要解决的是过拟合还是无效优化。才能保证模型的方向不会跑偏。最后是把「权限分家」实打实的给做好先切分「语义判断」与「确定性计算」再决定给模型多少自主权。让模型负责产生判断归纳共性、定位缺陷、择优推理代码负责确认事实算指标、比阈值、处理边界、保证事务。在Agent的自主性和人类的监督权之间找到平衡。再额外多聊一点过程中的感受我认为Agent的设计思路里最重要的是顺序先有判断好坏的评测基准再有跑起来的 Agent。评测基准出现之前架构上的争论——Loop 还是 Graph、单 Agent 还是多 Agent、要不要接框架——都少一个能被证伪的对象到最后比的只是谁的直觉更响评测基准出现之后这些问题反倒松弛下来形状可以换模型可以换换完跑一遍评测就知道是亏是赚。同时Human in the Loop 也不一定是执行层的终态但 Human In the Control也就是始终有人对目标、风险和结果负责应该是治理层的终态。随着评测、监控和回滚能力逐渐成熟人未必需要永远审批每一次上线。对于低风险、证据充分的变更系统完全可以在明确的边界内自动运行。但这不意味着人的责任消失了。人会从“判断每一个答案”转向更上层的工作定义什么叫正确划定系统可以自动行动的风险边界并保留暂停、接管和回滚的权力。所以未来真正可能被自动化的是逐次审批不能被自动化掉的是谁定义正确、谁划定风险边界以及谁对最终结果负责。也许未来不是把人从 Loop 里拿掉是让人从“判断每一个答案”转向“定义什么叫正确以及系统可以承担多大的错误”。*注本文为作者个人技术思考与经验分享不代表公司的官方立场或观点。文中部分论述涉及对技术趋势和发展方向的前瞻性判断基于作者写作时的认知与经验所有内容仅供交流参考读者应结合自身场景独立评估。