考察点
这道题出自美团后端 Agent 开发岗位一面。一面问这种题，是想确认候选人真的动手写过 Agent 主循环，而不是只会调现成框架。面试官想听你讲清楚：每一轮循环里 LLM 的输入输出是什么、工具调用怎么解析和执行、循环什么时候停、失控了怎么兜底。追问一般会深入到：循环不收敛怎么办、并行工具调用怎么处理、错误如何反馈给模型。
参考答案
主循环的骨架
Agent 的核心是一个 while 循环，每轮迭代做三件事：让模型基于当前上下文决定下一步动作，执行这个动作，把结果喂回上下文。用 ReAct 的话术说就是 Thought → Action → Observation 的循环，直到模型判断任务完成（给出 Final Answer）或者触达兜底条件退出。
伪代码大概长这样：
messages = build_initial_messages(task, tools_schema)
for step in range(max_steps):
response = llm.chat(messages, tools=tools_schema)
if response.has_tool_calls():
for call in response.tool_calls:
result = execute_tool(call) # 执行并捕获异常
messages.append(tool_message(call, result))
else:
return response.content # 模型给出最终回答，循环结束
raise MaxStepsExceeded()
现在主流实现不再让模型输出文本再正则解析 Action 了，直接用 function calling：工具 schema 以 JSON Schema 注册给模型，模型输出结构化的 tool_calls 字段，工程上可靠得多。
每一轮里发生了什么
细节上，每轮循环的模型输入是完整的消息历史：system prompt（含角色设定、工具说明、约束）、用户任务、历轮的 assistant 消息（含它的思考或工具调用请求）、以及每个工具调用对应的 tool 消息（执行结果）。这就是为什么 Agent 的上下文会膨胀——Observation 往往很长，比如一次文件读取、一次搜索结果可能几千 token。
模型输出有两种形态：要么发起一个或多个工具调用（继续循环），要么输出纯文本回答（终止循环）。这个「终止判断」不是工程代码做的，是模型自己做的——它选择不再调工具时循环自然结束。工程上要做的是兜住模型判断失误的情况。
工程上的关键控制点
第一，最大步数限制。不设 max_steps 的循环就是定时炸弹，模型可能陷入「搜索-结果不满意-换个词再搜」的死循环。常见量级是 10-30 步，视任务复杂度定，触顶后强制让模型基于已有信息总结回答，而不是直接报错。
第二，工具执行要防御式。每个工具调用包 try-catch，异常信息（包括堆栈摘要）作为 Observation 返回给模型，让它自己修正——比如 SQL 执行报错，把报错喂回去，模型下一轮通常会改写成正确语法。这比在外层写死重试逻辑灵活得多。
第三，成本与延迟控制。每轮都是一次完整的 LLM 调用，且上下文单调增长，第 N 轮的 prefill 成本是前面所有轮的总和。实践手段包括：工具结果截断（单次 Observation 限制在两三千 token 内，长结果存文件只回摘要）、并行工具调用（模型一轮发出多个无依赖的 call，并行执行压延迟）、以及给循环加总耗时墙。
第四，状态持久化。生产环境循环跑一半进程挂了怎么办？把 messages 历史按 session 存到 Redis 或数据库，每个 step 落一次，可以断点续跑，也方便排查「Agent 当时在想什么」。
和规划类模式的区别
上面讲的是 reactive 的 ReAct 循环，每步重新决策。另一类是 plan-and-execute：先让模型生成完整计划再逐步执行，定期 replan。前者灵活、适合探索性任务，后者省 token、适合步骤明确的任务。面试时可以主动提一句这个对比，说明你知道循环不是唯一范式。
可能的追问
- 循环不收敛怎么发现和干预？ 答：除了步数上限，还可以检测行为重复——连续几轮工具调用参数高度相似就判定陷入循环，注入一条提示让模型换策略或总结退出。
- 多个工具调用有依赖关系怎么办？ 答：模型一般会自己串行发起（先调 A 拿结果再调 B）；工程上要支持一轮返回多个 call 的并行执行，但执行顺序要按 call 的 id 对应回填结果，不能错位。
- 怎么评估 Agent 每一步的质量？ 答：把完整 trajectory（每轮的 thought、action、observation）落日志，离线用 LLM-as-judge 或人工标注评估单步合理性和终局成功率，bad case 回流改进 prompt 和工具设计。