在构建能够自主调用工具、处理多步业务的智能体时，开发者常常发现模型容易跳步、漏掉前置条件或在长链路任务中偏离主题。Plan-and-Solve提示词工程提供了一种结构化思路：不急于让模型直接给出最终答案，而是先在提示中要求其输出任务计划，再基于计划逐步执行。这种先规划后执行的方式，使智能体的行为变得可预期、可干预，也更容易在出错时定位到具体环节。
Plan-and-Solve的核心原理与价值
Plan-and-Solve的本质是把单一端到端生成，拆分成计划生成与计划执行两个显式阶段。传统提示往往只说“请完成任务”，模型内部虽然也会做一定推理，但过程不可见，一旦某步出错便难以挽回。通过提示词强制模型先列出步骤，我们相当于在黑盒推理外增加了一层白盒约束：每一步要做什么、依赖什么输入、产出什么结果，都先以自然语言固化下来。
从认知角度看，这种做法符合人类解决复杂问题的分治策略。当任务被分解为可管理的子目标，模型在每一步所需处理的上下文更短、更聚焦，幻觉与遗漏的概率随之下降。同时，计划阶段产出的内容可作为日志，方便开发者审查智能体是否理解了需求，而不是等到最终输出错误才回溯。
在工程落地中，Plan-and-Solve还能带来协作优势。比如当计划中包含“调用天气接口获取城市A数据”这一步时，人工可在执行前删除或替换该步，避免无效调用。这种人机协同在敏感业务场景里尤为重要，它把智能体的自主权限制在已确认的计划框架内，降低失控风险。
提示词结构设计与计划模板
一个可用的Plan-and-Solve提示词通常由角色设定、任务描述、计划指令、执行指令四部分构成。角色设定告诉模型它是具备规划能力的助手；任务描述给出背景与目标；计划指令明确要求输出编号步骤，并说明每步目的；执行指令则规定模型随后按计划依次推进，且可在某步失败时回看计划调整。
下面给出一个通用的提示词模板示例，其中计划阶段要求模型用中文列出三到五步，并标出可能需要的工具。执行阶段则强调严格依序进行，不允许跳过。这种结构既保留灵活性，又防止模型自作主张合并关键步骤。
你是一个擅长拆解任务的智能体。 任务：为用户规划一次三日杭州差旅，包含交通、会议、餐饮。 请先输出计划： 1. 明确用户出发地与预算 2. 查询往返高铁班次 3. 按会议时间排布每日行程 4. 推荐预算内餐厅 计划输出后，请依序号逐步执行并给出详细结果。
实际使用中，我们还可以要求模型在计划里标注每步的“成功标准”，例如“步骤2成功标准为：获得两个候选班次及票价”。这样在执行阶段，智能体能够自我校验是否达标，未达标则重试或声明阻塞，而不是默默给出不完整答案。
代码实现与执行循环示例
在代码侧，Plan-and-Solve可通过两次模型调用实现：第一次专用于生成计划，第二次携带计划与任务进入逐步执行。以下Python伪代码展示了一个最简闭环，先请求计划文本，再将其拼回后续提示中驱动执行。
import openai
def plan_and_solve(task_prompt):
# 第一阶段：生成计划
plan_resp = openai.ChatCompletion.create(
model='gpt-4',
messages=[{'role':'user','content': task_prompt + 'n请先只输出计划步骤。'}]
)
plan = plan_resp.choices[0].message.content
# 第二阶段：按计划执行
exec_resp = openai.ChatCompletion.create(
model='gpt-4',
messages=[
{'role':'user','content': task_prompt},
{'role':'assistant','content': plan},
{'role':'user','content': '请严格按上述计划逐步执行并输出最终结果。'}
]
)
return plan, exec_resp.choices[0].message.content
task = '分析销售CSV并给出季度环比增长最高的产品'
plan, result = plan_and_solve(task)
print('计划:n', plan)
print('结果:n', result)
上述写法把计划与执行解耦，便于在中间插入人工审核。若希望更自动化的代理，可将执行阶段改为循环：每完成一步，把该步结果追加进消息历史，再提示模型“继续下一步”，直到计划中的步骤全部消费完毕。这种增量方式更省上下文，也方便在单步报错时仅重跑该步。
要注意的是，模型可能在执行中擅自修改计划。为抑制该行为，提示词应写明“除非某步明显不可行，否则不得增删步骤；如不可行，请说明原因并停止”。另外，对于涉及写文件或发请求的操作，建议在计划阶段就要求列出确切参数，执行阶段直接套用，减少自由发挥空间。
常见误区与应对方案
不少团队在尝试Plan-and-Solve时，会把计划写得过于笼统，例如“先分析数据，再生成报告”。这类计划没有分解出可验证动作，执行阶段依旧容易跑偏。正确做法是让模型在计划里点明具体动作与对象，如“用pandas读取upload.csv的A列，计算月度均值”，越具体，后续偏差越小。
另一个常见问题是计划与执行使用不同模型或温度参数，导致执行端“看不懂”计划风格。应保持两次调用系统设定一致，或在大模型提示中复述计划原文，避免语义漂移。若任务极长，还可把计划存为外部状态，每步执行前由程序注入对应片段，而非依赖模型记忆全部内容。
最后，不要误以为Plan-and-Solve能替代任务本身的领域知识。它只是组织流程的框架，若模型缺乏底层能力，再好的计划也救不回错误结论。因此在关键业务里，仍要结合校验规则与人工抽检，把计划作为可控性增强手段，而非质量万能保证。
Plan-and-Solveprompt_engineeringagent修改时间：2026-08-15 13:48:17