1. 项目概述当多智能体系统开始“内卷”通信最近在折腾LLM多智能体系统时我遇到了一个非常具体且恼人的问题Token消耗失控。我们团队设计了一个由多个LLM智能体协作完成复杂任务的系统初期效果不错但随着任务复杂度提升和智能体数量增加整个系统的运行成本主要是API调用Token消耗呈指数级增长很快就变得不可持续。问题的核心在于所有智能体之间都在进行“全连接”式的广播通信每个智能体都要接收和处理来自其他所有智能体的冗长消息导致大量冗余的上下文信息和重复计算。这让我开始思考在自然界的高效协作系统中比如蜂群信息传递并非杂乱无章。工蜂、侦察蜂、蜂后之间有着清晰、动态变化的通信拓扑。受此启发我们设计并实现了一个名为QueenBee Planner的框架。它的核心思想很简单让多智能体系统中的通信拓扑结构能够像技能一样根据任务需求和智能体的表现进行动态演化从而在保证协作效果的前提下极致地优化Token使用效率。简单来说QueenBee Planner不再让智能体们进行“开会式”的群聊而是为它们建立了一个可智能调整的“沟通汇报关系网”。这个网络会根据谁擅长什么、当前任务需要什么动态决定谁和谁需要直接对话谁可以只听不说从而砍掉大量不必要的通信开销。接下来我将详细拆解这个框架的设计思路、核心机制、实现细节以及我们趟过的一些坑。2. 通信拓扑多智能体系统的效率瓶颈与演化契机在深入QueenBee Planner之前我们必须先理解“通信拓扑”为何成为多智能体系统的阿喀琉斯之踵。传统的多智能体框架如基于AutoGPT或CrewAI的思路通常采用两种模式中心化协调一个主控智能体分发任务、收集结果或民主化讨论所有智能体在一个共享上下文中广播消息。2.1 全连接拓扑的Token灾难民主化讨论模式在架构上近似一个“全连接”图。假设系统中有N个智能体每个智能体生成一条长度为L的消息。在同步通信轮次中每个智能体需要将其他N-1个智能体的消息作为上下文输入那么单轮通信的总Token消耗仅考虑消息传递至少是O(N * (N-1) * L)即近似O(N² * L)。当N5 L200一段简短的分析单轮消耗就高达4000个Token。这还不包括每个智能体内部推理消耗的Token。对于需要多轮迭代的复杂任务成本瞬间爆炸。注意这里的计算是高度简化的。实际中LLM的上下文窗口有长度限制长消息会被截断或总结但这本身又引入了额外的计算和可能的精度损失。2.2 静态拓扑的局限性为了降低成本很自然的想法是采用静态的、稀疏的通信拓扑比如星型一个中心协调者、环型或分层树状结构。这确实能降低Token消耗。例如星型拓扑下总通信量是O(N * L)。然而静态拓扑的缺点同样明显单点故障星型拓扑中的中心节点一旦做出错误决策或“宕机”整个系统可能瘫痪。能力错配一个被设计为“中继”的节点可能恰好是解决当前子问题的专家但由于拓扑限制它的意见需要经过多跳才能传达造成信息延迟和衰减。缺乏适应性任务阶段变化时所需的协作模式也不同。早期可能需要“头脑风暴”高连通度后期则需要“专项执行”低连通度。静态拓扑无法适应这种变化。因此理想的多智能体通信拓扑应该是动态的、稀疏的、且与任务及智能体能力相匹配的。这就是QueenBee Planner中“Skill-Evolving”概念的由来——通信能力本身被视为一种可进化、可学习的“技能”。3. QueenBee Planner 核心机制技能化拓扑演化QueenBee Planner 将整个系统建模为一个随时间演化的图G(t) (V, E(t))。其中顶点集合V代表所有智能体是固定的。边集合E(t)代表t时刻的通信连接是动态变化的。演化的动力来源于两个方面任务需求和智能体的历史表现技能画像。3.1 智能体技能画像的构建与量化每个智能体a_i都维护一个动态的技能向量s_i。这个向量不是预先设定的标签如“编程专家”、“文案高手”而是从历史交互中隐式学习得到的。我们采用的方法是记录智能体a_i在历史上对各类“问题-上下文”的响应并使用一个轻量级的嵌入模型如BGE-M3或text-embedding-3-small将“问题描述”和“该智能体提供的解决方案”分别编码为向量。通过对比学习或简单的相关性分析我们可以得到a_i的“能力向量”c_i和“表达风格向量”e_i共同构成技能画像s_i。例如在一个包含编码、写作、数据分析智能体的系统中编码智能体对“实现一个快速排序函数”这类问题的解决方案会与“算法”、“Python”、“递归”等概念在向量空间高度相关。写作智能体对“润色一段产品介绍”的解决方案会与“营销话术”、“流畅度”、“吸引力”等概念相关。这个画像会随着智能体成功其建议被采纳并最终导向任务成功或失败的经历而更新。成功经历会强化其在该问题领域的技能向量权重。3.2 基于任务分解的通信需求生成QueenBee Planner 的核心是一个轻量级的“规划器”模块Planner它本身可以是一个小参数LLM如Qwen2.5-7B或一组启发式规则。给定一个总任务T规划器首先将其分解为一系列有依赖关系的子任务{t_1, t_2, ..., t_k}。关键的一步是规划器会为每个子任务t_j生成一个期望技能向量d_j。这可以通过分析子任务描述得到。例如子任务“分析销售数据并生成趋势图表”的d_j会靠近“数据分析”、“可视化”、“统计”等向量。3.3 拓扑演化算法连接、评估与重构有了智能体技能画像s_i和子任务需求d_j拓扑演化就可以进行了。这个过程是周期性的例如每完成一个子任务或每经过N轮通信后触发。步骤一需求-技能匹配与核心边建立对于当前需要解决的子任务t_j计算所有智能体a_i的技能向量s_i与任务需求向量d_j的余弦相似度。选取相似度最高的前M个智能体例如M2或3它们被认定为解决该子任务的“核心小组”。在它们之间建立全连接或强连接高带宽允许长消息通信确保专家之间能充分讨论。步骤二效率驱动的稀疏边添加核心小组需要其他智能体的信息吗这里引入“信息增益”评估。规划器会模拟或基于历史数据估计将某个非核心智能体a_x的信息加入核心小组讨论可能带来的收益如提供关键背景数据与成本增加的Token消耗。只有信息增益/成本比超过某个阈值时才会在a_x和核心小组的某个代理节点之间建立一条单向、带宽受限的边。带宽受限意味着消息需要被总结或压缩后才能传递。步骤三无效连接的修剪与遗忘系统持续监控每条边(a_u, a_v)的“效用”。效用可以通过以下指标衡量信息流价值通过这条边传递的消息有多少比例在后续决策中被引用或采纳活跃度在过去一段时间内这条边是否被频繁使用 如果一条边的效用长期低于阈值它将被移除。这模拟了团队中沟通不畅或无关紧要的渠道被自然淘汰的过程。步骤四拓扑结构的持久化与迁移当系统从一个任务类型切换到另一个相似任务类型时上一次任务中演化出的高效拓扑结构可以被部分“继承”或作为初始化状态从而加速新任务的协作磨合实现“经验”的复用。通过这四个步骤QueenBee Planner 系统就形成了一个动态变化的通信网络在需要深度协作的专家间建立强连接在需要补充信息时建立高效的弱连接并不断淘汰无效连接。4. 实现详解从理论到可运行的代码框架理论听起来不错但如何实现我们基于Python和流行的LLM调用库如Litellm, OpenAI SDK构建了一个原型。以下是核心模块的拆解。4.1 系统架构与模块组成整个框架包含以下核心模块Agent Pool (智能体池)管理所有智能体实例每个智能体封装了一个LLM调用客户端、一个本地技能画像向量和一段历史交互记忆。Planner (规划器)负责任务分解、需求向量生成、以及执行拓扑演化算法。我们实现了一个基于规则和轻量级LLM混合的Planner。Topology Manager (拓扑管理器)维护当前的图结构G(t)提供接口供智能体查询“我可以和谁通信”并负责消息的路由与转发。路由时会根据边的“带宽”设置决定是传递原始消息还是调用一个“总结者”模型进行压缩。Skill Profiler (技能分析器)后台进程持续分析智能体间的交互日志更新它们的技能画像向量s_i。Communication Bus (通信总线)实际的消息传递层处理异步通信、消息队列并记录详细的通信日志用于分析和计费。4.2 关键数据结构与代码片段智能体类定义class QueenBeeAgent: def __init__(self, agent_id, llm_client, role_description): self.id agent_id self.llm llm_client self.role role_description self.skill_vector None # 初始为None后续由Skill Profiler更新 self.memory [] # 有限长度的交互记忆 def respond(self, task_context, from_agent_id): 核心响应方法。会根据拓扑决定接收哪些消息作为上下文。 # 1. 从Topology Manager获取当前可见的消息已由总线投递 visible_messages self._get_visible_messages() # 2. 组织Prompt包含角色、任务、历史、当前可见消息 prompt self._compose_prompt(task_context, visible_messages) # 3. 调用LLM生成响应 response self.llm.generate(prompt) # 4. 将交互记录到内存并发送到通信总线进行广播由拓扑管理器决定实际接收者 self._record_interaction(prompt, response, from_agent_id) return response拓扑管理器中的演化函数简化版class TopologyManager: def evolve_topology(self, current_task_vector, agent_pool): 根据当前任务需求演化拓扑 # 1. 计算所有智能体与当前任务的技能匹配度 similarities {} for agent in agent_pool.agents.values(): if agent.skill_vector is not None: sim cosine_similarity(current_task_vector, agent.skill_vector) similarities[agent.id] sim # 2. 选择核心小组 (Top-K) core_agents sorted(similarities.items(), keylambda x: x[1], reverseTrue)[:self.config.core_group_size] core_agent_ids [a_id for a_id, _ in core_agents] # 3. 建立核心小组全连接 new_edges set() for i in range(len(core_agent_ids)): for j in range(i1, len(core_agent_ids)): new_edges.add((core_agent_ids[i], core_agent_ids[j], high_bandwidth)) # 边属性高带宽 # 4. 为每个核心智能体评估并添加有价值的稀疏边 for core_id in core_agent_ids: potential_helpers [aid for aid in agent_pool.agents if aid not in core_agent_ids] for helper_id in potential_helpers: # 评估信息增益与成本这里简化为例行评估 if self._evaluate_edge_value(core_id, helper_id, current_task_vector): # 建立单向、低带宽边从helper到core new_edges.add((helper_id, core_id, low_bandwidth)) # 5. 应用新拓扑并修剪旧的低效用边 self._apply_new_topology(new_edges) self._prune_low_utility_edges()4.3 Token效率的度量与监控为了证明系统的有效性我们定义了以下几个关键指标进行监控Token Per Action (TPA)完成一个原子动作如生成一段代码、做出一个决策平均消耗的Token数。包括所有智能体的输入输出。Communication Overhead Ratio (COR)通信消耗的Token数 / 总消耗Token数。在冗余通信多的系统中这个比例会很高。Task Success Rate with Budget Constraint在给定Token预算下系统完成复杂任务的比率。在我们的对比实验中对于一个5智能体的产品设计任务市场分析、用户画像、功能设计、UI草图描述、技术可行性评估固定Token预算下使用静态全连接拓扑的成功率约为40%而使用QueenBee Planner的动态拓扑成功率提升至85%且平均TPA下降了约60%。5. 实战踩坑从理想模型到稳定系统在开发QueenBee Planner的过程中我们遇到了许多预料之外的问题以下是三个最具代表性的“坑”及其解决方案。5.1 技能画像的冷启动与偏差累积问题问题描述系统初始化时所有智能体的技能向量为空或随机。最初的几次任务分解和匹配几乎是随机的可能导致“专家”智能体被排除在核心小组之外做出错误决策进而污染技能画像——系统可能错误地强化了某个智能体在不擅长领域的权重。我们的解决方案预训练与种子标签在系统正式部署前用一个简单的任务集对每个智能体进行“面试”。例如给编程智能体一堆编程问题给写作智能体一堆润色任务。根据其回答的质量人工或用一个评估模型为其生成初始的技能向量“种子”。这大大加速了冷启动过程。引入探索机制在拓扑演化算法中我们以一个小概率ε例如5%随机选择一名非Top-K的智能体加入核心小组。这类似于强化学习中的ε-greedy策略保证了系统有一定的探索能力避免陷入局部最优的通信模式。画像衰减与重置为技能向量引入一个“衰减因子”。久未更新的技能维度权重会缓慢下降。同时如果某个智能体在某个领域连续失败可以触发该领域权重的部分重置。5.2 消息压缩与信息损失的权衡问题描述为了节省Token低带宽边上的消息需要被压缩。我们最初使用另一个LLM来总结消息但这带来了两个新问题1) 总结本身消耗Token和时间2) 总结可能丢失关键细节导致下游智能体误解。我们的解决方案采用分层消息传递协议。元数据优先每条消息必须附带一个由发送方生成的、结构化的元数据包括消息类型决策、数据、疑问、建议、关键实体列表、情感倾向积极/消极/中性、紧迫度。这个元数据非常简短几十个Token。按需索取接收方智能体先看到元数据。如果根据元数据判断需要了解详情它可以沿着原路径发起一个“请求详情”的回调。发送方此时再传递完整消息或更详细的摘要。智能总结对于确定需要压缩传递的消息我们训练了一个极轻量的文本摘要模型基于T5-small专门针对技术讨论、决策逻辑等场景进行优化而不是使用通用的、昂贵的LLM进行总结。这个协议类似于“先看标题再决定是否点开正文”在实践中减少了超过70%的非必要长消息传递。5.3 拓扑振荡与系统稳定性问题描述在任务边界或评估阈值附近拓扑可能频繁重构。例如智能体A和B的技能评分在阈值上下波动导致它们之间的边被反复创建和删除。这种振荡消耗了额外的规划资源并可能打断智能体间刚刚建立的协作默契。我们的解决方案迟滞阈值为边的创建和删除设置不同的阈值。创建一条边需要更高的“效用预期”而删除一条边则需要其效用低于一个更低的“失效阈值”。两者之间的区域为稳定区。拓扑变更冷却期在一次拓扑演化后设置一个最短时间窗口在此窗口内禁止新的演化除非遇到严重错误。这给了智能体们一个稳定的协作周期。变更影响评估在执行删除操作前进行轻量级的模拟预测评估删除该边是否可能导致某个关键子任务无法完成。如果是则暂缓删除并可能通过增加边的带宽限制来替代删除。6. 扩展思考QueenBee Planner 的适用边界与未来方向经过多个项目的实践QueenBee Planner 在任务可分解、智能体角色有差异性的场景下表现卓越例如复杂代码项目开发、多步骤研究分析、创意内容生成流程等。但它并非银弹。不适用或需谨慎使用的场景高度实时、同步的决策环境如自动驾驶车群协同拓扑演化的计算开销和延迟可能无法接受。智能体同质化严重如果所有智能体基于同一个LLM且没有差异化微调或角色设定技能画像难以区分拓扑演化的收益有限。任务极度模糊、不可分解如果Planner无法对任务进行有效分解和需求向量化整个演化过程就失去了依据。可能的未来优化方向离线学习与拓扑模板库将成功完成某类任务后形成的稳定拓扑结构保存为“模板”。当接到类似新任务时直接加载模板作为初始拓扑实现“开箱即用”的高效协作。引入博弈论与激励机制让智能体不仅被动接受拓扑还能主动“推销”自己的技能甚至为建立高价值连接付出“代价”虚拟Token从而形成一个更有机的、去中心化的拓扑形成市场。与外部工具链的深度集成将代码仓库、API文档、知识库等外部工具也视为特殊的“工具智能体”并为其建模技能向量。这样QueenBee Planner 就能动态决定何时该让LLM智能体直接讨论何时该去查询文档或执行一段代码形成人-机-工具混合的高效协作网络。实现一个Token高效的多智能体系统远不止是调用多个GPT API那么简单。它涉及到对协作本质、信息论和资源约束的深度思考。QueenBee Planner 是我们朝着这个方向迈出的一步其核心——将通信结构视为可优化的对象并让其根据能力和任务动态演化——为我们打开了一扇新的大门。在LLM API成本仍是实际制约的今天这种对效率的极致追求或许比单纯追求更强大的模型本身能带来更直接的回报。 QueenBee Planner：动态通信拓扑优化多智能体系统Token效率
1. 项目概述当多智能体系统开始“内卷”通信最近在折腾LLM多智能体系统时我遇到了一个非常具体且恼人的问题Token消耗失控。我们团队设计了一个由多个LLM智能体协作完成复杂任务的系统初期效果不错但随着任务复杂度提升和智能体数量增加整个系统的运行成本主要是API调用Token消耗呈指数级增长很快就变得不可持续。问题的核心在于所有智能体之间都在进行“全连接”式的广播通信每个智能体都要接收和处理来自其他所有智能体的冗长消息导致大量冗余的上下文信息和重复计算。这让我开始思考在自然界的高效协作系统中比如蜂群信息传递并非杂乱无章。工蜂、侦察蜂、蜂后之间有着清晰、动态变化的通信拓扑。受此启发我们设计并实现了一个名为QueenBee Planner的框架。它的核心思想很简单让多智能体系统中的通信拓扑结构能够像技能一样根据任务需求和智能体的表现进行动态演化从而在保证协作效果的前提下极致地优化Token使用效率。简单来说QueenBee Planner不再让智能体们进行“开会式”的群聊而是为它们建立了一个可智能调整的“沟通汇报关系网”。这个网络会根据谁擅长什么、当前任务需要什么动态决定谁和谁需要直接对话谁可以只听不说从而砍掉大量不必要的通信开销。接下来我将详细拆解这个框架的设计思路、核心机制、实现细节以及我们趟过的一些坑。2. 通信拓扑多智能体系统的效率瓶颈与演化契机在深入QueenBee Planner之前我们必须先理解“通信拓扑”为何成为多智能体系统的阿喀琉斯之踵。传统的多智能体框架如基于AutoGPT或CrewAI的思路通常采用两种模式中心化协调一个主控智能体分发任务、收集结果或民主化讨论所有智能体在一个共享上下文中广播消息。2.1 全连接拓扑的Token灾难民主化讨论模式在架构上近似一个“全连接”图。假设系统中有N个智能体每个智能体生成一条长度为L的消息。在同步通信轮次中每个智能体需要将其他N-1个智能体的消息作为上下文输入那么单轮通信的总Token消耗仅考虑消息传递至少是O(N * (N-1) * L)即近似O(N² * L)。当N5 L200一段简短的分析单轮消耗就高达4000个Token。这还不包括每个智能体内部推理消耗的Token。对于需要多轮迭代的复杂任务成本瞬间爆炸。注意这里的计算是高度简化的。实际中LLM的上下文窗口有长度限制长消息会被截断或总结但这本身又引入了额外的计算和可能的精度损失。2.2 静态拓扑的局限性为了降低成本很自然的想法是采用静态的、稀疏的通信拓扑比如星型一个中心协调者、环型或分层树状结构。这确实能降低Token消耗。例如星型拓扑下总通信量是O(N * L)。然而静态拓扑的缺点同样明显单点故障星型拓扑中的中心节点一旦做出错误决策或“宕机”整个系统可能瘫痪。能力错配一个被设计为“中继”的节点可能恰好是解决当前子问题的专家但由于拓扑限制它的意见需要经过多跳才能传达造成信息延迟和衰减。缺乏适应性任务阶段变化时所需的协作模式也不同。早期可能需要“头脑风暴”高连通度后期则需要“专项执行”低连通度。静态拓扑无法适应这种变化。因此理想的多智能体通信拓扑应该是动态的、稀疏的、且与任务及智能体能力相匹配的。这就是QueenBee Planner中“Skill-Evolving”概念的由来——通信能力本身被视为一种可进化、可学习的“技能”。3. QueenBee Planner 核心机制技能化拓扑演化QueenBee Planner 将整个系统建模为一个随时间演化的图G(t) (V, E(t))。其中顶点集合V代表所有智能体是固定的。边集合E(t)代表t时刻的通信连接是动态变化的。演化的动力来源于两个方面任务需求和智能体的历史表现技能画像。3.1 智能体技能画像的构建与量化每个智能体a_i都维护一个动态的技能向量s_i。这个向量不是预先设定的标签如“编程专家”、“文案高手”而是从历史交互中隐式学习得到的。我们采用的方法是记录智能体a_i在历史上对各类“问题-上下文”的响应并使用一个轻量级的嵌入模型如BGE-M3或text-embedding-3-small将“问题描述”和“该智能体提供的解决方案”分别编码为向量。通过对比学习或简单的相关性分析我们可以得到a_i的“能力向量”c_i和“表达风格向量”e_i共同构成技能画像s_i。例如在一个包含编码、写作、数据分析智能体的系统中编码智能体对“实现一个快速排序函数”这类问题的解决方案会与“算法”、“Python”、“递归”等概念在向量空间高度相关。写作智能体对“润色一段产品介绍”的解决方案会与“营销话术”、“流畅度”、“吸引力”等概念相关。这个画像会随着智能体成功其建议被采纳并最终导向任务成功或失败的经历而更新。成功经历会强化其在该问题领域的技能向量权重。3.2 基于任务分解的通信需求生成QueenBee Planner 的核心是一个轻量级的“规划器”模块Planner它本身可以是一个小参数LLM如Qwen2.5-7B或一组启发式规则。给定一个总任务T规划器首先将其分解为一系列有依赖关系的子任务{t_1, t_2, ..., t_k}。关键的一步是规划器会为每个子任务t_j生成一个期望技能向量d_j。这可以通过分析子任务描述得到。例如子任务“分析销售数据并生成趋势图表”的d_j会靠近“数据分析”、“可视化”、“统计”等向量。3.3 拓扑演化算法连接、评估与重构有了智能体技能画像s_i和子任务需求d_j拓扑演化就可以进行了。这个过程是周期性的例如每完成一个子任务或每经过N轮通信后触发。步骤一需求-技能匹配与核心边建立对于当前需要解决的子任务t_j计算所有智能体a_i的技能向量s_i与任务需求向量d_j的余弦相似度。选取相似度最高的前M个智能体例如M2或3它们被认定为解决该子任务的“核心小组”。在它们之间建立全连接或强连接高带宽允许长消息通信确保专家之间能充分讨论。步骤二效率驱动的稀疏边添加核心小组需要其他智能体的信息吗这里引入“信息增益”评估。规划器会模拟或基于历史数据估计将某个非核心智能体a_x的信息加入核心小组讨论可能带来的收益如提供关键背景数据与成本增加的Token消耗。只有信息增益/成本比超过某个阈值时才会在a_x和核心小组的某个代理节点之间建立一条单向、带宽受限的边。带宽受限意味着消息需要被总结或压缩后才能传递。步骤三无效连接的修剪与遗忘系统持续监控每条边(a_u, a_v)的“效用”。效用可以通过以下指标衡量信息流价值通过这条边传递的消息有多少比例在后续决策中被引用或采纳活跃度在过去一段时间内这条边是否被频繁使用 如果一条边的效用长期低于阈值它将被移除。这模拟了团队中沟通不畅或无关紧要的渠道被自然淘汰的过程。步骤四拓扑结构的持久化与迁移当系统从一个任务类型切换到另一个相似任务类型时上一次任务中演化出的高效拓扑结构可以被部分“继承”或作为初始化状态从而加速新任务的协作磨合实现“经验”的复用。通过这四个步骤QueenBee Planner 系统就形成了一个动态变化的通信网络在需要深度协作的专家间建立强连接在需要补充信息时建立高效的弱连接并不断淘汰无效连接。4. 实现详解从理论到可运行的代码框架理论听起来不错但如何实现我们基于Python和流行的LLM调用库如Litellm, OpenAI SDK构建了一个原型。以下是核心模块的拆解。4.1 系统架构与模块组成整个框架包含以下核心模块Agent Pool (智能体池)管理所有智能体实例每个智能体封装了一个LLM调用客户端、一个本地技能画像向量和一段历史交互记忆。Planner (规划器)负责任务分解、需求向量生成、以及执行拓扑演化算法。我们实现了一个基于规则和轻量级LLM混合的Planner。Topology Manager (拓扑管理器)维护当前的图结构G(t)提供接口供智能体查询“我可以和谁通信”并负责消息的路由与转发。路由时会根据边的“带宽”设置决定是传递原始消息还是调用一个“总结者”模型进行压缩。Skill Profiler (技能分析器)后台进程持续分析智能体间的交互日志更新它们的技能画像向量s_i。Communication Bus (通信总线)实际的消息传递层处理异步通信、消息队列并记录详细的通信日志用于分析和计费。4.2 关键数据结构与代码片段智能体类定义class QueenBeeAgent: def __init__(self, agent_id, llm_client, role_description): self.id agent_id self.llm llm_client self.role role_description self.skill_vector None # 初始为None后续由Skill Profiler更新 self.memory [] # 有限长度的交互记忆 def respond(self, task_context, from_agent_id): 核心响应方法。会根据拓扑决定接收哪些消息作为上下文。 # 1. 从Topology Manager获取当前可见的消息已由总线投递 visible_messages self._get_visible_messages() # 2. 组织Prompt包含角色、任务、历史、当前可见消息 prompt self._compose_prompt(task_context, visible_messages) # 3. 调用LLM生成响应 response self.llm.generate(prompt) # 4. 将交互记录到内存并发送到通信总线进行广播由拓扑管理器决定实际接收者 self._record_interaction(prompt, response, from_agent_id) return response拓扑管理器中的演化函数简化版class TopologyManager: def evolve_topology(self, current_task_vector, agent_pool): 根据当前任务需求演化拓扑 # 1. 计算所有智能体与当前任务的技能匹配度 similarities {} for agent in agent_pool.agents.values(): if agent.skill_vector is not None: sim cosine_similarity(current_task_vector, agent.skill_vector) similarities[agent.id] sim # 2. 选择核心小组 (Top-K) core_agents sorted(similarities.items(), keylambda x: x[1], reverseTrue)[:self.config.core_group_size] core_agent_ids [a_id for a_id, _ in core_agents] # 3. 建立核心小组全连接 new_edges set() for i in range(len(core_agent_ids)): for j in range(i1, len(core_agent_ids)): new_edges.add((core_agent_ids[i], core_agent_ids[j], high_bandwidth)) # 边属性高带宽 # 4. 为每个核心智能体评估并添加有价值的稀疏边 for core_id in core_agent_ids: potential_helpers [aid for aid in agent_pool.agents if aid not in core_agent_ids] for helper_id in potential_helpers: # 评估信息增益与成本这里简化为例行评估 if self._evaluate_edge_value(core_id, helper_id, current_task_vector): # 建立单向、低带宽边从helper到core new_edges.add((helper_id, core_id, low_bandwidth)) # 5. 应用新拓扑并修剪旧的低效用边 self._apply_new_topology(new_edges) self._prune_low_utility_edges()4.3 Token效率的度量与监控为了证明系统的有效性我们定义了以下几个关键指标进行监控Token Per Action (TPA)完成一个原子动作如生成一段代码、做出一个决策平均消耗的Token数。包括所有智能体的输入输出。Communication Overhead Ratio (COR)通信消耗的Token数 / 总消耗Token数。在冗余通信多的系统中这个比例会很高。Task Success Rate with Budget Constraint在给定Token预算下系统完成复杂任务的比率。在我们的对比实验中对于一个5智能体的产品设计任务市场分析、用户画像、功能设计、UI草图描述、技术可行性评估固定Token预算下使用静态全连接拓扑的成功率约为40%而使用QueenBee Planner的动态拓扑成功率提升至85%且平均TPA下降了约60%。5. 实战踩坑从理想模型到稳定系统在开发QueenBee Planner的过程中我们遇到了许多预料之外的问题以下是三个最具代表性的“坑”及其解决方案。5.1 技能画像的冷启动与偏差累积问题问题描述系统初始化时所有智能体的技能向量为空或随机。最初的几次任务分解和匹配几乎是随机的可能导致“专家”智能体被排除在核心小组之外做出错误决策进而污染技能画像——系统可能错误地强化了某个智能体在不擅长领域的权重。我们的解决方案预训练与种子标签在系统正式部署前用一个简单的任务集对每个智能体进行“面试”。例如给编程智能体一堆编程问题给写作智能体一堆润色任务。根据其回答的质量人工或用一个评估模型为其生成初始的技能向量“种子”。这大大加速了冷启动过程。引入探索机制在拓扑演化算法中我们以一个小概率ε例如5%随机选择一名非Top-K的智能体加入核心小组。这类似于强化学习中的ε-greedy策略保证了系统有一定的探索能力避免陷入局部最优的通信模式。画像衰减与重置为技能向量引入一个“衰减因子”。久未更新的技能维度权重会缓慢下降。同时如果某个智能体在某个领域连续失败可以触发该领域权重的部分重置。5.2 消息压缩与信息损失的权衡问题描述为了节省Token低带宽边上的消息需要被压缩。我们最初使用另一个LLM来总结消息但这带来了两个新问题1) 总结本身消耗Token和时间2) 总结可能丢失关键细节导致下游智能体误解。我们的解决方案采用分层消息传递协议。元数据优先每条消息必须附带一个由发送方生成的、结构化的元数据包括消息类型决策、数据、疑问、建议、关键实体列表、情感倾向积极/消极/中性、紧迫度。这个元数据非常简短几十个Token。按需索取接收方智能体先看到元数据。如果根据元数据判断需要了解详情它可以沿着原路径发起一个“请求详情”的回调。发送方此时再传递完整消息或更详细的摘要。智能总结对于确定需要压缩传递的消息我们训练了一个极轻量的文本摘要模型基于T5-small专门针对技术讨论、决策逻辑等场景进行优化而不是使用通用的、昂贵的LLM进行总结。这个协议类似于“先看标题再决定是否点开正文”在实践中减少了超过70%的非必要长消息传递。5.3 拓扑振荡与系统稳定性问题描述在任务边界或评估阈值附近拓扑可能频繁重构。例如智能体A和B的技能评分在阈值上下波动导致它们之间的边被反复创建和删除。这种振荡消耗了额外的规划资源并可能打断智能体间刚刚建立的协作默契。我们的解决方案迟滞阈值为边的创建和删除设置不同的阈值。创建一条边需要更高的“效用预期”而删除一条边则需要其效用低于一个更低的“失效阈值”。两者之间的区域为稳定区。拓扑变更冷却期在一次拓扑演化后设置一个最短时间窗口在此窗口内禁止新的演化除非遇到严重错误。这给了智能体们一个稳定的协作周期。变更影响评估在执行删除操作前进行轻量级的模拟预测评估删除该边是否可能导致某个关键子任务无法完成。如果是则暂缓删除并可能通过增加边的带宽限制来替代删除。6. 扩展思考QueenBee Planner 的适用边界与未来方向经过多个项目的实践QueenBee Planner 在任务可分解、智能体角色有差异性的场景下表现卓越例如复杂代码项目开发、多步骤研究分析、创意内容生成流程等。但它并非银弹。不适用或需谨慎使用的场景高度实时、同步的决策环境如自动驾驶车群协同拓扑演化的计算开销和延迟可能无法接受。智能体同质化严重如果所有智能体基于同一个LLM且没有差异化微调或角色设定技能画像难以区分拓扑演化的收益有限。任务极度模糊、不可分解如果Planner无法对任务进行有效分解和需求向量化整个演化过程就失去了依据。可能的未来优化方向离线学习与拓扑模板库将成功完成某类任务后形成的稳定拓扑结构保存为“模板”。当接到类似新任务时直接加载模板作为初始拓扑实现“开箱即用”的高效协作。引入博弈论与激励机制让智能体不仅被动接受拓扑还能主动“推销”自己的技能甚至为建立高价值连接付出“代价”虚拟Token从而形成一个更有机的、去中心化的拓扑形成市场。与外部工具链的深度集成将代码仓库、API文档、知识库等外部工具也视为特殊的“工具智能体”并为其建模技能向量。这样QueenBee Planner 就能动态决定何时该让LLM智能体直接讨论何时该去查询文档或执行一段代码形成人-机-工具混合的高效协作网络。实现一个Token高效的多智能体系统远不止是调用多个GPT API那么简单。它涉及到对协作本质、信息论和资源约束的深度思考。QueenBee Planner 是我们朝着这个方向迈出的一步其核心——将通信结构视为可优化的对象并让其根据能力和任务动态演化——为我们打开了一扇新的大门。在LLM API成本仍是实际制约的今天这种对效率的极致追求或许比单纯追求更强大的模型本身能带来更直接的回报。