4. 边界分层模型

Agent 与用户之间的交互不是单层协议，而是由展示层、交互层、决策层、执行层构成的四层边界。每层承载独立的职责与信任假设，层间通过标准化接口进行隔离。本章定义各层的边界划分、接口规范、数据流与安全策略，并给出落地步骤与验收清单。

4.1 四层职责与边界定义

4.2 层间接口规范

每一对相邻层之间定义严格的契约，使用 JSON Schema 或 Proto 描述，部署时生成校验桩。以下为展示层→交互层接口的伪代码定义（非实际实现）：

// 展示层 → 交互层 接口契约
Interface PresentationToInteraction {
  // 输入字段
  userId: string
  sessionId: string
  channelType: "web" | "voice" | "api"
  payload: {
    rawText?: string
    structuredForm?: Record<string, any>
    // 仅允许枚举类型，避免注入
    command?: "query" | "confirm" | "cancel"
  }
  // 输出（回调）
  ResponseCallback: (output: PresentationOutput) => void
  ErrorCallback: (errorCode: string, detail: any) => void
}

4.3 信任链路与权限模型

信任链自顶向下逐层衰减：展示层信任用户输入格式；交互层信任展示层已经做过基础清洗；决策层只信任交互层给出的意图，不信任原始输入；执行层信任决策层给出的计划，不信任上层传来的敏感参数。

权限校验集中在决策层入口。规则示例：

// 决策层权限检查伪规则
Rules:
- Role=admin → 可执行任何 ExecutionPlan
- Role=viewer → 仅允许只读 Intent（query类型）
- 高风险操作（文件删除、转账） → 必须附带二次确认 token
- 所有拒绝记录到 AuditLog，触发安全告警

4.4 异常处理与安全策略

各层独立处理本层异常，不得将底层异常细节暴露给上层。异常处理边界如下：

安全策略聚焦于层间传输：

• 展示层→交互层：必须启用 CSRF/API Token 验证
• 交互层→决策层：修改源 IP 白名单，禁止公网直接调用
• 决策层→执行层：必须使用短时效 HMAC 签名，防止重放
• 全链路：记录每条跨层消息的完整性哈希

4.5 分层架构总览

以下 SVG 展示四层边界及层间接口数据流。节点颜色对应各层职责：

4.6 方案权衡

4.7 落地步骤与验收标准

• 步骤1：绘制当前 Agent 的交互边界图，标注现有混合层的职责混乱点。
• 步骤2：按本章四层模型重构代码模块，每个层独立为命名空间或微服务。
• 步骤3：为每对相邻层编写接口 Schema（JSON Schema 或 Protobuf），并生成校验桩。
• 步骤4：在决策层入口集成权限校验与审计日志。
• 步骤5：配置层间超时熔断（默认：展示层→交互层 5s，交互层→决策层 10s，决策层→执行层 30s）。
• 步骤6：部署监控探针，统计每层 P99 响应时间与错误率。

验收检查清单：

1. 所有跨层调用均经过契约校验，契约变更必须双方确认。
2. 执行层不产生新决策，仅执行由决策层下发的计划。
3. 展示层不包含任何权限判断逻辑。
4. 违反信任链的行为（如执行层直接使用用户原始输入）被监控捕获并告警。
5. 层间异常不泄漏堆栈细节给上层。
6. 审计日志可追踪每条用户请求的完整四层流转路径。