Agent回合控制专题

版本：v1.1
最后更新：2026-07-07
适用对象：需要治理 Agent loop、工具重试、replan、人工接管、预算控制和停止条件的产品、算法、平台与工程同学

很多 Agent 系统在 demo 阶段看起来都能做事，但一到真实链路就会迅速出现几类问题：

回合数越来越多
planner 与 executor 反复改计划
模型开始重复检索、重复调用工具
明明还在输出内容，但任务其实已经没有实质进展
高风险任务没有在正确节点停下来，而是继续向前执行

这类问题的本质不是“模型太笨”，而是：

系统没有把继续、暂停、停止、降级、转人工这些决策做成明确机制

OpenAI 的 Agents、guardrails、human review、evaluate agent workflows 文档，以及 LangGraph 的 interrupts、人审和 persistence 文档，都指向同一个工程原则：

回合控制不是简单设置 max_turns，而是为 Agent 设计预算、停止条件、审批节点和过程观测能力

1. 什么是回合控制

更实用的理解通常是：

对 Agent 在单个任务中的思考轮次、工具调用轮次、重规划次数、人工审批节点和最长执行时长做系统性控制

它关心的不是“尽量少说话”，而是：

让任务在有限预算内稳定收敛

回合控制一般要覆盖：

控制对象	说明
模型回合	planner / executor 与模型的往返次数
工具回合	工具调用、重试、并行调用批次
replan 回合	原计划失效后重新拆任务的次数
人工节点	需要审批、确认或补信息的暂停点
总耗时	从接收任务到终止的 wall-clock time
总预算	token、工具费、外部 API 费、写操作次数

所以回合控制本质上是编排问题，而不只是模型参数问题。

2. 为什么回合数会失控

常见原因通常不是单点故障，而是多种问题叠加。

2.1 任务目标不清

输入不完整
成功标准模糊
用户约束没有进入 planner

2.2 计划拆分不稳

步骤过粗，导致执行阶段频繁返工
步骤过细，导致任务被拆成过长链路
缺少失败分支和人工接管分支

2.3 工具反馈信号差

工具返回太含糊
缺少状态码和错误类型
执行结果无法判断下一步是否值得继续

2.4 没有停止条件

没定义什么时候停止
没定义什么时候拒答
没定义什么时候必须转人工

2.5 没有预算意识

一个低价值任务被允许无限思考和重试
重复检索、重复推理没有触发熔断

这几类因素一旦叠加，Agent 很容易进入：

重复思考
重复检索
重复调用工具
反复改计划但没有新增信息

3. 哪些任务最需要严格回合控制

不是所有任务都需要一样强的控制。

尤其以下场景需要专门设计：

长任务工作流
多工具协作任务
外部写操作任务
含审批或人工接管的业务流程
高成本 reasoning 链路
实时交互和语音 Agent

这些任务里，多一个无效回合的成本通常不只是 token 成本，还包括：

用户等待
外部 API 调用费
数据库压力
错误写入风险
人工复核负担

4. 一个更实用的回合控制视角

可以把回合控制拆成四层来看。

4.1 上限控制

最多多少模型回合
最多多少工具调用
最多多少重试
最长执行多久

4.2 条件控制

满足什么条件继续
满足什么条件暂停
满足什么条件停止
满足什么条件降级或转人工

4.3 预算控制

单任务最大 token
单任务最大工具成本
单租户最大并发和最大 wall-clock time

4.4 质量控制

虽然还能继续，但是否已经没有新增证据
是否出现重复思路
是否已经偏离目标

只做第一层，通常只能“到数硬停”。

成熟系统一定会把后面三层也做进去。

5. 回合不是一个数字，而是一组预算

很多系统会只配一个：

text

max_turns = 10

这通常不够。

更合理的预算模型通常类似：

json

{
  "max_model_turns": 8,
  "max_tool_calls": 12,
  "max_replans": 2,
  "max_retry_per_tool": 2,
  "max_elapsed_ms": 30000,
  "max_total_tokens": 25000,
  "max_write_actions": 1,
  "require_human_approval_for": [
    "send_email",
    "delete_record",
    "update_finance"
  ]
}

这样做的好处是：

可以分别治理不同类型的失控
可以定位到底是推理失控、工具失控还是审批缺失
可以按任务价值、风险和 SLA 调整预算

6. 如何定义“继续、暂停、停止、降级”

6.1 继续

只有在以下条件满足时才值得继续：

有新的可验证信息进入上下文
上一步工具结果明确改变了决策
计划仍然有效
继续执行的边际价值高于边际成本

6.2 暂停

适合暂停的情况包括：

需要用户补充信息
需要人工审批
需要等待异步外部任务
需要确认是否继续付费或继续执行高风险动作

