代理循环成本高昂，因为每次调用都要为之前的所有步骤付费

关于代理成本的讨论通常集中在每token的价格上。哪个模型更便宜，这周谁降价了，便宜的模型是否足以应付那些枯燥的步骤。真正决定一次运行成本的因素在于别处：你为相同的token支付了多少次。循环中的每次调用通常都会重新发送整个累积的上下文。原始任务。代理已经执行的每一步。返回的每个工具结果。模型不会免费记住上一次调用，所以你必须再次发送所有内容。第一步很便宜。到了第二十步，它携带了之前十九步的历史，却只为了执行同等微小的工作。用整数来勾勒大致轮廓：一次运行需要20步，平均每步大约6000个token（包括重新发送的历史和新输出），那么一个任务大约消耗12万个token。这些数字是编造用来示意大致情况的；你的实际平均值取决于你的模型以及你向前拖拽了多少历史。每步成本随运行过程攀升，而你还要用这个不断上升的数字乘以一个未被限制的步数。两个实际后果。必须在调用之前检查上限，而不是之后。将下一次调用可能消耗的token加到运行总计数中，如果总数会超过你的上限，则停止调用而不是执行。事后检查的话，你已经花费了本想节省的，一次昂贵的调用接着一次。而且，上限不能放在提示词中。'一旦花费了十美元就停止'只是一个建议，一个专注于完成任务的代理会想办法绕过它。它必须放在代理无法控制的地方：你的循环代码，或者每次调用都必须经过的网关。我们把上限放在网关，主要是为了避免在每个新循环中重复编写同样的检查。它可以为每个API密钥或每个模型设置美元限额，因此新代理从一开始就带有上限。早期发现问题的是每次成功任务的成本，而不是每token成本。如果循环用了40个混乱的步骤来完成本应5步完成的事情，便宜的token也救不了你，而循环变得越来越迂回会在账单出来之前很久就表现为每任务成本上升。这更多是一个追踪问题，而非计费问题。对于你的代理，停止条件是有人有意选择的上限，还是循环只是运行直到它碰巧完成？好奇是否有人既限制每步又限制每次运行，因为两者捕捉的问题不同。