Lynkr

披露：我是 Lynkr 的维护者，这是一个带有循环防护中间件的开源 LLM 网关，因此我在本文的论点中存在利益关系。请将本文视为一个可供挑战的论题，而非中立综述。

Agent 讨论已经从提示词转向循环：一种持续运行直到模型决定完成任务的读取-行动-观察循环。我的反主流观点是，大多数所谓的循环工程都在优化错误的变量。更长、更丰富的循环通常只是收敛失败的伪装。 设计良好的循环是那个知道何时停止的短循环。

我所反对的共识

当 Agent 失败时，默认的做法是给循环更多：

  • 在放弃前给予更多回合。
  • 向窗口塞入更多上下文。
  • 增加更多脚手架：规划器、批评者、反思步骤、子代理生成子代理。
  • 使用更多反馈进行更多重试。

隐含的理论很简单：智能在迭代中累积，因此更多回合应该意味着更多收敛。有时这有效。但在实际流量中，大多不成立——即使有效，成本结构也残酷。

来自代码 Agent 的一个具体例子：给一个能力不足的模型一个仓库级重构任务，它通常不会通过"更长时间推理"获得成功。它会误读一个依赖，锚定在错误的文件上，然后在接下来的十几回合里详细阐述这个错误。循环没有拯救模型。它在资助失败。

为什么更长的循环会使错误的事情恶化

有两件事会在循环中累积，而两者都不是智能。

1. 循环成本增长迅速。 每个回合都会重新发送累积的上下文。一个 20 回合的会话不仅仅是 20 个单次调用连续执行；后面的每个回合都会将之前的令牌重新拖入模型。在许多代理工作负载中，循环成为服务预算中最昂贵的对象，而"增加更多回合"成为你可以调整的最昂贵的旋钮。

2. 可靠性在依赖步骤中崩溃。 即使每步可靠性乐观，多步链也会迅速退化。长循环不会平均错误；它们会乘以保持正确轨迹的概率。那个"只需要更多回合"的代理通常是一个带着更多确信走向错误分支更深处的代理，因为每个回合都将其自己的早期错误视为事实来条件化。

我们之前写过关于填充上下文窗口如何使代理变差而非更智能：注意力被稀释，检索锚定在错误的块上，信号被埋没。循环长度是时间轴上的相同失败。更多不是更好。

长循环实际上在发出什么信号

当一个代理需要 30 个回合来做某事时，这通常不是框架聪明。这是两个失败之一的信号：

  1. 任务被路由到一个无法完成的模型。 循环是那个模型的挣扎。脚手架很少能修复一个能力不足的模型决策；它通常只会使失败更加复杂和昂贵。
  2. 任务确实有很多步骤。 在这种情况下，工程问题不是"如何允许更多回合"，而是"如何廉价地验证每个步骤，以便在第 3 回合捕获错误分支，而不是复合到第 30 回合？"

两者指向同一个方向：要么将步骤分配给更好的模型，要么在继续前验证步骤。两者都说：不要增加回合并抱有希望。

循环工程应该真正是什么

如果循环是成本和错误累积的地方，那么好的循环工程应该最小化累积，而不是最大化每回合的能力。

1. 硬性限制循环。 每个循环都需要一个它不能超过的回合上限和工具调用上限，彻底停止。这不是作为紧急回退——而是作为一级设计约束。一个可以永远运行的循环，在某些输入上，会让你花费巨资产生垃圾。

2. 廉价地验证每个步骤。 对循环来说，最高杠杆的添加通常不是另一个推理阶段。而是对步骤输出进行快速、确定性的检查，以捕获你实际看到的失败模式：截断、格式错误的工具调用、空回答、退化循环、重复回响。检测胜过预测，因为你手头已经有输出。

3. 升级失败的步骤，而不是整个会话。 当一个步骤验证失败时，对那个步骤使用更好的层级重做。不要授予整个循环更多回合来挣扎。升级是针对性的；更多回合是一张空白支票。

这也困扰我们的部分

我们也不例外。在 Lynkr 中，我们推出了简洁模式，旨在通过推动模型给出更短回答来节省输出令牌。我们的验证器随后将一些这些简短回答误读为低努力失败，并将琐碎请求升级到更高层级，进入更长、更昂贵的路径。

修复只是一个谓词。但更广泛的教训不是。循环中的检查本身就是循环成本和失败面的一部分。 "添加验证"不是免费的美德；一个糟糕的验证器可以像幼稚的重试一样急切地延长循环。验证必须以与任何其他回合相同的怀疑来设计。

直白的论题

许多流行的循环工程在优化每回合能力的同时，将回合数视为免费。这完全颠倒了。在实际流量中，回合数往往是主要成本和复合错误的主要来源。

如果任务需要更多智能，为该步骤购买更多智能。如果任务需要更多可靠性，验证该步骤。如果循环不断增长，将其视为失败信号，而非复杂性。

让循环更短。让它停止。这才是工程。

Lynkr 是 Apache-2.0 许可的自托管项目。本文背后的循环防护中间件和步骤级升级想法都在仓库中：github.com/Fast-Editor/Lynkr。如果你见过循环运行太久并知道原因，我很乐意听你的实战故事。