AI Agent 智能体循环详解：工具调用、停止条件与故障排查

模型提出下一步行动；你的软件决定是否允许执行、记录执行结果，再决定能否发起下一次模型调用。无论是搭建第一个智能体，还是排查一个停不下来的智能体，都应先明确这层分工。

下文涉及的框架行为，均已于 2026 年 10 月 24 日对照各厂商当时的在线文档核实。对比时，我们统一梳理了各框架的计数口径和控制生效位置。文中的客服工单示例和策略建议仅用于说明，并非生产环境中的实测结果。

AI Agent 的智能体循环是怎么运转的？

一个有效的循环是：调用模型 → 调用工具 → 获取观察结果 → 继续循环。只要继续执行已无必要，或不再被允许，就应退出。

可以把它想象成调度员与维修技师的配合：调度员安排下一项工作，技师执行，再把工作报告交回来，供调度员决定下一步。发出检查机器的指令，不等于检查已经完成；一句让人放心的回复，也不能证明维修成功。

在软件中，调度员是大语言模型，也就是 LLM；技师是工具，例如读取数据库、搜索文档、执行命令或修改记录的函数。外围的运行时代码负责把两者连接起来。

以一个假设的工单回复起草任务为例，执行轨迹可能是：第一次调用模型，请求读取工单；第二次，请求读取相关政策；第三次，综合两者生成草稿。一次应用请求中，共发生 3 次模型调用和 2 次工具执行。如果发送回复需要审批，起草任务可以先完成，发送操作则继续等待批准。

任务状态应与对话记录分开保存。状态需要明确：当前处理哪张工单、已采纳哪项政策、是否已有草稿，以及发送是否获得授权。对话记录说明的是如何走到这一步。如果每次都让模型从不断增长的对话中重新推断这些信息，任务就会更难监督。

循环式智能体比固定工作流多了什么？

循环式智能体可以根据最新结果选择下一步。固定工作流则事先就知道执行顺序：读取工单、读取政策、生成草稿。如果下一步该做什么，取决于上一步发现了什么，就适合使用自适应循环；如果不存在这种不确定性，固定顺序即可。

ReAct 智能体如何使用这个循环？

ReAct 智能体循环把推理与行动连接起来：模型根据观察结果决定后续动作。ReAct 原始项目描述的正是在环境中交替进行推理和行动。监控应用时，应记录请求了哪些动作、获得了哪些观察结果，以及最终产生了什么结果。用文字描述进展，不能代替执行回执。

生产环境的智能体循环需要哪三类停止条件？

应有意识地设计三种退出路径：任务完成、额度耗尽，以及需要人工输入。这是工程上的分类，并不意味着所有 SDK 都提供相同的三个开关。崩溃、取消和不可恢复的错误，也需要明确的失败处理方式。

任务完成时停止

在第一次调用模型之前，就要定义什么叫完成。对起草助手而言，完成可能意味着生成符合要求、附有相关来源引用的草稿。对能够实际操作的助手而言，可能还需要确认写入成功的回执。

要区分“模型不再请求工具”和“用户要求的任务已经成功”。前者是运行时信号，后者需要针对任务的证据。模型也可能因为无法继续而停止；应用应将这种情况记为受阻或未完成，而不是显示任务成功。

不要在答案校验失败后就自动重启循环。纠正尝试必须消耗同一任务的额度，否则校验器本身也会成为无限重试的来源。

达到上限时停止

为步数、资源消耗和已用时间分别设置上限。步数上限约束重复次数；token 或费用预算约束消耗；截止时间则防止响应缓慢的模型或工具让任务无限期挂起。这几类限制不能互相替代。

在允许新操作开始之前检查限制，操作结束后更新用量。只统计已完成的调用，无法阻止正在运行的请求继续消耗资源。如果应用承诺严格的消耗上限，就必须在启动下一项操作之前，为它预留容量，并将并发执行中的工作计算在内。

限制应围绕整个业务任务设置，而不只是某一次 SDK 调用。重试、审批后恢复执行或启动子智能体，都不应悄悄获得一份新额度。确有必要继续时，应由应用明确决定是否追加额度。

人在回路中：审批必须发生在操作之前

