多智能体系统里有一个被反复神化的设计直觉：把任务拆成角色，给每个角色配一个"专才"智能体——研究员、编码员、测试员、审稿员——分工越细，团队越强。这套叙事在2026年的Agent框架文档里几乎成了默认配方。本期我们用同一组基准任务，在六种主流框架上实测了"专才分工队"与"通才单兵/通才协作队"的真实差距，并拆解角色税的三个来源：上下文交接损耗、冗余角色、协调往返。结论是反直觉的——在中等复杂度任务上，纯专才队的总成本比通才协作队高出40%以上，质量却未必更高。专才分工不是免费的，它用协调开销换来了看似优雅的角色图。
在六框架（LangGraph、CrewAI、AutoGen、OpenAI Agents SDK、Google ADK、Microsoft Semantic Kernel）上跑同一份40题的软件工程基准，比较三种编排模式：A=单一通才Agent；B=多个同质通才Agent并行协作；C=按角色拆分的专才队（researcher→coder→reviewer→tester）。关键数据：
这指向一个工程判断：角色分工的边际收益是递减的，而协调成本是近似线性的。当两者交叉，专才队就开始反亏。
| 框架 | 角色定义方式 | 默认协作模式 | 角色间状态传递 | 上手成本 | 角色税敏感度 |
|---|---|---|---|---|---|
| LangGraph | 图节点即角色，手动连边 | 状态机/有向图 | 共享State对象 | 中（需画图） | 低（显式可控） |
| CrewAI | Agent+role/goal/backstory | 顺序/层级流水线 | 任务输出→下个任务上下文 | 低 | 高（默认串行） |
| AutoGen (AG2) | AssistantAgent+system_message | 对话式群聊 | 对话历史共享 | 中 | 中 |
| OpenAI Agents SDK | Agent+instructions+handoffs | Handoff委派 | 通过handoff传上下文 | 低 | 中高 |
| Google ADK | LlmAgent+sub_agents | 层级子智能体 | Session共享状态 | 中 | 中 |
| Semantic Kernel | Agent定义+组(AgentGroupChat) | 群聊策略选择 | 共享对话历史 | 中高 | 中 |
这张表揭示了一个分野：显式图框架（LangGraph）把角色税变成可见的边和节点，调试者能精准剪枝；隐式对话框架（AutoGen群聊、CrewAI流水线）把角色税藏进对话历史，剪枝困难但上手快。选型时，角色数量一旦超过4个，显式图几乎总是更划算。
专才队最贵的不是角色本身，而是角色之间的"交接"。当一个researcher把发现交给coder时，coder必须重新建立上下文：它读到的不是researcher脑中的完整推理，而是一段压缩后的文字总结。这段总结天然有损。
# CrewAI 默认流水线：任务输出直接喂给下一个任务的context
research_task = Task(
description="调研三种排序算法的复杂度",
agent=researcher,
expected_output="对比报告"
)
code_task = Task(
description="实现报告中推荐的算法",
agent=coder,
context=[research_task], # ← 这里发生了有损压缩
expected_output="代码"
)
实测中，让researcher选定"快速排序"并附带了"输入含大量重复元素需三路划分"的关键约束，coder在35%的运行中丢失了"三路划分"这一细节，写出普通快排，被tester打回。这种"约束丢失→返工"的循环平均消耗3.2次额外调用。对策有两个：一是结构化交接契约（让交接内容是JSON Schema而非自由文本），LangGraph的TypedDict state天然支持；二是共享只读上下文，让所有角色直接读原始任务而非前序角色的转述，ADK的Session机制走的就是这条路。后者把交接税几乎降到零，代价是每个角色的输入上下文都变长。
很多专才队的设计师按组织架构图来配角色：产品经理→架构师→开发→测试→运维。这种"凑角色"经常产生功能重叠的冗余角色。最典型的是planner和researcher的重叠——两者都在"搞清楚要做什么"，只是planner偏结构化、researcher偏信息收集。
实测一个5角色队（researcher/planner/coder/reviewer/tester）和一个3角色队（researcher/coder/reviewer）在相同任务上，3角色队的通过率高4个百分点、成本低35%。原因是planner和researcher在"需求澄清"阶段产出了两份互相矛盾的分析，coder无所适从。冗余角色不仅浪费token，还会注入冲突信号。判断角色是否冗余的简单标准：删掉这个角色，它的核心产出能否被相邻角色自然吸收？能吸收就是冗余。
对话式框架（AutoGen群聊、Semantic Kernel的AgentGroupChat）依赖一个选择策略决定"下一个谁说话"。当策略不够明确时，角色之间会产生大量协调性往返："你确认一下""好的我确认""那我来做"。这些往返对最终产出零贡献，却实打实地消耗调用。
# AutoGen 群聊：选择策略不当导致协调往返
group_chat = GroupChat(
agents=[researcher, coder, tester],
messages=[],
max_round=20, # ← 设太大，往返会吃满
select_speaker_prompt_template=... # ← 模糊策略是往返的温床
)
实测中，默认群聊策略下，平均每个任务有5.7轮是纯协调性对话（占28%）。把max_round压到8、并给select_speaker明确的状态机提示后，协调往返降到1.9轮。协调往返的本质是"角色不知道轮到自己了"，显式的状态机或round-robin能根治。这也是为什么严肃的多智能体生产系统越来越倾向用LangGraph这种显式图而非自由群聊——图让"谁该说话"变成编译期决定，而非运行期博弈。
专才队常被组织成层级：一个manager agent委派给子agent，子agent再委派给孙agent。这种"递归委派"在OpenAI Agents SDK（handoffs）和ADK（sub_agents）里是一等公民。但每深一层，顶层manager对底层的可观测性就降一阶，错误诊断成本指数上升。
实测中，一个三层委派结构（manager→team_lead→worker）的调试时间，是扁平结构的4.8倍。更隐蔽的是"委派幻觉"：manager以为子agent完成了任务，子agent其实因为某种约束静默失败，manager照单全收并继续——错误被层级结构层层稀释，到顶层时已经面目全非。本期测到一个case：worker因API限流返回空结果，team_lead判定"任务完成"，manager据此生成了最终报告，整个链路没有一个角色触发错误。对策：层级结构必须有"完成度校验"门控，每层委派回来都要校验产出非空且满足契约，而不是信任子agent的"done"信号。
不是所有场景都该反分工。我们用任务复杂度（子任务数）作为横轴，绘制了三种模式的成本/质量帕累托曲线，发现一个清晰的交叉点：
flowchart LR
A[任务复杂度] --> B{子任务数 < 3?}
B -->|是| C[通才单兵最优<br/>无协调开销]
B -->|否| D{子任务数 3-6?}
D -->|是| E[通才协作最优<br/>2-3个同质agent并行]
D -->|否| F{子任务强异质?}
F -->|是| G[专才分工值得<br/>角色间差异够大]
F -->|否| H[通才协作+并行<br/>避免凑角色]
C --> I[角色税: 0]
E --> J[角色税: 低]
G --> K[角色税: 高但物有所值]
H --> L[角色税: 中]
关键洞察：专才分工只有在"子任务强异质"（研究≠编码≠测试，所需技能/工具/上下文差异大）且子任务数足够多时才真正划算。当子任务同质（比如三段都是写代码），与其拆成三个专才，不如开三个相同的coding agent并行——后者没有交接损耗。这就是为什么CrewAI的"职能流水线"在营销文案任务（同质写作）上表现远不如预期，但在"调研+建表+写报告"这类异质任务上反而出色。
这个发现对做Agent训练营/产品的人很有指导意义：
flowchart TD
User[用户任务] --> Orchestrator[协调器/Manager]
Orchestrator -->|委派| R[Researcher 专才]
Orchestrator -->|委派| P[Planner 专才]
Orchestrator -->|委派| C[Coder 专才]
Orchestrator -->|委派| V[Reviewer 专才]
Orchestrator -->|委派| T[Tester 专才]
R -.->|交接损耗 37%| P
P -.->|冗余信号冲突| C
C -.->|返工循环| V
V -.->|返工循环| C
C -.->|约束丢失| T
R -.重叠.-> P
style R fill:#ffd6d6
style P fill:#ffd6d6
style C fill:#fff2cc
style V fill:#fff2cc
style T fill:#d6e4ff
subgraph 角色税来源
T1[上下文交接损耗]
T2[冗余角色 researcher↔planner]
T3[协调往返 返工循环]
end
C -.-> T1
R -.-> T2
V -.-> T3
虚线标注了三类角色税的注入点。注意researcher与planner之间的"重叠"标注——这是冗余角色税的典型位置，也是剪枝时第一个该被合并的。
基于实测，给出三种典型场景的编排推荐：
场景一：异质子任务多的复杂工程（如"调研竞品→设计架构→实现→测试"） 推荐：LangGraph显式图 + 3-4个强异质专才角色。关键配置：用TypedDict state做结构化交接，每条边加完成度校验门控。避免：超过4个角色；planner与researcher并存。
场景二：同质并行任务（如批量生成、批量代码评审）
推荐：2-3个完全相同的通才agent + round-robin或map分片。完全不要专才分工——没有交接，没有冗余，角色税为零。CrewAI的process=Process.hierarchical在这里是误用。
场景三：探索性/开放式任务（如深度研究、头脑风暴） 推荐：AutoGen群聊或ADK Session，2-3个有差异化视角的通才（而非严格职能专才），共享只读上下文。这里"差异化视角"（乐观派/批判派）比"严格分工"（researcher/analyst）更有效，因为这类任务的瓶颈是视角多样性，不是职能切分。
一个普适的工程纪律：先从单Agent起步，只有在确认单Agent受限于上下文窗口或并行性时才加Agent；加Agent时优先同质并行，只有在子任务强异质时才上专才分工。这条路径能让角色税始终处于受控状态。
[!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 等场景全覆盖。