Agent的几个技术问题--系列1

杨昆
6 阅读11分钟

1、react和Plan-and-Execute是什么，分别在什么场景下使用？

ReAct（Reason + Act）与 Plan-and-Execute（规划 - 执行）是大语言模型（LLM）驱动智能体（Agent）的两大核心范式，核心差异在于推理与执行的时序关系——ReAct 走 “边想边做” 的即时迭代路线，Plan-and-Execute 走 “先定方案再执行” 的结构化流水线路线。以下结合典型场景与技术栈展开说明。

一、ReAct：边想边做的即时迭代范式

1. 核心逻辑

遵循 思考→行动→观察→再思考 的闭环循环，LLM 每一步决策都依赖实时外部反馈，适合动态不确定环境。例如回答 “北京今日天气并对比上海温差” 时，先思考 “需查两地天气”，行动调用天气 API，观察结果后再思考 “是否计算温差、如何组织答案”。

2. 典型场景与示例

典型场景具体示例适用原因
实时数据问答“查询今日美元兑人民币汇率，计算 1 万元可兑换金额”依赖实时外部数据，需即时调用 API 获取最新结果
多跳信息检索“对比 2025 年中美欧新能源车销量与政策差异，给出投资建议”需多轮搜索、筛选、整合信息，动态调整检索方向
运维故障排查“分析服务器 500 错误原因，定位日志并给出修复方案”故障场景动态多变，需根据中间结果（如日志关键词）调整排查步骤
代码辅助开发“写一个 Java 递归转非递归工具类，并用 JUnit 测试”需分步编写代码、执行测试、调试报错，动态调整实现逻辑
日程与邮件自动化“给项目组 5 人发会议邀请，附日程并抄送领导邮箱”需分步查询联系人、组装邮件内容、调用发送 API，中途可验证参数

3. 核心技术栈

技术层级核心工具 / 框架作用
LLM 基础层OpenAI API、DeepSeek、Claude、Ollama（本地部署）提供推理能力，生成 “思考 - 行动” 决策
工具调用层LangChain、LangGraph、AutoGen、DSPy封装工具（API、数据库、代码执行器），实现 Agent 与外部系统交互
搜索与数据层SerpAPI、DuckDuckGo、Wikipedia API、Weather API获取实时 / 权威外部信息，抑制幻觉
开发与部署层Python/TypeScript、FastAPI、Docker、Kubernetes实现 Agent 服务化、容器化部署，支持高可用
监控与调试层LangSmith、Prometheus、Grafana追踪 Agent 推理轨迹，监控工具调用成功率与响应时间

4. 适用优势与局限

  • ✅ 优势：即时响应，适合动态环境；轻量灵活，无需复杂任务分解；自然适配人类交互，推理过程可解释。
  • ❌ 局限：长任务易失控，多步骤复杂任务易遗漏或逻辑混乱；成本较高，多轮工具调用增加 API 开销。

二、Plan-and-Execute：先定方案再执行的结构化范式

1. 核心逻辑

拆分为 规划（Planning）  和 执行（Execution）  两个独立阶段：先由 Planner 生成结构化、可审计的步骤计划，再由 Executor 按计划逐项执行，支持动态重规划。例如 “规划北京三日游” 时，Planner 先生成 “查景点→查交通→订酒店→安排行程” 的计划，Executor 再分步执行。

2. 典型场景与示例

典型场景具体示例适用原因
复杂多步骤任务“生成公司年度财务分析报告，包含数据提取、环比计算、图表生成、结论撰写”需明确任务分解与依赖关系，确保每一步可追溯、可审计
企业审批流程“审核合同付款申请，校验合同金额、执行进度、发票合规性，输出审批意见”流程固定、合规要求高，结构化计划便于流程审计与风险控制
数据处理流水线“从 MySQL 加载销售数据→清洗异常值→按地区聚合→生成可视化报表”流程标准化，需保证步骤顺序与数据流转确定性
旅行 / 活动规划“规划广州 5 人家庭 3 日游，覆盖老人与儿童需求，预算 5000 元”需全局统筹多约束（人数、预算、人群），先定整体方案再填充细节
科研文献综述“收集近 3 年 AI 大模型论文→分类整理→分析研究热点→撰写综述”步骤明确、流程固定，结构化计划提升效率与完整性

3. 核心技术栈

