AI代理把我们从“手动调接口”变成了“下目标、等结果”，但当一个系统里同时出现十几个AI代理、十几个真实用户，代理之间还要代替各自的主人互相沟通、协商、完成任务流转，事情就完全不是调一个模型那么简单了。我最近一直在推敲的，就是“基于AI代理代为交互的多人多AI协同系统架构”这个方向，说直白点：让AI代理替人发言、替人协调、替人盯进度，同时还得保证它不会替人乱承诺。这篇内容我会把架构分层、代理间通信协议、权限边界、状态一致性、异构模型接入和部署形态拆开讲，也会把落地时踩过的坑一并交代清楚，适合正在做多智能体平台、智能体工作流，或者想给团队搭建AI协同底座的架构师和开发者。
1. 为什么“代为交互”是这套系统的地基
1.1 从“AI助手”到“AI代理”的关键转变
传统的AI助手本质上是一个问答工具：用户提问，模型回答，用户再决定下一步。AI代理则进了一步，它有目标、能拆解任务、会调用工具，甚至可以自主执行一个多步骤流程。而“代为交互”比这更往前迈了一大步——代理不是只和用户一个人对话，它可以代表用户在系统内部和其他代理打交道。
打个比方：以前的AI助手像一个计算器，你按数字它给你结果；AI代理像一个助理，你交代一件事它去跑腿；而“代为交互”的AI代理，像是助理拿着你的授权去和其他助理开会，会上可以讨论、妥协、交换资源、同步信息。这个“代表你去交互”的能力，是把多AI系统从“工具集合”变成“协作网络”的分水岭。
但这里也埋下了整个系统最核心的麻烦：一旦代理可以代表用户去交互，系统就必须有能力回答“这个交互行为是否在授权范围内”“代理说的话能否代表用户真实意图”“两个代理达成的协议是否真的有效”。
1.2 多人多AI的复杂度根源是关系网络，不是数量
一个用户配一个AI代理，技术难度并不高，市面上大多数个人助理产品都能做到。但当用户数量变成N、代理数量变成M，这个系统里的潜在交互关系就不再是N+M，而是N×M级别的组合。
我见过不少团队一开始的误区：以为只要把多个AI代理挂到同一个消息队列上，就算“多AI协同”了。结果一跑起来就发现，用户A的代理需要用户B的代理提供数据，用户B的代理又要等用户C审批，而用户C的代理半天没响应，因为它在等用户A的代理确认一个会议时间——整个任务链就死锁了。
多人多AI场景的复杂度来源主要有三个维度：
- 任务依赖：一个任务被拆成多个子任务，由不同代理执行，子任务之间存在先后关系和数据依赖。
- 信息归属：有些信息是公开的（比如项目里程碑），有些信息是某个用户私有的（比如个人日程偏好），代理之间交换信息必须知道信息能流到哪里。
- 决策权重：代理之间意见不一致时，谁说了算？是发起任务的用户，还是领域更专业的那个代理？还是必须升级到人？
如果不从架构层面解决这三个问题，代理再多也只是各自为政的孤岛。
1.3 一个贯穿全文的最小场景：跨职能任务协作
为了让后面的架构分析不悬空，我先定义一个最小场景，后面所有技术讨论都围绕它展开。
假设一个产品团队有三个人：产品经理（User A）、UI设计师（User B）、后端工程师（User C）。每个人都有一个AI代理（Agent A、Agent B、Agent C）。现在产品经理想让团队评审一个新的需求文档，并且希望设计师先输出两版视觉方案，工程师再评估技术可行性。
如果只是传统工具，产品经理要分别找设计师和工程师沟通，来回复制粘贴信息。但在“代为交互”的系统里，Agent A可以直接向Agent B发起一个“设计协作”请求，Agent B检查日程后开始出方案；同时Agent A把需求文档的关键段落同步给Agent C，Agent C可以先行预评估技术风险。整个过程里，三个代理在通信层自行协商，用户只需要在关键节点确认。
这个场景看起来简单，但后面的分层架构、通信协议、权限模型、状态一致性，全都是为了让这样一件事能够在“多个代理同时在场”的情况下安全、可靠、不发生信息错乱地跑起来。
2. 架构分层：接入、编排、协作、基础这四层怎么切
2.1 四层架构总览
我最终落地的方案，是把系统切成四层，每一层职责单一，互不越界。这个划分不是拍脑袋定的，而是踩了几次“大泥球”之后被迫形成的。
| 层次 | 核心职责 | 典型组件 | 最容易踩的坑 |
|---|---|---|---|
| 接入层 | 屏蔽异构模型和异构入口 | 模型适配器、用户渠道适配器、统一API网关 | 把模型私有能力直接上透给上层 |
| 编排层 | 管理任务生命周期与代理路由 | 任务状态机、会话管理器、路由策略引擎 | 把任务状态直接存进代理本地内存 |
| 协作层 | 处理代理间消息路由与协商 | 消息总线、共享黑板、冲突调解器 | 让代理直接操作共享数据库 |
| 基础层 | 提供持久化、可观测性、审计 | 事件日志、链路追踪、指标监控 | 上线后才发现没法排查问题 |
这个分层最重要的原则是：上层不依赖下层实现细节。接入层后面换一个模型厂商的产品，编排层不应该感知到任何变化；协作层加了新的通信模式，基础层的审计日志格式不需要改动。
2.2 接入层：异构模型与异构入口的统一适配
真实场景里，一个系统不可能只用一家模型。最常见的情况是：复杂推理用云端大模型，隐私敏感或离线场景用本地模型，还有一些专业领域任务会路由到专门的微调模型。这个现象现在已经很普遍了，很多团队在实践“AI代理助手加本地模型”的组合，就是为了在成本和隐私之间找到平衡点。
接入层要做的，就是把所有模型封装成统一的接口。我的设计里，每个模型是一个适配器，对外暴露同样的方法：plan(task)、act(tool_call)、respond(message)。至于背后是OpenAI接口、开源模型服务，还是本地推理框架，对上层完全透明。
同样的逻辑也适用于用户入口。用户可能从Web页面发起任务，从IM机器人对话，从内部系统通过API调用来触发代理。每个入口都需要一个适配器，把不同格式的输入统一转换为系统内部的规范化事件。
2.3 编排层：从函数调用到任务状态机
代理系统一旦进入多人多智能体阶段，最忌讳的就是把任务处理写成“发起请求-等待回复”这种简单的函数调用链。因为代理可能会挂起、会等待其他代理的输入、会需要人工审批介入、会失败重试。这本质上是分布式系统的状态管理问题。
我采用的方案是为每个任务维护一个显式状态机，状态包括：PENDING（等待执行）、RUNNING（执行中）、WAITING_DEPENDENCY（等待依赖）、WAITING_APPROVAL（等待人工确认）、COMPLETED（完成）、FAILED（失败）、CANCELLED（取消）。任务在不同状态之间流转时，会向协作层发出状态变更事件，其他代理可以通过订阅事件来感知任务进展。
举例来说，前面提到的需求评审场景，Agent A发起的“设计协作”子任务会进入WAITING_DEPENDENCY状态，等待Agent B的先导任务“输出视觉方案”完成。如果Agent B返回的方案被Agent A判定为不合格，子任务可以重新回到RUNNING状态再次执行，而不会让整个任务链断裂。
2.4 协作层与基础层：消息总线和可观测性缺一不可
协作层承担的是代理之间的“通信基座”。我自己在项目里是把这层实现为一个轻量级分布式消息总线，所有代理间的消息都通过总线转发，而不是让代理之间直接网络直连。这样做的好处是：消息路由规则（谁能访问谁）、消息流量控制、消息审计都集中在协作层完成，不会散落到各个代理内部。
基础层则提供一个很朴素但很关键的能力：把所有事情都记录下来。每一次代理交互事件、每一条消息、每一个任务状态变更，都写入事件日志。时间久了你会意识到，在一套多人多AI系统里，可观测性不是事后补的运维功能，而是系统能不能持续迭代的前提。
3. 代理间通信协议：消息、上下文与工具调用的约定
3.1 消息信封：trace_id与delegation_chain
代理之间的消息不能像聊天机器人那样随便发，必须有结构化的信封。我在系统里定义的消息格式长这样：
{ "message_id": "msg_e2b1c9f0", "sender_id": "agent_a", "recipient_id": "agent_b", "trace_id": "trace_7f3a1d", "parent_message_id": "msg_x90k2m", "delegation_chain": ["user_a", "agent_a", "project_omega"], "intent": "request_design_task", "payload": { "task_id": "task_001", "requirement_ref": "doc/req_v3.md", "deadline": "2025-07-20T18:00:00Z" }, "quota": { "max_cost": 12.5, "max_wait_seconds": 300 } }这里面最关键的是delegation_chain字段。它记录了这次通信的事件来源链，从原始用户到当前代理，再到这个动作所归属的项目。任何代理在收到消息后，都必须先校验这条链路，确认对方有这个权限发起这个意图。
为什么要专门做这个字段？因为如果没有它，代理很容易出现“身份漂移”。比如Agent A说“我是代表User A来催进度的”，但系统无法验证它是否真的得到过User A的授权。有了delegation_chain，每一层转发都会带上原始委托信息，审计和权限校验就有了抓手。
3.2 共享上下文与记忆分级：防止信息污染
代理之间协同最微妙的问题之一就是上下文共享。每个代理都有自己的记忆和能力，但它们能共享给其他代理的信息必须有边界。我把记忆分成三级：
- 私有记忆：用户的个人偏好、未公开的草稿、个人日程。默认不共享给其他代理。
- 项目记忆：项目文档、任务状态、已确定的里程碑。允许项目内代理访问。
- 全局知识：模型自身的世界知识、组织公开知识库。所有代理都可访问，但必须标注来源。
实际执行的时候，我会在协作文档里加一个context_policy字段，明确声明哪些段落允许被其他代理读取，哪些段落只能由本人或用户查看。这个设计投入不大，但它能挡住一大批“代理把用户A的隐私信息当作协作素材发给用户B”的恶性事故。
这里有个我常用的判断标准：代理A需要向代理B传递的内容，只传“结论+引用位置”，不传原始全文。比如Agent A给Agent B发消息，说“需求文档第3.2节提到的支付流程需要评估”，而不是把整个文档粘贴过去。消息里附带的是requirement_ref，Agent B有需要再按引用去拉取。这样既降低上下文token开销，也避免无关信息扩散。
3.3 任务编排模式的对比与选择
代理之间的配合模式有三种主流选择，我分别跑过之后整理了一张对比表：
| 编排模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Orchestrator-Worker（中心调度） | 目标明确、子任务边界清晰的流程 | 控制力强、状态清晰、可审计 | 中心节点容易成为瓶颈和单点 |
| Blackboard（共享黑板） | 多代理共同解决一个开放问题 | 灵活、信息透明、适合头脑风暴 | 收敛慢、容易出现信息冗余 |
| Peer-to-Peer协商（点对点） | 代理间交互频繁且对等 | 低延迟、自然模拟真实协作 | 状态管理难，容易产生消息风暴 |
我在系统里的做法是混合使用：任务有明确流程时，优先用Orchestrator-Worker模式，由一个总控代理负责任务拆分与进度跟踪；当任务是开放式设计评审、方案探讨这类问题时，切换到Blackboard模式，让多个代理把各自意见写到共享空间，再由一个调解角色做收敛。
需要特别提醒的是，Blackboard模式虽然灵活，但扛不住代理一多就开始刷屏。必须给每个代理设定发言频率上限，并要求每条意见必须附带依据引用，否则其他代理会被大量无来源的信息淹没。
3.4 冲突协商：代理意见不一致时怎么办
多个代理处理同一件事，一定会有意见冲突。最常见的是两个代理同时修改同一个文件，或者对同一个技术方案的可行性判断相反。
我的处理策略分三级。第一级是版本控制，任何共享资源的修改都走CAS（Compare-And-Swap）语义，如果Agent B要修改的文档已经被Agent A更新过了，系统会拒绝Agent B的写操作，并通知它重新拉取最新版本。第二级是调解代理，当两个代理意见相持不下时，系统拉起一个中立调解代理，让双方各自陈述依据，调解代理给出建议结论。第三级是升级到人，调解失败后，系统把双方意见摘要和请求依据一并打包发送给相关人员，由人来拍板。
升级到人这件事在系统设计里必须显式建模，不能靠代理自己“觉得搞不定再找人”。我在任务状态机里专门设置了WAITING_APPROVAL状态，任何涉及外部承诺、资金消耗、发布动作的任务，在状态流转到最终执行前都强制卡在这个状态等待人确认。
4. 权限边界与状态一致性：多人多AI系统最容易翻车的地方
4.1 身份与委托链：代理凭什么代表用户
代理“代为交互”的核心约束是授权。市面上很多多代理Demo只是把多个模型串起来跑，根本没有考虑权限问题——但在真实业务里，这一步绕不过去。
我给每个代理发放的令牌（Token）会绑定一个委托链，形如user_a -> agent_a -> {可操作资源集}。代理只能在令牌允许的资源范围内执行工具调用。比如Agent A可以读取需求文档、可以创建设计任务，但不能直接删除发布记录，不能修改其他人的私有笔记。
关键的一点是，委托令牌不可转发。如果Agent A收到Agent B的消息，想请求Agent B帮它完成一个操作，Agent B不能拿着Agent A的令牌去执行，必须通过系统重新申请一次授权，或者把操作请求回传让人确认。这样能杜绝“代理A拿到权限后转包给代理C执行，绕过用户审批”的漏洞。
4.2 状态一致性：事件溯源加乐观并发控制
多人多AI场景下，多个代理对同一个任务的操作天然是并发的。如果每个代理各自维护一份任务状态，很快就会不一致。我采用的做法是事件溯源（Event Sourcing）：任务状态的每一次变化都作为一个不可变事件追加到事件日志里，当前状态永远通过对事件流做折叠计算得到。
这样做带来的直接好处是，任何代理执行动作前，系统都能从事件流重建出当前的真实状态，而不是信任某个代理的本地内存。配合乐观锁（在事件写入时带上版本号，版本冲突就拒绝写入），可以解决掉绝大多数并发覆盖问题。
举个具体的例子：Agent A和Agent B几乎同时把任务task_001的状态改成“已完成”。因为系统要求事件写入必须依赖当前状态版本，第二次写入会因为版本号不匹配而失败。那个失败的代理会收到冲突通知，重新拉取最新状态后再决定是否需要重新提交。这个机制很朴素，但比加分布式锁要轻量得多，也更适合多代理这种“大量短事务”的场景。
4.3 幻觉在多人协同中的放大效应
单个AI代理的幻觉，影响的只是当前用户；但在多代理协同系统里，一个代理产生的错误信息一旦被其他代理当作“事实”去引用，就会沿着消息链传播，可能一路影响任务决策。我见过最离谱的情况是，Agent A转发了一份“已确认的排期表”给Agent C，Agent C据此调整了开发计划，后来发现那份排期表根本是Agent A自己预测的，并没有经过任何人确认。
对付这个问题，我给自己定了几条组织原则：
- 关键事实必须附带来源引用：消息中涉及数字、日期、决定、承诺的字段，必须有指向事件日志或文档的引用ID。
- 代理间传递信息时必须区分“事实”和“推断”：消息结构里加一个
confidence字段，confirmed表示有据可查，inferred表示是代理推测。 - 高风险操作强制人工确认：涉及对外承诺、资源消耗、生产变更的操作，无论代理多么自信，都必须卡在
WAITING_APPROVAL状态。
这套机制不能彻底消除幻觉传播，但能把“信任原点”从模型输出转移到真实事件记录上，让代理的每一次引用都有据可查。
4.4 审计与回滚：没有审计就没有“代为”
一个允许代理代表用户做事的系统，如果没有完整审计，出了事故连排查都无从下手。我维护的审计字段覆盖以下要素：
| 审计字段 | 作用 |
|---|---|
| actor_id | 实际执行操作的代理标识 |
| principal_user_id | 最终委托人（哪个用户发起的授权链） |
| model_id | 生成该决策所用到的模型（哪个厂商、哪个版本） |
| action | 执行的具体操作（读、写、创建、删除、审批） |
| resource_ref | 操作涉及的文件、任务或消息引用 |
| input_snapshot | 触发该决策的关键上下文摘要 |
| output_snapshot | 代理给出的结论或行动结果 |
| timestamp | 事件时间 |
| trace_id | 贯穿整条操作链的追踪ID |
有了这套审计日志，哪怕代理真的做错了事，也能沿着trace_id回溯整条决策链，找到是哪一步引入了错误信息，然后基于历史事件流做定点回滚。我在系统里把回滚做成了一等公民能力：任何时刻都可以指定某个trace_id作为回滚边界，系统自动撤销这个追踪链上未确认的动作。
5. 异构模型接入与部署形态：本地模型、云端模型与边缘设备的协同
5.1 为什么一个系统里会同时存在多个模型
很多人在做多智能体系统时，默认所有代理都用同一个大模型。但真实业务跑起来会发现，这根本行不通。成本是第一个问题，重要程度不高的请求全走大模型，费用很快就失控；隐私是第二个问题，很多企业内部数据不能出内网；延迟是第三个问题，关键路径上未必等得起一次完整的大模型推理。
所以我现在设计系统时，默认就是“一个平台、多个模型、按需路由”。比如前面提到的需求评审场景，Agent B负责出视觉方案，它调用的是本地部署的图像理解模型；Agent C负责技术可行性评估，它调用的是推理能力更强的云端大模型；而Agent A只需要协调沟通，直接用轻量模型就够了。
5.2 模型路由与降级策略
接入层除了统一适配，还要承担模型路由的职责。我设计的路由规则包含四个维度的判断：
- 任务类型：代码审查、数据分析、文档撰写、图像理解，各有擅长的模型。
- 隐私等级：敏感数据只能路由到内网模型或本地模型，不能出域。
- 成本预算：每个任务在消息信封里带有
quota.max_cost，路由引擎根据剩余预算选择模型。 - 当前负载：当某个模型服务繁忙时，路由引擎自动把任务分流到备用模型。
降级策略同样重要。模型A超时或返回质量明显异常时，系统会自动切换模型B重试，并在审计日志里记录“此任务实际由模型B完成”。这个重试逻辑对上层透明，编排层不会感知到模型切换。
5.3 部署拓扑：中心化、边端混合与完全分布式
不同场景对部署拓扑的要求完全不同，我梳理了三类最常见形态：
| 部署形态 | 适用场景 | 优势 | 挑战 |
|---|---|---|---|
| 中心化部署 | 企业内部流程协同 | 治理简单、审计集中、状态一致 | 单点风险、远端延迟 |
| 边端混合 | 工厂、门店、移动办公场景 | 本地模型保隐私、低延迟 | 设备资源有限，同步复杂 |
| 完全分布式 | 跨组织、跨公司的代理协作 | 去中心、抗单点故障 | 一致性保障难度大 |
我在实际项目里用得最多的是边端混合形态。一部分AI代理运行在中心服务器，负责流程编排和复杂决策；另一部分轻量代理运行在边缘设备上，负责快速响应和本地数据处理。边缘设备（比如ARM架构的开发板、迷你主机）上跑本地模型，配合中心端的统一事件日志做状态同步，既满足了低延迟需求，又保住了集中审计能力。
这里有一个值得借鉴的跨领域思路：机器人领域早就用ROS这类消息框架，把多个智能体节点连接在同一个通信域里协同工作。多AI代理系统面临的通信问题，和机器人群体的协调问题本质上高度相似——节点发现、消息路由、生命周期管理、状态同步。我们完全可以把ROS里验证过的成熟机制，映射到通用多代理系统设计里。这也是我把“消息总线”放在协作层核心位置的原因，它本质上就是一套适应智能体通信的分布式路由基础设施。
6. 落地复盘：我踩过的坑和对应调整
6.1 坑一：代理循环对话导致资源耗尽
第一次跑通多代理联调时，我们遇到一个很隐蔽的问题：Agent A向Agent B发了一条请求，Agent B发现信息不足，回了一条“请提供更多上下文”，Agent A又补充了一段，Agent B再回复……两个代理礼貌地来回聊了几十轮，直到把token预算耗尽。系统层面完全没有意识到这是一个死循环，因为每一轮都有新的消息产生。
虽然可以在需求层面通过设置最大轮数来兜底，但治本的办法是给每条消息加生命周期。我在路由规则里加了一个ttl字段，限制一条消息最多能被转发多少次；同时设置了代理间交互的最大跳数，超过跳数上限的通信链会自动断开，并触发警告通知到相关代理的用户。现在的效果是，代理之间一旦出现无效循环，通常在几轮之内就会被打断，而不是让资源白白烧光。
6.2 坑二：上下文风暴让每个代理都超载
多代理协作天然需要交换信息，但如果每个代理都倾向于“我把全部已知信息都发给你”，系统很快就会被上下文淹没。我实测过，三个代理协作处理一个中等复杂任务时，如果互相传递完整上下文，单个代理的输入token会在三轮交互后膨胀到不可控的程度，推理延迟和成本同时飙升。
这个问题的解法我用的是“按需拉取”取代“主动推送”。代理间沟通时，消息里只传递必要字段和引用ID，收件代理如果确实需要更多信息，再通过一次显式请求去获取原始数据。对应到系统实现里，消息总线会拦截那些体积过大的消息，超过阈值就要求发送方将内容转为索引引用。系统跑起来以后，整体token消耗比原来的推送模式下降了大约60%。
6.3 坑三：模型能力差异导致“协作偏心”
当同一个系统里的代理背后是不同的模型，能力强的模型往往会“顺手”把能力弱的模型的活也干了。乍一看好像是高效协作，实际上隐患很大：强模型可能会替弱模型做出超出其职责范围的决策，而这些决策并没有经过对应领域的校验。
比如Agent C（云端强模型）在回复Agent B的设计方案时，顺手把技术方案的架构选型也定了。虽然这个决定看起来合理，但它绕过了后端评审流程，后续一旦出问题，追责链路是混乱的。
后面我规定：每个代理只对自己的职责领域负责，跨领域建议必须走正式协商流程，不能直接在消息里拍板。而且系统会在代理做出超出职权范围的决策时给出提示，强制要求它重新表达为“建议”而不是“决定”。
6.4 坑四：多代理问题定位难到想放弃
系统里的代理一旦超过五个，排错就变成了灾难。之前没有做全局链路追踪的时候，任务出问题只能逐个代理看日志，经常看到一半就发现上下文对不上。后来我把trace_id贯穿到每一个消息、每一个任务事件、每一次模型调用里，配合日志聚合查询，才算真正能从端到端视角观察一条任务链的完整生命周期。
我建议其他团队在系统设计初期就把trace埋好。哪怕第一版只有简单的trace_id和parent_message_id，也比事后补一套全链路追踪工具要省力得多。另外我还会监控代理间的消息延迟、任务状态滞留时间、单代理的token消耗速度这几个指标，它们基本能覆盖多代理系统90%的异常场景。
7. 如果再让我重新设计一次，有几个地方我会直接推翻
这套架构做到现在，整体是能撑起“多人多AI协同”的核心诉求的，但如果带着现在的认知重新做一遍，有几个决定我会直接推翻。
第一，我会把“消息引用”机制放到第一优先级来设计，而不是中期才补。哪怕在最早期只有两个代理协作，也应该严格要求每条消息的消息体必须带来源引用，这个习惯养成后，后续做审计和回滚会省掉大量返工。第二，我会把审计日志当成核心业务能力来建设，而不是当作运维辅助功能。没有审计，就谈不上“代为”，这句话我是在踩了坑之后才真正体会到的。第三，我会把“人工确认”设计成系统的一等公民状态，而不是在代理逻辑里临时插入等待。代理做得越好、越快，人需要介入的点就越应该被显式管理，否则系统就是在加速制造不可控的后果。
至于完全自治的多AI协同，我反而觉得不是当前最应该追求的目标。更实际的方向是让代理之间把事务性协调做到位，同时让用户在人机边界上有清晰的把控权。这套“代为交互”的架构思路，本质上不是为了让AI代理取代人的决策，而是为了让人的意图能够准确、可靠地传达到每一个协作节点，再由代理网络把结果高效地带回来。多试几次，你就会发现，这种可控的自动化，比彻底放手让代理们自由协作要靠谱得多，也更接近真实业务里能长期稳定跑下去的那套形态。
