核心框架
ReAct 框架
概念
ReAct 的全称是 Reasoning + Acting（推理 + 行动）。可以把它想象成：一个会做题的学生，不是一口气写完答案，而是 边想边做——先在心里说一句「我接下来要干什么」（推理），然后真的去查资料、用计算器、调 API（行动），看到结果后再继续想下一步。
和传统「只输出最终答案」的提示不同，ReAct 要求模型在文本里 显式交替 写出：
- 推理（Thought）：为什么要这么做、下一步选什么工具、预期看到什么。
- 行动（Action）：调用某个工具（如搜索、代码执行），并给出参数。
- 观察（Observation）：环境/工具返回的结果。
- 循环多次，直到模型给出 Final Answer。
一句话：ReAct = 把「思考过程」和「工具使用」写进同一条轨迹里，让推理可监督、可纠错、可复现。
ReAct 和「普通 CoT 提示」有什么本质区别？
普通 CoT 只在模型内部展开推理链，不强制与外部环境交互；ReAct 把推理与 可执行行动 绑定，每一步行动后都有 真实 Observation 反馈，从而用工具结果约束生成，降低闭卷幻觉。
ReAct 为什么要显式写出 Thought？
显式 Thought 有三类价值：可解释性（便于人类审计）、可调试性（定位哪一步选错工具）、学习信号（可做监督微调或评估中间步骤质量）。在工程上，Thought 也帮助模型在下一步更稳定地选择 Action。
优缺点是什么
优点
- 可解释：轨迹可读，便于调试与评测中间步骤。
- 接地：通过工具把答案锚定在可验证数据上。
- 通用：与具体工具解耦，易于替换搜索/代码/SQL 等。
缺点
- 多轮调用：成本高、延迟大。
- 格式脆弱：模型若偏离模板，需要解析器与重试策略。
- 规划能力有限：逐步贪心，复杂任务上可能缺「全局最优计划」（对比 Plan-and-Execute）。
Plan-and-Execute 框架
概念
Plan-and-Execute 是 两阶段：先 制定计划（Planner），再 逐步执行（Executor）。像旅行前先列行程单，再按天去玩；执行中若发现「景点关门」，再 改行程（Re-planning）。
它与 ReAct 的差别可以记成：ReAct 常常是「走一步看一步」；Plan-and-Execute 先有一张「总蓝图」，再落地，适合步骤多、依赖关系清晰的任务。
Planner 组件设计（要点）
- 输入：用户目标、约束（时间/预算/格式）、当前已知上下文。
- 输出：结构化计划（步骤列表、每步子目标、依赖、所需工具类型）。
- 技巧：计划 粒度适中；过细易 brittle，过粗难执行。
Executor 组件设计（要点）
- 输入：当前步骤、state（已完成结果、中间变量）。
- 输出：步骤产物 + 新 state。
- 工具路由：每一步可选用不同工具（搜索、代码、数据库）。
重规划（Re-planning）机制
触发条件常见有：
- 工具失败、返回空、超时；
- Observation 与假设冲突；
- 新信息使原计划步骤多余或顺序错误。
Re-planning 做法：
- 局部修复：只替换失败步骤之后的子计划；
- 全局重规划：回到目标重新生成计划（成本高但更稳）。
Plan-and-Execute 相比 ReAct 什么时候更占优？
当任务步骤多、结构清晰、需要全局分解（如多文件代码改动、数据分析流水线、复杂调研提纲）时，Planner 先给出路线图能减少「短视」；ReAct 更擅长 动态工具交互、逐步探索。
Re-planning 会不会导致「计划抖动」？怎么缓解？
会。频繁重规划可能让执行轨迹不稳定。缓解方式包括：限制重规划次数、局部重规划优先、在 state 中保留已验证事实、对计划变更加 一致性检查（新旧计划差异说明）。
Reflexion 框架
概念
Reflexion 的核心是：做完不等于结束——还要 评估做得好不好，把 教训 记下来，下次 带着教训重试。像考试做错后写错题本，而不是盲目刷同一道题。
它强调 语言化反思（自然语言反思条目），而不是只改参数；反思作为 记忆，影响后续尝试的策略。
自我反思机制
典型角色分工（概念上）：
- Actor：生成行动/答案（可接工具）。
- Evaluator：给反馈（对/错、评分、缺失项）。
- Reflector：根据反馈写 反思文本（指出错误原因与改进策略）。
工作流程：Action → Evaluation → Reflection → Retry
Reflexion 和「让模型自己检查一遍」有什么不同？
自检往往是一次性的；Reflexion 把评估与反思 显式化、结构化，并 跨尝试复用 反思文本，形成可累积的「策略记忆」。工程上更易控制与评测。
LATS（Language Agent Tree Search）
LATS 把 Agent 的决策看成在 树 上搜索：每个节点是一种「状态/中间思路」，分支是不同行动。任务复杂、存在多条可能路径时，与其一次走到底，不如 探索多条路，用评估函数判断哪条路更有希望。
它常与 蒙特卡洛树搜索（MCTS） 思想结合：通过 选择—扩展—模拟—回传 在探索与利用之间折中，把「语言推理」嵌进搜索节点。
LangChain Agent 实现
LangChain 把 LLM、提示模板、工具、记忆、解析器等拼成可运行程序。Agent 在这里通常指：由 LLM 决定下一步调用哪个工具 的循环执行体；AgentExecutor 负责「跑这个循环直到结束」。
LangChain 里 AgentExecutor 解决的核心问题是什么？
把「模型决策 → 工具执行 → 结果回填 → 再决策」的 控制流标准化，统一处理 迭代限制、错误处理、中间消息结构，让开发者专注工具与提示。
LangGraph 状态机
如果把 LangChain Agent 看成「一套默认的循环」，LangGraph 则是把 Agent 工作流画成 图：节点是处理步骤（调用模型、调工具、审核），边是流转关系。复杂业务往往需要分支、循环、人工确认——用图更直观。
什么时候选 LangGraph 而不是 AgentExecutor？
当流程不是「单一工具循环」，而是需要 多阶段流水线、条件路由、回环修复、人工审核节点、并行任务 时，用图编排更清晰可维护。
LangGraph 的状态更新为什么要谨慎设计？
多节点写入同一字段可能冲突；需要 schema 约束、归约策略（append vs replace）、明确每个节点的写入职责。
AutoGen / CrewAI 等多 Agent 框架
多 Agent 框架把任务拆给多个「角色」：有人负责写代码，有人负责审查，有人负责检索。它们通过 对话 或 结构化消息 协作。AutoGen 偏 可编程的对话与工具；CrewAI 偏 角色驱动的团队流程（Crew）。
多 Agent 一定比单 Agent 更强吗？
不一定。更多 Agent 可能带来 协调成本、错误级联、对话冗长。当任务可清晰分工且有评估机制时收益大；否则单 Agent + 强工具可能更简单高效。
如何避免多 Agent「互相附和」？
引入 独立审查角色、基于规则的检查、外部工具验证（测试、检索），并明确 停止条件 与 异议处理流程。
综合
Plan-and-Execute 的最大风险是什么？如何缓解？
风险是 错误计划污染全局；缓解是 可验证子步骤、重规划、强 Planner 约束输出 与 执行期监控。