Agent工作流：多Agent协作Multi-Agent

可视化演示

演示多Agent角色分工、通信协议与协作决策机制，展示Agent通过消息传递与协商达成共识，协同完成复杂任务。

认识多Agent——从一人餐厅到协作团队

小林的面馆故事还有一个更深的隐喻：他最初让“一个自己”同时承担七个岗位，本质上是个体能力的天花板——一个人再厉害，双手也只有两只。单Agent也是如此：一个LLM系统要依次完成意图理解、信息检索、方案生成、结果检查，上下文窗口有限，单次推理顾此失彼，复杂任务经常做到一半就“忘记”了前面的要求。

多Agent协作Multi-Agent，就是把“一个人的超级多面手”拆成“一群人的专业团队”：每个Agent是独立的AI单位，有自己的职责、记忆与工具，彼此通过消息协作。Agent类型也各有分工：执行型Agent（检索Agent、代码Agent）负责干活，决策型Agent（规划Agent、评判Agent）负责出主意，协调型Agent（编排Agent）负责派单。协作模式上，有接力式的流水线协作，也有围绕一个共享目标的并行协作。

不过，团队协作并非没有代价——多了沟通、同步和等待时间。我们用“协作加速比”来度量收益：

小林的面馆从1人扩张到4人，翻台率提高了不只4倍，但也新增了催单、传话、分工不清的摩擦成本。多Agent协作同理：专业分工是收益，协作开销是代价。合理控制Agent数量与沟通成本，餐厅才能真正蒸蒸日上。

协作架构——店长、后厨与微信群

面馆变成餐厅后，小林开始琢磨组织结构。一开始他是“总指挥”，所有事情都要经过他——新来的配菜师连“能不能给3号桌加个蛋”都要跑来问他。后来大家建了个微信群直接沟通，结果一上午消息刷了几百条。最后他定下规则：加菜、换菜这类小事先自行解决，退单、投诉这类大事才上报店长。这就是三种协作架构的原型。

多Agent架构决定了消息如何在Agent之间流动。中心化架构（Centralized）中，一个编排Agent作为“大脑”统一调度所有成员，类似LangGraph中的Supervisor模式，优点是决策一致、过程可追踪，缺点是大脑容易成为瓶颈。去中心化架构（Decentralized）中，各Agent对等协商，类似AutoGen的GroupChat聊天组，灵活鲁棒，但话题容易漂移。混合架构则分层治理——高层定计划，底层自由协作，在真实项目中应用最广。

架构选择直接影响通信成本。如果每个Agent都要和其余所有Agent建立连接，链路总数是指数级膨胀的：

如果后厨10个人都在群里互相@，消息量会爆炸式增长——这就是N²通信问题。架构选择就是“设计餐厅的汇报关系”：谁向谁汇报、谁可以自主决策。好的架构让信息有序流动，坏的架构让人人都累得慌。

角色分工——配菜师的锅铲不归主厨

新餐厅招人时，小林写的招聘启事特别细：配菜师负责洗切，主厨负责烹饪，品控负责试菜，传菜员只负责端盘子。没有明确职责的餐厅必然混乱。这份“岗位说明书”，就是多Agent世界里的角色定义（Role）。

技术上，角色定义通过System Prompt实现，让Agent清楚“你是谁、你要产出什么、你不该做什么”。角色分工带来三重好处：一是每个Agent专注单一目标，输出质量更高；二是职责边界清晰，避免两个Agent重复劳动；三是出问题时可以快速定位到具体环节。任务分配是角色分工的落地环节——编排器把大任务拆成子任务，再按“匹配度”路由给对应Agent。上下文管理则确保每个Agent只拿到与自身角色相关的信息，而不是被塞进全部对话历史。

任务路由并非随机分配，而是按照各Agent对任务类型的匹配度计算概率：

好的餐厅不允许配菜师跑去炒菜——分工明确，出品才能稳定。多Agent的角色定义，就是给每个AI打上清晰的“岗位说明书”，谁也别越界，谁也别缺席。

协作策略——订单的流水与并行

餐厅的点餐流程通常是“下单→配菜→烹饪→出餐”，一步接一步，这是顺序编排。后来餐厅多了两个灶台，两张订单的烹饪可以同时进行——这就是并行协同。若顾客突然要求“少油少盐”，前厅要和后厨沟通调整，碰上两份订单抢同一个灶台，还得有人拍板。这些决策，就是协作策略要解决的问题。

多Agent协作策略规划的是“任务以什么顺序、由谁、在什么条件下执行”。顺序编排（Sequential）最简单，Agent A处理完交给Agent B，适合强依赖的流水线任务。并行协同（Parallel）把互相独立的子任务同时分发，显著提升吞吐量。协商机制（Negotiation）让Agent们交换信息、互相说服，弥合分歧。投票表决（Voting）则让多个Agent对候选方案表决，以多数意见做最终决策。

并行不是免费的午餐，Amdahl定律揭示了一个朴素的道理：

餐厅的终极追求是“让每个灶台都不闲着”，但下单和摆盘永远串行。多Agent策略优化的本质，就是在串行瓶颈与并行收益之间找平衡，而不是盲目加人。

记忆与通信——白板、传菜口与围裙口袋

小林在厨房挂了一块白板，上面写着“3号桌不吃香菜”“7号桌在等打包”。传菜口是前厅与后厨唯一的物理通道，所有菜品消息都从那个小窗口递进递出。与此同时，每个厨师私人的围裙口袋里装着自己的小笔记本。这一套系统，完美对应了多Agent的记忆与通信设计。

