Agent 04-智能体经典范式构建

引言

在前三章的学习中，我们已经掌握了关于大语言模型的基础知识。本章将进入实践环节，通过"亲手造轮子"的方式，从零开始编码实现三种业界经典的智能体构建范式：

ReAct — 推理与行动结合
Plan-and-Solve — 规划与执行分离
Reflection — 自我反思与迭代优化

我们将深入探索它们的核心工作原理，并通过具体的实战案例，分析各自的优势、局限与适用场景。

核心知识点概览

1. ReAct：思考-行动的动态循环

ReAct 范式构建了一个能与外部世界交互的智能体。其核心机制是 “思考(Thought) → 行动(Action) → 观察(Observation)” 的动态循环。

ReAct 循环

核心优势：

环境适应性强，能够利用外部工具
具备动态纠错能力
适合处理探索性、需要实时信息的任务

典型应用场景：

需要搜索引擎辅助的问答
实时数据查询
API 调用与交互式任务

2. Plan-and-Solve：先规划，后执行

Plan-and-Solve 范式将复杂问题分解为清晰的步骤，然后逐一执行。

执行流程：

1

输入问题 → 规划阶段（生成步骤列表） → 执行阶段（逐步完成）

核心优势：

结构性强，逻辑清晰
稳定性高，推理路径确定
适合逻辑路径固定、内部推理密集的任务

典型应用场景：

多步数学推理
复杂问题分解
流程化任务处理

3. Reflection：执行-反思-优化

Reflection 范式引入了自我优化能力，通过 “执行 → 反思 → 优化” 的迭代循环提升解决方案质量。

迭代流程：

1

初始方案 → 执行与评估 → 反思反馈 → 优化改进 → (循环) → 最终方案

核心价值：

显著提升输出质量
自动发现并修正错误
适用于对准确性和可靠性要求极高的场景

典型应用场景：

代码生成与优化
学术写作辅助
决策支持系统

三种范式的对比分析

本章探讨的三种范式，代表了智能体解决问题的三种不同策略，如下表所示：

范式	思考模式	核心优势	适用场景
ReAct	思考-行动一体，动态循环	环境适应、动态纠错	探索性任务、工具调用
Plan-and-Solve	先规划，后执行	结构稳定、逻辑清晰	多步推理、流程化任务
Reflection	执行-反思-优化迭代	质量提升、自我修正	高精度要求、复杂输出

💡 选择建议：在实际应用中，选择哪种范式取决于任务的核心需求。某些复杂场景下，也可以将多种范式组合使用。

架构组合示例

当面临复杂任务时，可以考虑 混合范式架构：

Plan-and-Solve 进行高层次任务规划
ReAct 在执行过程中处理具体的操作和环境交互
Reflection 对整个过程进行自我优化和改进

适用场景： 智能客服系统、自动驾驶、复杂工作流自动化等。

小结与展望

至此，我们已经掌握了构建单个智能体的核心技术体系：

✅ 理解了 ReAct 的动态交互机制
✅ 掌握了 Plan-and-Solve 的结构化规划方法
✅ 学会了 Reflection 的自我优化技巧

下一站预告： 为了更好地将理论付诸实践，下一章我们将探索不同低代码平台的使用方式，以及轻代码构建 Agent的实战方案。

思考与练习

⚠️ 提示：部分习题没有标准答案，重点在于培养对智能体范式设计的综合理解和实践能力。

练习一：范式理解与选择

问题 1.1：ReAct、Plan-and-Solve 和 Reflection 这三种范式在"思考"与"行动"的组织方式上有什么本质区别？

点击查看参考答案

范式	组织方式
ReAct	思考-行动一体，动态循环；思考指导行动，行动结果反哺思考
Plan-and-Solve	先规划，后执行；分阶段处理，一次规划多步执行
Reflection	执行-反思-优化；通过迭代循环持续提升质量

问题 1.2：如果要设计一个"智能家居控制助手"（需要控制灯光、空调、窗帘等多个设备，并根据用户习惯自动调节），你会选择哪种范式作为基础架构？为什么？

点击查看参考答案

推荐选择：ReAct

理由：

智能家居控制需要实时响应用户指令和环境变化
ReAct 的动态循环能够更好地适应这种需求
其环境适应性和动态纠错能力非常适合处理各种突发情况

问题 1.3：是否可以将这三种范式进行组合使用？请设计一个混合范式的智能体架构。

点击查看参考答案

混合架构设计：

1
2
3
4
5
6
7
8
9


输入任务
    ↓
[Plan-and-Solve] 高层次任务规划
    ↓
[ReAct] 动态执行与环境交互（每一步骤）
    ↓
[Reflection] 全过程自我优化与改进
    ↓
输出结果

