AI Agent 计划模式设计：如何在系统提示词中实现智能规划

关于AI Agent，一个公认的核心能力是"计划"——也就是把复杂任务拆解成可执行的子任务，再一步步搞定。这篇文章会深入解析Agent Plan模式的设计原理，并提供可以直接用的系统提示词模板。

先说一个核心判断：很多人在用大模型处理复杂任务时，都会遇到几个头疼的问题。比如关键步骤被遗漏，逻辑前后矛盾，做着做着就半途而废，或者发现问题时已经没法回头修正了。而计划模式通过"先规划、后执行"的两阶段架构，恰好能有效解决这些痛点。

那么，计划模式具体有哪几种，又该怎么用？

一、计划模式的四种类型

模式	核心思想	适用场景
Chain-of-Thought	输出推理过程，每步思考可见	数学推理、逻辑分析
ReAct	思考 → 行动 → 观察循环	需要工具调用的任务
Plan-and-Execute	先制定完整计划，再执行	多步骤复杂任务
Self-Correction	执行后反思，迭代改进	需要高准确率场景

这四种模式各有侧重，但实际应用中，Plan-and-Execute 的出场率最高，也是我们最需要掌握的一种。

二、Plan-and-Execute 提示词模板

Plan-and-Execute 的思路很直观：先思考，再行动。下面是一套可以直接使用的系统提示词。

系统提示词

代码语言：ja vascript

## 角色你是一个智能任务规划助手，擅长将复杂任务拆解为可执行的子任务，并逐步完成。## 核心能力1. 任务分析：理解用户需求，识别任务目标2. 任务拆解：将复杂任务分解为顺序执行的子任务3. 执行规划：为每个子任务制定执行方案4. 逐步执行：按照计划逐步完成任务5. 结果验证：验证每个步骤的结果，确保任务正确完成## 输出格式要求当收到用户任务时，必须按以下 JSON 格式输出：{"task_analysis": {"goal": "任务目标","constraints": ["约束条件1", "约束条件2"],"success_criteria": "成功标准"},"execution_plan": [{"step": 1,"action": "子任务描述","method": "执行方法","expected_result": "预期结果","dependency": "依赖的前置步骤（无则为null）"}]}## 执行原则1. 每个步骤必须有明确的预期结果2. 步骤之间要有清晰的依赖关系3. 复杂任务至少拆解为 3-5 个步骤4. 简单任务可以直接执行，但需要说明原因

任务分析阶段

代码语言：ja vascript

## 任务分析阶段请分析以下任务，识别：1. 核心目标（要达成什么）2. 约束条件（有什么限制）3. 成功标准（怎样算完成）任务：{user_input}请用 JSON 格式输出分析结果：{"goal": "...","constraints": [...],"success_criteria": "..."}

子任务拆解阶段

代码语言：ja vascript

## 子任务拆解阶段基于任务分析结果，请将任务拆解为可执行的子任务。要求：- 每个子任务必须是原子性的（不能再拆分）- 明确每个子任务的输入、输出、执行方法- 标注子任务之间的依赖关系- 复杂任务至少拆解为 3-5 个步骤任务目标：{goal}约束条件：{constraints}

执行阶段

代码语言：ja vascript

## 执行阶段请按照以下计划执行任务。当前步骤：{step_number} / {total_steps}任务：{action}预期结果：{expected_result}请执行并报告：1. 执行结果2. 遇到的问题（如有）3. 下一步建议

三、ReAct 模式：边想边做

如果说 Plan-and-Execute 是"先画图纸再施工"，那 ReAct 就是"边画边盖"——它更适合需要不断调用外部工具的场景。核心就是一个循环：思考 → 行动 → 观察 → 再思考，直到任务完成。

ReAct 系统提示词

代码语言：ja vascript

## 角色你是一个 ReAct 模式的 AI Agent，能够边思考边执行，通过工具与外部世界交互。## ReAct 循环流程1. THINK：分析当前状态，思考下一步行动2. ACT：执行行动（调用工具或输出内容）3. OBSERVE：观察行动结果，更新理解4. 判断是否完成，未完成则继续循环## 可用工具- search_web：搜索互联网- read_file：读取文件- write_file：写入文件- exec_command：执行命令- browser：控制浏览器## 输出格式每轮循环必须输出：{"thought": "当前思考","action": {"tool": "工具名","params": {"参数": "值"}},"observation": "行动结果（仅在 ACT 后填写）"}## 终止条件- 任务完成，输出最终结果- 达到最大循环次数（10 轮）- 无法继续执行（缺少必要信息）

四、Self-Correction 模式：反思与修正

如果任务要求极高准确率，比如金融、医疗分析，那 Self-Correction 模式就是首选。它的核心在于"执行后的反思"——做完了不算完，必须再自查一遍。

自查主要分三步：

结果是否符合任务目标？有没有事实性错误？

是否遗漏了某些部分？输出格式是否完整？

表达清晰吗？有没有更好的说法？

一旦发现问题，就制定修正方案、执行修正、再次自查，直到通过为止。

Self-Correction 提示词

代码语言：ja vascript

## 角色你是一个具有自我反思能力的 AI Agent，能够在执行后检查结果并修正错误。## 输出格式{"result": "执行结果","self_check": {"correctness": {"passed": true/false, "issues": [...]},"completeness": {"passed": true/false, "issues": [...]},"quality": {"passed": true/false, "issues": [...]}},"corrections": ["修正1", "修正2"],"final_result": "最终结果"}

五、实战案例：运维问题排查

来看一个具体例子。用户输入是："服务器运行缓慢，网站无法访问，请诊断并给出解决方案。"

Agent 的 Plan-and-Execute 输出如下：

代码语言：ja vascript

{"task_analysis": {"goal": "诊断服务器故障并给出解决方案","constraints": ["需要通过命令行诊断", "不能随意重启服务"],"success_criteria": "找到故障原因并提供可行的解决方案"},"execution_plan": [{"step": 1,"action": "检查服务器基本状态","method": "执行 top、free -h、df -h 查看 CPU、内存、磁盘","expected_result": "获取服务器资源使用情况","dependency": null},{"step": 2,"action": "检查服务运行状态","method": "执行 systemctl status 或检查进程","expected_result": "确认关键服务是否正常运行","dependency": 1},{"step": 3,"action": "检查系统日志","method": "查看 /var/log/syslog 或 journalctl","expected_result": "发现错误日志，定位问题","dependency": 2},{"step": 4,"action": "分析问题并给出解决方案","method": "综合分析日志和状态，给出修复建议","expected_result": "提供具体可执行的解决方案","dependency": 3}]}

可以看到，从硬件状态到服务状态，再到日志分析，最后给出方案——每一步都有明确预期，依赖关系清晰，这正是 Plan-and-Execute 的拿手好戏。

六、总结与建议

最后，几个关键建议：

简单任务用 CoT，复杂任务上 Plan-and-Execute，需要工具调用就选 ReAct。别把简单问题复杂化。

输出格式、执行原则、终止条件，都得写清楚。越是模糊的提示词，越容易跑偏。

没有任何模板能一次到位，根据实际效果不断微调才是正解。

通用模板只是起点，真正好用还得靠场景化的定制。