考察点
这道题考的是你能不能讲清楚 Agent 的主循环机制。ReAct 是最经典的答案，面试官想确认你理解「推理和行动交织」这个核心思想，而不是只会说「循环调用工具」。追问通常往 ReAct 和 Plan-and-Execute 的对比、循环怎么终止、实际工程里 observation 怎么塞回上下文这些方向走。
参考答案
ReAct 的核心思想
ReAct 是 2022 年 Google Research 在论文《ReAct: Synergizing Reasoning and Acting in Language Models》里提出的范式。核心就一句话：让模型把「想」和「做」交织起来，交替生成推理轨迹（Thought）和动作（Action），动作的结果（Observation）再回到上下文里影响下一轮推理。
在它之前，主流做法要么只推理不行动（Chain-of-Thought，模型在脑内推完直接给答案，容易一本正经地编），要么只行动不推理（直接输出一串动作，中间错了没法纠）。ReAct 把两者合起来：推理让行动有方向，行动让推理有事实依据。
一轮循环长什么样
以「查一下竞品 A 最新一轮融资金额，写进周报」为例，ReAct 循环大概是这样：
Thought 1: 我需要先搜竞品 A 的融资新闻。
Action 1: search("竞品A 融资 最新")
Observation 1: 返回 5 条结果，其中一条来自 36氪，标题提到 B 轮...
Thought 2: 36氪那条看起来最相关，但标题里没金额，我要打开看正文。
Action 2: fetch_url("https://36kr.com/p/xxx")
Observation 2: 正文显示「完成 2 亿美元 B 轮融资，2025 年 3 月」。
Thought 3: 信息拿到了，写进周报文件。
Action 3: append_file("weekly.md", "竞品A完成2亿美元B轮融资")
Observation 3: 写入成功。
Thought 4: 任务完成。
Action 4: finish("已完成，融资信息已写入周报")
每一轮模型只决定一步，执行器真正去调工具，把结果拼回 prompt，再让模型走下一轮。这个「模型出决策、代码做执行」的分工是 ReAct 架构的骨架。
工程实现的几个关键点
实际系统里，这个循环不是裸跑 prompt 那么简单，有几个必须处理的点。
第一是终止条件。模型主动输出 finish 只是理想情况，必须加上硬性上限：最大迭代轮数（常见 10-30 轮）、token 预算、超时时间。没有上限的循环早晚在离奇 case 上烧光预算。
第二是observation 的截断。工具返回的内容可能很大（一个网页几万个 token），直接全量塞回上下文，几轮就爆窗口。工程上会对 observation 做截断或摘要，只保留和当前子目标相关的部分。
第三是异常路径。工具超时、返回报错、模型输出了不存在的工具名，这些都不能让循环崩掉，而是把错误信息作为 observation 喂回去，让模型自己决定重试还是换方案。错误也是信息，这是 ReAct 自我修正能力的来源。
现在各家模型厂商的原生 function calling，本质上就是把 ReAct 的 Action/Observation 从纯 prompt 技巧变成了结构化协议：模型输出 JSON 格式的工具调用，框架执行后以 tool message 角色回传结果。范式没变，只是不再依赖脆弱的文本解析。
ReAct 的局限和变种
ReAct 是边想边做，适合路径不确定、需要即时反馈调整的任务。它的短板是缺乏全局规划，容易走一步看一步、在长任务上跑偏。于是有了 Plan-and-Execute 这类变种：先让规划器生成完整计划，执行器逐步执行，定期 replan。还有 Reflexion 在失败后让模型写一段「反思」注入上下文，提升下一轮成功率。面试里能提到这层对比，说明你不只背了名词，而是理解范式之间的取舍。
可能的追问
追问：循环停不下来怎么办？
三道防线：模型层的 finish 动作作为正常出口；框架层的最大轮数和 token 预算作为硬刹车；再加上重复检测——连续几轮 Action 和 Observation 高度相似就判定卡死，强制终止或降级让人工接管。
追问：ReAct 和 CoT 冲突吗？
不冲突，是包含关系。ReAct 里的 Thought 本身就是 CoT，只是 CoT 的推理过程被行动打断成了多段。可以理解为：CoT 是一次性推理，ReAct 是「分段推理 + 每段之间插入真实世界反馈」。
追问：Thought 一定要显式输出吗？
不一定。用原生 function calling 时很多实现是隐式推理，模型直接出 tool call。显式 Thought 的好处是可解释、方便 debug，还有研究表明能提升决策质量；代价是多消耗 token、增加时延。不少生产系统保留显式 Thought 但不上链给用户，只进日志。