适用场景： 智能客服系统、自动驾驶、复杂项目管理等需要同时具备规划能力、实时交互和持续优化的场景。

练习二：输出解析的鲁棒性

问题 2.1：在 ReAct 实现中，我们使用正则表达式解析大语言模型的输出。当前的解析方法存在哪些潜在脆弱性？

点击查看参考答案

潜在问题：

格式依赖性强：如果模型输出格式变化（如标签被替换或省略），解析会失败
额外文本干扰：输出中包含额外文本时可能导致匹配错误
边界情况处理：特殊字符、多行输出等边界情况容易引发问题

问题 2.2：除了正则表达式，还有哪些更鲁棒的输出解析方案？

点击查看参考答案

改进方案：

结构化输出：使用 JSON、XML 等格式规范模型输出
自然语言理解：使用 NLU 技术识别意图和实体
专用解析器：针对特定格式设计专用解析逻辑
模型约束：使用支持结构化输出的模型（如 Function Calling）

练习三：工具调用与扩展

问题 3.1：为 ReAct 智能体添加一个"计算器"工具，使其能够处理复杂的数学计算问题。

点击查看代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


def calculator(expression: str) -> float:
    """安全地计算数学表达式"""
    import ast
    import operator as op

    operators = {
        ast.Add: op.add, ast.Sub: op.sub,
        ast.Mult: op.mul, ast.Div: op.truediv,
    }

    def eval_node(node):
        if isinstance(node, ast.Num):
            return node.n
        elif isinstance(node, ast.BinOp):
            left = eval_node(node.left)
            right = eval_node(node.right)
            return operators[type(node.op)](left, right)
        raise ValueError(f"不支持的节点类型: {type(node)}")

    try:
        return eval_node(ast.parse(expression, mode='eval').body)
    except Exception as e:
        return f"计算错误: {e}"

# 注册工具
tools.register("calculator", calculator, "计算数学表达式，如 '(123 + 456) * 789 / 12'")

问题 3.2：当可调用工具数量增加到 50-100 个时，如何优化工具的组织和检索机制？

点击查看参考答案

优化策略：

问题	解决方案
上下文占用大	分层组织，按需加载工具描述
相似工具干扰	工具聚类 + 语义检索
选择错误率高	约束执行 + 置信度过滤

工程实现：

分层索引：建立工具分类目录（类目 → 子类 → 工具）
语义检索：用向量相似度找到候选工具子集
工具路由：训练轻量级路由模型，直接映射到目标工具
缓存优化：缓存常用工具的调用结果

练习四：动态规划机制

问题 4.1：Plan-and-Solve 的计划是"静态"的，如何设计一个"动态重规划"机制？

点击查看参考答案

动态重规划机制设计：

  graph TD
    A[执行步骤] --> B{结果校验}
    B -->|成功| C[继续下一步]
    B -->|失败| D{重试次数 < 阈值?}
    D -->|是| E[局部重规划]
    D -->|否| F[全局重规划]
    E --> A
    F --> A

关键组件：

结果校验模块：判断是否满足成功标准
局部重规划：更换工具/调整参数/插入补充步骤
全局重规划：重新生成后续步骤
安全退出：设置重试和重规划次数上限

问题 4.2：对比 Plan-and-Solve 与 ReAct，在处理"预订商务旅行"任务时哪种更合适？

点击查看参考答案

场景分析：

| 范式 | 优势 | 劣势 | |:—|:—| | Plan-and-Solve | 适合处理有关联的多步骤预订 | 难以应对实时变化（如售罄、价格跳变） | | ReAct | 能根据实时结果灵活调整 | 可能缺乏整体规划 |

最佳方案： 组合使用

用 Plan-and-Solve 做高层次规划（确定预订顺序和约束）
用 ReAct 处理每个子步骤的执行与纠错（如换日期、换机场）

问题 4.3：设计一个"分层规划"系统及其优势。

点击查看参考答案

分层规划架构：

1
2
3
4
5
6


高层抽象计划 (3-8 个里程碑)
    ├── 阶段 1
    │   └── 细化子计划 (具体工具、参数、检查点)
    ├── 阶段 2
    │   └── 细化子计划
    └── ...

核心优势：

优势	说明
可扩展	高层计划稳定，细节按需生成
更稳健	局部失败只需重规划子计划
工具选择	明确的意图收窄候选工具范围
可观测性	高层里程碑便于审计和监控
可复用	高层模板可跨任务复用

练习五：Reflection 机制深入

问题 5.1：使用两个不同的模型（一个更强大做反思，一个更快做执行）会带来什么影响？

点击查看参考答案

双模型架构分析：

收益	代价
用"高推理能力"提升正确性	增加系统复杂度
用"高吞吐低成本"承担重复劳动	需要模型对齐与调试
成本效益更优	增加调用链路延迟

