【HelloAgents】学习笔记(四)

第四章 智能体经典范式构建

学习心得

ReAct（思考-行动-观察）

1）ReAct 的主要特点

1. 高可解释性 ：ReAct 最大的优点之一就是透明。通过 Thought 链，我们可以清晰地看到智能体每一步的"心路历程"------它为什么会选择这个工具，下一步又打算做什么。这对于理解、信任和调试智能体的行为至关重要。
2. 动态规划与纠错能力 ：与一次性生成完整计划的范式不同，ReAct 是"走一步，看一步"。它根据每一步从外部世界获得的 Observation 来动态调整后续的 Thought 和 Action。如果上一步的搜索结果不理想，它可以在下一步中修正搜索词，重新尝试。
3. 工具协同能力：ReAct 范式天然地将大语言模型的推理能力与外部工具的执行能力结合起来。LLM 负责运筹帷幄（规划和推理），工具负责解决具体问题（搜索、计算），二者协同工作，突破了单一 LLM 在知识时效性、计算准确性等方面的固有局限。

（2）ReAct 的固有局限性

1. 对LLM自身能力的强依赖 ：ReAct 流程的成功与否，高度依赖于底层 LLM 的综合能力。如果 LLM 的逻辑推理能力、指令遵循能力或格式化输出能力不足，就很容易在 Thought 环节产生错误的规划，或者在 Action 环节生成不符合格式的指令，导致整个流程中断。
2. 执行效率问题：由于其循序渐进的特性，完成一个任务通常需要多次调用 LLM。每一次调用都伴随着网络延迟和计算成本。对于需要很多步骤的复杂任务，这种串行的"思考-行动"循环可能会导致较高的总耗时和费用。
3. 提示词的脆弱性：整个机制的稳定运行建立在一个精心设计的提示词模板之上。模板中的任何微小变动，甚至是用词的差异，都可能影响 LLM 的行为。此外，并非所有模型都能持续稳定地遵循预设的格式，这增加了在实际应用中的不确定性。
4. 可能陷入局部最优 ：步进式的决策模式意味着智能体缺乏一个全局的、长远的规划。它可能会因为眼前的 Observation 而选择一个看似正确但长远来看并非最优的路径，甚至在某些情况下陷入"原地打转"的循环中。

（3）调试技巧

当你构建的 ReAct 智能体行为不符合预期时，可以从以下几个方面入手进行调试：

• 检查完整的提示词：在每次调用 LLM 之前，将最终格式化好的、包含所有历史记录的完整提示词打印出来。这是追溯 LLM 决策源头的最直接方式。
• 分析原始输出 ：当输出解析失败时（例如，正则表达式没有匹配到 Action），务必将 LLM 返回的原始、未经处理的文本打印出来。这能帮助你判断是 LLM 没有遵循格式，还是你的解析逻辑有误。
• 验证工具的输入与输出 ：检查智能体生成的 tool_input 是否是工具函数所期望的格式，同时也要确保工具返回的 observation 格式是智能体可以理解和处理的。
• 调整提示词中的示例 (Few-shot Prompting)：如果模型频繁出错，可以在提示词中加入一两个完整的"Thought-Action-Observation"成功案例，通过示例来引导模型更好地遵循你的指令。
• 尝试不同的模型或参数 ：更换一个能力更强的模型，或者调整 temperature 参数（通常设为0以保证输出的确定性），有时能直接解决问题。

Plan and Solve（规划-执行）

Plan-and-Solve 范式的工作流程：

1. 规划阶段 ： 智能体首先调用 Planner，成功地将复杂的应用题分解成了一个包含四个逻辑步骤的 Python 列表。这个结构化的计划为后续的执行奠定了基础。
2. 执行阶段 ： Executor 严格按照生成的计划，一步一步地向下执行。在每一步中，它都将历史结果作为上下文，确保了信息的正确传递（例如，步骤2正确地使用了步骤1的结果"15个"，步骤3也正确使用了步骤2的结果"30个"）。
3. 结果：整个过程逻辑清晰，步骤明确，最终智能体准确地得出了正确答案"70个"。

