这两年AI Agent的热度高得惊人但你去观察实际落地场景会发现大多数实践还停留在“单用户单模型”的对话框里。真正进了生产环境迎面而来的往往是另一番景象一个团队里好几个人同时在用三五个AI系统每个模型各有擅长但彼此说不上话流程中间全靠人肉搬运输出、复制粘贴、手工汇总。这种“人多、AI多、协作乱”的状态恰恰是企业级应用里最普遍也最难受的环节。我自己在带团队做AI中台的过程中被这类问题反复折磨最后转向了“AI代理代为交互”的多人多AI协同架构——不是让用户自己去敲每个模型的接口而是让一组自治的AI代理替用户完成跨系统的感知、调度、取数、汇总和交付。这篇文章会把这套架构的设计思路、核心模块、关键实现和踩坑记录完整摊开适合正在做AI编排层、智能工作流或者多模型网关的工程师和架构师参考也适合刚接触Agent系统、想少走弯路的产品和技术负责人通读一遍。1. 为什么需要“代理代为交互”场景与痛点拆解1.1 从“人找AI”到“AI代理找人”先看一个最简单的对比。传统做法是人同时打开ChatGPT、Claude、通义千问好几个窗口一个问题分别问得到答案后自己在脑子里对比、复制、拼接再贴进文档。这个过程里有三重浪费——上下文切换的浪费、格式对齐的浪费、决策信息丢失的浪费。用户问完第二个模型时往往已经忘掉了第一个模型的推理细节最后只能凭感觉选一个“看起来更对”的答案。而“代理代为交互”的核心思路是把人从交互链路上撤下来改成由AI代理统一承接用户意图。代理自己去决定调用哪个模型、需要取哪些数据、按什么顺序执行、结果怎么拼装、冲突怎么消解。用户面对的不再是十几个各有脾气的AI系统而是一个统一入口、一个统一语言、一个统一结果形态。这个转变的本质是交互控制权从“用户侧”移交给了“代理侧”。但注意代理层绝不是简单的请求转发器。它需要理解意图边界、拆解任务、管理子任务生命周期、追踪执行状态、汇总多路结果并做冲突消解。落在系统架构上这就意味着要新增一层“代理中枢”而且这一层会成为整个系统里最复杂、最需要设计耐心的部分。1.2 多人多AI协同的真实场景光说概念容易飘我列几个我们实际跑过的场景大家感受一下“多人多AI协同”到底长什么样。第一个是市场部门的日报生成。三个分析师各负责不同渠道的数据要求每个渠道用不同的分析模型跑结论最后合并成一份统一的日报。单人单模型做这件事不难但三个分析师各自用自己的工具做做完以后格式不统一、口径不一致拼起来比自己做还累。第二个是研发部门的故障排查。监控系统触发告警后需要日志分析Agent、链路追踪Agent、知识库检索Agent同时介入分别分析日志特征、定位异常调用链、检索历史故障工单最后把三份分析结论合成一份根因报告。这个过程涉及多个Agent并行、中间结果互通、依赖关系编排靠人肉开多个终端去查效率低到没法接受。第三个是客服升级流程。用户问题先由客服机器人处理机器解决不了时需要质检模型、情绪分析模型、业务知识库模型和人工坐席共同决策最终给用户一个答复。这个场景的特殊之处在于模型的结论彼此可能冲突情绪分析说“用户很不满”知识库匹配却说“用户问题很简单”需要一套明确的冲突消解逻辑来裁决。这三个场景的共同特点非常明显多用户并发进入、多个AI系统并行处理、结果需要汇总且可能存在冲突、整个过程必须可追踪可审计。单机脚本或者普通API网关解决不了这类问题因为它们缺的不是“转发能力”而是“协同状态管理能力”。1.3 不做架构设计会踩哪些坑我见过不少团队跳过架构设计直接开干最后踩出四个典型大坑这里先说结论后面章节逐一展开应对方案。第一个坑是“多模型打架”。两个模型对同一个问题给出矛盾结论系统不知道该信谁最后只能靠人来裁决。这种坑在最早期最容易出现因为大家都默认“模型多了总比少了好”没意识到多模型的核心挑战是结果冲突处理。第二个坑是“上下文漂移”。每个子任务都带着全量历史去做分析上下文越滚越乱模型回复的质量肉眼可见地下降。尤其多轮协同场景里前一轮的中间输出混到后一轮的输入里模型把“别人的任务数据”当成“当前任务数据”来用直接导致结论跑偏。第三个坑是“单点风暴”。一个高并发入口把所有请求灌进同一个模型其他模型闲着整体吞吐被一个节点拖死。而且这类问题通常会以“外部AI系统额度突然被打爆”的形式暴露排查时才发现是内部调度侧没有做流量治理。第四个坑是“无法复盘”。线上出了问题想查是哪个模型、哪个Agent、哪个环节导致了错误结果日志分散在各个服务里格式不统一、链路串不起来只能靠开发人员一条一条翻时间全耗在排查上。这些坑都不是靠换一个更聪明的模型就能绕开的必须在架构层面给出答案。这也是这篇文章的核心主张先设计好协同架构再填充具体功能。2. 整体架构设计分层模型与核心模块2.1 四层架构总览与部署形态我们最终采用的架构是四层接入层、代理层、协同层、模型层。接入层负责统一API入口、鉴权、限流支持Web、企业微信、内部IM、移动端SDK等多种接入形态。这里多说一句如果你们的客户端涉及多端统一用Flutter这类跨端方案做接入层会很顺手一套协议打通App和Web避免每个端各写一套适配。代理层负责意图理解、任务规划、Agent生命周期管理。这一层的每个AI代理都是一个自治单元相当于一个“虚拟员工”——它有自己的职责边界、能力标签和决策逻辑可以独立完成一类子任务。协同层是整个架构的中枢负责任务调度、上下文管理、结果合并、冲突消解。之所以把协同层单独拆出来而不是塞进代理层内部是因为在多人多AI场景下代理会并发产生大量子任务子任务之间存在依赖关系需要编排——比如必须先完成数据检索才能进行总结分析。如果协同逻辑散落在各个代理内部一旦跨Agent协作状态就彻底乱了。模型层屏蔽不同AI系统的接入差异提供统一协议出口。这里特别说一下“本地模型云端模型混合”的接入方式。我们的实践是本地部署的向量模型、小参数专用模型和云端大模型都作为模型层的节点对待代理不关心背后是哪一种只看它能否满足能力标签和SLA要求。本地模型负责高频低成本的检索类任务云端大模型负责复杂推理和生成任务两者在模型层内做统一纳管替换成本极低。这里我借用一下分布式交换机系统架构里“控制面与数据面分离”的思路来做类比。协同层是控制面负责编排决策模型层是数据面负责实际执行。控制面不直接处理业务数据专心管调度、状态和策略数据面不关心任务从哪里来只按照协议执行并返回。这种分层的最大价值在于控制面可以独立伸缩数据面也可以独立扩容互不拖累。2.2 五个核心模块的职责拆解我习惯先把模块边界划清楚再动手写代码这是当年考系统架构设计师时养成的习惯——先画边界再补细节。这套架构最终落到五个核心模块会话管理模块Session Manager维护多用户多轮会话的状态。这里要特别区分“用户会话”和“任务会话”两层。用户会话是长连接记录交互目的、用户偏好、权限信息任务会话是短生命周期一次任务派发就建一个任务结束即销毁。两层分离的好处是用户中途打断任务、新起任务、切换任务都不会把执行状态搞乱。代理注册与发现模块Agent Registry负责让新接入的AI系统以插件形式注册并声明自己的能力标签和约束条件。能力标签像“擅长SQL生成”“擅长情感分析”“擅长多语言翻译”约束条件像最大并发数、支持的上下文长度、期望响应时延。调度时按标签匹配按约束过滤。任务编排引擎Orchestrator负责把用户的复杂意图拆解成DAG有向无环图按依赖关系调度执行。DAG里的每个节点是一个子任务每条边是一个依赖关系。这个模块是协同层里最复杂的部分因为它要同时处理任务分解、并行调度、失败重试、超时降级。上下文总线Context Bus是全局共享的中间结果存储区。所有子任务执行过程中的结构化中间结果都写进总线并附带版本号。这样做的好处是后续任务需要前序任务的输出时直接从总线按版本号取而不是把全量历史塞进每次模型调用。结果融合模块Result Fusion处理多AI输出的冲突消解和汇总。这个模块的输入是多个Agent的独立输出输出是一个统一的、经过验证的最终结果。关于冲突消解的策略我会在3.3节重点展开。模块核心职责关键接口/数据会话管理多轮状态维护、用户/任务会话分离session_id、session_state代理注册与发现能力声明、健康检查、路由匹配agent_id、capability tags任务编排引擎意图分解、DAG调度、重试补偿task_id、dependency graph上下文总线中间结果共享、版本控制、隔离payload、timestamp、version结果融合模块冲突检测、加权投票、人工升级confidence、source_agent_id2.3 关键设计取舍为什么这样做几个关键设计取舍值得单独拿出来讲因为它们在架构评审时争议最大。第一代理层与模型层必须解耦所有模型通过统一协议接入。这个和“AI代理助手加本地模型”的思路一脉相承代理的决策逻辑不依赖任何具体模型的API形态只看能力标签和SLA。实际好处是模型替换成本极低——我们曾经把一个核心模型从云端API切换为本地部署的推理服务只改了模型层的一个适配器代理层和协同层完全没动。第二会话状态与执行状态必须分离。会话状态属人记录的是“用户在聊什么”执行状态属系统记录的是“当前任务进行到哪一步”。两者不分离的后果是用户问了一句“刚才那个任务怎么样了”系统无法判断是在问历史任务还是当前任务只能靠猜。第三同步和异步通道并存而不是一刀切。用户发出复杂任务请求后立即返回一个task_id代理后台执行完成后通过回调或轮询通知结果。但低延迟交互类任务比如单轮问答、意图确认仍然走同步通道。哪个任务走同步、哪个走异步由任务类型决定这需要在任务规划阶段就标记好。第四每个任务都必须有超时和降级路径。任务启动时登记预期完成时间超时后先降级再失败——比如从“让3个模型投票”降级为“以主模型结果为准”而不是无限期等待。这个设计保住了整个系统的可用性底线某个外部AI系统再慢也不能拖垮用户的主流程。3. 核心机制实现代理交互协议与协同流程3.1 统一交互协议消息里到底放什么整个系统能跑起来的前提是定义一套统一交互协议。市面上现成的协议多是面向“人机对话”的缺少面向“代理间通信”的字段设计。我们最终采用的是JSON结构的消息格式每个消息包含三部分消息头、消息体、溯源信息。消息头声明消息类型request/response/event三种、关联task_id、涉及的agent_id、时间戳。消息体承载业务数据必须是结构化数据禁止用大段自然语言直接传递。溯源信息记录每一次Agent输出对应的输入上下文版本号这样后续如果发现结果有误可以精确回溯到“是哪个版本的上下文导致了错误”。这里有个细节必须强调消息里必须显式携带confidence置信度字段。这是多人多AI协同架构和普通API调用最大的区别之一。没有置信度后面的结果融合模块就完全无法判断该信谁。置信度的设置不要求模型自己精确打分可以由代理结合模型返回的logits分布、任务类型、历史准确率综合估算。以下是我们实际使用的消息协议核心字段示意{ header: { msg_type: request, task_id: task_20250111_001, parent_task_id: task_20250111_000, from_agent: intent_parser, to_agent: sql_generator, timestamp: 2025-01-11T10:22:33.000Z }, body: { intent: 生成本月各渠道销售汇总, params: {region: east, period: 2025-01}, confidence: 0.95 }, trace: { context_version: ctx_v3, source_message_ids: [msg_xxx] } }3.2 代理路由与任务分配怎么选Agent路由的核心不是“找到能干的Agent”而是“在多个能干的Agent里选出最合适的”。我们实现了一套两层路由策略第一层按能力标签筛选出候选Agent集合第二层在候选集合里按代价函数排序。代价函数主要考虑三个因素历史准确率、响应时延滑动窗口均值、当前队长度。最终选择代价最低的Agent作为主执行者同时把第二名的Agent留作备选。一旦主执行Agent失败直接切换备选重试不需要重新走一遍路由。这套策略在实测中把重试成功率提升了不少因为备选Agent通常具备相似能力不会因为同一原因失败。路由表必须支持动态更新不能写死。Agent上线、下线、健康状态变化时注册中心要实时推送变更消息。我们实测过一个数据点如果路由表更新延迟超过5秒高并发场景里就会出现大量请求路由到已下线Agent上的情况。所以这里不能靠定时轮询必须走事件驱动的推送机制。伪代码大致长这样def route_task(task, agent_registry): candidates [agent for agent in agent_registry if agent.match_capability(task.capability) and agent.is_healthy()] if not candidates: raise NoAgentAvailable(task) # 代价函数综合评估准确率、时延、队长度 ranked sorted(candidates, keylambda a: cost(a)) primary ranked[0] backup ranked[1] if len(ranked) 1 else None return primary, backup多Agent并行执行时任务编排引擎负责把一个大请求拆成多个子任务并行派发。但这里有一个反直觉的结论并行度不是越高越好。我们对每个模型层节点都设了并发阈值根据该AI系统的响应能力和外部API额度和动态计算防止同一个上游Agent把某个模型打爆。这就像分布式交换机的流量控制策略——队列排队比直接丢包要友好得多因为丢包会触发客户端重试反而放大压力。3.3 多AI结果合并与冲突消解信谁的多个Agent返回结果后不能简单拼接否则就是三个和尚没水喝。我们的结果融合模块采取三层策略按顺序执行。第一层是结构合并。如果多个Agent返回的是同构数据比如都是表格、都是JSON做字段级对比和拼接如果是异构内容一个是图表、一个是结论做内容级拼装组合。这一层的核心难点在于字段对齐——各Agent可能用不同命名表达同一个含义需要借助字段映射表或者让融合模块调用一个“对齐模型”做标准化。第二层是冲突检测。系统对比同一问题的多个答案计算语义相似度低于阈值就认为存在冲突。相似度计算我们直接用向量模型做embedding然后算余弦相似度。这里有个经验值相似度阈值设在0.75左右比较合适太高容易漏报冲突太低容易虚报。第三层是冲突消解策略。按任务类型选择不同的消解规则事实型问题用多数投票来源可信度加权统一输出各Agent的投票比例创新型问题以置信度最高的答案为主其他答案以参考形式附在附录里决策型问题则走人工升级通道把冲突情况连同各Agent的完整推理过程一并提交给负责人。这里有一个已经踩出来的深刻教训不要做“模型二次投票”。我们最初试过把多个模型的答案再丢给一个“仲裁模型”去判断结果发现仲裁模型经常有自己的倾向性而且越大的模型越容易被自己的先验偏好影响导致最后裁决反而弱于直接投票。所以能不做模型仲裁就尽量不做用规则、用权重、用投票都比再引入一个模型要可控得多。3.4 一次完整协同流程从用户发起到结果返回把上面的机制串起来看一次完整的多AI协同流程。假设用户发出请求“分析本月销售数据并对比竞品动态生成一份周报。”第一步接入层鉴权后代理层解析意图拆解出三个子任务数据分析、竞品信息检索、报告生成。三个子任务之间存在依赖前两个完成之后才能执行第三个。第二步任务编排引擎把三个子任务构造成DAG并根据能力标签将数据分析派给SQL生成Agent竞品检索派给网页搜索Agent报告生成暂时挂起等待前两者完成。第三步SQL生成Agent调用模型层的某个本地数据分析模型生成SQL并执行查询网页搜索Agent调用云端大模型抓取竞品新闻并总结。两个Agent并行执行中间结果写入上下文总线各带版本号。第四步前两个子任务完成后编排引擎唤醒报告生成Agent从上下文总线取回两个中间结果生成综合报告。第五步结果融合模块检查报告与各子任务输出的一致性确认无误后将最终报告返回给用户并把任务会话标记为完成全链路trace_id打点归档。这个流程看起来简单但每一步背后都有前面提到的路由、调度、上下文、融合机制在支撑。真正实现时每个环节都可能出问题这也是下一章要重点展开的内容。4. 工程落地中的关键问题与排查实录4.1 上下文漂移症状、原因与对策上下文漂移是多人多AI协同里最隐蔽、也最消耗排查时间的问题。表面症状是同一会话里Agent前面几轮回答质量还正常到后面开始答非所问甚至把之前任务里的数据当成当前任务的数据来用。我们遇到过最典型的一次用户先让Agent分析了华东区销售数据紧接着又问“那华南区呢”结果Agent给出的回答里分析图表数据还是华东区的。单看每一条日志都没问题但串起来一看问题出在上下文管理——系统把上一轮任务的全部中间结果原封不动地拼到了新一轮任务的输入里华南区的问题一来模型分不清哪些是背景数据、哪些是当前要处理的数据。根因就是上下文总线没有做好内容隔离。后来我们制定了严格的三级上下文策略一级是“任务级上下文”只包含当前子任务相关的最小必要信息二级是“会话级摘要”每五轮交互后由独立的摘要Agent生成一次结构化历史概要压缩掉过时细节三级是“全局知识”只放用户身份、偏好、权限这类稳定信息。一个模型调用能拿到什么上下文取决于它在任务DAG里的位置而不是它所在会话的历史长度。这条规则严格执行以后上下文漂移问题的出现率大幅下降。4.2 任务风暴一个真实案例的完整排查过程有段时间系统出现过一个诡异的现象某个用户一次触发了一个大任务该任务被拆解出120个子任务120个子任务几乎同时涌向模型层直接把几个外部AI系统的额度全打崩了。单看每个子任务的请求量都不大但从整体看这就是一次突刺式的流量冲击。排查过程我完整复盘一下。第一轮排查先从入口日志入手发现用户侧请求后端的耗时高达15秒远超正常水平。第二轮沿trace_id追踪到模型层发现某个外部AI系统返回了大量的429限流错误另外两个系统响应时延从正常的1.2秒上升到6秒以上。第三轮打开队列监控发现任务编排引擎在短时间内向模型层推送了密集请求峰值并发达到常规水平的20倍。定位到根因后解决方案分两步落地。第一步增加入口限流按用户维度做并发配额限制单用户同时活跃的任务数量超额任务进入排队队列不再无限派发。第二步增加出站限流给每个模型层节点配置令牌桶桶容量按该节点的承载能力动态设定出站方向统一限速。排查这类问题可观测性是第一生产力。现在每个任务发起时都会打上trace_id贯穿日志、消息、上下文三条链路出了异常依据trace_id就能串起选路、调度、模型响应、结果合并全过程。没有这套观测能力任务风暴排查会变成一场灾难。4.3 模型降级与容错别让单一Agent拖垮全局多人多AI协同的容错设计核心思想是一句话任何单点失败都不能阻塞主流程。我们给每个任务定义了三个降级等级。L1降级主Agent不可用时切换到备选Agent重试。这个最轻量只影响局部选择用户无感知。L2降级整类Agent都不可用时启用本地规则引擎生成保守结果宁可结果粗一点、精度差一点也不让流程断掉。L3降级部分冗余子任务比如“多模型对比验证”“多模型一致性检查”直接跳过用主结果直接进入下一步。这里必须强调降级策略必须在任务派发前定义好而不是等失败发生再临时决定。我们在DAG的每条边上都标注了“是否可降级”和“降级到哪个等级”编排引擎遇到节点失败时不需要人介入就能按预设路径切换。这是“AI代理代为交互”模式最核心的优势之一代理替用户承担了失败处理的决策过程用户不需要理解内部到底降了几级只需要知道最终结果可用。系统内部可能经历了从主模型到备选模型、再到本地规则的降级链但用户感知到的只是一个稳定交付的结果。4.4 可观测性设计系统内部发生什么必须看得见架构做大了以后最怕的就是黑盒。我们规划了三个维度的观测能力。第一是链路追踪维度。以trace_id打通任务全流程回答“这个结果是怎么来的”。每一层、每个Agent、每次模型调用都打点确保能重建任意一个结果的处理路径。第二是健康度维度。每个Agent都要上报心跳与性能指标包括成功率、时延、吞吐量回答“现在哪个节点处于亚健康状态”。第三是质量度维度。定期抽样对比Agent输出与人工标注结果评估每个Agent的能力漂移回答“哪个模型最近变强了或者变弱了”。观测数据最终汇聚到一个独立模块不依赖任何单个Agent的日志实现。因为Agent日志格式千差万别汇聚成本太高。统一做法是所有Agent接入SDK后强制按统一格式上报结构化事件存储层直接用时序库保存指标数据。在可观测性上我见过很多团队栽了跟头。他们的共同问题是等线上出了大问题才想到补日志但这个时候架构已经长歪了补观测比补功能还难。正确做法是在架构设计的第一天就把观测能力纳入规划哪怕是先打最简单的结构化日志也比事后补强一百倍。4.5 常见问题速查表症状可能原因排查方法解决思路多Agent结论互相矛盾冲突消解策略缺失检查结果融合模块是否被绕过启用三层冲突消解流程上下文越滚越乱上下文总线未隔离对比不同版本输入的模型输出严格按任务级/会话级/全局知识三级取上下文大量429限流错误子任务并行度过高查看出站令牌桶熔断记录增加模型层节点级限流配置Agent答非所问路由匹配到错误能力标签检查能力标签注册信息重新规划Agent注册与发现策略任务迟迟不结束某个外部AI系统卡死查看任务超时登记表为所有任务配置超时降级路径5. 一点实操感受收尾这套架构从设计到落地前后迭代了三个大版本。最大的体会是不要一次性把架构铺得太大先从小闭环跑起来。第一版我们只做“单人多模型路由”解决的是“选哪个模型”的问题第二版加入“DAG任务编排”解决的是“子任务如何协同”的问题第三版才完整加入“代理层与协同层分离”解决的是规模化、可观测、可降级的问题。每多一层运维复杂度就上一个台阶如果第一版就把四层全堆上大概率会死在调试复杂度里。还有一点是跨平台部署的坑。我们团队有几次在国产化服务器环境里部署遇到过CPU架构不匹配导致运行时无法启动的问题处理方式无一例外都是优先选用跨架构兼容的运行时再针对特定架构做灰度验证。这个看似无关紧要的部署细节在多人多AI协同架构里会放大成稳定性问题——一个节点的部署事故会影响整个协同链路的可用性所以基础设施层面的兼容性审查要放进架构评审清单。最后再说一句多AI协同系统的质量瓶颈从来不在“模型多聪明”而在“协同是否可控”。就像分布式交换机系统架构的核心在于控制面对数据面的规整管理AI协同架构的核心是把每一个决策点变成可观测、可决策、可恢复的节点。手里正在搭这类系统的朋友建议先盘一盘自己的场景里哪些环节必须人工介入、哪些可以交给代理自治——边界划清楚架构自然就清晰了。后面我还会继续补充这套架构在更多行业场景里的落地案例欢迎大家带着实战问题来交流。
多人多AI协同架构设计：代理编排、DAG调度与冲突消解实践
这两年AI Agent的热度高得惊人但你去观察实际落地场景会发现大多数实践还停留在“单用户单模型”的对话框里。真正进了生产环境迎面而来的往往是另一番景象一个团队里好几个人同时在用三五个AI系统每个模型各有擅长但彼此说不上话流程中间全靠人肉搬运输出、复制粘贴、手工汇总。这种“人多、AI多、协作乱”的状态恰恰是企业级应用里最普遍也最难受的环节。我自己在带团队做AI中台的过程中被这类问题反复折磨最后转向了“AI代理代为交互”的多人多AI协同架构——不是让用户自己去敲每个模型的接口而是让一组自治的AI代理替用户完成跨系统的感知、调度、取数、汇总和交付。这篇文章会把这套架构的设计思路、核心模块、关键实现和踩坑记录完整摊开适合正在做AI编排层、智能工作流或者多模型网关的工程师和架构师参考也适合刚接触Agent系统、想少走弯路的产品和技术负责人通读一遍。1. 为什么需要“代理代为交互”场景与痛点拆解1.1 从“人找AI”到“AI代理找人”先看一个最简单的对比。传统做法是人同时打开ChatGPT、Claude、通义千问好几个窗口一个问题分别问得到答案后自己在脑子里对比、复制、拼接再贴进文档。这个过程里有三重浪费——上下文切换的浪费、格式对齐的浪费、决策信息丢失的浪费。用户问完第二个模型时往往已经忘掉了第一个模型的推理细节最后只能凭感觉选一个“看起来更对”的答案。而“代理代为交互”的核心思路是把人从交互链路上撤下来改成由AI代理统一承接用户意图。代理自己去决定调用哪个模型、需要取哪些数据、按什么顺序执行、结果怎么拼装、冲突怎么消解。用户面对的不再是十几个各有脾气的AI系统而是一个统一入口、一个统一语言、一个统一结果形态。这个转变的本质是交互控制权从“用户侧”移交给了“代理侧”。但注意代理层绝不是简单的请求转发器。它需要理解意图边界、拆解任务、管理子任务生命周期、追踪执行状态、汇总多路结果并做冲突消解。落在系统架构上这就意味着要新增一层“代理中枢”而且这一层会成为整个系统里最复杂、最需要设计耐心的部分。1.2 多人多AI协同的真实场景光说概念容易飘我列几个我们实际跑过的场景大家感受一下“多人多AI协同”到底长什么样。第一个是市场部门的日报生成。三个分析师各负责不同渠道的数据要求每个渠道用不同的分析模型跑结论最后合并成一份统一的日报。单人单模型做这件事不难但三个分析师各自用自己的工具做做完以后格式不统一、口径不一致拼起来比自己做还累。第二个是研发部门的故障排查。监控系统触发告警后需要日志分析Agent、链路追踪Agent、知识库检索Agent同时介入分别分析日志特征、定位异常调用链、检索历史故障工单最后把三份分析结论合成一份根因报告。这个过程涉及多个Agent并行、中间结果互通、依赖关系编排靠人肉开多个终端去查效率低到没法接受。第三个是客服升级流程。用户问题先由客服机器人处理机器解决不了时需要质检模型、情绪分析模型、业务知识库模型和人工坐席共同决策最终给用户一个答复。这个场景的特殊之处在于模型的结论彼此可能冲突情绪分析说“用户很不满”知识库匹配却说“用户问题很简单”需要一套明确的冲突消解逻辑来裁决。这三个场景的共同特点非常明显多用户并发进入、多个AI系统并行处理、结果需要汇总且可能存在冲突、整个过程必须可追踪可审计。单机脚本或者普通API网关解决不了这类问题因为它们缺的不是“转发能力”而是“协同状态管理能力”。1.3 不做架构设计会踩哪些坑我见过不少团队跳过架构设计直接开干最后踩出四个典型大坑这里先说结论后面章节逐一展开应对方案。第一个坑是“多模型打架”。两个模型对同一个问题给出矛盾结论系统不知道该信谁最后只能靠人来裁决。这种坑在最早期最容易出现因为大家都默认“模型多了总比少了好”没意识到多模型的核心挑战是结果冲突处理。第二个坑是“上下文漂移”。每个子任务都带着全量历史去做分析上下文越滚越乱模型回复的质量肉眼可见地下降。尤其多轮协同场景里前一轮的中间输出混到后一轮的输入里模型把“别人的任务数据”当成“当前任务数据”来用直接导致结论跑偏。第三个坑是“单点风暴”。一个高并发入口把所有请求灌进同一个模型其他模型闲着整体吞吐被一个节点拖死。而且这类问题通常会以“外部AI系统额度突然被打爆”的形式暴露排查时才发现是内部调度侧没有做流量治理。第四个坑是“无法复盘”。线上出了问题想查是哪个模型、哪个Agent、哪个环节导致了错误结果日志分散在各个服务里格式不统一、链路串不起来只能靠开发人员一条一条翻时间全耗在排查上。这些坑都不是靠换一个更聪明的模型就能绕开的必须在架构层面给出答案。这也是这篇文章的核心主张先设计好协同架构再填充具体功能。2. 整体架构设计分层模型与核心模块2.1 四层架构总览与部署形态我们最终采用的架构是四层接入层、代理层、协同层、模型层。接入层负责统一API入口、鉴权、限流支持Web、企业微信、内部IM、移动端SDK等多种接入形态。这里多说一句如果你们的客户端涉及多端统一用Flutter这类跨端方案做接入层会很顺手一套协议打通App和Web避免每个端各写一套适配。代理层负责意图理解、任务规划、Agent生命周期管理。这一层的每个AI代理都是一个自治单元相当于一个“虚拟员工”——它有自己的职责边界、能力标签和决策逻辑可以独立完成一类子任务。协同层是整个架构的中枢负责任务调度、上下文管理、结果合并、冲突消解。之所以把协同层单独拆出来而不是塞进代理层内部是因为在多人多AI场景下代理会并发产生大量子任务子任务之间存在依赖关系需要编排——比如必须先完成数据检索才能进行总结分析。如果协同逻辑散落在各个代理内部一旦跨Agent协作状态就彻底乱了。模型层屏蔽不同AI系统的接入差异提供统一协议出口。这里特别说一下“本地模型云端模型混合”的接入方式。我们的实践是本地部署的向量模型、小参数专用模型和云端大模型都作为模型层的节点对待代理不关心背后是哪一种只看它能否满足能力标签和SLA要求。本地模型负责高频低成本的检索类任务云端大模型负责复杂推理和生成任务两者在模型层内做统一纳管替换成本极低。这里我借用一下分布式交换机系统架构里“控制面与数据面分离”的思路来做类比。协同层是控制面负责编排决策模型层是数据面负责实际执行。控制面不直接处理业务数据专心管调度、状态和策略数据面不关心任务从哪里来只按照协议执行并返回。这种分层的最大价值在于控制面可以独立伸缩数据面也可以独立扩容互不拖累。2.2 五个核心模块的职责拆解我习惯先把模块边界划清楚再动手写代码这是当年考系统架构设计师时养成的习惯——先画边界再补细节。这套架构最终落到五个核心模块会话管理模块Session Manager维护多用户多轮会话的状态。这里要特别区分“用户会话”和“任务会话”两层。用户会话是长连接记录交互目的、用户偏好、权限信息任务会话是短生命周期一次任务派发就建一个任务结束即销毁。两层分离的好处是用户中途打断任务、新起任务、切换任务都不会把执行状态搞乱。代理注册与发现模块Agent Registry负责让新接入的AI系统以插件形式注册并声明自己的能力标签和约束条件。能力标签像“擅长SQL生成”“擅长情感分析”“擅长多语言翻译”约束条件像最大并发数、支持的上下文长度、期望响应时延。调度时按标签匹配按约束过滤。任务编排引擎Orchestrator负责把用户的复杂意图拆解成DAG有向无环图按依赖关系调度执行。DAG里的每个节点是一个子任务每条边是一个依赖关系。这个模块是协同层里最复杂的部分因为它要同时处理任务分解、并行调度、失败重试、超时降级。上下文总线Context Bus是全局共享的中间结果存储区。所有子任务执行过程中的结构化中间结果都写进总线并附带版本号。这样做的好处是后续任务需要前序任务的输出时直接从总线按版本号取而不是把全量历史塞进每次模型调用。结果融合模块Result Fusion处理多AI输出的冲突消解和汇总。这个模块的输入是多个Agent的独立输出输出是一个统一的、经过验证的最终结果。关于冲突消解的策略我会在3.3节重点展开。模块核心职责关键接口/数据会话管理多轮状态维护、用户/任务会话分离session_id、session_state代理注册与发现能力声明、健康检查、路由匹配agent_id、capability tags任务编排引擎意图分解、DAG调度、重试补偿task_id、dependency graph上下文总线中间结果共享、版本控制、隔离payload、timestamp、version结果融合模块冲突检测、加权投票、人工升级confidence、source_agent_id2.3 关键设计取舍为什么这样做几个关键设计取舍值得单独拿出来讲因为它们在架构评审时争议最大。第一代理层与模型层必须解耦所有模型通过统一协议接入。这个和“AI代理助手加本地模型”的思路一脉相承代理的决策逻辑不依赖任何具体模型的API形态只看能力标签和SLA。实际好处是模型替换成本极低——我们曾经把一个核心模型从云端API切换为本地部署的推理服务只改了模型层的一个适配器代理层和协同层完全没动。第二会话状态与执行状态必须分离。会话状态属人记录的是“用户在聊什么”执行状态属系统记录的是“当前任务进行到哪一步”。两者不分离的后果是用户问了一句“刚才那个任务怎么样了”系统无法判断是在问历史任务还是当前任务只能靠猜。第三同步和异步通道并存而不是一刀切。用户发出复杂任务请求后立即返回一个task_id代理后台执行完成后通过回调或轮询通知结果。但低延迟交互类任务比如单轮问答、意图确认仍然走同步通道。哪个任务走同步、哪个走异步由任务类型决定这需要在任务规划阶段就标记好。第四每个任务都必须有超时和降级路径。任务启动时登记预期完成时间超时后先降级再失败——比如从“让3个模型投票”降级为“以主模型结果为准”而不是无限期等待。这个设计保住了整个系统的可用性底线某个外部AI系统再慢也不能拖垮用户的主流程。3. 核心机制实现代理交互协议与协同流程3.1 统一交互协议消息里到底放什么整个系统能跑起来的前提是定义一套统一交互协议。市面上现成的协议多是面向“人机对话”的缺少面向“代理间通信”的字段设计。我们最终采用的是JSON结构的消息格式每个消息包含三部分消息头、消息体、溯源信息。消息头声明消息类型request/response/event三种、关联task_id、涉及的agent_id、时间戳。消息体承载业务数据必须是结构化数据禁止用大段自然语言直接传递。溯源信息记录每一次Agent输出对应的输入上下文版本号这样后续如果发现结果有误可以精确回溯到“是哪个版本的上下文导致了错误”。这里有个细节必须强调消息里必须显式携带confidence置信度字段。这是多人多AI协同架构和普通API调用最大的区别之一。没有置信度后面的结果融合模块就完全无法判断该信谁。置信度的设置不要求模型自己精确打分可以由代理结合模型返回的logits分布、任务类型、历史准确率综合估算。以下是我们实际使用的消息协议核心字段示意{ header: { msg_type: request, task_id: task_20250111_001, parent_task_id: task_20250111_000, from_agent: intent_parser, to_agent: sql_generator, timestamp: 2025-01-11T10:22:33.000Z }, body: { intent: 生成本月各渠道销售汇总, params: {region: east, period: 2025-01}, confidence: 0.95 }, trace: { context_version: ctx_v3, source_message_ids: [msg_xxx] } }3.2 代理路由与任务分配怎么选Agent路由的核心不是“找到能干的Agent”而是“在多个能干的Agent里选出最合适的”。我们实现了一套两层路由策略第一层按能力标签筛选出候选Agent集合第二层在候选集合里按代价函数排序。代价函数主要考虑三个因素历史准确率、响应时延滑动窗口均值、当前队长度。最终选择代价最低的Agent作为主执行者同时把第二名的Agent留作备选。一旦主执行Agent失败直接切换备选重试不需要重新走一遍路由。这套策略在实测中把重试成功率提升了不少因为备选Agent通常具备相似能力不会因为同一原因失败。路由表必须支持动态更新不能写死。Agent上线、下线、健康状态变化时注册中心要实时推送变更消息。我们实测过一个数据点如果路由表更新延迟超过5秒高并发场景里就会出现大量请求路由到已下线Agent上的情况。所以这里不能靠定时轮询必须走事件驱动的推送机制。伪代码大致长这样def route_task(task, agent_registry): candidates [agent for agent in agent_registry if agent.match_capability(task.capability) and agent.is_healthy()] if not candidates: raise NoAgentAvailable(task) # 代价函数综合评估准确率、时延、队长度 ranked sorted(candidates, keylambda a: cost(a)) primary ranked[0] backup ranked[1] if len(ranked) 1 else None return primary, backup多Agent并行执行时任务编排引擎负责把一个大请求拆成多个子任务并行派发。但这里有一个反直觉的结论并行度不是越高越好。我们对每个模型层节点都设了并发阈值根据该AI系统的响应能力和外部API额度和动态计算防止同一个上游Agent把某个模型打爆。这就像分布式交换机的流量控制策略——队列排队比直接丢包要友好得多因为丢包会触发客户端重试反而放大压力。3.3 多AI结果合并与冲突消解信谁的多个Agent返回结果后不能简单拼接否则就是三个和尚没水喝。我们的结果融合模块采取三层策略按顺序执行。第一层是结构合并。如果多个Agent返回的是同构数据比如都是表格、都是JSON做字段级对比和拼接如果是异构内容一个是图表、一个是结论做内容级拼装组合。这一层的核心难点在于字段对齐——各Agent可能用不同命名表达同一个含义需要借助字段映射表或者让融合模块调用一个“对齐模型”做标准化。第二层是冲突检测。系统对比同一问题的多个答案计算语义相似度低于阈值就认为存在冲突。相似度计算我们直接用向量模型做embedding然后算余弦相似度。这里有个经验值相似度阈值设在0.75左右比较合适太高容易漏报冲突太低容易虚报。第三层是冲突消解策略。按任务类型选择不同的消解规则事实型问题用多数投票来源可信度加权统一输出各Agent的投票比例创新型问题以置信度最高的答案为主其他答案以参考形式附在附录里决策型问题则走人工升级通道把冲突情况连同各Agent的完整推理过程一并提交给负责人。这里有一个已经踩出来的深刻教训不要做“模型二次投票”。我们最初试过把多个模型的答案再丢给一个“仲裁模型”去判断结果发现仲裁模型经常有自己的倾向性而且越大的模型越容易被自己的先验偏好影响导致最后裁决反而弱于直接投票。所以能不做模型仲裁就尽量不做用规则、用权重、用投票都比再引入一个模型要可控得多。3.4 一次完整协同流程从用户发起到结果返回把上面的机制串起来看一次完整的多AI协同流程。假设用户发出请求“分析本月销售数据并对比竞品动态生成一份周报。”第一步接入层鉴权后代理层解析意图拆解出三个子任务数据分析、竞品信息检索、报告生成。三个子任务之间存在依赖前两个完成之后才能执行第三个。第二步任务编排引擎把三个子任务构造成DAG并根据能力标签将数据分析派给SQL生成Agent竞品检索派给网页搜索Agent报告生成暂时挂起等待前两者完成。第三步SQL生成Agent调用模型层的某个本地数据分析模型生成SQL并执行查询网页搜索Agent调用云端大模型抓取竞品新闻并总结。两个Agent并行执行中间结果写入上下文总线各带版本号。第四步前两个子任务完成后编排引擎唤醒报告生成Agent从上下文总线取回两个中间结果生成综合报告。第五步结果融合模块检查报告与各子任务输出的一致性确认无误后将最终报告返回给用户并把任务会话标记为完成全链路trace_id打点归档。这个流程看起来简单但每一步背后都有前面提到的路由、调度、上下文、融合机制在支撑。真正实现时每个环节都可能出问题这也是下一章要重点展开的内容。4. 工程落地中的关键问题与排查实录4.1 上下文漂移症状、原因与对策上下文漂移是多人多AI协同里最隐蔽、也最消耗排查时间的问题。表面症状是同一会话里Agent前面几轮回答质量还正常到后面开始答非所问甚至把之前任务里的数据当成当前任务的数据来用。我们遇到过最典型的一次用户先让Agent分析了华东区销售数据紧接着又问“那华南区呢”结果Agent给出的回答里分析图表数据还是华东区的。单看每一条日志都没问题但串起来一看问题出在上下文管理——系统把上一轮任务的全部中间结果原封不动地拼到了新一轮任务的输入里华南区的问题一来模型分不清哪些是背景数据、哪些是当前要处理的数据。根因就是上下文总线没有做好内容隔离。后来我们制定了严格的三级上下文策略一级是“任务级上下文”只包含当前子任务相关的最小必要信息二级是“会话级摘要”每五轮交互后由独立的摘要Agent生成一次结构化历史概要压缩掉过时细节三级是“全局知识”只放用户身份、偏好、权限这类稳定信息。一个模型调用能拿到什么上下文取决于它在任务DAG里的位置而不是它所在会话的历史长度。这条规则严格执行以后上下文漂移问题的出现率大幅下降。4.2 任务风暴一个真实案例的完整排查过程有段时间系统出现过一个诡异的现象某个用户一次触发了一个大任务该任务被拆解出120个子任务120个子任务几乎同时涌向模型层直接把几个外部AI系统的额度全打崩了。单看每个子任务的请求量都不大但从整体看这就是一次突刺式的流量冲击。排查过程我完整复盘一下。第一轮排查先从入口日志入手发现用户侧请求后端的耗时高达15秒远超正常水平。第二轮沿trace_id追踪到模型层发现某个外部AI系统返回了大量的429限流错误另外两个系统响应时延从正常的1.2秒上升到6秒以上。第三轮打开队列监控发现任务编排引擎在短时间内向模型层推送了密集请求峰值并发达到常规水平的20倍。定位到根因后解决方案分两步落地。第一步增加入口限流按用户维度做并发配额限制单用户同时活跃的任务数量超额任务进入排队队列不再无限派发。第二步增加出站限流给每个模型层节点配置令牌桶桶容量按该节点的承载能力动态设定出站方向统一限速。排查这类问题可观测性是第一生产力。现在每个任务发起时都会打上trace_id贯穿日志、消息、上下文三条链路出了异常依据trace_id就能串起选路、调度、模型响应、结果合并全过程。没有这套观测能力任务风暴排查会变成一场灾难。4.3 模型降级与容错别让单一Agent拖垮全局多人多AI协同的容错设计核心思想是一句话任何单点失败都不能阻塞主流程。我们给每个任务定义了三个降级等级。L1降级主Agent不可用时切换到备选Agent重试。这个最轻量只影响局部选择用户无感知。L2降级整类Agent都不可用时启用本地规则引擎生成保守结果宁可结果粗一点、精度差一点也不让流程断掉。L3降级部分冗余子任务比如“多模型对比验证”“多模型一致性检查”直接跳过用主结果直接进入下一步。这里必须强调降级策略必须在任务派发前定义好而不是等失败发生再临时决定。我们在DAG的每条边上都标注了“是否可降级”和“降级到哪个等级”编排引擎遇到节点失败时不需要人介入就能按预设路径切换。这是“AI代理代为交互”模式最核心的优势之一代理替用户承担了失败处理的决策过程用户不需要理解内部到底降了几级只需要知道最终结果可用。系统内部可能经历了从主模型到备选模型、再到本地规则的降级链但用户感知到的只是一个稳定交付的结果。4.4 可观测性设计系统内部发生什么必须看得见架构做大了以后最怕的就是黑盒。我们规划了三个维度的观测能力。第一是链路追踪维度。以trace_id打通任务全流程回答“这个结果是怎么来的”。每一层、每个Agent、每次模型调用都打点确保能重建任意一个结果的处理路径。第二是健康度维度。每个Agent都要上报心跳与性能指标包括成功率、时延、吞吐量回答“现在哪个节点处于亚健康状态”。第三是质量度维度。定期抽样对比Agent输出与人工标注结果评估每个Agent的能力漂移回答“哪个模型最近变强了或者变弱了”。观测数据最终汇聚到一个独立模块不依赖任何单个Agent的日志实现。因为Agent日志格式千差万别汇聚成本太高。统一做法是所有Agent接入SDK后强制按统一格式上报结构化事件存储层直接用时序库保存指标数据。在可观测性上我见过很多团队栽了跟头。他们的共同问题是等线上出了大问题才想到补日志但这个时候架构已经长歪了补观测比补功能还难。正确做法是在架构设计的第一天就把观测能力纳入规划哪怕是先打最简单的结构化日志也比事后补强一百倍。4.5 常见问题速查表症状可能原因排查方法解决思路多Agent结论互相矛盾冲突消解策略缺失检查结果融合模块是否被绕过启用三层冲突消解流程上下文越滚越乱上下文总线未隔离对比不同版本输入的模型输出严格按任务级/会话级/全局知识三级取上下文大量429限流错误子任务并行度过高查看出站令牌桶熔断记录增加模型层节点级限流配置Agent答非所问路由匹配到错误能力标签检查能力标签注册信息重新规划Agent注册与发现策略任务迟迟不结束某个外部AI系统卡死查看任务超时登记表为所有任务配置超时降级路径5. 一点实操感受收尾这套架构从设计到落地前后迭代了三个大版本。最大的体会是不要一次性把架构铺得太大先从小闭环跑起来。第一版我们只做“单人多模型路由”解决的是“选哪个模型”的问题第二版加入“DAG任务编排”解决的是“子任务如何协同”的问题第三版才完整加入“代理层与协同层分离”解决的是规模化、可观测、可降级的问题。每多一层运维复杂度就上一个台阶如果第一版就把四层全堆上大概率会死在调试复杂度里。还有一点是跨平台部署的坑。我们团队有几次在国产化服务器环境里部署遇到过CPU架构不匹配导致运行时无法启动的问题处理方式无一例外都是优先选用跨架构兼容的运行时再针对特定架构做灰度验证。这个看似无关紧要的部署细节在多人多AI协同架构里会放大成稳定性问题——一个节点的部署事故会影响整个协同链路的可用性所以基础设施层面的兼容性审查要放进架构评审清单。最后再说一句多AI协同系统的质量瓶颈从来不在“模型多聪明”而在“协同是否可控”。就像分布式交换机系统架构的核心在于控制面对数据面的规整管理AI协同架构的核心是把每一个决策点变成可观测、可决策、可恢复的节点。手里正在搭这类系统的朋友建议先盘一盘自己的场景里哪些环节必须人工介入、哪些可以交给代理自治——边界划清楚架构自然就清晰了。后面我还会继续补充这套架构在更多行业场景里的落地案例欢迎大家带着实战问题来交流。
