小模型大协作：SLM多Agent协同框架设计

可视化演示

展示小语言模型多Agent协同框架：编排器协调规划者、执行者、审查者三类角色，通过结构化通信协议实现任务分配与结果聚合。切换模式查看不同协作机制。

角色分工设计

后厨里没有谁是全能的。主厨不切菜，切配师傅不炒菜，传菜员不掌勺，品控师傅只检查不烹饪。每个人都只干自己最拿手的活，菜品质量才能稳定下来。SLM多Agent框架也遵循同样的逻辑：单靠一个“什么都会一点”的小模型，远不如把一个团队拆成明确角色、各守一摊来得可靠。

在SLM多Agent协同系统中，“角色分工”是最顶层的设计决策。一个典型的架构包含四种角色：决策者Agent负责拆解用户请求、决定子任务派发给谁；执行者Agent接收分配的任务，用自身的小模型能力完成具体子任务；协调者Agent维护整个系统的运行状态，同步各Agent进度，处理依赖关系；监督者Agent负责检查输出质量，过滤低质量或有害结果，防止“垃圾进垃圾出”。这四种角色既可以由同一个SLM通过不同提示词切换，也可以分配给多个独立的SLM实例。

如何判断一个任务该交给谁？我们可以用匹配度分数来量化。

这就像主厨在菜单上勾选“这道菜归哪个师傅”：川菜找川菜师傅，甜品找甜品师傅。角色分工的价值，就是让每个Agent永远只做自己最擅长的菜。

通信协议机制

后厨高峰期最怕传菜员对所有厨师喊“这个菜是谁的？”每个人都被打断，切配的手一抖，炒菜的火候就过了。所以餐厅规定了一套喊话格式：“五号桌宫保鸡丁”只有炒锅师傅响应，“三号桌蒸鱼”只有蒸锅师傅接。统一的喊话方式，就是后厨的通信协议。

Agent之间也一样。通信协议要回答三个问题：消息长什么样？消息怎么送达？谁优先送达？在SLM多Agent框架中，消息通常采用结构化的JSON格式，至少包含发送者、接收者、消息类型和载荷内容四个字段。路由方式主要有四种：广播适合一对多通知，比如决策者向所有执行者广播任务；轮询是接收方每隔一段时间主动查询消息队列，实现简单但实时性一般；令牌传递让一个令牌在环形网络里按顺序流转，只有拿到令牌的Agent才允许发言，从物理上避免消息冲突；优先级通道则为紧急消息开辟一条“快车道”，让高优任务插队。

通信不可能永远成功，所以协议还要考虑可靠重试。一条消息发一次可能会丢，重试 $n$ 次后到达的概率是多少？

传菜员喊一次没应就再喊一次，只要重复足够多次，厨师总能听到。通信协议的意义，就是让“喊话”既有格式可依，又有可靠的兜底。

任务分配策略

主厨不会把所有凉菜都堆给一个师傅。他扫一眼每个人的排队数量，手头活儿少的师傅优先接新菜单。任务分配的本质，就是“能力匹配”和“负载均衡”的双重博弈。

在SLM多Agent架构中，任务分配的目标有三个：做得好、做得快、别累垮。能力匹配是硬约束，任务优先发给技能项命中的Agent；负载均衡用于防止某一个Agent的推理队列过长；动态调度在运行过程中根据实时负载持续微调；失败重试则在某Agent执行失败后把任务转交给下一个合适的Agent。

整体完工时间由谁决定？答案是系统里最慢的那个环节。设 Agent i 当前队列负载为 $L_i$，新任务预估耗时 $a_i$，则全体完工时间可以表示为：

主厨只要盯着最忙的那个师傅，保证他的排队不超阈值，整条出菜线就稳了。

结果聚合机制

一道菜出锅前，主厨会亲自尝一口、看看色泽，还会让身边的师傅互相打量一眼。确认没跑味，才肯走菜。多个Agent分别给出答案之后，同样需要一个“走菜”环节——把零散结果聚合成一个可信的最终答案。

结果聚合要解决两件事：谁说了算？意见矛盾怎么办？常用的机制有四种。投票表决是最直接的方式，少数服从多数；加权融合更进一步，每个Agent按置信度或历史准确率拥有不同权重，权重高者的意见更算数；管道接力适合顺序型任务，比如一个Agent负责检索、下一个Agent负责总结、再下一个负责润色；冲突消解负责兜底，当不同Agent的答案严重冲突时，要么选置信度最高的，要么直接返回“不确定”让用户澄清。

多个Agent各自的投票如何合并成最终答案？加权投票的数学表达如下：

几个师傅都说“咸了”，那这道菜就真的咸了；只有一个人说咸、其他人沉默，那就按多数人的感受上菜。结果聚合，就是把个体判断升级为团队判断。

架构设计原则

