在构建前沿机构级投资流程（@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）

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

验证的层级与实践意义

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

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

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

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

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

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

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