让 AI 智能体做大事，第一步是把大任务拆成小任务，拆到多小就是拆解粒度。粒度太粗，一个子任务里塞了五件事，专员做不完整；粒度太细，拆出一百个碎步骤，光协调就把预算耗光了。找合适的粒度，是多 Agent 系统设计里最见功力的一步。
类比搬家：你说「把家搬走」太粗，说「先抬左脚再抬右脚」是笑话，合适的说法是「厨房一车、卧室一车、易碎品单独一车」。
把一件事切到多大
经验上有三条标准。一是单一目标：一个子任务只追求一个可验收的结果，「收集资料并写完初稿」就是两件事，要拆开。二是独立可验：子任务做完后，不需要看别的子任务就能判断它做得对不对。三是一次执行：一个专员在一轮工作里能从零做完它，中途不需要别人插手。
三条全满足，粒度就基本合适；任何一条不满足，要么再拆，要么合并。
切太粗与切太细的两种翻车
切太粗的翻车方式：上下文超长，专员读到后面忘前面；一步出错，整块返工，重来一遍既慢又费。切太细的翻车方式更隐蔽：子任务之间交接频繁，每交接一次都要传背景、对格式，协调开销超过干活本身，而且主管要盯的状态数量暴增。
用 Kimi 或豆包做长报告时能直观感受这一点：让它「写完整本书」几乎必然烂尾，让它「先出十节提纲、每节单独成文」就稳得多——十节这个数字，就是粒度本身。
粗、细、刚合适三种状态，症状和处置并排看。
| 粒度状态 | 典型症状 | 怎么调 |
|---|---|---|
| 切太粗 | 上下文超长，专员读到后面忘前面；一步出错整块返工 | 再拆一层 |
| 切太细 | 交接频繁，协调成本超过干活本身；主管要盯的状态暴增 | 合并回去 |
| 刚合适 | 单一目标、独立可验、一次执行三条全满足 | 保持，靠检查点微调 |
拆完再验一遍
拆解不是一次到位的动作，要留检查点。主管每收到一份汇报，可以顺手评估：这个子任务是不是太容易（说明可以合并）、是不是反复失败（说明该再拆或换路）。粒度是调出来的，不是一次想清楚的。
还有一种动态拆法：先粗拆三层，执行时哪一层卡住，再把那一层临时拆细。这比一开始就拆到最细更省，因为大部分任务并不是每一块都难。
类比哪里失效：拆完还能自动合并
人类把活拆细之后，合并要靠人开会统筹；智能体系统里合并可以由主管自动完成，汇总、改写、去重都是程序动作。所以机器世界的粒度可以比人类团队更细一点，因为协调成本比人低。
但失效的另一面是：机器不会因为「分工看起来合理」而更卖力，粒度再漂亮，验收标准写不清，专员照样交付不了。粒度解决的是「分」，验收解决的是「合」，两头都要硬。
走之前带走的一句话
粒度合适的标志是：每个子任务用一句话就能说清「做什么、怎么算做完」。说清了就是好粒度；要靠「你懂的」和口头补充才能交代明白，说明还没拆到位。
粒度判断三问
- 单一目标吗？一个子任务只有一个验收点
- 独立可验吗？不看邻居任务也能判断对错
- 一次执行吗？一个专员一轮工作能干完
拆完提纲后，逐条过这三问，两条不满足的那一条，就是下一步要动的对象。
相关词条：子任务怎么递出去，见什么是 Agent 间通信？交接与汇报；拆好的任务放哪，看什么是共享工作区？多 Agent 的白板；执行全程怎么盯，参考什么是 Agent 可观测性？盯住执行过程；拆解质量怎么统一检验，见什么是评测套件？Agent 能力的考卷。
换个问法再问拆解粒度三句
- 任务数量有没有推荐区间？：没有硬数，但经验上单层五到十个子任务最稳，超过就得考虑分层，否则主管的注意力先撑不住。
- 粒度和模型能力有关吗？：有关。能力强的模型可以吃更粗的粒度，能力弱的要拆得更细，所以换了模型，粒度也要跟着重调。
- 拆错了能中途改吗？：能，这正是要留检查点的原因，主管可以在执行中合并、再拆或改派，粒度本来就该是动态的。
