前阵子团队把产品规划、写代码、技术评审、写文档这几件事分别交给不同的AI代理来做结果很快发现一个尴尬的事实每个AI代理单拎出来都能干但一旦需要它们配合就像几个能力很强但各自为战的同事谁也不知道别人手头在干什么、什么时候交结果、任务卡在哪个环节。更麻烦的是团队里不止一个人产品经理、前端、后端各带各的代理代理和代理之间还得代表不同的人去沟通这就牵扯到权限、优先级、责任边界一整套问题。我把这套系统从零搭起来中间经历了各种翻车、死锁、上下文串台最后沉淀出一套还算能用的多人多AI协同系统架构。这篇文章会把这套架构的拆解逻辑、通信机制、协调策略、踩坑记录一次性讲清楚希望给正在尝试多代理落地的人一些参考。1. 多人多AI协同和单兵代理的架构分水岭1.1 从三个AI开会聊崩说起我的第一版方案很天真三个人每人配一个AI代理把代理拉进同一个群让它们自主开会。结果惨不忍睹。三个代理用的是不同厂家的模型有的支持function calling有的不支持有的上下文窗口只有32K有的自带工具调用还要单独开开关。它们看起来都在说话但说的不是同一套协议。产品经理的代理让后端的代理把接口联调一下后端的代理反问它接口文档在哪个仓库两边聊了十几轮谁也没有调用工具去查我的代理觉得这个对话和自己无关直接沉默到最后超时。这不是模型能力问题是架构问题。单兵代理只需要用户—模型—工具一条链路复杂度很低多人多AI协同的本质是多条链路交叉而且每个代理背后都站着一个真实的人。人的目标不同、优先级不同、可授权的操作范围也不同代理之间一旦要替人去承诺、去执行就必须有明确的边界定义。1.2 分布式系统给了启发但AI协同有自己的特殊性做这块的人很容易想到用微服务那套思路——注册中心、消息队列、服务编排、分布式事务。老实说这套东西确实管用但不能照搬。原因有两点一是AI代理的行为是概率性的同一套输入每次输出可能不一样。分布式系统处理的是确定性故障超时、宕机、消息丢失而多代理系统还要面对模型答非所问工具调用参数幻觉上下文漂移这类非确定性故障。二是人和代理是紧耦合的。普通微服务之间不需要模拟人但每个AI代理都带有主人的意图和权限边界它不能像无状态服务一样随时被替换或重启——你重启了一个代理等于把你同事的数字分身杀掉他手里还没交给系统的待办事项就丢了。所以我把这套架构的目标定得很朴素让多个代理像一支训练有素的远程团队那样协作而不是像一群散兵游勇那样自由发挥。既要确定性又要保留AI的灵活性既要自动化又不能剥夺人的最终控制权。1.3 先明确四个核心问题在设计具体架构前我给自己列了一个问题清单后面所有模块都是围绕这四件事展开的编配一个复杂的任务到了系统里怎么拆解、派发给哪个代理、结果怎么汇总通信代理之间通过什么语言、什么协议交换信息怎么避免鸡同鸭讲协调多个代理同时工作时谁先谁后资源冲突了怎么办任务状态如何保持最终一致权限代理替自己的主人做了多少事哪些决策必须由人拍板这四点也是本文的骨架。接下来我会按照从总体到细节的顺序把这套系统从0到1地拆开来看。2. 总体架构接入层、协调层、执行层的三层切割2.1 为什么必须分三层而不是让代理直接互连一开始我确实试过让代理直接互连——A代理拿到一个需求直接调用B代理的接口把结果转发给C代理。这个方案在只有两三个代理、而且都属于同一个人的时候很爽代码量也小。但只要代理数量超过五个、用户超过三个人立刻失控每个代理要维护和其他所有代理的连接接口签名五花八门调用关系乱成蜘蛛网出一个问题要查半天到底是谁先挑起的。后来我切成了三层结构问题立刻清晰了很多接入层面向用户负责建立会话、绑定代理、收集用户指令、展示协同结果统一对外API。用户不需要知道消息背后是哪个代理在应答。协调层中间的大脑负责任务拆解、代理路由、状态跟踪、冲突仲裁和权限校验。所有对外通信必须经过协调层禁止代理间私自互连。执行层每个AI代理所在的运行时负责真正调用大模型、操作工具、执行任务然后把结果回报给协调层。这有点像一个公司的运作模式执行层是干活的项目组他们之间不直接承诺所有排期和资源由项目经理协调层统一安排。三层结构确实损失了一点点消息直达的效率但换来了全局可见的状态、清晰的故障边界和可控的权限访问点这笔账非常划算。2.2 系统里各模块的职责划分与交互链路在我的实现里项目代号叫MAFSMulti-Agent Fabric System核心模块一共六个模块职责关键实现API Gateway用户接入、会话管理、限流认证FastAPIJWTWebSocketAgent Registry代理注册、能力描述、状态上报PostgreSQL存储元数据Redis缓存在线状态Task Scheduler任务拆解、排期、派发、重试Redis Streams做任务队列优先级队列Message Broker代理间消息传递、事件广播Redis Streams 事件订阅Memory Pool共享上下文存储、会话记忆管理Redis 向量索引用于语义召回Audit Logger全链路日志、操作审计、权限留痕ClickHouse存储按会话ID聚合查询每个AI代理在执行层被封装成一个标准化的Worker对外暴露统一的gRPC接口。Worker内部跑着模型推理、工具调用和本地逻辑但是Worker和Worker之间没有gRPC直达它们只能通过Message Broker收发事件所有的路由和校验都在协调层完成。这个设计的核心收益是你能把代理当作可替换的演员来管理而不是缠在一起的线团。某个代理挂了系统可以把它从注册表摘除把任务重新分配给同能力的备份代理某个代理需要升级模型也只需要重启一个Worker对整个系统的影响面是可控的。3. 代理间通信协议与上下文流转设计3.1 不要发明新协议但消息结构必须标准化代理之间最常犯的错误是直接传自然语言。自然语言信息量大但歧义也大而且接收方模型的理解能力直接影响消息处理质量。你让Agent A传给Agent B一句这个事有点问题B可能根本不知道是什么问题。要解决这个问题消息必须带上结构化字段。我的方案是代理间通信基于一个明确的Message Envelope包含固定元数据自由payload{ msg_id: a1b2c3d4, msg_type: task_assigned, from_agent: pm_agent, to_agent: backend_agent, session_id: proj_alpha, timestamp: 1710000000, priority: 5, payload: { task_id: t-1024, action: code_review, target_repo: repo/service-a, deadline: 2024-03-12T18:00:00Z, description: review the auth refactor PR } }msg_type我固定了七种task_assigned、task_ack、task_result、task_progress、request_clarify、clarify_response、human_escalation。所有业务内容塞在payload里接收方首先解析msg_type决定走哪条业务分支再用payload里的字段驱动工具调用或模型生成。有人问为什么不直接全部用自然语言原因是让模型解析结构化消息的可靠性远高于让模型自己生成结构化行为。你让模型根据收到的内容决定下一步做什么它可能脑补出各种奇怪行为但你让它收到task_assigned就调用评审工具、收到request_clarify就查阅上下文并回复行为就稳定得多。这是工程系统用AI的正确姿势——把AI放在流程节点里而不是把流程交给AI自己发明。3.2 全局状态机每个代理挂在什么阶段必须可查多代理协同最可怕的场景是一个代理认为任务已经完成另一个代理还在苦等任务明明超时了却没人触发重试。为了杜绝这种状态漂移我在协调层为每个任务维护了一个显式状态机PENDING排队中 →ASSIGNED已派发 →ACKED代理已接单 →RUNNING执行中 →REVIEWING结果校验中 →COMPLETED完成 /FAILED失败 /NEED_HUMAN需人工介入任何一次状态迁移都会写入PostgreSQL状态存储 广播到Redis Streams事件流。所有代理和用户端都能订阅状态变化前端界面因此可以实时展示backend_agent正在评审PR已完成60%。没有这个状态机多代理协作的每分每秒都在猜别人在干嘛有了它整个系统的运行轨迹就是一条可追溯的时间线。3.3 上下文共享Memory Pool不是把聊天记录堆在一起多人多AI协同里上下文管理比单代理复杂得多因为你面对的是多对多的会话多个真实用户、多个AI代理、多个任务主题交织在一起。如果每个代理只维护自己的对话窗口它不知道项目里其他人之前聊过什么决定如果把所有消息都塞给每个代理上下文窗口瞬间爆掉而且会引入大量无关信息干扰推理。我做的Memory Pool分三层Session Memory一次会话内的关键信息按session_id隔离所有参与该会话的代理可以读取。内容按重要性摘要化超过阈值自动压缩。Project Memory跨会话的长期信息包括项目目标、决策记录、代码仓库地址、约束条件。用向量化存储代理需要的时候按语义相似度召回。Personal Memory单个代理私有的信息比如某个开发代理的习惯、偏好、常用工具链。只对该代理可见其他代理无权访问。这里要注意的是AI代理在任务执行过程中不该实时扫描所有历史记录这样既慢又贵。我的做法是协调层在派发任务时把和任务相关的Memory片段作为预加载上下文一并塞到消息里代理执行时的上下文窗口只包含这些预加载内容 当前任务信息。Memory Pool的召回发生在派发任务之前而不是发生在代理推理过程中这降低了代理本身的复杂度。4. 代为交互的落地权限模型与人的监督闸门4.1 代理不是自主的人是你的授权代表标题里的代为交互是这套系统的灵魂。所谓AI代理代为交互不是说代理可以完全自主地替用户做所有决定而是说代理在用户授权的边界内代替用户去和其他代理进行交互和承诺。这跟现实中的授权委托是一样的你可以替老板发一封会议邀请但你不能替老板签合同。我把授权边界拆成了四级每级对应不同类型的操作L0 只读级代理只能读取共享信息、查询任务状态不能对外发送任何操作请求。L1 操作级代理可以调用工具执行任务读写代码、发消息、运行脚本但不能对外承诺交付时间也不能修改涉及其他代理的公共状态。L2 承诺级代理可以代表用户接受任务、承诺交付时间、协调资源。这是代为交互的核心级别代理相当于获得了团队内的话语权。L3 决策级代理可以直接拍板一些用户预先授权过的决策比如如果测试覆盖率低于80%就自动驳回PR但必须在规则白名单内。权限判断放在协调层而不是在每个代理内部。也就是说backend_agent想向pm_agent承诺明天交付这个动作会先到协调层的Permission Service校验backend_agent的主人在当前项目里是否有L2以上权限。如果权限不足协调层会拒绝这条消息并通知用户您的代理尝试做出超出授权的承诺。4.2 关键闸门什么样的决策必须转人工即便授予了L2甚至L3权限系统里依然留了一批硬性人工闸门。设计原则是当AI代理的行为可能导致不可逆后果时必须由真人确认。我总结了三类情况必须转人工影响外部系统比如给客户发正式邮件、删除生产环境数据、对外发布公告。这类操作一旦执行错误成本极高AI再自信也不能让它直接操作。超出预授权范围代理的权限是用户事先划定的白名单一旦任务突破了白名单边界比如要购买第三方服务、要新增云资源立即挂起并通知用户。代理间反复冲突无法自行消解两个代理在资源占用或方案选择上扯了三轮以上还无法收敛说明问题已经超出了技术协调范畴需要人来裁决。转人工闸门不是简单地把问题丢给用户而是要携带充分的上下文——协调层会把冲突双方的立场、尝试过的方案、各自依赖的信息打包成一张请求决策单自动推送到用户的工作台。用户只需在一个界面上选择支持谁、拒绝谁、或者补充新条件然后系统继续执行。这套机制避免了用户来回翻聊天记录的痛苦。4.3 会话隔离谁的信息能让谁看到的边界多用户接入带来了一个单代理系统不存在的敏感问题用户A的代理替A说了句话B能不能看到如果不做隔离A和B的代理共享一个上下文池A的意图可能被B的代理在无关任务中偷看到这在企业内部是绝对不可接受的。我的做法是引入会话域的概念。每个会话域包含一份成员名单、一份可见性策略和一份共享记忆空间。代理在通信时会声明自己所属的会话域协调层校验消息双方是否在同一域内。私聊场景的会话域只有两个成员群聊是N个代理对代理的协同任务一般使用一个临时的任务域任务结束即销毁。这样既保证了协同所需的信息共享又严格限制了信息的扩散范围。5. 任务协调与控制面拆解、仲裁、同步的实操经验5.1 任务拆解的两种模式智能拆分和规则拆分多代理协同的第一步是任务拆解。拆得太粗一个代理的活太重会拖慢整个链路拆得太细代理之间通信开销大于干活本身。我的经验是按任务确定性程度选择两种模式规则拆分适用于流程高度固定的任务。比如完成一次需求上线我可以预设一个DAG有向无环图前端代理完成UI改动→后端代理完成API实现→联调→测试代理生成用例并执行→文档代理补充文档。每个节点有明确的输入输出和前置依赖协调层的Task Scheduler按依赖关系依次派发。这种模式稳定、可预测、方便定位问题。智能拆分适用于探索性任务。比如调研两个方案的优劣并给出建议连AI自己也不知道该怎么分步骤这时候协调层会让主代理先做一个初步的调研规划调用模型分解子任务再把子任务分发出去最后汇总各子任务的结果。智能拆分的准确性依赖模型的规划能力我一般在关键节点还会让用户确认一下拆解结果防止方向性错误。实际使用中最常见的错误是把规则拆分的任务硬塞给智能代理做规划结果模型把本来很明确的流程改得乱七八糟。正确的选择逻辑是凡是人工已经定义过流程的任务一律走规则拆分只有人工定义不了的开放性问题才走智能拆分。5.2 三种协同模式实践对比编排、协商与市场拆解完之后任务协调要回答多个代理同时进行时以什么节奏推进。我在实践中试过三种协同模式。编排式Orchestration协调层像指挥家一样一步步告诉每个代理该做什么前面的完成了再触发后面的。优点确定性强状态好追踪缺点是编排逻辑需要大量人工设计而且处理动态变化的能力弱。协商式Negotiation代理之间通过消息你来我往地达成一致协调层只负责记录和监督。比如前端代理想知道后端接口什么时候给两个代理自己商量如果商量不拢再上升到人工闸门。这种方式灵活也能减轻编排层的负担但容易反复沟通、效率偏低而且消息风暴会让审计日志非常难读。市场式Market任务作为一个标发布出来每个代理根据自己的能力、当前负载和兴趣竞标协调层根据投标结果分配任务。这种方式在处理大量可并行、能力重叠的代理群时效率最高但需要额外的竞价算法而且代理投标时的自我认知能力描述会不稳定需要额外的能力背书机制。我的建议是不要试图用单一模式统治所有任务。在这套框架里规则拆分的任务走编排式探索性任务走协商式量大且能力重叠的任务用市场式。协调层根据任务类型自动选择协同模式而不是让用户手工切换。5.3 优先级与互斥两个代理不能同时改同一个文件多代理并发执行时资源冲突是最容易翻车的地方。最典型的例子前端代理和后端代理同时需要修改同一个配置文件或者两个代理同时往同一个目录里写代码最后互相覆盖。这方面的工程化方案借鉴了分布式锁的设计。MAFS里每个资源代码目录、配置文件、外部API的某个额度都有一个对应的锁记录。代理在动手之前必须先向协调层申请资源锁协调层根据资源的互斥属性决定授予还是拒绝。申请不到锁的代理必须等待或改选其他方案而不是强行并行。我初始实现踩过一个坑锁的粒度太粗整个仓库加一把锁导致前后端代理完全无法并行工作效率还不如单代理。后来改成文件目录级锁只有修改同一文件时才互斥不同目录可以并行。这个粒度在实践中既保证了安全又没有牺牲太多效率。5.4 心跳、超时与重试让失败成为一等公民分布式系统工程师都知道一句话在分布式世界里你无法区分慢和死。多AI协同系统同样如此。我见过的最常见死法一个代理执行任务时模型API卡住了任务队列一直等它等到超时了重试策略没配好直接把整个流水线卡死。我的超时与重试配置经验可以总结为一张表环节超时设置重试策略说明代理接收任务ACK10秒3次间隔指数退避超过3次仍未ACK任务转给备用代理代理执行任务按任务估时 x 1.52次间隔30秒执行超时后触发agent内省重新规划再执行代理间协商消息30秒不重试直接上报人工协商类消息重试意义不大该转人就转人资源锁获取5秒5次每次增加锁等待时间仍拿不到锁则丢弃当前任务释放资源这里有个非常关键的心得AI系统的重试不等于原封不动再跑一次。对确定性系统来说重试是安全的但对AI来说同一个prompt再次调用模型输出很可能不同重试反而可能引入不确定行为。所以我的方案是执行超时的任务触发agent内省重规划——让代理先解释自己刚才为什么卡住多模态模型输出formatted错误、工具调用参数错乱、上下文冲突再基于解释修正策略后重试。这个做法在实际运行中把执行成功率从58%拉到了87%左右。6. 模型与工具接入的工程现实6.1 多模型网关不要让每个代理自己选模型不同任务对模型能力的要求不一样。写简单文案用轻量模型就够做复杂代码生成最好用最强模型内部敏感数据处理必须走本地模型。如果每个代理各自对接模型厂商API模型无所谓、切换复杂还容易超出配额预算然后在月底收到一张看不懂的账单。我在执行层前面加了一道模型网关统一管理模型路由、配额、重试、降级。代理只给网关发送任务特征任务类型、上下文大小、隐私级别网关根据策略路由到具体模型。比如任务类型代码生成隐私级别高 → 路由到本地私有化部署的模型任务类型摘要总结上下文8K → 路由到轻量级云端模型任务类型复杂推理上下文32K → 路由到长上下文模型网关还负责模型供应商侧的API限流和配额管理。一套多代理系统跑下来像样的项目团队少说也有几十万token的日消耗如果不在网关卡一道很快就能超预算。这里插一句对多数中小企业来说追求最强的单模型不如学会在合适的任务上用对的模型成本能降一半以上效果不会差太多。6.2 本地模型与外部工具链的接入方式标题熱词里有本地模型和openclawros这类组合这其实对应多代理系统在具体业务落地时的两个方向一个是数据不出内网的隐私场景另一个是代理要和物理世界工具链打通。本地模型接入的路径相对清晰在执行层部署Ollama或vLLM实例后只需要在模型网关注册几个本地模型端点按任务隐私级别路由即可。我个人的经验是本地模型的输出质量虽然和云端顶尖模型还有差距但在结构化任务格式转换、提取、分类上完全够用而且具备两个独特优势一是数据不出门审批流程省一大截二是可以针对自己的业务数据微调越用越准。至于类似OpenClaw这类开源助手框架和ROS机器人操作系统的集成本质上是把外部工具封装成工具插件通过一个工具执行接口挂在代理执行层下面。代理需要操作ROS时通过标准的工具调用协议把指令发给工具执行器执行器再去调用ROS接口。这个设计的好处是代理不需要理解ROS的内部机制它只需要知道有一个工具可以控制无人机旋转90度剩下的过程由工具执行器完成。工具执行器返回的结果是结构化的成功/失败状态数据模型只需要基于结果决定下一步。6.3 工具调用的一致性与回滚策略代理调用外部工具最大的风险是说做就做做错没法挽回。尤其在多代理协同场景里一个代理做了错误操作影响的不只是自己可能污染共享的代码仓库、配置中心、任务状态。我的实践是工具调用也走一次拟执行流程代理生成工具调用意图后先进入一个PREVIEW状态协调层对意图进行校验参数合法性、权限级别、资源冲突检查校验通过后才真正执行。执行结果如果再出现问题通过资源锁记录的快照做回滚。这套机制虽然增加了延迟大概多200ms但相比代理乱改代码然后我来修的成本这点延迟完全可以接受。7. 实测中的瓶颈与踩坑记录四个月跑下来的真实问题7.1 上下文漂移代理会把上一轮任务的信息带到下一轮这是我遇到最多、也最难排查的一类问题。现象是代理在任务A执行到一半时突然冒出一句任务A之前的信息或者把任务B的信息混进任务A的结果里。最开始我以为是prompt写得不够清楚后来一步步排查发现根因在上下文管理——代理执行完一个任务后它的记忆里还残留着之前的对话状态新任务一旦没有覆盖这段状态模型就会自然而然地把旧信息关联进来。解决办法是在派发新任务时显式重置执行上下文并且让代理在开场先复述任务目标——这是最简单的AI对齐技巧让代理用自己的话描述当前任务如果描述出现偏差说明上下文串了协调层在这个环节就能发现异常及时重新初始化。这个复述动作增加了大概一秒延迟但极大地减少了上下文污染导致的问题。7.2 代理间死锁互相等待的恶性循环死锁出现的形式很隐蔽两个代理各自持有对方需要的资源同时又在等对方释放资源谁也无法前进。比如Agent A在写接口文档需要Agent B确认接口参数Agent B却在改代码需要Agent A先把文档里的参数改掉再继续。两边都在等对方系统直接陷入僵局。单纯靠超时机制能缓解但不能根治——就算超时后重新执行资源状态已经进入互相依赖的局面还是会反复触发。后来我在协调层加了一个依赖环检测器每次任务进入WAITING状态时协调层检查整个会话域里的等待关系图如果发现环直接把这个环上的任务全部挂起转人工仲裁。这是用图算法解决AI系统协调问题的典型例子解决方式比依赖各种重试机制可靠得多。7.3 从能跑通到能上线工程化要补的课很多人做多代理Demo跑通了第一个应用就觉得任务完成了。实际上从Demo到稳定运行还有一道深不见底的坑要过审计日志的可观测性、监控告警、代理行为回放、权限变更的审计、成本分摊。我在最初两周每天花大量时间翻日志就是因为在多代理协同里一个问题的根因经常跨越三四个模块没日志根本定位不了。经验总结下来有三件事尽早做全链路追踪必须从第一天做每个消息带上trace_id控制台能按trace_id把所有参与代理的执行步骤串成一条时间线。监控指标要分两层系统层消息延迟、队列堆积、锁等待时长和AI层任务成功率、重试率、上下文压缩次数。后者往往更早暴露出问题。代理操作审计要比人更严格所有对外写入操作必须留痕不然出了问题根本说不清是哪个代理干的、干了什么、基于哪条指令干的。踩过这些坑之后我对多AI协同系统的态度从挺酷变成了如履薄冰。它确实能把团队从琐碎的信息搬运中解放出来但也要求你像对待分布式系统一样敬畏它——该加锁的地方加锁该有超时的地方有超时该让人拍板的地方决不交给代理自己决定。对我来说真正的架构稳定不是某个模块多巧妙而是当代理A卡住时代理B不会无休止地空转当用户C离开工位他的代理不会越界承诺任何它不该承诺的事。这套系统现在还在根据使用反馈一点一点打磨但至少它已经从一个研究原型变成了团队日常工作中离不开的协作基础设施。