AI Agent全栈架构

主题

高频面试题

什么是 Agent Loop（智能体循环）？一个典型的 Agent Loop 包含哪些步骤？

这道题表面在问循环步骤，实际是在看你能不能把“模型自己往下做”讲成一个可验证、可停止、可恢复的工程状态机。

适合阶段：Agent 入门 / Agent 工程实现面核心能力：Goal · State · Action · Observation · Stop Condition

面试官角度分析，想考什么 ​

  • 什么是 Agent Loop？典型步骤有哪些？
    考你能否把它说成受控的任务推进闭环，而不是简单 while true。

  • 它和 ReAct 是什么关系？怎么知道该停？
    考循环意识：ReAct 是常见实现形态；停止要靠完成、失败、预算和人工接管，不能只靠模型自觉。

  • 失败时怎么排查？
    考 trace：看动作选择、参数、工具结果、状态更新和停止条件，而不是只看最终回复。

可直接抄走的 30 秒参考答案 ​

text
Agent Loop 是智能体推进任务的主循环。它不是调一次大模型就结束，而是每一轮先读目标和当前状态，让模型判断下一步该做什么，再由系统校验动作、执行工具、把结果写回状态，最后判断是继续、完成、失败、追问用户还是转人工。典型步骤可以记成：理解目标、构建上下文、选择动作、校验动作、执行工具、观察结果、更新状态、判断停止。生产里最关键的是停止条件、权限控制和 trace，不然很容易写成一个无限调工具的 `while true`。

面试回答详解，知其所以然 ​

这道题不要答成“Agent Loop 就是 while 循环”。更准确的说法是：Agent Loop 是一个受控的任务推进闭环。模型可以提出下一步动作，但外层系统要负责状态、工具执行、校验、记录和停止。

1. Agent Loop 解决什么问题 ​

普通 LLM 应用通常是一问一答：

text
用户输入 -> LLM -> 输出

但 Agent 面对的是需要多步推进的任务，比如“查资料并写报告”“定位测试失败并修复”“查询订单并判断能否退款”。这些任务不能靠一次模型调用完成，需要边做边看结果，再决定下一步。

Agent Loop 的价值就在这里：

text
目标 -> 决策 -> 行动 -> 观察 -> 更新状态 -> 再决策

它让模型从“只生成答案”变成“参与任务推进”。但只要进入循环，就必须处理失控风险：重复调用工具、越权执行、上下文膨胀、成本飙升、提前结束、假装完成。

2. 一个典型 Agent Loop 的步骤 ​

面试里可以把典型 loop 拆成七步：

  • 接收目标：理解用户要完成什么，抽取约束、输入、验收标准和风险边界。
  • 读取状态：查看当前已经做了什么、缺什么、有哪些工具结果和历史决策。
  • 决策下一步：由 LLM 或 planner 判断下一步是调用工具、继续推理、询问用户还是给最终答案。
  • 校验动作：外层 runtime 检查工具名、参数、权限、预算、幂等和安全策略。
  • 执行动作：调用搜索、数据库、代码执行器、文件系统、业务 API 等工具。
  • 观察结果：把工具返回、错误、环境反馈或用户回复整理成 observation。
  • 更新并停止：把 observation 写回结构化 state，再判断成功、失败、继续、转人工或超预算。

可以用一个更工程化的流程表示：

text
Receive Goal
  -> Build Context
  -> Select Action
  -> Validate Action
  -> Execute Tool / Ask User / Final Answer
  -> Observe Result
  -> Reduce State
  -> Check Stop Condition
  -> Continue or Exit

3. ReAct 是 Agent Loop 的经典思想来源 ​

ReAct 可以理解成 Agent Loop 的经典语言层范式：

text
Thought -> Action -> Observation -> Thought -> ...

模型先思考当前该做什么，再执行一个动作，拿到 observation 后继续思考。ReAct 的贡献是把 reasoning 和 acting 交错起来，让模型能基于外部反馈修正计划，而不是一次性把答案编完。

现代 Function Calling / Tool Calling 可以看作 ReAct 的工程化版本：模型不再输出脆弱的 Action: search(...) 文本，而是输出结构化 tool call；应用层执行工具，再把 tool result 回灌给模型，进入下一轮。

4. 生产里的 Agent Loop 是状态机，不是模型独角戏 ​

Demo 里常见写法是：

text
while not done:
  ask_llm()
  call_tool()
  append_result()

这个结构能演示概念，但不能直接当生产实现。生产里的 Agent Loop 更像状态机：

  • 模型只提出候选动作，不直接拥有执行权。
  • Runtime 校验工具、参数、权限和预算。
  • Tool executor 负责真实调用、超时、重试和错误包装。
  • Reducer 负责把 observation 写成结构化 state。
  • Stop checker 负责判断任务是否完成、失败、需要用户或转人工。
  • Trace 记录每一步，便于调试和评估。

这也是 LangGraph 这类框架强调 graph、state、node、edge 的原因：Agent 需要循环，但循环不能没有边界。

5. 停止条件是 Agent Loop 的关键 ​

