Verification Loop1、引言2、Verification Loop 到底解决什么问题3、Verification Loop 核心原理3.1 四个零件Judge / Rubric / Feedback / Retry3.2 跟人工 review比差在哪4、生产级实现LangGraph 结构化 Rubric5、2026 年的关键改进点5.1 从一句话打分到多维结构化评分5.2 裁判与运动员不同模型5.3 Budget-Aware Retry不是无限重写6、适用场景与性能基准7、总结1、引言小屌丝鱼哥上回你教我那 Agent Loop 是真好用我让它写一份本季度的运营复盘它吭哧吭哧查数据、拉表格、写稿子三分钟就给我整出来了。小鱼那不是挺好小屌丝好个屁。我直接把它贴到部门群里了老板。结果十分钟后老板私聊我小李这个’DAU 同比增长 47%你自己去后台看一眼到底是 4.7% 还是 47%我一查——4.7%。它小数点都给我吃了。小鱼笑你这就是把 Agent Loop 当成流水线工人货一出来直接装车没经过质检。小屌丝那我咋办我自己审它一分钟出一篇我审一篇十分钟我一天啥也别干了。小鱼你再给它套一层循环——Verification Loop。让另一个或者同一个AI 当质检员按一份评分表Rubric去打分不合格就把错在哪、怎么改当反馈塞回去让原 Agent 重写。直到过审为止。小屌丝这不就是AI 检查 AI吗那它俩串供怎么办我写它判它肯定放水啊。小鱼问到点子上了。2026 年这套东西已经进化出一堆套路——裁判用更大的模型、按维度拆 Rubric、跟标准答案对照、多个裁判投票。今天我就给你讲讲怎么让质检员不摸鱼。2、Verification Loop 到底解决什么问题上一篇的 Agent Loop 解决的是把活干完这一篇解决的是干出来的活能不能直接用。对应素材里的循环 2Agent 输出 ↓ Grader评分器—— LLM as a Judge ↓ 符合标准 ├─ 是 → 通过交付 └─ 否 → 反馈错误具体改进建议→ 回到 Agent 输出重写为什么必须要有这一层因为 LLM 有三个天生毛病幻觉它会把 4.7% 写成 47%语气还特别自信格式漂移你要 JSON它给你加一段寒暄你要三段它给你写五段风格不稳定今天写得像资深总监明天写得像刚入职的实习生。Agent Loop 越自主这三个毛病放出去的代价越大。Verification Loop 就是出货前的那道闸。阶段没有 Verification有 Verification Loop内容生成一次生成直接交付生成 → 评审 → 不合格重写错误代价直接发给用户/老板在系统内部被拦下来质量一致性看模型当天心情按 Rubric 量化打分可回归成本看起来省了一步多花 1–2 倍 token但事故成本下降一个数量级一句话总结Verification Loop LLM as Judge Rubric 可执行反馈 有限次重试把AI 写的从看起来还行变成敢直接发出去。3、Verification Loop 核心原理3.1 四个零件Judge / Rubric / Feedback / Retry拆开看就四样东西Grader / Judge评分器一个 LLM 调用输入任务 原始要求 Agent 输出输出过还是不过理由是什么。Rubric评分表把好这件事拆成几个可判断的维度比如事实准确性、数字是否与来源一致、格式是否合规、语气是否对、有没有遗漏关键要点。Feedback反馈不过的时候不能只说重写必须具体到第 3 段那个 47% 来自哪个数据源请核对后改成 4.7%并在末尾加上环比说明。Retry重试把 Feedback 作为新的上下文塞回 Generator让它重写而不是从头再来。关键Feedback 的质量直接决定重试能不能收敛。你给一句写得不行它重写十遍还是不行你给一句第三段数字与源数据不符源数据是 4.7%请修正并补一句环比它一遍就能改对。3.2 跟人工 review比差在哪维度人工 reviewVerification Loop延迟几小时几天几秒几十秒成本资深工程师几百块/小时一次 Judge 调用几分钱一致性不同人标准漂移同一份 Rubric每次口径一致覆盖量抽检 5% 顶天100% 全量缺点慢、贵、漏会被模型偏见影响需要工程手段对冲所以 2026 年的玩法不是AI 替代人而是AI 拦掉 95% 的低级错误人只看那 5% AI 拿不准的。4、生产级实现LangGraph 结构化 Rubric下面这套是 2026 年的标准做法Generator 出稿 → Grader 按 Pydantic 定义的多维 Rubric 打分 → 不过就把结构化反馈塞回去重写最多 2 轮防止死循环。# verification_loop.pyfrom__future__importannotationsimportoperatorfromtypingimportAnnotated,Literal,Sequence,TypedDictfromlanggraph.graphimportStateGraph,ENDfromlangchain_openaiimportChatOpenAIfrompydanticimportBaseModel,Field# ---------- 1. 状态 ----------classVState(TypedDict):task:str# 原始任务draft:str# 当前 Agent 草稿source_facts:str# 参考资料用于事实核对attempts:int# 已重试次数max_attempts:int# ---------- 2. Rubric把好拆成结构化维度 ----------classRubricScore(BaseModel):factual:intField(ge1,le5,description事实准确性数字/引用是否与 source_facts 一致)format:intField(ge1,le5,description格式合规是否按要求的结构输出)tone:intField(ge1,le5,description语气是否符合目标读者)coverage:intField(ge1,le5,description要点覆盖有没有漏掉 task 要求的关键点)pass_:boolField(description综合判定是否通过)feedback:strField(description不通过时必须给出具体到段落/数字的修改建议)# ---------- 3. Generator出稿 ----------defgenerator(state:VState)-VState:llmChatOpenAI(modelgpt-5-mini,temperature0.3)promptf你是运营分析师。任务{state[task]}参考资料{state[source_facts]}{上一版未通过评审请按下面反馈修改state.get(feedback,)ifstate.get(feedback)else}直接输出最终稿。respllm.invoke(prompt)return{draft:resp.content,attempts:state[attempts]1}# ---------- 4. Grader审稿用更大/不同的模型 ----------defgrader(state:VState)-VState:# 关键裁判用比 generator 更强的模型避免学员改作业给学员打分judge_llmChatOpenAI(modelgpt-5,temperature0)judgejudge_llm.with_structured_output(RubricScore)score:RubricScorejudge.invoke(f任务{state[task]}\n参考资料{state[source_facts]}\n待审稿件{state[draft]})return{draft:state[draft],feedback:ifscore.pass_elsescore.feedback,rubric:score.model_dump(),}# ---------- 5. 路由 ----------defroute(state:VState)-Literal[pass,retry,give_up]:ifstate.get(rubric,{}).get(pass_):returnpassifstate[attempts]state[max_attempts]:returngive_up# 别死循环交给人returnretry# ---------- 6. 构图 ----------defbuild_verification_loop():gStateGraph(VState)g.add_node(gen,generator)g.add_node(judge,grader)g.set_entry_point(gen)g.add_edge(gen,judge)g.add_conditional_edges(judge,route,{pass:END,retry:gen,give_up:END,# 上线时这里通常接 human-in-the-loop 队列})returng.compile()if__name____main__:appbuild_verification_loop()outapp.invoke({task:写一段本季度运营复盘包含 DAU 同比,source_facts:本季度 DAU 123 万去年同期 117.4 万同比 4.7%,draft:,attempts:0,max_attempts:2,})print(out[draft])注意几个工程细节Grader 用强模型Generator 用快模型——审贵写便宜整体成本才可控source_facts同时喂给 Generator 和 GraderGrader 才有对照标准答案的能力不然它只能凭感觉打分give_up分支在生产上不要直接 END要扔到人工审核队列而不是把不合格的稿子发出去。5、2026 年的关键改进点5.1 从一句话打分到多维结构化评分2024 年的 Judge 提示词长这样请判断下面这段输出是否合格回答是或否 ...这种 judge 有两个毛病标准漂移、反馈没法用。2026 年的做法就是上面代码里的RubricScore——每个维度 1–5 分每个分数都有明确锚点最后一个pass_字段做综合判定一个feedback字段装可执行建议。更进一步生产里会把 Rubric 放进版本管理LangSmith Prompt Hub / Promptfoo每次改评分标准都留 diff跟代码 review 一个待遇。5.2 裁判与运动员不同模型自己写自己判在学术上叫self-preference bias——模型倾向于给自己写的东西打高分。2026 年的对冲手段大小模型错配生成用gpt-5-mini/Claude Haiku评审用gpt-5/Claude Opus同模型不同温度评审temperature0生成temperature0.3–0.7多裁判投票关键场景起 3 个 judge不同厂商模型2:1 多数决能显著降低单模型偏见Reference-guided grading有标准答案时把参考答案一起塞给 judge它就不敢乱打。一个经验值judge 模型比 generator 大一级事实性错误的拦截率能从 ~60% 提到 ~85%。5.3 Budget-Aware Retry不是无限重写Verification Loop 最容易被忽略的成本是重试风暴。2026 年的标准做法最多 N 次重试一般 2–3 次超过就转人工重试时把上次的 Rubric 分数一起喂回去让模型知道上一轮 factual 只有 2 分这轮重点改数字指数退避 熔断同一个 task 连续 3 次都不过直接报警不要继续烧钱失败样本自动进 golden dataset——这就接到了第 4 篇的 Hill Climbing Loop。6、适用场景与性能基准场景推荐度说明客服话术 / 对外文案⭐⭐⭐⭐⭐错误直接面对客户必须过审代码生成 / PR 描述⭐⭐⭐⭐⭐配合单元测试当硬 judge比 LLM judge 还靠谱周报 / 复盘 / 邮件⭐⭐⭐⭐事实性和格式问题高频创意写作 / 头脑风暴⭐⭐过度审核会扼杀多样性建议只审事实错误实时聊天1s 延迟⭐多一轮 judge 延迟翻倍不适合一组 2026 年参考数字GPT-5 系列LangGraph单次评审延迟1–3 秒评审本身的 token 开销约生成成本的30%–50%一次平均重试次数1.2–1.8 次事实性错误拦截率80%–90%有参考资料时综合任务通过率含重试从裸生成的 ~55% 提升到 ~85%单条总成本约裸生成的1.8–2.5 倍但事故成本下降一个数量级。7、总结Verification Loop 是 Loop Stack 的第二层——它不替 Agent 干活它保证 Agent 干的活敢拿出去见人。核心记忆点没有 Verification 的 Agent 是裸奔的打工人越自主事故越大Rubric 必须拆成维度别让 judge 凭感觉说行不行Feedback 要具体到段落和数字不然重试十遍也没用Judge 模型要比 Generator 强一档关键场景多裁判投票重试有预算超限转人工别让 Loop 自己把自己烧穿失败样本自动沉淀这是下一篇 Hill Climbing Loop 的燃料。下一篇我们再往上爬一层Agent 会干活了、活也能过审了那它能不能自己被事情叫醒而不是等用户来戳一下这就是 Event-Driven Loop。我是小鱼CSDN 博客专家AIGC 技术MVP专家阿里云 专家博主51CTO博客专家企业认证金牌面试官多个名企认证特邀讲师等名企签约职场面试培训、职场规划师多个国内主流技术社区的认证专家博主多款主流产品(阿里云等)评测一等奖获得者关注小鱼学习【人工智能与大模型】最新最全的领域知识。