第四章 习题参考答案 By 安妮的心动录

[anneheartrecord]

第四章 习题参考答案

参考答案仅供参考。本章的重点不是背诵某一种范式，而是理解不同范式如何组织"思考、行动、观察、反思"，以及这些差异在真实系统中的工程后果。

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

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

核心差异

范式	核心循环	本质特点	优势	局限
ReAct	Thought -> Action -> Observation	边想边做	对环境变化响应快，适合工具调用	容易局部贪心，获取局部最优解，但缺少全局规划
Plan-and-Solve	Plan -> Execute -> Execute	先规划再执行	全局约束处理更好，适合复杂多步骤任务	静态计划容易在执行中失效，缺少自我改进能力
Reflection	Execute -> Reflect -> Refine	做完之后再打磨	适合质量优化和生成改写	迭代成本高，实时性差

智能家居控制助手应选哪种

我会以 ReAct 作为基础架构。

原因：

• 智能家居是强工具调用场景，必须直接操作灯光、空调、窗帘、音响等设备接口。
• 环境是动态的，执行完一步后必须立刻观察对应的结果，例如灯是否真的关掉、空调是否在线。
• 用户指令往往是上下文相关的，例如"也把那个关了"，需要在执行中持续解释指代。

能否组合使用

可以，而且在生产系统里通常应该组合。

推荐的混合架构是：

1. 用 Plan-and-Solve 生成高层计划。
2. 每个子步骤内部用 ReAct 执行并根据工具返回动态调整。
3. 最终输出前使用 Reflection 做质量检查或风险审查。

适用场景：电商退款、商务出行、企业报表生成、复杂客服流程等，既需要全局规划，也需要执行中观察，还需要输出质量控制。

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

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

正则方案的脆弱点

正则解析在格式完全稳定时有效，但一旦 LLM 的输出格式稍微变化就容易失效，常见问题包括：

• 多了 Markdown 代码块。
• 中英文冒号混用。
• 字段顺序变化。
• 多次 Action 连续出现。
• 模型先输出解释文字，再输出结构体。

这类失败本质上不是推理失败，而是读取的协议格式设计太脆弱。

更鲁棒的替代方案

推荐顺序如下：

1. Function Calling / Tool Calling：最佳方案，直接让模型返回 JSON 格式的结构化 Tool 调用。
2. JSON Mode：强制输出 JSON，再由程序解析。
3. JSON + 容错重试：解析失败时提取代码块 JSON、对象片段，必要时要求模型重试。

Function Calling 方案代码实现

以下代码展示如何将原本基于正则解析的 ReAct 改造为使用 Function Calling 的版本：

import os
import json
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

# ── 1. 定义工具的 Schema（告诉模型有哪些工具可以调用）──────────────
TOOLS_SCHEMA = [
    {
        "type": "function",
        "function": {
            "name": "search",
            "description": (
                "一个网页搜索引擎。当你需要回答关于时事、最新资讯、"
                "产品参数等在你知识库中找不到的信息时，应使用此工具。"
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "搜索关键词，例如：'华为最新手机 2026'"
                    }
                },
                "required": ["query"]
            }
        }
    }
]

# ── 2. 工具执行函数（保持不变，与正则方案复用）─────────────────────
def execute_tool(tool_name: str, tool_args: dict) -> str:
    """根据工具名和参数执行对应工具，返回 Observation 字符串。"""
    if tool_name == "search":
        # 复用之前的 search 实现，这里用占位模拟
        query = tool_args.get("query", "")
        print(f"🔍 正在搜索: {query}")
        # 实际项目中替换为真实搜索调用
        return f"搜索结果：关于'{query}'的最新信息已返回（示例）"
    return f"错误：未知工具 '{tool_name}'"

