引言

在做 AI Agent 架构设计时，很多讨论都集中在“用什么框架”上——比如用 CrewAI 还是 LangGraph，用 Claude SDK 还是 OpenAI Agents SDK。但框架只是工具，真正需要想清楚的是“执行模式”。

不同复杂度的任务，需要不同的执行模式来处理：简单查询和复杂决策走一样的流程，要么浪费资源，要么效果不佳。本文整理了我在实际项目中使用的三种执行模式：Master-Slave（主从模式）、Crew（团队协作模式）、Debate（辩论决策模式），并详细说明每种模式的适用场景、优劣势，以及如何在一个系统里让它们共存。

一、先看全貌：三种执行模式的定位与适用范围

系统中的 BasicAgent 会根据任务复杂度，自动选择对应的执行模式，三者的定位和适用场景清晰区分如下：

选择哪种模式并非主观判断，而是基于任务复杂度评分决定。在我们的系统中，用一个 ExecutionPlan 模型来规范执行计划，代码如下：

class ExecutionPlan(BaseModel):    steps: List[ExecutionStep]    execution_mode: Literal["single", "crew", "debate"] = "single"    crew_config: Optional[CrewConfig] = None    debate_config: Optional[DebateConfig] = None

下面逐个拆解每种模式的细节、优劣势及适用场景。

二、模式一：Master-Slave（主从模式）

2.1 架构结构

主从模式是最经典的 Agent 架构，由一个 Master Agent 负责全局调度，多个 SubAgent 负责具体执行，Master 遵循固定的 6 个 Phase 流程，结构如下：

其中，SubAgent 按权限分级（借鉴 learn-claude-code 项目 v3 子代理设计），核心是“上下文隔离”——每个 SubAgent 有独立的上下文窗口，执行完毕后仅将结果返回给 Master，避免中间过程的大量 token 污染主上下文：

• explore 类型：仅使用只读工具，用于信息检索；
• code 类型：拥有完整工具权限，用于需要写入操作的任务；
• plan 类型：仅做分析和规划，不直接执行。

2.2 优劣势

2.3 适用场景

• 简单查询：如“查询今天的保洁完成率”；
• 确定性流程：已知步骤、已知工具调用顺序的任务；
• 延迟敏感场景：需要快速返回结果；
• 成本敏感场景：不希望多个 Agent 之间大量通信消耗 token。

三、模式二：Crew（团队协作模式）

3.1 架构结构

Crew 模式源于 CrewAI 框架的设计理念，核心是“专业分工协作”——一组具有不同专业角色的 Agent 组成团队，围绕共同目标协作完成任务，每个 Agent 有自己的角色定义、专属工具和行为目标。架构如下：

与主从模式的关键区别：Crew 中的 Agent 不是简单接受指令执行子任务，而是有自己的“角色认知”，会主动基于角色完成工作（如数据分析师主动寻找数据异常点）。

Crew 模式的两种核心执行方式：

• Sequential（顺序执行）：Agent 按顺序依次执行，前一个的输出是后一个的输入，适合有明确步骤依赖的任务；
• Hierarchical（层级执行）：由 Manager Agent 负责调度，其他 Agent 接受调度，与主从模式的区别在于 Manager 的调度基于 LLM 决策，而非固定规则。

3.2 优劣势

3.3 适用场景

• 多步骤专业任务：如“分析上月保洁数据趋势，找出异常项目，给出改进建议”；
• 需要交叉验证的任务：如数据分析师出结论，领域专家审核；
• 内容生成任务：如研究 -> 撰写 -> 校对。

四、模式三：Debate（辩论决策模式）

4.1 架构结构

Debate 模式是较新的实践，核心思路是“多角度对抗决策”——让多个 Agent 就同一个问题给出不同角度的分析和方案，再由裁判 Agent 综合评估后给出最终决策，模拟人类决策中的“红蓝对抗”或“魔鬼代言人”机制，减少决策盲区。架构如下：

典型辩论流程：

