Thinker-Worker-Verifier:把自我改进 Agent 写成有限状态机1×0:007:110:08开场与事件播报1:21技术拆解3:52工程意义5:15落地建议6:35收尾0:08主播今天这期,我们看一个很小、但很值得工程团队抄作业的动态。Regolo 在六月二十四日发了一篇文章,配套放出了一个 Thinker、Worker、Verifier 的 Crew A I 示例。它不是又造一个万能 Agent,而是把「自我改进」这四个字,写成一个有限状态机:先想,后做,再验收,没过关就回到前一步。0:33主播为什么这件事值得放进今天的 AI Loop Engineering?因为过去很多团队说 self improving agent,其实只是让模型多试几次。Regolo 这份实现的关键,是把循环拆成三个明确角色:Thinker 负责改写任务和形成计划,Worker 负责执行,Verifier 只判断结果是否达标,并给出下一轮改进信号。0:59主播我先把结论放前面:这类结构真正有价值的地方,不是它用了几个 Agent,而是它把「继续迭代」从模型的自由发挥,改成了一个系统可以观测、可以限制、也可以复盘的状态转移。对要把 Agent 放进生产环境的团队,这比一句「让它反思一下」要可靠得多。1:21主播先看第一层,有限状态机。Regolo 的文章把流程写得很朴素:Thinker 接收原始目标,产出更清楚的任务;Worker 根据这个任务完成交付;Verifier 检查输出,如果失败,就把反馈交回 Thinker。这里最重要的工程边界是,循环不是无限的,系统必须有最多迭代次数、失败退出条件和可记录的中间状态。1:52主播这跟普通多 Agent 编排的差别在于,角色不是为了热闹,而是为了隔离责任。Thinker 不直接交付,Worker 不决定验收标准,Verifier 也不去重写成果。职责一旦分开,日志、评估和报警才能分开;否则你只会看到一大段模型输出,很难判断到底是计划错了、执行错了,还是验收标准本身太含糊。2:18主播第二层,是反馈信号要变成结构化输入。很多 Agent 项目会把错误信息直接塞回提示词,让模型自己悟。Thinker-Worker-Verifier 的好处是,Verifier 的反馈可以被设计成固定字段:缺了什么、哪里不满足、下一轮要优先修什么、是否应该停止。这样一来,循环就不只是口头反思,而是一个带状态的控制系统。2:46主播第三层,是可观测性。这里可以把 Arize 六月二十二日发布的 Project Rosetta Stone 放进同一条线看。Arize 那个项目把同一个聊天购物 Agent,做成二十二个以上框架里的参考实现,并且给每个实现配了无观测、Phoenix 观测和 Arize AX 观测三种层级。它的重点不是卖某个框架,而是证明:只要 span 结构统一,Lang Graph、Spring A I、Mastra 这些不同运行时,都可以落到同一套 trace 和评估管道里。3:21主播这正好补上 Thinker-Worker-Verifier 的下一步。如果一个循环只能跑,但看不见每一轮的计划、工具调用、验收结论和用户会话,那它只是一个会重复尝试的黑盒。把每次 Thinker 的计划、Worker 的动作、Verifier 的判定都打成 trace,团队才能问更细的问题:失败是不是集中在某类工具?是不是第三轮以后收益迅速下降?是不是某个验收器太宽松?3:52主播对工程团队来说,这个模式的第一条启示,是不要把「更聪明的模型」当作唯一解。循环系统里的质量,常常来自角色边界、退出条件、评价器和观测,而不是某一次提示词写得更漂亮。模型变强当然有帮助,但如果 Worker 的错误没有被 Verifier 捕捉,再强的模型也会把问题带进下一轮。4:18主播第二条启示,是成本控制要进入循环本身。arXiv 上的 Brick 论文虽然讲的是混合模型路由,但它提供了一个相邻的思路:系统可以按查询难度和模型能力维度做调度,而不是每次都上最贵的模型。放到 Thinker-Worker-Verifier 里,团队可以让轻量模型做第一轮计划或格式检查,把高价模型留给真正有不确定性的执行和最终验收。4:47主播第三条启示,是评价器不要只看最终答案。Agent 失败经常不是最后一句话错,而是中途走错工具、漏掉约束、没有在该停的时候停。一个健康的反馈循环,至少要看四件事:任务改写是否保留原意,工具调用是否必要且参数正确,验收反馈是否具体,循环终止是否合理。只用最终通过、不通过,太粗了。5:15主播如果你准备在团队里试这个模式,我建议从一个低风险、可验收的流程开始,比如自动整理工单、生成测试计划,或者把内部文档改写成发布说明。不要一上来就让它改线上代码。先把 Thinker、Worker、Verifier 三段的输入输出格式固定下来,再给每一轮加上 trace 标识和最大迭代次数。5:42主播第二步,把 Verifier 写得比 Worker 更保守。它不需要很会创作,但必须非常清楚验收条件。比如,必须覆盖哪些字段,必须引用哪些来源,不能出现哪些风险表述,失败时反馈要能被下一轮直接使用。Verifier 如果只说「不够好,请改进」,整个系统还是会退回模糊提示词工程。6:06主播第三步,先量化循环,而不是急着扩大权限。你可以记录每个任务跑了几轮,哪一轮提升最大,失败原因分布是什么,人工接管发生在哪一步。等这些数字稳定以后,再决定是否接入更多工具、更长链路,或者更贵的模型。Loop Engineering 的核心不是让 Agent 一直转,而是知道什么时候转、为什么转、转完有没有变好。6:35主播今天可以带走的一句话是:自我改进 Agent 的第一步,不是让模型「多思考」,而是把思考、执行和验收拆成可记录的循环。只要这个循环能被限制、被观察、被评价,它才有资格进入生产工程。否则,它只是一个更会绕路的自动化脚本。我们明天继续追踪 AI Loop Engineering 的新动态。
Add more perspectives or context around this Post.