# ── 3. Function Calling 版本的 ReAct 主循环 ─────────────────────────
class ReActAgentWithFunctionCalling:
    """
    使用 Function Calling 替代正则解析的 ReAct 智能体。
    核心优势：工具调用格式由 API 层保证，永远不会因模型输出格式变化而崩溃。
    """

    def __init__(self, model: str = None, max_steps: int = 5):
        self.model = model or os.getenv("LLM_MODEL_ID")
        self.client = OpenAI(
            api_key=os.getenv("LLM_API_KEY"),
            base_url=os.getenv("LLM_BASE_URL"),
        )
        self.max_steps = max_steps

    def run(self, question: str) -> str:
        print(f"\n{'='*50}")
        print(f"问题: {question}")
        print(f"{'='*50}\n")

        messages = [
            {
                "role": "system",
                "content": (
                    "你是一个智能助手，可以使用工具来回答用户问题。"
                    "当需要查询实时信息时，请调用 search 工具。"
                    "获得足够信息后，直接给出最终答案，不要再调用工具。"
                )
            },
            {"role": "user", "content": question}
        ]

        for step in range(self.max_steps):
            print(f"--- 步骤 {step + 1} ---")

            response = self.client.chat.completions.create(
                model=self.model,
                messages=messages,
                tools=TOOLS_SCHEMA,
                tool_choice="auto",  # 让模型自主决定是否调用工具
            )

            message = response.choices[0].message

            # ── 情况 A：模型决定调用工具 ──────────────────────────────
            if message.tool_calls:
                # 将模型的 tool_call 消息加入历史
                messages.append(message)

                for tool_call in message.tool_calls:
                    func_name = tool_call.function.name
                    func_args = json.loads(tool_call.function.arguments)

                    print(f"🔧 工具调用: {func_name}({func_args})")

                    # 执行工具，获取 Observation
                    observation = execute_tool(func_name, func_args)
                    print(f"📋 观察结果: {observation}\n")

                    # 将工具结果加入历史，供模型下一轮参考
                    messages.append({
                        "role": "tool",
                        "tool_call_id": tool_call.id,
                        "content": observation
                    })

            # ── 情况 B：模型决定直接回答（不需要工具）──────────────────
            else:
                final_answer = message.content
                print(f"✅ 最终答案: {final_answer}")
                return final_answer

        return "已达最大步骤数，未能完成任务。"


# ── 4. 运行示例 ──────────────────────────────────────────────────────
if __name__ == "__main__":
    agent = ReActAgentWithFunctionCalling()
    agent.run("华为最新旗舰手机是哪款？有什么核心配置？")

两种方案对比

方案	优点	缺点
正则表达式	实现简单，依赖少，所有模型均可用	对格式变动极度敏感，维护差，生产不可靠
Function Calling	结构永远稳定，天然参数校验，支持并发多工具调用	依赖支持该能力的模型接口（GPT/Gemini/Claude 均支持）
JSON Mode	比正则稳健很多，实现较简单	仍可能出现不合法 JSON，需要额外校验

结论：教学代码里可以用正则帮助理解机制，但生产环境的系统应优先使用结构化协议，而不是依赖脆弱文本约定。

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

提示:这是一道动手实践题，建议实际编写代码

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

计算器工具实现

核心原则是：不要使用 eval()，而应使用 AST 白名单解析。

实现思路：

• 输入表达式后先统一中英文符号，例如 × 转 *，÷ 转 /。
• 使用 ast.parse(..., mode="eval") 解析表达式树。
• 只允许数字、加减乘除、幂、取模、一元负号等安全节点。
• 对非法语法、除零、非白名单节点返回错误。

这样做的本质是对 LLM 的权限做约束，从执行任意代码收缩成只执行数学语法子集。

import ast
import operator

# ── 白名单：允许的 AST 节点类型 ────────────────────────────────────────
SAFE_NODES = (
    ast.Expression,
    ast.BinOp,       # 二元运算：a + b, a * b
    ast.UnaryOp,     # 一元运算：-a
    ast.Constant,    # 数字常量
    # 允许的运算符
    ast.Add, ast.Sub, ast.Mult, ast.Div,
    ast.FloorDiv, ast.Mod, ast.Pow,
    ast.USub, ast.UAdd,  # 一元正负号
)

