2. 权限控制架构总览：系统分层、模块边界、核心组件
Agent操作执行权限控制不是单一组件，而是一套分层防御体系。每一层负责独立的职责，层间通过明确定义的接口通信，形成从请求发起、策略判定、执行决策到审计追溯的完整链路。本章从全局视角拆解架构分层、模块边界与核心组件，为后续各章按层展开提供统一的参考框架。
2.1 系统分层模型
采用四层纵向划分，从上至下依次为接入层、策略层、执行层和审计层。每层仅依赖下层提供的服务，禁止跨层直接调用。
| 分层 | 核心职责 | 典型模块 | 对外暴露接口 |
|---|---|---|---|
| 接入层 | 接收Agent原始请求，进行身份认证与协议适配 | API Gateway、身份令牌校验、请求解析器 | REST/gRPC终端、WebSocket |
| 策略层 | 基于身份、上下文、资源三元组进行权限判定 | 策略引擎、策略仓库、条件评估器 | 内部RPC：Evaluate(Subject, Action, Resource) → Decision |
| 执行层 | 根据决策结果执行或拒绝操作，并实施资源隔离 | 执行沙箱、资源配额控制器、操作调度器 | 内部消息：ExecCommand(Op, Env) |
| 审计层 | 记录所有决策与执行事件，支持事后追溯与告警 | 审计日志收集器、策略变更追踪、异常检测 | 异步写入：LogEvent(event) |
分层边界原则：接入层不参与策略判定；策略层不直接触发执行；执行层不修改策略规则；审计层对上层只读。任何跨层穿透都视为架构违规。
2.2 模块边界与隔离单元
每个分层内部进一步划分为多个模块，模块之间通过服务接口或事件通道交互。模块边界由以下三个维度定义：
- 职责域：每个模块只负责一类原子能力。例如“策略引擎”只做规则匹配与运算，不负责规则存储。
- 生命周期域：模块可独立部署、升级、伸缩。策略层允许热加载策略库而不影响执行层。
- 信任域：模块间的交互必须通过签名的内部RPC或消息队列，防止身份伪造与重放。
典型模块边界划分示例：
# 策略层内部模块职责分配
模块：策略引擎
边界：接收 EvaluateRequest，返回 Allow/Deny + 约束
依赖：策略仓库（只读）、上下文解析器（读）
模块：策略仓库
边界：管理策略版本、存储、缓存
依赖：持久化存储（DB / 对象存储）
不依赖：任何执行模块
模块：条件评估器
边界：解析策略中的动态条件（时间、位置、资源属性）
依赖：外部身份系统、环境数据服务
2.3 核心组件及职责
整个架构由以下核心组件构成，每个组件在分层中扮演独立角色。
| 组件名称 | 所属分层 | 职责描述 | 关键数据/控制流 |
|---|---|---|---|
| 身份校验器 | 接入层 | 验证Agent令牌、OAuth2/OIDC token、mTLS证书 | 输入：原始请求 → 输出：Subject身份 |
| 请求转换器 | 接入层 | 将Agent操作请求解析为结构化Action+Resource对象 | 输入：HTTP/gRPC payload → 输出：Action, Resource, Context |
| 策略引擎 | 策略层 | 加载策略规则，基于Subject/Resource/Context计算决策 | 输入：评估请求 → 输出：Decision + 约束列表 |
| 策略仓库 | 策略层 | 存储、版本化、缓存策略规则，支持热更新 | 输入：策略变更事件 → 输出：策略快照 |
| 执行沙箱 | 执行层 | 在隔离环境中执行允许的操作，实施资源限制（CPU/内存/网络） | 输入：执行指令 + 约束 → 输出：执行结果 |
| 配额控制器 | 执行层 | 跟踪资源使用，防止Agent独占或滥用 | 输入：资源请求 → 输出：配额 Check 结果 |
| 审计日志器 | 审计层 | 收集决策、执行、策略变更事件，持久化存储 | 输入：LogEvent → 输出：结构化日志 |
| 异常检测器 | 审计层 | 基于日志分析异常行为（高频拒绝、越权试探） | 输入：日志流 → 输出：告警通知 |
2.4 数据流与控制流
一个完整的Agent请求处理流程包含三条关键链路：
- 请求主链路：Agent → 接入层（认证+转换） → 策略层（评估） → 执行层（沙箱执行） → 响应返回
- 策略更新链路：管理面板/CI → 策略仓库（写） → 策略引擎（缓存刷新） → 后续评估生效
- 审计链路：各层组件异步发送事件 → 审计日志器 → 异常检测器 → 告警/归档
风险点：审计链路若采用同步发送会影响主链路延迟；推荐使用无强可靠性的异步通道（如Kafka/Redis Stream），并在审计层内实现幂等写入。
2.5 信任链路与安全模型
层间信任建立在mTLS + 服务网格基础上，每个模块拥有独立的服务身份。关键信任规则：
- 接入层信任Agent请求中携带的令牌，但令牌本身必须由外部身份提供者签发。
- 策略层信任接入层传递的Subject身份，不信任原始请求中的自声明身份。
- 执行层信任策略层返回的决策，但执行沙箱额外校验决策是否包含有效签名。
- 审计层信任来自各层的事件，但事件必须包含发送方模块签名，防止伪造日志。
信任链路的关键验证点：
1. 接入层 → 策略层：传递调用者身份时，必须使用内部mTLS channel，且令牌在接入层完成验证。
2. 策略层 → 执行层：决策结果除了包含Allow/Deny，还附加策略引擎的数字签名，执行层验签后执行。
3. 审计层：接收事件时校验发送方证书，拒绝未签名事件。
2.6 选型权衡与对比
| 维度 | 选项A | 选项B | 适用场景 |
|---|---|---|---|
| 策略引擎实现 | 内置规则引擎（如OPA/Rego） | 自研条件匹配器 | A适合标准化策略；B适合高度定制化 |
| 执行隔离技术 | 容器沙箱（Docker/WASM） | 进程级 cgroup + seccomp | A适合多租户；B适合低延迟单租户 |
| 审计存储 | 关系数据库（结构化查询） | 对象存储 + 索引引擎（Elastic） | A适合小规模；B适合大规模日志流 |
建议：初期优先选用社区成熟的开源策略引擎（如OPA），将开发精力集中在执行沙箱与审计层。后期规模增长后，策略层可逐步替换为自研高性能引擎。
2.7 落地步骤（第2章视角）
完成架构总览后，后续章节将按以下顺序逐步实现：
- 接入层实现：选择网关框架（Envoy/Kong）并集成身份校验中间件（第3-4章）。
- 策略层搭建：部署策略引擎服务，定义策略数据结构与语法（第5-8章）。
- 执行层构建：实现沙箱环境，对接资源配额与隔离（第9-14章）。
- 审计层集成：配置事件通道，建立日志存储与告警规则（第15-18章）。
- 端到端联调与安全测试：验证信任链路、边界隔离与异常处理（第19-22章）。
- 生产加固与运维：热更新、监控、容量规划（第23-30章）。
2.8 验收标准
架构总览阶段的验收标准确保后续各章设计不偏离全局框架：
- 分层完整性检查：每个操作请求必须经过接入层→策略层→执行层（不允许跳过任何一层）。
- 边界隔离检查：任何模块的Java/.NET/Go二进制中不得出现跨层API的直接调用（通过代码审查+架构检视）。
- 信任链路验证：在测试环境中注入伪造令牌、篡改决策结果、伪造日志事件，系统必须全部拒绝并记录。
- 数据流一致性：审计日志中每条记录的请求ID必须能被追溯到接入层的原始请求ID。
- 组件职责映射：所有核心组件（8个）均已绘制在SVG架构图中，且职责描述与文本一致。