架构设计：Plan-Execute-Replan设计模式核心原理

[!WARNING] 可以在本文看完后，去旧文档看看以前的评论，也值得学习[架构设计：Plan-Execute-Replan设计模式核心原理](/oncall/智能 OnCall Agent 项目/旧文档备份/架构设计：Plan-Execute-Replan设计模式核心原理/)

一、为什么要用Plan-Execute-Replan？

大家好，今天来聊一个在运维Agent领域非常核心的设计模式——Plan-Execute-Replan。

如果你正在做运维Agent相关的项目，或者对AI Agent的架构设计感兴趣，这篇文章应该能帮你把这个模式彻底搞明白。

我会从"为什么需要它"讲起，一步步带你理解它的本质、工作流程，以及它和另一个常见模式ReAct的区别。

📷 [图片 token=SFaVbNVtQovtH7xXUjgcTxPonui（未能下载，见飞书原文）]

在聊这个模式之前，我们先想一个问题：工程师平时处理告警的时候，到底在干嘛？

假设凌晨3点，你手机响了——某台服务器CPU飙到100%了。作为一个值班同学，你大概会这么干：

1. 先登上去看看日志，有没有明显报错

2. 再看看监控面板，哪个进程吃的CPU最多

3. 查一下这个进程最近有没有做什么变更

4. 根据排查结果，决定是重启服务、回滚版本还是扩容

看起来挺有条理的对吧？但问题是，不是每个工程师都能做到这么有条理。

实际工作中，运维告警处理有几个很现实的痛点：

痛点一：流程全靠经验，新人一脸懵

老同事知道"先查日志再看监控"，但新人可能上来就手忙脚乱，不知道该先干嘛。排查步骤全在脑子里，没有结构化的流程，效率差距非常大。

痛点二：遇到"此路不通"就卡住了

比如你查了日志，发现啥异常都没有——然后就愣住了：“日志没问题啊，那是啥原因？“人工排查很容易在某个环节卡壳，不知道怎么调整方向。

痛点三：信息散落在各个系统，来回切换累死人

日志在ELK里，监控在Prometheus/Grafana里，工单在别的系统里，告警在企业微信群里……人工排查需要在这些系统之间反复横跳，光复制粘贴就够喝一壶的了。

所以，当我们想让AI Agent来替代人工处理这些告警的时候，就需要一种设计模式，能够：

• 像老同事一样有条理地规划排查步骤（解决流程混乱）

• 遇到"此路不通"时能灵活调整方向（解决卡壳问题）

• 统一调度各个系统的工具（解决信息孤岛）

这，就是 Plan-Execute-Replan 模式要干的事。

📷 [图片 token=Izajba1g8o6VOvxq3rncxEW4nkb（未能下载，见飞书原文）]

二、Plan-Execute-Replan到底是什么？

一句话定义

Plan-Execute-Replan 是一种Multi-Agent（多智能体）协作的任务执行模式，核心思路是：先规划、再执行、随时调整。

📷 [图片 token=RfsxbKNHCoiCQ0xWgE3cHDFxn9d（未能下载，见飞书原文）]

你可以把它理解成一个"三人小团队"在协作完成任务：

这里要解释下什么叫 Multi-Agent（多智能体）。简单说，就是不是一个AI在单打独斗，而是多个AI各司其职、分工协作。每个Agent负责一个专门的职责，就像公司里不同岗位的同事配合完成一个项目。

装修房子的类比

为了让你更直观地理解，咱们拿装修房子打个比方。

假设你买了一套新房要装修，完全没经验，你会怎么做？

第一步：Plan（规划）

你找了个设计师，让他出一套完整的方案：先拆旧墙→再布水电→然后泥瓦工贴砖→接着木工打柜子→最后刷漆。每一步干什么、用什么材料、大概要多久，都写得清清楚楚。

这就是 Planner 在做的事——把一个大目标拆成有序的步骤清单。

第二步：Execute（执行）

