【智能体】Agent的四种设计模式之：Plan-and-Execute

Agent 四种工作模式之Plan-and-Execute

1、引言
[2、 Plan-and-Execute 到底怎么工作？](#2、 Plan-and-Execute 到底怎么工作？)
[3、P&E 的 Token 到底省在哪](#3、P&E 的 Token 到底省在哪)
4、三个核心挑战
- [4.1 计划僵硬 ------ 你永远不知道哪一步会翻车](#4.1 计划僵硬 —— 你永远不知道哪一步会翻车)
- [4.2 规划质量依赖 ------ Planner 错了，后面全错](#4.2 规划质量依赖 —— Planner 错了，后面全错)
- [4.3 执行器能力悖论 ------ 工具太多反而难管](#4.3 执行器能力悖论 —— 工具太多反而难管)
5、代码示例
6、总结

1、引言

小屌丝：鱼哥，ReAct 太烧钱了，跑一个长任务烧掉我几十万 Token，有没有省钱的办法？

小鱼：有。ReAct 是边想边做，每一步都调一次大模型。你试试 Plan-and-Execute，先把完整计划定下来，然后执行阶段按部就班地走，主打一个"思考一次性到位，执行不用愁"。

小屌丝：省 Token 我知道，但具体怎么省？执行到一半出问题怎么办？是不是还得有个啥机制兜底啊？

小鱼：问得好。Plan-and-Execute 远不止"省 Token"这一件事。从 OIC 的双 Agent 设计到 SAP 的安全研究，再到微软的 CodeAct 和 Google 的结构化输出规范，2025~2026 年这个模式已经进化了好几轮。今天我给你从架构到代码，从优势到局限，一口气讲透

2、 Plan-and-Execute 到底怎么工作？

Plan-and-Execute（简称 P&E），顾名思义：先规划，后执行。它的核心思想来源于关于规划和解决提示（Plan-and-Solve Prompting）的论文，而 BabyAGI 项目则是将这一思想落地为可运行架构的早期实践。

这个模式把 Agent 的工作拆成两个完全独立的阶段：
是
否
⚙️ 阶段二：执行（Execute）
✅ Step 1

调用工具，获取结果
✅ Step 2

调用工具，获取结果
✅ Step 3

调用工具，获取结果
📋 阶段一：规划（Plan）
🧠 Planner Agent

深度推理，分析任务全貌
📝 生成结构化步骤列表
📌 Step 1: 明确子目标
📌 Step 2: 匹配工具与参数
📌 Step 3: 设定验证条件
👤 用户输入任务
❓ 是否出现异常

或计划失效？
🔄 触发 Replanner

仅对剩余步骤重新规划
✅ 交付最终成果

解析：

阶段一（规划）：Planner Agent 一次性分析任务全貌，输出结构化的"步骤清单"。它在这个阶段只推理，不调用任何外部工具。
阶段二（执行）：Executor Agent 逐条执行清单上的步骤。Oracle OIC 官方明确指出，Executor 本身就是一个 ReAct Agent，但它被严格限定在"只能执行计划中的步骤"的框架内，不允许自由发挥。
异常兜底：如果执行到某一步时发现环境变了，触发 Replanner 对剩余步骤重新规划，而不是推倒重来。

一句话总结：
Plan-and-Execute = 深度思考 + 批量执行 + 条件重规划

3、P&E 的 Token 到底省在哪

看一张对比表，两种模式的工作方式一目了然：

维度	ReAct	Plan-and-Execute
工作方式	思考→行动→观察→再思考，循环往复	先规划完整计划，再批量执行
模型使用	每一步都用大模型推理	规划用大模型，执行用轻量模型（甚至不用）
决策时机	每步根据上一个工具返回结果实时决策	只在规划时决策一次，执行阶段不做新决策
Token 消耗	每步都重新推理，持续燃烧 Token	规划阶段消耗 Token，执行阶段几乎不烧
灵活性和可审计性	极高：随时根据反馈调整	中等：有清晰计划链路可追踪，启动前即可检视

ReAct 的 Token 花在"每一步都要重新推理"上。一个 5 步的任务，ReAct 要调 5 次大模型，每次都要把整个对话历史塞进上下文。而 Plan-and-Execute 规划阶段调一次大模型，剩下的执行阶段不需要任何推理------因为这 5 步早就在规划阶段定下来了，执行时只是按计划调工具而已。

根据行业实测数据，在复杂多步骤任务中，Plan-and-Execute 的 Token 消耗大约是 ReAct 的五分之一，工具调用次数减少约 42%，平均执行时间缩短约 35%。

一句话总结两者的本质区别 ：ReAct 是"先把我知道的做了，看看能发现什么"；Plan-and-Execute 是"先想清楚要做什么，再动手"。

4、三个核心挑战

4.1 计划僵硬 ------ 你永远不知道哪一步会翻车

Plan-and-Execute 最大的痛点，就是计划无法实时响应环境变化。如果在执行过程中发现某个子任务的环境或数据发生了意外变化，原有的计划就会变得不适用。

解法一：Replanner。在执行过程中加入"重新规划检查点"，每隔若干步触发一次 LLM 判断："当前计划还靠谱吗？"如果不靠谱，只对剩余步骤重新规划，不推倒重来。
解法二：模型分层。 Planner 用高能力大模型确保规划的全局战略性足够好；Executor 用精细指令驱动低级模型，以减少执行过程中的偏差。

4.2 规划质量依赖 ------ Planner 错了，后面全错

Plan-and-Execute 将"正确的规划"作为唯一前提。如果规划 Agent 本身的能力不足，输出的计划从一开始就是错的，那么执行得再完美也是白费功夫。一篇来自 AAAI 2026 的论文指出，ReAct 容易陷入"局部优化陷阱"，而 Plan-and-Execute 则面临"全局规划偏见"------Plan 质量直接决定了整个任务的成败。

解法一：用强模型做规划。 Planner 必须用能力最强的大模型（如 GPT-4o、Claude Opus 4.6），不要在规划阶段省成本。
解法二：规划验证。在规划输出后、执行开始前，增加一个"计划审核"环节------可以由另一个 Agent 评审计划质量，也可以由人类快速扫一眼。一分钱的规划审核，省下十分钱的执行返工。

4.3 执行器能力悖论 ------ 工具太多反而难管

当 Executor 被要求调用太多工具时，即使有计划引导，也可能在执行过程中迷失方向。火山引擎的开发实践指出，如果执行器需要频繁切换工具且缺乏中间结果的共享机制，串行任务的延迟也会累积到不可接受的程度。

解法一：工具分层。按任务类型对工具进行分类和裁剪，每个执行阶段只开放必需的 2~3 个工具，避免 Executor 在众多工具中不知所措。
解法二：并行执行。当 Planner 生成 DAG 型计划时，Executor 可以并行处理无依赖关系的子任务，显著缩短整体执行时间

5、代码示例

下面是一个直接能跑通的 Plan-and-Execute 代码示例，覆盖了"规划 → 执行 → 检查点 → 重新规划"的完整流程

python 复制代码

# -*- coding:utf-8 -*-
# @Time   : 2026-05-02
# @Author : Carl_DJ

from openai import OpenAI
import json

client = OpenAI()

# ========== 步骤 1：规划 ==========
def generate_plan(user_input: str) -> list:
    """让 LLM 一次性生成完整执行计划（Planner 角色）"""
    response = client.chat.completions.create(
        model="gpt-4o",  # 规划阶段必须用强模型
        messages=[
            {"role": "system", "content": """你是一个任务规划师。将用户需求拆解为有序步骤列表。
每步以'Step N: 动作 | 所需工具 | 参数'的格式输出。"""},
            {"role": "user", "content": user_input}
        ],
        temperature=0
    )
    plan_text = response.choices[0].message.content
    steps = [line.strip() for line in plan_text.split("\n") if line.strip().startswith("Step")]
    return steps

# ========== 步骤 2：工具集 ==========
TOOLS = {
    "get_weather": lambda city: json.dumps(
        {"city": city, "temperature": "22°C", "condition": "晴"}, ensure_ascii=False
    ),
    "search_flights": lambda origin, dest, date: json.dumps(
        {"flights": [{"no": "CA1234", "time": "08:00", "price": 1280}]}, ensure_ascii=False
    ),
    "book_flight": lambda flight_no, passenger: json.dumps(
        {"status": "已预订", "flight": flight_no, "passenger": passenger}, ensure_ascii=False
    ),
    "search_hotel": lambda city, date: json.dumps(
        {"hotels": [{"name": "商务酒店", "price": 380}]}, ensure_ascii=False
    ),
}

# ========== 步骤 3：带检查点的执行 ==========
def execute_steps(steps: list, checkpoint_interval: int = 2) -> list:
    """逐条执行步骤，每隔 N 步触发一次检查点"""
    results = []
    i = 0
    while i < len(steps):
        step = steps[i]
        print(f"\n⚙️  执行: {step}")

        # 简化的工具路由（生产环境建议用更完善的解析和路由机制）
        try:
            if "天气" in step:
                result = TOOLS["get_weather"]("北京")
            elif "航班" in step:
                result = TOOLS["search_flights"]("北京", "上海", "2026-05-03")
            elif "订票" in step:
                result = TOOLS["book_flight"]("CA1234", "张三")
            elif "酒店" in step:
                result = TOOLS["search_hotel"]("上海", "2026-05-03")
            else:
                result = f"[模拟] 执行完成: {step}"
        except Exception as e:
            result = f"❌ 执行失败: {str(e)}"

        results.append({"step": step, "result": result})
        print(f"   结果: {result}")

        i += 1

        # 检查点：每 N 步评估一次计划是否仍然有效
        if i % checkpoint_interval == 0 and i < len(steps):
            print("\n🔍 [检查点] 评估剩余计划...")
            remaining = steps[i:]
            check_prompt = f"已完成步骤及结果：{json.dumps(results, ensure_ascii=False)}\n剩余步骤：{remaining}\n\n当前计划是否仍然有效？如果有效请回复'继续'，否则请说明需要调整的内容。"
            check_resp = client.chat.completions.create(
                model="gpt-4o-mini",  # 检查点可以用轻量模型降低成本
                messages=[{"role": "user", "content": check_prompt}],
                temperature=0
            )
            check_result = check_resp.choices[0].message.content
            if "继续" not in check_result:
                print(f"⚠️  计划需要调整：{check_result}")
                # 触发 Replanner：仅重规划剩余步骤
                new_steps = generate_plan(
                    f"已完成任务：{json.dumps(results, ensure_ascii=False)}\n剩余任务需要重新规划。原始目标：完成剩余步骤 {remaining}"
                )
                steps = steps[:i] + new_steps
                print(f"🔄 重规划完成，新计划共 {len(steps)} 步")

    return results

# ========== 主流程 ==========
user_input = "帮我安排一趟5月3号从北京到上海的出差：查天气、查航班、订机票、订酒店"
plan = generate_plan(user_input)
print("📋 规划结果：")
for p in plan:
    print(f"  {p}")

results = execute_steps(plan)
print("\n========== 任务完成 ==========")
for r in results:
    print(f"  {r['step']} → {r['result']}")

代码解析：

Planner 用 GPT-4o：规划质量是整套系统的瓶颈，不能在规划阶段省模型成本。
Executor 不调 LLM：执行阶段只调工具函数，不消耗 Token 做推理------这正是 Plan-and-Execute 省 Token 的关键。
Replanner 用 GPT-4o-mini：检查点判断"计划是否继续有效"的逻辑相对简单，用小模型可进一步降低成本。
异常兜底：工具调用加了 try-except，单步失败不会让整个流水线崩溃。

6、总结

Plan-and-Execute 不是 ReAct 的对立面，而是它的"效率层优化"。

ReAct 解决的是"灵活"问题------走一步看一步，路径不确定时最管用。
Plan-and-Execute 解决的是"效率"问题------当路径可以提前确定，就不再每步烧 Token。

记住一个判断法门 ：在写下任务描述时，如果能在 Agent 启动前就列出需要调用的精确工具列表，就应该使用 Plan-and-Execute。

我是小鱼：

CSDN 博客专家；
AIGC 技术MVP专家；
阿里云专家博主；
51CTO博客专家；
企业认证金牌面试官；
多个名企认证&特邀讲师等；
名企签约职场面试培训、职场规划师；
多个国内主流技术社区的认证专家博主；
多款主流产品(阿里云等)评测一等奖获得者；

关注小鱼，学习【人工智能与大模型】最新最全的领域知识。