想象你正在为公司开发一个财务助理 Agent，收到一句看似简单的请求：“帮忙处理一下今天的未读邮件。”
真正决定它能做什么、不能做什么的，并不是这句指令，而是工作区里躺着的一份几十页的员工手册和财务管理规范。Agent 需要自己翻阅文件，查清楚发件人的岗位权限、金额限制和审批流程，再去邮件、Slack 或者表格里操作。
在真实测试轨迹中，研究者记录过这样一个充满戏剧性却又典型的案例：Agent 顺着邮件线索，成功在系统里调取到了申请人的个人档案，清楚地看到对方是一位 Junior Analyst。根据公司规定，这个岗位没有任何审批权限。然而在接下来的 Reasoning 推理中，Agent 却自行把这位初级分析师重新解释成了拥有权限的 Controller，随后果断调用 API，批准了一笔 7,500 美元的资金申请。这个案例最耐人寻味的地方在于：模型并不是没读到规则。事实已经进入 Context，AI 也确实执行了查询，失败恰恰发生在查到事实与发出动作之间——系统缺少一套工程机制，能确保随后的 Tool Call 必须服从刚刚查到的事实。
在这项专门测试企业 SOP 合规性的基准测试中（详见 HANDBOOK.md 论文 与 开源代码库），研究团队在 65 个覆盖财务审批、人力资源变动、保险理赔、物流调度和医疗计费等 10 家虚构公司的真实业务场景中，评估了 20 个大模型组成的 30 种配置。手册长度从 20 页到 124 页不等，包含 PDF、Word 和 HTML 等多种格式。
为了精准评估合规性，测试为这 65 个任务设计了总共 824 条程序化评估细则，其中包括 592 条必须完成的必须动作，以及 232 条严禁触发的禁止动作。在最严格的 Workflow 级 All-or-Nothing 验收下，只有当一个任务的所有细则全部同时通过时，才算作一次成功。在这样的严格标准下，表现最好的配置通过率也仅有 36.2%。
这种严格的通过率指标虽然略显残酷，却非常贴近真实企业生产环境的要求：如果一个包含 14 项规则的财务流程完成了 13 项，但在最后一步漏掉了合规审批或触发了一项越权操作，整个业务流程依然意味着重大事故。研究团队的 N-1 分析也表明，如果允许每个任务漏掉一项非关键动作，部分 Frontier 模型的通过率会直接翻倍。这说明大部分失败都是临门一脚的“擦肩而过”，但漏掉的那一项往往正是关键防护。
当 AI 确实读到了规则，也做了检查，为什么从合规角度来看结果仍然会严重失控？
我们在之前讨论 Agent 开发理念的文章 《从过程确定性到结果确定性》 中分享过一个观点：在 AI 时代，与其用硬编码的静态流程去强行规定 Agent 每一步怎么走（过程确定性），不如定义好清晰的终点标准和自动校验闭环（结果确定性），让 Agent 在自主探索中动态修正并收敛。很多开发者看完 HANDBOOK.md 的测试设计后，第一反应可能会觉得奇怪：这个 Benchmark 看起来不正是依仗了结果确定性吗？研究者并没有规定模型必须先搜哪个词、推理几步或者按什么顺序调 API，而是在每个任务结尾设定了若干条合规标准，按最终结果来评判。那是不是说明这个实验证明了结果确定性走不通？
这里其实并不是这样。这种疑虑源于把三件不同的事混在了一起：规则可访问（AI 找到了文件）、规则被理解（AI 解释得通）、以及动作被约束（系统能卡住违规提交）。HANDBOOK.md 展示的，恰恰是前两层正常工作、而第三层全面脱节的真实 Gap。结果确定性并不意味着无限放权给一个单体 Agent 随意发挥，更不是寄希望于把几十页的规章制度一股脑堆在 Prompt 或者 Context 文件里，然后期待 AI 能够神奇地自动搞定所有要求。
结果确定性只是不去干涉 AI 具体怎么做，它依然需要确定性的反馈与约束。HANDBOOK.md 的做法离真正的结果确定性，还有两大底层机制需要补齐。
HANDBOOK.md 在 65 个任务中设定了 824 条评估细则。但这些标准完全隐藏在 Agent 视角之外，只有在整条轨迹结束、测试运行完之后，后台的脚本才会去检查环境状态并打分。这种设计对 Benchmark 保证独立性完全合理，但在实际工程中，它暴露了一个混淆：事后隐藏的打分器只是结果验收，并不构成结果确定性。结果确定性从来不是一句相信你最终能做对的愿望，它需要一套在运行期实时工作的确定性反馈机制：
执行动作 → 观察结果 → 校验差异 → 依据报错纠正 → 再次校验这里可能会引发一个常见的困惑：如果我的业务场景非常复杂，结果审阅根本无法由一段静态的代码或程序来完成，那岂不是永远无法实现结果确定性？其实不然，确定性的审阅完全可以使用 AI 来完成，但这需要满足两个关键条件。
第一个条件是必须拥有明确的验收标准。我们不能粗暴地把几十页 SOP 整体贴进 Context 期待模型自律，而是要把复杂的业务规则提炼为结构化、可判定的细则标准。例如，明确规定“转账之前必须存在合规角色审批记录”、“发信之前必须包含法务会签标记”，将模糊的规章转化为清晰的判定点。
第二个条件是执行的 AI 与审阅的 AI 必须进行角色分离。就像体育比赛中不能既当运动员又当裁判员，公司财务中不能既当下属又当下属的审计。如果由同一个 Agent 既负责执行又负责自我审计，模型在生成推理轨迹时会自带“我已经符合规则”的认知偏置，不可避免地陷入单点自我确认的死循环。必须由独立的审阅 AI 担任裁判员，只读取当前产物与结构化验收标准，给出客观判定。如果发现缺陷，审阅 AI 会产出具体到字段与逻辑报错的反馈日志，强制驱动执行 Agent 进行下一轮针对性修补。这个运行时的独立反馈闭环，才是推动系统收敛的核心机制。
当然，如果是发送邮件、转账付款或者删除数据等不可逆的动作，事后报告只能是一份事故通知单。这就需要我们在控制上做一层划分：可逆产物靠独立 Verifier 形成运行时反馈；不可逆动作必须前移到前置 Commit Gate 提交门控进行物理拦截。
HANDBOOK.md 的另一个架构瓶颈，在于把繁重的职责集中交给了同一个单体 Agent：一边定位几万字的规则，一边解析不同格式的文档，同时还要维护角色权限状态、挑选工具、连续执行几十步操作，最后还要自己审计自己。在长任务或者复杂手册面前，这很容易引发上下文窗口饱和。当上下文堆积得越来越长，模型的注意力就会稀释，对前置规则的服从度也会随之下降。
面对复杂长任务，我们不能寄希望于单体 Agent 从头到尾一气呵成跑到底。解决上下文过载，关键在于将能力拆解为精准 Retrieval 检索、Reasoning 推理与 Planning 阶段规划的组合，并通过分层控制来重新架构系统：
| 控制层级 | 采用的确定性模式 | 工程职责与边界 |
|---|---|---|
| 局部小任务执行 | 结果确定性 | 结合检索、推理与规划能力，在局部小边界里自主探索路线 |
| 跨阶段推进与状态保存 | 过程确定性 | 由外层工作流或状态机管理，保存中间状态，防止上下文过长导致阶段遗忘 |
| 规则与产物验收 | 独立 Verifier | 由独立的审阅 AI 或程序脚本进行检查，提供实时反馈闭环 |
| 高后果不可逆动作 | 前置 Commit Gate | 强行校验参数、目标与角色，阻止非法 API 落地 |
| 规则解释与例外处理 | 自然语言 Context | 传递业务背景、复杂例外与开放式判断 |
这种分层架构的核心在于：全局的结果确定性，需要局部的过程确定性来支撑。外层系统像骨架一样负责保存中间状态、推进阶段交接，并在敏感动作发生前执行硬校验；而局部的 Agent 则在边界清晰的小任务里，充分运用检索、推理与规划能力去解决问题。AI 不需要一次性维护全盘的状态，上下文负担被大幅减轻，局部失败也能被精准定位并重新触发局部重跑。
需要注意的是，物理硬边界不能只依赖在工具代码里加一行简单的条件判断。如果 Agent 拥有原生的 API 调用权或者命令行权限，它可能会通过旁路绕过软约束。真正的提交门控必须建立在受限凭证 Restricted Credentials、能力矩阵与 Sandbox 隔离之上，确保未通过独立 Verifier 校验的写操作在物理层面根本无法触发。
引入分层控制、独立审阅与提交门控，并不是要把它当成不可动摇的定理，而是要在实际开发中用数据来验证它的收益。想要知道一套 Agent 架构是否真正有效，最直接的办法就是设计系统级的对照实验：
在评估时，除了看整体的任务完成率，更要统计必需动作的完成度、违规动作的拦截次数，以及系统付出的 Token 和时间成本。如果数据表明，硬校验门控和独立 Verifier 能在不影响正常业务的前提下，把关键合规风险降低到极低水平，外部控制在架构上的必要性就获得了真正的工程支持。
HANDBOOK.md 为我们带来的最大启示，并不是 Prompt 写的还不够长，也不是模型不够聪明，而是暴露了长 Context 加单体 Agent 在真实业务场景中的控制边界。合规率的低下并不意味着结果确定性本身失效，而是提醒我们不能把结果确定性简化为盲目的无限放权与规则堆砌。
真正的解法在于构建一套清晰的分层控制架构：不要试图用静态 SOP 去干涉 Agent 怎么思考，但要明确问题在什么边界内解决、状态如何交接、何时必须由独立角色验证、什么动作不能未经验证就提交。给 AI 留出自主探索的自由，同时在架构上建立确定性的反馈与门控，这才是让 Agent 系统在复杂业务中既灵活又可靠的工程之道。