施工队拿到方案后开始干活。先拆旧墙，拆完了汇报：“墙拆好了，发现里面有根水管。”

这就是 Executor 在做的事——按计划执行当前步骤，然后把结果反馈回来。注意，Executor不需要操心全局，它只需要把眼前这一步做好就行。

第三步：Replan（重规划）

设计师一听"里面有根水管”，马上调整方案：“水电布线方案要改一下，那根水管得绕过去。后面的步骤也要跟着调整。”

这就是 Replanner 在做的事——根据执行结果评估当前进展，决定要不要调整计划。

三者不断循环配合，直到房子装修完毕。

三个核心组件详解

咱们再从技术角度，把这三个组件的职责说清楚。

1. Planner（规划器）—— “军师”

Planner 是整个模式的起点。它接收用户的目标（比如"排查CPU飙高的原因”），然后生成一份结构化的执行计划。

什么叫结构化？就是不是含糊地说"你去查查吧"，而是明确列出：

步骤1：调用日志工具，查询服务器近1小时的error/warn级别日志
步骤2：调用监控工具，获取CPU突增时段的进程占用排行
步骤3：调用历史工单，检索该进程过往的CPU异常处理方案

每一步做什么、用什么工具、传什么参数，都规划好。这就像项目经理给你排的Task列表，清晰明了。

Planner 的关键能力：理解复杂目标的内在逻辑，把大任务拆成可执行的小步骤，并且安排好合理的执行顺序。

2. Executor（执行器）—— “干活的人”

Executor 是真正动手的那个。它拿到计划中的当前第一步，然后去调用对应的工具完成任务。

比如计划说"调用日志工具查error日志"，Executor 就真的去调日志API，传入服务器IP、时间范围、日志级别这些参数，拿到返回结果。

这里有个重要的设计理念：Executor 只专注做好当前这一步，不操心全局。

为什么要这么设计？因为"规划"和"执行"本来就是两种不同的能力。你让一个人既要统筹全局又要埋头干活，反而两边都做不好。分开之后，Executor 可以心无旁骛地把当前步骤做到最好。

Executor 的关键能力：准确调用工具、处理工具返回的结果。

3. Replanner（重规划器）—— “监理 + 指挥官”

Replanner 是这个模式里最关键的角色——它让整个系统从"死板执行"变成了"智能适应"。

每次 Executor 完成一步之后，Replanner 都会介入，做三件事：

情况一：步骤完成，结果有效 → 继续推进

“日志查到异常了，接下来按计划执行第二步。” 这种情况最简单，照着计划往下走就行。

情况二：结果不符合预期 → 调整计划

“日志查了，啥异常都没有。那原计划的排查顺序可能不太对，得先看监控定位是哪个进程的问题。” 这时候 Replanner 会修改后续步骤的内容或顺序。

情况三：所有步骤完成 → 终止任务，输出结论

“根因已经定位了——是全量同步任务没做分页，导致CPU打满。任务结束，输出报告。”

Replanner 的关键能力：评估执行结果、判断任务进度、识别问题并动态优化计划。

三、工作流程：从目标到结果的完整闭环

光说概念可能还有点抽象，咱们用一个完整的运维实战案例，把整个流程走一遍。

📷 [图片 token=SQJCbfJwBoH7IYxHumacAB8snef（未能下载，见飞书原文）]

场景：凌晨CPU 100%告警

某电商平台凌晨2点，监控系统发出告警：服务器 10.0.1.5 的CPU使用率突然飙到100%。运维Agent接到告警后开始自动排查。

Round 1：Planner 出手，制定初始计划

Planner 拿到目标"排查CPU突增的根因"，结合运维知识，生成了以下计划：

步骤1：调用日志工具，查询服务器近1小时error/warn级别日志
步骤2：调用监控工具，获取CPU突增时段的进程占用排行
步骤3：调用历史工单，检索该进程过往CPU异常的处理方案

