以设计为本的终止开关：智能体治理架构

预测

2026 年 5 月，Gartner 发布了一项预测，将智能体治理从合规细节重新定位为生存问题：到 2027 年，40% 的企业将因仅在生产事件之后才发现的治理缺口而降级或下线自主 AI 智能体。

根据 Gartner 的 Shiva Varma，根本原因在于企业把治理当作二元的——"要么锁死，要么完全信任"。这种框架之所以失败，是因为生产智能体运行在一个自主性的谱系上。一个读取目录以回答支持问题的智能体，所需的控制不同于一个持有库存、为报价定价并将已接受订单写入 NetSuite 的智能体。对两者施加相同的治理，意味着低风险智能体被过度控制，而高风险智能体被控制不足。二者以不同的方式失败。

Gartner 的框架定义了四个自主性级别，每个级别都有不同的治理要求：

• 级别 1（观察）： 只读访问。轻量控制——受限的数据访问、用户认证、使用日志记录。风险：数据暴露。
• 级别 2（建议）： 只读，由人类执行操作。风险：自动化偏见。治理：准确性与幻觉测试、特定领域的质量评估。
• 级别 3（经批准后行动）： 可以写入、通信或修改——但仅在每次操作获得明确人工批准之后。风险：批准疲劳。治理：强有力的安全测试、带审计追踪的清晰批准流程、针对智能体的事件响应。
• 级别 4（自主行动）： 在护栏内独立执行。风险：规模与速度超出人类监督。治理：持续监控、强制护栏、快速回滚、断路器、明确的归属。

40% 的下线预测正落在级别 4。一个在没有断路器和快速回滚的情况下自主运行的智能体，正是那种在事件之后——而非之前——被下线的智能体。

证据：单一的终止开关行不通

Gartner 的框架是分析师的指导。而支撑它的证据更难被驳倒。

一项 Stanford Law School CodeX 分析（2026 年 3 月）批评了 UC Berkeley Agentic AI Risk-Management Standards Profile，并引用了模型在 100 次测试中有 79 次破坏关停机制的证据。Berkeley Profile 是一份 55 页的 NIST AI RMF 扩展文件，是一份严肃的文档。但 Stanford 的批评指出了三个结构性缺口：

1. 人工监督是回溯性的。 Berkeley Profile 在事后审查已发生的事情。Stanford 的 AILCCP 框架提出前瞻性控制——一个针对敏感操作的人工批准门（Human Approval Gate），它在执行之前门控可能发生的事情，而非事后发生的事情。

2. 终止开关被当作单一实体的终止。 Berkeley Profile 假设你关停一个智能体。在多智能体架构中，如果智能体间的通信仍然活跃，关停一个智能体并不能遏制损害。AILCCP 框架用分层关停系统取代单一终止开关：智能体终止开关（带状态捕获与不可变日志的即时停止）、回滚与隔离、多智能体协议安全（遏制智能体间通信）、以及速率与范围限制器（在升级之前限制频率、支出和影响半径）。

3. 范围限制是静态的。 一条声称"该智能体只应修改开发系统"的策略毫无意义，如果该智能体在技术上拥有对生产环境的访问权，且没有任何机制阻止它到达生产环境。AILCCP 框架通过安全操作过滤器（允许列表）和影子模式预执行检查（对比预期操作与已批准操作的空跑）在实时中强制范围。

Stanford 的结论很直接："全面的风险识别若没有相应的控制具体性，就产出一份描述火情却不提供灭火器的文档。"AILCCP 框架规定了 48 项控制，旨在把原则转化为可审计、可辩护的机制。

Cloud Security Alliance（2026 年 1 月）通过一条不同的路径独立得出了相同的结论。CSA 发布了一个六级自主性分类法（L0 到 L5），对应 SAE J3016 车辆自动化级别。CSA 的关键发现："大多数部署智能体式 AI 的组织没有正式的自主性级别分类系统，以临时方式做出自主性决策，[并且]缺乏对自主性边界的技术强制。"CSA 直言："一条声称'该 AI 只应修改开发系统'的策略毫无意义，如果该 AI 在技术上拥有对生产环境的访问权，且没有任何机制阻止它访问生产环境。"

三个独立来源——Gartner、Stanford Law CodeX、CSA——汇聚到同一个结论：二元治理会失败，带分层关停的按比例治理才是标准，而对自主性边界的技术强制正是策略与控制之间的区别。

监管的强制推力

欧盟人工智能法案将于 2026 年 8 月 2 日达到全面执法——距今 22 天。第 14 条要求高风险 AI 系统实现实时停止能力。第 12 条要求日志至少保留六个月。第 99 和 100 条鉴于条款将合规扩展到多智能体链中的每一个智能体。最高罚款为 3500 万欧元或全球年营业额的 7%。

