从Plan-Execute到混合PEV：一个运维诊断Agent的架构演进实录

在构建运维诊断Agent时，我踩进了一个经典的坑：用Plan-Execute架构去应对高不确定性的诊断场景，结果推理割裂、流程卡死。

这篇文章，我想复盘一下这次架构演进的全过程------从最初的PE拆分，到中间踩坑，再到最终成型的混合PEV方案。希望能给正在做类似事情的同行一些参考。

一、踩坑实录：被拆散的PE架构

最开始，为了"做得专业一点"，我严格遵循PE思想，把主流程拆成了这样一串节点：

Planner → Executor → Gatekeeper → Verifier → Composer

每个节点各司其职：Planner定计划，Executor调工具，Gatekeeper校验参数，Verifier审查结果，Composer写报告。听起来很合理对吧？

实际跑起来，问题一个接一个。

问题1：计划赶不上变化

运维诊断有个特点：排查路径是"走一步看一步"。查了日志发现超时，才决定下一步去看下游服务；看了下游的监控，可能又要去查配置。

但PE架构要求Planner在开头就把整条路径规划好。这就很尴尬了------Planner要么只能猜一个大概率的路径（一旦猜偏就全错），要么每查一步都得传回Planner重新规划。状态在节点间来回踢皮球，推理链条被切得稀碎。

问题2：LLM审查LLM，陷入死循环

为了防幻觉，我在主链路里串了两个审查节点------Gatekeeper和Verifier。这俩都是LLM节点。

结果出现了最讽刺的情况：Verifier觉得Executor的结论不行，打回去重做；Executor改了一版，Verifier还是不满意。两个模型来回拉锯，主流程彻底卡死，Token哗哗地烧。

更麻烦的是，Verifier自己也会幻觉------它可能把Executor基于真实证据得出的正确结论给误判打回。用一个可能犯错的东西去审查另一个可能犯错的东西，这事儿本身就不太靠谱。

问题3：传状态成了大麻烦

节点多了，状态传递就成了灾难。要么把工具返回的原始数据全量传过去，Planner和Verifier的上下文迅速爆炸；要么做摘要传递，但摘要一做就可能丢掉关键线索。

怎么传都不对。

二、重新想清楚：诊断场景到底需要什么？

踩完这些坑，我回过头重新想了一个问题：诊断场景到底需要什么样的架构？

答案是：诊断本质上是一个"边摸边探"的过程，不适合提前做死计划。 你不可能在动手之前就知道问题出在哪。

所以，高不确定性场景需要的是ReAct那种"感知→决策→行动→反馈"的高频闭环，而不是Plan-Execute那种先计划再执行的线性流程。

但是，这并不代表PE思想完全没用。只是需要用对地方。

三、破局：混合PEV架构

基于这个思路，我把架构重构为"主干ReAct + 已知场景固化 + 分层验证"的混合形态。

改造1：砍掉Planner，让Agent边查边想

删掉独立的Planner和Executor节点，合并成一个DiagnosisAgent。内部就是一个ReAct循环：想一步、做一步、看结果、再想下一步。所有推理都在一个上下文里完成，连贯性自然就好了。

改造2：高频已知场景走"高速通道"

有个现实问题：80%的工单是重复的已知问题。对于这些场景，没必要每次都走ReAct绕一圈。

我的做法是：把常见问题的排查路径由专家固化成SOP（也就是离线的Plan）。一旦用户的问题命中了已知特征，直接走预设的流水线，秒级出结果，不经过LLM推理。我管这个叫"Highway模式"。

改造3：验证拆成两层，避开死循环

经典的PEV里，Verify是同步阻塞的，这也是死循环的根源。我把验证拆成两层：

第一层：代码验真（主链路同步，0次LLM调用）

检查报告里的证据ID是否真实存在、文件路径是否合法、JSON格式对不对。这些都是代码断言，不涉及LLM，所以零幻觉、零延迟。不通过就直接打回Agent重试（最多2次）。

第二层：语义校验（后台异步，独立Agent）

代码管不了的交给这个层：比如日志报错时间和指标飙升时间是否对齐、结论逻辑是否自洽。

关键点是：它是异步触发的，不阻塞主链路。它不参与"打回重做"的循环，只输出一个置信度分数。

改造4：基于置信度的输出策略

异步校验期间，用户不能干等着。我的处理方式是这样的：

主Agent输出草稿报告，代码验真通过后，先不直接给结论，而是写入暂存区，状态标记为"校验中"
前端显示"证据收集完毕，正在安全校验..."
后台异步跑Verifier Agent
根据置信度，通过WebSocket做二次推送：
- ≥0.7：直接推结论
- 0.4~0.7：推结论，但附带"建议人工复核"的提示
- <0.4：不推结论，只展示原始日志和异常时间线，交给人工判断
- 超过8秒未返回：直接推草稿报告，附加"校验超时"提示

这样用户始终有反馈，不会被卡住，同时高风险的结论也不会"裸奔"出门。

四、架构全景

重构后的整体架构是这样的：

flowchart TD A[用户诊断请求] --> B{命中已知SOP} B -->|是| C[Highway流水线] C --> D[秒级输出结果] B -->|否| E[单ReAct Agent] E --> F[草稿报告] F --> G[代码物理验真零LLM调用] G -->|不通过| H[打回Agent重试最多2次] H --> E G -->|通过| I[写入暂存区校验中] I --> J[前端提示证据收集中] J --> K[异步Verifier Agent 语义校验] K --> L[置信度分级] L --> M[高置信度推送强结论] L --> N[中置信度推送结论加警告] L --> O[低置信度推送原始线索] L --> P[超时推送草稿加提示]

五、几点总结

复盘这次架构演进，有这么几点体会：

不要迷信经典架构。Plan-Execute在确定性场景里很好用，但诊断这种高不确定性场景，它天然水土不服。选架构先看场景特性，别拿锤子找钉子。
LLM不该用来审查LLM。让一个可能幻觉的东西去审查另一个可能幻觉的东西，逻辑上就站不住。硬性校验交给代码，语义校验做成异步参考，别让它阻塞主流程。
高频场景要固化，别让模型每次都从头想。80%的已知问题走高速通道，让模型把精力花在那20%的长尾复杂问题上。
异步和降级是生产级系统的必修课。校验慢了就降级输出，别让用户空等。工程上"够快且可用"比"完美但卡死"强得多。

诊断场景的Agent架构，本质上是在敏捷试探 和可靠验证之间找平衡。把这两个需求解耦，各自用合适的方案去满足，系统自然就稳了。