需要人工参与的 AI 智能体，应在需要审批的操作执行之前暂停。展示拟执行的动作、目标和相关参数，保存待处理调用与当前任务状态，再等待明确决定。

对工单助手而言，审批应对应发给特定收件人的那一条具体回复。批准一份草稿，不应变成对后续所有消息的全面授权。如果模型在获批后修改了收件人或内容，就需要重新评估该操作。

暂停状态应记为 awaiting_approval，而不是 completed。审批被拒后，应转入预先定义的替代路径或停止，不应换个工具反复尝试执行同一操作。人在回路中的 AI 指南介绍了审批队列和升级处理方式。

用伪代码搭建最小智能体循环

只要在每项操作前后设置好策略检查，循环本身可以很简洁。下面是伪代码，不是可以直接运行的 SDK 代码。示例中 8 次模型调用的上限只是一种演示性的应用配置；实际限制应根据任务和观察到的执行轨迹自行确定。

state = new_job(task, max_model_calls=8, budget, deadline)

while true:
    if limit_reached(state):
        return stop("limit", partial_result=state)

    reserve_capacity_or_stop(state, next_model_call)
    response = call_model_with_deadline(state)
    record_model_call_usage_and_response(state, response)

    if response.is_final and not response.tool_calls:
        return validate_and_finish_or_stop_incomplete(response, state)

    if not response.tool_calls:
        return stop("no_action", partial_result=state)

    for index, call in enumerate(response.tool_calls):
        decision = validate_and_authorize(call, state)
        if decision == "denied":
            return stop("denied", partial_result=state)
        if decision == "needs_human":
            return pause_and_save(state, response.tool_calls[index:])

        reserve_capacity_or_stop(state, call)
        observation = execute_with_timeout_and_retry_cap(call)
        record_tool_usage(state, observation)
        append_matching_tool_result(state, call, bounded(observation))

    if no_progress(state):
        return stop("stalled", partial_result=state)

这些辅助函数的名称背后都有具体职责。预留容量时，必须考虑已经在执行的工作。工具重试必须设上限。写入操作超时且结果不明时，必须先停止或核实结果，才能重试。模型或工具发生致命错误时，应记录失败并退出，不能直接落入下一轮循环。

保存暂停状态时，必须同时保存剩余工具调用、已完成的结果和已消耗额度。恢复后，接着执行保存下来的工作，并重新检查授权和限制。从头重跑整个任务，可能重复产生之前已经发生的操作效果。

留意各项检查的位置：审批在工具执行之前，用量核算在操作完成之后；仅凭模型请求继续，并不足以启动下一轮。

各框架如何控制智能体循环？

OpenAI Agents SDK、Claude Agent SDK、Vercel AI SDK 和 LangGraph对循环的封装方式各不相同。比较配置项名称之前，先看清它们的计数单位，以及在哪个边界停止执行。

这些名称分别来自 OpenAI 循环文档、Claude 循环文档、Vercel 循环文档和 LangGraph Graph API。各框架审批机制的文档链接见下文对应小节。

OpenAI Agents SDK：由 Runner 决定如何继续

在 OpenAI Agents SDK 中，Runner 负责调用模型、执行请求的工具、追加结果并继续运行。交接会切换当前活动的智能体，然后继续本次运行。文档规定的正常结束条件是：输出符合预期类型，且没有工具调用；超过 max_turns 时，如果没有相应处理，就会抛出 MaxTurnsExceeded。OpenAI 智能体运行文档。

对工单助手来说，这为限制模型调用轮次提供了直接的控制点。但要注意，本次运行结束，并不等于业务操作完成：你仍需配置输出约定，并检查任务所要求的证据。

审批方面，Python 工具可以声明 needs_approval；待批准的调用会出现在 interruptions 中。保存 RunState，应用批准或拒绝决定，然后恢复执行。暂停过的运行并不是一个新的用户请求。OpenAI 人在回路中的审批文档。

Claude 智能体循环：轮次和费用都要设限

Claude Agent SDK 内置了支撑 Claude Code 的循环，包括文件和命令工具。它的 maxTurns 按工具使用轮次计数；maxBudgetUsd 设置预估费用阈值。两者未设置时均不设上限。Python 中对应名称为 max_turns 和 max_budget_usd。Claude 智能体循环文档。

