一、总结

在本章，从零开始编码实现了三种业界经典的智能体构建范式：ReAct、Plan-and-Solve、Reflection。而在ReAct范式诞生之前，主流的方法可以分为两类：“纯思考型”和“纯行动型”。

1. ReAct：Resonning-Acting，“思考-行动-观察”循环。在本章中，实现了一个利用搜索引擎回答自身知识库无法覆盖的问题，有较高的实时性。

此种范式的优点：高可解释性（Thought过程透明）、动态规划与纠错（基于对外界世界的observation，展开Thought并执行Action）、工具协同能力（使用LLM进行规划推理，调用工具解决问题）。
缺点：对LLM的强依赖性（当LLM规划错误导致agent错误）、执行效率问题（调用LLM和外部工具过程中的网络延迟和计算成本）、提示词的脆弱性（提示词的细微改动对LLM的影响，并非所有LLM都能够持续稳定的遵循预设格式）。

2. Plan-and-Solve：先plan，后solve。在本章中，使用智能体解决了一道简单的数学题，分别计算周一、周二、周三卖出的苹果数，最后相加即得到三天总共卖出的苹果数。

在规划阶段，通过设计prompt，接收原始问题，输出清晰、分步骤、结构化的行动计划。
在执行阶段，根据规划阶段得到的完整计划，严格按照步骤，逐一解决问题。
优点：保持更高的目标一致性，避免在中间步骤中迷失方向。
适合任务：结构性强、可以被清晰分解的复杂任务。

3. Reflection：“执行-反思-优化”。在本章中，实现了解决“查找一定范围内的素数”这一问题的代码，并从时间复杂度和空间复杂度两方面进行代码优化。

价值所在：提供了一个内部纠错回路；实现了持续优化过程，显著提高了复杂任务的最终成功率和答案质量；构建了一个临时的“短期记忆”。
适用场景：存在明确的优化路径、反思点清晰、优化方向明确。
优点：解决方案质量的跃迁；智能体鲁棒性与可靠性增强。
缺点：模型调用开销增加；任务延迟显著提高；提示词工程复杂度上升。

二、习题（参考LLM）

1.本章介绍了三种经典的智能体范式: ReAct 、 Plan-and-Solve 和 Reflection 。请分析:

• 这三种范式在"思考"与"行动"的组织方式上有什么本质区别？
• 如果要设计一个"智能家居控制助手"（需要控制灯光、空调、窗帘等多个设备，并根据用户习惯自动调节），你会选择哪种范式作为基础架构？为什么？
• 是否可以将这三种范式进行组合使用？若可以，请尝试设计一个混合范式的智能体架构，并说明其适用场景。

答：１）ReAct采用边思考边行动的组织方式（可能陷入局部最优）；Plan-and-Solve采用先思考后行动的组织方式（保证目标一致性）；Reflection采用先行动后思考的组织方式（引入反思、内部纠错）。

２）（LLM）我会选择ReAct范式作为基础架构。分析“智能家居控制助手”这个任务，用户下达指令后可能希望快速响应，即对实时性有较高要求；对家居设备的控制是一个序列决策过程，例如先检查环境温度，再选择空调开启温度，这要求智能体与环境交互性较高；此外，这一任务本身较为简单，不应该再进行分解，也不需要反思优化，不适用于Plan-and-Solve和Reflection 范式。

３）（LLＭ）可以将这三种范式组合使用，去解决复杂、环境动态变化、具体操作对实时性有较高要求的任务。以自动驾驶系统为例，在这个系统中，从地点A行驶到地点B需要先给出一个完美计划，即路线规划（Plan-and-Solve）。在具体行驶过程中，需要不断采集周围环境状态，一旦需要避障马上采取行动（ReAct）。在完成一次规划后需要进行反思复盘，并进行路线优化（Reflection ）。

2.在4.2节的 ReAct 实现中，我们使用了正则表达式来解析大语言模型的输出（如 Thought 和 Action ）。请思考：

