第四章《智能体经典范式构建》习题答案｜逐章学习笔记

[jarvanstack]

本帖是我对《从零开始构建智能体》的逐章学习答案。基于教材仓库 main 分支提交 92e6891（2026-08-09 读取）。开放题为个人理解，欢迎指正。

原章链接：第四章 智能体经典范式构建

1. 三种范式与混合架构

• ReAct：思考与行动交替，环境的新观察会改变下一步。适合信息不完整、需要探索和工具反馈的任务。
• Plan-and-Solve：先形成相对完整计划，再按步骤执行。适合依赖关系清晰、希望降低遗漏的任务。
• Reflection：先产出结果，再用评价信号发现问题并迭代。适合可评审、质量要求高但一次生成难达标的任务。

智能家居以 ReAct 为基础更合适，因为设备状态和人在场情况动态变化，动作后必须观察反馈；但日常节能可用 Plan-and-Solve 生成计划，高风险或异常行为可用 Reflection 审查。

一个混合架构可以是：规划器分解目标 → ReAct 执行每个步骤并收集实时状态 → 验证器检查约束 → 失败或低质量时 Reflection 找原因 → 触发局部重规划。它适用于旅行预订、运维处置、复杂客服等既有总体结构又会遭遇动态反馈的任务。关键是为每层设预算和终止条件，避免“规划—反思”无限嵌套。

2. 更鲁棒的输出解析

正则方案可能因标签大小写、空格/换行、模型添加解释、Action 中含嵌套 JSON、一次输出多个动作、代码块、标签缺失或用户内容恰好包含 Action: 而失败。解析失败还可能被误判成工具名错误。

更可靠的方案包括模型原生 function calling、受 JSON Schema 约束的结构化输出、语法约束解码、Pydantic 校验以及状态机式协议。示例结构：

{
  "kind": "tool_call",
  "thought_summary": "需要查询实时天气",
  "tool": "weather",
  "arguments": {"city": "杭州"}
}

from pydantic import BaseModel, ValidationError
from typing import Literal, Any

class AgentStep(BaseModel):
    kind: Literal["tool_call", "final"]
    tool: str | None = None
    arguments: dict[str, Any] = {}
    answer: str | None = None

def parse_step(raw: str) -> AgentStep:
    try:
        return AgentStep.model_validate_json(raw)
    except ValidationError as error:
        raise ValueError({"type": "schema_error", "detail": error.errors()})

JSON Schema 更易校验、日志化和跨语言处理；正则实现简单、调试直观、对旧模型兼容。结构化方案仍需处理截断、语义无效参数和模型把 JSON 包进代码块的问题；若供应商支持原生工具调用，应优先使用其受约束接口。

3. 工具扩展、失败恢复与大规模工具集

计算器不应直接 eval 任意字符串。可解析白名单运算符：

import ast, operator

OPS = {
    ast.Add: operator.add, ast.Sub: operator.sub,
    ast.Mult: operator.mul, ast.Div: operator.truediv,
    ast.USub: operator.neg,
}

def calculate(expression: str) -> float:
    def run(node):
        if isinstance(node, ast.Expression): return run(node.body)
        if isinstance(node, ast.Constant) and isinstance(node.value, (int, float)): return node.value
        if isinstance(node, ast.BinOp) and type(node.op) in OPS:
            return OPS[type(node.op)](run(node.left), run(node.right))
        if isinstance(node, ast.UnaryOp) and type(node.op) in OPS: return OPS[type(node.op)](run(node.operand))
        raise ValueError("unsupported expression")
    return run(ast.parse(expression, mode="eval"))

题中表达式结果为 (123 + 456) × 789 / 12 = 38069.25。

工具失败机制应返回机器可读错误：不存在的工具、schema 校验失败、权限拒绝、超时和业务失败必须区分。第一次失败把合法参数和简短修正提示反馈给模型；同类失败连续两次时禁止原样重试并要求重新选择；达到阈值后转人工或安全终止。调用有副作用的工具前要审批，并使用幂等键。

当工具达到 50～100 个时，把全部描述放进提示会造成上下文膨胀和选择混淆。可建立分层目录：先路由到领域，再用关键词/embedding/权限过滤检索 top-k 工具，只把候选 schema 暴露给模型；对工具做版本、标签、成功率和成本管理；常见组合封装为高级工具；离线评估路由召回率和参数正确率。工具发现与工具执行应分离。

4. 动态重规划与分层规划

动态重规划需要显式状态：计划步骤、依赖、执行结果、剩余预算和失败原因。每步后由验证器判断 success / retry / replan / abort。可恢复错误先重试；前置假设失效时仅重规划受影响的子树；目标或安全约束变化则全局重规划。旧计划要保留版本，防止模型反复回到已失败路径。

