Tool 调用失败：
哪些重试，谁判断，任务怎么恢复？

英文问法A tool call fails. Which errors do you retry, and who decides: your code or the model? · How do you stop an agent from calling the same failing tool forever? · The agent service crashes mid-task. How does it resume?

考过别家面经原题：作业帮 Golang 实习一二面（发帖 2026-10-22）「怎么判断哪些错误应该重试、哪些不应该重试？是由程序判断，还是完全交给模型？」「任务失败后，有没有保存执行上下文？如何记录失败在哪一步，以及当时的状态？」（牛客）、虾皮 Data Infra 实习二面（面试 2026-06-15）「防死循环机制怎么做的？」（牛客）和一面（面试 2026-05-26）「Agent服务突然挂掉了怎么办？」（牛客）、字节 Agent 开发日常实习一面（发帖 2026-10-20，作者按回忆转述）「Task DAG 给了一个场景：ABCDE 里 BCD 依赖 A 并行跑，E 依赖 BCD，如果 D 崩了有没有恢复机制。」（牛客） · 英文侧：Qualified Health SWE onsite 2026-09，追问上游 LLM API 返回 429 时怎么做 backoff 和 backpressure，以及长任务怎么 "design fault tolerance and state checkpoints to avoid wasting large amounts of token charges"（PracHub，站方编辑过的面经页，其余是转述） · 中文面经样本里有 15 帖问可靠性 · 没有 Unity 自己的面经原题

先弄清楚：每个概念是什么

Transient error
等一下再发可能就好的错误。例：timeout、rate limit（HTTP 429）、网络抖动。
确定性错误
重发多少次结果都一样的错误。例：参数错、文件不存在、权限不够。
幂等（idempotent）
同一个调用执行一次和多次，效果相同。例：把文件内容设成 X 是幂等的，往末尾追加一行不是。
Exponential backoff
每次重试前等的时间翻倍，有次数上限。像打电话占线，越拨间隔越长。例：先等 1 s，最多重试 3 次，最坏一共等 \(1 + 2 + 4 = 7\) s。
Checkpoint
把当前状态落盘，像游戏存档。

30 秒回答

I split errors into three kinds. Transient ones, like timeouts and rate limits, the harness retries with exponential backoff and a cap, without involving the model. Deterministic ones, like a bad argument, go back to the model as the tool result so it can fix the call. Calls with side effects are retried only if they're idempotent; otherwise I check the state first. To prevent loops, the harness stops and escalates when the same call keeps failing. And it checkpoints messages and task state after every step, so a crashed run resumes from the last step.

三类错误，各自谁处理

错误类型谁处理怎么处理
Transient errorharnessexponential backoff 自动重试，超过上限才把报错交给 model
确定性错误model报错原样当作 tool result 还给 model，让它改调用
有副作用的调用，如写数据库、开 PRharness 先把关幂等才重试。不幂等就带 idempotency key，或先查状态确认上一次没生效

防死循环和 checkpoint

防死循环。harness 给每次调用的 tool 名和参数算 hash，同一个 hash 连续失败或反复出现 N 次就停下并上报，再用 max steps 兜底。stop condition 的一般讲法见 search loop。

Checkpoint。每一步之后，harness 把 messages 和 task 状态落盘，带上 step 编号和最后一个 tool call 的结果或报错。重启后从最近的 checkpoint 接着跑。最后那一步可能只执行了一半，恢复时按有副作用的调用处理。

必答点

追问

tool 调用失败后 model 编造结果，怎么办？（蚂蚁原题）

结果只认 tool 的真实输出。没有成功的 tool result，verifier 就不放行。

Task DAG 里 B、C、D 并行，D 崩了怎么恢复？（字节）

每个节点的结果单独落盘。只重跑 D，B 和 C 的结果读回来。

上游 LLM API 一直返回 429 怎么办？（Qualified Health）

每个 worker 自己 backoff 不够。调度层还要限流并加 backpressure，上游忙时少派任务（见 大批量跑 agent）。

让 model 参与错误分析和恢复，行不行？（影石创新原题）

行，但只交确定性错误，它要理解任务才能改对。transient error 从错误码就能判断，交给 model 只是多花 token。

来源面经原帖：作业帮 Golang 实习、虾皮二面、虾皮一面、字节 Agent 开发日常实习一面、蚂蚁 AI 应用方向（「如果工具调用失败，模型开始编造结果，怎么处理？」）、影石创新 AI Agent 一面（「是否考虑过让大模型参与错误分析和自动恢复？这种方案有什么优缺点？」） · PracHub：Qualified Health（429、checkpoint、幂等的追问） · ml-八股 08 第 35 题 · 中文平台调研笔记 1.9 节