Agent 如何避免无限循环？

简化版

不能让 Agent 仅凭模型输出的“完成”决定循环终止。生产系统要同时设置最大步数、时间、Token、费用和工具调用预算，并用确定性完成条件、重复动作检测、无进展检测控制退出；达到边界后返回可恢复状态，转人工或降级，而不是继续重试。

详细版

Agent 循环一般是“规划—行动—观察—再规划”。无限循环常由目标含糊、工具持续失败、观察没有新信息、模型反复改计划或完成条件不可验证引起。

控制器至少维护这些状态：

step_count, deadline, token_used, cost_used
last_actions, state_fingerprint, progress_score
task_status, side_effect_log

每轮先检查硬预算，再校验动作是否合法；执行后比较新旧状态。如果连续多轮状态指纹相同、同一工具参数重复出现，或进度分数没有改善，就触发澄清、换策略或停止。成功必须由业务条件验证，例如目标文件存在且测试通过，不能只接受模型说 done。

完整版教学

一、循环为什么会失控

LLM 不持有可靠的程序计数器，也不能天然证明目标已经完成。工具报错后，它可能换一种措辞重复同一调用；搜索没有答案时，它可能不断改写查询；目标模糊时，它还可能持续“优化”已经可用的结果。

plan -> act -> observe -> plan
          ^                 |
          +--- 无新信息 ----+

记忆钩子：模型负责提出下一步，控制器负责决定这一步还能不能走；终止权必须在确定性代码手里。

二、硬预算是最后一道保险

无论推理多合理，都要设置不可突破的上限：最大步骤、墙钟时间、累计 token、费用、工具调用次数和单工具重试次数。多个限制要同时存在，因为 20 步可能每步只花 0.1 秒，也可能每步等待 30 秒。

假设限制为 12 步、60 秒和 0.5 元。Agent 第 7 步累计 0.46 元，即使时间只过 15 秒，也只能执行预计成本不超过 0.04 元的动作。预算检查应发生在调用前，而不是账单产生后。

三、完成条件必须可以验证

“我认为任务完成了”只是模型声明，不是证据。不同任务要有对应验证器：代码任务运行测试，数据任务核对行数与约束，预订任务检查确认号，研究任务检查必需问题是否都有来源。

目标	弱完成条件	可验证条件
修复代码	模型输出 done	测试通过且 diff 在允许范围
发邮件	已生成正文	收件人确认后 API 返回 message_id
收集资料	找到了很多网页	必需字段齐全且每项有证据

验证失败应产生结构化原因，让下一轮能针对缺口行动；只返回 false 容易让模型盲目重试。

四、用状态指纹识别重复

动作文本稍有不同，不代表取得进展。可以把规范化后的工具名、关键参数、结果摘要和任务状态做哈希，形成状态指纹。最近窗口中同一指纹出现三次，通常说明进入环路。

fingerprint = hash(normalize({
    "tool": tool_name,
    "args": semantic_args,
    "result": result_code,
    "state": task_state,
}))

敏感参数不能直接写日志；哈希前也要规范化时间戳、请求 ID 等随机字段，否则每次都会得到不同指纹，检测不到实质重复。

五、无进展检测比重复检测更广

有些循环每一步都不同，却没有靠近目标。例如搜索词一直变化，但必需字段覆盖率始终是 60%。因此控制器要定义进度指标，如已完成子目标数、测试失败数、缺失字段数或验证器分数。

若覆盖率依次为 40%、60%、60%、60%，连续两轮增量为零，就应触发策略切换；若新策略后仍不改善，则停止。进度不是让模型自评“80%”，而应尽量来自外部状态或验证器。

六、重试要有分类和退避

超时、限流等瞬态错误可以指数退避重试；参数非法需要修正参数；权限拒绝不能靠重试解决；资源不存在则要换数据源或询问用户。把所有异常统一重试，是工具循环最常见的根源。

第 1 次等待 1s -> 第 2 次 2s -> 第 3 次 4s -> 停止

写操作还必须携带幂等键。否则 Agent 因响应超时再次调用付款接口，可能实际付款两次。停止循环不仅是省成本，也是在保护现实世界状态。

七、退出时要保留可恢复状态

达到预算不应只抛出“失败”。控制器应保存已完成步骤、最后可靠状态、未满足条件、工具副作用和建议下一步。这样人工可以接管，稍后也能从检查点继续，而不是重新执行全部动作。

退出策略可分为成功、需要澄清、可重试失败、预算耗尽、高风险拦截和人工接管。每种状态对用户的提示和后续恢复方式不同，不能都映射成 HTTP 500。

八、用故障场景验证循环控制

测试不能只跑顺利路径。应注入工具连续超时、返回相同结果、交替返回矛盾结果、完成验证器永久失败、模型反复选同一动作等故障。

一个 200 条任务的测试集中，可统计任务完成率、平均步骤、P95 步数、无进展停止率、错误副作用数和人工接管率。若完成率提高 1%，但 P95 从 8 步涨到 40 步，系统可能只是用暴力重试掩盖问题。

九、常见误区与追问

误区：设置最大步数就解决了循环。 它只能止损，不能识别无进展原因或提供恢复路径。
误区：模型输出 done 就代表完成。 必须由业务验证器检查真实状态。
误区：每次工具参数不同就不算重复。 应比较规范化语义和任务状态，而不是原始字符串。
误区：工具失败多重试几次总会成功。 权限和参数错误重试无效，还可能扩大副作用。
误区：超时以后直接从头运行最简单。 已发生的写操作可能被重复执行，需要检查点和幂等。
追问：最大步骤设多少合适？ 根据成功任务的步骤分布和业务成本确定，并按任务类型分档。
追问：如何检测模型只是换说法？ 对工具、语义参数、结果和状态规范化后生成指纹。
追问：停止后怎样让用户继续？ 返回缺失信息和检查点，补齐参数后从安全状态恢复。

十、加强记忆

Agent 循环控制记住“四道闸”：硬预算限制最多走多远，完成验证器证明是否到达，状态指纹与进度指标发现原地打转，分类重试和检查点保证安全退出。模型可以建议行动，但控制器掌握终止权；涉及副作用时，再加幂等键和操作日志，才能既防烧钱又防重复执行。

简化版

详细版