把 AI 写的代码直接推到生产环境，你敢吗

我在构建 Agent 系统时踩过不少坑，实测跑了 170 个 Agent 目标，发现 Planner 极其容易重复出现三种规划缺陷；另外跑了 83 个真实 Agent 过工具调用门控，结果花了一周时间在修 Matcher，最后发现 Bug 其实就在 Evaluator 的六行代码里。

如果你习惯了 add/commit/push 这种流程，你应该意识到：有些检查在 CI 绿灯时是看不出来的。我把下面这几项从「建议」升级成了「门控（Gate）」——建议是希望，而门控是如果不通过就直接让 Build 失败的硬性测试。

验证依赖项是否在执行前已就绪

这是我记录到最常见的缺陷。AI 的 Planner 知道某个步骤需要什么前置条件，但它经常忘记在之前的步骤里把这个条件给建立起来。在我收集的 63 个失败计划中，有 57 个拦截点都属于这一类。

[BLOCKER] unverified_dependencies, task=cutover_traffic_100
 "Cutover to 100% is dependent on prior stages being established 
 but lacks confirmation of stability before proceeding."

解决办法不能靠 Prompt，而要用一个确定性的前置条件检查器（Precondition Closer）。在模型产出草案后运行，必须确保每一个前置条件都能映射到之前的某个具体任务，否则直接打回。如果 AI 告诉你「在验证之后」，你得追问具体哪个任务在验证，如果它回答「这不言而喻」，那这就是个 Bug。

强制要求任务在硬性前置条件之后排序

我统计过有 46 个拦截点纯粹是因为排序错误。比如切流跑在了检查之前，回填跑在了索引验证之前，甚至数据库在备份完成前就被删了。

大模型擅长列出正确的步骤，但很不擅长排序。这本质上是一个图论问题，而不是语言问题。所以不要试图通过优化 Prompt 来解决，直接上拓扑检查（Topological Check）。

[BLOCKER] unsafe_sequencing, task=backfill_vectors
 "Cannot proceed until the index is verified for quality; 
 it is ordered incorrectly in the sequence."

高风险步骤必须配备可信的回滚方案

AI 经常在常规步骤里写回滚，但在切流、销毁或回退等高风险步骤时反而给漏了。我在 18 个拦截案例中发现了这个问题。

[BLOCKER] weak_rollback, task=dual_write_setup
 "Rollback only switches to single-write mode without addressing 
 the inconsistencies dual-write may have introduced."

很多 AI 写的回滚只是「装饰品」，并不能真正恢复到之前的状态。建议在门控里问一个核心问题：如果这一步失败了，声明的回滚操作能否让系统回到已知的健康状态？记住，回滚覆盖率不重要，回滚的可触达性（Reachability）才重要。

对工具调用做门控，而不是对 Prompt 做限制

很多人把 Agent 的安全性寄托在 Prompt 上，但用 Prompt 防御 Prompt 注入只是个建议。Agent 的工具调用（Tool Call）是唯一能实现确定性控制的地方，所以必须把它做成门控。

我之前基于这个思路构建了 Agent ToolTrust，把权限分成了四个状态：allow（允许）、audit（审计）、escalate（升级）、deny（拒绝），而不是简单的二元对立。因为二元选择要么导致 Agent 权限过大，要么导致审核员产生疲劳。由于这个引擎运行在模型之外，无论怎么做 Prompt Engineering 都无法绕过 deny 状态。

@adapter.guard(tool_name="deploy_service", action="deploy", 
 environment="production", data_class="restricted")
def deploy_service():
    # 具体的部署逻辑
    pass