• 当前的解析方法存在哪些潜在的脆弱性？在什么情况下可能会失败？
• 除了正则表达式，还有哪些更鲁棒的输出解析方案？
• 尝试修改本章的代码，使用一种更可靠的输出格式，并对比两种方案的优缺点。

答：1）在4.2节中，实现了一个调用外部搜索引擎的智能问答助手，在实现过程中，使用正则表达式提取Thought和Action、解析工具名称和输入以及最终答案。这种使用正则表达式解析模型输出的方法要求模型严格按照格式输出，并寻找匹配的关键词进行工具调用，当大模型并没有按照要求的格式输出时，会导致整个流程无法正确执行。(LLM)总的来说，正则表达式解析的方式存在以下脆弱性：格式偏差脆弱（没有严格按照格式、大小写不一致），内容缺失（比如：模型在Thought中可能包含"Action:"文本，导致解析的内容不准确）。
2）除了使用正则表达式对大语言模型的输出进行解析，可以在提示词中明确要求大模型输出结构化数据，这种方式更加可靠，易于解析。
3）

3.工具调用是现代智能体的核心能力之一。基于4.2.2节的 ToolExecutor 设计，请完成以下扩展实践:

• 为 ReAct 智能体添加一个"计算器"工具，使其能够处理复杂的数学计算问题（如"计算 (123 + 456) ×789/ 12 = ? 的结果"）
• 设计并实现一个"工具选择失败"的处理机制:当智能体多次调用错误的工具或提供错误的参数时，系统应该如何引导它纠正？
• 思考:如果可调用工具的数量增加到50个甚至100个，当前的工具描述方式是否还能有效工作？在可调用工具数量随业务需求显著增加时，从工程角度如何优化工具的组织和检索机制？

答：1）在4.2.2节中，ToolExecutor类中定义了以下三个方法：工具注册、工具获取、可用工具获取，在使用的时候，需要先初始化工具执行器toolExecutor = ToolExecutor()，然后注册该工具search_description = "一个网页搜索引擎。当你需要回答关于时事、事实以及在你的知识库中找不到的信息 时，应使用此工具。" toolExecutor.registerTool("Search", search_description, search)，其后可以打印可用工具print(toolExecutor.getAvailableTools())，调用工具toolExecutor.getTool(tool_name)。
如果要添加一个“计算器”工具，可以仿照search函数，调用外部科学计算器Api作为计算器，也可以进行编程实现一个简单的计算器，将其封装在Calculator中，然后进行工具注册calculator_description = "一个简单计算器，处理复杂的数学计算问题。" toolExecutor.registerTool("Calculator", calculator_description, calculator)和使用。
２）(LLM)在智能体运行过程中，工具选择失败是常见问题，为此，设计一个分层引导与自适应纠正机制，包括以下几步：a)错误分类体系，识别错误类型，包括工具选择错误、参数错误、工具不可用等；b)针对不同的错误类型，采取不同的措施，工具错误-提供可用工具列表-降低该工具权重-重新生成计划；参数错误-返回具体参数要求-参数解析提示-重试当前步骤。如果连续失败多次，则启动高阶干预，例如通知开发者，等待人工决策；例如切换备用策略，启用规则引擎或预设流程；例如任务降级，进行任务分解，逐步验证。
3)(LLM)如果可调用工具的数量增加到50甚至100个，当前的工具描述存在以下问题：a)上下文长度限制，ReAct智能体会将工具清单和每轮上下文交互记录在提示词中，所有工具描述拼接后可能超过上下文窗口限制。b)检索效率下降，每次进行工具选择时都需要遍历全部工具做语义匹配，会较大的影响响应速度。c)错误匹配率升高，当工具中存在语义相近的工具名称时，可能导致工具选择错误。d)维护成本高，新增、修改某一工具时需要人工更新描述，容易出错且难以保证一致性，提高了维护成本。e)缺乏结构化组织，工具呈扁平列表，缺乏分类、层级、依赖关系相关描述，不利于工具管理。为了解决以上问题，可以采用分阶段、分层次的工具发现与调度架构，核心思想是缩小候选集，再进行精细匹配。展开来说，在工具选择过程，使用两阶段检索，先快速筛选得到一个候选工具集合，再进行精细排序，选择最终工具。在每一轮推理结束后，记录每次工具选择的结果，选择指标进行评估，使用强化学习和监督微调训练专门的工具选择器模型。