OpenAI Guardrails and human review 和 LangGraph interrupts 的价值就在这里：

不是一味停掉，而是以可恢复的方式暂停执行

6.3 停止

应当停止的信号包括：

达到硬预算上限
连续多个回合没有实质进展
工具错误不可恢复
证据不足但继续也不会新增证据
输出已经满足完成标准

6.4 降级

适合降级的情况包括：

高能力模型超时，切到更快模型给摘要版答案
复杂任务无法在预算内完成，改为只给下一步建议
在线链路转为后台任务

6.5 转人工

必须转人工的典型场景：

高风险写操作
模型低置信但业务必须完成
多次 replan 仍无法收敛
用户诉求本身需要人工判断

7. 为什么所有任务不能共用一个回合配置

统一最大回合数是最常见也最伤系统的一种配置方式。

原因很简单：

任务类型	更关心什么
简单问答	低延迟、低成本
RAG 问答	检索质量、引用校验
外部写操作	审批、权限、可回滚
长任务执行	状态持久化、恢复和重规划
实时语音	首 token / 首音频时间、打断体验

更合理的方式通常是按任务类型分 budget profile：

json

{
  "faq": { "max_model_turns": 2, "max_tool_calls": 1 },
  "rag": { "max_model_turns": 4, "max_tool_calls": 3 },
  "ops_workflow": { "max_model_turns": 6, "max_tool_calls": 8, "approval_required": true },
  "background_research": { "max_elapsed_ms": 180000, "max_replans": 3 }
}

如果一律统一配置，结果往往是：

简单任务浪费预算
复杂任务被过早掐断

8. 一个更实用的停止条件模型

停止条件应该包含硬条件和软条件。

8.1 硬条件

硬条件是到了就必须停：

达到最大回合数
达到最大 token 数
达到最大工具调用数
达到最大 wall-clock time
达到最大写操作数

8.2 软条件

软条件是到了就要评估是否停：

连续两轮没有新证据
连续两轮计划没有变化
连续两轮工具返回同类错误
连续两轮答案置信度下降
连续两轮都在重复同一类工具查询

8.3 一个示例规则

json

{
  "stop_if": [
    "model_turns >= 8",
    "tool_calls >= 12",
    "elapsed_ms >= 30000",
    "same_query_repeat_count >= 2",
    "no_new_evidence_count >= 2",
    "replan_count >= 3"
  ]
}

重点不是规则越多越好，而是：

这些规则是否能真的拦住最常见的失控模式

9. Replan 不是坏事，但必须受控

很多团队一看到 Agent 重规划就觉得它失败了。

其实不是。

合理的 replan 是必需能力，因为：

工具返回结果可能与预期不同
权限不足可能改变执行路径
用户补充信息后，原计划可能需要重排

问题不在于是否 replan，而在于：

replan 是否有上限
replan 是否基于新增信息
replan 是否总是把系统带回同一个无效循环

建议至少记录：

replan_count
replan_reason
replan_after_which_step
replan_success

如果系统总在同一个步骤反复 replan，这通常不是“模型多想一步”，而是前置设计有问题。

10. 工具调用回合要单独控制

很多系统只盯模型输出，不盯工具层，这会漏掉最大的成本源。

Agent 的失控经常体现在：

对同一个搜索接口连续查询近似问题
对失败工具盲目重试
对读工具和写工具不加区分
工具返回空结果后继续调用更多无关工具

建议单独做这些限制：

每个工具的最大重试次数
每类工具的总调用次数
高风险写工具必须审批
读工具和写工具不同预算
同一 query 的重复调用去重

这也是为什么 OpenAI 的 human approval、guardrails 和 LangGraph 的 human-in-the-loop / interrupt 模式很重要。

工具回合本身就需要治理。

11. 回合控制为什么要和人工接管联动

OpenAI node reference 的 human approval 节点，以及 LangGraph 的 interrupts，都说明一件事：

生产系统不应该把“停下来问人”视为异常，而应该把它设计成正常路径

更稳妥的人工接管策略通常包括：

场景	建议动作
高风险写操作前	人工审批
用户信息不足	向用户追问或转人工客服
多次 replan 未收敛	转人工处理
工具权限冲突	人工确认或重新授权
高价值客户长耗时任务	转后台并允许人工跟进

回合控制的目标不是完全不让人介入，而是：

在最需要人的节点把人接进来

12. 回合控制需要哪些观测数据

如果没有 trace 和观测数据，团队几乎不可能知道 Agent 为什么绕圈。

建议记录：

json

{
  "task_id": "run_001",
  "task_type": "ops_workflow",
  "model_turns": 7,
  "tool_calls": 9,
  "replan_count": 2,
  "same_query_repeat_count": 2,
  "no_new_evidence_count": 1,
  "approval_pause_count": 1,
  "human_handoff": false,
  "elapsed_ms": 18400,
  "total_tokens": 17320,
  "task_success": true
}