一个成熟的 Agent Loop 必须知道什么时候停。停止条件不能只写在 prompt 里，因为模型可能忘记、误判或假装完成。

常见停止状态包括：

  • success：目标已满足，输出最终答案或产物。
  • need_user：缺少必要输入，需要向用户澄清。
  • insufficient_evidence：证据不足，不能继续可靠回答。
  • permission_denied：工具或数据无权限访问。
  • handoff_to_human：高风险或复杂场景需要人工处理。
  • max_steps_reached：超过最大步数，防止死循环。
  • timeout：超过时间预算。
  • repeated_action_blocked：重复调用相同工具或参数，被循环检测拦截。

面试时把这些 stop reason 说出来，会比只说“设置 max_steps”更有工程味。

6. 好的 Agent Loop 要能被观测和评估 ​

Agent Loop 每一步都应该留下 trace。至少记录：

  • 当前 step 编号和 state 摘要。
  • 模型看到的关键上下文。
  • 模型提出的 action 和 reason。
  • 工具名、参数、延迟、成本和返回结果。
  • reducer 如何更新 state。
  • 当前 stop reason 或下一步计划。

否则 Agent 失败时只能靠猜：到底是模型选错工具、参数错、工具返回错、observation 被误读、状态没写回，还是停止条件缺失。

面试官追问3个问题 ​

追问一：Agent Loop 和 ReAct 是一回事吗？ ​

  • 考察点：是否能区分思想范式和工程实现。
  • 回答方向：ReAct 是一种典型 Agent Loop 范式，强调 Thought / Action / Observation 交替；Agent Loop 是更宽的工程概念，可以用 ReAct、tool calling、状态机、graph 或 workflow + 局部 agent 节点实现。

追问二：怎么避免 Agent 无限循环？ ​

  • 考察点：是否知道 max_steps 只是底线。
  • 回答方向：要结合最大步数、超时、重复 action 检测、参数相同检测、状态进展检测、工具错误分类、预算控制和明确 stop reason。更关键的是把停止条件写在 runtime 里，而不是只靠 prompt。

追问三：Observation 应该怎么写回上下文？ ​

  • 考察点：是否理解工具结果不能原样无限追加。
  • 回答方向：工具结果应先结构化，区分成功、失败、错误码、可重试性和关键数据。短结果可以进入当前上下文，长结果要摘要、分页或落盘；关键事实还要写入结构化 state，供后续步骤稳定读取。

扩展知识 ​

Agent Loop 和 ReAct 的关系 ​

ReAct 论文提出把 reasoning traces 和 task-specific actions 交错生成。它的简单形式是：

text
Thought: 我需要先查订单状态
Action: lookup_order(order_id)
Observation: 订单已发货
Thought: 需要再查退款政策
Action: lookup_policy(...)
Observation: 已发货不可自动退款
Final Answer: ...

这给 Agent Loop 提供了一个很好理解的心智模型：Agent 不是先想完整答案再行动，而是在行动过程中持续修正认知。现代 API 里的 Function Calling / Tool Calling 把这个流程结构化了，但思想仍然来自 ReAct：推理和行动交替，外部反馈驱动下一轮推理。

Agent Loop 和 Workflow 的区别 ​

Workflow 的控制流主要由代码提前写死：

text
分类 -> 检索 -> 生成 -> 审核 -> 返回

Agent Loop 的控制流则由模型在运行时参与决定：

text
当前状态 -> 模型选择下一步 -> 工具反馈 -> 更新状态 -> 再选择

区别不是谁更高级，而是谁决定下一步。如果路径固定、规则清楚、风险高，Workflow 更稳；如果任务路径不确定，需要根据中间结果动态探索，Agent Loop 更合适。真实系统通常混合使用：外层 Workflow 管风险边界，局部复杂节点内部用 Agent Loop。

Agent Loop 的最小工程骨架 ​

一个可控 loop 至少要有这些角色：

  • planner：基于目标和状态提出下一步动作。
  • validator：校验动作、参数、权限和预算。
  • executor：执行工具，并返回结构化结果。
  • reducer：把 observation 写回 state。
  • stop_checker：判断成功、失败、继续或转人工。
  • tracer：记录每一步，服务调试和评估。

如果缺少 validator，Agent 可能越权或乱调工具；缺少 reducer，Agent 会把状态留在自然语言里，越跑越乱；缺少 stop checker，Agent 会死循环或假装完成；缺少 tracer，线上 badcase 很难复盘。

常见 loop 类型 ​

不同 Agent 的 loop 形态不完全一样：

  • Turn-based Loop：每次用户消息触发一轮或少量几轮动作，常见于客服和办公助手。
  • Goal-based Loop：围绕一个明确目标持续运行，直到完成、失败或需要用户确认。
  • Evaluator Loop：生成结果后由评估器检查，不满足就修正，适合代码、写作和结构化输出。
  • Long-running Loop：跨较长时间运行，需要 checkpoint、恢复、取消、通知和人工介入。

面试里一般先讲 goal-based loop，因为它最能体现 Agent 的“目标驱动 + 反馈控制”。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构