4.Plan-and-Solve 范式将任务分解为"规划"和"执行"两个阶段。请深入分析:

• 在4.3节的实现中，规划阶段生成的计划是"静态"的（一次性生成，不可修改）。如果在执行过程中发现某个步骤无法完成或结果不符合预期，应该如何设计一个"动态重规划"机制？
• 对比 Plan-and-Solve 与 ReAct :在处理"预订一次从北京到上海的商务旅行（包括机票、酒店、租车）"这样的任务时，哪种范式更合适？为什么？
• 尝试设计一个"分层规划"系统:先生成高层次的抽象计划，然后针对每个高层步骤再生成详细的子计划。这种设计有什么优势？

答：1）在4.3节中，基于Plan-and-Solve范式构建智能体计算三天共卖出的苹果个数。在规划阶段，通过提示词引导大语言模型生成完整计划，在执行阶段，则按照计划中的每一步进行计算。这种范式看似高效，但如果在规划阶段出现问题，将会导致整个智能体的工作是无效的。为了解决上述问题，应该引入一个“动态重规划”机制，这一机制的核心思想是持续监控、条件判断、必要时触发重新规划。具体来说，每一次调用工具后，获取工具返回值、判断任务必要性即该工具的调用是否合理，判断错误类型，并选择性的进行局部重新规划或全局重新规划。
2）Plan-and-Solve这一范式更合适，ReAct范式边思考边行动，更适用于对响应速度有较高要求的简单场景，显然，题干所述的任务包含多个明确的子任务，它更看重规划的准确性和逻辑性，因此，Plan-and-Solve这一范式更为合适。
3）优势：a)降低认知负荷，LLM不必一次性考虑所有细节，只需要先关注“做什么”，在解决“怎么做”的问题。b)高可解释性与可控性，用户可以看到整体计划框架，便于进行干预。c)强鲁棒性与灵活性，某个子计划失败只影响局部，也只需要重新规划该部分，而无需重新规划整个计划。d)执行并行与异步执行，不同高层步骤对应不同的子计划，可以同时执行，显著提升效率。

5.Reflection 机制通过"执行-反思-优化"循环来提升输出质量。请思考:

• 在4.4节的代码生成案例中，不同阶段使用的是同一个模型。如果使用两个不同的模型（例如，用一个更强大的模型来做反思，用一个更快的模型来做执行），会带来什么影响？
• Reflection 机制的终止条件是"反馈中包含无需改进"或"达到最大迭代次数"。这种设计是否合理？能否设计一个更智能的终止条件？
• 假设你要搭建一个"学术论文写作助手"，它能够生成初稿并不断优化论文内容。请设计一个多维度的Reflection机制，从段落逻辑性、方法创新性、语言表达、引用规范等多个角度进行反思和改进。

答：1）优势：成本效益：使用较小的模型做执行，较大的模型做反思，可显著降低计算成本；性能优势：更强大的模型在复杂任务上表现更佳，而小模型的执行效率更高；专业化分工：在不同阶段使用不同的大模型分别完成反思和执行动作，则可以实现对结果的针对性微调。挑战：一致性风险：不同的大模型知识、风格、偏好不一致，要针对性的解析不同模型输出；信息损失：反思模型和执行模型的能力不一致，可能导致执行模型无法准确完成反思模型的动作，反思模型不理解执行模型的能力限制；复杂协调：需要额外机制确保两个模型有效协同。
2）Reflection机制的局限性：过早停止；缺乏量化的反思效果评估指标；忽略收敛性判断。改进方向：多指标收敛检测-语义相似度、问题解决率；目标达成度评估-基于任务完成度判断；资源预算平衡-综合权衡评估时间、计算成本、答案质量；借助量化指标辅助评估。
3）（Reflection机制：执行-反思-优化）想要实现一个能够生成初稿并不断优化论文内容的“学术论文写作助手”，在执行阶段需要生成一份论文初稿；在反思阶段进行多维度的评估，评估维度包括段落逻辑、方法创新、语言表达、引用规范多个角度，并根据重要性分配不同的权重，主要进行各维度问题的定位识别，输出指标包括量化的评估分数、收敛判断结果，在优化阶段生成改进策略，并主要改进反思阶段识别到的各维度问题。