def calculate(expression: str) -> str:
    """
    安全的数学表达式计算器。
    使用 AST 白名单解析，禁止任意代码执行。

    Args:
        expression: 数学表达式字符串，如 "(123 + 456) * 789 / 12"

    Returns:
        计算结果字符串，或错误说明
    """
    # ── Step 1: 统一符号，支持中文乘除号 ──────────────────────────────
    expression = (
        expression
        .replace("×", "*")
        .replace("÷", "/")
        .replace("，", ",")
        .replace("（", "(")
        .replace("）", ")")
        .strip()
    )

    print(f"🧮 正在计算: {expression}")

    try:
        # ── Step 2: 解析为 AST ─────────────────────────────────────────
        tree = ast.parse(expression, mode="eval")

        # ── Step 3: 白名单校验，拒绝任何非法节点 ────────────────────────
        for node in ast.walk(tree):
            if not isinstance(node, SAFE_NODES):
                return f"错误：不允许的操作 '{type(node).__name__}'，计算器只支持基础四则运算。"

        # ── Step 4: 安全求值 ──────────────────────────────────────────
        result = eval(compile(tree, "<string>", "eval"))  # noqa: S307
        # 整数结果去掉小数点
        if isinstance(result, float) and result.is_integer():
            return str(int(result))
        return str(round(result, 10))  # 避免浮点精度问题

    except ZeroDivisionError:
        return "错误：除数不能为零。"
    except SyntaxError as e:
        return f"错误：表达式语法不合法 - {e}"
    except Exception as e:
        return f"错误：计算失败 - {e}"


# ── 注册到 ToolExecutor ────────────────────────────────────────────────
if __name__ == "__main__":
    from tool_executor import ToolExecutor  # 假设 ToolExecutor 已定义

    toolExecutor = ToolExecutor()

    # 注册搜索工具
    toolExecutor.registerTool(
        "Search",
        "一个网页搜索引擎。当你需要回答关于时事、事实以及在你的知识库中找不到的信息时，应使用此工具。",
        search  # 假设 search 函数已定义
    )

    # 注册计算器工具
    toolExecutor.registerTool(
        "Calculator",
        "一个安全的数学计算器。当你需要进行精确的数学运算时使用，支持加减乘除、幂运算、取模。输入标准数学表达式字符串。",
        calculate
    )

    print("--- 可用工具 ---")
    print(toolExecutor.getAvailableTools())

    # 测试计算器
    print("\n--- 计算器测试 ---")
    test_cases = [
        "(123 + 456) × 789 / 12",
        "2 ** 10",
        "100 / 0",
        "__import__('os').system('ls')",  # 应被拒绝
    ]
    for expr in test_cases:
        print(f"输入: {expr}")
        print(f"结果: {calculate(expr)}\n")

工具选择失败的处理机制

建议设计三层机制：

1. 第一次失败：返回温和纠错，告诉模型当前工具不存在或参数不对。
2. 第二次失败：注入更详细的参数说明、示例和上次错误原因。
3. 第三次失败：触发熔断，停止工具调用，回退为文本回答或转人工。

关键不是"无限重试"，而是把失败显式反馈回下一轮上下文，让模型有机会自我修正。

class ToolExecutorWithFallback:
    """
    带有失败处理机制的工具执行器。
    对每次工具调用失败进行分级响应：纠错 → 强提示 → 熔断。
    """

    def __init__(self):
        self.tools = {}
        self.failure_counts = {}   # 记录每个工具的连续失败次数
        self.MAX_FAILURES = 3      # 熔断阈值

    def registerTool(self, name: str, description: str, func):
        self.tools[name] = {"description": description, "func": func}
        self.failure_counts[name] = 0

    def execute(self, tool_name: str, tool_input: str) -> str:
        """
        执行工具，内置三级失败处理。

        Returns:
            工具执行结果或结构化错误提示（供下一轮 Observation 使用）
        """
        # ── 熔断检查 ────────────────────────────────────────────────────
        fail_count = self.failure_counts.get(tool_name, 0)
        if fail_count >= self.MAX_FAILURES:
            return (
                f"[CIRCUIT_BREAKER] 工具 '{tool_name}' 已连续失败 {fail_count} 次，"
                f"已触发熔断。请直接根据已有信息给出最终答案，不要再调用工具。"
            )

        # ── 工具不存在 ────────────────────────────────────────────────
        if tool_name not in self.tools:
            available = list(self.tools.keys())
            self.failure_counts[tool_name] = fail_count + 1

            if fail_count == 0:
                # 第一次：温和提示
                return (
                    f"错误：工具 '{tool_name}' 不存在。"
                    f"可用工具列表：{available}。请重新选择正确的工具名称。"
                )
            else:
                # 多次失败：强提示 + 示例
                return (
                    f"错误：工具 '{tool_name}' 仍不存在（第 {fail_count + 1} 次失败）。"
                    f"可用工具：{available}。\n"
                    f"调用示例：\nAction: {available[0]}\nAction Input: 你的输入"
                )

        # ── 执行工具 ─────────────────────────────────────────────────
        try:
            result = self.tools[tool_name]["func"](tool_input)
            self.failure_counts[tool_name] = 0  # 成功后重置计数
            return result

        except TypeError as e:
            # 参数类型错误
            self.failure_counts[tool_name] = fail_count + 1
            desc = self.tools[tool_name]["description"]
            return (
                f"错误：工具 '{tool_name}' 参数不正确 - {e}。\n"
                f"工具说明：{desc}\n"
                f"请检查 Action Input 的格式后重试。"
            )

        except Exception as e:
            self.failure_counts[tool_name] = fail_count + 1
            return f"错误：工具 '{tool_name}' 执行异常 - {e}。"

    def getAvailableTools(self) -> str:
        return "\n".join([
            f"- {name}: {info['description']}"
            for name, info in self.tools.items()
        ])

    def resetFailureCount(self, tool_name: str = None):
        """重置失败计数，供新一轮对话使用。"""
        if tool_name:
            self.failure_counts[tool_name] = 0
        else:
            self.failure_counts = {k: 0 for k in self.failure_counts}