要检查结果子类型：success、error_max_turns 和 error_max_budget_usd 代表不同结局。在单次运行模式下，错误结果之后还会抛出异常，因此结果处理和异常处理都不能遗漏。Claude 结果处理说明。

权限边界同样需要仔细处理。allowedTools 会自动批准列表中的工具；工具不在该列表里，并不意味着它被移除了。在默认权限模式下，需要审批且未匹配任何允许规则的调用，会进入 canUseTool。用这个 SDK 执行无人值守的写入之前，要检查完整的权限策略。Claude 权限文档。

在跨子智能体核算用量时，Claude 区分主循环的 usage 与整棵智能体树的 modelUsage，后者在 Python 中名为 model_usage。排查一个任务的消耗时，要选择正确的总量口径。Claude 成本与用量文档。

具体实现可以从本站的 Claude Agent SDK 指南开始。

Vercel AI SDK：stopWhen 控制是否进入下一步

Vercel AI SDK 通过 stopWhen 控制是否继续。当前文档使用 isStepCount 设置步数上限，也允许提供多个条件，任意一个满足即停止。ToolLoopAgent 默认上限为 20 步，而 generateText 和 streamText 默认仅执行一次生成。选择哪个入口，会影响默认行为。Vercel 循环控制、工具调用文档。

一步包括一次生成及其本地工具执行。关键在于，只有当最后一步包含工具结果时，才会评估 stopWhen。**它无法撤销已经产生这些结果的工具操作。**因此，它控制的是后续是否继续，不是行动之前的审批。Vercel 多步调用。

需要用户明确批准时，应使用文档中的 toolApproval 机制。当前文档已将旧的工具属性 needsApproval 标为弃用。Vercel 工具审批。

上下文管理方面，prepareStep 会在每一步之前运行，可以修改消息或设置。可利用这个时机提供相关状态，避免每次都携带所有原始结果。Vercel prepareStep。

LangGraph 与 LangChain 的智能体循环

LangGraph是一个图运行时：节点执行工作，边决定接下来运行什么。用图搭建 LangChain 智能体循环时，应明确画出返回模型的路径和通往 END 的路径。Python 的 recursion_limit 限制的是图的超级步，并行节点共享一个超级步。它不是工具调用计数器。LangGraph Graph API。

recursion_limit 应放在调用配置的顶层，而不是 configurable 内部。达到上限会抛出 GraphRecursionError；正常情况下，应通过预先设计的完成路径结束，而不是等到触发这个应急出口。LangGraph 递归上限。

需要人工审核时，interrupt() 会暂停图执行。使用检查点保存器和稳定的 thread_id，再通过 Command(resume=...) 恢复。这里有个关键边界：恢复时，会从被中断节点的开头重新执行。中断之前的代码可能再次运行。因此，产生实际影响的操作应放在审批之后，或者设计成幂等操作，也就是重复执行不会产生额外影响。LangGraph 中断机制。

当分支和可恢复状态是任务的核心时，可以选择这种显式图结构。如果只是搭建第一个只读助手，工具循环也很简单，就从能满足需求的最小运行时开始。

为什么一次运行会走到 40 步？

提高上限之前，先诊断每一步之间究竟发生了什么变化。一次长时间运行，可能是在完成有价值的工作，也可能是在反复失败，或因重启丢失了已完成工作的记录。单看数字，无法区分这些情况。

死循环：反复执行，却没有新证据

工单智能体可能搜索某项政策，收到空结果，然后重复同一搜索。下一次观察没有带来任何新信息，模型也就可能再次选择相同动作。

记录规范化后的工具名称与参数、结果指纹，以及反映任务进展的标记。如果操作重复而状态没有变化，应触发停滞检查。合理的轮询也会重复，所以应为轮询单独设置有上限的策略，而不是把所有重复都当成错误。

重试之前，要改变某个条件：搜索词、缺失的标识符、可用数据源，或任务范围。如果没有任何有意义的调整空间，就返回尚未解决的需求，或寻求帮助。仅仅“再试一次”，算不上恢复策略。

