OpenClaw Agent 速查表（6 角色）

这张表回答三个问题：

1. 每个 agent 擅长什么？
2. 什么时候该用它？
3. 在你这套配置里，它通常以哪种调度形态运行：multi-agent（固定角色协作） 还是 sub-agent（按需临时拉起的子代理）？

总览速记

• main：总控/统筹/落盘（把事推进到“交付”）
• writer：写作成文（对外表达/公众号/复盘）
• code：写代码与实现（脚本/项目/重构）
• executor：执行跑活（跑命令、批处理、按清单执行）
• ai-research：调研对比（带引用、结论与建议）
• debug：排障定位（日志、根因、修复路径）

---

速查表

Agent	擅长干啥	什么时候该用	调度形态（multi-agent vs sub-agent）	怎么调用（对我说的话术）
main	总控/统筹：拆任务、定优先级、串联多步骤、把关键结果落盘到 Vault	你不确定怎么做；需要从目标→方案→落地的一条龙；需要跨工具协调	multi-agent 主控位：长期常驻，用来路由其它角色；也会按需拉起 sub-agent 承接重活	“用 main 帮我把这事拆成步骤并落盘到 Obsidian” / “你作为 main 统筹，把 A→B→C 跑通”
writer	写作与表达：公众号长文、结构化文章、润色、人话改写、复盘总结	需要对外稿件/文章；需要更顺的叙事与标题小节；素材多且散	multi-agent 固定角色：通常作为专职写作角色被切换调用；也可能被 main 调度来产出终稿	“用 writer 把这段整理成公众号文章，语气更像人写的” / “writer 给我 3 个标题 + 开头”
code	代码实现：写脚本、做功能、重构、读代码后给出可运行改动	要真正落地实现；要写可执行脚本（如 inbox 自动整理）；要改仓库	multi-agent 固定角色：面向工程实现；遇到大工程也可能由 main 拉 sub-agent（ACP coding harness）来并行写	“用 code 把这个方案实现成脚本/项目（含 README）” / “code 帮我把 XX 功能写出来并给 diff”
executor	执行型操作：跑命令、批处理、搬运文件、生成报表、按明确指令落地	方案已定只差执行；要批量动作；要把 code 产物跑起来验证	sub-agent 倾向：更像临时工位（按清单执行一轮）；也可作为 multi-agent 的执行角色被 main 频繁调用	“用 executor 按这个清单执行：1…2…3…” / “executor 帮我批量把这些文件改名/移动”
ai-research	调研与对比：最佳实践、论文/文章、竞品分析、技术选型对比（给引用）	还在选方案；不确定最佳实践；需要证据、引用、对比表	sub-agent 倾向：典型是 main 拉起一个“研究子代理”做资料搜集与综述，然后主控汇总决策	“用 ai-research 调研：A vs B 的最佳实践，给引用链接+结论”
debug	排障定位：命令报错、配置不生效、环境问题、权限/依赖、自动化为什么没跑	出错/不符合预期；需要快速定位根因；需要一步步验证与修复	sub-agent 倾向：常被 main 按需拉起做诊断；问题解决后即可结束，不长期占用上下文	“用 debug 帮我排查：为什么 cron 没触发/为什么写入失败（附日志）”

---

典型协作套路（按你这套配置的“主控 + 子代理”模型）

1. ai-research（子代理） → main（汇总决策） → code（实现） → executor（执行验证） → writer（对外成文）

2. main → writer

• 你给素材，我直接统筹并成文落盘。

3. main → debug（子代理） → code → executor

• 先定位根因，再修复并验证。

---

备注：如何理解 multi-agent vs sub-agent

• multi-agent（固定角色协作）：你手头有一组“常驻角色”（main/writer/code…），你在不同任务阶段切换角色，或由 main 路由给它们。
• sub-agent（按需临时拉起）：当任务重、需要并行、或需要隔离上下文（尤其是研究/排障/大规模改动）时，临时拉起一个子代理做一件事，做完就结束。

在实践里，两者会混用：

• 角色清晰 → 用 multi-agent
• 需要隔离/并行/重活 → 用 sub-agent