多Agent的记忆分为共享记忆（Shared Memory）与私有记忆（Private Memory）：白板是共享的，围裙口袋是私有的。共享记忆通常实现为一个公共消息池或全局缓冲区，让第五步的“调研结果”能被第八步的“写作Agent”直接引用。消息传递（Message Passing）则通过消息队列或Agent间直接调用，把上下文从一个Agent搬运到另一个。状态同步确保各Agent对“任务进展到哪一步”有共识，而信息隔离则划清界限：敏感信息如用户密码不进入共享白板，无关信息不污染单一Agent的推理。

记忆总量是实打实的Token成本，可以用预算公式表示：

白板写太满，后厨反而找不到重点——共享记忆要够用，私有记忆要安全，消息传递要精准。多Agent工程的记忆设计，直接决定成本与准确性，是整个协作体系的“信息底座”。

性能优化——翻台率与成本账

餐厅的利润公式其实很简单：翻台率乘以客单价减去成本。小林发现午市门口排长队，店里却有空桌，症结是“上菜太慢”。他改用预配菜（缓存）、增加一个灶台（并行）、失败菜品免费重做（重试策略），翻台率立刻上去了。多Agent系统的性能优化，同样是围绕延迟、成本、质量三个指标展开。

延迟优化靠并行化与结果缓存：把独立子任务同时下发，把重复查询的结果缓存复用。成本控制则要求精打细算——精简Agent角色数量、小模型处理简单子任务、复用中间结果，避免每个环节都调用最大最强的大模型。冲突解决需要明确的仲裁规则：两个Agent给出矛盾结论时，由编排器按预设策略裁决，或触发重试。质量评估则引入评分与反馈闭环，对每个Agent的输出进行可量化的验证，形成“生成→评判→修正”的增强回路。

所有优化最终都要落到成本账上：

餐厅的最终目标不是“人越多越好”，而是“每桌都赚钱”。多Agent优化同样追求性价比——在可接受的延迟与质量范围内，把成本压到最低。这是从“Demo能跑”走向“生产可用”的关键一步。

实战展望——从单店到连锁

面馆火了之后，小林要开第二家店。他不再亲自上阵，而是把菜品配方、出餐流程、服务标准写成SOP手册，培训一个店长去复制。这个“手册化、框架化”的过程，正是多Agent从实验走向工程的关键一跃。

目前典型的多Agent框架各具特色：AutoGen主打对话式多Agent协作，让Agent们在群聊中商讨问题；LangGraph用有向图定义工作流，节点是Agent、边是状态转移，可编排可回滚；CrewAI以“角色+任务”为核心，让每个Agent像员工一样认领任务。项目实践上，智能客服、数据分析管线、复杂代码生成都已大量采用多Agent架构。常见故障也很有代表性：Agent陷入无意义对话死循环、幻觉在传递中被一步步放大（“以讹传讹”）、Token成本失控超出预算。工程上需要设置超时上限、最大迭代次数、信息摘要压缩和事实核查节点来兜底。

如果系统中某个环节需要“多个Agent分别给出方案，再择优采用”，整体成功率会显著提升：

连锁餐厅靠的不是某一位大厨，而是可复制的系统。多Agent正从“有趣的实验”走向“企业级生产基础设施”，谁先掌握协作编排的工程能力，谁就拿到了下一代AI应用的入场券。

AI 应用场景

Python 演示

import randomimport time  class BaseAgent:    def __init__(self, name, role):        self.name = name        self.role = role        self.task_count = 0        self.message_count = 0     def process(self, task):        time.sleep(random.uniform(0.05, 0.12))        self.task_count += 1        return "[{}]".format(self.name)     def send(self, receiver, message):        self.message_count += 1        return receiver.receive(self.name, message)     def receive(self, sender, message):        self.message_count += 1        return "{}<-{}:{}".format(self.name, sender, message)  class Worker(BaseAgent):    def process(self, task):        time.sleep(random.uniform(0.08, 0.16))        self.task_count += 1        return "{}处理了[{}]".format(self.name, task)  class Inspector(BaseAgent):    def process(self, task):        time.sleep(random.uniform(0.05, 0.10))        self.task_count += 1        return "{}验收了[{}]".format(self.name, task)  class ShopManager(BaseAgent):    def __init__(self, name, member_list):        BaseAgent.__init__(self, name, "manager")        self.member_list = member_list     def dispatch(self, order):        result = self.process(order)        for member in self.member_list:            result += " -> " + self.send(member, result)        return result  def main():    prep = Worker("配菜师", "prep")    cook = Worker("主厨", "cook")    critic = Inspector("品控官", "inspector")    boss = ShopManager("店长", [prep, cook, critic])     orders = ["订单1:红烧肉", "订单2:清蒸鱼", "订单3:麻婆豆腐"]    for order in orders:        final_result = boss.dispatch(order)        print(final_result)        print("---")     all_workers = [prep, cook, critic, boss]    total_tasks = sum(a.task_count for a in all_workers)    total_msg = sum(a.message_count for a in all_workers)    print("总任务数:", total_tasks)    print("总消息数:", total_msg)  if __name__ == "__main__":    main()

1. class BaseAgent:定义所有Agent的公共基类，相当于餐厅员工的“岗位手册”，包含名字、角色、任务计数和消息计数。
2. class ShopManager(BaseAgent):店长Agent继承基类，额外承担编排职责，是中心化架构里的“大脑”。
3. self.member_list = member_list保存所有下属Agent的引用列表，方便后续按顺序派单。
4. def dispatch(self, order):编排核心方法：接收一笔订单，分发给每一位团队成员处理。
5. result += " -> " + self.send(member, result)关键协作动作：把当前进度消息发送给下一个成员，形成接力式的流水线。
6. total_msg = sum(a.message_count for a in all_workers)统计整个团队的通信总量，帮助我们直观感受多Agent协作中的消息开销。

常见误区

面试题