news 2026/7/5 2:14:44

为什么简单的Agent循环会崩成slop?结构化验证才是解药

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
为什么简单的Agent循环会崩成slop?结构化验证才是解药

在构建前沿机构级投资流程(@openforage)时,我们只用Agent就花掉了上万亿token。现在看来,循环(loops)几乎是所有有意义agentic工程的核心

扔更多token能提升解的质量,这点已经不是新鲜事。但很多人在实际落地长时运行的Agent会话(有时长达一周)时,却发现天真的循环几乎必然产出大量无用slop——要么严重偏离原始意图,要么充斥无法修复的bug。

为什么?

因为在朴素的循环里,同时发生了三件事,而这三件事会把你的工程拖进深渊。

为什么扔更多token有效?(先把基础说清楚)

和人类一样,Agent第一次输出的结果几乎永远不是最好的。

扔更多token能让Agent:

  • 广度探索更大范围的解空间
  • 深度推理更多维度的权衡

这能产生真正新颖、分布外(out-of-distribution)的方案。

但前沿模型被训练成“token高效”和“快速响应”,这与“多token=高质量”直接冲突。于是我们发明了循环——既满足想快速聊天的人,又让想解决难题的builder能轻松扔几十亿token。

天真的循环为什么必然崩盘

1. 错误会指数级 compounding

早期Agent犯的错误会像在不稳的地基上建摩天大楼,越往上越危险。

一个早期做出的糟糕设计决策,后续Agent会因为context compaction而“忘记”它只是妥协方案,反而把它当作既定事实,并在此基础上继续构建整个基础设施。

这不是Agent笨,而是上下文压缩让它失去了对“这是妥协”的记忆。

2. 缺乏有意义的迭代

很多聪明人困在自己脑袋里,只用廉价的内心模拟和现实对抗,结果影响力为零。

Agent也一样。让它用相同上下文审查自己的工作,几乎只能得到边际改进。

人类和Agent都是从给定上下文对应的解分布中抽取方案。没有上下文变化,就很难跳出当前解的附近。

你有没有过这种经历:刚写完/画完/做完一个东西时觉得“这是我目前最好的”,几天后回头看却觉得“这是垃圾”?

那是因为你给了自己新的上下文(不同日子、不同心境),从而从不同的解分布中重新抽取。

朴素循环里的Agent做不到这一点。

3. 没有北极星(North Star)

没有明确的验证目标和实现方向,Agent会无限漂移。每一次上下文压缩都让它离原始意图更远。

最终你得到的,可能是一幅印象派小船,而你本来要的是能真正航行的船。

更好的循环该怎么写

要解决以上三个问题,我们需要同时实现三件事:

  1. 尽早拦截错误,阻止它们 compounding
  2. 给Agent提供有意义的迭代(引入不同上下文 + 明确的优化目标,让它真正能hill-climb)
  3. 提供一个清晰的北极星

验证(Verification)恰好同时解决这三件事。

核心做法是:在实现Agent完成工作后,创建一个全新上下文、未被污染的验证Agent,让它审查实现Agent的工作。

  • 早做:在早期就捕获误解和bug,防止它们变成后续Agent不再认为是“妥协”的永久设计。
  • 常做:频繁反馈让实现不断迭代。这既是“扔更多token”的机制,也是防止spec drift的北极星。

把心态调整为:你想要的解在第一百次迭代之后。验证Agent要尽可能频繁介入。

验证虽然很贵(token消耗大),但频率和强度的权衡正是harness优化的核心。验证做得越好、越频繁,最终方案质量就越高。

什么才算好的验证?

好的验证必须有有意义的rubric(评分标准)

你几乎总应该花时间设计清晰的验证维度。

例如验证“代码整洁度”时,你可能关心:

  • 代码可扩展性
  • 变量命名
  • 模块化程度
  • 有意义的规范化

在每个维度下,再进一步拆解出可量化的细粒度字段,并定义如何打分、如何聚合成分数。

没有rubric,验证就会变得极度模糊,迭代也会充满噪声。

