动态策略网关：给 fix-system-agent 加上会话级工具权限编排

 
适配 gitcode.com/agent-best-practices/fix-system-agent 项目，配套今天可提交的 Issue，文风社区技术博客，偏架构思考
 
前言
 
当前 fix-system-agent 的工具权限大多是静态绑定：Agent 初始化时加载固定工具列表，要么全开放，要么直接禁用。在故障修复场景里，这个模式有明显的矛盾：排查问题时需要足够多的诊断工具，但是写入、删除、变更配置这类高危操作，一旦放开，很容易因为模型幻觉、prompt 注入、上下文漂移引发不可逆的系统改动。
 
很多 Agent 框架把权限控制写在 prompt 提示词里，这是一种很脆弱的方案。提示词可以被绕过，模型本身不适合做确定性的安全裁决。真正可靠的防线，应该独立于 LLM，放在工具调用入口层，也就是我们常说的工具网关。
 
现有方案痛点
 
1. 权限粒度是会话全局的：一次会话一旦开启，工具集全程不变。前期排查只需要  ls 、 cat 、 curl  这类只读诊断工具，后期确认修复方案才需要修改配置；现在只能一次性全部放行，或者反复重启会话切换配置。
2. 风险分级缺失：没有对工具做风险标签，无法区分只读查询、状态变更、高危销毁操作。
3. 审批链路粗粒度：要么全部自动执行，要么每一次调用都人工确认，缺少“同类操作批量授权、限时临时权限”的能力。
4. 审计链路不绑定策略：日志只记录工具调用结果，缺少“本次调用通过哪条策略放行、临时授权有效期、授权人”等策略元信息。
 
设计思路：会话绑定的动态策略网关
 
核心思想：工具权限不是在 Agent 启动时静态下发，而是在会话生命周期内，由策略引擎根据上下文状态、风险等级、人工审批结果动态编排。
 
整体拆成四层：
 
1. 工具元数据层：给每个工具打标签，风险等级（低/中/高）、副作用类型（只读/变更/销毁）、资源作用域、参数白名单校验规则。例如  get_log  低风险只读， restart_service  中风险变更， rm -rf  高风险销毁。
2. 策略引擎层（Policy-as-Code）：加载规则文件，支持默认基线策略、会话临时策略、用户自定义策略。基线策略默认只放行低风险只读工具；中高风险工具默认拦截，进入审批队列。
3. 授权与生命周期层：支持三种授权模式
- 单次授权：仅允许本次工具调用
- 会话限时授权：比如 10 分钟内允许执行一类变更工具，超时自动回收
- 条件授权：满足上下文条件时自动放行（例如仅在测试环境、仅针对指定服务名）
4. 审计与观测层：每一次 tool call 都附加策略判定结果、授权凭证、有效期，和链路追踪 ID 绑定，方便事后回溯。
 
关键原则：LLM 的 tool call 只是意图申报，最终能不能执行，由网关做确定性判定，模型无权绕过策略。
 
适配 fix-system-agent 的落地细节
 
fix-system-agent 定位是系统故障修复智能体，场景天然分为「故障排查阶段」和「修复执行阶段」。
 
- 排查阶段：基线策略自动放行日志读取、状态查询、网络探测等只读工具，无人工打扰；
- 当 Agent 第一次调用变更类工具时，网关拦截，抛出标准化审批请求，附带工具参数、预期影响、目标资源；
- 运维确认授权后，下发限时策略，会话内一段时间内允许同类操作；
- 会话结束或者授权超时，权限自动回收，不留长期权限窗口。
 
同时策略可以和上下文快照能力联动（就是我们之前聊的上下文隔离快照）：每次授予高危权限前，自动生成工作区快照，一旦变更引发问题，可以一键回滚。
 
权衡与取舍
 
- 不追求无限灵活：策略规则做强类型校验，拒绝通配符式宽泛权限，守住最小权限底线；
- 不引入过重组件：优先内置轻量策略引擎，兼容简单 YAML 规则，后期再对接外部 OPA 等策略引擎；
- 避免审批疲劳：区分风险等级，低风险免审，中风险限时授权，高风险强制单次审批，平衡安全和效率。
 
后续可扩展方向
 
- 基于历史工单、运维知识库做风险预评估，给工具调用自动打分，辅助人工审批；
- 策略漂移检测：监控 Agent 会话内权限调用模式，识别频繁越权尝试、异常工具序列；
- 多租户隔离：不同主机、不同业务集群绑定独立策略集，防止横向越权。