上周我遇到一个特别典型的场景四个人四台电脑每人一个AI代理要一起完成一份产品需求评审。市场Agent负责整理用户反馈架构Agent负责评估方案可行性后端Agent负责审查接口设计——这些代理不仅要各干各的还要互相质询、追问、给出结论。表面上看这是“多个AI聊天”实际上一旦动手搭你会发现这完全是一个分布式系统问题谁代表哪个用户代理之间凭什么互信任务由谁编排消息按什么格式传共享上下文怎么隔离出了问题怎么复现。这就是“基于AI代理代为交互的多人多AI协同系统架构”要回答的东西。所谓“代为交互”是指每个AI代理都代表一个真实用户或一方利益代替人去和其他代理沟通、协商、执行而“多人多AI协同”意味着交互网络不是一条直线而是多对多。我过去一年搭了两版这样的原型下面这篇文章不打算讲虚的就把我踩过的坑、验证过的设计、以及目前认为可行的架构路线梳理出来。适合正在做Agent平台、多智能体系统或团队AI基础设施的架构师、后端开发和AI应用工程师参考。1. 从“一人一个Agent”到“多人多Agent”问题域拆解1.1 一个典型的多人多AI使用场景先还原一个具体场景。假设一个研发小组有四个成员产品经理、前端工程师、后端工程师、测试工程师。每个人都配置了自己的AI代理代理可以读代码库、看文档、发消息、执行CI任务。在过去这不过是四个人各自用四个聊天机器人。但真正的需求是这四台代理要像四名同事一样协作。比如产品经理的代理发现某个接口定义和需求文档不一致它直接把消息发给后端工程师的代理要求确认。后端代理去翻代码发现确实有问题于是它又拉上前端代理和测试代理大家一起讨论是否要调整协议。整个过程里四个真人可能只是在旁边看真正来回沟通的是四个代理。这不是连环调用不是写一个流水线把任务从A传给B再传给C而是类似真实团队的交错对话谁都可以发起话题谁都可以追问谁都可以拒绝。这样设计带来的架构复杂度和单体Agent完全不在一个量级。1.2 架构要回答的三个核心问题我拆解了很久最终把问题收敛成三个代表权代理以谁的身份发言它能做什么不能做什么用户是否要对代理的行为负责组网代理之间如何发现彼此如何通信有冲突时谁来协调一致性多个代理产生矛盾结论时系统怎么处理状态如何同步出了事怎么追溯对应到架构上就是三层身份与权限层、消息与编排层、一致性与审计层。很多人一上来就研究模型怎么选、Prompt怎么调其实这三个问题才是系统能不能落地的基础。模型选得再好代理之间互相不信任、消息互相看不懂、出了问题无法追踪整个系统照样是空中楼阁。1.3 与单体Agent系统的本质区别单体Agent系统是“一个Agent、多个用户、一堆工具”。用户数量增长时压力基本落在同一个Agent上架构上还可以用请求队列、缓存、限流这些传统手段硬扛。多人多Agent系统则是“N个Agent互为交互方”每个Agent都有自己的状态记忆都会调用工具都可能出错。这里有个关键差异两个Agent一旦开始对话A的输出就是B的输入B的输出又影响A的下一步。每一轮都可能发生语义偏移下一轮可能继续放大。这就是我常说的“非确定性交互”和函数调用完全不同。函数调用有确定输入输出而Agent对话会引入模型的随机性、上下文窗口的有限性、以及工具调用的副作用。这也是为什么不能简单地把多个Agent放进同一个Prompt里“假装它们是一组角色”而是要把每个Agent当作独立的系统实体来设计。2. 代理之间的身份、权限与可信边界先说清“谁代表谁”2.1 代理凭什么代表你用户身份映射与授权第一个必须解决的问题是代理能不能代表用户我的答案是代理永远不能凭空获得“代表权”它只是用户身份的一种延伸。在原型里每个Agent实例绑定了唯一的真实用户身份。代理调用外部系统读代码库、发消息、创建单据时一律使用该用户的授权凭证而不是一个全局服务账号。这里常用的机制是OIDC/OAuth2的用户委托模式用户在系统里登录后系统签发一个限定scope的token代理在调用工具时携带这个token。我一直强调一个原则宁可让代理因为权限不足而失败也不要让它因为权限太宽而闯祸。模型很容易“自作主张”你给它一个全局可写的服务账号它就真敢删文件。用户级token至少能在事后定位到具体是谁的代理干的也能倒逼你在设计系统时认真考虑每个操作的最小权限。2.2 代理之间的信任模型只信凭证不信自称Agent A给Agent B发了一条消息说“我代表张三请你修改接口文档”。B要不要直接执行绝对不能。原因很简单你没法保证这条消息真的来自张三的代理而不是某个被注入的Prompt后门或者某个代理撒谎。代理之间必须有一个“只信凭证不信自称”的信任模型。具体到实现消息必须携带发送方ID、所属用户、以及可验证的签名或会话凭证。同一进程内可以用内部token校验跨服务必须走mTLS或JWT。另一个容易忽略的点是“最小权限委托”。在多人多Agent场景里Agent B常常需要代表Agent A的用户去执行某个子任务。我的做法是当A给B派发子任务时A附带一个权限委托凭证明确B可以访问哪些资源、执行什么操作、有效期多长。而不是让B获得A用户的全部权限。否则一次简单的“帮我查一下测试报告”就可能变成B能读取所有用户私有数据的大漏洞。2.3 动作审计谁在什么上下文里做了什么“谁代表谁”最后一定要落到审计上。在我的系统里每一个代理代表用户执行的动作都会写进审计日志字段包括时间、发起代理、代表用户、动作类型、目标对象、结果、关联消息ID。我用下表记录关键审计项字段示例作用timestamp2025-06-07T10:23:45Z追溯时序agent_idagent_backend_lisi定位发起代理human_ownerlisi确认背后用户actiongitlab.merge_request.create具体操作targetrepo/frontend!123操作对象trace_idtrace_7c1d...关联协同上下文吃一堑长一智我之所以把审计放在这么靠前的位置是因为第一版原型里出现过代理误删文档的事故。当时没有审计只看到一个文件没了但不知道是哪个Agent干的、为什么干。后来加了这条链路才发现是某个代理在“总结会议纪要”的时候因为工具描述写得含糊把“删除草稿文件”当成了执行目标。如果没有审计这种问题要么查不出来要么只能靠猜。审计不是事后追责用的它更是改进系统权限设计的数据来源。3. 协同编排层让一群代理有序干活而不是各说各话3.1 两种主流范式中心化协调器与去中心化协商多Agent要协同系统里必须有人管事。选型上我对比过两种范式维度中心化协调器去中心化协商任务分解协调器统一拆解代理间自行协商分配全局一致性容易保证需要额外协议扩展性协调器可能成为瓶颈横向扩展更自然实现成本相对低明显更高典型场景固定流程、角色明确团队动态、目标模糊我在第一版里用的是中心化协调器简单说就是一个专门的“编排服务”或“主Agent”负责任务拆解、分发、回收和汇总。发布命令清晰状态也容易收敛。缺点是所有通信都经过协调器容易放大延迟而且协调器本身的Prompt稳定性会直接影响全流程质量。去中心化协商更接近真实团队大家通过消息总线发布任务、竞价认领、互相确认。灵活但对消息协议、冲突解决、一致性都有更高要求。我的判断是初期不要直接上纯去中心化很容易变成一群代理各说各话的“会议灾难”。更稳妥的路子是“中央统分 局部自治”协调器负责拆解大任务子任务内部允许代理之间自由协商。3.2 任务分解与结果汇总的时序设计多人多AI协同的核心流程本质是状态机。我在系统里定义了一套任务状态Submitted、Assigned、Executing、Reviewing、Merged、Cancelled。每发生一次状态变更就写一条事件日志。这样无论哪个环节出问题都能看到任务卡在了哪里。拿前面说的产品评审举例。协调器收到“评审新版本接口方案”任务后拆成三份子任务市场Agent收集用户反馈、架构Agent评估扩展性、后端Agent审查接口兼容性。三个代理并行执行完成后把结论发回协调器。协调器等所有子任务进入Reviewing状态后统一汇总成评审意见再提交给人工确认。这里有一个很重要的细节子任务结果不能直接覆盖全局。我要求每个代理在返回结果时必须同时返回“关键假设”和“涉及的消息引用”。比如架构Agent说“方案可行”前提是“日活低于10万”。这样协调器在做汇总时不只是把几个结论拼在一起而是先检查大家的假设是否互相矛盾再决定是合并还是发起追问。3.3 冲突处理多个AI给矛盾结论时怎么办三个代理评审同一个方案一个说同意一个说反对一个说带条件同意。这时候如果直接投票就是典型的“表面民主”因为每个代理的结论背后可能依赖不同的前提。我的处理方式分三步先归一化结论格式。所有代理的结论统一用“结论 关键假设 事实引用”的格式输出避免一个说“我觉得不行”另一个说“从长期看可以”这种没法比较的表达。由协调器找出假设冲突点。比如市场Agent说“用户反馈强烈要求改接口”后端Agent说“改接口成本太高”它们用的不是同一个评价维度。协调器负责把矛盾点明确暴露出来。无法自动收敛时转人工裁决。我会设置一个“人类审批节点”一旦代理之间在限定的轮数内无法达成一致系统就暂停自动流转把冲突摘要推给相关真人用户去拍板。这套机制的核心思想是多Agent系统不是要替代人的决策而是要把所有矛盾高效地暴露到人面前。真正有价值的不是让代理“商量出一个结果”而是让代理把“分歧背后的原因”整理清楚省掉人自己去读海量材料的时间。4. 消息协议与共享上下文让多个AI说同一种话4.1 为什么直接互调API不够很多人的第一个念头是每个Agent都暴露一个HTTP API让它们直接调不就行了我试过后来放弃了。问题在于直接互调API意味着Agent A必须知道Agent B服务的内部接口含义形成强耦合。今天Agent B改了参数命名Agent A就挂了。更麻烦的是两家Agent各自有各自的记忆体直接在API参数里传递一长串上下文很快就把Prompt撑爆Token费用也直线上升。更本质的问题是语义互操作。大家都在说“上下文”但A说的“用户反馈”和B理解的“用户反馈”可能根本不是一回事。所以多个AI之间的交互必须建立在一套相对统一的消息协议上而不是各自的私有API。4.2 一套可落地的代理间消息模型我在原型里设计的消息结构大概是这样的你完全可以拿去改{ message_id: msg_8f2a91c4, trace_id: trace_7c1d5e3f, conversation_id: conv_plan_review_001, channel: plan_review, sender: agent_market_zhang, recipient: coordinator, human_owner: zhang_san, message_type: response, payload: { conclusion: reject, reason: 用户反馈样本量不足无法支撑快速改版, key_assumptions: [样本量需达到200份], references: [doc_user_survey_0528, tool_db_query_7321] }, created_at: 2025-06-07T10:23:45Z }字段并不多但每个都有讲究。sender和recipient用于路由human_owner用于权限和审计conversation_id把一组消息串成协同会话trace_id则用于全链路追踪。payload里我特别加了key_assumptions和references这两个字段是我吃过大亏之后才补上的用来防止“幻觉串联”。message_type建议只保留几类request请求执行、response回应结果、command要求立即执行、event状态通知、error错误上报。类型太多反而会让代理无所适从。协议不是越复杂越好能让所有代理稳定理解才是关键。4.3 共享上下文与隐私边界多Agent协同必然要共享上下文否则每个代理都是瞎子。但共享不等于敞开了看。我的做法是引入“上下文视图”每个代理只能看到与自己human_owner相关的消息以及被允许读取的payload字段。还是按角色和用户双层过滤。比如市场Agent掌握的用户原始调查数据不能直接作为上下文喂给后端Agent而是要经过一层脱敏和摘要把“用户原话”转成“用户痛点分类”。这样既保留了协作需要的信息又不让敏感的原始数据越界。我记得第一版原型就翻过车后端Agent在上下文里看到了某位用户的姓名和联系方式然后自作主张给对方发了一封问卷回复邮件。虽然最后撤回了但这足以说明上下文隔离不做好的话系统和“裸奔”没什么区别。4.4 上下文压缩与记忆策略多Agent协同还有一个很实际的痛点每个Agent都要带一段历史上下文进入下一轮推理轮次一多Token消耗大得惊人。我的实测里一个简单的两方协作任务光是互相追问三五轮上下文就能把模型的可用窗口撑到极限。后来我采用了两条策略。第一阶段压缩每完成一个阶段就把原始对话交给一个专门的“摘要Agent”转成结构化要点后续Agent只读摘要不读全文。第二目标锚定每次进入新阶段时系统会重新给代理注入“当前状态摘要 本阶段目标 关键约束”而不是把所有历史重放一遍。这既节省Token还能减少上下文漂移让代理不容易聊着聊着忘了最初的任务。5. 混合部署架构本地模型与云端模型如何协同5.1 为什么要把本地模型拉进来聊到部署架构一个绕不开的问题就是到底用云端模型还是本地模型。我的答案是两者都要而且要通过网关把它们统一管理起来。本地模型的优势第一是隐私。内部代码、未公开的产品方案、用户原始数据这些东西一旦发到外部API就有泄露风险在不少企业里甚至直接违规。第二是成本和延迟。对于高频的简单任务比如意图分类、实体抽取、格式转换本地小模型几十毫秒就能返回成本几乎为零。第三是可用性。局域网断网时云端模型全部瘫痪本地模型至少能维持核心流程运转。云端大模型的优势也很明显复杂推理、创意生成、长文本理解还是得靠它。所以问题的关键不是“选哪个”而是“让哪个模型干哪件事”。5.2 一个可用的拓扑代理运行时 模型路由网关 执行环境我在第二版原型里用的拓扑可以简化为三条路径用户 - 代理运行时 - 模型路由网关 - 本地模型或云端API代理运行时负责的是Agent的“身体”部分记忆管理、工具调用、消息收发。像OpenClaw这类代理框架适合做这一层它能把“Agent该有的能力”和“具体模型”解耦开来。模型路由网关是决策中枢它不生成内容只决定“这条消息该交给哪个模型”。所有Agent交互消息统一走事件队列避免高频调用把服务打挂。外部执行环境比如机器人仿真里的ROS是通过工具插件接入代理运行时的。我的建议是凡是实时控制类的工具调用路径上尽量不要绕到云端再回来。本地代理负责生成高层指令ROS节点负责实际执行执行结果再回传给代理做下一轮判断。这样延迟可控也不会因为网络抖动让机械臂动一下卡一下。5.3 模型路由策略什么任务交给谁模型路由看起来是技术判断本质是成本和质量之间的权衡。我日常使用的路由规则大致如下任务类型推荐模型原因意图分类、实体抽取、格式转换本地小模型快、便宜、准确率高代码审查、文档摘要本地中型模型或云端大模型依赖代码库上下文本地更安全复杂推理、方案设计、多轮谈判云端大模型需要强推理能力敏感数据处理本地模型数据不出内网但静态规则不够我加了一层动态评估当本地模型的置信度低于阈值网关会把问题升级到云端模型再判断一次。这个“置信度兜底”机制让整体准确率提升了不少。路由决策本身也要可观测每次路由都要记录“为什么选了这个模型”否则后期你根本不知道一次糟糕的输出是哪个环境产生了。5.4 当多个模型协同出现“翻译损耗”混合部署还有一个非常隐蔽的问题本地模型和云端模型的表达能力不一致。本地小模型生成的结构化数据很规矩但缺乏“想象力”云端大模型能力全面但有时候会在工具调用参数里加一些稀奇古怪的字段。我的处理方式是关键节点不让模型直接输出“自然语言”而是强制输出JSON Schema规定的结构。网关层再做一层校验发现解析失败就自动重试一次仍然失败则换模型。不要小看这一步多人多AI系统里一个模型输出格式不稳定可能导致下游所有代理连锁报错。6. 可观测性多代理系统的“黑盒”排错手段6.1 最难的从来不是写功能而是复现问题单Agent出问题你可以拿同样的输入跑一遍看输出就完了。多Agent系统里同样的输入在不同时间跑结果大概率不一样模型参数有随机性上下文内容在变工具调用的返回也在变。一旦出了问题你连“这个Bug怎么复现”都答不上来。所以我的原则是第一版就要埋可观测性不要等出事了再补。具体说就是给每一次协同过程生成一条完整的链路trace记录每个Agent看到了什么、做了什么、调用了什么、输出了什么。有了这条链排查问题才不是大海捞针。6.2 一个轻量级的协同链路追踪方案我在系统里对每个Agent的处理步骤记录一份span日志字段包括字段示例用途trace_idtrace_7c1d5e3f关联整条协同链路agent_idagent_backend_lisi定位处理者input_summary接口变更提议v3输入要点model_nameqwen2.5-72b实际调用模型prompt_tokens12034成本观察completion_tokens856成本观察tool_callsgitlab.get_mr_changes工具调用清单output_summary结论需要改3处输出要点statusok或error结果状态所有span按trace_id汇总到日志中心通过一次查询就能还原“市场Agent - 协调器 - 后端Agent - 工具服务”的完整调用链。有一次系统卡了半小时我打开trace一看发现是市场Agent和后端Agent陷入了循环追问各执行了二十多轮直接把队列堵死了。没有trace这个问题打死也猜不到。6.3 常见故障模式与处理多Agent系统的故障和单体系统完全不一样。我遇到的典型故障模式有这几种循环对话A问BB问A谁都不给结论一直转圈。解决方法是设置最大轮次并加环检测发现同一对Agent在重复相同话题就强制中断。幻觉串联A在推理时产生一个错误结论B把这个结论当成事实继续推理错误像滚雪球一样放大。解决方法是强制要求每个代理在关键结论里附带references下游代理必须检查引用是否存在。上下文漂移代理聊着聊着偏离了最初的任务目标。解决方法是阶段启动时重新注入“当前状态摘要 本阶段目标”让代理回到主线。重复执行代理因为网络超时重试结果重复执行了工具调用。解决方法是每个指令带幂等键工具侧按幂等键去重。这几种故障里幻觉串联最隐蔽因为它不报错每个代理都觉得自己是对的每个人类用户看到结果也可能觉得“好像有点问题但说不出哪里不对”。所以我在系统里加了一道硬规矩代理在把结论发给其他代理之前必须先在结论中列出它依赖的关键假设。这等于逼着模型在传播信息之前先做一次自我检查。6.4 让代理给出置信度与来源讲到这再分享一个实用习惯在关键决策点我会在消息协议里加入confidence字段要求代理输出一个0到1的置信度。同时强制要求references引用原始文档、查询记录或对话消息。置信度不是用来做投票权重的我从不按置信度简单加权。它是用来做“人工注意力路由”的置信度低的消息在人工界面上高亮展示提醒用户重点复核。这样人不需要看全部消息只需要盯住那些代理自己都没把握的部分效率会高很多。7. 落地路线与我的实测体会7.1 起点小先做两两协同再逐步扩展如果你也想搭一套多人多AI协同系统我最想给的劝告是不要从“全员互联”开始。先做最简单的三角关系用户 - 自己的Agent - 另一个用户的Agent。把代表权、消息协议、审计链路这三件事跑通再让协调器介入最后才是多个Agent自由组网。我第一版就是因为想得太美一上来就让四个Agent全面互联结果每天花大量时间在排查“为什么A突然不回复B”这类问题连核心流程都没跑完。第二版学乖了从一条最小链路开始稳定之后一个节点一个节点地加整个系统才真正可用了。7.2 控制并发与Token成本多人多Agent协同的真正经济账不是看模型API的单价而是看上下文膨胀和重试次数。我实测过一个场景单次任务的原始需求只有不到2000 Token但因为两个代理互相追问最后总Token消耗接近10000。这个倍数在多人场景里会被继续放大。控制手段有三个一是限制每个代理单轮可携带的上下文长度超出部分做摘要压缩二是所有指令带幂等键防止重试浪费三是代理并发调用统一走限流队列防止一瞬间把所有模型API额度打满。7.3 人必须在回路里不管是技术上的乐观还是对这个方向的期待都改变不了一个事实现在的AI代理还没到可以完全放手执行高风险动作的阶段。我的底线是所有面向外部世界产生实际影响的动作——发邮件、改代码提MR、下单、删除数据——必须经过真实用户确认。代理可以起草、建议、分析但最终拍板的人必须是人。这条原则要在一开始就固化到架构里而不是等出了问题再加。我在系统里把它实现为一个强制性的“人工审批节点”所有高危动作在执行前都要生成审批请求推送给对应的human_owner。宁可牺牲一些自动化率也要保住系统的可信度。7.4 一个让我系统变稳的小技巧最后分享一个实际操作中得来的技巧。我要求每个代理在把结论发给其他代理之前先做一步“自我质疑”列出这个结论依赖的假设如果假设不成立结论会不会改变这一步看起来很简单但它能拦住大量幻觉串联。比如市场Agent本来要说“用户强烈建议改接口”自我质疑后可能就会补一句“样本量只有20份结论置信度不高”后端Agent就不会把这句话当铁律去执行了。相当于在每个代理前面加了一道低成本校验闸门。这套多人多AI协同架构我迭代了两版走过不少弯路但方向上是走得通的。如果你也在搭类似的东西建议从最小三角关系开始先把身份、消息、审计三件事钉死再谈智能、路由和协同。架构的骨架稳了模型升级只是换发动机骨架是歪的换多少模型都救不回来。