技术层级核心工具 / 框架作用
规划层（Planner）LangChain Plan-and-Execute、LangGraph Planner、AutoGen Planner基于 LLM 生成结构化步骤计划，明确目标、依赖与工具
执行层（Executor）LangChain Executor、LangGraph StateGraph、Dify按计划调用工具、处理步骤依赖、累积上下文结果
工具与数据层MySQL/PostgreSQL、MinIO、Pandas、Matplotlib、Email API支撑数据读取、处理、可视化、外部系统交互
流程编排层Airflow、Dagster、Temporal企业级流水线调度，支持重试、失败恢复与定时执行
开发与部署层Python、Java、Spring Boot、Docker、Kubernetes实现高可靠、可扩展的服务化部署，适配生产环境
合规与审计层Pydantic（结构化输出）、ELK Stack、PostgreSQL确保计划与执行结果可追溯，满足企业合规要求

4. 适用优势与局限

  • ✅ 优势：稳定性高，结构化计划避免逻辑混乱；可审计性强，符合企业合规需求；支持并行执行，提升长任务效率。
  • ❌ 局限：灵活性不足，计划外的突发场景难适配；前期规划成本高，复杂任务需精细设计计划。

三、场景选型与混合实践

1. 快速选型指南

任务特征优先范式典型案例
实时性强、动态多变ReAct实时问答、故障排查、即时交互
步骤固定、合规要求高Plan-and-Execute企业审批、数据流水线、结构化报告
长周期、多约束复杂任务混合模式大型项目规划、跨领域研究、全流程业务自动化

2. 混合实践案例

实际生产中常结合两者优势，例如 智能客服：

  1. 用 Plan-and-Execute 制定服务流程（如 “查询用户信息→验证权限→处理问题→记录反馈”）；
  2. 遇到复杂问题（如 “查询历史订单并分析退款原因”）时，切换至 ReAct 模式，多轮调用搜索与数据库工具获取数据；
  3. 执行完成后，再用 Plan-and-Execute 汇总结果并生成标准化回复。

dify属于Plan-and-Execute吗？

结论： Dify Workflow 是 “固定流程”，Plan-and-Execute 是 “动态生成流程”。长得像，但本质完全不是一回事。

Dify 的 Workflow（工作流）之所以接近 Plan-and-Execute 范式，是因为两者都遵循“分步执行”的核心逻辑，均强调按既定步骤推进任务、完成目标，在执行形态上高度相似，但本质上存在核心差异，因此并非真正的 Plan-and-Execute 范式，核心区别集中在“规划能力”的归属与灵活性上。

Dify Workflow 的核心是“静态执行”，所有执行步骤、分支逻辑、工具调用顺序，都需要人工提前通过可视化拖拽配置完成，相当于人预先画好“执行地图”，Workflow 仅负责按地图一步步推进，无法自主调整。运行过程中，它不会根据任务变化、执行结果动态新增步骤、删除步骤或调整顺序，即使遇到预设之外的情况，也无法自主决策，只能按既定流程执行或报错，本质是“执行人工预设的流程”，没有自主规划的能力。

而 Plan-and-Execute 范式的核心是“动态规划+执行”，它包含独立的规划模块（Planner）和执行模块（Executor）。面对任务时，Planner 会自主分析任务目标，动态生成完整的执行计划，明确每一步的目的、顺序和依赖关系；Executor 按计划执行后，若发现结果不符合预期或存在新问题，Planner 还能自主重规划，调整步骤、补充工具调用，全程无需人工干预。

简单来说，两者的关键差异的是“流程由谁制定、能否动态调整”：Dify Workflow 是“人定流程、机器执行，不可调整”，仅具备执行能力；Plan-and-Execute 是“机器定流程、机器执行，可动态调整”，核心在于自主规划能力。 因此，Dify Workflow 只是接近 Plan-and-Execute 的执行形态，缺乏其核心的自主规划能力，并非真正的 Plan-and-Execute 范式。

四、总结

ReAct 以即时迭代适配动态场景，适合轻量、实时、交互密集型任务；Plan-and-Execute 以结构化流水线适配稳定场景，适合复杂、合规、长周期任务。技术栈选择需结合业务需求（实时性 / 合规性）、团队能力（开发效率）、部署环境（本地 / 云 / 混合）综合决策，多数企业会采用混合模式平衡灵活性与稳定性。

