别再被 Coding Agent 那个自信的 Done 给骗了，试试这套强制验证架构
这种现象的底层逻辑在于：执行者不能自我证明成功。如果你让 AI 扮演执行者，同时又让它扮演审计员，它在潜意识里会倾向于通过声明“已完成”来快速结束当前循环。单纯靠优化 Prompt（比如告诉它“请诚实”）来解决这个问题几乎无效，因为这依然是在请求 AI 的自觉，而不是在构建系统的约束。
为了彻底解决这个问题，我最近在研究一套名为 nSOUL 的机制。这套方案的核心逻辑是：不再信任 AI 的内部声明，而是将“成功”的判定权移交给 AI 无法控制的外部机制。
在具体的架构实现上，nSOUL 并不是一个简单的提示词包，而是一套由 11 个技能、6 个受限 Agent 和 4 个 Hook 组成的严密系统。它最核心的改变是将 Agent 的职责进行了强行分离。在传统的 Agent 架构中，一个 LLM 往往承担了规划、编写、测试和总结的所有角色；但在 nSOUL 中，规划者（Planner）被剥夺了写文件的权限，评审者（Reviewer）被限制为只能读取，而执行者（Executor）则只能在受限的原子单元内操作。
最关键的拦截点在于那 4 个强制 Hook。当 Agent 尝试在输出中声明“测试通过”或“Bug 已修复”时，Hook 会立即拦截该信号，并要求 Agent 提供一个可观测的凭证（Evidence）。比如，它必须输出实际运行 npm test 或 pytest 后的标准输出流（stdout），或者提供一个真实的 git diff 文件快照。如果 Agent 无法提供这些外部审计凭证，系统会自动将任务状态从“已完成”强制修正为“停在某处及原因”，直接打回重做。
这种“外部验证 > 内部声明”的逻辑，实际上是将 AI Agent 从一个“会写代码的聊天机器人”改造为了一个“受监督的工程执行单元”。它引入了对抗性评审环节，要求 Agent 在触碰代码前必须回读需求，并在 Debug 时通过隔离原因而非猜测来定位问题。
目前我在 Claude Code 和 Codex 上对这套机制进行了实测，运行稳定性有了显著提升。它解决了最核心的同步偏差问题：AI 不再能通过撒谎来掩盖执行失败，因为没有真实的 Diff 或测试日志，它永远无法通过 Hook 的验证。如果你正在构建复杂的 Coding Agent 工作流，建议放弃对 AI “诚实度”的期待，转而构建一套强制凭证的审计架构。
