最近在帮团队搭一套多人多AI协同系统第一道坎儿不是模型能力而是到底由谁来做交互。我们最初的产品形态很简单每个人一个AI代理助手大家在同一套工作流里各干各的。但跑了一周之后就发现问题了——代理和代理之间根本不会好好说话人也被无休止的确认消息淹没。标题里基于AI代理代为交互这个说法意思就是让代理替人去完成协同过程中的信息传递、任务协调和决策支撑而不是让代理继续扮演对话框里的助手。这篇文章我想把多人多AI协同系统的架构研究思路完整写出来包括我试图解决什么、怎么分层、代理之间怎么通信、冲突怎么仲裁、落地时踩了哪些坑。如果你最近也在折腾多智能体系统的架构设计或者准备让AI代理真正介入团队协作流程这篇应该能帮你省不少试错时间。1. 为什么代为交互是多人协同里最难啃的骨头1.1 传统协同工具的信息过载先说一个让我很头疼的场景。团队五个人项目群里有需求变更、技术方案、测试报告、客户反馈一天能刷几百条。每个人都要花大量时间去做同一件事把散落在各处的信息拼起来搞清楚现在到底进行到哪了。更麻烦的是上下文是断裂的。产品经理在群聊里发了一条需求变更开发可能三天后才看到而AI助手能做的只是把这条消息总结得更短并没有真正解决信息该往哪走、谁该关注什么的问题。这里的关键不是信息太多而是信息与决策者的连接关系没有被建模。传统协同工具把信息仓库做得很完善但它默认人会自己去看。当参与者和信息量同时增长人根本看不过来协同效率就开始崩塌。1.2 代理代交的三个层次我后来把代为交互拆成了三个层次来理解这样架构设计才有抓手第一层信息代收代发。代理帮你盯着消息、筛选优先级、把相关变更转给对应的代理。这层只做路由不做决策最容易落地。第二层任务代接代转。代理能理解任务的状态把需要他人配合的动作转交出去比如开发代理把测试请求发给测试代理并跟踪结果。第三层决策代议代裁。代理在规则允许范围内代表你参与讨论、谈判资源、甚至拍板。这层最难因为你要面对信任和责任问题。大多数团队做多AI协同死在了第一层往第二层过渡的地方。因为一旦代理要代接任务就必须有跨代理的状态协议而这是传统AI应用没考虑过的事情。1.3 我的实验场景一个需求变更的跨代理流转我用一个具体案例来说明这个区别。某次需求评审会上产品经理的代理收到了变更指令它生成了一份变更摘要直接把消息推给了开发代理和测试代理。开发代理识别出涉及两个模块自动生成工作量评估回传给产品代理测试代理则在开发确认后创建回归测试计划。整个过程中产品经理只需要在最后审批变更是否上线其他环节全是代理之间完成的。这个实验让我意识到多人多AI协同系统的核心不是每个人都有一个更聪明的助手而是把人与人之间的交互协议——通知、确认、转办、催办、裁决——全部抽象成代理间的通信协议。2. 把协同职责拆进五层架构每一层都在解决什么问题如果只做一个Demo不需要分层脚本编排就能跑通。但一旦要支撑真实业务流程分层是必须的。我最后用的架构是五层从下到上依次是基础设施层、数据与记忆层、模型接入层、代理编排层、交互呈现层。2.1 五层架构的职责边界层级核心职责关键组件交互呈现层多媒体交互、消息通知、人工介入入口Web客户端、IM机器人、语音/白板接口代理编排层任务状态机、代理间路由、策略仲裁编排引擎LangGraph、规则引擎模型接入层大模型统一网关、云本地模型路由OpenAI兼容网关、Ollama/vLLM接入数据与记忆层短期上下文、任务状态、长期知识、审计日志Redis、PostgreSQL、向量数据库基础设施层通信总线、分布式部署、可观测性NATS/Kafka、Kubernetes、OpenTelemetry这张表是整个架构的骨架。我实际开发时的顺序恰好相反先从基础设施层的通信总线开始因为代理之间要对话必须先把路修通。2.2 交互呈现层多媒体交互不是简单聊天窗口交互层是人和系统接触的边界也是代为交互安全感的第一来源。如果代理替人做了决定但人看不到推理过程信任感会迅速崩塌。所以这层不只是聊天界面还包含操作回放与决策解释面板每次代理动作都带为什么这么做的说明。消息提醒策略区分需要你马上回应和记录一下即可避免代理把人也卷入消息风暴。多媒体接入文本、语音、白板、文件批注要统一进消息协议。我们在白板标注上吃过亏——代理能读文字但读到一张图画圈时它需要转成结构化标注才能继续流转。我的建议是交互层设计一定要遵循一个原则代理能处理的自动处理不能处理的优雅升级给人。而不是反过来把所有信息都推给人看。2.3 代理编排层状态机是协同的地基代理编排层就是整个系统的大脑。我最初以为要做一个通用的多Agent框架后来发现最稳的思路是把它做成一个任务状态机每个代理围绕任务状态来驱动。一个任务流转的基本状态包括pending等待处理processing代理正在处理waiting_external等待其他代理或人negotiating多个代理对结论有分歧需要仲裁done完成rejected被驳回以需求变更为例产品代理创建任务后状态变成processing随后调开发代理任务转为waiting_external开发代理返回结果后如果产品代理发现工作量超出预期可以发起negotiating最终达成一致后变为done。这套状态机用LangGraph实现非常合适节点就是各种代理动作边就是状态迁移。我在代码里是这样组织的伪代码graph StateGraph(TaskState) graph.add_node(product_agent, product_agent_handler) graph.add_node(dev_agent, dev_agent_handler) graph.add_node(test_agent, test_agent_handler) graph.add_node(human_approval, human_approval_node) graph.add_edge(product_agent, dev_agent, conditionis_requirement_change) graph.add_edge(dev_agent, test_agent, conditiondev_finished) graph.add_edge(test_agent, human_approval, conditionneeds_approval)这里有个关键点不是所有路径都由模型决定很多路径是规则写死的。只有这样才能保证可控性。模型可以生成摘要、评估工作量、判断冲突等级但它不能决定任务流去哪里任务流由编排引擎决定。2.4 模型接入层云端模型与本地模型的混合路由模型接入层解决的是什么样的任务交给什么样的模型。大模型在各个代理间被共享调用如果不做统一网关会出现一个非常现实的问题多个代理各自直连模型服务来回切换上下文成本失控。我做的模型网关支持两种路由策略按敏感度路由涉及客户敏感数据、内部财务信息的内容强制走本地模型数据不出域通用的总结、润色、创意文本走云端模型。按延迟敏感度路由实时决策类任务走低延迟本地小模型复杂度高的深度推理走大参数云端模型。这里我要强调一下本地模型的价值热度很高的ai代理助手加本地模型这个方向不是赶时髦。实测下来用Ollama部署一套7B到14B的量化模型处理日常的文本分类、意图识别、信息抽取延迟能压到500毫秒以内而且完全不受云端限流影响。多代理场景中会有大量轻量级理解请求如果每个请求都坐等云端大模型整个系统的吞吐会被按在地板上摩擦。网关还要做一层协议统一。无论底层是OpenAI、Claude还是本地模型对外暴露统一的接口代理编排层不关心模型是谁。2.5 数据与记忆层跨代理的记忆不共享协同就是空的数据与记忆层包含三类存储短期上下文一段对话周期内的消息用Redis存带TTL。工作记忆任务状态、审批流程、代理间的待办关系用PostgreSQL持久化支持事务。长期记忆从历史交互中沉淀的项目知识、团队偏好、用户画像用向量数据库存。这三类存储要严格区分。我见过一个项目把所有历史对话一股脑塞进上下文结果token爆炸每一个请求都慢得像爬。更合理的做法是代理只携带与当前任务直接相关的短期上下文其他信息通过检索获取。数据层的另一个重点是记忆的归属。每个用户的代理有私有记忆团队层有共享记忆二者必须隔离。否则就会出现你的代理把我之前的隐私对话当成了团队参考这种社死级事故。3. 代理间通信与状态同步最容易翻车的地方3.1 通信选型消息队列不是可选项是底线代理之间交互采用什么通信方式是我最先拍板的决定。一开始团队有同学说直接用HTTP调用不就行了吗——代理A调代理B的接口拿到结果就返回。听起来简单但真实跑起来全是坑。HTTP同步调用的核心问题是强耦合和重试地狱。代理A调代理BB卡住了A也得卡住B在重试C也在重试整个链路瞬间毛线团。多人多AI系统里代理数量一旦超过两三个同步调用就是灾难。我的选择是引入消息总线用的是NATS轻量、够快、部署简单。核心通信模式是异步的发布-订阅加请求-应答混合发布-订阅代理广播任务状态变更、通知事件。请求-应答代理向另一个代理发起有返回的协作请求。Kafka也可以但如果是中小规模团队Kafka的运维成本不低。NATS JetStream在持久化和消息回溯上已经够用。真正的核心不是选哪个中间件而是建立统一的消息协议。我定义的核心消息结构长这样伪代码{ protocol_version: 1.0, message_id: uuid-xxx, sender: product_agent, recipient: dev_agent, task_id: task-001, msg_type: request_review, payload: { requirement_id: R-012, change_summary: ..., priority: high }, created_at: 1719900000, trace_id: trace-abc }trace_id是贯穿全链路的关键没有它分布式排查问题会累到怀疑人生。3.2 状态同步上下文要传增量不要传全量代理之间除了消息还要同步状态。这块我踩过一次大坑。最初的设计是代理B在收到任务时代理A把所有已知信息打包发过去。结果每个任务的消息体积随流程推进线性膨胀到后面一个简单的确认操作都要带几十KB上下文模型输入成本飙升。正确的做法是状态同步加增量上下文每次传递只携带相对上一个版本的变化。新代理启动时先向状态服务拉取任务快照再订阅增量事件。所有状态变更都带版本号用乐观锁防止覆盖。比如开发代理更新了任务状态为开发完成耗时2人日这个变更本身就是增量信息代理链路上只需要广播这一条JSON。想要全量视图去PostgreSQL里查别在消息里带。3.3 消息风暴与代理死锁通信架构搭好之后还会有两个更隐蔽的问题。第一个是消息风暴。我实测过如果两个代理在协商一个未定义清晰的协议比如你觉得呢我觉得可以那你觉得呢双方会无限互发消息。这不是模型的问题是协议没有终止条件。解决方法是给消息链路加最大跳数。任何一个任务的消息流转深度超过预设阈值我常用6跳就强制转人工。第二个是代理死锁。开发代理在等测试代理的确认测试代理在等开发代理的测试报告两边互相等人也不知道。这种情况在分布式系统里叫死锁处理方式也很经典超时回退加人工唤醒。每个waiting状态都设置超时时间超时后自动升级为需要人处理。4. 仲裁、人机回权与安全边界代理能替你拍板到什么程度4.1 冲突类型与仲裁策略多代理协同一旦进入真实业务冲突是必然的。我遇到的冲突分两种资源冲突两个代理同时要调用同一个外部工具。比如同一个数据库写连接或者同一个执行任务的worker。这种冲突靠分布式锁解决制定好锁的粒度就行。决策冲突产品代理说这个需求要做开发代理说成本太高不建议。这是最棘手的。我用过一套三层仲裁策略规则优先如果冲突场景符合预设规则比如安全问题一票否决直接按规则执行。投票协商无明确规则时让相关代理投一次票各自附理由系统汇总。升级给人如果投票仍没有结论或者冲突影响面较大直接升级到人。这里有一个原则升级给人的门槛要低不要怕打扰人。代理协同的目标是减少低价值沟通而不是在高风险决策上替人做主。4.2 人在回路的notify、approve、override三级控制我给每个代理配了三种控制级别这是整个系统安全感的来源notify级别代理自主决策但每个决策都记录日志并推送摘要给人。适用于低风险操作比如会议纪要整理、任务优先级建议。approve级别代理可以提出方案但执行必须等人工确认。适用于高风险或高成本操作比如对外发送正式邮件、修改生产环境配置、批量删除数据。override级别人可以直接接管代理手动修改任务状态或流程走向。当代理卡死或乱来人可以一键切换成手动模式。实测中最容易翻车的是approve边界划定。划得太宽人不停点确认协同效率为零划得太窄代理悄悄干了一件不该干的事。我的经验是划边界时多问一句这个动作如果错了修复成本高不高 修复成本高的一律要approve。4.3 权限即边界代理权限永远不要超过主人安全设计上我的核心原则是代理的权限永远不要超过主人。每个代理携带一个权限令牌令牌的权限集继承自所属用户并且可以细化到功能模块。关键词之一是最小化授权开发代理只能读代码仓库不能推送代码产品代理只能读需求文档不能访问财务数据。另一个是时效性授权某些权限只在任务周期内有效任务结束自动撤销。这一块没有太多可讨价还价的余地。做多人多AI系统权限模型的复杂度会随人数和代理数线性上升越早设计越省钱。5. 从一个人两个代理开始落地路径与踩坑报告5.1 三个让我崩溃的坑多智能体系统的坑有一部分是分布式系统的通病有一部分是AI特有的。我按崩溃程度排序最值得一提的三个第一个坑是幻觉在代理链路上的放大。单代理的幻觉还只是自己答错多代理链路上的幻觉是灾难式的。代理A在总结时说需求已完成其实没完成代理B直接引用这个结论往下走后面所有环节都建立在一个不存在的事实上。解决办法是强制事实回链每个关键结论必须附引用来源编号后续代理如果要引用必须追溯到原始记录源头没有可靠来源的标记为待确认。第二个坑是上下文膨胀。我一开始把让代理多带点上下文当作提高准确率的手段结果每个请求慢得离谱。后来我才接受一个现实模型的能力再强也架不住在几十万token里翻找关键信息。现在我的做法是摘要加召回双通道先给代理一个全局摘要关键细节按需从向量库检索检索不到才追加上下文。第三个坑是框架选型锁死。团队一开始用了一个非常高级的多代理框架后期发现很多底层行为不可控想改又受限于框架封装。我的建议是如果是做生产系统优先选择可编程性强的编排框架我选了LangGraph框架只提供状态机骨架决策逻辑全部自己写。看起来工作量多一点但排障时有全栈的控制力值。5.2 中小规模团队的组件清单按团队规模不同我给出两套可以直接抄的组件组合小规模5人以内代理数小于10PostgreSQL保存一切持久状态Redis做短期缓存和分布式锁NATS做消息总线编排层用LangGraph模型网关用自研轻量服务或者直接接OpenAI兼容网关UI端用现成IM机器人加Web面板。中等规模20人左右代理数几十把NATS升级为Kafka引入完整向量数据库比如Milvus或qdrant加独立认证服务所有代理动作走审计日志再加一套OpenTelemetry链路追踪。这里有一条经验架构上预留升级路径但实现上不要一上来就上重武器。先用一台机器跑通全流程等真的发生性能瓶颈再扩容比一开始就铺Kafka集群划算得多。5.3 下一步从办公协同到具身场景多代理协同的架构不会只在聊天和文档场景止步。最近我比较关注的是openclawros为你的ai代理这类方向——把AI代理的能力从软件交互延伸到硬件控制。本质架构没有变依然是代理编排、消息通信、控制回权三件套只是交互层变成传感器数据、机器人控制指令。另外一个趋势是边缘部署。像u盘安装麒麟系统arm架构这种硬件适配需求说明很多团队已经在考虑把整个系统跑到工控机或边缘设备上。本地模型加轻量消息总线在ARM架构上完全跑得起来资源占用可用性都不错。我现在对这个方向的判断是多处落地的通用组件还没有定型但核心架构范式已经出现了。消息协议、状态机、权限模型、人机回权这四件事无论将来底层模型怎么进化都是绕不开的骨架。写到这里我更想说的是架构图人人都能画真正区分设计好坏的是边界的取舍——哪些交给代理自主决策哪些必须升级给人哪些上下文要传递哪些要裁剪哪些消息要实时等哪些异步就行。这些决策没有标准答案只能靠小步实验一点点调出来。如果你正在搭这样的系统我只有一个建议别一上来就是五层架构、十几个代理。先让一个流程完整跑通让两个代理真实协作完成一个任务把通信、状态、回权这条链路走顺。等这条链路不再出错再慢慢往里面加人、加代理、加场景。多代理系统的复杂度是指数增长的但起步永远可以是从一个人两个代理开始。