1. Round 1：各方 Agent 分别给出自己的方案和论据；
2. Round 2：各方 Agent 审视对方方案，提出质疑和反驳；
3. Round 3：各方 Agent 回应质疑，可选择修正自己的方案；
4. 裁决：裁判 Agent 综合所有论点，给出最终决策及理由。

4.2 优劣势

4.3 适用场景

• 复杂决策：如“这个区域的保洁方案应该选增加人手还是优化排班？”；
• 方案评估：多个可选方案，需要综合评估优劣；
• 风险分析：需要从不同角度识别潜在风险。

五、三种模式的横向对比

为了更清晰地选择模式，从核心维度对三种模式进行横向对比，同时给出直观的选择策略：

5.1 核心维度对比

5.2 直观选择策略

六、在同一个系统中混合使用三种模式

实际系统中，三种模式并非互斥，而是共存的——系统根据任务复杂度自动选择合适的模式，核心实现思路是在 BasicAgent 层增加一个模式选择器。

6.1 核心实现代码

class BasicAgent:    async def execute(self, task: str, context: dict):        # 分析任务复杂度，生成执行计划        plan = self.planner.create_plan(task, context)        # 根据执行计划选择对应模式执行        if plan.execution_mode == "single":            return await self._execute_single(plan)        elif plan.execution_mode == "crew":            return await self._execute_crew(plan)        elif plan.execution_mode == "debate":            return await self._execute_debate(plan)

6.2 任务复杂度评分逻辑

通过评分维度判断任务复杂度，进而匹配模式，评分维度包括：意图数量、是否需要多种工具、是否涉及主观判断、是否需要创意性输出等，具体评分规则如下：

• 简单查询（score < 30）：单一意图，明确的工具调用 → Master-Slave；
• 中等任务（30 ≤ score < 70）：多步骤，需要专业角色 → Crew；
• 复杂决策（score ≥ 70）：多方案权衡，没有标准答案 → Debate。

七、关键补充：成本、回退机制与框架支持

7.1 模式切换的成本考量

除了任务特征，成本是选择模式的重要因素。以下是典型任务的成本、延迟粗略测算（基于 GPT-4o），可作为选型参考：

注：成本差异达量级，大部分日常查询用 Master-Slave 即可，成本比 Debate 低 10 倍以上。

7.2 回退机制（避免模式选择出错）

混合架构中，模式选择可能出错（如简单任务误判），因此需要增加回退机制——当低复杂度模式执行结果不达标时，自动升级到高复杂度模式重试，同时限制最大重试次数，避免资源浪费。

async def execute_with_fallback(self, task, context, max_upgrades=1):    modes = ["single", "crew", "debate"]    current_idx = 0    for attempt in range(max_upgrades + 1):        result = await self._execute_mode(modes[current_idx], task, context)        # 检查结果置信度，达标则返回        if result.confidence >= 0.7:            return result        # 不达标则升级模式，最多升级到最高级        current_idx = min(current_idx + 1, len(modes) - 1)    # 多次升级仍不达标，返回最后一次结果    return result

7.3 与主流框架的对应关系

三种模式均可基于主流框架实现，其中 Debate 模式目前缺乏框架级内置支持，需应用层自研，具体对应关系如下：

补充：Debate 模式自研难度不高，核心是让多个 Agent 针对同一问题生成不同观点，再由裁判 Agent 汇总评估。

八、总结

三种执行模式的选择，本质是在“速度/成本”和“质量”之间做权衡，核心总结如下：

• Master-Slave：快、省、可控，适合 70% 以上的简单日常任务，是系统的基础；
• Crew：平衡协作与效率，适合 25% 左右的中等复杂度专业任务，是系统的核心补充；
• Debate：质量最高，但成本和延迟也最高，仅适合不到 5% 的复杂决策任务，作为兜底。

核心建议：成熟的 Agent 系统应让三种模式共存，由系统自动匹配任务特征；若系统刚起步，优先把 Master-Slave 做扎实，再逐步迭代 Crew 模式，Debate 模式可后期优化补充，避免“一刀切”的选型误区。