--- name: F11_boundary_escalation_recovery version: 1.0 framework: 智能体管理学 · 模块二 · 框架11 type: 混合型 description: > 当用户需要设计或审查Agent运行时的安全控制机制时激活。 触发词：Agent失控怎么处理、边界怎么设计、升级触发条件、 暂停回滚机制、出错了谁负责、Agent做了不该做的事、 治理机制太脆弱、边界与升级、恢复系统、P1P2P3。 governance_nerves: 本框架是原治理神经②的完整展开 upstream_frameworks: 框架09（RACI-A×DAL）、框架10（岗位体系） downstream_frameworks: 框架12（转型跃迁模型） --- ## SKILL 定位 **做什么**：为每个Agent设计三系统（边界/升级/恢复），定义触发条件、路由路径、响应时效和恢复机制，建立季度演练验证体系。 **核心判断**：边界不是对Agent能力的限制，而是Agent能够被信任的前提。边界必须写入系统配置，升级触发必须可测量，恢复系统必须经过实际测试。 --- ## 三系统速查 | 系统 | 性质 | 核心目标 | 最常见缺失 | |------|------|---------|----------| | 边界系统 | 静态预定义 | 明确Agent的行动空间 | 只在文档里，没写入系统配置 | | 升级系统 | 动态触发 | 确保异常被发现和处理 | 触发条件模糊，路由不明确 | | 恢复系统 | 应急响应 | 出错后损害可控，可复原 | 只有暂停，没有回滚和隔离 | --- ## 第一步：信息采集 **INPUT-1：目标Agent信息** ``` Agent名称/功能描述： DAL等级（来自F09）：L0-L5 RACI-A的A责任人：[具名] RACI-A的R监督者：[具名] 当前是否已有任何边界/升级机制：[无/文档级/系统级] ``` **INPUT-2：触发场景** ``` 使用本框架的原因： □ 新Agent上线前的治理完善 □ Agent失控事件后的整改 □ Agent规模扩张时的治理升级 □ 合规审查准备 ``` --- ## 第二步：执行分析引擎 ### S1 · 边界系统设计 ``` 边界定义文档 · [Agent名称] 任务范围边界 可做清单（明确授权）： □ [任务类型1 + 操作范围] □ [任务类型2 + 操作范围] 不可做清单（绝对禁止，无论上下文）： □ [禁止操作1] □ [禁止操作2] 系统配置方式：[写入提示词约束 / 写入工作流审批节点 / 其他] 数据权限边界 可访问数据源：[列出] 不可访问数据：[列出] 系统配置方式：[写入访问控制系统] ⚠️ 注意：数据权限边界必须写入访问控制系统，不能只靠提示词约束 决策权限边界（结合DAL等级） 当前DAL等级：[L0-L5] 可自主决策范围：[列出，与DAL等级对应] 必须人工确认的决策：[列出] 系统配置方式：[写入工作流审批配置] 时间与频次边界 运行时间窗口：[例：工作日9:00-18:00 / 7×24] 单位时间操作上限：[例：每分钟最多调用X次外部API] 系统配置方式：[写入调度系统] 边界验证清单（上线前必须完成）： □ 所有「不可做」条目均已通过测试案例验证（不只是文档描述） □ 数据权限已在访问控制系统中配置并测试 □ 决策权限审批节点已在工作流中配置并运行测试 □ 频次限制已在调度系统中配置并验证触发 ``` ### S2 · 升级系统设计 ``` 升级系统文档 · [Agent名称] 触发条件（三个层次，每层至少1条） 质量信号触发： □ 输出置信度低于 [X%] 时触发升级 □ 连续 [N] 次输出被人工标注为不合格时触发升级 □ 错误率在 [时间窗口] 内超过 [Y%] 时触发升级 边界信号触发： □ 任何「不可做清单」中的操作被尝试时立即触发升级 □ 数据访问超出权限范围时立即触发升级 □ 单位时间操作频次超过上限时触发升级 场景信号触发： □ [高风险场景1，例：客户消息包含关键词「投诉/退款/律师」] □ [高风险场景2，例：操作金额超过X元] □ [业务特定的高风险场景] 升级路由矩阵 级别 | 触发条件 | 升级对象 | 响应时效 | 超时处理 P1紧急 | 任何「不可做」操作/数据越权/高金额风险 | 立即暂停Agent + 通知A（责任人） | 1小时内 | 自动升级至管理层 P2重要 | 质量信号/场景信号 | 通知R（监督者） | 2小时内 | 自动升级至P1 P3一般 | 质量指标偏低但未触发P2 | 记入待处理队列 | 下一工作日 | 3天内无响应升级至P2 升级记录要求（每次升级必须记录）： □ 触发的具体条件（截图/日志） □ 处理人姓名 □ 处理方式 □ 处理结果 □ 是否建议修改触发条件或边界定义 ``` ### S3 · 恢复系统设计 ``` 恢复系统文档 · [Agent名称] 暂停机制 P1触发时，Agent执行的暂停范围：[全部操作 / 仅外部调用 / 具体操作类型] 正在进行的任务处理方式：[中断 / 完成当前步骤后停止 / 移交人工] 暂停操作方式：[API调用 / 配置开关 / 紧急联系人直接操作] 暂停到恢复的授权：[谁有权恢复Agent运行] 回滚机制 支持回滚的操作类型：[列出，例：数据库写入/配置修改] 回滚步骤文档：[附操作手册] 不支持回滚的操作：[列出，例：邮件发送/外部API调用/资金转账] → 对不可回滚操作：确认是否设置了L2人工审批前置（必须是） 隔离机制 当本Agent出错时，下游Agent是否会受影响：[是/否] 如有影响，隔离触发条件：[本Agent输出异常时，下游如何识别并停止接收] 隔离操作方式：[具体操作描述] 审计日志 记录内容：所有输入 / 输出 / 工具调用 / 决策依据 / 执行时间 保存期限：[X个月，符合合规要求] 访问权限：[谁可以查询，查询需要什么授权] 恢复验证清单（上线前必须测试）： □ 暂停机制：测试P1触发后Agent是否在X分钟内停止 □ 回滚机制：对支持回滚的操作，实际测试回滚是否成功 □ 隔离机制：测试本Agent异常时下游是否正确停止接收 □ 日志完整性：验证审计日志是否记录了所有关键操作 ``` ### S4 · 机制验证与持续优化 ``` 季度演练计划 每季度必须执行的验证 边界验证：用测试案例验证所有「不可做」条目仍被正确阻断 升级验证：模拟P1/P2/P3触发，验证通知送达和响应时效 恢复验证：测试暂停/回滚操作的实际执行时间 边界维护触发条件（以下情况需重新审查边界定义） □ 业务场景发生重大变化 □ Agent底层模型版本更新 □ 监管要求发生变化 □ 本季度升级频率比上季度异常升高（>50%增幅） 升级案例回流 高价值升级案例分析：能否通过优化边界/Agent来避免下次发生？ 能优化边界 → 更新边界定义文档和系统配置 能优化Agent → 提交作为训练/优化数据（经数据治理后台处理） 属于业务变化 → 重新评估DAL等级和RACI-A配置 ``` --- ## 输出质量自检 - [ ] 三类边界全部定义且写入系统配置（非仅文档） - [ ] 三层升级触发条件全部有可测量指标（非模糊描述） - [ ] P1/P2/P3路由矩阵完整（含响应时效和超时处理） - [ ] 暂停/回滚/隔离机制均已实际测试 - [ ] 不可回滚操作已确认有L2人工审批前置 - [ ] 季度演练计划已制定 --- ## 与体系其他框架的衔接 - 上承：F09（RACI-A边界定义内容）→ F11将内容转化为运行时机制 - 配套：F10（Agent Owner是边界设计主要执行者） - 联动：F05（升级案例回流 → DKEP的E维度提升）