多人多AI协同架构设计：代理总线实现AI代理代为交互

开头。

AI代理这个词最近火到什么程度，我就不重复了。但真正扎到实际项目里以后，我发现一个很尴尬的现实：大家都在研究单个agent怎么更聪明、工具调用怎么更稳，却很少有人认真想过一个更麻烦的问题——当一群人带着各自的AI代理、在同一个任务里一起工作的时候，系统架构到底该怎么设计？

这个标题的核心不是"AI自动干活"，而是"代为交互"四个字。什么意思呢？就是人和人之间、人和AI之间、AI和AI之间，所有的信息交换、任务传递、结果确认，都不再是点对点的原始直连，而是通过一个代理层统一接管。换句话说，每个参与者都有一个自己的AI代理，这个代理负责帮你理解任务、调用工具、找同事的agent协作、再把结果汇报给你。而我们要研究的，就是把这套多人多AI协同的骨架立起来。

这篇文章适合谁读？如果你正在做企业内部AI平台、做AI协同工具，或者只是想在团队里把AI代理真正用起来而不是停留在聊天框里，那这篇文章的思路可以直接拿来当设计蓝图。我会从架构设计的底层逻辑讲起，拆解代理层怎么搭、上下文怎么共享、多Agent之间怎么仲裁，最后给出踩坑记录和可复现的最小实现方案。

1. 先想清楚为什么：多人多AI协同的两个死结

1.1 直接连接模式为什么走不通

很多人一上来想的方案是：每个人各自调各自的AI，各干各的，最后人工汇总。这种模式在一个人用AI写周报的时候没有任何问题，但一旦进入多人协同场景，立刻会撞上两堵墙。

第一堵墙是无状态。A让AI生成了一份技术方案，B也要基于这份方案做评审意见，但B的AI完全不知道A的AI做了什么。于是B只能把A的方案复制粘贴给AI，AI看一遍再输出意见。这个复制粘贴的动作，就是状态传递的断裂点。人可以在脑子里记住"这是A的v3版本，B已经提过意见了"，但AI不行，每次对话都是一次失忆重启。

第二堵墙是身份与责任边界。A让AI帮忙修改了一份合同条款，B的AI也修改了同一份合同，最后两份改动冲突了，你根本说不清楚这个冲突是AI的问题还是指令的问题，更说不清楚该由谁来拍板。这里缺的不是AI能力，而是一个能追踪"谁在什么时间、基于什么上下文、做了哪个改动"的审计层。

说白了，点对点的直连模式里，AI只是增强版的搜索引擎或写作助手，它们各自为战，没有形成组织。而"组织"恰恰是协同的核心。

1.2 代理总线的定位：把"对话"变成"事件"

解决上面两个问题，需要一个介于人和AI之间的中间层。这个中间层有两件事要做。

第一件事，是把AI的每一次响应、每一个动作，都记录成结构化的事件。A的AI改完方案，不再是对话框里的一句"好的我改完了"，而是一条事件消息：方案ID=xxx，修改人=A的代理，修改时间=14:32:05，修改摘要=替换了第三章的架构图并更新了接口定义。这个事件本身是机器可读的，它可以被存储、被检索、被转发给B的代理。

第二件事，是给每个参与者一个稳定的"代理身份"。从系统架构的角度看，人不是直接跟AI对话，而是跟自己的代理对话，代理再跟别的代理对话。这样做的好处是：A不用关心B用的是GPT还是本地模型，B也不用关心A的提示词写得怎么样，大家只需要通过代理之间约定好的协议来交换信息。

我习惯把这种模式叫"代理总线"。它的思想其实不新鲜，和消息队列中间件、ESB（企业服务总线）是一脉相承的，只不过现在总线里跑的不是数据库变更消息，而是AI的工作产物和任务指令。

1.3 拓扑选型：为什么是总线而不是网状

分布式系统里有两种常见拓扑：网状直连和中心化总线。网状直连最灵活，每个节点都能跟其他节点通信，但问题也很明显——当你有5个人、5个AI代理的时候，通信路径是C(10,2)=10条，还能接受；当你有20个代理的时候，路径就变成190条，任何一条路径上的协议变化都可能引发连锁故障。

