第四章习题个人解答

[SilkSong]

一

• ReAct: 思考-行动-观察, 再思考, 再行动, "走一步看一步", 动态规划与纠错能力
• Plan-and-solve: 是先思考后行动, 谋定而后动, 一次性形成完整的计划, 工作流程分为规划阶段和执行阶段。
• Reflection: 先行动后反思, 再优化，事后自我循环纠正

ReAct 和 Plan-and-solve 的区别是直观的, 一个是走一步看一步，动态规划，一个是谋定而后动，先生成整体的计划，再严格按步骤执行；
ReAct 和 Reflection 都是思考-行动循环执行, 也都有着之前执行的历史记忆。但 Reflection 根据它的意识词, 它可以对当前的行动进行反思, 并且它并不是一定会进行下一次行动, 如果当前行动足够好，它就会停下；相反，如果当前行动非常不好, 它会反思, 可能会考虑别的方法, 而不是沿着当前路线持续迭代。

2. 我会选择 ReAct 作为基础架构。 首先该场景并不需要按照步骤执行计划, 所以 Plan-and-solve 不适合, 其次它也不是对最终结果的质量、准确性和可靠性有极高要求的场景，并且要求一定的实时性，所以 Reflection 并不合适。ReAct 是合适的, 它需要调用外部工具 (智能家居的 API), 天然的就适合使用 ReAct 框架, 其次 ReAct 可以根据外部的反馈例如天气, 房间温度/湿度来判断是否开启空调/加湿器, 从而达到自主调节的目的

3. 对于一个复杂的问题, 可以先由 Plan-and-solve 形成一个整体的执行框架, 例如 step1, step2, step3..... 在每个执行步骤内, 通过 ReAct 来实现外部工具调用以及行动决策, 在 ReAct 过程中, 加入 Reflection 的思想, 例如再返回 observation 后，反思工具选对了么？如果选的不对 是否应该选择新的工具等..

二

1. 在学习过程中, 多次运行代码，LLM输出的最终行动 (Finsih Action) 都只有起始大括号, 没有终止大括号, 导致代码 match = re.match(r"\w+\[(.*)\]", action_text) 会因为缺少 \] 而解析失败, 本质上是 LLM 输出的是自然语言, 一点符号上的确实或者变动就会导致正则匹配失败。

2. 可以不解析自然语言, 直接让模型输出结构化结果例如 XML 或者 JSON, 一般是 JSON, JSON 有许多库可以更鲁棒的解析；或者彻底绕开文本解析, 使用 Function Calling, 让模型直接返回结构化 JSON, 由服务端保证结构, 但依赖底层 LLM/SDK 的支持, 不具有普遍性

3. 代码参见: https://github.com/SilkSong/Hello-Agents-Solution/blob/main/chapter04/ReAct_JSON.py
   JSON 解析:

   1. 更鲁棒，更易扩展
   2. 教学上略显不直观

   正则解析:

   1. 实现简单, 教学直观，不需要引入第三方库
   2. 脆弱，不易扩展, 难以校验

三

AI 生成, 代码参见: https://github.com/SilkSong/Hello-Agents-Solution/blob/main/chapter04/toos_Calculator.py

四

• 新增 Evaluator：输入当前步骤、结果、原始问题、历史记录，输出 {ok/failed, reason}
• 新增 Replanner：输入原始问题、历史、失败原因、剩余计划，输出新计划
• 流程：1. 在 Executor 的 for-loop 中，把每步结果喂给 Evaluator 2. Evaluator 判定失败 → 触发 Replanner → 用新计划替换“剩余步骤” 3.用“历史记录 + 失败原因 + 已完成步骤 + 当前上下文”作为重规划上下文

2. ReAct 更合适, 首先该场景中智能体需要具备调用各种外部的工具的能力, 其次旅行中会发生各种 X 因素, 例如车票售罄, 天气变化等, 需要根据不同的情况做出动态的决策
3. 这种设计类似于习题 1.3 的回答, 首先生成高层次的抽象计划确保了整个行动方案的正确性, 不会偏离方向太多, 在子计划中可以引入 ReAct 和 Reflection 框架的思想, 进行动态的调整和反思, 让整个规划更加灵活