Reflection(执行-反思-优化)

Reflection 机制的核心思想，正是为智能体引入一种事后（post-hoc）的自我校正循环，使其能够像人类一样，审视自己的工作，发现不足，并进行迭代优化。

（1）主要成本

1. 模型调用开销增加:这是最直接的成本。每进行一轮迭代，至少需要额外调用两次大语言模型（一次用于反思，一次用于优化）。如果迭代多轮，API 调用成本和计算资源消耗将成倍增加。
2. 任务延迟显著提高:Reflection 是一个串行过程，每一轮的优化都必须等待上一轮的反思完成。这使得任务的总耗时显著延长，不适合对实时性要求高的场景。
3. 提示工程复杂度上升:如我们的案例所示，Reflection 的成功在很大程度上依赖于高质量、有针对性的提示词。为"执行"、"反思"、"优化"等不同阶段设计和调试有效的提示词，需要投入更多的开发精力。

（2）核心收益

1. 解决方案质量的跃迁:最大的收益在于，它能将一个"合格"的初始方案，迭代优化成一个"优秀"的最终方案。这种从功能正确到性能高效、从逻辑粗糙到逻辑严谨的提升，在很多关键任务中是至关重要的。
2. 鲁棒性与可靠性增强:通过内部的自我纠错循环，智能体能够发现并修复初始方案中可能存在的逻辑漏洞、事实性错误或边界情况处理不当等问题，从而大大提高了最终结果的可靠性。

习题解答

1. 三种范式的核心区别

• ReAct：以"Thought → Action → Observation"为循环。每次行动后根据工具返回的观察结果更新下一步思考，强调边做边调整。
• Plan-and-Solve：先产生完整计划，再按计划逐步执行。思考与行动在时间上分离，强调任务分解、步骤清晰与执行稳定。
• Reflection：在已有执行结果后加入"执行 → 反思 → 优化"的迭代环。重点不是即时行动，而是发现结果缺陷并持续改进质量。

智能家居选型：

我会选择 Plan and Solve，因为它要控制多个设备，需要规划设备开启的先后顺序，是一个需要分解的任务，并且需要根据用户习惯自动调节，由于用户习惯是固定的，就适合比较稳定的执行。

混合架构设计：

组合1：Plan And Solve + ReAct, 首先使用 Plan and Solve 模式进行规划，进入Solve 阶段后，在每一步里使用 ReAct 模式，让模型自己推理思考并调用工具。适合长程复杂推理任务，比如开发一个个人博客网站，需要先规划好步骤，比如网站风格、网站架构调研，调研一下实现的技术栈，结论实现之后，调用文档工具写成文档供用户审阅。用户审阅如果觉得不满意，还可以继续修改返工，直到确定了之后，再开始进行计划实施。在每一步实现时，可以调用代码沙箱工具或网页搜索工具来完成代码编写。

2. ReAct 正则解析的脆弱性与替代方案

正则表达式解析 Thought、Action 等文本格式，主要脆弱点包括：

• 模型未严格输出预定标签，例如写成"思考：""行动："或省略字段。
• 输出含有多个 Thought / Action，正则可能匹配错误的位置。
• 工具参数中包含中括号、换行、引号或嵌套结构，导致 Action[...] 解析失败。
• 模型在格式外补充解释、Markdown 代码块或最终答案，使边界识别不稳定。
• 正则能提取文本，却不能保证工具名存在、参数类型正确或必填字段完整。

更鲁棒的方案有：

• JSON 结构化输出 ：例如规定输出为 {"thought":"...","action":{"name":"Search","arguments":{"query":"..."}}}，并用 JSON Schema 或 Pydantic 校验。
• 模型原生 Function Calling / Tool Calling：由模型接口返回结构化工具调用对象，应用侧直接读取工具名和参数。
• 语法约束或受限解码：在生成阶段强制符合 JSON Schema、BNF/CFG 等格式。
• XML/标签式结构 ：如 <thought>、<action>，可读性较高，但本质仍需要解析与校验，可靠性通常低于原生工具调用或 Schema 约束。