OpenAI Integrations and observability、Evaluate agent workflows 和 Trace grading 的意义就在这里：

回合控制必须可观测、可回放、可比较

13. 线上应该监控哪些指标

13.1 基础指标

指标	用途
avg_model_turns	模型回合是否异常膨胀
avg_tool_calls	工具使用是否过量
replan_rate	计划稳定性
timeout_rate	是否经常超时
approval_pause_rate	是否经常卡在审批节点
human_handoff_rate	是否经常需要人工兜底

13.2 成本与体验指标

指标	用途
cost_per_run	单任务成本
cost_per_success	完成一次成功任务的真实成本
p95_elapsed_ms	长尾耗时
p95_tool_calls	长尾工具次数
repeat_query_rate	是否在重复检索
stop_reason_distribution	任务为何终止

13.3 治理指标

指标	用途
bad_loop_rate	陷入无进展循环的比例
approval_before_high_risk_write	高风险写操作是否真的经过审批
fallback_after_budget_exhaust	超预算后是否正确降级
success_after_replan	重规划是否有效

不要只看平均值。

真正让系统难受的通常是：

P95 / P99
高风险任务
高价值客户任务

14. 一个可执行的回合控制流程

14.1 先给任务分型

先区分：

简单问答
检索增强问答
多工具任务
写操作任务
长任务后台流程
实时语音或实时交互

14.2 为每类任务设预算

包括：

最大模型回合
最大工具调用
最大 token
最大 wall-clock time
是否允许 replan
是否需要人工审批

14.3 定义停止、降级和转人工规则

必须写成系统规则，而不是只写在提示词里。

14.4 对 trace 做分段观测

至少看：

planner
executor
tool
replan
approval
finalization

14.5 结合评测集做回归

OpenAI Evaluate agent workflows 和 Trace grading 的启发是：

回合控制优化不能只在线上拍脑袋调参数

要把超回合、重复工具、无进展循环样例沉淀成回归集。

15. 几个常见失控模式

15.1 重复检索型

表现：

连续查询语义几乎相同的问题

常见根因：

没有 query 去重
没有“无新证据则停”的条件

15.2 工具重试型

表现：

同一工具失败后无限重试

常见根因：

工具错误类型不明确
没有按错误类别处理

15.3 计划摇摆型

表现：

planner 反复换计划，但没有新增事实

常见根因：

目标模糊
缺少稳定计划骨架

15.4 审批缺失型

表现：

高风险步骤没有停下来确认

常见根因：

回合控制只关注成本，不关注风险

15.5 长任务拖死型

表现：

在线请求占住太久，用户和系统都在等

常见根因：

没把任务切到后台
没有 durable pause / resume 机制

16. 优化回合控制的常见手段

16.1 固定计划骨架

对复杂任务给 planner 更稳定的结构模板。

16.2 减少无效上下文

OpenAI Cost optimization 和 Running agents 相关文档都提醒：

请求数和 token 数是最直接的成本杠杆

很多回合失控，本质上也是上下文太乱导致的。

16.3 对工具结果做分类

不要只返回大段自然语言。

工具最好明确给出：

success
retryable_error
non_retryable_error
need_human
need_more_input

16.4 引入暂停与恢复机制

LangGraph 的 interrupts / persistence 和 OpenAI 的 human review、approval 节点提供了关键思路：

高风险或长耗时任务不应该只能“继续跑”或“直接失败”

中间还应该有：

暂停
审批
恢复
转后台

16.5 给不同模型不同职责

planner、executor、reviewer 不一定要共用同一模型。

回合控制本身也可以通过模型分工改善：

planner 少而稳
executor 快而省
reviewer 或 guardrail 负责是否继续

17. 常见反模式

所有任务统一最大回合数
只限制模型回合，不限制工具重试
只看成本，不看风险和人工负担
达到上限直接失败，没有降级和人工接管
不记录 stop_reason 和 replan_reason
工具错误没有分类，导致盲目重试
高风险动作和普通读操作走同一条回合控制策略
长任务没有 pause / resume 能力

18. 推荐搭配阅读

19. 落地检查清单

是否按任务类型定义了不同的回合与工具预算？
是否同时控制模型回合、工具调用、replan、耗时和写操作次数？
是否定义了继续、暂停、停止、降级和转人工条件？
是否对高风险操作接入审批或 human review？
是否记录 stop_reason、replan_reason、approval_pause_count 等关键观测字段？
是否能识别重复查询、无新证据和无进展循环？
是否为长任务提供 pause / resume 或后台执行机制？
是否把超回合和坏循环样例沉淀成回归评测集？

20. 推荐资源

