数据安全与人工在环机制
一、设计背景
在企业数据分析场景中，数据安全是不可妥协的底线。传统 AI 辅助分析工具往往需要 Agent 直接访问数据，这在涉及敏感业务信息的环境中存在显著风险。本框架将数据安全作为首要设计原则，而非事后补充。
二、安全三原则
原则一：Agent 不访问真实数据
所有 Agent（包括数据分析 Agent、脚本编写 Agent、审阅 Agent）均不直接接触原始数据。
实现方式：
- Agent 仅接收脱敏后的元数据描述（字段名、类型、统计特征）
- Agent 生成脚本，但脚本在 Agent 环境中仅作为文本输出
- 真实数据的读取和执行完全在人工环境完成
原则二：Agent 不执行代码
任何代码的执行都必须在人工可控的环境中进行：
Agent 生成脚本（文本）
↓
人工审查脚本
↓
人工在本地环境执行
↓
人工将结果反馈给 Agent
这样设计的原因：
- Agent 执行环境可能存在安全漏洞
- 数据可能被 Agent 服务端缓存/记录
- 人工执行可以在执行前发现脚本中的问题
原则三：全链路留痕可追溯
每个环节的产出物都以文档形式保存，确保可以在任意时间点回溯：
| 环节 | 留痕内容 | 形式 |
|---|---|---|
| 方案制定 | 分析方案文档 | Markdown |
| 脚本编写 | 可执行脚本 | .py 文件 |
| 脚本执行 | 执行结果摘要 | Markdown + Excel |
| 审阅 | 一致性审阅报告 | Markdown |
| 阶段分析 | 阶段分析报告 | Markdown |
| 最终汇总 | 完整分析报告 | Markdown |
三、人工在环（Human-in-the-Loop）机制
关键介入节点
框架在以下节点强制要求人工介入：
业务流程框架制定 → DataAnalyst 自动完成，人工确认
↓
阶段性方案制定 → DataAnalyst 自动完成，人工确认
↓
脚本编写 → ScriptWriter 自动完成
↓
本地执行 → 人工在本地执行 ← 关键安全节点
↓
一致性审阅 → Reviewer 自动完成，人工最终判定
↓
阶段分析与优化 → DataAnalyst 自动完成，人工确认
↓
最终汇总 → DataAnalyst 自动完成，人工发布
人工在每个节点上的职责：
| 节点 | 人工角色 | 决策内容 |
|---|---|---|
| 框架确认 | 业务决策者 | 分析方向是否正确的？框架是否符合业务需要？ |
| 方案确认 | 业务分析师 | 方案逻辑是否完整？需求清单是否全面？ |
| 脚本执行 | 执行者 | 脚本是否安全？执行结果是否正常？ |
| 审阅确认 | 质量门禁 | 审阅结论是否接受？是否需要重新执行？ |
| 阶段确认 | 项目负责人 | 阶段分析是否有价值？方向是否需要调整？ |
| 最终发布 | 业务负责人 | 结论是否可信？是否可以用于决策？ |
人工与 Agent 的协作节奏
实践中总结出的经验：
- 前期（框架 + 方案）：人工需要较多投入，确保方向正确
- 中期（脚本 + 执行 + 审阅）：人工主要参与"执行"节点，其他环节由 Agent 自动完成
- 后期（分析 + 汇总）：人工以"审阅者"角色介入，高效验收成果
一个典型阶段的人工耗时约 20 分钟，其中主要时间花在阅读和确认上，而非技术操作。
四、数据脱敏与反脱敏
脱敏策略
在将数据信息提供给 Agent 前，必须完成脱敏处理：
原始数据（含真实客户名、产品名等）
↓
脱敏处理（映射为编号/代称）
↓
脱敏数据（提供给 Agent 用于分析）
↓
Agent 生成分析结果（基于脱敏数据）
↓
反脱敏处理（将结果映射回真实标识）
↓
业务结论（真实标识，可直接使用）
映射管理
实践中使用 JSON 格式维护脱敏映射表：
{
"脱敏名称1": "真实名称1",
"脱敏名称2": "真实名称2",
...
}
映射表本身作为敏感信息，不提供给 Agent。
反脱敏脚本
反脱敏逻辑通常较为简单，本质是查表替换。由 ScriptWriter 生成反脱敏脚本，人工执行后将分析结论恢复为可直接用于业务决策的形式。
五、一致性审阅机制
审阅是保障执行质量的关键环节。Reviewer 的核心工作是对比 三个对象：
┌────────────────────────────────────────────────┐
│ 一致性审阅 │
│ │
│ 方案方案文档 ───── 对比 ──── 执行脚本 │
│ │ │ │
│ └──────── 对比 ──────────┘ │
│ │ │
│ 执行结果摘要 │
└────────────────────────────────────────────────┘
审阅维度
| 维度 | 检查内容 | 示例 |
|---|---|---|
| 步骤完整性 | 是否遗漏方案要求的所有步骤 | 方案要求 3 项指标，脚本只算了 2 项 |
| 严格执行性 | 是否严格遵守方案定义的计算口径 | 方案要求不去重，脚本做了去重 |
| 需求覆盖 | 是否有多余实现或缺失实现 | 脚本额外计算了方案未要求的指标 |
| 输出格式 | 结果是否符合规定的格式规范 | 输出路径不对、文件格式不符 |
审阅报告结构
### 审阅结果
- 一致性结论：✅ / ⚠️ / ❌
- 步骤完整性：[描述是否有遗漏]
- 严格执行性：[描述是否严格遵守]
- 需求覆盖：[是否有新增或缺失]
- 输出格式：[是否符合规范]
### 修正建议
[仅在必要时提供简短操作建议]
实践中发现的典型问题
- 命名不一致：文档中提到的指标名和脚本中的变量名不一致
- 边界条件处理：空值、零值等边界情况未按方案要求处理
- 计算口径差异：脚本实现与方案定义的算法有细微差异
- 输出格式偏差：输出文件的列名、格式与方案要求不完全匹配
六、安全 Checklist
在实际执行多 Agent 协作分析前，建议逐项确认：
← 上一章：Prompt 与 Rule 工程实践 | Multi-Agent协作框架-MOC | 下一章：完整流程复现示例 →