# ── 测试 ──────────────────────────────────────────────────────────────
if __name__ == "__main__":
    executor = ToolExecutorWithFallback()
    executor.registerTool("Search", "网页搜索", lambda q: f"搜索结果：{q}")
    executor.registerTool("Calculator", "数学计算", calculate)

    print("=== 测试工具不存在 ===")
    print(executor.execute("Compute", "1+1"))   # 第1次失败
    print(executor.execute("Compute", "1+1"))   # 第2次失败
    print(executor.execute("Compute", "1+1"))   # 第3次，触发熔断
    print(executor.execute("Compute", "1+1"))   # 已熔断

    print("\n=== 重置后正常调用 ===")
    executor.resetFailureCount()
    print(executor.execute("Calculator", "(123 + 456) * 789 / 12"))

当工具扩展到 50-100 个时如何优化

当前把所有工具描述都塞进 Prompt 的方法不可持续，主要问题是：

• token 成本太高。
• 相似工具容易混淆，导致模型选择准确率会下降。

工程上的优化路径：

1. 按能力域做工具分类。
2. 对工具描述做 embedding，先检索最相关的 5-10 个工具再给模型。
3. 采用两阶段路由：先选类别，再选具体工具。
4. 对超大工具集训练专用路由器模型。

结论：工具规模一大，问题就从 提示词设计 升级为 工具的检索和路由系统设计。

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

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

动态重规划机制怎么设计

静态计划在真实环境里一定会遇到失败，因此需要分级重规划：

• 轻微失败：参数错误、短暂超时，只重试当前步骤。
• 中度失败：当前路径不可行，但目标没变，从失败点向后重规划。
• 严重失败：目标本身不可达，停止执行并向用户解释或请求新约束。

关键设计原则：

• 保留已完成步骤的有效结果。
• 全局步数或 token 预算不重置，防止无限重规划。
• 失败信息必须结构化记录，供下一轮规划使用。

商务旅行任务：Plan-and-Solve 还是 ReAct

对于"北京到上海商务旅行（机票、酒店、租车）"，更适合 Plan-and-Solve + 动态重规划。

原因：

• 子任务之间有强约束，例如航班时间影响酒店入住，酒店位置影响租车取车点。
• 用户通常希望先看完整可行方案，再确认执行。
• 预算、时间和地点约束必须在全局上统一处理。

纯 ReAct 的问题是容易局部最优，例如先订到最便宜的航班，结果破坏了后续酒店和会议安排。

分层规划系统的优势

推荐使用高层计划 + 子计划的分层规划结构。

优势包括：

• 降低单次规划复杂度。
• 错误隔离更强，只需局部重规划。
• 更适合并行执行不同子模块。
• token 使用更高效。

本质上，分层规划把一个超长任务拆成战略层和战术层，更符合人类和系统的共同认知方式。

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

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