此外,至少有一个主要验证维度必须直接绑定到项目规格/问题本身——“这个方案在多大程度上解决了我的原始问题/达成了spec”。这才是真正的北极星。

停止条件(Stopping Criteria)

你可以组合使用:

  • 固定阈值(总分超过90分就停)
  • 改进阈值(连续几次改进小于10%就停)
  • 早停(连续N次尝试无改进就停)

定义“好分数”的同时,也自然定义了循环的终止点。

规范的Agentic循环(Canonical Loop)

想要构建某物

设计清晰的验证Rubric

设定“好”的阈值/停止条件

实现Agent执行

验证Agent早且频繁审查
新鲜上下文

验证通过?

结束循环
输出最终方案

把验证反馈注入实现Agent

这就是最基础却极其实用的结构。

验证的层级与实践意义

验证可以设计得非常强大(多层级、不同模型角色、校准机制等),足以对抗“agentic slop炮”。

但即使只是一个设计良好的基础验证系统,也能让你走得很远。

在真实构建机构级投资流程的过程中,我们深刻体会到:循环本身不是魔法,结构化的验证才是让循环真正工作的引擎

它把“扔更多token”从赌博变成了可控的、持续收敛的工程过程。


实践建议
下次你用Agent做任何非 trivial 的任务时,先花15-30分钟设计一套rubric(至少包含1个直接绑定spec的维度 + 2-3个质量维度)。然后把验证频率调高到“早且频繁”,观察最终输出质量和迭代次数的变化。

你目前正在构建的Agent工作流里,最该加入验证机制的是哪个环节?

我是紫微AI,在做一个「人格操作系统(ZPF)」。后面会持续分享AI Agent和系统实验。感兴趣可以关注,我们下期见。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/5 2:13:55

2342342342

123

作者头像 李华
网站建设 2026/7/5 2:13:02

说说程序员、博客、论坛及个人专业相关知识的提高

遇到问题必须努力解决 在写过程中发现有些知识点觉得比较难,自己无法很好的讲述出来,所以必须去google,找许多的资料,直到自己弄懂了,才敢在博文里用自己的语言表达出来,这个找资料、理解资料、再表述出来…

作者头像 李华
网站建设 2026/7/5 2:11:14

Git命令超全终极手册|从零到精通 开发/运维必备完整版教程

1. 命令简介Git 是一个开源的分布式版本控制系统,由 Linus Torvalds 于 2005 年为管理 Linux 内核开发而创建。它旨在高效处理从小型到超大型项目的版本管理,具有速度快、设计简单、完全分布式、对非线性开发模式(数千个并行分支)…

作者头像 李华
网站建设 2026/7/5 2:10:07

09102黄大年茶思屋榜文91期 第2题 TDD系统下的SRS与PMI联合信道重构

黄大年茶思屋榜文91期 第2题 TDD系统下的SRS与PMI联合信道重构 摘要 针对TDD系统单独依赖SRS或PMI测量精度不足、异类信息维度不统一的痛点,本文给出基于时频波束三维稀疏融合的现货级落地方案,在终端移动速度5km/h、SRS信噪比-15dB场景下,可…

作者头像 李华
网站建设 2026/7/5 2:08:42

CSDN文章如何轻松破百赞

【保姆级全攻略】CSDN文章轻松破百赞:从选题、写作、排版到运营,一套模板直接复制套用 摘要 很多程序员在CSDN兢兢业业写技术博客,文章阅读几百、收藏寥寥、点赞常年卡在10个以内,辛辛苦苦整理的干货无人认可。本文结合大量百赞爆…

作者头像 李华
网站建设 2026/7/5 2:07:41

云原生 AI 模型灰度:别把新模型一次性推给所有流量

云原生 AI 模型灰度:别把新模型一次性推给所有流量 一、模型灰度比普通服务更需要谨慎 普通服务灰度主要关注错误率、延迟和资源。AI 模型灰度还要关注答案质量、引用准确性、成本变化和用户反馈。新模型接口兼容,不代表业务效果一定更好。 模型上线如…

作者头像 李华