分阶段调度多智能体系统：Token高效协同架构设计与工程实践-平芜编程栈

1. 项目概述：当多智能体协作遇上“算力焦虑”

最近在折腾一个多智能体协作的项目，目标是让一群AI“打工人”能高效地协同完成一个复杂任务。这听起来挺酷，对吧？但实际操作起来，一个巨大的拦路虎立刻出现了：Token消耗。每次让多个智能体同时“思考”和“对话”，API的调用成本就像开了闸的洪水，哗哗地流。更头疼的是，这种“全员在线”的模式，往往伴随着大量的无效沟通和信息冗余，效率反而上不去。

这让我开始思考，有没有一种方法，能像管理一个项目团队一样，为多智能体系统引入“日程表”和“工作流”？不是让所有智能体7x24小时待命，而是根据任务的不同阶段，精准地调度最合适的“专家”上场，其他成员则暂时“休眠”，从而大幅节省宝贵的计算资源（Token）。这就是“Phase-Scheduled Multi-Agent Systems for Token-Efficient Coordination”（分阶段调度的多智能体系统，用于高效Token协同）的核心思路。它不是一个具体的工具，而是一套设计范式与架构理念，旨在解决多智能体应用中成本与效率难以兼得的痛点。

简单来说，它要解决两个核心问题：第一，“谁在什么时候干活？”——通过定义清晰的任务阶段（Phase）和触发条件，实现智能体的按需调度。第二，“怎么干最省？”——通过优化智能体间的通信模式、信息传递内容以及自身的“思考”过程，最大化每一次Token消耗的价值。这套方法特别适合那些任务链条长、角色分工明确、且对成本敏感的应用场景，比如自动化内容生产、复杂数据分析流水线、游戏NPC生态模拟等。

2. 核心架构设计：从“圆桌会议”到“接力赛跑”

传统的多智能体系统，很像一场没有主持人的圆桌会议。所有参与者（智能体）同时被激活，针对同一个议题（用户查询）各抒己见，它们之间可能会相互辩论、补充或提问。这种模式的优点是“头脑风暴”效果好，能激发多样性。但缺点也极其明显：会议（会话）轮次多，每个人（每个智能体）每次发言都要消耗Token，且大量讨论可能偏离主题或重复。

Phase-Scheduled（分阶段调度）架构，则把这场“圆桌会议”改造成了一场组织有序的“接力赛跑”。整个任务被分解为多个连续的阶段（Phases），每个阶段有明确的输入、输出、负责的智能体（或智能体组合）以及进入下一阶段的条件。

2.1 阶段（Phase）的定义与划分逻辑

阶段划分是整个系统的骨架，划分的依据直接决定了系统的效率和智能。划分的核心原则是**“高内聚、低耦合”与“责任单一”**。

基于任务类型划分：这是最直观的方式。例如，在一个“调研报告生成”任务中，可以划分为：
- Phase 1: 理解与拆解：由“分析员”智能体负责，解析用户需求，输出报告大纲和关键问题列表。
- Phase 2: 信息搜集：由“研究员”智能体负责，根据大纲和问题，并行或串行地搜索、提取关键信息。
- Phase 3: 整合与撰写：由“撰稿人”智能体负责，将搜集到的信息整合成连贯的草稿。
- Phase 4: 审核与润色：由“编辑”智能体负责，检查逻辑、事实、语法，并优化表达。
基于决策里程碑划分：在一些决策型任务中，阶段以关键决策点为界。例如，在“商业方案评估”中：
- Phase 1: 可行性初筛：快速过滤掉明显不可行的方案。
- Phase 2: 详细分析：对初筛通过的方案进行深入的成本、收益、风险分析。
- Phase 3: 综合比选与推荐：对比分析结果，给出最终推荐意见。
基于数据流状态划分：在处理数据管道任务时，阶段根据数据的形态变化来定义。例如，在“数据清洗与分析”流水线中：
- Phase 1: 原始数据校验与格式化。
- Phase 2: 缺失值处理与异常值检测。
- Phase 3: 特征工程与转换。
- Phase 4: 模型训练与评估（如果需要）。

实操心得：阶段的粒度需要权衡。阶段分得太细（例如，把“润色”再拆成“语法检查”和“修辞优化”两个阶段），调度开销会增加；分得太粗（例如，把“搜集”和“撰写”合并），则失去了精准调度、节省Token的意义。一个实用的技巧是，以“是否值得切换一个具有不同系统指令（System Prompt）和能力的智能体”为标准。如果值得，那就应该是一个新阶段。

2.2 调度器（Scheduler）的设计：系统的大脑