思路很清晰：先看日志有没有直接线索 → 再看监控定位具体进程 → 最后查历史方案。

Round 2：Executor 执行步骤1——查日志

Executor 按照计划，调用日志工具：

• 参数：服务器IP=10.0.1.5，时间范围=近1小时，日志级别=error/warn

返回结果：日志中未发现error/warn记录，只有大量info级别的定时任务执行成功日志。

嗯，没查到有用信息。如果是人工排查，这时候可能就愣住了——“日志没问题啊，那是啥情况？”

Round 3：Replanner 介入评估，调整计划

Replanner 分析执行结果后得出判断：日志无异常，说明问题大概率不是应用报错导致的，更可能是某个进程在"悄悄"吃CPU。那就应该优先看监控数据，定位到底是哪个进程在搞事情。

于是 Replanner 调整了计划的执行顺序：

步骤1（已完成）：查日志 → 无异常
步骤2（更新）：调用监控工具，获取02:00-02:10时段进程占用排行 ← 优先执行这个
步骤3（更新）：针对步骤2定位的异常进程，查其详细日志
步骤4：调用历史工单，检索处理方案

看到没？Replanner 不是简单地"跳到下一步"，而是根据已有的结果，重新优化了后续的计划。这就是"Replan"的精髓——动态调整，而不是死板地按原计划走。

Round 4：Executor 执行更新后的步骤2——查监控

Executor 调用监控工具（比如Prometheus），查询CPU突增时段的进程排行。

返回结果：02:00-02:10时段，进程「data-sync-service」CPU占用率达95%（正常情况下通常不到10%）。

好家伙，找到嫌疑人了。

Round 5：Replanner 再次评估

Replanner 看到结果：“已经定位到异常进程了，接下来需要查这个进程的详细日志，看看它到底在干什么。” 计划无需大改，继续执行步骤3。

Round 6：Executor 执行步骤3——查进程日志

Executor 调用日志工具，这次参数更精准了：

• 进程名=data-sync-service，时间范围=近1小时

返回结果：日志显示02:00触发了一次全量数据同步任务，遍历数据库1000万条记录，没有做分页处理。

真相大白了！

Round 7：Replanner 最终评估——任务结束

Replanner 判断：根因已经明确了——全量同步任务没做分页，导致一次性加载1000万条数据把CPU打满了。不需要再查历史工单了（因为问题已经定位清楚），直接输出结论。

最终输出：

故障根因：服务器进程 data-sync-service 在02:00执行全量数据同步时，未做分页处理，遍历1000万条记录导致CPU使用率突增至100%。

建议方案：优化同步逻辑，添加分页参数（如每次拉取1000条），并将同步任务调整到非高峰时段执行。

流程小结

把上面的过程抽象一下，Plan-Execute-Replan的工作流程就是这样一个循环闭环：

📷 [图片 token=D0jXbHKqEodAkExc8ZQco7yWnne（未能下载，见飞书原文）]

核心就八个字：规划→执行→评估→调整，不断循环，直到任务完成。

四、和ReAct模式的区别

聊到Agent的设计模式，很多人会拿 ReAct 来对比。这两个模式都能让Agent完成复杂任务，但思路完全不同。

📷 [图片 token=A8jeb3gT6oVxRXxOrOPcCWBJnne（未能下载，见飞书原文）]

ReAct是什么？

ReAct 的全称是 Reasoning + Acting（推理+行动）。它的核心思路是：边想边做。

用大白话说就是：Agent每走一步之前，先想一下"我现在该干嘛"，然后干一步，看看结果，再想下一步该干嘛……如此循环。

它没有一个预先的完整计划，而是每一步都是"临场决策"。

打个比方来区分

Plan-Execute-Replan 像是按导航开车：

出发前先看好路线（Plan），然后按导航走（Execute），遇到堵车了导航会重新规划路线（Replan）。你始终知道"我现在在第几步，还有几步到终点"。

ReAct 像是凭感觉找路：