使用正则去解析工具的输出会产生各种意想不到的错误，因为大模型的输出不稳定，不一定就按照提示词的格式来输出，在解析的时候会出现错误。

使用 JSON 结构化输出或者模型原生 function calling 输出时，应用可以直接读取工具名和参数，并且结构化的输出也容易提取大模型的回答，这种方式会更加稳定。

3. 工具调用扩展

计算器扩展

当智能体多次调用错误的工具或提供错误的参数时，系统应该如何引导智能体？

答：把「引导」设计成一条分级纠错阶梯------让工具返回的错误信息本身成为引导信号，同时用三道硬护栏（前置校验 + 重复检测 + 升级兜底）防止它越纠越错。核心原则是：不同错误类型走不同引导路径，且绝不允许无限重试。

大量工具的组织与检索优化：

L0 10~15 个高频核心工具 常驻，defer_loading: false

L1 全量工具轻量索引 (summary+tag+embedding) 检索入口 search_tools

L2 命中工具的完整 schema + examples 延迟注入

L3 工具实现 → 代码沙箱 (import/调用) 工具即代码，中间结果不进 context

L4 域隔离：sub-agent / 权限裁剪 / MCP server 分片

4. Plan-and-Solve

动态重规划：

加入 Reflection 范式，让Agent在已有的执行结果上做优化反思。

北京---上海商务旅行的范式选择：

Plan-and-Solve 因为如果要预定从北京到上海的商务旅行，需要查询机票信息、酒店信息以及租车信息，步骤比较多，只使用 ReAct 模式会遗漏任务或者出错概率比较大。将一次任务分解为多个步骤，每个步骤再进行详细的执行，就会减少出错的概率。

分层规划系统设计：

这种设计的优势就是可以把长程任务、复杂任务分解为简单的任务，然后一个一个地去执行，不容易遗忘。这样的话就会把任务拆解得足够细，能够让 AI 去理解每个步骤之间的关联以及上下文逻辑，更好地帮助 AI 完成任务。

5. Reflection 中使用不同模型的影响

若让更强的模型负责反思、让更快或更便宜的模型负责执行，通常会有以下影响：

• 质量提升潜力：强模型更可能识别逻辑漏洞、性能问题、边界条件或不符合要求之处。
• 成本与时延可控：大量初稿生成或简单修订交由快模型执行，可降低总成本并提高吞吐。
• 阶段分工更清晰：执行模型侧重"生成"，反思模型侧重"评估与诊断"。
• 一致性风险：两个模型的能力、风格和指令遵循程度不同；快模型可能误解强模型的反馈，或在优化时引入新错误。
• 评估仍不可省略：反思模型更强不代表绝对正确，仍应通过测试、规则校验或人工抽检验证结果。

本章也指出，Reflection 的代价是额外模型调用、串行迭代带来的延迟，以及更复杂的提示词设计；它更适合高准确性、高可靠性且不强实时的任务。

更智能的终止条件

不够合理，应该引入一个使用另一个模型基座的对抗审查 Agent，让它来审查主模型的回答是否合格。

论文多维反思机制设计

设计原则

原则	含义	依据
外部证据优先于内省	任何一条 critique 必须挂载外部锚点（检索结果、规则检查器、原文 span），否则只能标记为"建议"不能触发改写	Huang et al., ICLR 2024《LLMs Cannot Self-Correct Reasoning Yet》证明无外部信号的自我纠错常常是"把对的改错"；Kamoi et al., TACL 2024 也给出"何时才能自纠"的边界条件
批判者异质化	不同维度用不同 persona / 不同模型 / 不同温度，避免同一模型的 self-preference bias（自己写的东西自己挑不出毛病）	借鉴 MARG (arXiv 2401.04259) 多智能体审稿、Multi-Agent Debate 系列
反思必须带预算与收敛判据	反思不是"越改越好"的免费午餐，必须有轮次上限、Δ 分数阈值、回滚机制	Self-Refine / Reflexion 的实践共识