后厨的动线决定了出菜效率：备菜区、炒菜区、出菜口互不交叉，一个灶台坏了，其他灶台照常烧。多Agent系统也一样，角色和通信方式定好之后，还需要几条顶层架构原则来保证整个团队长期稳定。

第一条是去中心化。不要把所有控制逻辑放在一个Agent身上，否则它一旦崩溃全系统瘫痪。第二条是模块化插拔。每个Agent最好是独立模块，换掉一个执行者不必改动其他组件。第三条是协议标准化。消息格式公开统一，不同Agent之间才能自由互操作，新Agent也能即插即用。第四条是故障隔离。某个Agent出错时，错误应该被限制在局部，而不是沿消息链扩散传染。

这四条原则最终都指向一个量化目标——系统可用性。假设每个Agent的可用性为 $A_i$，系统只要有任意一个Agent存活就能继续运行，那么整体可用性为：

哪怕一个师傅临时请假，只要其他师傅还在灶台上，后厨就能继续出菜。架构设计给系统的“余量”，就是它在意外面前的底气。

资源受限适配

小店后厨就一张案板、两口灶，但照样能出菜单上的每一道菜。秘诀是什么？提前把复杂菜式的半成品备好，高峰时快速组合出餐。SLM要跑在手机、智能音箱、车载盒子上，同样得精打细算。

资源受限适配有四个常用手段。模型量化把模型权重从32bit浮点数压成8bit整数，内存占用直接缩到四分之一；内存调度通过分时复用和按需加载，保证多个Agent不打架；算力分摊利用多核CPU或NPU并行执行不同Agent的推理任务；离线运行依赖本地权重和缓存，断网也照常服务。这套组合拳，让“微型后厨”也能撑起整张菜单。

但压缩是有代价的。量化前后的数值差异，会直接影响模型输出质量。我们定义量化误差为：

菜谱从精装版变成口袋本，关键配料和火候比例还在，端上来的菜味道就差不了太远。资源受限适配，就是用工程手段把“味道损失”控制到最低。

AI 应用场景

Python 演示

import randomfrom collections import Counter  class Agent:    def __init__(self, name, role, skills):        self.name = name        self.role = role        self.skills = set(skills)        self.load = 0        self.mailbox = []     def receive(self, task):        self.mailbox.append(task)     def respond(self, task):        if task["type"] in self.skills:            return self.name, task["type"], 0.9        if random.random() < 0.2:            return self.name, "guess", 0.3        return self.name, "none", 0.0  def dispatch(agents, task):    best = None    score = -1.0    for agent in agents:        s = 1.0 if task["type"] in agent.skills else 0.0        s -= agent.load * 0.05        if s > score:            score = s            best = agent    return best  def aggregate(results, lead_name):    votes = Counter()    total = 0.0    for name, answer, conf in results:        if answer == "none" or conf <= 0:            continue        weight = conf + (0.5 if name == lead_name else 0.0)        votes[answer] += weight        total += weight    if not votes:        return "none", 0.0    top = votes.most_common(1)[0]    return top[0], top[1] / total  def main():    agents = [        Agent("chief", "coordinator", ["plan", "route"]),        Agent("worker_a", "executor", ["parse", "fetch"]),        Agent("worker_b", "executor", ["classify"]),        Agent("supervisor", "supervisor", ["verify"]),    ]    tasks = [        {"type": "parse", "text": "turn on light"},        {"type": "classify", "text": "cat photo"},        {"type": "plan", "text": "go to station"},    ]    for task in tasks:        lead = dispatch(agents, task)        print("ASSIGN {} -> {}".format(task["type"], lead.name))        results = []        for agent in agents:            agent.receive(task)            results.append(agent.respond(task))        answer, conf = aggregate(results, lead.name)        print("RESULT {} conf={:.0%}".format(answer, conf))        for agent in agents:            if agent.name == lead.name:                agent.load += 1  if __name__ == "__main__":    main()

1. class Agent:定义一个Agent类，封装名字、角色（coordinator/executor/supervisor）、技能集合、当前负载和消息邮箱。
2. def respond(self, task):Agent对任务作答：命中技能返回0.9置信度的答案，否则有20%概率随机猜一个低置信度答案，其余返回"none"。
3. def dispatch(agents, task):任务分配函数：匹配技能得1分，再减去负载乘以0.05的惩罚项，得分最高者接单。
4. s = 1.0 if task["type"] in agent.skills else 0.0能力匹配的硬编码逻辑：擅长该类型任务就加分，不然不加。
5. def aggregate(results, lead_name):结果聚合函数：对每个有效答案按置信度加权，领衔Agent额外加0.5权重。
6. weight = conf + (0.5 if name == lead_name else 0.0)权重设计：执行者本身置信度越高权重越大，被选中的主导Agent再加成。
7. top = votes.most_common(1)[0]取加权票数最高的答案作为团队最终结果。
8. agent.load += 1每次任务完成后给接单Agent增加负载，让后续分配自动避开热点。

常见误区

面试题