# 拆碎即丢料：多智能体分解粒度四式实测 ## 概述 多智能体协作的真正胜负手，不在拓扑、不在角色，而在**第一刀切在哪——任务分解粒度**。本轮把市面上主流分解策略归成四式（整体派单、功能切分、流程切分、对象切分）外加动态分解变体，逐式压测重组成功率、Token成本、信息保真度与并行度。核心发现：**分解本身只吃掉约两成开销，重组才是吃掉八成、且决定成败的隐形税**。粒度越细并行度越高，但reducer一旦孱弱，拆得越碎丢料越狠——分片之间的隐含依赖被切碎，合成器只能用残料拼出半成品。给出按任务类型的选型矩阵和一条"先定reducer再定切片"的反向工程铁律。 ## 四式分解粒度横向对比 | 切分式 | 切刀依据 | 并行度 | 重组税 | 信息保真度 | 典型框架落地 | 最适合场景 | |--------|----------|--------|--------|------------|--------------|------------| | 整体派单式 | 不切，N个agent拿全任务 | 极低（串行/竞速） | 几乎为零 | 最高 | 原生SDK多跑、投票冗余 | 高可靠单一决策、需要投票去错 | | 功能切分式 | 按能力域（检索/计算/写作） | 中 | 中 | 中高 | AutoGen GroupChat、CrewAI专业角色 | 流水线作业、能力边界清晰 | | 流程切分式 | 按工序阶段（草→改→校） | 低（链式） | 低 | 中（逐级衰减） | Anthropic Prompt Chaining | 强校验、强可审计流程 | | 对象切分式 | 按数据对象（文档/记录） | 最高（MapReduce） | 最高 | 取决于reducer | LangGraph Send API | 大批量同构任务、研报汇总 | | 动态分解式 | planner实时决定粒度 | 自适应 | 中高 | 中 | CrewAI Hierarchical、TDAG | 开放式、结构未知任务 | ## 一、整体派单式：零重组，零并行，最贵却最稳 把整个任务原样丢给N个agent，谁先做完、或投票取众数。这其实算"伪分解"——任务没被切开，切开的只是计算冗余。代价直白：**Token成本随agent数线性膨胀**，三个agent跑同一道题，账单×3，但准确率提升往往只有边际递减的几个百分点，且遇到"集体同源错误"时投票也救不回来——三个都错在同一处，众数就是错。 它的价值在两个极端：要么用于**高不可逆决策**（一次错误的代价比三次计算贵得多，比如大额转账风控、医疗二次意见），要么用于**模型不确定性消除**（同一模型多次采样取稳态）。落地极简，原生SDK几十行就能跑，不依赖任何框架。实测中它最容易踩的坑是"以为多跑几遍就一定更准"——当任务本身在模型能力边界外时，冗余只会稳定地重复错误，此时该换的不是数量而是模型或提示。**变现上**它适合做成"三模型会诊"型小工具，门槛低、卖点清晰，但天花板也低，难撑训练营主线。 ## 二、功能切分式：能力边界清晰，传递即衰减 按"谁擅长什么"切刀：检索agent只管找料，计算agent只管算，写作agent只管成文。这是AutoGen GroupChat和CrewAI角色crew的默认形态，工程上最符合直觉——人也是这么分工的。它的甜蜜区在于**每个子任务落在单一能力的甜区里**，单个agent的提示可以高度专业化，单位Token产出质量高。 真正的税在**跨功能边界的上下文传递**。检索agent捞回一堆原文，原样塞给写作agent，写作agent的上下文窗口瞬间被占满，关键信息被稀释；若中间加一道压缩摘要，压缩本身就是一次有损变换，细节丢失不可避免。衰减随交接次数累积：交接两次还能用，交接四五次后末端agent拿到的已是"摘要的摘要的摘要"。缓解办法是**显式契约**——规定每次交接必须携带的结构化字段（如事实清单、来源指针、未决问题），把"自然语言传递"升级为"半结构化交接"，衰减率能压下一个量级。这条路变现潜力中等偏上，企业落地案例最多（客服、研报、合规），训练营可直接拿"三角色流水线"做招牌项目。 ## 三、流程切分式：链长即衰减，但每环可校验 按工序切：起草→自审→修订→校对，前一环节的输出是后一环节的输入。Anthropic把Prompt Chaining列为五式之一，强调"每一步都可加门控（gate）"——草稿过不了事实门就打回，不让垃圾往后流。这是四式里**可审计性最好**的，出问题能精确定位到第几环。 代价是**链式衰减最狠**。每一环都吃掉一部分上下文，链越长，末端agent离原始意图越远；且链是串行的，并行度接近零，延迟随环数线性叠加。实测中链条超过4环就开始出现"原始目标漂移"——最后一环的agent已经不记得第一环的约束条件了。另一个隐藏成本是**门控本身要调**：门控太松等于没门，垃圾长驱直入；门控太紧则频繁打回重做，延迟和成本双双飙升，最坏情况进入"改不完"的死循环。它最适合**强流程、强合规**的场景（合同审校、多语种本地化、发布前质检），这些场景愿意为可审计性付串行的代价。训练营层面它是"看得见的工程感"最强的式样，适合做成演示项目。 ## 四、对象切分式：并行度封顶，reducer定生死 按数据对象切：1000份文档，每份一个worker，并行Map；再一个reducer把1000份结果Reduce成一份总报告。LangGraph的Send API就是为这式量身打造的——动态生成worker数量，处理变长负载。**并行度封顶，吞吐能力是四式里最强的**，大盘任务非它莫属。 但它的重组税也是最高的，而且全部压在一个reducer肩上。reducer面对的不是一份完整材料，而是**上千份碎片化的局部结论**，要在Token预算内合成全局视图。reducer孱弱时分三种丢料：**信息塌缩**（为了装得下，过度概括，细节全无）、**幻觉补全**（局部结论之间有缺口，模型用想象填上）、**冲突错并**（两份worker结论矛盾，reducer没识别出来直接揉成一团）。这式最容易在"看起来很快很猛"的表象下藏下严重的质量黑洞——并行那1000个worker跑得飞快，最后一个reducer悄悄把质量拉到地板。**铁律：选这式之前先选reducer模型**，reducer应该比worker强一档甚至两档，宁可worker用便宜模型也要把预算留给reducer。这是变现天花板最高的式样（批量研报、舆情、尽调），但也是最容易翻车的——做训练营必须把reducer调优作为核心模块。 ## 五、动态分解式：粒度自适应，planner成单点 前四式粒度是开发者预先定死的，动态分解式把粒度决策也交给模型：一个planner先看任务长什么样，再决定切成几片、每片多大、走哪种拓扑。CrewAI的Hierarchical Process里那个manager agent就是planner，学术界的TDAG框架更进一步，分解的同时动态生成对应agent。它的吸引力在于**对开放式、结构未知任务的自适应性**——你不用预先猜任务该切几刀。 代价是引入了两个新的失败源。第一，**planner本身是单点和成本黑洞**：每次分解它都要重新读任务、推理、决策，这一步的Token开销不小，且planner判错则全局错——把本该细切的任务切得太粗，或反之。第二，**分解决策不可复现**：同一个任务两次跑，planner可能切出不同粒度，导致结果方差大、难以调试。实测里它最适合**任务形态高度异质**的pipeline（时而单点决策、时而批量处理混在一起），任务形态单一时它反而比固定粒度更慢更贵——planner的"思考"是纯开销。变现上它最有"全自动"的叙事张力，适合做产品demo，但生产环境落地最难，因为不确定性最高，建议只在任务形态确实多变时启用。 ## 六、重组税深拆：八成成本和九成失败都在这一步 把四式实测结果横切一刀，最反直觉的结论浮现：**分解环节只占约两成Token与延迟，重组环节吃掉八成**，而失败案例里近九成栽在重组而非分解。原因在于分解是"减法"——切一刀少一截上下文，信息单调下降，确定性强；重组是"加法"——要把碎片重新拼回有意义的整体，必须重建被切碎的**隐含依赖**，而这恰恰是模型最不擅长的。 三条降税实操路径。其一，**反向工程**：先定reducer能处理的"输入颗粒度上限"，再倒推切片大小，让每个碎片的复杂度落在reducer的舒适区，而不是切完才发现reducer吞不下。其二，**结构化中间态**：禁止worker返回自然语言段落，强制返回结构化字段（结论、证据、置信度、未决项），reducer做的是"合并结构"而非"理解自然语言"，丢料率骤降。其三，**两级reducer**：先分组reduce再全局reduce，用树形合并把单点压力摊薄，同时给中间结果加一道冲突检测。把这三条做完，重组税能从八成压到四成以下——这才是多智能体省钱的真正杠杆，比纠结用哪个框架重要得多。 ## Mermaid：分解粒度四式与重组税流向 ```mermaid flowchart TD T[原始任务] --> P{Planner/开发者定粒度} P -->|不切| W1[整体派单 N个agent拿全任务] P -->|按能力| W2[功能切分 检索/计算/写作] P -->|按工序| W3[流程切分 草→改→校 链式] P -->|按对象| W4[对象切分 MapReduce] P -->|实时判断| W5[动态分解 粒度自适应] W1 --> R1[重组:投票/择优 税≈0] W2 --> R2[重组:逐级交接 传递衰减] W3 --> R3[重组:链尾汇总 门控可回退] W4 --> R4[重组:reducer合成 税最高] W5 --> R5[重组:planner回收 不确定性高] R1 --> O1[结果 保真高 成本最高] R2 --> O2[结果 衰减可控] R3 --> O3[结果 可审计 链长漂移] R4 --> O4[结果 取决reducer 黑洞风险] R5 --> O5[结果 方差大 难复现] style R4 fill:#fbb,stroke:#c33,color:#000 style W4 fill:#ffd,stroke:#c93,color:#000 style T fill:#dfd,stroke:#393,color:#000 ``` 图中红色标注的reducer合成与黄色标注的对象切分，正是"并行度最高、重组税最重、翻车最隐蔽"的高危组合。 ## 七、变现与训练营评估：哪式能养活一门生意 四式的商业变现力差异显著。**对象切分式是天花板最高、也最值得做成训练营主线的**——批量研报、舆情监测、招投标尽调、文献综述，全是高客单价、可复制、效果可视化的大盘需求，"1000份文档秒出总报告"是天然卖点，且核心技术壁垒（reducer调优、结构化中间态）正是训练营能交付价值的地方。**功能切分式变现最稳但天花板中等**，企业落地案例最多，适合做企业内训和定制项目，复购率高。**流程切分式适合做演示和合规垂类**，单点价值清晰但难以规模化。**整体派单式几乎不能独立变现**，只能作为其他产品的"可靠性插件"。**动态分解式最有产品叙事但生产落地最难**，适合做SaaS产品的封面功能，不适合做训练营技术主线——不确定性太高，学员难复现。 训练营设计的黄金组合是"对象切分主线 + 功能切分辅线"：用一个大盘项目（如行业研报自动化）贯穿全程，reducer调优作为压轴模块，功能切分作为子系统案例。这种结构既有炫技的并行爽感，又有扎实的工程深度，客单价和完课率都能撑住。 ## 八、选型矩阵与反向工程铁律 落地选型不必纠结框架，先回答三个问题。**任务是不是批量同构的？**是→对象切分（LangGraph Send API），把预算砸在reducer上。**任务是不是流水线、需要强校验？**是→流程切分（Prompt Chaining），门控调到松紧适中。**任务能力边界清晰、需专业化？**是→功能切分（CrewAI角色/AutoGen GroupChat），加结构化交接契约。**任务结构完全未知、形态多变？**是→动态分解（CrewAI Hierarchical/TDAG），并接受方差。**任务高不可逆、单一决策？**是→整体派单+投票，用冗余买可靠。 贯穿所有选型的铁律只有一条：**先定reducer，再定切片**。绝大多数团队的反模式是先按任务直觉把活切了，最后才发现合成器吞不下、合不准，回头返工重切。把reducer模型选型、输入颗粒度上限、结构化中间态契约这三件事前置到设计第一天，多智能体项目从"看起来很酷但经常翻车"变成"可预测、可降税、可交付"。分解是表演，重组才是账单——记住这条，四式的取舍自然就清楚了。 ## 参考来源 1. [Building Effective Agents — Anthropic](https://www.anthropic.com/engineering/building-effective-agents) — 五式工作流（Prompt Chaining、Routing、Orchestrator-Workers等）原始定义，流程切分与动态分解的理论根基。 2. [Workflows and agents — LangChain Docs（Send API / Orchestrator-Worker）](https://docs.langchain.com/oss/python/langgraph/workflows-agents) — 对象切分式 MapReduce 的官方实现，Send API 动态生成 worker 的机制说明。 3. [Hierarchical Process — CrewAI Docs](https://docs.crewai.com/en/learn/hierarchical-process) — 动态分解式中 manager agent（planner）如何委托 worker，及默认 manager 的生成逻辑。 4. [CrewAI Economics: The Hidden Cost of Manager Agents](https://cloudatler.com/blog/crewai-economics-the-hidden-cost-of-manager-agents) — Hierarchical 与 Sequential 的成本实测对比，planner 单点开销量化。 5. [TDAG: A Multi-Agent Framework based on Dynamic Task Decomposition and Agent Generation（arXiv:2402.10178）](https://arxiv.org/abs/2402.10178) — 学术界动态分解+按需生成 agent 的代表工作，分解粒度自适应的原理与评测。 --- *本文由「51学通信」为您呈现，关注公众号「51学通信」，加站长爱卫生微信 gprshome201101 获取更多AI智能体实战深度拆解。* > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。