一句话：先顺着业务本身的缝切成块，再看一个人能管几块、把块分下去，最后检查有没有"两家都管"和"谁都没管"。
一、任务的划分（切在哪）
（1.1）业务级任务：按业务切
一个业务一个任务，以业务之间的天然界限作为任务之间的界限。
- 这是客观约束，只能发现，不能发明。同一个词在两处含义不同（"客户"在销售是潜在客户，在结算指付款主体）、数据各有主人、事务边界天然如此——这些缝在写第一行代码之前就存在了。
- 判据：这件事能不能独立说清"做成什么样算完成"。
（1.2）流程级任务：业务内部按工作流切
在单个业务级任务内部，按实际工作流程切，如"查询数据 → 处理数据 → 输出结果"切成三个流程级任务。
- 这是设计选择，可粗可细，切错成本低，改了就行（业务缝切错是要还债的）。
- 切点必须落在流程的天然交接口上：上一段交出去、下一段接收进来的那个东西，必须说得清是什么、什么格式。
（1.3）两条硬规矩（对 1.1 和 1.2 都适用）
- 不能重叠：一块地的责任只能有一个主人，不能让两个 Agent 都能改。
- 不能留空：所有块拼起来必须盖满整件事，不能有悬空的活。
- 只能向上并，不能向下劈：一个 Agent 可以管 1 个或多个完整任务，但不能只接管某个任务的 60%。
- 判据：抓住一个 Agent 问"你这份活做完了、做对了，能自己说了算吗？"必须跑去问别人 → 就是被劈开了。
（1.4）共享的东西不切
用户、权限、账务这类所有业务都要用的，切给任何一家都是埋雷。认一家提供，别家只读引用。
二、任务的分配（派给谁）
分配的判断顺序，就是往下问三句话。
（2.1）第一问：上下文窗口扛得住一个完整的业务级任务吗？
扛得住 → 1 个 Agent 承担 1 个及以上完整的业务级任务。
- 必须完整，不能与其他 Agent 所负责任务重叠。
- 一个 Agent 管多个业务时，三条都满足才合并：有自己的数据、有自己的规则、能独立判定完成。缺一条，中间就会出现"这块到底该不该动那张表"的模糊地带。
- 合并的代价要认：分给两个人，中间是硬边界（定好接口，越界就报错）；合给一个人，中间只剩"你自己注意点"，没有机制拦着你搞混。省了通信，丢了约束。
（2.2）第二问：扛不住一个完整的业务级任务，怎么办？
→ 1 个 Agent 承担该业务内的 1 个及以上流程级任务。
- 切点仍然要落在流程的天然交接口，不能切在流程中间。这不是按人头劈，而是沿着业务内部本来就有的节点切。
- 承担多个流程级任务时，任务之间最好连续：每少一次交接，就少一次信息损耗（上家的判断依据、犹豫的地方，是传不下去的）。
- 必须指定这个业务的总负责人——由一个 Agent 或主控 Agent 对"这个业务整体做对了"负责。缺这一条，业务级责任就真空了：分段都合格，合起来是错的，没人认领。
（2.3）第三问：一个流程级任务自己也装不下，怎么办？
→ 不要继续切人。 这说明该细拆的是工具范围、数据范围或判断步骤，而不是再派一个 Agent 来分走一半。
（2.4）主控 / 架构总管 Agent：公共层的归属
任务划分只解决"包含什么"。权限校验、审计日志、金额精度、单号生成、事务边界，这些不属于任何业务任务——按业务切必然出现真空，三家都以为别人做了。
所以运行期必须留一个公共层的归属，通常落在主控或架构 Agent 身上。注意这不违反"按业务切"：它是第 0 层的横切责任，不是从某个业务里抢活。
（2.5）流程级 Agent 之间的交互：交接要有契约
- 每一段交接都要说清楚：给什么、什么格式、什么口径。
- 下家发现不对，必须敢退回去，不能硬着头皮往下算。否则三段都没毛病，结论是错的，没人认领。
三、怎么判断"上下文够不够"
不能只看字数（token），要看四样，而且按最坏情况估，不按平均：
- 装得下多少材料——最常用的那条路径，材料全不全。
- 工具面——挂太多工具，选错工具的概率明显上升，往往比超长更早出问题。
- 规则串味——两套业务的规则混在一个窗口里，容易把 A 的规矩用到 B 上，这是合并最常见的事故。
- 故障半径——一个 Agent 出错，会拖垮几个任务。
四、一页检查表
- 每个业务级任务都有唯一主人
- 没有哪个任务被两个 Agent 同时接管（不重叠）
- 所有块拼起来盖满全部工作，没有悬空的活（不留空）
- 被拆成流程段的业务，指定了总负责人
- 每个交接点写清了"给什么、什么格式、什么口径"
- 下游有拒收权，且真的会退
- 权限、审计、金额精度、单号、事务边界都有明确归属
- 共用数据只有一家能写，其他家只读
- 没有任何一个 Agent 的活是"某个任务的 60%"