商务旅行包含机票、酒店、租车的时间和地点依赖，先用 Plan-and-Solve 建立整体约束更合适；但价格和库存实时变化，纯静态计划不够。因此最佳方案是 Plan-and-Solve 管依赖，ReAct 执行查询和预订，并在库存失败时局部重规划。

分层规划先生成“确认需求—交通—住宿—地面交通—复核”高层步骤，再为每步生成可执行子计划。优势是降低单次规划复杂度、易并行、能局部重试、便于人审和预算分配；风险是高层错误向下传播、层间约束丢失，因此需要共享约束表和跨层验证器。

5. Reflection 设计

强模型做反思、快模型做执行可以提高成本效益：快模型生成候选，强模型负责批判和难题修正。但两个模型可能对格式、事实或评价标准理解不一致；强评审也可能过度改写正确答案。应使用统一 rubric、结构化反馈和抽样校准，并比较“质量增益/额外成本”。

仅检查固定短语或最大轮数过于脆弱。更智能的终止条件可以综合：自动测试全部通过；rubric 分数超过阈值；相邻两轮提升低于最小增益；关键缺陷数为零；成本/时间预算耗尽；多评审一致；出现振荡或重复版本。终止应由外部控制器根据结构化指标决定，而不是让生成模型口头宣布完成。

论文助手可使用多评审维度：

评审器	检查内容	可验证信号
逻辑	论点—证据—结论是否连贯，段落是否互相矛盾	论证图、矛盾清单
方法	问题是否重要，方法与基线是否匹配，创新声明是否过度	与相关工作对照表
实证	数据、指标、统计和消融是否支持结论	表格重算、实验清单
语言	清晰、简洁、术语一致	风格规则和可读性指标
引用	引用是否存在、是否支持对应表述、格式是否一致	DOI/元数据校验、原文证据

流程应先冻结作者事实与实验结果，只修改被允许的文本；每轮生成差异、理由和证据，作者确认后合并。反思模型不能伪造实验或引用。

6. 提示词如何服务范式

ReAct 提示强调可用工具、Thought/Action/Observation 协议、一次一步以及何时给最终答案，因为它需要把环境反馈重新送入循环。Plan-and-Solve 提示强调先输出完整、编号、依赖明确的计划，再按计划执行，目的是减少遗漏和目标漂移。两者结构差异来自控制流差异，而非文案偏好。

角色设定会改变评价函数。“严格代码评审专家”更倾向发现正确性、安全和边界问题，反馈更苛刻；“重视可读性的开源维护者”更关注命名、接口、文档、社区可维护性，也可能降低对性能微优化的优先级。角色不能替代明确 rubric，否则输出会随角色刻板印象漂移。

给 ReAct 增加 few-shot 时，应展示一条正确工具调用和一条工具失败后的纠正：

Question: 计算 12 * 8
Action: calculator
Action Input: {"expression":"12*8"}
Observation: {"value":96}
Final: 96

Question: 查询火星天气
Action: weather
Action Input: {"city":"火星"}
Observation: {"error":"unsupported_location"}
Final: 当前工具不支持该地点，无法可靠查询。

比较时应测试未见问题的格式成功率、工具选择准确率和错误恢复率，避免只观察单个示例。

7. 电商客服智能体

核心架构采用 Plan-and-Solve + ReAct + 条件 Reflection：计划保证“理解—查证—政策判断—复核—回复”的完整性；ReAct 获取订单和物流的实时反馈；低置信度或规则冲突时才触发 Reflection。最终退款动作仍由规则/审批服务控制。

至少需要：

• get_order(order_id, user_id)：查询订单、支付、商品类型和售后状态；
• get_logistics(order_id)：查询签收、异常和轨迹；
• retrieve_refund_policy(product_type, region, purchase_time)：返回带版本的适用条款；
• assess_evidence(files)：读取用户图片/材料并标注置信度；
• submit_refund_decision(...)：受权限、金额阈值和幂等键保护的业务动作；
• send_email(draft_id)：只能发送已审核模板。

提示词要明确优先级：遵守法律和公司政策；只基于工具证据；政策冲突或缺失时不得猜测；把用户陈述与已验证事实分开；解释决定和申诉路径；措辞尊重但不承诺越权补偿。输出使用结构化字段：事实、适用条款、风险、建议决定、置信度、给用户的草稿。

上线风险包括幻觉政策、越权退款、提示注入、隐私泄露、偏见、重复执行、成本延迟和高峰不可用。控制措施包括 RAG 引用、规则引擎、最小权限、审批阈值、输入隔离、PII 脱敏、幂等操作、全量审计、离线回放、红队测试、灰度发布、漂移监控和随时人工接管。