如何在智能体工程中使用循环构建最难的产品

引言

在某些圈子里，循环是智能体工程的核心，这已不是什么新闻。

在花费了万亿令牌仅用智能体构建了一个前沿的机构投资流程（@openforage）之后，以下是一些关于“智能体循环”以及如何思考并高效利用它们的想法。

关于循环的思考

循环只是一种直观的机制：大众已经学会，向一个问题投入更多令牌可以提高解决方案的质量（对于大多数问题而言）。

这应该不难理解，但往往容易被遗忘。像人类一样，智能体在大多数事情上的第一次尝试通常不是最好的。我从未遇到过某个会话中我觉得智能体的第一次尝试无法改进的情况。

向问题投入更多令牌可以让它们探索更大范围的解决方案空间（广度），并让它们能够推理各种解决方案的更多维度（深度）。就像人类一样，智能体推理对于提出新颖且超出常规分布的解决方案非常有益。

话虽如此，令牌是昂贵的，前沿模型并不只是为了解决极其困难的问题而训练的——有些人只对利用智能体进行确认偏差和精神错乱感兴趣，在这种情况下，智能体所需的唯一能力就是说“是的，你完全正确”。

因此，这些前沿模型被训练和调优成“令牌高效”并且能够恰当地提供“快速响应”。不幸的是，这与（至关重要的）范式相悖——向问题投入更多令牌会显著提高解决方案的质量。

所以，我们发明了循环作为一个合理的折中方案。精神错乱/闲聊爱好者群体可以获得快速响应，而试图解决困难问题的构建者则可以轻松地向问题投入（数十亿）令牌。

愚蠢循环的问题

所以，我们确定了向困难问题投入令牌是有益的，而且我们现在已经达到了模型智能水平，足以让智能体设定合理困难的目标，并在长期会话中持续工作，有些长达一周。

这听起来像乌托邦，但对这种循环的幼稚实现几乎总是会带来一堆垃圾。你要么得到偏离原始想法太远的东西，要么得到充满太多错误的东西，基本上毫无用处。

为什么？

幸运的是，解释起来既直观又令人满意。

在一个愚蠢的循环中，有三件事同时发生。

错误在累积

早期发生的智能体错误可能会累积并失控，就像试图在不牢固的地基上建造一座极高的塔。你会发现，在长期会话早期引入的错误决策、设计或错误会继续影响在会话后期编写的代码和流程。

这种变体很多，但一个常见（且恶劣）的例子是在早期做出一个非常糟糕的设计选择，然后在循环的后期通过强制执行这个糟糕的设计选择并以此为基础构建整个基础设施来加倍坚持。

并不是说你的智能体很蠢，而是上下文压缩让它“忘记”了设计选择是一个“妥协”而非有意的产物。

缺乏有意义的迭代

最近的一个梗是@pmarca的“retardmaxxin”推文风暴，他采取了一种简化的立场，认为内省是坏事。

表面上看，这似乎是一个奇怪的立场，但简单的推论是：没有迭代的内省是坏事。生活的意义在于进步。为内省而内省往往恰恰缺乏进步。

有很多极其聪明的人，我们永远不会感受到他们的影响力，因为他们太忙于陷入自己的思维，只会将自己的想法与廉价而肤浅的现实模拟对抗。

同样，智能体也不会从内省中受益。当你让智能体用相同的上下文审查自己的工作时，它不会在改善情况方面取得有意义的进展。这方面的改进是肤浅的。

无论是人类还是智能体，都是在给定上下文中从解决方案分布（所有可能解决方案的集合）中提取解决方案。如果没有上下文的改变，我们不太可能提取出与当前方案相差甚远的另一个解决方案。

你是否曾经写过、画过或创造过某样东西，检查过后，以为自己尽了最大努力而沾沾自喜，结果几天后回来却觉得那完全是狗屎？

这之所以可能，是因为你允许自己改变上下文（不同的一天、不同的心情等），从而从不同的解决方案分布中提取。

因此，困在愚蠢循环中试图改进自己工作的智能体，通常只能获得一些边际改进。

没有北极星

如果没有一个实现/验证的目标作为北极星，智能体可能会无限偏离，因为每次上下文压缩都会让它们离原始意图越来越远。