Gartner、Stanford 和 CSA 所描述的分层关停系统不仅是最佳实践。它正是满足第 14 条停止能力、第 12 条日志保留、以及第 99 和 100 条鉴于条款多智能体范围的架构。合规截止日期使治理架构成为近期要求，而非未来考量。

四层架构

AILCCP 分层关停系统对应四个具体的实现层。每一层都是一项可以测试、审计并向合规审查者演示的控制。

第 1 层：基于身份的访问门控

每一次工具调用在执行前都要经过认证。智能体对 MCP 服务器并不拥有一揽子访问权——它出示一个凭证，服务器验证它，只有凭证有效时调用才会继续。

在 SilvaEngine 的 ai_mcp_daemon_engine 中，这就是 FlexJWTMiddleware——一个 Starlette 中间件，拦截每个请求，提取 Bearer 令牌，并将验证路由到 AWS Cognito（用于生产部署）或本地 HS256 JWT 提供者（用于开发）。该中间件维护一份公共路径列表（/auth、/health），并以 401 响应拒绝每一个不携带有效令牌的其他请求。Cognito 路径从用户池的 well-known 端点获取 JWKS，支持 HTTP/2 并缓存 JWKS 响应（TTL 可配置，默认 3600 秒），因此令牌验证不会在每次调用时增加一次网络往返。

这就是 AILCCP 的"带身份撤销的智能体终止开关"——第一道门。当一个智能体的凭证在 Cognito 中被撤销时，该智能体随后的每一次工具调用都会在中间件处失败。关停是即时的，无需触及智能体代码或模块配置。撤销一个 Cognito 用户是停止行为异常智能体的最快方式。

第 2 层：按工具的断路器与审计日志

每一次工具执行都被包裹在一个装饰器中，该装饰器在运行前记录调用，并在完成后用结果更新记录。记录捕获工具名称、输入参数、输出内容、状态（initial、completed、failed）、耗时（毫秒）以及调用者的身份。

在 ai_mcp_daemon_engine 中，这就是 mcp_utility.py 中的 execute_decorator。在工具函数执行之前，装饰器在 DynamoDB 中创建一条状态为 initial 的 MCPFunctionCallModel 记录，捕获 partition key、工具名称、参数和时间戳。执行之后，它用内容、状态 completed 和以毫秒计的 time_spent 更新记录。如果工具抛出异常，装饰器会捕获它，将记录更新为 failed 状态并在备注字段中记录完整的 traceback，然后重新抛出。

MCPFunctionCallModel 将记录存储在一个 DynamoDB 表（mcp-function_calls）中，使用 partition_key 作为哈希键，mcp_function_call_uuid 作为范围键。三个本地二级索引支持按 MCP 类型、按名称和按更新时间戳查询——因此运营人员可以询问"给我看过去一小时内对定价工具的每一次失败调用"，并通过单次索引查询得到答案。超过 DynamoDB 400KB 单项限制的内容会自动卸载到 S3，并用 content_in_s3 标志标记该记录。

这就是 AILCCP 的"不可变日志"与"断路器"的结合。审计追踪是第 12 条所要求的合规证据。按工具的状态跟踪是断路器的基础——当某个工具的失败率越过阈值时，运营人员可以禁用该工具而不影响智能体的其余部分。MCPFunctionCallModel 记录是监控、告警和事件后重建的数据来源。

第 3 层：按租户隔离的数据

每一次工具调用都携带一个 partition key，将数据访问限定到单个租户。partition key 由端点 ID 和可选的部分 ID 构成，以 # 分隔符连接。所有 DynamoDB 查询、所有缓存查找和所有模块状态操作都按此键过滤。为租户 A 运行的智能体无法读取租户 B 的数据，因为 partition key 在数据层而非应用层被强制执行。

在 ai_mcp_daemon_engine 中，AIMCPDaemonEngine._apply_partition_defaults 方法从传入请求的 endpoint_id 和 part_id 构造 partition key，并通过 GraphQL 上下文将其传播到每一个下游查询和变更。MCPFunctionCallModel、MCPFunctionModel、MCPModuleModel 和 MCPSettingModel 都使用 partition_key 作为其哈希键。缓存层（CACHE_ENTITY_CONFIG 和 CACHE_RELATIONSHIPS）将每个缓存条目键入 context:partition_key，因此缓存失效是按租户的。