总线拓扑则简单得多。所有代理只跟总线通信，总线负责路由、过滤、排障、审计。坏处是总线本身成为单点，但这可以通过集群部署解决，比维护190条不稳定连接的成本低得多。

在实际项目里，我见过一个中等规模团队用网状直连，最后崩溃的现场：某天一个agent的上下文长度溢出，返回了报错信息，结果所有依赖它的agent都在等待超时，整个任务链卡死。排查的时候，你根本不知道错误源头在哪，因为消息拓扑太散。改成总线模式之后，所有消息经过统一网关，问题定位时间从小时级压缩到了分钟级。

说句实在话，多人多AI协同的场景，不要追求拓扑上的花活，稳定压倒一切。总线的核心优势从来不是性能，而是可控性。

2. 整体架构设计：五层代理体系怎么搭

2.1 从接入到存储：五层架构的分工

在前面总线思路的基础上，我把整个系统拆成五个层次，每一层只做一件事，不越界。

• 接入层：负责对接终端用户，处理WebSocket连接、消息协议转换。人在这里连上自己的代理，而不是直接连AI。
• 代理层：每个用户（或每个角色）对应一个独立的Agent Runtime，这是整个系统的核心执行单元，负责维护自己的上下文、调用工具、生成动作。
• 调度层：承担总线的路由职责，决定一条任务指令该发给哪个代理、按什么顺序执行、如果目标代理忙该怎么排队。
• 协同层：处理多代理之间的协作逻辑，包括冲突仲裁、共识达成、上下文共享。这一层解决的是"多个agent怎么一起做决定"的问题。
• 存储与安全层：保存会话历史、事件日志、文档资产，并负责权限校验、敏感信息过滤。

这五层的划分思路和传统企业应用分层很像——接入、业务、调度、数据各自独立。但在AI场景下，每一层都有一些特殊细节，下面逐一展开。

2.2 代理层的核心设计：Agent Runtime

代理层是整个系统里最像"人"的部分。每个Agent Runtime本质上是一个有状态的循环：接收消息、理解意图、决定行动、调用工具、生成回复、再等待下一条消息。

它和单机版AI助手的区别在于三个额外设计。

一是会话封装。代理人不会被一句接一句的闲聊打断，它有一个长期记忆库，存的是当前项目的所有关键上下文。比如我让它负责项目周报，它会在会话里维护一个状态：本周完成列表、阻塞项、风险登记。不管有没有人来找它，这份状态都在。

二是工具注册表。给代理配一组可调用的工具，比如读数据库、发邮件、写文档。每个工具都带清晰的功能描述和参数schema，代理在需要的时候自行决定调用哪个工具。这里的关键教训是：工具宁可少配，不可乱配。工具越多，模型误调用概率越大。

三是角色隔离。不同代理有不同权限域。一个负责代码审查的代理，绝对不应该有写生产数据库的权限。这个在单机场景容易忽略，但在多人协同场景，如果权限不隔离，一个代理被注入恶意提示词，可能连累全组。

我用一个Java风格伪代码来表示Agent Runtime的大致行为：