2、工具描述写得再好，模型也瞎传参数怎么办

一、问题本质

大模型做工具调用时，只靠自然语言描述约束不住参数，一定会出现：

  • 漏参、错参、类型乱填
  • 编造不存在的参数 / 工具
  • 格式不规范、语义乱写

解决思路只有一条：

模型负责 “意图理解”，你负责 “参数强约束”

二、第一层：给模型的强约束（前端治理，减少犯错）

在工具定义前加上刚性指令，并使用 JSON Schema 而不是纯文字描述：

【工具调用强制规则】
1. 只调用已定义工具，禁止编造工具名
2. 必须传全所有 required 参数，禁止缺参漏参
3. 禁止编造参数值，不确定必须反问用户
4. 禁止添加未定义字段
5. 严格遵守参数类型、格式、枚举范围

再配上结构化工具定义：

{
  "name": "get_weather",
  "description": "查询城市天气",
  "parameters": {
    "type": "object",
    "required": ["city"],
    "properties": {
      "city": {
        "type": "string",
        "description": "中文城市名"
      },
      "date": {
        "type": "string",
        "description": "日期格式 YYYY-MM-DD，可选"
      }
    }
  }
}

作用：

  • 大幅降低模型乱传概率
  • 但不能完全杜绝

三、第二层：轻量级路由层（后端兜底，彻底根治）

1. 作用放在模型输出和真实工具执行之间的一层极薄中间逻辑，只做三件事：

  • 工具路由：根据 tool_name 分发到对应处理逻辑
  • 参数校验：检查必填、类型、格式、枚举是否合法
  • 参数清洗：过滤多余字段、修正格式、统一值

本质就是：工具调用的守门员

2. 特点

  • 极轻量，无框架依赖
  • 完全可控、可预测、可调试
  • 不侵入业务工具代码
  • 是解决 “模型乱传参数” 的标准工程方案

3. 性能与成本

  • 规则：1ms
  • 小模型：几十～几百 ms
  • 高并发下完全不是一个量级。

4. 可调试、可审计
规则错了一眼定位。
模型错了，你根本不知道它为啥这么判。

三、参数校验：用 Pydantic 实现（最推荐）

路由层里的校验，不要手写一堆 if-else，直接用 Pydantic。
1. 为什么用 Pydantic

  • 声明式定义参数结构，比手写规则清晰太多
  • 自动校验：必填、类型、格式、长度、枚举
  • 自动过滤模型瞎传的多余字段
  • 抛出标准化错误，可直接返回给模型重传
  • 轻、快、稳，完全符合 “轻量级路由” 定位

2. 典型结构

  • 为每个工具定义一个 Pydantic 参数模型
  • 路由层根据 tool_name 选择对应模型做解析校验
  • 校验通过 → 调用真实工具
  • 校验失败 → 返回错误信息让模型修正

四、完整结构（最终标准架构）

用户请求
   ↓
大模型生成：tool_name + model_args
   ↓
【轻量级路由层】
   1. 校验 tool_name 是否在白名单
   2. 根据工具找到对应 Pydantic 模型
   3. 用 Pydantic 校验、清洗参数
   ↓
   合法 → 执行真实工具
   非法 → 返回参数错误 → 模型重新生成调用

这一套就是工业界通用、最轻量、最稳定的工具调用参数治理方案。

五、几个关键疑问统一澄清

  1. 轻量级路由层只能是规则式吗？

是的，主体必须是规则式。
路由分发、必填校验、格式校验、枚举校验这类强确定性逻辑，必须用硬规则保证稳定。
2. 能用小模型代替这套规则校验吗？
不能完全替代，只能辅助。

  • 小模型仍然会 幻觉、乱判、漏判
  • 参数校验要求100% 确定，模型做不到
  • 性能、可调试性、成本都不如规则

合理用法：

  • Pydantic + 路由做兜底强校验
  • 小模型只做：语义补全、模糊值转换、自然语言错误解释

六、极简总结

  • 轻量级路由层是工具调用的入口分发与参数治理层
  • Pydantic 是路由层里最优雅、最轻量的参数校验实现
  • 路由 + Pydantic 共同解决：模型乱传参数、漏参、瞎编参数
  • 主体必须是规则式，小模型只能辅助，不能替代

avatar
文章
阅读
粉丝