五

1. 反思更强会更容易发现算法的瓶颈，更容易一步到位的指出优化方向, 加上更快的模型来做执行，会让整体响应时间下降
2. 还不够合理。目前模型如果回答无需提升, 用户对于是否下一次迭代是否会更好并不透明。合并反思和修改模块, 无论回答是否包含无需提升, 都显式的给出第二次代码的结果。引入一个评估模块, , 对于两次代码进行评估，限定模型的回答为 YES 还是 NO, 如果没有实质性提升，则模型回答 NO, 优化停止。
3. 在代码案例的基础上, 优化反思模块的提示词, 可以一次性从段落逻辑性、方法创新性、语言表达、引用规范等多角度进行反思，或者拆分成多个反思模块, 依次执行, 具体需要看工程效果，模型能力以及响应时长, 拆分成多个模块的优势在于可以选用不同的模型进行不同角度的反思，确定在于 token 消耗过多，响应时间较长

六

1. ReAct 的提示词定义了一个模板, 包括角色定义, 工具清单, 格式规约, 和动态上下文, 其中工具清单和格式规约强制 LLM 的输出具有结构性, 才得以被解析为 thought 和 action 来服务于整个 ReAct 的核心流程, 提供了 history 的历史可以让 LLM 拥有完整的上下文进行决策。

   Plan-and-solve 则因为包含一个规划器和一个执行器的角色，需要编写两个提示词, 除了基础的角色定位, 规划器也强制规约了输出的格式，方便执行器进行每步计划的解析; 执行器则包含原始问题, 完整计划，历史步骤结果以及当前步骤来让 LLM 拥有完整的上下文进行决策

2. 尝试了几个实例, 更换后没有太多差别😂。但理论上, 对于特定的任务, 如果改为"注重代码可读性的开源项目维护者", 代码中可能会多一些注释来帮助理解

3. ReAct 加入 Few-shot

REACT_PROMPT_TEMPLATE = """
请注意，你是一个有能力调用外部工具的智能助手。

可用工具如下：
{tools}

请严格按照以下格式进行回应：

Thought: 你的思考过程，用于分析问题、拆解任务和规划下一步行动。
Action: 你决定采取的行动，必须是以下格式之一：
- `{{tool_name}}[{{tool_input}}]`：调用一个可用工具。
- `Finish[最终答案]`：当你认为已经获得最终答案时。
- 当你收集到足够的信息，能够回答用户的最终问题时，你必须在`Action:`字段后使用 `Finish[最终答案]` 来输出最终答案，并确保左右中括号闭合。

下面是一些示例：

示例 1:
Question: 北京的天气怎么样？

Thought: 用户在询问天气信息，我需要通过搜索工具查询北京当前的天气情况。
Action: Search[北京 当前 天气]

Thought: 我已经获取到天气信息，可以直接回答用户。
Action: Finish[北京今天晴，气温约 25℃，微风，适合外出。]

---

示例 2:
Question: 华为最新发布的手机型号是什么？

Thought: 手机发布信息更新较快，我需要通过搜索工具获取最新发布内容。
Action: Search[华为 最新 发布 手机]


Thought: 信息已足够，可以回答用户问题。
Action: Finish[华为最新发布的手机是 Mate 60 Pro，主要卖点包括卫星通信和自研芯片。]

现在，请开始解决以下问题：
Question: {question}
History: {history}
"""

七

1. 选择 ReAct + Reflection (条件e)
2. 电商平台订单查询工具, 物流查询工具, 邮件发送工具, 公司政策查询工具
3. 首先, 对于提示词的角色设定, 需要强调在系统提示词中表示它是一个公司的智能客服, 它的行为要始终符合公司的利益, 其次, 在跟用户进行回答以及回复邮件时, 设计约束尽可能的展示友好, 礼貌的态度

• 对于错误退款和滥批退款, 高金额时触发规则引擎强制约束进行人工兜底
• 对于错误的拒绝, 采用低置信度触发 Reflection, 提供补充材料辅助决策
• 对于合规/法律问题, 敏感场景的关键字检测, 强制人工介入

[CodeHoker]

牛

[chuliyuoujian]

太赞了！