智能体安全三系统架构 Agent Boundary-Escalation-Recovery System ABERS

01当 Agent"越权"的那一刻

一家电商平台的价格监控 Agent，被设计用来在竞争对手降价时自动触发价格调整。有一天，它检测到了一个竞争对手大幅降价的信号——其实是对方的系统 Bug 产生的错误数据——然后自动把自己平台上二十七个品类的商品全部下调了 35% 的价格。

四个小时后，系统发现异常。但那四个小时里，已经有大量订单以错误价格成交。损失是实质性的，但更大的问题是：没有任何一个机制在这个 Agent 越权行动的第一分钟发出警报。它在做"被允许做的事"——自动调价——但没有任何边界告诉它"调价幅度超过 20% 时，必须先人工确认"。

这就是 F11 边界与升级机制要解决的根本问题：边界不是对 Agent 能力的限制，而是 Agent 能够被信任的前提。一个没有边界的 Agent，不管它多聪明，都是一个潜在的风险点。

02核心问题：三系统缺一不可

F11 把 Agent 的安全控制机制分为三个相互关联的系统，缺少任何一个都会形成安全盲区：

边界系统（静态预定义）：在 Agent 上线之前，明确定义它的行动空间——可以做什么，不能做什么，可以访问什么数据，可以自主决策什么范围。边界系统是预防性的，它的目标是"不让越权发生"。

升级系统（动态触发）：在 Agent 运行时，动态监测是否触发了需要人工介入的条件——输出置信度低于阈值，任务类型超出授权范围，连续多次失败，涉及特定高风险场景。升级系统是探测性的，它的目标是"越权发生时立即知道"。

恢复系统（应急响应）：当问题已经发生，如何快速止损、恢复正常状态、防止扩散——暂停机制（立即停止 Agent 继续执行）、回滚机制（撤销已执行的操作）、隔离机制（防止问题从一个 Agent 扩散到其他系统）。恢复系统是应急性的，它的目标是"出问题时损害可控可复原"。

03边界必须写入系统，不能只在文档里

这是 F11 框架最关键的操作要求，也是最经常被违反的一条。很多企业的 Agent 边界是"文档级"的——有一份文件描述了这个 Agent 不应该做什么，但这些限制没有被写入系统配置，也没有被技术上强制实施。

文档级边界的问题是：Agent 不会主动阅读文档。如果"不可做"清单只存在于文档里，任何绕过提示词的输入、任何系统状态的异常，都可能触发越权行为。边界必须在两个层面被实施：提示词约束层（在模型层面限制行为范式）和系统配置层（通过工作流审批节点、访问控制系统、权限管理强制执行）。缺少后者的边界，是纸上的边界。

04升级触发条件必须可测量

很多企业的升级规则是这样写的："当 Agent 遇到无法处理的情况时，升级到人工"。这不是升级规则，这是一句废话——因为 Agent 不会主动判断自己"无法处理"。

可执行的升级触发条件，必须是可测量的：置信度低于 0.7、连续三次未达到质量标准、任务类型包含特定关键词、处理时间超过阈值、涉及金额超过限额。这些条件都可以在系统层面被监测和自动触发，不依赖 Agent 的自我判断。

升级路由也需要被精确定义：升级给谁？通过什么渠道？要求多长时间内响应？如果在规定时间内没有响应，接下来如何处理？模糊的升级路由等于没有升级路由。

05恢复系统必须经过真实测试

恢复系统最常见的问题是：有计划，没测试。很多企业在纸面上设计了回滚机制，但从来没有实际触发过，也不知道当真正需要回滚时，这个机制是否真的能工作。

F11 框架要求每季度进行一次三系统的实际演练——模拟一个真实的 Agent 越权或异常场景，触发升级机制，执行恢复流程，验证整个链条的响应速度和有效性。从未经过测试的恢复系统，在真正需要它的时候往往会失效——因为没有人真正操作过，流程依赖已经过期，工具权限已经变化。

06在体系中的位置

F11 是治理神经②"边界与升级机制"的完整展开，也是模块二"组织重写"从理论设计向操作实施转化的关键一步。F09 定义了谁负责，F10 设计了岗位，F11 告诉负责人具体应该如何把安全控制机制落实到每一个 Agent 的系统层面。

上承 F09（RACI-A 治理，责任归属设计）和 F10（岗位体系，编排层人员配置）→ 本框架（三系统边界/升级/恢复设计，系统级安全控制）→ 下启 F12（组织变革，把治理文化内化到整个组织而不只是技术团队）。同时，F11 的三系统框架也是 F03（Agent 组合矩阵）中 L3+ Agent 扩张前必须完成的治理要求。