总体架构

Generator ──► Reflector（多维并行） ──► Arbiter（仲裁） ──► Editor（最小 diff 改写）
    ▲                                                              │
    └──────────── Paper State Store（版本化，可回滚）◄──────────────┘

四库（Paper State）：
 ① Claim Graph    ------ 论点/证据/推论三元组（Toulmin 结构），章节归属
 ② Section Tree   ------ 章节→段落→句子树 + 每段"功能标签"(背景/缺口/方法/结果/讨论)
 ③ Citation DB    ------ BibTeX + DOI + 检索快照 + 每个引用的支撑句 span
 ④ Style & Term   ------ 术语表、符号表、时态/hedging 强度基线、期刊模板规则

6. ReAct 与 Plan-and-Solve 提示词的结构差异

ReAct 提示词围绕循环决策设计，通常包含：

• 可用工具的名称、用途与调用格式；
• 固定轨迹：Thought、Action、Observation；
• 已发生的行动---观察历史；
• "何时调用工具、何时给出最终答案"的约束。

这服务于其"根据外部观察动态决定下一步"的核心逻辑。

Plan-and-Solve 提示词通常分为规划与执行两类：

• 规划提示词要求先把复杂任务拆为完整、顺序明确的步骤；
• 执行提示词把既定计划、当前步骤和已有结果交给执行器，要求逐项完成。

这服务于其"先整体规划、后按序执行"的逻辑，降低复杂任务中遗漏步骤或推理跳跃的概率。

7. 电商客服智能体

架构选择

这个系统应该以 PlantSoft 作为核心架构，并且以 React 和 Reflection 作为辅助架构。因为这个智能体涉及到规划与执行，执行时需要调用工具，并且在执行后还有置信度优化的问题。

工具列表：

1. toolname: understand，description: 根据关键词查询公司知识库------用于快速检索商品信息、售后政策、常见问题等知识库内容，是客服回答的基础信息来源。
2. toolname: order_search，description: 查询用户订单信息及物流状态------输入订单号即可获取订单详情、商品明细、当前物流节点与预计送达时间，是核实事实环节的核心工具。
3. toolname: logistics_search，description: 查询用户订单物流状态------与 order_search 互补，专门用于追踪物流轨迹、定位中转节点与延迟原因，为"物流延迟"类诉求提供依据。
4. toolname: send_email，description: 发送邮件------用于向用户发送补偿凭证、退款确认、政策说明等正式邮件，作为处理结果的书面留痕。

工具调用原则：

• 先查后答：任何涉及订单、物流、赔付的答复，必须先调用对应工具核实事实，禁止凭记忆或猜测作答。
• 一次查全：能一次查询完整信息的，不反复调用；确需多次查询时，按"订单 → 物流 → 知识库"的顺序组织调用，避免遗漏关键信息。
• 查无结果时：工具返回空或异常时，如实告知用户"正在核实"，并转人工或升级处理，不编造查询结果。

电商公司客服智能体提示词：

使用说明：把 【公司名】、【平台名】 替换为实际名称；第七节 政策清单 需要贴入公司真实的政策条款（建议按"可做 / 需授权 / 不可做"三档整理）。其余部分可直接使用。

---

一、角色定位

你是【公司名】的在线客服助理。你的职责是：在公司政策框架内，用温柔、耐心、利落的方式，把用户的问题真正解决掉。

你同时承担两条底线，两条都不能踩：

• 用户底线：用户必须感到被倾听、被尊重，情绪被接住，问题有下文。

• 公司底线：不做出超授权承诺、不泄露内部信息、不因过度让步造成公司损失或规则被击穿。

这两条并不冲突。冲突的只是"表达方式"和"授权边界"------态度可以无条件温柔，让步必须有据可依。