编写更好的循环

为了解决愚蠢循环的问题，我们需要解决三件事：

• 我们需要一种机制，能够早期遏制错误并防止它们累积

• 我们需要一种机制，能够通过引入不同的上下文让智能体从更广泛的解决方案分布中提取，并提供有意义的目标让智能体真正地爬山目标，从而实现有意义的迭代

• 我们需要一个北极星

这就是为什么我们在循环中使用验证作为关键组件，因为它恰好能解决愚蠢循环的所有问题。

在你的智能体实现了一些东西之后，你创建一个具有全新上下文、不受实现上下文污染的新智能体，来验证实现智能体的工作。

你需要尽早且频繁地进行验证。同样重要的是，你的验证智能体每次都要有全新的上下文——这可以让它们避免上下文枯竭的问题，而且随着代码/解决方案的变化，验证智能体从不同的分布中提取反馈，该反馈被注入到实现智能体中，使其也能从不同的分布中提取解决方案，以此类推。

在智能体工作流早期进行验证，可以让你在误解和错误演变成永久性设计选择之前就将其捕获，否则后续的智能体将不再将其视为妥协并开始围绕它们构建。

频繁进行验证则是提供反馈，让实现能够朝着更好的解决方案迭代。这就是“向解决方案投入更多令牌”以获得更好解决方案的机制，同时它也是北极星，防止规格漂移。

要保持这样的心态：你寻找的解决方案位于一百次迭代的终点。你希望验证智能体尽可能频繁地介入——向实现智能体提供反馈。验证非常（令牌）昂贵，因此验证的频率和强度就成了一个（框架）优化问题。

一般的理解是，验证进行得越频繁，最终解决方案的质量就越高，因为你向问题投入了更多的令牌，并且解决方案经历的迭代次数也会更多。

当然，这仅在你有好的验证时才成立。

什么构成了一个（简单的）好验证

一个好的验证必须由有意义的评分标准来引导。你几乎总是应该花时间设计好的评分标准，用于你想验证的内容。

例如，如果你想验证代码的整洁性，你可能会关注：1）代码的可扩展性，2）变量命名，3）代码的模块化，4）有意义的规范化等。

在你在意的整洁代码的每个维度内，你可以进一步识别出捕获该维度某个方面的粒度字段。这些字段应该如何评分，以及这些评分如何聚合到单个维度，应该有明确的定义。

然后，验证智能体可以参照评分标准客观地给解决方案打分，并向实现智能体提供反馈以便迭代。缺乏评分标准会使验证极其模糊，从而使你的迭代充满噪声。

有几种方法可以定义“好的验证/好的分数”。

你可以使用固定阈值，例如总分超过某个分数（比如90分）就停止。也可以使用百分比阈值，例如当解决方案相比上一个解决方案的改进不超过某个百分比（比如10%）时停止。你还可以使用早停法，例如当解决方案在若干次尝试（比如3次迭代）后没有改进时停止。你可以并且应该探索组合使用不同的停止机制。

通过定义“好的分数”，你也自然地创建了循环的停止点，从而形成以验证为中心的清晰智能体工作流。

我以“整洁代码”为例来验证，因为这很容易解释（教学上很干净），但你的验证中至少有一个主要维度应该直接与项目/规格相关联。你需要一种“这个解决方案在实现规格或解决我的问题方面有多好”的验证。

这就是作为北极星，防止规格漂移。你不希望在要求一艘真正的船时，却收到一幅印象派的船画。

经典循环

想要构建某物

-> 设计好的评分标准来验证解决方案

-> 确定一个“好”的阈值

-> (1) 智能体实现

-> (2) 实现尽早且频繁地送去验证

-> (3) 验证通过？

-> (4) 如果是，结束循环；如果否，带着验证反馈回到(1)

结论

验证是有层次的，你可以设计真正强大的验证系统，以避免被智能体垃圾炮轰。然而，即使是基本的、设计良好的验证系统也能让你走得很远。

以上就是我关于智能体工程中有意义循环的文章。如果这有帮助，我很希望得到一些反馈，以便我可以继续这个关于用智能体工程构建真正困难产品的系列。