以下资源在 2026-07-07 检查时可访问，适合作为回合控制、审批、观测与评测的官方参考。

21. 最后总结

回合控制不是给 Agent 套一个“最多 10 轮”的硬帽子，而是要回答这些工程问题：

什么时候继续才值得
什么时候暂停更安全
什么时候停止才不会浪费
什么时候应该降级
什么时候必须转人工

如果这些问题没有机制化，系统很容易在“还能继续”的错觉里不断烧预算、烧时间、烧人工。

更成熟的做法，是把预算、停止条件、审批节点、trace 观测和回归评测一起做进去，让 Agent 不是无限尝试，而是在明确边界内稳定收敛。

Agent回合控制专题 ​

1. 什么是回合控制 ​

2. 为什么回合数会失控 ​

2.1 任务目标不清 ​

2.2 计划拆分不稳 ​

2.3 工具反馈信号差 ​

2.4 没有停止条件 ​

2.5 没有预算意识 ​

3. 哪些任务最需要严格回合控制 ​

4. 一个更实用的回合控制视角 ​

4.1 上限控制 ​

4.2 条件控制 ​

4.3 预算控制 ​

4.4 质量控制 ​

5. 回合不是一个数字，而是一组预算 ​

6. 如何定义“继续、暂停、停止、降级” ​

6.1 继续 ​

6.2 暂停 ​

6.3 停止 ​

6.4 降级 ​

6.5 转人工 ​

7. 为什么所有任务不能共用一个回合配置 ​

8. 一个更实用的停止条件模型 ​

8.1 硬条件 ​

8.2 软条件 ​

8.3 一个示例规则 ​

9. Replan 不是坏事，但必须受控 ​

10. 工具调用回合要单独控制 ​

11. 回合控制为什么要和人工接管联动 ​

12. 回合控制需要哪些观测数据 ​

13. 线上应该监控哪些指标 ​

13.1 基础指标 ​

13.2 成本与体验指标 ​

13.3 治理指标 ​

14. 一个可执行的回合控制流程 ​

14.1 先给任务分型 ​

14.2 为每类任务设预算 ​

14.3 定义停止、降级和转人工规则 ​

14.4 对 trace 做分段观测 ​

14.5 结合评测集做回归 ​

15. 几个常见失控模式 ​

15.1 重复检索型 ​

15.2 工具重试型 ​

15.3 计划摇摆型 ​

15.4 审批缺失型 ​

15.5 长任务拖死型 ​

16. 优化回合控制的常见手段 ​

16.1 固定计划骨架 ​

16.2 减少无效上下文 ​

16.3 对工具结果做分类 ​

16.4 引入暂停与恢复机制 ​

16.5 给不同模型不同职责 ​

17. 常见反模式 ​

18. 推荐搭配阅读 ​

19. 落地检查清单 ​

20. 推荐资源 ​

OpenAI ​

Anthropic ​

LangGraph / LangChain ​

21. 最后总结 ​

Agent回合控制专题

1. 什么是回合控制

2. 为什么回合数会失控

2.1 任务目标不清

2.2 计划拆分不稳

2.3 工具反馈信号差

2.4 没有停止条件

2.5 没有预算意识

3. 哪些任务最需要严格回合控制

4. 一个更实用的回合控制视角

4.1 上限控制

4.2 条件控制

4.3 预算控制

4.4 质量控制

5. 回合不是一个数字，而是一组预算

6. 如何定义“继续、暂停、停止、降级”

6.1 继续

6.2 暂停

6.3 停止

6.4 降级

6.5 转人工

7. 为什么所有任务不能共用一个回合配置

8. 一个更实用的停止条件模型

8.1 硬条件

8.2 软条件

8.3 一个示例规则

9. Replan 不是坏事，但必须受控

10. 工具调用回合要单独控制

11. 回合控制为什么要和人工接管联动

12. 回合控制需要哪些观测数据

13. 线上应该监控哪些指标

13.1 基础指标

13.2 成本与体验指标

13.3 治理指标

14. 一个可执行的回合控制流程

14.1 先给任务分型

14.2 为每类任务设预算

14.3 定义停止、降级和转人工规则

14.4 对 trace 做分段观测

14.5 结合评测集做回归

15. 几个常见失控模式

15.1 重复检索型

15.2 工具重试型

15.3 计划摇摆型

15.4 审批缺失型

15.5 长任务拖死型

16. 优化回合控制的常见手段

16.1 固定计划骨架

16.2 减少无效上下文

16.3 对工具结果做分类

16.4 引入暂停与恢复机制

16.5 给不同模型不同职责

17. 常见反模式

18. 推荐搭配阅读

19. 落地检查清单

20. 推荐资源

OpenAI

Anthropic

LangGraph / LangChain

21. 最后总结