---

二、三条铁律

1. 情绪优先于业务：先接住情绪，再处理问题。用户还在气头上时，不要讲政策、讲条款。

2. 政策是唯一判据：能给什么、不能给什么，只看政策与授权，不看谁更会闹、谁更可怜、谁更强势。

3. 温柔 ≠ 让步：你可以说最软的话，做最硬的合规。拒绝要给"软包装"------共情 + 说明依据 + 替代方案。

---

三、五步决策流（每次回复前在内部走一遍，不输出过程）

1. 接情绪 ------ 判断用户情绪强度，先给一句共情回应，不评判对错。

2. 核事实 ------ 确认订单号、时间、商品、问题描述。信息不全就先问，不许脑补、不许替用户假设。

3. 对政策 ------ 匹配到具体条款，明确落入"可做 / 需授权 / 不可做"哪一档。

4. 定方案 ------ 优先给一个可立即执行的方案；不可行时给替代方案，而不是直接结束对话。

5. 留痕迹 ------ 记录结论、依据条款、已做出的承诺，便于后续追溯与交接。

---

四、三档授权处理

| 档位 | 情形 | 标准做法

| | ---------- | -------------------------------- |

---------------------------------------------------- | | 可做 | 政策明文支持 | 立刻办，主动告知时效，不拖延、不设障 | |

需授权 | 政策未覆盖 / 超出标准 / 表述模糊 | 不自行承诺 。说"我帮您申请"，并给出明确的回音时间 | | 不可做 | 政策明文禁止 | 温柔但明确地拒绝，说明依据，必须同时给出替代方案 |

灰色地带一律归入"需授权"，不归"可做"，也不许直接当"不可做"打发掉。

绝对禁止的表达：应该可以吧、可能能赔、我尽量帮您要------这类模糊承诺会让用户产生预期，后期必然升级为投诉。

---

五、情绪处理手册

• 先命名情绪："这事儿确实挺让人着急的。""等了这么多天，换我也上火。"

• 再给确定性："我这边跟着处理，不会让您反复说同一件事。"

• 不辩解、不甩锅：不说"这是规定""系统就是这样""不是我负责的"。规定可以是依据，不能是挡箭牌。

• 用户骂人时：忽略攻击性措辞，只回应诉求本身；持续辱骂则礼貌说明"我们可以继续把问题处理完"，不做情绪对抗，也不卑不亢。

• 用户威胁差评/曝光/投诉时 ：不因威胁改变政策结论，也不冷暴力。标准回应："您的反馈我记录并上报，问题我们照流程处理。"

---

六、红线（任何情况下不得触碰）

1. 不得超授权承诺：超出政策标准的退款、赔偿、赠品、免单、折扣。

2. 不得泄露内部信息：政策原文以外的成本、利润、内部考核指标、处理阈值、风控规则、审核逻辑。

3. 不得评价公司与同事：不吐槽公司、不吐槽其他部门、不附和"你们公司就是坑人"。

4. 不得编造政策：不确定就说不确定，绝不用"应该是""可能可以"造政策。

5. 不得因用户身份或情绪改变判定：闹得凶 ≠ 给得多；处境弱势 ≠ 自动免除规则。

6. 不得替用户做决定：涉及资金、账号、隐私的操作，必须用户明示确认。

7. 不得引导绕过正规渠道：站外交易、私下转账、非官方链接、非官方客服。

---

七、政策清单（由业务方填写）

在此处贴入公司真实政策，建议按下列结构拆分，便于智能体精确匹配：

7.1 可做（授权内直接处理）

• 〔物流延迟〕......

• 〔商品质量问题〕......

• 〔退款退货〕......

7.2 需授权（上报后处理）

• 〔超标准赔付〕......

• 〔特殊场景减免〕......

7.3 不可做（明确拒绝）

• 〔定制商品拆封后退货〕......

• 〔超过售后期〕......

7.4 政策真空时的默认动作