工具报错：分清可恢复失败与结果不明

参数格式错误、权限被拒和服务暂时故障，需要不同的处理方式。返回简明、能让模型据此采取行动的错误信息。对可恢复的错误限制重试次数；如果在当前任务权限内无法修复，就应立即停止。

写入超时更棘手：即使没有收到响应，写入也可能已经成功。在重新发送客户消息或再建一条记录之前，应查询操作状态，或使用幂等键。这是一种稳定的标识符，能让服务识别出这是同一个预期操作。

恢复时要保留已经成功的工作。如果工单已读取成功，只是获取政策失败，重跑整个任务会增加工作量，还可能重复产生已发生的操作效果。

上下文膨胀：保留决策，不要搬运全部原始数据

每条观察结果都会与任务指令和此前的证据争夺模型下一次调用时的注意力。工具返回的大段内容即使在技术上有效，也可能让下一次决策失去重点。

限制工具输出大小，把大型产物存放在提示词之外，返回精简结果及可用于取回原内容的引用。将已接受的约束、审批结果和已确认的动作保存在持久化的应用状态中。摘要可以描述这些记录，但不应成为唯一的存档。

Claude SDK 文档介绍了接近上下文上限时的自动压缩，并提醒摘要可能丢失早期指令。因此，关键状态需要有意识地单独保存。Claude 上下文压缩。上下文退化解析进一步说明了为什么内容装得进上下文窗口，并不代表模型能有效回忆和使用它。

让执行轨迹回答运维人员真正关心的问题

对每个任务，记录标识符、模型调用次数、工具尝试次数、用量、已用时间、待审批事项和停止原因。对每项操作，记录请求了什么、完成了什么，以及是否改变了任务状态。

模型请求、工具执行和运行时步数应分别计数。仪表盘只写“40 步”而不说明单位，就无法解释这次运行。子任务和重试的消耗也应计入父任务。AI 智能体编排指南讨论了工作跨越多个智能体时，如何明确责任归属。

智能体循环有哪些被夸大的能力？

迭代次数更多，并不能证明进展更多。循环只是提供了反复利用反馈的机会；反馈质量和成功标准，才决定重复执行有没有价值。

模型说“完成了”，只意味着它结束了自己这一轮交互。步数上限证明运行受到了约束。两者都不能证明客服回复正确，也不能证明用户要求的修改已经发生。

使用框架也不意味着可以省去权限、持久化和恢复机制的设计。框架提供执行机制；应用定义什么算成功，以及有权执行什么操作。

智能体测试循环是另一项任务

智能体测试循环根据测试用例和验收标准评估行为。它可以在执行循环之外加一层检查器：结果合格就接受，否则反馈问题，让执行循环再尝试。LangChain 的循环工程讲解区分了执行、验证和事件触发的工作。

检查器也必须有上限。反复询问另一个模型“这个答案好不好”，可能耗尽额度，却始终拿不到决定性证据。尽可能使用具体检查：必填字段是否齐全、引用记录是否匹配、是否存在写入回执，或预期测试是否通过。

开发者和运维团队接下来该做什么？

**第一次开发智能体的人：**从范围小而明确的只读任务开始，写清完成标准，并限制各项操作。等到能够展示拟执行动作、落实授权检查，并从结果不明的情况中恢复时，再加入写入能力。如果执行顺序本就确定，固定工作流可能已经够用。

**排查高成本运行的运维人员：**在更换模型或提高上限之前，先检查重复调用、连续重试，以及不断膨胀的观察结果。找出哪一步带来了有效证据，又究竟是哪项计数触发了停止。

**已有可靠固定工作流的团队：**在自适应工具选择能解决具体问题之前，继续使用现有流程。只有当中间结果会决定下一步动作时，循环才有价值；仅仅需要重复执行，不构成重建系统的理由。

周一就可以做这件事：选一个有代表性的任务，走通任务完成、达到上限退出、等待审批、操作被拒和工具失败这几条路径。确认每条路径都留下明确状态，并且恢复后既保留已完成工作，也保留正确的剩余额度。

智能体循环常见问题

想获取构建和运维 AI 系统的实用指南，可以订阅邮件通讯。