1. 为什么非要多一个“代理代为交互”的中间层1.1 市面主流Agent框架的“单用户假设”去年我们内部准备把一个多Agent协作平台从Demo推向生产时卡了整整两周问题不在模型效果而在架构。任务本身听起来很简单一个项目组五个人每人配一个专属AI代理Agent实例这些代理之间能互相调用能力、交换信息甚至代表各自主人参加项目晨会讨论技术方案。听起来很顺理成章对不对可真正动手设计时发现市面上的多Agent框架几乎全都建立在一个默认前提上——单一用户。AutoGen的GroupChat假设所有Agent在同一个对话组里围绕一个目标运转CrewAI的流程编排、LangGraph的图式控制流本质上都是“一个User指挥一群Worker”。你可以让多个Agent协作但协作的指令、上下文、成果归属都天然属于同一个人。而换成“多人各带自己的AgentAgent之间再互相协作”时问题一下子就变了A的代理在讨论中引用了B的私有上下文怎么办C和D的代理同时抢同一个待办任务由谁拍板每个人的代理都在独立思考但它们共同改一份共享计划文档改坏了谁来负责这就是我在这篇内容里反复强调的“代理代为交互”Agent-Mediated Interaction的架构价值AI代理不是用户手里的一把锤子而是用户与整个多Agent系统之间的服务中介。用户不与后端每个模型、每个Agent直接耦合而是先把自己的意图交给自己的代理由代理去路由、协商、汇总、汇报。这一层中间层正是多人多AI协同系统能否落地的分水岭。1.2 AI代理作为中介替用户说的话、办的事“代理代为交互”这个词听起来偏学术拆开看其实就是三个动作替用户保管会话替用户路由请求替用户参与多方协商。替用户保管会话意味着用户的私人上下文、偏好、历史决策都沉淀在自己的代理侧而不是散落在每次API调用里。替用户路由请求是指用户只需要说“帮我确认一下下周的发布窗口和资源是否有冲突”代理会自己去问运维代理、项目代理、资源调度代理不需要用户逐个找。替用户参与多方协商则是代理可以在用户授权范围内代表用户同意、拒绝、让步比如晨会上几个代理讨论API设计方案达成一致后再向各自用户汇报摘要而不是把七嘴八舌的完整记录甩给用户看。这层设计一旦成立系统架构就随之清晰了用户和代理群是两个平面用户面稳定代理面复杂代理面的复杂度被“交互层”封装起来用户只面对自己代理给反馈。实践中没有这层抽象的多Agent项目多半会退化成“用户手动指挥多个线程”这在一个人影视效果尚可一旦多个用户介入马上乱成一锅粥。1.3 生产环境对多人多AI协同的硬性要求除了逻辑上的清晰生产环境还给了我们四个硬性要求缺一个都不用上线会话所有权必须明确。用户A的代理读不到用户B的私聊历史这是底线不能靠“提示词里说别越权”来解决。并发语义必须落地。多个代理对同一共享任务的读写不能互相覆盖必须有锁、租约或版本控制。可干预性与安全边界。任何协同过程中对应的人类用户要随时能介入中止或改向系统不能变成几个AI代理之间的黑盒博弈。全链路可审计。出了问题能回溯哪条消息从哪个代理发出哪个代理基于什么上下文做了决策。这四点在单用户多Agent项目里很少有人较真但在多人多AI场景里每一条都会咬人。后面章节的所有设计基本都是在回答这四个要求怎么做。2. 分层架构设计接入、编排、协同控制与模型网关的四层职责2.1 四层架构的职责边界与数据流向在定架构时我们反复讨论过要不要把“协同控制”单独拎出来一层后来发现不单独拎出来根本扛不住多人场景的复杂度。最终落地了四层接入层、代理编排层、协同控制层、模型与工具层。每层只做一件事边界清晰到连新人入职两天都能说清楚。接入层负责所有用户触达渠道的归一化。Web端、IM工具、语音入口都汇进来统一做身份认证、会话恢复和权限校验。代理编排层维护Agent Registry记录每个代理属于哪个用户、具备什么角色能力、当前状态是活跃还是休眠、绑定哪套模型策略。协同控制层是整个架构的心脏消息总线负责代理间的通信会话语义池负责共享上下文的读写隔离任务仲裁服务负责任务的注册、派发、租约与超时回收。模型与工具层则通过一个统一网关向下对接云端大模型、本地模型、RAG知识库和各种外部工具执行器。数据流向是用户请求先进接入层凭身份映射到自己的代理实例代理解析意图后发现需要资源把需求写入协同控制层的任务队列或消息总线其他代理通过总线订阅相关主题各自评估后再把结果返给发起方代理最后发起方代理汇总、由用户确认或直接按授权执行。整个过程后端模型不直接暴露给用户用户只跟自己的“代理前台”对话。2.2 核心数据实体代理实例、会话、消息与任务抽象完分层紧接着是定义数据实体。我们一开始只设计了Agent和Message两张表上线模拟一跑就发现远远不够会话归属和任务状态根本说不清。后来稳定下来的四个核心实体是AgentInstance代理实例包含agent_id、owner_id归属用户、role、capabilities、model_binding、status、memory_policy。这里有个容易忽略的细节一个用户可以拥有多个代理实例比如“写代码的”“审代码的”所以owner_id与agent_id是多对多关系权限模型要按agent_id粒度走。Session会话域包含session_id、thread_id、visibilitypublic/project/private、participants、created_by。visibility决定该会话的上下文能进语义池还是只能私域可见。Message代理间消息包含msg_id、correlation_id一次业务协同的关联ID、from_agent_id、to_topic、to_agent_ids、payload、visibility、msg_typeproposal/accept/reject/result/query等、ts。correlation_id特别重要没有它排查协同问题就是灾难。Task共享任务包含task_id、title、assignee_agent_id、status、priority、version、ownership_lease_expire。version是乐观锁版本号ownership_lease_expire是租约过期时间这两个字段救了系统很多次。这四类实体的关系像一个同心圆最外层是被授权的用户在控制台看到的“会话”往内是代理间流转的“消息”再往内是被反复认领和交接的“任务”最核心是每个代理各自的“记忆策略”。后面所有协同机制的实现都可以收拢到这四个实体上。2.3 消息信封与路由策略从点对点杂网到收敛总线代理间通信最忌讳做成点对点杂网。我们一开始图省事让代理之间直接WebSocket互发结果三个代理还好十个代理上线后连接矩阵爆炸、消息乱序、根本无法定位是谁先引发一连串动作。后来参考“分布式交换机系统架构”的思路把思路整个反转过来所有代理间通信必须经过一条收敛的消息总线总线负责持久化、广播、点对点投递和订阅分发代理不维护任何对方的连接地址。总线上的消息统一走信封格式信封字段大体上就是2.2里Message实体的内容。路由策略分两层一层是按Topic订阅适合广播式协同比如“sprint-planning”主题上所有代理都能看到规划类消息并发言另一层是按能力定向投递适合精准协作比如发起方需要在消息里声明to_agent_ids或目标能力标签总线根据能力注册表把消息只送给匹配的代理。这套设计带来一个副产品因为所有消息都经过总线沉淀天然就有了全量审计事件流。后面章节会讲到可观测性和debug复盘很多人以为那是额外加的监控其实只要总线成熟了消息流本身就是最完整的审计日志。3. 多人多AI协同的三个核心难题上下文隔离、任务仲裁、协商编排3.1 上下文隔离与共享的平衡带可见性的语义池多人场景第一个绕不开的问题是上下文隔离。要么把所有代理接到同一个上下文里协同高效但隐私全无而且上下文长度也扛不住要么完全隔离信息安全了协同却变成“两个看不见对方的瞎子互传纸条”。我们的做法是设置一个“会话语义池”作为所有代理共享上下文的统一服务但每次读写都必须携带可见性标记。可见性分为三级public全局可读、project项目内共享、private仅归属用户与指定代理。每个代理在读取语义池内容时服务端按代理的归属项目和用户权限过滤后再返回。这个设计在工程上等价于一个带权限过滤的分布式消息历史库写入时打标签读取时执行过滤逻辑。实现难度不高但让产品层面聪明了很多代理既能在公共工作区协作又能在私聊里说悄悄话两个区域的上下文在拼接进提示词之前就被服务端切干净了。有人会问为什么不让代理自己过滤我们踩过坑提示词过滤在单消息上看着有效但长期多轮协同里上下文会把不同可见域的消息混在一起大模型很容易“遗忘边界”并误引用安全是底线不能交给随机性。语义池的服务端强制过滤才是可控方案。3.2 任务所有权仲裁租约机制避免多人抢活多人多AI协同还有一个独特问题任务所有权。单人场景里AI代理执行任务不存在“谁干”的竞争但多人场景里A的代理和B的代理可能同时看到同一个待办“更新项目周报”两个代理都主动认领并执行结果就是互相覆盖周报越改越乱。我们的仲裁机制分两步认领阶段采用“先到先得租约续期”。任务进入公共队列时带一个task ownership_lock代理认领时通过Redis的原子操作写入agent_id和过期时间谁先写入成功谁获得所有权。获得所有权的代理必须周期性续租续租失败则任务自动释放回队列让其他代理重新认领。执行阶段采用乐观锁任务带version字段每次更新都带上version做CAS校验版本不一致就重读重试杜绝两个代理同时修改同一状态字段。这套机制借鉴了分布式系统里的租约锁思想但应用在AI代理上要注意一个细节代理的“执行”往往不是瞬时的而是多轮LLM调用所以租约时间要按任务粒度和模型响应时间设置我们早期设在30秒结果复杂任务还没干完就过期了后来放宽到10-30分钟并支持代理主动续期才稳定。3.3 代理间对话的三种协作模式与适用场景代理之间怎么“说话”直接影响合作效率。我们把决策问题拆开沉淀了三种协作模式按场景选用。第一种是总控编排模式适合目标清晰、步骤固定的任务比如发布上线。一个总控代理拆解步骤逐个向执行代理派活执行代理只做事不决策。这个模式稳定、可控、责任明确但灵活性差不适合探索型任务。第二种是民主协商模式适合方案设计类任务。所有相关代理围绕一个Topic发言每条发言自带proposal/agree/disagree/result消息类型由一个“主持人代理”负责收敛结论。这个模式我们用在技术评审上效果很好几位“各有立场”的AI代理会围绕接口方案反复辩论最后形成带决策记录的结论比瞎开会强得多。第三种是市场竞价模式适合多代理竞争执行的任务。任务发布到总线各代理评估自身能力和负载后投标由一个仲裁者按评分选择执行者。实践下来三人以下的小型协同用民主协商就够跨部门、多目标的大型协同必须引入总控或市场竞价否则收敛太慢。有人会担心总控模式退化成单Agent分化身确实有这个倾向所以我们规定总控代理只负责调度和决策记录不参与具体领域执行每步决策都要落审计日志避免“总控一言堂”掩盖了真正的多人多AI协同语义。4. 原型落地的技术选型与核心机制实现骨架4.1 技术选型为什么是FastAPIRedis StreamsliteLLM描述架构太多不如跑一个原型。原型阶段我们的选型原则是快且能验证协同语义不用一步到位上航母级基础设施。控制面用了FastAPI理由很简单异步IO天然适合多代理并发等待OpenAPI文档帮助我们快速调接口Python生态也方便对接各种Agent框架语言模型SDK。消息总线用Redis Streams而不是Kafka或MQTT。多人多AI协同的消息量级其实不大每秒几百条撑死了Redis Streams的持久化、消费者组、消息确认都够用还省一套Kafka运维。任务仲裁的锁也复用Redis原子操作省得再引etcd。上下文语义池用PostgreSQL存消息历史用JSONB存可见性标签读取时在SQL里做权限过滤简单可靠。LLM网关用litellm它统一了上百家模型接口这样我们既能接云上大模型也能在中转层接本地模型不锁死在单一供应商上。很多团队拿到这类项目第一反应是上Kubernetes、Kafka、微服务全家桶我的建议是原型期别这么干。协同架构最难的是协议语义基础设施只是工具先用RedisPostgreSQL把交互协议跑通后面再平滑迁到更强底座也不迟。4.2 协商状态机与任务租约的代码骨架消息信封设计好了下一步是给协同流程一个状态机。我们用的协商状态机核心状态是Proposed、Accepted、Rejected、Assigned、Executing、Done、Failed。原型里对应一个简单的Python类核心逻辑大致如下class NegotiationStateMachine: ALLOWED_TRANSITIONS { Proposed: {Accepted, Rejected}, Accepted: {Assigned}, Assigned: {Executing}, Executing: {Done, Failed}, } def __init__(self, task_id): self.task_id task_id self.state Proposed def transition(self, to_state, operator_agent): allowed self.ALLOWED_TRANSITIONS.get(self.state, set()) if to_state not in allowed: raise InvalidTransition( ftask{self.task_id} state{self.state} - {to_state} rejected ) self.state to_state publish_event(self.task_id, transition, self.state, operator_agent)每次状态跳转都会向总线发布一条transition事件这是审计与debug的基础。注意operator_agent字段不能省多人协同里必须知道是谁触发了状态变化否则出了事根本不知道是哪家代理干的。任务租约的实现也简单直接在Redis原子操作上包一层def acquire_task_lease(redis, task_id, agent_id, ttl600): key ftask:lease:{task_id} token uuid.uuid4().hex ok redis.set(key, token, nxTrue, exttl) if ok: return token raise TaskOwnershipConflict(task_id, agent_id) def renew_task_lease(redis, task_id, token, ttl600): key ftask:lease:{task_id} if redis.get(key) ! token: raise LeaseExpired(task_id) return redis.expire(key, ttl)配合之前说的乐观锁版本号任务表更新时带上WHERE version old_version返回匹配行数为0就重读。这套组合拳基本能堵住99%的并发覆盖问题。4.3 上下文语义池的读写实现语义池在原型里不复杂本质是对Message实体加了可见性过滤的查询层。写入逻辑是任何代理发出的消息都带visibility标记public/project/private读取时根据请求方代理所属项目、用户权限和消息的visibility做交集过滤。def read_pool(requester_agent, thread_id, pool_conn): rows pool_conn.execute( SELECT payload, from_agent_id, visibility FROM semantic_pool WHERE thread_id %s , (thread_id,) ).fetchall() allowed [] for row in rows: if can_read(row[visibility], requester_agent): allowed.append(row) return allowed这个函数看起来简单但有一个关键点容易被忽略过滤不能只做到“LLM输入提示词前”还要把来源血缘字段一起拼给模型否则模型引用了别人的上下文却不能溯源。我们在返回的每条消息上额外带上parent_msg_id和source_agent_id当用户问“这段结论哪来的”时系统能一路追溯到最初的提案消息。这节内容对应的标题是“基于AI代理代为交互的多人多AI协同系统架构研究”如果只看了一遍可能觉得这些机制琐碎但它们才是协同系统架构最值钱的部分——架构不是画在PPT上的分层图而是这些让多人多代理协作可预期、可追踪的小机制叠出来的。4.4 本地模型与云端模型的双通道网关模型接入我们专门花了一周设计网关层因为多人多AI协同的负载特性是“高频短消息”代理间协商的消息大多是短文本走云端大模型要注意延迟和成本而涉及方案生成、代码编写的重任务又需要强模型能力。最终思路是让每个代理在创建时绑定一个模型策略网关按策略路由。数据敏感的团队内部信息一律走本地模型我们接入了几款开源模型并通过GPU服务暴露OpenAI兼容接口。云端通道则留给非敏感、高要求的生成任务比如最终评审报告。网关统一用litellm接入同一种请求格式模型切换对上层透明。有个开箱即用的组合值得一说本地模型加上向量检索成了边缘节点上跑“代理助手”的标准姿势数据不出内网延迟低适合知识库问答、私有文档摘要这类协同辅助任务。这验证了一个判断多人多AI协同系统根本不需要所有代理都用顶级大模型分层模型策略反而能极大降低整体成本和延迟。5. 从原型到生产半年运行后踩过的坑和对应解法5.1 并发争抢目标一致的两个代理互相覆盖原型跑通很简单放到真实业务里立刻遇到第一个大坑两个代理在“协作”更新同一份项目计划但目标一致的做法互相冲突。A代理认为技术方案应该先做性能优化B代理认为应该先加新功能两个代理同时读取了旧计划各自按自己的逻辑写了新版后写的覆盖先写的技术方案的决策直接丢了。这个场景充分暴露了前面设计的价值如果没有乐观锁版本号和任务所有权仲裁系统根本无法判断哪份计划才是“正确”的。解决过程分两步首先给Task表加version字段更新时用CAS其次强制所有写操作必须走仲裁器不能由代理直连数据库。很多团队到了这一步才意识到多Agent协同里最危险的不是模型能力不够而是并发控制几乎为零。我们把这两个机制补上后共享文档覆盖问题基本消失。这里也想提醒一句版本冲突时不要简单合并字符串数据结构化字段用字段级冲突检测文本字段宁可返回冲突提示让使用者自己裁决也不要让模型自动合并否则会产生更隐蔽的错误。5.2 上下文漂移代理在公共任务里引用了别人的私聊第二个坑比并发更难发现。某次项目回顾大家发现代理A在公共报告里引用了一句结论但团队里没有人见过这句话。追查后发现这句话来自代理B和其用户之间的私聊因为那次私聊里讨论的语义片段和公共任务语义相似语义池做关键词匹配时把它捞了出来又因为可见性过滤配置漏了private标签被误当成公共知识喂给了代理A。这就是上下文漂移代理的长期记忆和上下文拼接在没有严格血缘管控时会“越权”引用其他会话域的内容。我们后来做了两个修改一是写入语义池的消息强制携带visibility和thread_id读取时按请求方的可见性范围严格过滤绝不把所有语义池内容一股脑塞给模型二是给每条消息打上血缘标记LLM拼接上下文时在提示词里天然带上“本条消息来源于哪个会话、由谁发出”模型不会再无意识混淆来源。这里有个经验过滤规则宁可写死也不能依赖模型自律大模型不是安全边界。5.3 黑盒协同不透明定位问题全靠总线审计接入真实用户后最后一个换来教训的是可观测性。多人多AI协同是一次多代理的异步协商过程中间还夹杂着工具调用和模型决策任何一个环节出错表现都像“结果不对”但根本定位不了。刚开始我们只有应用日志结果代理A说“我等B返回”代理B说“我没收到消息”DBA说“消息表里没有这条记录”三方互相对质一周排查不出问题。后来我们做了一个不太优雅但极其有效的决定把所有代理间消息、协商状态转移事件、工具调用结果都只落地到总线侧的一个事件流里。排查问题时按correlation_id检索这个事件流等同于回放了一次完整的多代理对话。事件流结构是消息ID、来源代理、目标主题、消息类型、状态转移、调用链ID、事件时间戳。需要可视化时我们自己写了一个简单查询页按时间轴展示这些事件相当于给“黑盒协同”装了行车记录仪。实践半年后我们最常做的事情反而是新功能上线前故意制造一个有冲突的任务去观察各代理如何协商通过事件流改进总控编排的决策逻辑。5.4 边缘部署、ARM节点与ROS设备接入这套架构能走多远最后聊聊边界。很多人在做类似系统时问多人多AI协同非得全跑在云端数据中心吗我们的实践是完全不需要。架构里所有关键机制都只依赖消息总线和语义池这两者都可以下沉。我们在几个实验现场把协同控制层跑到了本地集群上节点有很大比例是ARM指令集的边缘设备甚至包括一些国产化要求比较严格的硬件环境系统照样工作。LLM侧只要有一个支持OpenAI兼容协议的本地模型服务代理协同就完全可以在离线网络里闭环外部网络断开影响不大。这说明架构无关芯片指令集只要操作系统能跑容器、网络能通编排与仲裁逻辑是平台无关的。更有意思的是设备接入。有人问过AI代理能不能作为真实世界设备的代理人我们试过把协同总线桥接到ROS机器人操作系统节点上让大模型代理不只是在会话里讨论而是真正派发执行指令给物理设备设备再通过ROS消息把状态回传给代理群。这个方向做原型时让我很有感触架构里“代理代为交互”的含义被放大了——代理不仅替用户和别的AI交流还能替用户和物理世界的执行器交流。多人多AI协同系统的下一步一定不只是会议室里的文本辩论而是代理群代表人类去协调真实世界的资源与行动。这也让系统架构研究从纯软件层面延伸到了边缘计算、设备接入和实时控制前景比我们最初设想的要宽得多。最后分享一条这半年下来最深的体会做多人多AI协同算法模型不是瓶颈架构治理才是。数据隔离、任务仲裁、消息审计这“三件套”能让你在项目早期就规避掉绝大多数后期炸雷的问题。如果你正打算做类似系统建议先把这三件事落在代码里再谈智能。