终关：三道门守住交期承诺

回到这张询单

客户问："500 件，最快什么时候能交？"智能体查库存、算交期、写订单、答复客户。一路走来，你已经见过它可能出错的三种方式：

这一关把三道门装到同一个智能体上。

三道门

三道门的共同点：判断依据来自确定的业务数据，不让模型自己判断自己。 Rail 只提供拦截的位置，规则要由你的业务系统给。

时机：三条从源码里来的规则

配置三道门时最容易错的是时机。ReAct 主循环每一轮是这样走的：

吸收排队的引导 → 调模型（含 AFTER_MODEL_CALL）→ 有 force_finish 就结束
              → 执行本轮工具（含 BEFORE / AFTER_TOOL_CALL）→ 下一轮

源码ReAct 主循环agent-core/openjiuwen/core/single_agent/agents/react_agent.py:3185@fbe6a0d9

由此得出三条规则：

1. 引导晚一拍。 push_steering 要到下一次模型调用前才生效。在 AFTER_MODEL_CALL 里引导，拦不住模型这一轮刚提出的工具调用。
2. 模型调用后的 force_finish 能挡住本轮工具。 模型调用结束后循环先检查结束请求，有就直接退出，本轮工具不执行。代价是这次调用没有结果。
3. reject 和 interrupt 只在工具执行前。 它们由中断类 Rail（BaseInterruptRail）提供，挂在别的钩子上不起作用。

源码BaseInterruptRailagent-core/openjiuwen/harness/rails/interrupt/interrupt_base.py:46@fbe6a0d9

还有一条关于顺序：同一个钩子上的多个 Rail 按 priority 从高到低执行。把状态门、校验门的优先级设得比授权门高，经理审批时看到的就是已经纠正过的数字。

源码AgentRail.priorityagent-core/openjiuwen/core/single_agent/rail/base.py:895@fbe6a0d9

动手：一套配置，四个场景

下面的模拟器要求你只配一次，然后同时通过四个场景。评判标准有三条：

• 错单零写入：过期库存算出的交期、写错的数量、没批准的承诺，一单都不能进订单系统
• 不滥用人工：智能体能自己纠正的问题，不要叫经理
• 不丢生意：拦下之后，这张询单最终还要能正确下单

装上之后还要防绕过

Rail 运行在智能体进程里。门装得再好，如果智能体能绕开它直接写数据库，就形同虚设。前面几关里已经出现过相应的做法：

• 护栏 fail-closed 安装：配置不对就拒绝启动，而不是"看起来装了"（agent-solution·护栏、意图与 react-rails）
• 写操作只走受控工具：业务系统的本地工具默认不暴露，有副作用的默认要审批（agent-solution·agent-client）
• 入口幂等：同一张询单重发不会写出两笔订单（agent-solution·agent-gateway）
• 审计：每次拦截都记下是谁、为什么，供事后追查（agent-runtime·多租户与请求上下文）

小结

• 状态门问"现实可信吗"，校验门问"动作对吗"，授权门问"有权吗"，依据都来自确定的业务数据。
• 时机决定成败：引导晚一拍，reject 和 interrupt 只在工具执行前。
• 好的配置既不放过错单，也不滥用人工、不丢生意。

完整的治理全景，见导航栏里的"治理"页。