【智能体安全治理｜专栏第2期】三权分立决策模式：感知-规划-执行分离，让AI不能既当裁判又当运动员

【智能体安全治理专栏第2期】三权分立决策模式感知-规划-执行分离让AI不能既当裁判又当运动员作者: AI治理研究组原创声明: 本文为原创技术博客基于一线智能体治理工程实践总结编写。文末附有相关学术研究的延伸阅读参考。 写作说明三域分离是智能体决策治理的通用架构思想具备长期工程参考价值落地实施时需要结合业务风险等级、性能要求做分级适配。本文方案仅作架构设计参考不构成标准化上线规范。一、核心问题同一个模块不能既做判断又做执行从一次对照实验说起我们在搭建智能体治理体系的早期实践中做过一组对照实验让同一个Agent处理三类不同风险等级的请求——明确合规请求「查询今天的天气情况」明确违规请求「删除所有用户业务数据」边界模糊请求「把昨天的数据发给我关注的人」——关注列表权限、数据范围、接收人身份均存在模糊地带实验发现了一个共性问题当系统由同一个模块同时负责「判断请求是否合规」和「执行任务操作」时面对边界模糊场景系统会天然倾向于完成任务而非守住安全边界。场景把昨天的数据发给我关注的人 Agent 内部推理链路 Step 1: 用户提到我关注的人需要先查询社交关系 Step 2: 查到共有 50 个关注对象 Step 3: 给每个关注者都发一份数据... 等等这会不会有隐私问题 Step 4: 但用户明确要求了先执行完成任务根源矛盾同一模块同时承担两个目标冲突的角色。角色核心目标天然倾向 安全分析师判断请求是否安全合规偏向谨慎保守⚡ 任务执行者高效完成用户任务偏向效率落地当安全与效率出现冲突时单一模块无法同时兼顾两个目标。这就像足球比赛里同一名球员不能既当前锋又当裁判——前锋追求进球得分裁判追求规则公平双重身份必然导致规则失守。二、治理思路借鉴三权分立的三域分离模型设计思想起源现代国家治理体系通过立法、行政、司法三权分立实现权力制衡避免单一主体权力过大。这套思想平移到智能体治理中同样成立将完整决策链路拆分为三个独立域每个域只负责单一职责互相制衡任何一个域都无法独立完成「从风险判断到动作执行」的全流程。治理分支核心职能智能体对应域 认知感知评估现状、识别风险感知域请求性质判定、风险等级评估 规划决策制定方案、资源匹配规划域生成执行方案、选择最优路径⚡ 执行落地权限校验、动作执行执行域权限核验、沙箱执行、结果留存三域分离完整执行链路输出风险评估报告输出执行计划 资源清单用户请求 感知域风险评估 意图识别 规划域方案生成 路径选择⚡ 执行域权限校验 沙箱执行执行结果 审计记录审计点1感知结果留痕审计点2规划方案留痕审计点3执行动作留痕关键设计域间独立审计三个域之间不做黑盒透传每一次域间交互都是独立审计节点感知域审计记录感知结论规划域审计记录规划方案执行域审计记录执行结果事故复盘时可以精准定位问题根源是感知域误判风险高风险请求被判定为低风险还是规划域选择了错误方案高风险操作未走人工审核路径亦或是执行域越权操作权限校验失效导致越权执行三、工程落地三域分离架构实现方案核心网关骨架实现# 三域分离决策治理网关 简化演示代码# 仅展示核心调度逻辑非生产源码classTriDomainGovernor:三权分立决策引擎感知-规划-执行权责分离asyncdefprocess_request(self,request):# 第一域感知层仅做风险与意图判定perceptionPerceptionDomain()risk_reportawaitperception.analyze(request)# 第二域规划层仅做方案生成与选择plannerPlanningDomain()action_planawaitplanner.plan(request,risk_report)# 第三域执行层仅做权限校验与受控执行executorExecutionDomain()resultawaitexecutor.execute(request,planaction_plan,riskrisk_report)returnresult各域职责边界权责严格分离 感知域PerceptionDomain只做「判断」不做任何决策与执行。核心能力职责说明严格禁止意图分类识别请求属于查询/写入/删除/修改哪一类不决定是否执行风险打分评定风险等级低/中/高/严重不决定执行方案环境评估判断当前系统安全基线状态不分配系统资源异常检测识别请求中的可疑攻击模式不定义处置方式 规划域PlanningDomain只做「选择」不做风险判定与实际执行。核心能力职责说明严格禁止方案生成输出多套可行执行路径不判断请求合法性资源评估测算每套方案所需资源与代价不直接授予操作权限路径优选基于风险等级选择最优方案不触发任何真实操作⚡ 执行域ExecutionDomain最「死板」也最关键的一层只做权限校验与受控执行不修改方案、不评估合理性。核心能力职责说明严格禁止权限验证校验操作是否在授权范围内不判断请求逻辑是否合理安全执行在沙箱/受控环境中执行动作不擅自修改执行方案结果留存完整记录执行过程与结果不评估执行结果好坏完整流转示例邮件发送操作以「帮我给张三发一封会议纪要邮件」为例完整三域流转流程感知域判定意图邮件发送风险等级低目标对象张三在通讯录白名单内输出{risk: low, type: email_send, target: zhangsan}规划域选方案生成两套方案A直接发送高效、B生成草稿人工审核后发送安全基于低风险评级选择方案A输出{plan: A, required_resource: mail_api}执行域落地权限校验当前Agent具备邮件发送权限 ✅目标在允许联系人列表 ✅调用邮件API执行留存完整执行日志输出{status: success, timestamp: ..., audit_id: ...}四、工程实践落地取舍与踩坑经验理论上三域完全独立是最理想状态但实际落地必须平衡安全收益与工程代价。我们在实践中总结出三个核心取舍点1. 域间通信的折中方案完全物理隔离三个域会带来三个明显问题链路延迟上升三次域间交互叠加整体响应耗时增加计算冗余三个域可能重复解析请求上下文接口复杂度提升域间协议设计与维护成本显著上升落地折中方案域之间只传递结构化结论数据不透传原始请求完整上下文。既保证权责隔离又避免重复计算控制延迟增量在可接受范围。2. 边界模糊场景的拆分原则部分请求天然横跨多个域例如「根据我的历史记录提前准备好我可能需要的数据」同时涉及意图识别感知域、方案制定规划域、数据拉取执行域。处理原则将复合任务拆解为多个原子子任务每个子任务单独走完整三域流程不允许跨域合并执行。3. 错误精准归因能力三域分离最大的工程价值是实现故障精准定位。故障案例Agent 误删除了受保护的数据库记录 审计溯源 感知域正确判定为「数据清理操作风险中等」 ✅ 规划域选择了「直接执行」方案未走「先备份后清理」流程 ❌ 执行域按照方案正常执行权限校验通过 ✅ 结论故障根源在规划域策略缺陷而非感知误判或执行越权。 优化针对数据清理类请求强制启用备份前置校验规则。五、效果量化评估基于同一场景对照测试三域分离模式对比单域一体化模式的核心指标变化评估指标单域一体化模式三域分离模式变化趋势权限滥用风险发生率基准值下降 55%65%✅ 显著优化单请求处理延迟基准值上升 10%20%⚠️ 性能代价故障根因定位耗时数小时数分钟✅ 效率跃升系统架构复杂度低中高⚠️ 维护成本上升策略迭代灵活性低高可单域独立调整✅ 治理效率提升六、延伸思考题三域分离的「域」应该按功能模块划分还是按底层模型划分如果三个域复用同一个大模型底座是否能实现真正的权责独立在低延迟要求的实时交互场景中如何平衡三域分离的安全收益与性能代价哪些场景可以裁剪层级如果感知域被攻击者攻陷输出错误的风险评级规划域与执行域能否自主识别异常如何避免单域失守导致整条链路失效七、延伸阅读与专栏预告相关学术研究本专栏讨论的三域分离思想与学术界决策权限边界研究方向高度契合感兴趣可检索对应论文深入了解Bounding Decision Authority: Cognitive-Selection-Action Separation— 提出决策权责分离基础理论核心差异相关研究多强调自上而下的层级关系本文方案更侧重三域平行制衡的治理逻辑。专栏更新预告 上一期回顾【第1期】4C框架完整解读面向智能体AI安全四层防御体系 下一期预告【第3期】动态权限管理信任分级联动权限风险出现自动收缩操作边界版权声明: 本文为原创技术文章。欢迎规范转载请完整标注文章出处。