为什么人工智能代理会耗尽预算却无法完成任务，以及如何阻止这种情况

了解为何在“完成”状态未定义时工具调用智能体会持续循环，令牌消耗去了何处，以及哪些停止条件比单纯提高步骤数或预算上限更有效。

1533 词

一个崩溃的自主智能体很容易处理。真正棘手的则是那种永不崩溃的智能体：它不断调用各种工具，生成看似合理的操作步骤，却始终无法到达终点，同时令代币消耗持续增加。本文将解释这种行为背后的机制、失控智能体的资源消耗通常会在何处累积，以及能够阻止这种情况的具体停止条件，从而帮助你设计出能自行判断任务是否完成的智能体循环，而无需依赖更大的资源预算来弥补浪费。

举一个简单的例子：一次无人监督的下午运行任务，收费40美元却没有任何成果。按照代理操作的标准，这算不了什么；各团队还互相讲述过那些无人监控的夜间运行任务，其费用甚至高达四位数。费用高低并非关键所在，重要的是它换来了什么。该代理并未陷入停滞状态，也没有出现任何人可以指出的错误，但它全程都在“忙碌”，实际上却什么工作都没做。

日志中失控代理的表现

打开一个偏离正常轨道的代理的日志，你几乎找不到堆栈跟踪信息。看到的内容更像是一个认真负责的员工，只是忘记了原本的任务是什么。

该智能体先打开一个文件并对其进行总结，然后以略有不同的方式呈现相同内容并再次总结。它进行搜索后认为结果不够理想，于是通过更换几个词重新发起查询。单独看每一步都是合理的。正因如此，粗略浏览时很难发现这种模式：没有哪一步看起来有问题。整个过程根本无法收敛。

模型为何决定停止

如果需要构建或运行智能体，了解这一行为的具体原因十分重要。像 Claude 这样的工具调用模型在每次响应结束时，都会根据一个简短的固定列表给出停止原因。Anthropic 的关于处理停止原因的指南涵盖了多种情况，其中两种对智能体循环尤为重要。第一种情况表明模型认为自己的工作已经完成：

"stop_reason": "end_turn"

第二种情况则表示模型希望调用某个工具并继续执行：

"stop_reason": "tool_use"

智能体循环属于普通的应用程序代码。它发送请求，执行模型要求的任何工具，再将结果传回，如此重复直到模型返回end_turn。没有外部因素能宣告任务已完成。在每个轮次中，模型都会自行判断手头的工作是否已经完成。还存在其他停止原因，比如达到输出token限制，但这些属于中断情况，并非表明任务已经完成的判断。

这一事实就解释了整个失败的原因。当目标设定得过于模糊，导致模型无法判断是否已达成时，总还有其他需要检查的事项，循环便会持续下去，直到有外部因素介入，通常是预算警报。关于循环设计的代码级实现方式，请参阅适用于LLM工具开发的受限智能体循环与可靠TypeScript模式。

这种情况有多常见

人们很容易将此视为某种特定工具的缺陷。但更多证据表明并非如此。一项基于对65位经验丰富的数据科学家和工程师的访谈而进行的RAND公司研究显示，人工智能项目的失败率超过80%，大约是传统IT工作的两倍。该研究针对的是一般的人工智能项目，并非特定智能体，但那些无休止运转却无法创造价值的循环，正是导致此类资源浪费的常见日常因素之一。它们从未出现在会议主题演讲中，却会出现在发票上。

还有更详细的版本在流传。一份被频繁引用的报告讲述了一个递归循环的问题，其在有人干预之前就已产生五位数的支出。这一数字尚未得到独立验证，任何类似的惊人数字都应引起怀疑。不过，这种机制确实存在，并且只会不断加剧：同一个循环在某个下午可能花费40美元，而在无人监管的周末则可能耗费4,000美元。

支出集中的地方

在研究这些失控的开支，并将其与大型智能体集群的运营者所报告的情况进行比较后，会发现资金往往集中在少数几个地方：

