考察点
这道题出自 Amazon 大模型应用岗的技术面试，DSPrep 标注 Google/Amazon 常考，属于「用过才知道为什么需要」的题。面试官想确认你理解 Agent 循环不是确定会停的程序——它是一个 LLM 控制的 while 循环，没有收敛保证。考察重点是：AgentExecutor 在循环里到底干什么、循环失控的几种典型模式、max_iterations 撞限后怎么优雅收尾。追问会往超时控制、轨迹监控、LangGraph 的替代方案走。
参考答案
AgentExecutor 在循环里扮演的角色
拆开看，一个 ReAct 式 agent 只负责「决策」：拿到当前 scratchpad（历史轨迹），输出下一步动作（调哪个工具、传什么参数）或者最终答案。AgentExecutor 是包在外面的执行引擎，它做的事包括：
- 调 agent 拿到决策；
- 解析出 tool call，找到对应工具执行，捕获结果或异常；
- 把（action, observation）追加进 scratchpad；
- 检查终止条件：agent 说「完成」、撞 max_iterations、撞超时；
- 未终止就回到第 1 步。
本质上它把「LLM 的意图」翻译成「真实的函数调用」并维护循环状态，同时负责所有护栏——max_iterations、max_execution_time、错误回传格式都在这一层。
为什么循环可能不收敛：三种典型失控模式
不设上限的 agent 循环在生产里是事故，失控通常长这三种样子：
- 工具乒乓：模型在两个工具间反复横跳。比如 search 没查到结果，模型想「那问问 calculator 吧」，得到无意义输出后又回 search——每轮都「有进展」的假象，实际上在原地转圈。根源往往是工具描述边界不清。
- 失败重试死循环：某工具持续报错（比如 API 一直 500），错误作为 observation 回传后，模型每轮都决定「再试一次」。LLM 没有「放弃」的内置倾向，prompt 不写清楚它就会试到天荒地老。
- 目标漂移：长链路任务里轨迹越来越长，早期目标被推出有效注意力范围，模型开始围绕无关 observation 打转，永远凑不齐「可以给出最终答案」的条件。
这三种模式共同点是：每一步单独看都「合理」，整体看永远不停。靠 prompt 工程能缓解，但不能保证——所以必须有框架层的硬熔断。
maxiterations 的正确用法
取值依据是任务的期望步数分布，不是拍脑袋。 简单问答型 agent（搜一下、查一下就答）设 3-5；多跳研究型任务 10-15；超过 20 基本说明任务设计有问题，该拆子任务或用 plan-and-execute。设之前先看离线评测里的步数分布，取 P99 再加点余量。
撞限不等于失败，要优雅降级。 AgentExecutor 撞限后默认抛错或返回半成品，生产上应该配置 handle_parsing_errors 和撞限回调，让 agent 把已有轨迹总结一下交给模型生成「基于目前查到 X、Y，但 Z 未能确认」的部分答案，而不是给用户一个 500。用户拿到 80% 的答案加明确的不确定声明，体验远好过于报错。
配合另外两道闸才算完整。 一是 wall-clock 超时（max_execution_time），防止某次工具调用或 LLM 请求本身卡死把迭代次数都耗在等待上；二是 token 预算——每次循环的轨迹都进 prompt，十轮循环的输入 token 可能从两千涨到两万，成本和延迟都失控。工程上要对单次 observation 截断（比如限 2000 token），长轨迹滚动摘要。
监控迭代数本身就是健康指标。 线上统计每次会话的实际迭代次数分布：均值从 3 涨到 6，多半是某个工具开始返回垃圾结果或描述被改坏了；max_iterations 撞限率超过几个百分点，说明要么任务变复杂了，要么 agent 陷入上述失控模式，值得逐条捞轨迹复盘。
LangGraph 时代的演进
值得主动提的一句：LangChain 官方现在推荐用 LangGraph 替代 AgentExecutor——把 agent 循环显式建模成状态图，循环上限、中断恢复（interrupt）、human-in-the-loop 都是图结构的一等公民，可控性比一个黑盒 Executor 强得多。AgentExecutor 适合理解原理和快速原型，复杂生产 agent 应该往图上迁。
可能的追问
1. 怎么区分「任务真的复杂」和「agent 在转圈」？
看轨迹的 observation 增量：每轮是否带来新信息。连续两轮 observation 语义重复（可以用 embedding 相似度检测）基本就是转圈，这个检测可以做成在线熔断，比固定 max_iterations 更智能。
2. 工具调用本身很慢（比如查外部 API 要 10s），迭代上限还合理吗？
迭代数和耗时是两个维度，都要限。慢工具应该单独设超时 + 并发化（无依赖的工具调用并行发起），必要时把慢调用拆成异步任务，agent 先继续别的分支。
3. 用户中途中断会话怎么办？
AgentExecutor 本身不擅长中断恢复，这也是 LangGraph 的 checkpoint 机制被推荐的原因——每步落盘状态，中断后能从断点续跑而不是从零重来。长任务场景这是刚需。