北京
我原本以为自己在构建一个更好的规划引擎。结果发现，我造出来的是一台专门展示"看起来不错的计划到底有多容易出错"的机器——而且错得恰到好处：不是明显错误，而是恰好漏掉那个能把迁移变成事故的依赖关系或排序约束。
这个认知来得并不轻松。整个Agent生态都在痴迷于执行层：工具、记忆、编排、RAG、函数调用、评估。这些当然重要。但在构建了PlannerCritic之后，我越来越确信：很多团队在优化错误的那一层。
真正的失败，发生在第一次工具调用之前
一个Agent拿到"把这个服务迁移到新的认证提供商"这样的目标，在单次隐藏的思维链中完成分解，然后开始行动。三步之后，它发现数据库模式从未被检查过，停机窗口从未协调过，回滚路径从未真正存在过。计划在第零步看起来没问题，在第三步崩塌了。这时候你调试的不是Agent，而是清理它已经改动的状态。
更关键的问题在于：让同一个模型起草计划，然后"审查"自己的计划，这根本不叫审查——这只是带着额外步骤的自我认同。
研究早就暗示过这一点。当模型无法独立验证答案时，自我纠错失败的频率高得惊人。但我直到亲眼看着现场测试一遍又一遍地在我自己的系统里复现同样的模式，才真正内化了这个结论。
我给计划做了个代码审查系统
于是PlannerCritic诞生了。核心思路很简单：把计划当成Pull Request来对待。
一个LLM写草稿，另一个LLM审查。确定性门控检查结构。规划器反复修订，直到计划要么安全到可以批准，要么具体到必须升级给人类。
在实践中真正重要的几点：
- 确定性门控优先。它们检查排序、分支合理性、回滚覆盖、验证、前置条件和高风险完整性。它们不读取目标文本，因此对注入免疫。
- 审查者与规划者分离。同模型自我审查太容易被糊弄。角色分离至关重要。
- 循环有界。修订上限、收敛检测和预算执行，防止系统无限空转。
- 升级是特性，不是失败。如果循环无法收敛，引擎会产出一个最小化的人类问题，而不是猜测。
用一句话概括这个引擎：在Agent被允许行动之前，给计划做一次代码审查。
第一份计划看起来没问题，其实没有
现场测试中最有价值的一条追踪记录来自一个区块链恢复目标：bch-02-chain-split-recovery。规划器的第一版草稿看起来相当合理——直到审查者指出了那个缺失的依赖关系，那个足以让整个恢复流程变成事故现场的关键约束。
这正是157个Agent计划实测中最扎心的发现：执行从来不是瓶颈，计划本身才是。当你的Agent在第三步才发现第二步就该知道的事情，问题不在执行，在规划。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