结论： 对于工程化长期运行的系统（如自动代码代理），双模型架构通常比单模型更稳定、更经济。

问题 5.2：如何设计更智能的 Reflection 终止条件？

点击查看参考答案

改进的终止条件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


def should_terminate(iteration, history):
    # 1. 质量评分阈值
    if latest_score >= 0.95:
        return True, "质量达标"

    # 2. 改进幅度检测
    if abs(latest_score - previous_score) < 0.01:
        return True, "改进饱和"

    # 3. 外部评估通过
    if all_tests_passed():
        return True, "测试通过"

    # 4. 迭代次数上限
    if iteration >= max_iterations:
        return True, "达到最大迭代次数"

    return False, "继续优化"

多维度判断： 质量评分、改进幅度、外部测试、计算预算

问题 5.3：设计一个"学术论文写作助手"的多维度 Reflection 机制。

点击查看参考答案

多维度评估体系：

  graph TD
    A[论文初稿] --> B[段落逻辑性评估]
    A --> C[方法创新性评估]
    A --> D[语言表达评估]
    A --> E[引用规范评估]
    B --> F[综合反馈报告]
    C --> F
    D --> F
    E --> F
    F --> G[针对性优化]
    G --> H{终止条件满足?}
    H -->|否| A
    H -->|是| I[最终论文]

评估维度：

段落逻辑性：连贯性与结构合理性
方法创新性：科学贡献与技术亮点
语言表达：语法、用词、流畅度
引用规范：格式正确性与引用完整性

练习六：提示词工程

问题 6.1：ReAct 和 Plan-and-Solve 的提示词结构设计有何不同？

点击查看参考答案

范式	提示词设计重点
ReAct	强调"Thought-Action-Observation"循环，明确三者角色定义
Plan-and-Solve	强调分阶段处理，明确规划阶段和执行阶段的边界

核心差异：提示词结构设计直接服务于各自范式的执行逻辑。

问题 6.2：角色设定对智能体行为的影响。

点击查看参考答案

角色设定对比：

角色	输出倾向
“严格的代码评审专家”	关注正确性、性能、安全性
“注重可读性的开源维护者”	关注清晰度、注释、结构
“注重效率的工程经理”	关注开发速度、可维护性

结论： 角色设定是引导模型行为的重要手段，应根据目标场景精心设计。

问题 6.3：Few-shot 示例的效果分析。

点击查看参考答案

方案	优点	缺点	适用场景
无 Few-shot	灵活、节省 token	格式不稳定	创意性任务
有 Few-shot	稳定性高、格式遵循好	token 消耗大	结构化输出任务

建议： 对于需要结构化输出的智能体（如 Reflection、Planner），Few-shot 是必要而非可选的优化。

练习七：综合实战

场景： 某电商公司希望搭建"客服智能体"，需要以下功能：

理解用户的退款申请理由
查询用户的订单信息和物流状态
根据公司政策智能判断是否批准退款
生成得体的回复邮件并发送
争议情况下进行自我反思

问题 7.1：选择何种范式作为核心架构？

点击查看参考答案

推荐架构：ReAct + Reflection

组件	职责
ReAct	动态调用工具查询订单、物流，做出初步判断
Reflection	对争议决策进行反思，提供更审慎的建议

问题 7.2：系统需要哪些核心工具？

点击查看参考答案

工具	功能描述
订单查询工具	根据用户信息查询订单详情和物流状态
政策判断工具	根据退款政策评估申请是否符合条件
邮件生成工具	生成得体回复并发送至用户邮箱
情感分析工具	分析用户情绪，调整回复语气

问题 7.3：如何设计提示词以平衡公司利益与用户体验？

点击查看参考答案

提示词设计策略：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 角色设定
你是一位专业且友好的客服代表，代表公司处理退款申请。

# 决策原则
1. 严格遵守公司退款政策
2. 在保护公司利益的前提下，尽可能满足用户需求
3. 对用户表达理解和关心

# 回复要求
- 语气友好、专业
- 清晰说明决策理由
- 提供替代方案（如适用）

问题 7.4：产品上线可能面临哪些风险？如何降低？

点击查看参考答案

风险类型	风险描述	缓解措施
错误决策	误批/误拒退款申请	多模型评估 + 人工审核兜底
隐私泄露	用户数据暴露	数据加密 + 访问控制 + 审计
体验下降	回复不当导致用户不满	持续优化提示词 + 反馈机制
系统稳定性	服务中断影响用户	冗余架构 + 监控告警 + 定期维护

结语

本章通过三种经典范式的实践，建立了构建智能体完整技术栈的认知。下一章，我们将走进低代码平台的世界，探索更高效的 Agent 构建方式。

敬请期待！