6.​​​​​​​提示词工程是影响智能体最终效果的关键技术。本章展示了多个精心设计的提示词模板。请分析:

• ​​​​​​​对比4.2.3节的 ReAct 提示词和4.3.2节的 Plan-and-Solve 提示词，它们显然存在结构设计上的明显不同，这些差异是如何服务于各自范式的核心逻辑的？
• 在4.4.3节的 Reflection 提示词中，我们使用了"你是一位极其严格的代码评审专家"这样的角色设定。尝试修改这个角色设定（如改为"你是一位注重代码可读性的开源项目维护者"），观察输出结果的变化，并总结角色设定对智能体行为的影响。
• 在提示词中加入 few-shot 示例往往能显著提升模型对特定格式的遵循能力。请为本章的某个智能体尝试添加 few-shot 示例，并对比其效果。

答：１）在ReAct范式中，提示词采用“Thought-Action-Observation”三段式循环结构，强调快速实时反馈驱动的动态推理。而ReAct范式的核心目标是边思考边行动，适用于需要与环境频繁交互的任务，例如4.2.3节中的网页搜索案例；Plan-and-Solve范式则是先思考再行动，面对一个复杂问题，会先进行整体规划和任务分解，再逐步执行，强调整体行为的一致性。因此提示词采用明确的有先后顺序的两阶段，即planning和solving，强调目标一致性，避免陷入局部最优。
2）角色设定对智能体行为的影响：不同的角色会让模型在后续任务中有不同的关注点，不同的知识分布与语言风格和不同的价值判断。
3）效果：引入少量示例来引导大模型输出，能够显著提升模型对复杂结构的遵循能力和输出质量。这对于需要高度结构化输出的任务尤为重要。

7.​​​​​​​某电商初创公司现在希望使用"客服智能体"来代替真人客服实现降本增效，它需要具备以下功能:

​​​​​a.理解用户的退款申请理由
b.查询用户的订单信息和物流状态
c.根据公司政策智能地判断是否应该批准退款
d.生成一封得体的回复邮件并发送至用户邮箱
e.如果判断决策存在一定争议（自我置信度低于阈值），能够进行自我反思并给出更审慎的建议，此时作为该产品的负责人:

• 你会选择本章的哪种范式（或哪些范式的组合）作为系统的核心架构？
• 这个系统需要哪些工具？请列出至少3个工具及其功能描述。
• 如何设计提示词来确保智能体的决策既符合公司利益，又能保持对用户的友好态度？
• 这个产品上线后可能面临哪些风险和挑战？如何通过技术手段来降低这些风险？

答：１）分析该智能体需要具备的功能，我会选择混合使用ReAct、Plan-and-Solve、Reflection三种范式。

阶段	所用范式	功能
理解与规划阶段	Plan-and-Solve	将用户请求分解为：理解理由 → 查询信息 → 判断政策匹配度 → 生成回复 → 是否需反思？提前规划逻辑路径，避免盲目响应。
执行与交互阶段	ReAct	在执行中动态调用工具（如查订单、查物流），根据观察结果更新推理，实现“边看边判”。适合处理外部数据依赖的任务。
审慎决策阶段	Reflection	当模型对决策置信度低时（如争议性退款），启动自我反思机制，重新评估依据、考虑边缘情况，提升判断稳健性。

2）
3）
4）风险与挑战：错误决策风险；用户体验下降；政策滥用或绕过；数据隐私泄露；模型幻觉。如何降低：构建A/B测试系统，部分请求由智能体处理，部分由真人处理，对比满意度与解决率；收集用户反馈，使用微调或强化学习实现提示词和智能体的优化。