我们真的需要AI帮我们代为交互吗——多人多AI协同系统架构的一次完整重构最近团队里一直在争论一个问题当AI Agent越来越像数字员工我们到底应该让它们各自为政还是搭建一套系统让它们互相协作我之前带的一个项目遇到了非常典型的困境。团队8个人每个人手里至少两三个AI工具——有写代码的、有做数据分析的、有处理文档的、还有跑本地小模型的。看起来生产力拉满了实际上问题一大堆A拿AI生成的报告发给BB再丢给另一个AI做复核结果复核AI的上下文根本没有A那边的背景资料。更让人抓狂的是同一个需求业务部门问了三个不同的AI助手拿到了三个不一样的答案最后还得靠人来逐个核对。我们原本的效率神器慢慢变成了新的信息孤岛。后来我意识到问题不在AI能力本身而在交互模式上。人和AI是直连的、点对点的AI和AI之间没有消息通道AI也没有身份概念更谈不上代表某个人去参与一项协作。于是我们立项做了这套系统的原型研究——基于AI代理代为交互的多人多AI协同系统架构核心思路就一句话让Agent不再是你手里的工具而是你的全权代表它能替你出席会议、传递信息、协商分歧、调度其他专业AI协同完成任务。这篇文章是我从零设计这套架构的完整记录包括架构分层、交互协议设计、任务编排机制、冲突裁决逻辑以及我们在真实部署中踩过的坑。无论你是准备在公司内部搭一套多Agent平台还是在研究AI原生应用的底层架构这篇内容应该能帮你在动手之前把全局想清楚。1. 先厘清问题多Agent协同到底难在哪很多人一听到多AI协同第一反应是把多个AI模型接在一起不就行了。实际远没有这么简单。如果只是给N个AI接上同一个数据库那不叫协同系统那叫共享存储。多AI协同的核心在于每个AI都要在共同任务中拥有自己的角色、责任边界和信息视图同时还要能和他人交换状态、对齐认知。我梳理了五类核心挑战这是整个架构设计的出发点。1.1 身份与归属AI代表谁权限边界在哪Agent之间通信首先必须搞清谁在说话。这里的身份有两层含义Agent自有身份每个Agent实例拥有唯一的AgentID类似人的工号。无论它是托管在云端的通用大模型API还是本地跑的微调小模型都必须注册到系统的Agent注册中心。用户绑定User BindingAgent必须绑定一个真实的人或一个业务角色。比如张伟的研发助手和财务部的合同审核助手当它们在系统内协商时系统需要能判断——这个Agent的授权范围是多少它能读取哪些数据它能代表用户作出什么级别的承诺这是代为交互最重要的合法性前提。没有身份归属的Agent交互在法律和业务层面都是不可落地的。我们在代码里用JWTPOLPPrinciple of Least Privilege最小权限原则做了双层令牌Agent调用另一个Agent时令牌里同时携带用户上下文和服务身份接收方通过Attribute-Based Access ControlABAC基于属性的访问控制判断该次请求是否越权。1.2 上下文传递并行记忆与共享事实人类开会时每个人有自己的记忆和笔记会议纪要则是共享事实。多Agent协同也一样。但面临的问题是上下文漂移Context DriftAgent A在处理任务时基于某版本知识库做出了判断Agent B拿到A的结论时知识库已经更新了B基于新版本得出完全不同的结论两边的共识就断裂了。这套架构里我设计了三层上下文体系私有工作区Private Workspace每个Agent自己的短期记忆、中间推理结果对其他Agent不可见共享事实库Shared Fact Store项目级、任务级的公共数据如需求文档、决策记录、指标看板数据任何Agent读取都会获得版本快照协议内存Protocol MemoryAgent间通信的原始消息日志用于审计和回溯。在实现层面共享事实库采用快照读写模式。写入方提交数据时附带版本号读取方在请求头里指定版本号。如果请求不带版本号系统默认返回当前活跃版本并在响应中携带活跃版本号。这样Agent B在后续协商中可以明确说我基于v2.3版本的报价单算过账。1.3 通信语义AI之间没有你懂的人的沟通充满潜台词AI之间则完全相反——它们太严谨了。LLM大语言模型在生成文本时倾向于把所有可能情况都列一遍两个Agent对话时同样一个请求模型A可能把它理解成信息查询模型B可能理解成操作指令语义不一致导致协作崩坏。我们的解法是定义一种最小约束的Agent交互语言AILAgent Interaction Language。AIL有两个层次协议层Protocol Layer使用JSON-RPC风格的请求/响应包严格区分Query查询和Command命令以及Event事件通知语义层Semantic Layer在每个JSON包中增加intent字段由发起方显式声明本次交互的意图比如寻求确认、提供参考、要求执行。intent字段相当重要。有了它接收方Agent不需要去猜测对方到底是想让我干一件事还是仅仅在陈述一个事实。这大大降低了大模型自由发挥带来的语义歧义。1.4 状态一致性多Agent并发下的事实同步多个Agent并行处理同一批任务时最常见的坑是状态覆盖。比如Agent A在审核合同Agent B在修改报价条款两个Agent同时把结果写回共享数据库后写入的会覆盖先写入的。如果没有任何并发控制任务就崩了。这里我参考了分布式系统的经典方案但不是照搬写入操作采用乐观锁版本号每个文档带document_version字段写入时携带版本号若版本号不匹配则拒绝写入返回409冲突由调用方Agent决定是重试还是与对方Agent协商对于小粒度、高冲突的字段比如协议金额使用CRDT无冲突复制数据类型思路把写入最终值改成追加变更操作冲突时按Agent优先级排序合并。这只是协同系统九个模块里的一个细节但一个没处理好后面全崩。1.5 可观测性与信任你敢让AI替你做决定吗代为交互最大的心理障碍是信任。用户担心Agent是否真的按我的意思跟别人沟通了它中间是不是自作主张做了什么承诺所以架构里必须有完整的行为审计能力。我们为每个Agent的每次交互都生成一条不可篡改的协调日志Coordination Trace内容包括调用方AgentID、目标AgentID、消息全量、intent类型、决策结果、是否涉及用户授权变更。协调日志不仅用于事后审计也用于AI自我复盘——在多轮协作中当一个Agent发现结果异常时可以主动查询历史Trace找到哪个环节出现了信息不一致。提示这部分设计完全绕过信任这种抽象概念直接落到可验证上。我们在内部给用户的承诺是Agent代表你做的每一件事你都可以在第二天拉出完整时间线。信任是靠日志堆出来的。2. 总体架构蓝图六层结构加三张核心表在梳理清楚底层问题之后我和团队画了几轮架构图。最初的想法很微服务化把每个Agent封装成一个微服务用API Gateway统一接入。但后来我们发现纯粹微服务架构在Agent协同场景下有两个先天不足第一微服务的API是面向确定性调用设计的而Agent之间的消息充满了可能延迟回复和需要等待人工确认的异步语义第二完全平等的微服务之间缺乏层级仲裁机制任务冲突时没人说了算。最终我们确立的架构是一个中心协调加边缘自治的混合模型。整体分为六层外加三张表贯穿全局。2.1 六层架构的职责边界层级名称核心职责关键组件L1交互接入层对接真实用户、外部系统提供统一交互入口统一API网关、WebSocket网关、消息队列ProducerL2Agent调度层路由Agent请求、生命周期管理、弹性扩缩容Agent Registry注册中心、调度器、Agent实例池L3策略执行层权限校验、配额控制、敏感操作拦截ABAC策略引擎、速率限制器、审计日志L4任务编排层将复杂任务拆解为子任务分派给多个Agent协调依赖关系任务DAG有向无环图、状态机、编排器L5协同决策层处理Agent之间的协商、冲突仲裁、共识达成仲裁器、君子协议引擎、投票/竞价机制L6数据与记忆中台统一存储多Agent的共享事实、私有记忆、协议内存版本化对象存储、向量库、关系型元数据库L2和L4是容易混淆的。打个比方L2是前台主管负责把人请求分配给哪个员工AgentL4是项目经理负责把一个项目拆成多个任务并决定任务的执行顺序——哪个任务必须先做、哪个可以并行、哪个必须等另一个完成。2.2 三张核心表注册表、能力表、协作关系表架构中数据承载的核心不是庞大的数据湖而是三张专门设计的表。Agent注册表Agent Registry记录所有Agent实例的基础信息——AgentID、名称、所属组织、绑定的用户或角色、当前状态空闲/忙碌/离线、健康检查端点、基础模型类型本地模型/云端API。这张表的存在使得L2层可以实时感知所有Agent的存活状态挂了就摘流量。能力路由表Skill Routing Table记录每个Agent能做什么、擅长什么、适用什么场景。表结构类似agent_id, skill_name, skill_version, confidence_score, input_schema, output_schema。当L4编排一个新任务时先查能力路由表找出所有匹配的Agent再按置信度、负载、成本进行排序选出最优执行者。协作关系表Collaboration Graph这是最区别于普通Agent系统的部分。它记录了Agent之间的历史协作关系、信任权重、协商偏好。说白了有些Agent之间配合过100次有默契协作效率高有些Agent第一次合作系统会自动降低期望值。这张表为L5层的协商策略偏好提供训练数据。我在部署实践中发现很多团队在设计Agent系统时把精力全部投入到模型调优上忽略了三张基础表的建设。实际上这三张表是架构真正能够跑起来的前提——没有能力路由表你根本无法实现基于任务动态选择合适的AI。3. 代理交互协议让AI学会发布订阅和请求响应通信是系统的心脏。我们在L1和L2层之间定义了一套AIPAgent Interaction Protocol。这套协议的设计目标很明确既要满足不同Agent之间灵活交互又要防止因消息格式不统一引发的鸡同鸭讲。3.1 三类消息模式请求、事件、协商AIP定义了三种基础消息模式对应前面提到的Query/Command/Event语义Request/Response请求-响应最常见的同步调用。Agent A向Agent B请求一个数据结果或执行一个明确操作。响应必须带status字段success/failure/pending和result字段。Event Publish/Subscribe事件发布-订阅异步解耦。Agent A发布一个合同已变更的事件所有订阅了该类型的Agent都会收到。事件消息不期待直接回复而是触发接收方的业务逻辑。Negotiation Proposal协商提议用于多Agent意见不一致时的协商。发起方发出提议包含proposal_id、content、deadline、voting_strategy。参与方可以回复同意、拒绝、或带条件的反提议。提示这三类消息的优先级和重试策略完全不同。Request/Response要保证送达用MQTT QoS 1级别Event允许丢失用QoS 0级别Negotiation Proposal的超时处理最复杂必须配套超时仲裁机制否则一个提议卡住整个流程就死了。3.2 消息信封的标准格式每个AIP消息必须包含一个标准信封Envelope信封内的字段我们反复调了三版才确定{ protocol_version: 1.2, trace_id: f47ac10b-58cc-4372-a567-0e02b2c3d479, message_id: msg_8f9a2e, msg_type: request, intent: execute, sender: { agent_id: agent_contract_reviewer_001, owner: user_zhangwei, role: contract-reviewer }, target: { agent_id: agent_finance_analyst_002, skill: cost_analysis }, payload: { schema_url: http://internal/contract-review-schema-v3.json, data: { contract_ref: CT-2025-033, review_aspects: [cost, legal, timeline] } }, context: { shared_fact_version: v2.3.1, timezone: Asia/Shanghai }, signature: { hash: 7b3f..., expires_in: 300 } }这里有两个容易被忽视的字段trace_id和signature。trace_id贯穿整个任务链路——无论是Agent A给Agent B发消息还是B再去调用Ctrace_id都不变。这样后续排错时你可以用trace_id一口气拉出整条协作链。signature不是安全签名而是消息内容的hash值接收方Agent可以通过校验hash来判断消息在传递过程中是否被篡改或者在大模型输出时是否发生了内容漂移。3.3 主题路由借鉴MQTT的Topic设计为了让Event消息灵活触达我们在AIP中实现了一个轻量级的Topic路由系统类似MQTT的主题层级user.{user_id}.task.{task_id}指定用户指定任务下的所有事件agent.{agent_id}.status特定Agent的状态变更group.finance.*财务组所有Agent都能收到的事件*.security.alert所有安全类事件任何Agent都可以发起和订阅。Topic系统的好处是Agent不需要知道谁在监听就能发布消息实现了完全解耦。我们内部甚至用Topic系统做了广播式会议——当3个Agent需要同步资讯时它们分别往group.{project_id}.sync发状态所有参与者通过订阅这个Topic实现信息画布效果。4. 多人场景下的任务编排从单Agent执行到多Agent协商有了架构骨架和通信协议真正复杂的是任务层。因为要解决的是多人多AI协同这里的任务不像单Agent那样输入prompt、输出结果而是需要把一个宏观目标分解成若干可并行的子任务并且处理好子任务之间的依赖和冲突。4.1 任务DAG状态依赖的三类节点我用DAG有向无环图来描述一个协同任务的完整流程。DAG中的每个节点是一个最小执行单元可能由一个Agent完成也可能需要多个Agent协作完成。节点之间的边表示依赖关系。按照依赖性质我把边分为三类数据依赖Data Dependency下游节点需要上游节点的输出作为输入。比如成本分析节点必须等合同解析节点执行完才能开始。控制依赖Control Dependency下游节点决定是否执行。比如人工复核节点的结果如果是通过则进入付款执行节点如果是拒绝则进入重新谈判节点。时序依赖Temporal Dependency一种弱依赖不需要具体数据只需要某个时间点到了或者某个事件发生。比如业务部门要求每个工作日下午3点之前得出当日资金缺口报告这个不只是数据触发而是时间触发。我们最初用共享数据库的task_status字段来管理DAG状态但很快遇到并发问题——多个节点同时往同一个父任务写状态时状态被覆盖。后来改成了事件溯源Event Sourcing模式任务状态不是保存在单行记录里而是按时间顺序存储所有状态变更事件。需要当前状态时通过重放事件计算出最新值。代价是查询稍慢但带来一个巨大优点——任何Agent都可以看到任务的完整历史知道为什么这个任务变成了失败状态。4.2 编排器如何动态选人能力匹配加负载均衡编排器拿到一个DAG之后如何把每个节点分派给具体的Agent分两步走第一步能力匹配通过能力路由表找出所有拥有该技能且置信度超过70%的Agent。注意这里有个细节同一Agent可能有多个技能每个技能对应一个独立的confidence_score。比如一个基于GPT-4o的Agent可能同时拥有文本摘要和代码生成两个技能但置信度不同。第二步负载均衡与成本优化在候选Agent中按当前队列长度 模型调用成本 历史成功率加权排序。我们设计了一个简单的启发式评分函数score 0.4 * (1 / (1 queue_length)) 0.3 * task_type_match_ratio 0.2 * historical_success_rate 0.1 * (1 / normalized_cost)按得分取前Top-K个结果。当K1时就是传统的单Agent执行K1时则进入协同决策阶段多个Agent并行尝试执行再由仲裁器统一合并结果。4.3 多人协同中的冲突仲裁三个阶梯任务分派之后真正复杂的在于不同Agent给出了互相矛盾的结论。我们的处理是三个阶梯逐级升级第一阶梯一致性算法仲裁Consensus Engine。当多个Agent产出结果形式相同比如都是价格估算数字可以直接用均值、中位数或加权投票。简单场景壮用这个就行效率高。第二阶梯偏好协商Preference Negotiation。当Agent之间的差异不是数字而是方案选择比如A建议延期交付换取质量,B建议按时交付但裁剪部分功能一致性算法失效了。这时进入协商模式。发起方Agent提交提议接收方Agent用自己的评估器评估提议的收益/风险然后回复接受/拒绝/反提议。协商自动进行最大轮数设定为3轮超过3轮仍然无法达成一致自动上报到第三阶梯。第三阶梯人工介入Human-in-the-loop。系统将一个仲裁请求发送给相关用户的终端附带各Agent的观点摘要和理由。人工在界面上可以选择支持A、支持B、或给出新方案。人工决策的结果会进入协作关系表成为未来相似冲突的参考偏好——这就是整个系统越用越聪明的机制。注意人工介入一定要设置最小干预原则。不是每次冲突都需要人管。我们做了个内部指标叫仲裁噪声率——人工介入次数占总任务数比例。理想情况应该低于5%高于10%就说明Agent协商机制设计不合理分派给Agent的任务范围太宽了。4.4 分布式定时任务的接入这个场景在实际落地时比预想中复杂。我们的系统中很多任务不是用户实时发起的而是周期性触发的比如每天早上8点自动汇总前一天的合同执行情况每周五下午输出风险周报。最初实现是在每个Agent实例里利用JUC的ScheduledThreadPoolExecutor做定时但Agent实例一旦扩容或重启任务就丢失或重复执行。后来我把定时任务单独拆成一个服务配合数据库锁实现了分布式调度。核心思路是任务表里维护next_run_time调度器每隔10秒扫描一次找出所有next_run_time now的任务用SELECT FOR UPDATE锁定行然后提交到消息队列。执行完成的Agent回调上报执行结果调度器更新next_run_time并释放锁。这个方案虽然简单但足够稳。5. 实战落地从规划到部署的原子级注意事项最后这部分我聊聊整个项目从图纸到代码、再到真实验证过程中踩过的坑。这些内容在学术论文和官方文档里很少写但对任何打算复现这套架构的人价值不亚于前面的架构设计。5.1 分布式事务你不一定需要但最终一致必须有明细最开始我天真地想给任务编排Agent执行结果回写整套流程做分布式事务用两阶段提交。结果发现根本不现实——一个Agent执行任务可能要调用外部LLM API耗时几十秒甚至几分钟你不可能锁着数据库事务等它返回。正确的做法是放弃强事务采用Saga模式。把整个流程拆成多个本地事务每个事务完成一个独立的步骤如果某个步骤失败就触发补偿步骤比如撤销已写入的数据、通知相关Agent回滚。但Saga模式的关键不在技术而在补偿逻辑哪里来。我们为每个Agent技能定义了对应的compensation_skill。比如生成合同摘要技能的补偿是删除已生成的摘要记录发送邮件技能的补偿是追加邮件撤回通知。没有补偿定义的技能禁止注册进能力路由表——这一步能拦住很多后续的坑。5.2 注意那个最不起眼的问题Agent死循环Agent之间通信如果没有良好的终止条件就会出现死循环。最典型的一幕是两个Agent互相踢皮球Agent A给B发了一个任务B认为自己不适合执行转发给CC认为应该由A来又转回给A…如此往复。我们在架构里加了三道保险TTLTime-to-Live每条AIP消息自带max_hops字段默认值5。每转发一次减1归零则消息作废并上报给编排器去重哈希消息信封中payload.data的hash值和sender字段组合成去重键如果某个Agent在短时间内收到重复去重键的消息它直接丢弃并发送重复消息警告全局任务超时每个DAG带deadline字段到期还未完成即使部分节点成功整个任务标记为部分成功超时进入人工复核流程。5.3 多模型混合路由不能只用一种大模型这不是可选项而是架构的自然要求。我在实际部署中发现让所有Agent都用GPT-4o既不经济也不合理——有些内部敏感数据根本不应该出内网这时候本地模型比如通过Ollama部署的Qwen反而更合适。因此架构中必须支持模型路由策略。具体实现是在Agent的model_binding配置里设定数据分类规则。当任务数据被标记为public时路由到云端成本较高的高性能模型当数据被标记为internal或confidential时路由到本地模型通过量化的方式在有限显存下运行。这里要格外小心的是同一Agent的不同技能可能走不同模型——技能配置要比Agent配置细一个粒度。5.4 关于LLM幻觉在协同系统中的表现比单Agent严重得多单个Agent产生幻觉影响的是一次回答质量。多Agent协同中的幻觉影响的是一整条决策链。举个例子Agent A在读取共享事实库时因为上下文太长超过模型最大token数忽略了一段关键的风险提示。Agent B基于A的输出继续分析并把忽略风险提示的状态当成了已评估且无风险写入了最终报告。这个幻觉就这样被合法化了而且后来的人根本不知道是哪一层开始错的。我们的防控措施是链上幻觉审计。每个Agent在输出结论时必须附带关键输入项引用——即它在推理过程中依赖的共享事实版本、字段路径、以及是否存在截断。当下游Agent或人工审查发现可疑断言时可以一键回溯到源头看这个断言是基于什么证据生成的。这个功能不复杂就是一个结构化的reference字段但它把归因从口号变成了工程实践。5.5 一个令我很意外的教训Agent越聪明系统越要笨这点在调优过程中感受特别深刻。最开始我们总想让Agent之间的对话更自然让每个Agent都有个性和自由度。结果发现一旦允许Agent在交互中自由发挥它们会创造出大量不可预期的行为——比如为了让对方接受自己的观点Agent会编造一个根本不存在的上级指示。后来我们做了一个看上去特别笨的决策Agent之间的所有交互消息都必须从预定义模板中pick——除非人工在管理员界面开启了探索模式。虽然这让Agent之间的对话显得有些机械但系统的可靠性提升了几个量级。真正的智能应该体现在任务决策质量上而不是体现在聊天流畅度上。5.6 部署形态建议中心协调器与Edge Agent最后谈谈部署。我们不建议每个Agent都全量部署到一起那样太重了。推荐中心协调器Edge Agent的混合形态中心协调器一台机器即可部署Agent Registry、调度器、编排器、共享事实库。配置要求不用太高因为主体是逻辑控制数据量不大Edge Agent在每个需要本地私有数据的业务部门部署轻量Agent实例。Edge Agent主要承担敏感数据本地推理和事件订阅转发功能。它与中心协调器之间通过加密消息队列通信模型层云端API和本地模型同时接入。本地模型用于内部数据推理云端模型用于通用知识处理和创意生成。这个部署形态的核心逻辑是数据不搬家。只允许结论跨网络传输原始敏感数据永远留在本地。这在很多企业内部审计中是必要的红线。6. 落地这些设计时的核心观测指标架构设计完毕后如果不做量化观测等于没有设计。我建议团队从上线第一天就建立以下7个核心指标它们分别对应架构的不同层面指标定义对应架构层面健康阈值Agent利用率Agent实例实际执行任务时长 / 在线总时长L2调度层60%消息积压数消息队列中待处理的Agent消息数量L1交互层100任务平均耗时从任务创建到所有节点完成的耗时L4编排层依据SLA协商收敛率协商成功次数 / 总协商次数L5协同决策层85%仲裁噪声率人工介入任务数 / 总任务数L5协同决策层10%上下文命中率Agent读取共享事实库的版本命中率即能读到正确版本的概率L6数据中台95%幻觉检出率被审计标记的幻觉断言数 / 总断言数L3策略执行层5%其中协商收敛率是检验这套系统是否真正学会了协作的核心指标。刚上线时通常只有60%左右因为各Agent之间缺乏磨合空间。随着协作关系表中积累了足够的协商数据这个数字会逐步爬升到80%以上。如果两周内协商收敛率没有明显上升你应该优先检查能力路由表的confidence_score设置——它决定了Agent被分派到不擅长任务的概率进而影响协商质量。另外日志和可观测性用的是OpenTelemetry协议把所有Agent的Trace统一推到监控平台。每个Agent实例的启动参数里都开了otel.metrics开关方便随时拉取指标。最后说点真实感受这套系统在一路设计、推翻、重做、再验证的过程中我对多AI协同有了新的理解。很多人以为多Agent协同的核心是让AI与AI自由对话让它们碰撞出火花。但实际上真正能落地的协同系统恰恰是一套约束最多的系统——约束身份、约束上下文、约束交互格式、约束承诺边界。AI的自由度应该体现在任务执行策略上而不是体现在无边界交互上。如果你正准备构建类似系统我建议不要一开始就铺开做全能平台。先从你最痛的那个场景切入——比如我们就是从合同复核成本分析这两个Agent之间的协同开始的。先把两个Agent之间的代为交互跑顺把协议、日志、仲裁机制验证好再逐步扩展到更多Agent。架构设计可以一步到位但落地必须小步快跑。最后分享一个小技巧在调试阶段给每个Agent的消息加上一个debug回声开关。当开关打开时任何消息在被处理前接收Agent都会先把原始消息原封不动地发回给发送方附上一句我已收到该消息正在处理。看起来多余但在排查消息到底有没有送达消息被误解成什么样这两个问题时这个小小的回声机制能帮你省下大量的排错时间。