推理范式与架构选型

Q：你用 ReAct 还是 Plan-and-Execute？为什么？

来源：腾讯 Agent 岗终面 【蚂蚁AI应用开发二面同题：ReAct 核心原理与复杂任务提升逻辑】【字节二面同题：ReAct vs Plan-and-Execute 理解与优劣对比】【小红书 Agent 岗一面追问：ReAct/Plan Mode 双模式与多轮状态机实现】【字节火山引擎 Managed Agent 一面追问：Reasoning + Action 循环】

新手答：“看情况，复杂用 ReAct，简单用 Plan。”

高手答：

先明确两者的核心机制。ReAct（Reasoning + Acting）是推理与行动交替的循环——模型先 Thought（思考当前该做什么）、再 Action（调用工具）、拿到 Observation（工具返回），根据新信息再 Thought，循环直到任务完成。它的特点是每一步决策都基于上一步的真实反馈，天然适应不确定性。Plan-and-Execute 则是规划与执行分离——Planner 先一次性生成完整步骤序列，Executor 按序执行，互不干扰。它的特点是全局最优、可预测、可审计，但对中间变化的适应性弱。

我们按任务不确定性来选。流程固定的内部工具（如日报生成）用 Plan-and-Execute，省成本。面对用户的开放任务（如旅行规划）必须用 ReAct，因为用户下一秒就可能改需求。

核心技巧是在 Plan 的每个步骤里嵌入“ReAct 式检查点”——比如调用天气 API 后，自动检查返回字段是否完整，不完整立刻触发修复，而不是让整个计划崩掉。

差距在哪：新手只说了“看情况”，但没有给出判断标准。高手的回答有三个层次：① 明确的选择维度（任务不确定性）；② 具体的业务对应（内部工具 vs 用户任务）；③ 混合方案的工程技巧（检查点机制）。面试官要的不是“我知道这两个东西”，而是“我在实际系统里怎么选、怎么用”。

追问：CoT 和 ReAct 的核心区别是什么？

来源：淘天 AI Agent 二面

很多人把 CoT 和 ReAct 混为一谈，认为“ReAct 就是带工具的 CoT”——这只对了一半。

维度	CoT（Chain of Thought）	ReAct（Reasoning + Acting）
本质	纯推理链——模型在输出答案前先“想一想”	推理 + 行动交替——想一步、做一步、看结果、再想
信息来源	仅靠模型内部知识和上下文	可以通过工具调用获取外部信息
典型输出	思考过程 → 最终答案	Thought → Action → Observation → Thought → ...
适用场景	逻辑推理、数学、常识推理	需要查询外部数据、调用 API、操作环境的任务
局限	无法获取模型不知道的信息	工具调用引入延迟和不确定性

关键区别：信息闭环 vs 信息开环

CoT 是闭环推理——所有信息在推理开始时就已经确定，模型只是把隐式推理显式化。ReAct 是开环推理——每一步行动的结果会改变后续推理的方向，信息在推理过程中动态增加。

CoT：已知信息 → 推理步骤1 → 推理步骤2 → 答案
ReAct：已知信息 → 推理 → 行动（搜索/查询）→ 新信息 → 推理 → 行动 → 答案

所以判断用哪个的标准很简单：回答这个问题需不需要模型目前不知道的信息？ 需要就用 ReAct，不需要就用 CoT。

追问：Plan-and-Execute 架构里，Planner 和 Executor 之间是如何通信的？

来源：字节后端 Agent 二面

Planner 和 Executor 之间的通信是 Plan-and-Execute 架构的核心设计点——通信格式决定了系统的灵活性和可调试性。

标准通信协议：

Planner 输出的不是自然语言描述，而是结构化的执行计划：

{
  "plan": [
    {"step": 1, "action": "search_flights", "params": {"from": "北京", "to": "上海", "date": "2026-05-10"}, "depends_on": []},
    {"step": 2, "action": "search_hotels", "params": {"city": "上海", "checkin": "2026-05-10"}, "depends_on": []},
    {"step": 3, "action": "generate_itinerary", "params": {}, "depends_on": [1, 2]}
  ]
}

Executor 按依赖关系执行每步，返回结构化结果：

{"step": 1, "status": "success", "result": {"flights": [...]}}

三种通信模式：

模式	流程	适用场景
一次性计划	Planner 生成完整计划 → Executor 顺序执行 → 返回最终结果	任务确定、步骤间依赖少
迭代式重规划	Planner 生成计划 → Executor 执行一步 → 结果回传 Planner → Planner 决定是否调整后续计划	中间结果影响后续步骤
事件驱动	Planner 注册事件监听 → Executor 执行并发出事件 → Planner 响应事件动态调整	长时间运行、外部环境会变化

生产中最常用迭代式重规划——每步执行完 Planner 都重新评估，兼顾了计划性和灵活性。关键是 Executor 返回的结果要带上足够的上下文（成功/失败/部分成功 + 关键数据），让 Planner 有足够信息做判断。

---

Q：Tree of Thoughts (ToT) 在线上系统里能用吗？成本不高？

来源：腾讯 Agent 岗终面

新手答：“理论上可以，但成本高，一般不用。”

高手答：

重度 ToT 线上不能用，但轻量化版本是杀手锏。

我们用在“客服话术生成”上：当用户投诉时，让模型并行生成 3 条不同风格（共情、解释、补偿）的回复草稿，然后用一个非常轻量的评判模型（甚至是一组规则）快速选出一条最合适的，再继续细化。

这本质是束搜索（Beam Search），成本是单次生成的 3 倍，但换来的是回复质量质的提升，在关键场景 ROI 很高。

差距在哪：新手只回答了“能不能用”，结论是“不能”——这等于没回答。高手的思路是“原版不能直接用，但核心思想可以工程化降级”，并给了一个具体场景。面试官考的是“你能不能把论文里的方法落地”，这需要理解方法的本质（并行搜索 + 评估筛选）而不是只记住名字。