最近在做多人多AI协同系统架构的预研发现一个很有意思的现象大家讨论最多的往往是“哪个模型又多强了”“本地模型部署到哪一步了”但真正难啃的骨头压根不在这——而是多个AI代理之间怎么协作、它们代表谁的利益、出了问题谁负责。我带着团队跑了几轮实验把AI代理、消息总线、记忆引擎、仲裁器这些组件拼在一起搭了一套“代理代为交互”的原型系统。这篇文章不聊模型本身重点把整体架构、关键机制、踩过的坑和一组实测数据一次说清楚希望对同样在探索这个方向的人有点用。1. 从“人手一个AI”到“代理代表你参会”这个架构要解决的现实问题先说一个我自己的体验。上个月小组做技术方案评审六个人每人电脑上都开着两三个AI聊天窗口。产品经理问“发布方案谁帮我看看风险”开发说他刚让AI写了一版评估但不知道发给谁测试那边也攒了一份检查清单最后所有信息都堆进共享文档没人分得清哪些内容经过人工确认、哪些是AI直接生成的、哪些已经过时。这一刻我意识到一件很本质的事给每个人配一个AI助手不等于团队能用好AI协作。单人多AI本质上还是用户自己在多个聊天框之间复制粘贴真正的多人多AI协同需要一个不一样的抽象每个用户拥有一个能代表自己、替自己与其他AI系统沟通的代理Agent整个系统围绕“代理间交互”而不是“模型间调用”来设计。1.1 信息孤岛每个AI聊天窗口都是一座孤岛传统用法里AI服务的边界就是一个聊天会话。用户聊完一个话题上下文就锁在那个窗口里。团队里A的AI不知道B的AI聊过什么更不可能主动承接下一个环节的工作。我做过一个小调研一个10人团队用各类AI助手的场景里90%的信息流转还是靠人肉搬运——从AI窗口复制到文档再发到群里再被别人贴进另一个AI窗口。这种方式有三个硬伤信息不同步同一份需求不同代理基于不同上下文给出互相矛盾的结论责任不明确AI生成的建议没人认领后续没人跟进校验上下文不连续跨天、跨任务之后AI完全不记得自己曾经给过什么结论。所以这套架构的第一个目标很朴素打破“一个聊天窗口一个孤岛”的状态让代理之间通过结构化消息直接对话把协作链路从“人肉搬运”变成“代理接力”。1.2 代理代交互给每个用户配一个“数字秘书”“代理代为交互”是我在这套系统里反复强调的核心概念。它不是让模型更聪明而是改变了交互的主体过去是人直接跟AI对话现在是人跟自己的代理对话代理再以你的名义去跟别的代理、别的AI服务交互。你可以把代理理解成一个有身份、有记忆、有权限边界的数字秘书有身份每个代理绑定一个真实用户知道“我是谁”“我能代表谁做决定”有记忆它记得用户的长期偏好、历史决策和领域知识不用每次重新交代背景有工具它能调用代码、检索文档、读取数据不只是输出文本有边界关键决策必须回到用户那里审批代理不能越权承诺。直接让用户一个人同时操作多个AI与让用户的代理去跟其他代理打交道体验上有一个关键差异前者需要用户自己协调、自己背锅后者把协调工作下沉到了系统层用户只需要在关键节点做监督和授权。1.3 适合与不适合的边界这套架构适合的领域有一个共同点任务可以拆解、责任可以明确、过程需要可追溯。比如项目管理、研发协同、市场调研、代码评审、活动策划这类场景就很合适。反过来高风险决策场景如医疗诊断、司法判断、财务放款现阶段不应该让代理自治即便要用也必须设计强制人工审批节点代理只能做信息汇总和风险评估。2. 动手设计前的三个关键判断身份、记忆与仲裁架构图画起来容易真正动手才发现有三个问题如果不在设计前期想清楚后面处处受制代理的身份怎么建模记忆归谁所有多代理意见冲突时听谁的。这三个问题都没有标准答案我给出我的判断和理由。2.1 给代理一个“数字人格”我把代理身份设计成了“用户身份的数字延伸”而不是一个独立的系统账号。每个代理有一张代理卡Agent Card记录四类信息字段内容示例身份标识agent ID、绑定用户agent:product_po01绑定用户“张明”能力声明可执行的技能与工具数据分析、文档生成、HTTP调用权限边界可读写的资源范围可读产品需求库不可改财务数据风格画像沟通风格、决策偏好简洁直接偏好量化指标这张代理卡的作用不只是给人看的。每次代理调用大模型时系统会把代理卡里的身份信息注入到系统提示词中并在代理间消息里附带身份签名。这么做的好处是从顶层设计上避免“AI不知道自己是谁”的混乱——这个问题在单聊场景下不明显一旦多代理交互任何一个代理都可能误解自己的角色。2.2 记忆管理要回答“这段记忆是谁的”多代理协同里最常见的认知错误是只要上下文够长代理就能做好。实际上记忆的核心矛盾不是长度而是归属权。同一个信息放错层级会导致两种灾难把该保密的私有信息共享给了所有代理或者把团队共知的决策锁在一个人的私有记忆里导致重复劳动。我采用的方案是做三级记忆隔离私有记忆只有代理自己可读包含用户一对一的历史对话、个人草稿、未公开偏好团队记忆代理间可共享包含项目文档、决策记录、进度状态写入团队记忆需要较高权限公共记忆全系统可读包含制度规范、知识库由管理员维护。实际实现时记忆不是一个大文本而是按条目存储。每个记忆条目带元数据标签创建者代理、创建时间、读取权限。代理读取记忆时先过一遍权限过滤再进入向量检索。这一步直接决定了后续协同的可靠程度。2.3 多代理协同不是并行是仲裁业界聊多代理时爱强调“并行调用”“pipeline流水线”但我做下来最深的体会是多代理协同的本质是仲裁。因为多个代理各自代表不同用户的利益目标天生会冲突。比如产品代理要快速上线研发代理担心质量风险合规代理要加一堆审核流程——每个都合理但没法同时满足。我的设计是让系统层介入仲裁而不是让代理自己吵出结果。仲裁器的规则如下按决策类型划分管辖权技术方案听研发代理的体验问题听设计代理的风险合规听合规代理的同一类型意见冲突时按任务的优先级权重投票权重由任务发起时用户共同设定涉及资源、预算、对外承诺的一律转人工审批代理只有建议权。这套机制看似增加了系统复杂度却避免了一个更麻烦的问题代理之间陷入无限沟通却无法收敛。说到底代理没有真正的利益诉求它们只是在替不同的用户在表达——那冲突就必须回到用户层的授权关系去解决。3. 五层架构落地交互层、代理运行时、编排层、模型网关与基础设施想清楚上面三个判断之后我开始搭具体的系统结构。整体上分为五层每层职责单一、可独立替换这也是分布式系统架构里反复强调的解耦思路——就像交换机把网络切成可管理的交换域一样每层只跟相邻层通信避免大泥球。3.1 分层总览层次核心职责关键组件用户交互层与用户对话、呈现代理行为、审批入口Web聊天界面、审查面板代理运行时层维护代理状态、记忆、工具调用状态机、记忆引擎、工具集编排与仲裁层任务路由、协作编排、冲突仲裁路由器、仲裁器、任务队列模型网关层统一模型接入、路由、上下文管理模型路由、提示词组装、限流基础设施层消息传递、存储、可观测性消息总线、向量库、日志系统依赖方向是单向的上层依赖下层的接口下层不反向依赖上层。这意味着我可以随时替换某一层的具体实现比如把消息总线从一种中间件换到另一种上层完全无感。3.2 用户交互层人的审查比AI的决策更重要交互层表面上是个聊天界面实际承担着一个关键职责代理行为的审查与授权。用户跟代理对话时系统会同时提供一个“代理近期行为面板”显示代理刚刚做了什么、调用了什么工具、准备向谁发送什么消息。涉及敏感操作时代理进入waiting_approval状态消息不会真正发出直到用户在面板上点“批准”。我的理由很简单代理可以自治但不能自主到脱离人的监督。多数任务场景下用户并不想每步都确认所以我把审批策略设计成三级可配置——全自动、关键节点人工确认、全部人工确认。默认是中间档代理能自主完成信息收集、草拟、分析凡是生成外部消息、修改团队记忆、承诺时间节点必须经过用户确认。3.3 代理运行时层状态机、记忆引擎与工具集每个代理在运行时是一个长驻的服务实例内部维护一个状态机idle → receiving → planning → acting → reporting → waiting_approval任何时刻代理都处于其中一个状态。状态机的好处是可控系统能清晰知道每个代理在做什么也能在异常时做状态回退。记忆引擎是这一层最重的模块。我用SQLite存结构化条目用户偏好、决策记录用向量库存非结构化文本会议纪要、文档段落。代理读取记忆时先走权限过滤再做向量检索最后把命中的条目组装进提示词。工具有些是内置的代码执行、HTTP请求、文件读写有些是插件化的企业内部的API比如需求管理系统、Bug追踪系统。3.4 编排与仲裁层多代理协作的交通警察编排层是这套架构里“多人多AI协同”的核心体现。它的职责不是帮代理写内容而是决定“谁该参与这个任务、以什么顺序参与、意见冲突时听谁的”。路由器的输入是任务的类型标签列表输出是参与代理的名单和协作模式后面章节会细说。仲裁器则维护一组规则和决策记录每次争议解决后都会把结论写入团队记忆形成类似判例的沉淀。任务队列也是这一层的重要部分。多代理不是各自想干就干所有跨代理任务都进入统一队列按优先级和依赖关系调度。实测下来这个设计非常必要——没有队列控制两个代理同时修改一份文档导致的覆盖问题在多代理场景下会被放大数倍。3.5 模型网关层本地模型与云端模型的路由策略模型网关把五花八门的模型统一成一套接口内部做路由。这里特别说一下本地模型和云端模型如何混合使用——这是我在预研里花时间最多的一块。策略不是“全上云端”或“全上本地”而是按任务特征路由任务类型路由目标理由代理间内部协商、意图识别本地小模型如Qwen 7B级延迟低、成本低、数据不出域文档摘要、信息抽取本地中型模型效果足够敏感内容可控复杂推理、长文创作、代码审查云端大模型推理质量要求高关键决策建议双模型交叉验证降低单模型幻觉概率这里有个不太直观的经验本地模型的定位不是“平替云端”而是“就近处理低敏感、高频、高实时要求的任务”。代理之间的很多内部沟通其实只需要中等智力水平没必要每次都调用最强的云端模型。省下来的token留给真正需要深度思考的任务效果反而更好。3.6 基础设施层消息、存储与追踪基础设施层里最重要的组件是消息总线。所有代理间消息都走总线而不是点对点直连。这样代理之间完全解耦发送方不需要知道接收方的地址和状态也方便做消息的持久化、重放和审计。存储方面除了记忆用的向量库还需要对象存储保存代理生成的大文件文档、图片、代码包。可观测性这块我用了日志追踪系统给每个协同任务打一个全局trace_id串起所有相关消息和模型调用——没有这个多代理出问题的时候排查起来就是灾难。4. 代理间协作机制详解协议格式、协作模式与异常回退架构定了之后真正的硬骨头在协作机制本身。代理之间怎么说话、怎么分工、谈不拢怎么办、有代理失联怎么处理这些细节决定了系统是“能跑”还是“好用”。4.1 结构化消息协议给代理之间定规矩代理之间不传自然语言碎片而是传递结构化消息。下面是消息的基本格式示例{ message_id: msg_8f3a2c, protocol_version: 1.0, type: task.delegate, sender: agent:product_po01, recipient: agent:tech_lead01, trace_id: trace_d4349f, intent: 请评估发布计划中的技术风险并输出结论, context_refs: [mem:team:release_20250115, mem:public:risk_control_policy], permission_required: read:team_repo, write:risk_log, deadline: 2025-01-20T18:00:00Z, priority: 5, signature: agent:product_po01:timestamp:sig }几个关键字段说明一下。intent是消息的意图系统会先做一次意图识别判断该交给哪个代理、属于什么协作模式这比让模型直接读整条消息更省token也更可控。context_refs是引用记忆条目标识接收方按标识去取具体内容而不是把全文塞在消息里——这是避免上下文爆炸的重要手段。permission_required声明这条消息需要什么权限接收方代理在行动前会校验自己的权限是否覆盖。signature是身份签名防止身份伪造。4.2 三种协作模式委派、协商与黑板多代理协作不是只有一种形态。我在系统里实现了三种模式按任务性质选择主从委派任务发起代理把任务拆分委派给多个执行代理执行代理完成后回报。适合“老板分活”的结构。比如产品发布计划拆成风险分析研发代理、体验检查设计代理、宣传物料运营代理。执行代理之间不直接交互由发起代理汇总。对等协商多个代理平级讨论一个问题各自基于自己的用户视角给出意见由仲裁器做最终裁定。适合意见型任务比如“版本是否达到发布标准”。每个代理先独立分析再提交结论和理由仲裁器按管辖权规则裁决。黑板共享多个代理读写一个共享工作区黑板上的一块空间谁看到有自己能做的就去补充。适合持续演进型任务比如联合编辑一份长期维护的文档。黑板是异步的代理不需要同时在线我用了带版本控制的对象存储来实现。4.3 仲裁与权限链每个决策都要能追到人多代理协同里最敏感的问题就是责任归属。系统里任何决策记录都保留一条完整的授权链提议者代理 → 支持该提议的代理们 → 最终确认的用户或仲裁规则。在审计界面上一条决策可以完整展开“谁提的、谁附议的、根据什么规则定的、哪个环节经过了人工审批”。这样做还有一个额外的好处仲裁规则本身会沉淀成决策记录后续遇到类似冲突可以直接复用不用每次重新吵一遍。4.4 异常处理与回退代理毕竟是大模型驱动天然有不确定性和不稳定性。我预置了三类异常处理机制超时回退消息发出后如果接收代理在设定时间内未响应发起方按策略升级重发一次、改派其他代理、转人工死循环保护任何协作链路的迭代步数设上限超过上限强制进入人工接管流程状态恢复代理状态机实现了检查点进程崩溃后可以从最近一个稳定状态恢复消息队列里的消息不会丢失。这三种机制一开始只做了前两种第三次跑实验时一个代理进程直接崩溃恢复后它完全不记得自己发了什么我才明白消息持久化和状态恢复必须一起做。现在每个代理落地时都会先写检查点再更新状态虽然多了一次写操作但可靠性大幅提升。4.5 记忆跨代理共享的脱敏策略代理之间的记忆共享安全边界比功能更优先。我给记忆读取加了一道脱敏层代理A请求读取团队记忆里的某个条目时系统先把条目通过本地模型跑一遍脱敏识别过滤掉带私有标签的实体人名细节、未公开数字、客户编码输出脱敏版本给代理A。这导致一个意料之中的副作用读取记忆多了几秒延迟。但因为脱敏是本地模型执行的不涉及外部调用延迟可控。5. 技术选型复盘与踩坑实录框架、总线、上下文与死循环这节写的是最折腾人的部分。理论设计再顺落地时总会碰到一些文档里不会写的问题。我把选型思路和六个最典型的坑都放在这里。5.1 Agent框架选型为什么没有直接用AutoGen市面上Agent框架不少主流的LangGraph、AutoGen、CrewAI各有优势。AutoGen的多代理对话能力很强但它的抽象偏重“对话流”对“代理身份绑定用户”“记忆权限隔离”“审批链路”这类的企业协同需求支持较粗改造起来不顺手。LangGraph的好处是状态图模型清晰适合精确定义代理状态流转但团队需要自己补齐记忆、权限、总线这些外围模块。我最终的选择是LangGraph做代理内部的状态编排通信和记忆模块自研。理由很直白多人多AI协同的复杂点不在“让模型聊天聊得久”而在“身份、权限、记忆、仲裁”这套协同基础设施。框架只能解决前30%剩下的还是要自己造轮子。5.2 消息总线选型并发实测与教训消息总线我在NATS、RabbitMQ和Kafka之间比对过。Kafka吞吐高但偏重团队只有几十个代理的场景用它是杀鸡用牛刀RabbitMQ功能全但运维复杂度稍高。NATS轻量、部署快、支持请求-响应模式符合我这套系统当前阶段的规模。同机环境下做了个快速测试128个并发消息端到端延迟稳定在2ms上下完全够用。总线选型这里想提醒一句不要按“以后可能到百万并发”来定按当前场景的量级选留好替换接口就行。多代理协同系统真正的瓶颈永远在模型推理延迟不在消息总线。5.3 上下文爆炸最早就踩的坑第一次联调两个代理协作分析一份30页的产品需求文档消息里直接把全文作为context传了过去。结果就是token消耗暴涨模型回答质量反而下降被无关细节干扰还拖慢了整个链路。后来我彻底改成前面说的context_refs引用机制消息不传递内容本体只传引用ID接收方按需检索后再把必要片段组装进提示词。配套还做了上下文压缩代理状态机在每次任务结束后把本轮对话摘要成一个结构化条目存入团队记忆新任务开始时不再加载全部历史只加载摘要和检索命中的相关条目。这两个手段叠加后同样任务token消耗降了约70%。5.4 代理死循环两代代理互相等待有个经典翻车现场代理A请代理B确认方案代理B说需要代理A先提供测试数据代理A又说测试数据要等B的确认才能生成——两个代理就这么在队列里互相等直到超时。如果没有迭代上限这个过程可以无限持续既浪费token又拖垮整个任务。修复方案是双管齐下全局协作链路设置最大迭代步数默认8步超出强制转会人工同时每个消息携带deadline字段接收方如果预期在deadline前完成不了必须主动发送阻塞通知让发起方及时调整策略而不是干等。5.5 身份边界模糊代理忘掉了自己是谁跑协同实验时长文本对话代理A在引用代理B的建议后突然以B的口吻继续输出并且在后来的交互里把自己当成了B去承诺事项。这个问题的根源是上下文里身份信息弱化模型在长对话中丢失了“我是谁”的锚点。解决方法是三层加固代理卡身份信息随每次请求注入系统提示词消息协议里强制带签名代理输出模块增加身份一致性校验发现输出名字与代理身份严重不符时自动截断并要求重新生成。从此这个现象基本绝迹。5.6 可观测性没有Trace就没法排查这条不是坑是救命的工具。多代理协同里一个问题可能涉及五六个代理、十几次模型调用和几十条消息。没有全局trace_id之前每次线上问题排查都是噩梦不知道哪个环节出的错、模型里发生了什么。现在每个任务从进入队列那一刻就生成trace_id贯穿所有消息和调用日志。排查问题时按trace_id一搜整条链路一目了然。这个设计建议所有做类似系统的人从第一天就加上不要等。6. 六代理协同实测一次产品发布任务的完整流转最后用一个实际跑通的场景收尾。测试团队六个人每人一个代理产品、研发、测试、设计、运营、合规。任务是24小时内产出产品发布方案。6.1 任务拆分与分工任务进入路由器后按类型标签拆成了四条子任务链风险与技术可行性研发代理、质量验收标准测试代理、发布物料与推广计划运营代理、合规审核清单合规代理。设计代理没有直接进主线而是在运营代理生成物料时被动态调用。这个“动态按需加入”的机制是路由器的重要功能——不是所有代理都要参与所有任务。6.2 关键交互与仲裁流程最关键的冲突发生在研发代理和运营代理之间。研发代理建议发布日定在25号因为还有两个bug需要回归运营代理坚持20号配合节日营销窗口。两个代理都给出了自己的理由消息进入了仲裁器。按我的仲裁规则发布排期这类任务属于运营管辖权但涉及阻塞性缺陷研发风险意见权重更高。最终仲裁结论23号发布研发代理在21号前提测修复版本测试代理同步编排加速回归计划。整个仲裁过程在系统里留了完整记录包括每个代理的理由摘要和最终确认人。6.3 实测数据与当前局限跑完整个流程记录下几组数据端到端耗时约47分钟其中模型推理时间占88%全部代理合计调用模型约240次消耗token约21万含本地模型部分团队记忆新增决策条目17条全部带授权链。对比人力全职做同样方案的历史耗时大约一个下午效率提升是实打实的。但这套系统目前的局限也明确一是代理的结论质量高度依赖基础模型能力复杂场景下仍会出现幻觉性建议只能靠人工审批兜底二是跨组织场景下的信任问题没解决——两个公司各自部署一套系统代理之间互信、数据授权都是开放问题三是仲裁规则目前还是人工配置规则之间的隐性冲突需要维护者持续调整。我个人做完这轮预研最大的体会是多人多AI协同系统架构的难点技术占一半组织机制占另一半。代理之间怎么说话是工程问题代理代表谁的利益、多大权限、冲突听谁的这些在系统设计前就得想清楚。上面的方案肯定不是最优解但它把我在实际搭建中踩过的雷、验证过的机制都如实记录下来了。后面我还会继续深挖机器人场景下的多智能体协同感兴趣的话可以持续关注。