无限制的网页检索。 每次获取页面或进行重复搜索都会产生成本。由于没有上限，只要模型认为还存在有价值的资料来源，就会持续进行无止境的检索。
高性能模型却用于低价值任务。 Frontier系列模型因具备更强的推理能力而价格更高，但许多操作步骤，如重新格式化文件、检查状态或重试调用等，并不需要这样的功能。使用较小的模型就能以极低的成本完成这些任务。
永无止境的对话线程。 在持续进行的对话中工作的智能体每次都会重新处理其积累的全部历史记录，这使得即便请求非常简单，数周前的对话线程每次处理的成本也会比最初更高。如果服务提供商支持提示词缓存，可以缓解这一问题，但上下文量依然会不断增长。

被遗忘的调度任务。一旦配置好的周期性任务，即便早已有人使用了其输出结果，它仍会持续运行。

这些情况其实并不罕见。综合来看，它们就如同被遗忘的订阅服务，按令牌而非按月计费。若想从结构层面了解这些成本是如何累积的，可阅读文章为何代理型AI的成本会激增以获得更深入的解析。

应修正停止条件，而非上限

在经历一次高昂的运行成本后，人们的本能反应往往是提高步数或支出上限。但这通常适得其反，因为更高的上限只会让同一个陷入死循环的任务在撞上上限之前持续更长时间。真正有效的做法是让该循环能够察觉到进展已停滞，而这与它是否用尽了步数限额是两回事。

将终点设定在目标中

应将“完成”作为任务的一部分来定义，而非事后才考虑的事项。像“修复失败的测试”这样的指令会让人产生处理导入整理或重新格式化整个文件等额外任务的念头。而“让这个测试通过后再结束”则给出了模型能够明确识别的终点。完成标准越清晰，模型就越容易在恰当的时刻返回end_turn。

让工具结果明确无误

工具反馈应清晰说明操作是成功还是失败。含糊的结果对智能体而言更像是一种重新尝试的提示，而非停止操作的信号。明确的状态字段和清晰的错误信息能够消除导致重复尝试的不确定性。

检测重复行为而非统计步骤数

固定的步数计数器是一种较为粗糙的工具。同一个计数器可能在第11步时就终止一个本应进行15步的有效任务，而却允许一个仅包含2步的循环在触发之前浪费多次昂贵的调用。一种更好的方式是采用重复检测：通过标记连续向同一工具发送参数完全相同的调用，可以直接捕捉到前述模式，而不会对那些本身执行时间较长的任务造成不利影响。

添加人工检查点与严格的花费限制

任何被搁置数分钟以上的任务都应设置有人员检查进度的环节。自动化监控机制可起到补充作用。例如，GitHub的gh-aw提供了可配置的预算警戒机制，一旦工作流的支出超过设定阈值就会立即停止流程，而无需等待有人查看账单才能发现问题。这类监控机制属于安全网，并不能替代合理的停止条件，但在其他措施都失效时仍能限制损失。

活动并不等同于进展

失控流程最令人担忧的并非成本，而是其确定性。该自动化工具的输出从不掩饰，也不承认任何工作是否真的有效。它会持续生成看似合理的步骤，直到有外部因素介入——通常是有人对异常账单感到好奇并加以制止。

这个教训并非是要全面不信任各类代理。而是要避免将动作误认为是进展，无论是在自动化系统中还是许多人工工作中都是如此。

关键要点

在工具调用循环中，模型通过返回end_turn来决定何时结束；如果目标没有明确的终点，它可能永远不会停止。
过度支出往往集中在无限制的研究、用于简单任务的庞大模型、不断增多的任务线程以及被遗忘的定时作业上。
提高预算或步骤限制只会推迟同样的失败；应在任务中明确定义完成标准。
应返回明确的工具执行结果，并检测重复的相同工具调用，而非依赖步骤计数。
对于无人监控的运行过程，需将人工检查点与严格的支出限制相结合。