Agent 面试：当面试官问“模型复读机了怎么办”，他到底在考什么？
有这样一个问题：“在实际运行中，如果你的 Agent 陷入了 ReAct 循环，或者不断调用同一个错误的工具，你是怎么在工程上解决的？”
为什么这个问题是“分金岭”？
很多人做 Agent 还停留在 Demo 阶段，认为只要 Prompt 写得好，模型就能自动完成任务。但在真实场景下，Agent 经常会变成“复读机”：它发现工具 A 没给它想要的结果，于是思考一下，再次调用工具 A，如此循环，直到烧光你的 Token。
深度解析：你该如何作答？
一个标准的、有“工程手感”的回答，应该包含以下三个层面的策略：
- 第一层：硬性约束（Stop Conditions）这是最基础的。你需要提到你设置了最大迭代次数（Max Iterations）和超时机制。但别止步于此，面试官会追问：“如果到了次数任务还没完，怎么给用户交代？”这时你可以聊聊**“兜底方案”**，比如返回当前阶段最接近的结果，并标记为“未完成”。
- 第二层：反思与状态记录（State Management）你可以分享如何引入**“反思节点（Reflection Node）”**。在 Agent 连续两次做出相同 Action 时，强制触发一个反思 Prompt，提示模型：“你已经尝试过此路径且失败了，请更换策略。”
- 第三层：工具侧的反馈优化（Self-Correction）这也是最能加分的地方。如果 Agent 调用 SQL 工具报错了，你返回给它的不能仅仅是 Error，而是要把报错堆栈（Traceback）中最关键的信息塞回上下文。让 Agent 像程序员修 Bug 一样，根据报错信息去修正它的下一行代码。
延伸到“数分 Agent”的设计
如果面试官让你以此设计一个数据分析 Agent，你就可以顺势带出：你会设计一个“代码执行沙箱”+“反馈循环”的结构。Agent 写完 Python 代码，在沙箱运行，如果失败，报错信息自动反馈给模型进行自愈。