public class AgentRuntime { private String agentId; private ContextStore contextStore; private ToolRegistry toolRegistry; private LLMConnector llm; public Response onMessage(Message msg) { // 1. 把新消息写入上下文 contextStore.append(msg); // 2. 拉取历史上下文 + 当前消息，组装Prompt Prompt prompt = contextStore.buildPrompt(msg.getSessionId()); // 3. 让LLM决定下一步：是直接回复，还是调用工具 LLMOutput output = llm.complete(prompt); if (output.hasToolCall()) { // 4. 校验权限后执行工具调用 ToolResult result = toolRegistry.execute(output.getToolCall()); // 5. 把工具结果返回给LLM，让它生成最终回复 output = llm.complete(contextStore.appendToolResult(result)); } // 6. 记录事件到总线 eventBus.publish(agentId, output); return output.toResponse(); } }

这个结构不复杂，复杂的是memory和工具调用的交互循环。很多人写agent只用一轮prompt，但真正可靠的做法是让 agent 能循环地"观察-行动-再观察"，直到任务完成。

2.3 调度层：路由策略与优先级

调度层的职责，说穿了就是三个路由维度。

意图路由：识别消息的意图，决定该交给哪个代理。比如"A，帮我看看B写的接口文档有没有问题"——这条消息的目标其实是B的代理，A只是转发者。这里需要从自然语言里抽取实体和动作。

能力路由：不同代理能力不一样，有的擅长写代码，有的擅长做PPT，有的擅长查资料。调度层维护一个能力目录，按任务类型匹配代理。

负载路由：当同一类代理有多个实例时，按空闲度分配任务。这个相对简单，不展开。

优先级设计也有讲究。多人协同里最怕的问题是：所有人的请求同时打到一个代理上，导致那个代理的上下文爆炸。我的做法是用一个优先队列，人工发起的请求永远优先于代理之间的自动请求；同优先级的请求按FIFO处理。这样做的好处是，当系统吃紧时，至少人的体验不会崩。

2.4 协同层与存储层的边界划分

协同层负责的是多代理之间的"社交"。它维护了一份全局任务图（DAG），记录每个子任务的依赖关系。比如"设计评审"依赖"需求梳理"完成，"需求梳理"又可能依赖"用户访谈纪要汇总"。代理完成一个子任务后，协同层检查后继任务是否可以被激活，如果可以就自动触发下一个代理。

存储层则管三样东西：会话记录、产物版本、元数据索引。这里我不建议用传统的关系型数据库存大文本，用对象存储存文档，用向量数据库存语义索引，再用一张轻量的关系表存事件关联关系，这样配合起来最顺手。

存储层还有一个特殊职责，就是存"决策回放"——也就是每个代理在什么时间、依据什么信息、做了什么决定。这个在事后复盘和争议追溯时极其有用。

3. 协同机制拆解：上下文、仲裁与权限

3.1 上下文隔离与共享：既不能全通，也不能全断

多人多AI协同场景里，上下文管理是最容易翻车的地方，没有之一。

如果把所有代理的上下文全打通，模型会陷入信息过载，更重要的是，隐私边界会消失。但如果完全隔离，协同就无从谈起。需要分粒度设计。

我的方案是三层上下文。第一层是个体上下文，只属于某个代理，包含它的对话历史和私有记忆，其他代理不可读。第二层是任务上下文，属于当前这个任务下的所有参与者，比如需求文档、会议纪要、待办清单，参与这个任务的代理都能读取。第三层是共享知识库，面向全团队，比如规范手册、历史项目复盘、技术选型文档。

这样划分以后，权限控制就落在数据层面。代理能不能读某个文档，不取决于它想不想读，而取决于它在哪个任务里。系统通过给每个上下文打标签来实现：task:project-alpha:requirement、team:default:wiki，等等。

实操中有一个细节容易被忽略：即使共享上下文，代理之间的信息传递仍然建议走事件而不是直接读库。原因是直接读库会造成隐式耦合——B的代理读到了A还没确认的数据，会基于不完整信息做误判。通过事件总线流转的上下文，天然有状态变更的确认感，更接近人类的协作习惯。

3.2 冲突仲裁：多Agent意见不一致时听谁的

协同系统最精彩的场景，是多个Agen对同一件事给出了不同的结论。比如让四个代理评审同一个方案，两个说可行，一个说技术债太重，一个说资源不足，这时候必须有一个仲裁机制。

先把仲裁分成两种情况。一种是对客观事实的仲裁，比如两个代理从不同数据源拿到了不同的指标，这时应该以权威数据源为准，可以给数据源设可靠性权重。另一种是对主观意见的仲裁，比如设计风格的取舍、方案方向的抉择，这时不能用权重一刀切，需要引入"发起者优先"和"投票表决"的组合策略。

我常用的策略是三级仲裁：

• 第一级，检查是否存在硬性约束冲突。如果某个结论违反已设定的约束，比如"工期不得超过两周"、"必须使用已有的中间件版本"，直接淘汰。
• 第二级，优先级比较。带明确的"决策所有者"角色的代理，其意见权重高于普通建议型代理。如果决策所有者支持，一般就不再纠缠。
• 第三级，冷投票。如果前两级仍然无法裁决，就把所有候选方案交给一个独立的仲裁代理，同时隐藏各方案是谁提的，避免身份偏好影响判断。

这套三级仲裁机制在真实项目中验证过，比单纯靠大模型硬投票可靠得多。核心原因是：它把"人对事情的判断权"和"机器对事实的计算权"分开了，而不是把所有决策都交给随机的LLM直觉。

3.3 工具调用与审批流：权限必须落在代理身份上

安全是多人多AI系统里最容易被低估的坑。一个人用一个AI工具，出了问题最多影响自己。但一个团队用多个代理时，一个代理的越权操作就可能波及所有人的数据。

我的建议是三层工具权限控制。最小权限原则，每个代理默认不给任何工具权限，按需申请。执行双确认，涉及写操作的工具，代理只能发起执行请求，必须由相应权限的人点击确认后才能真正执行。全链路审计，每次工具调用，无论成功失败，都记录入事件日志。

这里有一个具体案例：我曾给一个团队配置了"文档自动修改"代理，它权限足够大，能改共享文档。测试阶段一切正常，有一天它收到一个被恶意注入的消息，要求把文档里所有"竞品分析"替换成"内部代号"。幸好我开了执行双确认，人工发现了这条诡异请求，否则整个对外分享的报告都会被篡改。

这事给我的教训是：技术再好，都不能省掉人工确认这一环。AI代理之间的信任不能靠自觉建立，只能靠机制建立。

4. 实操落地：最小可行版本与真实场景编排

4.1 最小可行架构的落地步骤

如果你要从零开始搭这套系统，我建议不要一上来就追求完美，按下面四步走，每一步都能独立跑起来。

第一步，搭消息总线。不要自己写，直接用现成的消息中间件，比如NATS、RabbitMQ、Kafka任选其一。先定义好消息主题的命名规范，比如agent.command、agent.result、agent.audit。这个阶段的目标是让两个代理能互发消息。

第二步，写一个最小Agent Runtime。不要接任何高级功能，就做一个能接收消息、调用一个工具函数（比如调用天气API或读取本地文件）、并返回结构化结果的单目循环。验证消息协议是否稳定。

第三步，实现任务上下文存储。选一个关系库、一个文档存储、一个向量库，维护任务的元信息、文档内容和语义索引。这一步做完，系统已经能支撑"一个任务关联多个代理"的基本形态。

第四步，接入仲裁与权限模块。先做最粗暴的规则仲裁（硬性约束检查），再做事件审计。最后把工具执行回调改成"待确认"状态，接入IM通知。

完成这四步，你就拥有一个可以演示、可以小规模试用的多人多AI协同雏形。剩下的智能路由、复杂意图理解，都可以在这样一个地基上慢慢长出来。

4.2 四个典型场景编排实例

我整理了几个已经实际落地过的场景，可以直接对照着编排你的代理。

场景一：方案评审会。召集三个代理，一个读历史方案库，一个做技术可行性分析，一个做资源估算。协同层自动把待评审方案的摘要发送给三个代理，设定一条约束"所有意见必须在1小时内返回"。三个代理结果回来后触发仲裁代理汇总，生成一个带冲突标注的评审报告，发送给项目负责人。

场景二：跨角色任务协同。产品、开发、测试各配一个代理。产品代理更新了需求文档，事件总线上触发requirement.updated。开发代理收到事件，检查影响范围、修改排期。测试代理同步感知变化，更新测试用例。全程无人转发，但每一项变更都有人工确认的复审节点。

场景三：研发冲刺周报自动生成。每周五下班前，调度层自动触发汇总代理，从git提交记录、需求面板、缺陷系统里拉数据，生成一份逐人逐任务的周报草稿，然后分发给每个成员确认。成员只改自己的部分，再归档到知识库。

场景四：客户投诉响应。客服代理和知识库代理并行工作，客服代理负责识别投诉情感倾向，知识库代理负责搜索相似历史案例的处理方案。两路结果合并成一个应对建议，提交给值班主管确认后发送。

这四个场景的共同点是：自动化跑流程，但决策权始终留在人手里。代理之间可以互相传递信息和半成品，但最终对外的输出必须经过人工确认。

4.3 成本与资源估算的实用算法

多人多AI协同系统，成本往往是翻车重灾区。我见过一个团队雄心勃勃搭了20个代理，一个月后看账单傻眼。

算成本其实有一个相对靠谱的公式：月成本 ≈ Σ(每个代理的日均请求数 × 单次请求Token数 × Token单价) × 工作天数。问题在于，代理之间的自动消息会指数级放大请求量。一个100次的嵌套协作，可能产生上千次LLM调用。

为了控制成本，我常用三个手段。一是任务合并，相近的上下文请求合并为一次调用，减少重复阅读长文档的成本。二是降级模型，协作过程中的内部消息（比如两个代理之间确认格式的消息）用小模型处理，只有面向人的高质量生成才用大模型。三是结果缓存，对同文档、同知识库的中立信息请求，直接读缓存返回，不再调用LLM。

资源估算上，并发度的计算也不难。设定一个代理平均处理一条消息要4秒，那么单代理名义QPS是0.25。一个任务链有20个串行步骤，则从发起到达成结果的理论耗时是80秒。如果你的业务SLA要求在10秒内给出响应，就必须把串行步骤拆成并行分支，或者对部分链路做缓存预生成。

5. 常见问题与排查实录：踩坑后的经验总结

5.1 上下文错乱：最隐蔽的系统性故障

多人多AI系统里，上下文错乱几乎是必然会发生的问题。典型症状：B的代理回复里出现了A的私有信息，或者一个代理忘了当前任务的版本号，用旧版本做了决策。

排查套路是先区分是存储问题还是路由问题。出现信息串线，优先检查消息主题是否被错误转发，事件总线上是否有消息头缺失。确认链路畅通后再检查上下文标签，看代理拿到的上下文窗口里是否混入了错误命名空间的数据。

预防比排查更重要。我会在每个上下文的开头强制注入一段系统提示，明确当前任务ID、当前用户、当前接入的代理ID。这样即使上下文串了，模型也有机会感知到异常。

5.2 多代理死锁：谁都不动，全局卡死

死锁的场景很典型：代理A在等B的结果，B在等C的结果，C又在等A的确认，三者互相等待，超时策略没配置，整个任务链就挂在墙上。

排查死锁，首先看超时设置。很多agent框架默认没有给工具调用和消息等待设超时，这是根本隐患。我的经验是每个内部请求都要设三重超时：连接超时（网络层）、等待超时（消息队列层）、业务超时（任务逻辑层）。

其次看等待策略。不要让代理傻等，而是采用"异步回调 + 状态轮询"。代理发出协作请求后，把自己挂起，定时查询任务状态。如果发现依赖的任务超时，主动上报并请求人工介入。

5.3 消息风暴：代理之间的聊天比人还频繁

当代理数量超过10个，消息风暴会变成非常现实的问题。一个代理的一次小改动，可能触发下游所有代理的感知通知，形成消息雪崩。

缓解手段有三板斧。首板斧是消息聚合，在总线层设置缓冲窗口，比如50毫秒内的同类事件合并为一条批量通知。二板斧是订阅过滤，让下游代理只订阅与自己相关的事件类型，而不是全量订阅。三板斧是限流，总线上设置令牌桶，超限消息进入延迟队列。

5.4 迟到的共识：达成一致时任务已经不需要了

还有一种很尴尬的情况：几个代理花了10分钟终于达成一致，但用户那边已经等不及，自己手工处理完了。这在系统层面表现为任务被取消，但代理链还在跑。

解决办法是加一条"存活检查"机制。调度层在发起任务链前，先向发起人确认任务是否仍然有效。链路执行过程中，每个关键节点结束后回传进度，如果发起人主动取消，协同层立即广播取消信号，所有代理终止当前动作并丢弃相关结果。

5.5 问题速查表

最后分享一点个人感触。每次做完一个协同任务，我去复盘整个链路，总会发现真正决定这次协作质量的因素，不在于哪个大模型更强，而在于架构上给了系统多少"缓冲"——有没有足够的确认环节、有没有清晰的责任边界、有没有在关键节点上留出人说"不"的位置。这套基于AI代理代为交互的多人多AI协同架构，说到底不是在解决AI的问题，而是在解决组织分工的问题。AI只是更好的执行者，但架构才是让人和AI都待在正确位置上的那个框架。

我个人的实操经验是：小规模试点时，宁可多接几个笨一点的代理，也不要一上来就堆满智能。先把消息协议、上下文隔离、人工确认这三根柱子打牢，再慢慢往里面加聪明程度。这个顺序，比什么都重要。