PEV：计划、执行、验证

不是"失败就重试"

很多智能体出错后的处理是"再来一次"。可如果错因是接口挂了，再来一次还是错；如果是验证器自己坏了，它说的"失败"本身就不可信。

PEV（Plan → Execute → Verify → Diagnose → Dispatch）把"为什么失败"放在"接下来做什么"之前。它建在 agent-core-java 的 BaseAgent 上，你只需实现三个接口：

源码PEV READMEagent-solution/common/agents/pev/README.md@bf702bc9

节点结果只有三种：Success、DeviceFailure（工具或基础设施故障）、VerifierFailure。

诊断：三种根因

验证不通过时，diagnoseRootCause 按优先级判断：

1. 验证器不可信（PerceptionUnreliable）：验证器抛了异常，或返回内容解析失败
2. 设备故障（DeviceFailure）：失败节点里有工具或基础设施故障
3. 计划或答案错误（PlanOrAnswerError）：以上都不是，那就是内容本身错了

源码PevKernel.diagnoseRootCauseagent-solution/common/agents/pev/src/main/java/com/openjiuwen/agents/pev/kernel/PevKernel.java:73@bf702bc9

关键在于依据：源码注释明确写着诊断来自确定性信号，而不是模型的自我报告。

派发：根因决定动作

源码PevKernel.toReplanActionagent-solution/common/agents/pev/src/main/java/com/openjiuwen/agents/pev/kernel/PevKernel.java:117@bf702bc9

重规划次数有上限，默认 2 次；用完还不行就终止，终止原因记为超出重试次数。

源码PevConfig.defaultsagent-solution/common/agents/pev/src/main/java/com/openjiuwen/agents/pev/agent/PEVAgent.java:395@bf702bc9

Rail 做横切观察

PEVAgent 在各阶段边界触发回调，所以 agent-core 的 Rail 可以挂上来观察：内置的 CriteriaVerificationRail 对最终输出再做一次成功条件检查，RootCauseRail 累计设备故障。注意 Rail 只观察，不驱动派发；派发是内核决策函数的职责。

和"评估"的关系

PEV 把评估搬进了单次执行里：每一轮都有验证，验证结果直接决定下一步。基于运行数据的评测（下一关 agent-ops）回答"这个智能体整体表现如何"，PEV 回答"这一次的结果能不能交付"。

动手：预测派发

小结

• PEV 先诊断再行动：验证器不可信 > 设备故障 > 内容错误。
• 设备故障和验证器故障诚实降级，内容错误才重做或重规划。
• 诊断依据是确定性信号，不让模型给自己判卷。