在之后每个阶段的博客中，如果我没有特别说明的话阶段内任意两篇文章都是可以并行运行的，有先后顺序的情况我会在开头进行说明。
当前 ManiMind 的默认角色一共 8 个：
lead
explorer
planner
coordinator
html_worker
manim_worker
svg_worker
reviewer它们不是平级随便聊天的 Agent，而是被三种 AgentMode 约束：read_only、structured_write、verify_only。也就是有的角色只能读和分析，有的角色能写结构化产物，有的角色只能审核。仓库文档明确列出了这 8 个默认角色，并说明每个角色都有 allowed_stages、required_inputs、owned_outputs、output_contract 四类约束。
1. Lead：项目总控 / 状态维护者
lead 是全局负责人。它负责维护项目状态、汇总上下文、推进阶段切换。
它主要管：
输入归档
研究总结
术语表
公式目录
资产清单
阶段推进它不是所有内容都自己生成，而是负责把项目维持在一个“可继续推进”的状态里。代码里的职责描述是：维护项目全局状态、汇总上下文并推进阶段切换；输出契约是只能写结构化项目状态，不直接替代所有媒体子任务。
你可以把它理解成：
Lead = 项目经理 + 总编辑 + 状态管理员2. Explorer：资料探索者
explorer 是只读角色，不能写正式产物。
它主要做：
查论文
查代码
查参考资料
查第三方资产
给出候选引用和发现它的价值是“找材料”，不是“定稿”。所以它的模式是 read_only。代码中它的职责是只读检索论文、现有代码与第三方资产中的相关模式，输出契约是不直接落盘项目产物。
你可以把它理解成：
Explorer = 资料检索员 / Research Assistant3. Planner：规划分析者
planner 也是只读角色。
它和 explorer 的区别是：explorer 偏找资料，planner 偏做方案判断。
它主要做：
分析约束
提出分镜建议
提出实现路线
评估哪段适合 HTML / Manim / SVG但它不能直接写正式分镜。正式脚本和分镜要由 coordinator 写入结构化上下文。代码中它的输出契约也明确写着：只能产出规划建议，正式分镜需由协调层写入结构化上下文。
你可以把它理解成：
Planner = 策划顾问 / 方案设计者4. Coordinator：协调者 / 脚本与分镜落地者
coordinator 是核心写入角色之一。
它负责把前面的研究总结、术语表、公式目录、风格要求，真正转成：
讲解脚本
分镜
任务分发表
session.handoff它是从“想法”进入“可执行任务”的关键角色。没有 coordinator，系统会停留在研究和规划阶段，无法进入多 worker 分发。
你可以把它理解成：
Coordinator = 主编 + 分镜导演 + 任务调度员它的位置大概是：
research.summary / glossary / formula.catalog / style.guide
↓
coordinator
↓
narration.script / storyboard.master / session.handoff
↓
HTML / Manim / SVG workers5. HTML Worker：HTML 科普片段执行者
html_worker 负责生成 HTML 交互式科普片段。
适合处理：
交互说明
网页式演示
可视化小组件
滚动叙事
公式旁白解释卡片它只能写 HTML 相关产物，不能越权去改 Manim 或 SVG 产物。代码里的输出契约也明确限制它只负责 HTML 片段及其回传说明。
你可以把它理解成：
HTML Worker = 前端动效 / 交互科普片段生成器6. Manim Worker：数学动画执行者
manim_worker 是数学动画核心执行者。
它负责：
公式动画
几何动画
坐标系动画
函数图像动画
推导过程动画
Manim 代码生成如果某个 segment 是 MANIM 或 HYBRID，或者这个片段里有公式，系统就会派发 Manim 任务。build_worker_tasks 里已经写了这个逻辑：如果片段 modality 是 Manim / Hybrid，或者存在 formulas，就创建 Manim worker task。
你可以把它理解成：
Manim Worker = 数学动画工程师这是 ManiMind 里最核心的执行工种之一。
7. SVG Worker：补充动效执行者
svg_worker 负责 SVG 局部动效。
适合处理：
图标动画
矢量示意图
路径动画
局部标注动画
轻量级结构图
非 Manim 的补充视觉元素如果片段 modality 是 SVG 或 HYBRID，或者 requires_svg_motion=True，系统就会派发 SVG worker task。
你可以把它理解成：
SVG Worker = 矢量动效工程师它和 Manim Worker 的边界是：
Manim：数学推导、公式、坐标系、几何变换
SVG：轻量图形、标注、流程、局部视觉辅助
HTML：网页交互、滚动叙事、综合展示8. Reviewer：审核者
reviewer 是验证角色，不参与内容生产。
它负责审核：
数学正确性
叙事与分镜一致性
渲染可执行性
结构化产物完整性
是否允许进入后处理它的模式是 verify_only，只能输出审核结论，不能参与内容生产。代码里也明确写了：审核未通过前禁止进入后处理。
你可以把它理解成：
Reviewer = 数学审稿人 + 质量门禁总体角色关系
可以这样画：
┌──────────────┐
│ Lead │
│ 项目总控/状态 │
└──────┬───────┘
│
┌────────────────┼────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Explorer │ │ Planner │ │ Coordinator │
│ 资料探索 │ │ 方案规划 │ │ 脚本/分镜/分发│
└─────────────┘ └─────────────┘ └──────┬───────┘
│
┌────────────────────────┼────────────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ HTML Worker │ │Manim Worker │ │ SVG Worker │
│ HTML片段 │ │ 数学动画 │ │ SVG动效 │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────────────┼────────────────────────┘
│
┌──────▼──────┐
│ Reviewer │
│ 审核/阻塞/放行│
└─────────────┘按职能分层
更适合研发会讲法是把 8 个角色分成 4 层：
第一层：总控层
- lead
第二层：研究与规划层
- explorer
- planner
第三层：协调分发层
- coordinator
第四层：执行与审核层
- html_worker
- manim_worker
- svg_worker
- reviewer最核心的设计思想
这个角色系统不是为了“多弄几个 Agent 显得复杂”，而是为了把权限边界切清楚：
谁能读？
谁能写？
谁负责哪个阶段？
谁拥有哪个输出？
谁有权推进任务？
谁有权阻塞后处理？所以 ManiMind 的角色设计本质上是一个带权限边界的内容生产流水线：
Lead 维护状态
Explorer 找资料
Planner 出建议
Coordinator 落成脚本和分镜
HTML / Manim / SVG Worker 生成具体片段
Reviewer 审核并决定是否放行一句话概括：
ManiMind 当前一共 8 个默认角色，核心不是“八个聊天机器人”，而是“一个项目总控、两个前期智囊、一个协调分发者、三个媒介执行者、一个审核门禁”组成的闭环生产体系。