角色定义与协作流程
一、四角色分工模型
框架定义四个核心角色，相互独立、各司其职，形成完整的协作闭环。
1. 数据分析 Agent（DataAnalyst）
| 属性 | 说明 |
|---|---|
| 定位 | 分析大脑与框架制定者 |
| 核心职责 | 设计分析框架、拆解任务、制定需求清单、汇总结果、提炼洞察 |
| 专业背景 | 资深数据分析师，具备统计学、业务理解与报告撰写能力 |
| 产出物 | 业务分析框架文档、阶段性方案、分析报告、优化建议 |
| 关键原则 | 仅输出文档，不执行代码、不访问数据 |
2. 脚本编写 Agent（ScriptWriter）
| 属性 | 说明 |
|---|---|
| 定位 | 代码实现者 |
| 核心职责 | 根据方案编写最小可执行脚本（MVP Script） |
| 产出物 | 可执行的 Python 脚本 |
| 关键原则 | 仅生成代码，不执行、不访问真实数据；严格遵循方案实现 |
3. 审阅 Agent（Reviewer）
| 属性 | 说明 |
|---|---|
| 定位 | 质量门禁 |
| 核心职责 | 核查脚本与方案一致性，识别新增、遗漏或偏差 |
| 产出物 | 一致性审阅报告 |
| 关键原则 | 不修改代码、不执行、仅对比检查；保持独立客观 |
4. 人工环节（Human）
| 属性 | 说明 |
|---|---|
| 定位 | 安全闸门与最终决策者 |
| 核心职责 | 数据安全、脚本执行、结果判定、最终确认 |
| 关键原则 | 所有数据操作由人工完成；Agent 不接触原始数据 |
二、六阶段协作流程
整个流程从框架制定到最终沉淀，经过如下标准阶段：
阶段 1：业务流程框架制定（DataAnalyst）
输入：业务流程、背景知识、数据结构（脱敏后）、分析需求
输出：业务流程框架文档（Markdown）
此阶段的目标是明确分析范围、输入输出定义与总体逻辑，为后续阶段提供方向指引。框架文档应包含：
- 分析策略与核心思路
- 分阶段的任务定义
- 关键指标体系
- 数据口径与约束条件
阶段 2：阶段性方案制定（DataAnalyst）
基于业务框架，制定每个阶段的具体任务与需求清单。方案文档需要足够详细，让 ScriptWriter 能够直接理解并生成脚本。
重点产出物：
- 分析目标：明确要回答的核心问题
- 需求清单：Checklist 格式，列出每个需要计算的信息项
- 输出检查清单：明确预期输出的文件格式和路径
- 注意事项：数据口径、计算逻辑、边界条件
阶段 3：脚本编写与执行（ScriptWriter + Human）
- ScriptWriter 根据方案文档生成可执行脚本
- Human 在本地安全环境中执行脚本
- 若执行异常，Human 反馈给 ScriptWriter 修正
- 遵循最小可行性原则，脚本只做方案要求的事
阶段 4：一致性审阅（Reviewer）
Reviewer 对比 方案要求 vs 脚本实现 vs 执行结果，检查：
- 步骤完整性：是否遗漏方案要求的步骤
- 严格执行性：是否严格遵守脚本指令
- 需求覆盖：是否满足所有明确需求
- 输出格式：是否符合规定格式
输出审阅结论（✅/⚠️/❌）和修正建议。
阶段 5：阶段分析与框架优化（DataAnalyst）
汇总本阶段的执行结果，输出阶段分析报告，并基于新发现调整业务框架。这体现了框架的动态进化能力，而非一次性固定不变。
阶段 6：最终汇总与知识沉淀（DataAnalyst + Human）
整合所有阶段成果，形成完整的分析报告。最终的业务框架文档作为可复用的知识模板沉淀下来。
三、文档驱动机制
为什么选择 Markdown？
- 普适性：几乎所有的 AI 工具和代码平台都支持
- 结构化：天然支持标题、列表、表格、代码块
- 可追溯：文本格式便于 diff、版本控制和审阅
- 轻量：无需特殊工具，任何文本编辑器都可处理
文档驱动的核心原则
- 统一信息载体：所有 Agent 通过 Markdown 交互，不依赖工具调用链
- 单向依赖：下游 Agent 依赖上游输出的文档，形成清晰的信息流
- 版本可见：每次修改都产生新的文档版本，过程可回溯
- 即归档：每个阶段的产出就是归档内容，无需额外整理
文档类型汇总
| 文档类型 | 生产者 | 消费者 | 作用 |
|---|---|---|---|
| 业务框架文档 | DataAnalyst | DataAnalyst | 定义整体分析方向 |
| 阶段方案文档 | DataAnalyst | ScriptWriter | 提供可执行的方案 |
| 执行脚本 | ScriptWriter | Human | 生成分析结果 |
| 执行结果摘要 | Human | Reviewer | 展示分析结果 |
| 审阅报告 | Reviewer | Human | 反馈一致性问题 |
| 阶段分析报告 | DataAnalyst | Stakeholder | 呈现分析洞察 |
| 最终报告 | DataAnalyst | 业务方 | 完整分析结论 |
四、关键设计解读
为什么 ScriptWriter 不执行代码？
这是框架最核心的设计决策之一：
- 数据安全：Agent 无法接触原始数据
- 结果可控：人类对执行过程有完全控制权
- 错误隔离：脚本错误不会直接影响数据环境
- 合规要求：满足数据隐私和安全合规要求
为什么需要独立审阅角色？
- 避免视角盲区：方案制定者和代码实现者容易形成思维定式
- 质量门禁：在结果交付前多一层质量保障
- 经验积累：审阅发现的问题可以反哺 Rule 和模板的改进
为什么强调"最小可执行"？
- 降低出错概率：每段脚本只做一件事，复杂度可控
- 便于审阅：小段代码更容易检查和验证
- 快速迭代：小步快跑，有问题及时修正