到了一个路口，想一下"往左好像对"，就往左走；走到下一个路口再想一下"好像该右转了"……每一步都是现想现走，没有全局路线图。

具体对比

什么时候该用哪个？

用 Plan-Execute-Replan 的场景：

任务比较复杂，步骤多，需要有条理地推进。比如运维告警排查、自动化报告生成、多系统联动的工作流。这类任务如果"边想边做"，很容易跑偏或者遗漏步骤。

用 ReAct 的场景：

任务比较灵活，事先不确定需要几步，探索性强。比如回答一个开放性问题、在网上搜索信息等。这类任务如果非要先出计划，反而显得僵硬。

对于运维Agent来说，告警排查这种场景天然适合 Plan-Execute-Replan——因为排查步骤是有章可循的，而且需要跨多个系统协作，用结构化的方式来管理更靠谱。

五、核心优势

聊了这么多，我们总结一下 Plan-Execute-Replan 模式到底好在哪里。

优势一：结构化拆解，把复杂问题变简单

面对一个复杂任务，人容易"不知从何下手"，Agent也一样。Plan-Execute-Replan 通过 Planner 把大任务拆成小步骤，每一步都清晰可执行，大大降低了认知负荷。

就像你面对一道很长的数学大题，把它拆成 (1)(2)(3) 三小问来做，每一问就没那么难了。

优势二：动态适应，遇到问题不"死磕"

这是 Replanner 带来的最大价值。在实际执行中，各种意外都可能发生——工具调用失败、返回数据为空、中间结果和预期不符……

如果没有 Replan 机制，Agent 就只能傻傻地按原计划继续走，明明方向错了还在往前冲。有了 Replanner，Agent 就能像老司机一样灵活应变：此路不通，换条路走。

优势三：职责分离，各司其职更高效

Plan-Execute-Replan 把"规划"、“执行”、“评估"三个职责分开，交给不同的Agent来做。这种设计有几个好处：

• Planner 可以专注于理解目标和拆解任务，不用操心工具怎么调

• Executor 可以专注于执行当前步骤，不用操心全局进度

• Replanner 可以专注于评估和决策，不用操心具体执行细节

各管一摊，反而比"一个Agent包揽所有事"效率更高，这也是 Multi-Agent 架构的核心思想。

优势四：任务进度可观测

因为有明确的步骤计划，我们随时知道"Agent现在执行到第几步了"“还剩几步没做"“哪一步出了问题”。这对于运维场景特别重要——你需要知道Agent的排查进展，而不是把任务扔给它后就只能干等结果。

六、总结

最后，我们用一张"知识导图"来回顾一下这篇文章的核心内容：

为什么用？ → 运维告警排查面临流程无序、遇阻卡壳、跨系统低效三大痛点，需要一种结构化且灵活的任务执行模式。

是什么？ → Plan-Execute-Replan 是一种 Multi-Agent 协作模式，由 Planner（规划）、Executor（执行）、Replanner（重规划）三个智能体角色协同工作。

怎么工作？ → 规划→执行→评估→调整，不断循环直到任务完成。每次执行完一步都会评估结果，根据实际情况动态调整后续计划。

和ReAct的区别？ → Plan-Execute-Replan 是"先规划再执行”，适合复杂流程任务；ReAct 是"边想边做”，适合灵活探索任务。运维排查场景更适合前者。

核心优势？ → 结构化拆解降低复杂度、动态适应应对意外、职责分离提升效率、任务进度可观测。

一句话概括：Plan-Execute-Replan 让运维Agent像一个经验丰富的老运维一样——拿到告警先理清思路，然后按步骤排查，遇到意外灵活调整，最终给你一个清晰的结论和建议。

如果你正在设计运维Agent的架构，Plan-Execute-Replan 几乎是绕不开的核心模式。理解了它的原理，后面再去看具体的代码实现，就会顺畅很多。

希望这篇文章对你有帮助，有问题欢迎一起交流讨论！