调度器是Phase-Scheduled架构的核心组件，它负责监控整个系统的状态，并根据预定义的规则，决定何时启动哪个阶段，以及向该阶段传递什么上下文。它的设计直接关系到系统的可靠性和Token效率。

基于规则的调度器：最简单也最常用的类型。它维护一个阶段状态机，每个阶段结束后，其输出会经过一个“条件判断”模块。这个模块检查输出是否满足进入下一阶段的条件（例如，大纲是否完整？数据质量是否达标？）。如果满足，则触发下一阶段；如果不满足，可能触发重试、回退到上一阶段或报错。
- 优点：逻辑清晰，可控性强，易于调试。
- 缺点：灵活性差，无法处理规则外的情况。条件判断逻辑本身可能需要消耗Token（例如，用一个轻量级智能体来判断）。
基于模型的调度器：引入一个专用的“调度员”智能体（通常是一个轻量级模型或经过特定提示词优化的智能体）。这个调度员评估当前任务状态和所有阶段的状态，动态决定下一步动作。它甚至可以处理异常，比如当某个阶段智能体表示“无法完成”时，调度员可以决定换一个备选智能体，或者调整任务目标。
- 优点：灵活性高，能应对复杂、不确定的任务流。
- 缺点：引入了额外的Token开销和复杂度，“调度员”本身也可能做出错误决策。
混合调度器：结合上述两者。主体流程使用规则驱动，确保主干高效稳定；在特定的决策节点或异常处理分支，引入模型调度。这是平衡效率与灵活性的常用策略。

Token高效的关键在于调度器的“吝啬”：它传递的上下文必须是精炼的。调度器不应该把整个会话历史都扔给下一个智能体，而应该只传递必要的、结构化的摘要信息。例如，从“分析员”传递给“研究员”的，不是分析员和用户的所有对话，而是一个提炼后的、包含核心问题和大纲的JSON对象。

2.3 智能体（Agent）的角色与状态管理

在这个架构下，每个智能体不再是随时待命的“常驻服务”，而是具有明确职责的“模块化组件”。

角色专业化：每个智能体都被赋予一个高度专业化的角色，并通过其系统指令（System Prompt）固化。例如，“事实核查员”的指令会强调准确性优先，禁止创造性发挥；“创意写手”的指令则鼓励发散思维。专业化减少了智能体在无关任务上的“思考”消耗。
状态生命周期：智能体有三种核心状态：
- 休眠（Dormant）：未加载，不占用任何计算资源（Token）。这是最省资源的状态。
- 活跃（Active）：被调度器唤醒，加载了特定的上下文和指令，正在执行任务。
- 挂起（Suspended）：任务完成，但其输出被暂存，以备后续阶段可能需要回溯查询。此时智能体实例可能被释放，但其输出作为数据被保存。
上下文隔离与传递：这是节省Token的另一个重要手段。阶段A的智能体完全不知道阶段B的智能体内部讨论了什么，它只接收调度器传递过来的、过滤后的输入。这避免了智能体在长上下文窗口中进行无关信息的检索与处理，显著降低了每次交互的Token基数。

3. 实现Token高效协同的核心技术策略

架构设计好了，如何在实际的API调用和提示词工程中，把“省Token”落到实处？以下是几个经过实践验证的关键策略。

3.1 提示词（Prompt）的极致优化

在多智能体系统中，提示词不仅是给AI的指令，更是控制Token流的阀门。

系统指令（System Prompt）的模块化与复用：为每个角色编写精准、简短、无歧义的系统指令。避免在每个请求中重复发送冗长的角色描述。在实现上，可以将这些指令存储在外部配置或数据库中，通过一个简短的标识符（如role: fact_checker）在API调用中引用，而由后端服务自动填充完整的指令内容。这样，网络传输和计费的Token只是那个简短的标识符。
上下文（Context）的摘要与结构化：坚决传递摘要，而非原始对话。例如，阶段一的输出可能是一段自由文本。在传递给阶段二之前，可以用一个极简的提示词（或规则）将其转换为结构化的数据：
- 原始输出：“用户想要一份关于新能源汽车电池技术发展的报告，重点关心固态电池的产业化进度和成本趋势，报告需要包含技术对比和主要厂商分析，字数约3000字。”
- 结构化摘要：
```
{ "report_topic": "新能源汽车电池技术发展", "focus_areas": ["固态电池产业化进度", "固态电池成本趋势"], "required_sections": ["技术对比", "主要厂商分析"], "target_length": 3000 }
```
这个JSON可能只有几十个Token，却承载了所有关键信息，远比传递上百Token的原始文本高效。
思维链（Chain-of-Thought）的受控使用：CoT能提升复杂任务的效果，但也会显著增加Token消耗。在Phase-Scheduled系统中，需要策略性地使用：
- 关键决策点使用：只在最需要复杂推理的阶段（如方案评估、矛盾解决）要求智能体“逐步思考”。
- 缩短CoT：通过提示词限制思考步骤，例如“请用不超过3步的推理得出结论”。
- 分离CoT与输出：有些API允许你获取模型的“内部思考”过程，但最终只返回结论。你可以选择不将思考过程传递给下一阶段，仅传递结论。