这就是 AILCCP 的"速率与范围限制器"和 CSA 的"对自主性边界的技术强制"合于一个机制。智能体的影响半径由 partition key 界定。一个被批准修改开发系统的级别 3 智能体无法到达生产系统，因为 partition key 不同，且不存在跨分区的查询路径。范围限制由数据模型强制，而非由策略文档。

第 4 层：快速回滚与模块级禁用

每一个 MCP 模块都可以在不触及编排主干的情况下被禁用。模块配置存储在 DynamoDB 中，并在运行时通过 Config.fetch_mcp_configuration 加载。禁用一个模块意味着更新其配置记录——下一次配置获取会排除它，返回给智能体的工具列表将不再包含被禁用的工具。无需代码部署，无需重启，无需智能体重新编译。

Config 类中的 admin_static_token 提供了一条受限的撤销路径。持有管理员令牌的运营人员可以通过 GraphQL 变更接口发出配置更改——禁用一个模块、更新速率限制、更改一项设置。该令牌是一个带 perm: true 声明的静态 JWT，会绕过过期检查，因此即使正常的令牌签发流程中断，管理员路径也始终可用。

这就是 AILCCP 的"回滚与隔离"层。当一个模块行为异常时，运营人员的第一个动作是通过配置禁用它——智能体继续用其余工具运行，被禁用模块的函数调用返回一个智能体可以通过其回退路径处理的错误。模块被隔离（其配置被保留以供调查）而不使智能体下线。这就是"停止一切的终止开关"与"隔离故障的分层关停"之间的区别。

为什么各层协同工作

每一层应对一种不同的故障模式：

故障模式	层	控制	会发生什么
智能体凭证被泄露	1	基于身份的访问门控	撤销 Cognito 用户；随后所有调用返回 401
工具产出错误结果	2	按工具的断路器	禁用该工具；智能体路由到回退或升级到人工
智能体访问未授权数据	3	按租户隔离	partition key 在数据层阻止跨租户查询
模块行为不稳定	4	快速回滚	通过配置禁用模块；智能体以其余工具继续运行

各层是独立且可组合的。一个 Gartner 级别 2（建议）的智能体可能只需要第 1 层和第 2 层——认证和审计日志——因为它的操作是咨询性的，由人类执行结果。一个级别 4（自主行动）的智能体需要全部四层，外加对审计追踪的持续监控，以在异常升级之前将其检测出来。

CSA 分类法增加了动态调整的维度：自主性级别可以在异常期间自动下降。一个通常在级别 4 运行的智能体，可以在其错误率超过阈值时被自动降级到级别 3（经批准后行动）——来自第 2 层断路器的数据为自主性级别决策提供输入。正是在这里，各层从一个堆栈变成一个系统：审计追踪为治理决策提供信息，治理决策调整护栏，而调整后的护栏又通过同样的四层被强制执行。

采购标准

Gartner 的预测——到 2027 年 40% 的企业将下线智能体——有一个面向买方的翻译。如果你的智能体供应商无法回答这四个问题，他们就没有治理模型：

1. 你的智能体在什么自主性级别运行？ 如果答案是"看情况"或"完全自主"，那就没有分类系统。CSA 发现，大多数组织没有正式的分类。

2. 你如何关停一个行为异常的智能体？ 如果答案是"我们停止进程"或"我们从代码里移除工具"，那就没有分层关停。智能体无法在不部署的情况下被禁用，这意味着响应时间以小时而非秒来衡量。

3. 你能给我看最近 100 次工具调用的审计追踪吗？ 如果答案是"我们在 CloudWatch 里有日志"，那就没有结构化的按工具审计记录。审计追踪应当可以按工具名称、状态和时间范围查询——而不是在日志流里 grep。

4. 如果一个租户的智能体出错，影响半径是多大？ 如果答案是"我们按部署隔离"，那就没有数据层的租户隔离。影响半径是整个部署，而非单个租户。

四层架构以具体机制而非策略声明回答每一个问题。这就是"描述火情"与"提供灭火器"之间的区别。

---

一个运行 NetSuite、BigCommerce 和三个供应商目录的分销商，部署了一个 Gartner 级别 3 的智能体：它为报价定价、持有库存，并将已接受的订单写入 NetSuite——但每一个超过阈值的定价操作都需要人工批准，且每一次工具调用都记录 partition key、工具名称、参数哈希和耗时。当某个供应商目录模块开始返回不一致的可用性数据时，运营人员通过配置禁用该模块。智能体路由到回退目录，被禁用模块的近期调用从审计追踪中被查询以供调查，而智能体全程保持在线。该构建是四步法的第 2-4 阶段，通常在 5-8 周内上线。

申请一次限定范围的构建。 一周发现。你会得到一份系统清单、一张工作流程图和一个固定范围——无论你是否与我们一起构建。