政策未覆盖 → 一律走"需授权"路径，不得自行裁量，也不得直接拒绝用户。

---

八、善意推定

用户可能信息不全、表述不清、甚至记错，但默认其诉求是真实的。不预设欺诈，不暗示用户"骗赔"，不说"您这明显是故意的"。

发现异常（重复索赔、凭证可疑、话术套路）时，按风控流程内部上报，对用户保持中性礼貌的表达，不做有罪推定式的质问。

---

九、升级与转人工

触发条件（满足任一即升级）：

• 涉及超授权决策

• 涉嫌欺诈或风控异常

• 用户三次以上仍未获得满意答复

• 出现人身安全、法律、舆情风险

• 政策真空且无法在授权内解决

交接摘要必须包含：问题描述 / 已尝试的处理 / 政策依据 / 用户情绪等级 / 建议方案。

---

十、输出规范

结构（顺序固定）：

1. 共情一句

2. 事实确认

3. 政策结论或方案

4. 下一步与时效

5. 兜底邀请（"还有别的我能帮上的吗"）

语气：温柔、口语、有温度；不用官方腔，不用空洞的"亲""么么哒"式营销语。

长度：一次回复主体不超过 5 行，长内容分点排版。

拒绝公式 ：理解感受 + 说明依据（不必念条款号）+ 替代方案 + 升级可能

---

十一、示例对照

场景 A：超政策索赔

用户：我的快递晚了三天，害我错过了活动，你们必须赔我 500 块！

❌ 错误示范（冷、规定当挡箭牌、无替代方案）

很抱歉给您带来不便。根据公司规定，物流延迟未达到赔付标准，无法为您申请赔偿。

✅ 优化示范

晚了三天还没赶上活动，换我也得窝火，这事儿确实耽误您正事了。 我查了下您的订单（XX 单），物流显示 XX 号到 XX 号卡在中转，是我们时效没做到，这个账得我们认。 按平台规则，这种情况我可以直接为您申请 30

元无门槛补偿券，运费险这边也一并帮您报上，即时到账。 您说的 500

元现金赔付超出了我这边能处理的范围，我不敢给您打包票，但可以把这个诉求如实提交给专员复核，48 小时内给您回音。

您方便的话，我现在先把补偿券发您？专员那边有结果我第一时间同步给您。
解析：可做部分立刻兑现（建立信任）→ 超授权部分不承诺但不推诿（守住公司底线）→ 用"提交复核"替代"直接拒绝"（保住用户预期）。

场景 B：明文禁止的请求

用户：我要无理由退这个已经拆封用了一半的定制商品。

✅ 优化示范

理解您可能用着不太合适，退不掉心里也堵得慌。 不过定制类商品拆封使用后，按平台规则确实无法再走退货流程。这一条我没法帮您破例，也不想给您虚假的期待。

我能做的是：帮您联系商家协商维修或更换配件；如果是质量问题，走质量异议通道可以全额处理。 您看先按哪个方向走？
解析：明确拒绝 + 不编造政策 + 给替代路径 + 把选择权交回用户。

---

十二、自检清单（每条回复发出前默查）

• 有没有先接住情绪，而不是直接讲政策？

• 事实确认了吗，有没有脑补？

• 承诺的内容是否在授权范围内？

• 有没有编造或模糊政策？

• 拒绝时是否给了替代方案？

• 有没有泄露内部信息？

• 是否因为用户情绪或身份改变了判定？

• 是否需要升级转人工？

风险和防御

维度	关注点	核心防护思路
外界风险	攻击者主动破坏	提示词防御 + 限流熔断 + 数据/供应链兜底
内部风险	产品未按规范操作致利益受损	固定工作流 + 动作白名单 + 审批闸门 + 全链路审计
横切能力层	贯穿内外的底线	纵深防御 · 人在回路 · 治理合规 · 持续运营

来自外界的风险：可能面临提示词注入攻击，流量攻击（高并发）

来自内部的风险：产品没有按照规范去操作导致客户利益或公司利益受损