3.2 通信模式与消息传递的优化

智能体间的“对话”方式是Token消耗的大头。

广播 vs. 单播 vs. 聚合：
- 广播（Broadcast）：一个智能体的输出同时发给多个下游智能体。这在需要并行处理的阶段有用（如多个“研究员”同时调研不同子问题），但要确保信息是只读的、无需讨论的指令或数据。
- 单播（Unicast）：点对点传递，这是最常用的模式，符合阶段化流水线的设计。
- 聚合（Aggregate）：多个智能体的输出先由一个“聚合器”智能体（或简单规则）进行汇总、去重、排序，生成一份精简的摘要，再传递给下一阶段。这能极大避免信息重复。例如，三个研究员返回了15条信息，其中可能有5条是重复的，聚合后只传递10条精华。
回合数（Turn）最小化：在设计阶段流程时，目标之一是让每个智能体在其阶段内，尽可能一次交互就完成任务。避免在一个阶段内部设计多轮对话（除非绝对必要，如澄清模糊需求）。这要求上游阶段提供的输入必须足够清晰、完整。
使用工具（Function/Tool Calling）替代自然语言描述：当智能体需要执行确切操作（如查询数据库、调用计算函数）时，优先让它们调用预定义的工具，并将工具执行后的结构化结果作为上下文传递，而不是用自然语言描述“我查到了XXX”。结构化数据（JSON、列表）通常比描述同等信息的自然语言更Token高效。

3.3 模型选型与混合部署策略

不是所有阶段都需要“重型火炮”（如GPT-4）。根据阶段任务的难度，混合使用不同能力和成本的模型，是降低成本的关键。

路由策略：在调度器中集成模型路由逻辑。
- 简单任务使用轻量模型：对于格式转换、简单分类、信息提取等确定性较高的任务，可以使用更便宜、速度更快的模型（如 Claude Haiku, GPT-3.5-Turbo）。
- 复杂任务使用强大模型：对于需要深度推理、创意生成、复杂决策的阶段，则调用GPT-4、Claude Opus等顶级模型。
- 验证任务使用轻量模型：对于“审核”、“校验”这类阶段，其工作更多是基于规则和对比，也可以考虑使用轻量模型。
后备与降级机制：当主要模型因速率限制或故障不可用时，调度器应能自动切换到备用的、能力稍逊但可用的模型，并可能调整对该阶段输出的期望值，保证系统整体可用性。

4. 实战构建：一个自动化报告生成系统的分阶段实现

让我们通过一个具体的例子——“行业分析报告自动生成系统”，来串联以上所有概念。假设用户输入是：“请分析一下人工智能在医疗影像诊断领域的应用现状、主要技术瓶颈和未来两年趋势，输出一份结构化报告。”

4.1 阶段划分与智能体定义

我们将任务划分为四个阶段，并定义相应的智能体：

Phase 1: 需求解析与大纲生成

智能体：Analyst(使用GPT-4，确保深度理解)
输入：用户原始请求。
核心指令：“你是一个资深行业分析师。请将用户的模糊需求解析为一个详细、可操作的分析报告大纲。大纲必须包含：1. 明确的报告标题；2. 3-5个核心章节标题；3. 每个章节下需要回答的3-5个关键问题列表。以JSON格式输出。”

输出示例：

