多步任务中途停住，先分两条线看：一条是步骤拆得太粗，单步里同时塞进了需要多次判断、多次工具调用的动作；另一条是这一步本该调用的工具没接上或没授权，智能体拿不到结果，只能停下或反复追问同一句。这两类的表现很像，区分手段不靠读提示词猜，而是把同一条任务拆成粗、细两个版本各跑一次，看停住的位置是否随粒度变化。粒度变了就停得住，多半是拆解问题；粒度怎么变都卡在同一个工具调用前后，优先查工具与权限。
同一任务用粗、细两个版本各跑一次，是区分粒度问题与工具问题最省事的手段：细粒度版能走完、粗粒度版卡在同一处，多为单步负载过重；两版都停在同一个工具调用前后，先查工具是否可用、是否授权、返回是否被正确解析。判断依据只取运行记录里的原始输入与报错，不要用一次偶发成功就确认修好。确属能力边界、需要人判断的环节要单独列出，不要算进自动化步骤。
把同一条任务拆成粗、细两个版本各跑一次
先固定输入：同一条原始需求、同一份初始数据、同一个模型配置，只改拆解方式。粗粒度版一般 2 到 3 步，每步承担“取数 + 判断 + 生成”多个动作；细粒度版把每个动作拆成独立一步，通常 5 到 8 步，每步只做一件事，输出直接作为下一步输入。跑之前先建好下面这张记录表的列，跑完按实际填写，不要回头补写。
| 版本 | 步骤数 | 每步输入 / 输出 | 停住位置 |
|---|---|---|---|
| 粗粒度（示意，按实际替换） | 3 | 1 输入=原始需求，输出=任务清单；2 输入=任务清单，输出=汇总结果；3 输入=汇总结果，输出=最终答复 | 第 2 步，工具调用后无返回 |
| 细粒度（示意，按实际替换） | 7 | 1 输入=原始需求，输出=字段清单；2 输入=字段清单，输出=查询语句；……7 输入=各步结果，输出=最终答复 | 第 6 步，或全部走完 |
记录时逐步骤写下“进入这一步时的输入是什么、期望输出是什么、实际输出是什么”。停住位置是最关键的一列：粗粒度版停在“一次要做三件事”的那一步，而细粒度版能越过同一动作，说明问题在拆解；两个版本都停在同一类工具调用上，说明问题和粒度无关。
在运行记录里找到停住那一步的原始输入
翻运行日志时，不要只看智能体最后输出的那句话，要定位到停住步骤的那条调用记录，把三样东西抄出来：这一步开始时实际收到的上下文、它发起的工具调用、工具返回的原始内容或报错。很多“反复追问”其实是工具返回了空值或一段无法解析的文本，模型拿不到可用信息，只能重问。日志结构各平台不同，可按下面的字段去对应查找：
步骤序号: 6
输入上下文(截取): 前几步的输出摘要 + 用户原始需求
工具调用: query_order_status
调用参数: { "order_id": "..." }
工具返回: "" 或 {"error":"permission denied"} 或 一段非结构化文本
模型下一步动作: 重复提问 / 直接结束重点看工具返回：是空、是错误码、还是格式和预期不一致导致无法解析。如果返回里有明确的拒绝或未授权字样，直接跳到下一节；如果返回正常但模型仍停住，问题更可能在上下文长度不够或上一步输出没被传递进来。
核对这一步需要的工具是否可用且已授权
静默停住里，工具缺失和权限不足占了相当比例，而且往往不报错，只表现为模型反复要同一份信息。先确认工具是否在本次会话中挂载、名称与参数是否对得上，再确认凭据和权限范围。通用配置骨架如下，字段名以实际界面与文档为准，替换成自己的即可：
{
"tools": [
{
"name": "query_order_status",
"description": "按订单号查询状态",
"enabled": true,
"auth": { "type": "token", "scope": ["order:read"] },
"timeout_ms": 15000
}
],
"tool_choice": "auto",
"max_steps": 20
}权限先只给只读范围跑一遍：能读到数据、能返回结构化结果，就说明工具链路通，问题不在“没接对”；返回未授权或空结果，就是权限或凭据没配对。还要留意工具超时设置，超时太短会让调用被中断，看起来像模型自己停住。
用一个最小复现任务验证改动是否生效
改完拆解或权限后，不要拿原来那条复杂任务直接判断，先用一条最小任务验证：输入固定为一句可复现的需求，例如“查询订单 A123 的当前状态并输出一行结果”，只依赖一个工具、一步或两步就能完成。连跑三次，把每次的结果按下面几列记下来：
- 第几次运行：第一次 / 第二次 / 第三次
- 是否走完全部步骤：是 / 否
- 停住位置与原始报错：空白表示无
- 工具返回是否结构化：是 / 否
改动前的记录同样保留一份。三次结果一致且都能走完，改动才算可重复；三次里有一次成功两次失败，说明还有随机因素，通常是上下文截断或工具偶发超时，需要继续缩小范围，而不是当作已经修好。
把仍需人工介入的环节单独列出来
有些停住不是配置问题，而是任务本身需要人判断：涉及金额调整、对外发送、删除数据这类动作，通常需要授权确认；信息有歧义、缺关键字段时，需要人来补；工具明确返回业务拒绝时，需要人工处理而不是重试。把这些点从自动化步骤里拆出来单独标注，避免把它们也算进“应该自动跑完”的期望里：
- 涉及写操作或对外动作 → 触发条件：即将提交变更，等待人工确认后继续
- 输入缺少必填字段 → 触发条件：字段校验为空，转为向用户询问
- 工具返回业务规则拒绝 → 触发条件：错误码属于规则类，转人工处理
- 多次重试仍失败 → 触发条件：同一工具连续失败达到设定次数，暂停并上报
这样区分之后，再遇到中途停住，可以快速归类：停在人工确认点属于设计如此；停在工具调用前后且返回为空或未授权，查权限与参数；停在没有任何工具调用的推理步骤，多半是步骤太粗或上下文没传全。