不同阶段使用两个模型会带来什么影响

推荐模式是：

• 快模型负责执行和改写。
• 强模型负责审查和反思。

优点：

• 总成本更低。
• 平均延迟更低。
• 审查质量更高。

风险：

• 反思模型给出过强、过抽象的建议，执行模型接不住。
• 两个模型风格不一致，导致输出震荡或导致预期之外的输出。

工程上要约束反思模型输出具体、可执行的修改建议，而不是只给抽象批评。

更智能的终止条件

仅靠"无需改进"字符串或固定最大轮数不够健壮和友好。更好的方案有三类：

• 质量分数阈值：达到 8/10 以上就停止。
• 版本改动幅度阈值：连续两轮变化极小则视为收敛，比如小于10%。
• 进行多维度评分：正确性、完整性、可读性、效率都达标后停止。

结论：Reflection 的终止条件应从硬编码文本判断升级为 显式质量控制。

学术论文写作助手的多维 Reflection 机制

可从四个维度反思：

• 段落逻辑：论证是否连续、章节是否自然衔接。
• 方法创新性：方法是否只是已有工作的简单改写。
• 语言表达：术语是否统一、句式是否学术化。
• 引用规范：论点是否有来源支撑、引用格式是否一致。

可以让不同反思器分别给分，然后只针对最低分维度做下一轮优化。

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

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

ReAct Prompt 与 Plan-and-Solve Prompt 的结构差异

• ReAct Prompt 更强调循环协议，告诉模型如何在 Thought -> Action -> Observation 中逐步推进。
• Plan-and-Solve Prompt 更强调先给出完整计划，再严格执行，不鼓励执行中随意跳步。

这些差异并不是写法风格不同，而是在服务各自的范式逻辑。

角色设定为什么会影响 Reflection 行为

如果把角色设定从"极其严格的代码评审专家"改成"重视可读性的开源维护者"，模型的反馈重点通常会从：

• bug、边界条件、异常处理

转向：

• 命名、注释、接口清晰度、维护成本

说明角色设定实际上是在调整"评价函数"的隐式权重。

Few-shot 示例的作用

在固定输出格式和高一致性要求场景下，few-shot 往往很有价值。

例如给 ReAct 加入一个样例：

Question: 北京天气怎么样？
Thought: 我需要调用天气工具查询。
Action: weather
Action Input: {"city": "北京"}

这样可以显著降低模型格式漂移，提高工具调用解析成功率。

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

a. 理解用户的退款申请理由

b. 查询用户的订单信息和物流状态

c. 根据公司政策智能地判断是否应该批准退款

d. 生成一封得体的回复邮件并发送至用户邮箱

e. 如果判断决策存在一定争议（自我置信度低于阈值），能够进行自我反思并给出更审慎的建议

此时作为该产品的负责人:

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

选择哪种范式

我会选择 Plan-and-Solve + ReAct + Reflection 的组合：

• Plan-and-Solve 负责高层流程，例如理解退款诉求、查询订单、核验物流、根据政策判断、生成回复。
• ReAct 负责执行阶段调用订单、物流、邮件等工具。
• Reflection 负责在低置信度或高争议案件上做二次审查。

至少三个工具设计

可用工具包括：

• order_lookup：查询订单状态、商品信息、支付金额。
• logistics_query：查询物流轨迹和签收状态。
• policy_checker：根据退款政策给出规则判断。
• send_email：生成并发送回复邮件。

提示词如何兼顾公司利益和用户体验

提示词中需要同时写明：

• 必须遵守公司退款政策，不得越权承诺。
• 对证据不足的情况要明确说明原因，而不是编造。
• 回复语气需专业、克制、友好，避免对抗性表达。
• 若置信度低于阈值，优先转人工而不是冒险决策。

上线后的主要风险与技术缓解手段

主要风险包括：

• 误判退款导致资金损失。
• 工具调用错误导致查错单、发错信。
• 高争议案件中措辞不当引发投诉升级。
• 在复杂长尾场景中出现幻觉和流程死循环。

缓解方式：

• 对不可逆动作使用规则网关和人工审批。
• 为工具调用做参数校验和失败熔断。
• 对高风险案件启用 Reflection 和人工兜底。
• 对全链路做日志和审计，方便回放和复盘。