{ "report_title": "人工智能在医疗影像诊断领域的应用深度分析报告", "sections": [ { "title": "应用现状分析", "key_questions": ["当前主流AI医疗影像产品有哪些？", "渗透率最高的科室和病种是什么？", "典型的临床工作流集成模式是怎样的？"] }, { "title": "核心技术瓶颈剖析", "key_questions": ["数据质量与标注瓶颈的具体表现？", "模型可解释性在临床采纳中的阻力有多大？", "跨机构、跨设备泛化能力不足的根源？"] }, // ... 其他章节 ] }

Phase 2: 并行信息搜集
- 智能体：多个Researcher(使用GPT-3.5-Turbo，降低成本)
- 调度策略：调度器接收Phase 1的JSON输出，为sections数组中的每一个章节，创建一个独立的Researcher实例（或任务）。实现真正的并行化。
- 核心指令：“你是一个高效的信息研究员。基于以下章节标题和关键问题，进行信息搜集。请为每个问题提供2-3个核心观点或事实，并注明信息类型（如：技术原理、市场数据、专家观点、案例）。以JSON格式输出，确保信息简洁、准确。”
- 输出：每个Researcher输出一个针对其章节的JSON，包含问题与答案的列表。
Phase 3: 报告整合与撰写
- 智能体：Writer(使用GPT-4，保证文笔和质量)
- 输入：调度器将Phase 1的大纲和Phase 2所有Researcher的搜集结果，聚合成一个完整的、结构化的数据包。
- 核心指令：“你是一名专业的行业报告撰写人。请根据提供的大纲和已搜集的研究材料，撰写一份完整的、结构清晰、语言专业的行业分析报告。报告应直接基于材料，避免补充未经核实的信息。确保段落间逻辑连贯。”
- 输出：完整的报告Markdown文本。
Phase 4: 事实核查与格式精修
- 智能体：Editor(使用GPT-3.5-Turbo，侧重规则检查)
- 输入：Phase 3生成的报告草稿。
- 核心指令：“你是一名严谨的报告编辑。请执行以下操作：1. 检查报告中提及的具体产品名称、公司名称、数据（如百分比、年份）是否有明显矛盾或模糊之处，如有，用‘[需核实]’标出。2. 检查Markdown格式是否正确（标题层级、列表、引用等）。3. 优化过渡句，使行文更流畅。直接输出修改后的完整报告。”
- 输出：最终版报告。

4.2 调度器与上下文传递实现

调度器可以用任何你熟悉的语言实现（Python, Node.js等），其核心是一个状态机循环。伪代码如下：

# 伪代码示例 class ReportGenerationSystem: def __init__(self): self.scheduler = RuleBasedScheduler() self.current_phase = None self.context = {} # 存储阶段间传递的上下文 def run(self, user_query): self.context['user_query'] = user_query self.current_phase = 'Phase1_Analysis' # Phase 1 analyst_output = call_agent('Analyst', self.context['user_query']) self.context['outline'] = parse_json(analyst_output) # 结构化存储 self.current_phase = 'Phase2_Research' # Phase 2 - 并行 research_tasks = [] for section in self.context['outline']['sections']: task_input = {'section': section, 'all_outline': self.context['outline']} # 这里可以启动异步任务 task = async_call_agent('Researcher', task_input) research_tasks.append(task) all_research_results = await_all_tasks(research_tasks) self.context['research_data'] = aggregate_research(all_research_results) # 关键：聚合 self.current_phase = 'Phase3_Writing' # Phase 3 writer_input = { 'outline': self.context['outline'], 'research': self.context['research_data'] # 传递的是聚合后的精简数据 } report_draft = call_agent('Writer', writer_input) self.context['draft'] = report_draft self.current_phase = 'Phase4_Editing' # Phase 4 final_report = call_agent('Editor', self.context['draft']) return final_report

注意上下文传递的精简：Writer接收的不是所有Researcher的原始长篇大论，而是经过aggregate_research函数处理后的聚合数据。这个函数可能做去重、排序、提取核心句等操作，最终生成一个Token量大幅减少的上下文。

4.3 Token消耗对比分析

假设每个环节的Token消耗估算如下（仅为示意）：

传统圆桌模式（所有智能体持续讨论）：
- 用户请求：50 Token
- 智能体A（分析）发言：200 Token
- 智能体B（研究）回应并提问：300 Token
- 智能体A再回应：150 Token
- 智能体C（写作）加入... 多轮后，总对话可能轻松超过2000 Token，且过程混乱。
分阶段调度模式：
- Phase 1 (Analyst): 输入50 + 输出150 =200 Token
- Phase 2 (Researcher x 3): 平均每个输入100（大纲摘要）+ 输出200 = 300 Token。并行处理，但Token计费累加：900 Token
- Phase 3 (Writer): 输入400（聚合后的研究数据）+ 输出800（报告正文）=1200 Token
- Phase 4 (Editor): 输入800 + 输出50（主要修改标记）=850 Token
- 总计：~3150 Token

看起来总数可能相近甚至更多？但这里的关键差异在于：

质量可控：分阶段模式产出的报告结构严谨、信息经过聚合去重，质量远高于混乱讨论的结果。
过程高效：总耗时可能更短，因为并行处理和清晰的流水线。
可优化点明确：我们可以轻易地针对最大消耗阶段（Phase 3）进行优化，例如让Writer输出更简洁，或使用更便宜的模型进行初稿撰写。而在圆桌模式中，优化点分散且难以管理。
关键节省在于“无效交互”：分阶段模式完全避免了智能体间的开放式、可能冗余的讨论所消耗的巨量Token。实际项目中，对于复杂任务，圆桌模式的Token消耗往往是分阶段模式的数倍甚至十倍以上。

5. 常见陷阱、调试与进阶优化

在实际部署Phase-Scheduled系统时，你会遇到一些典型问题。

5.1 常见问题与排查清单

问题现象	可能原因	排查与解决思路
阶段卡住，不向下推进	1. 阶段输出格式不符合调度器解析预期。 2. 条件判断规则过于严格，永远不满足。 3. 智能体输出中包含导致API调用异常的字符。	1.强化输出格式约束：在智能体指令中明确要求“必须输出纯JSON”，并使用`json.loads()`进行解析，配合try-catch。可先让智能体在思维链中确认自己的输出格式。 2.记录与审查中间状态：实现详细的日志系统，记录每个阶段的输入和原始输出。卡住时，检查上阶段的输出日志。 3.设置超时与重试：为每个阶段设置超时时间，并设计重试逻辑（可能使用不同的提示词微调）。
Token节省效果不显著	1. 阶段划分不合理，粒度太粗。 2. 上下文传递没有做摘要和聚合，传递了原始长文本。 3. 每个阶段内部使用了不必要的长思维链或多轮对话。	1.进行Token审计：在日志中记录每个API调用的输入输出Token数。分析哪个阶段、哪个智能体消耗最大。 2.实施强制摘要：在阶段交接处，插入一个轻量级的“摘要智能体”或规则引擎，强制将上游输出压缩至固定Token数以内。 3.优化提示词：使用“直接回答”、“无需解释过程”等指令，抑制非必要的CoT。
最终输出质量下降	1. 过度聚合导致信息丢失。 2. 使用了能力不足的模型处理关键阶段。 3. 阶段间上下文传递丢失了重要隐性信息。	1.实施质量检查点：在关键阶段后（如研究阶段后），引入一个“质量评估”子阶段，用小成本模型判断信息是否充分，若不充分则触发重新执行或补充。 2.A/B测试模型：对质量敏感的阶段（如撰写、最终判断），对比不同模型的输出效果，找到成本与质量的平衡点。 3.传递“评估元数据”：除了内容摘要，同时传递上游智能体对自身输出的置信度评分，供下游智能体参考。
系统异常处理不足	智能体输出不可控内容（如拒绝回答、胡言乱语），导致流程中断。	1.设计熔断与降级：当某个智能体连续失败，调度器应能跳过该阶段，或使用一个更简单、更稳定的备用流程。 2.实现输入/输出净化：对输入和输出进行基本的清洗（如截断过长文本、过滤敏感词）。 3.完善监控告警：对错误率、平均响应时间、Token消耗速率进行监控，设置阈值告警。

5.2 进阶优化技巧

动态阶段规划：对于高度不确定的任务，可以让第一个“规划师”智能体动态生成后续阶段计划，而不仅仅是执行固定流程。这增加了灵活性，但需要更复杂的调度器来管理动态生成的任务图。
智能体记忆与缓存：对于频繁使用的、相对静态的信息（如公司背景、产品功能），可以为智能体配备一个向量数据库缓存。智能体在回答问题前，先查询缓存，避免重复生成相同内容，节省Token。
基于成本的实时调度决策：调度器在决定调用哪个模型时，不仅考虑能力，还实时查询API的当前定价（如果有多版本模型）和自身的预算消耗，做出成本最优的决策。
验证回路（Validation Loop）：在关键输出点（如报告完成前），引入一个“验证”阶段。用一个轻量级但可靠的模型（或规则集）快速检查输出是否满足基本要求（如包含所有要求的关键点、无事实矛盾）。如果不满足，则回退到特定阶段重做，避免在错误的方向上浪费更多资源。

Phase-Scheduled Multi-Agent Systems 的本质，是将软件工程中的模块化、流水线、微服务等思想，应用到了大语言模型智能体的协作上。它通过牺牲一部分智能体间自由交互的“灵性”，换来了可控性、可预测性和极高的成本效益。在当下大模型API成本仍是重要考量因素的阶段，这套设计范式对于构建可持续、可规模化部署的复杂AI应用，提供了极具价值的实践路径。从我自己的项目经验来看，一旦将混乱的群聊模式改造为清晰的分阶段流水线，Token成本下降30%-50%是常态，而输出质量的一致性和可靠性反而得到了提升。