AI代理协同架构实战：身份、记忆与仲裁机制全解析

最近在做多人多AI协同系统架构的预研，发现一个很有意思的现象：大家讨论最多的往往是“哪个模型又多强了”“本地模型部署到哪一步了”，但真正难啃的骨头压根不在这——而是多个AI代理之间怎么协作、它们代表谁的利益、出了问题谁负责。我带着团队跑了几轮实验，把AI代理、消息总线、记忆引擎、仲裁器这些组件拼在一起，搭了一套“代理代为交互”的原型系统。这篇文章不聊模型本身，重点把整体架构、关键机制、踩过的坑和一组实测数据一次说清楚，希望对同样在探索这个方向的人有点用。

1. 从“人手一个AI”到“代理代表你参会”：这个架构要解决的现实问题

先说一个我自己的体验。上个月小组做技术方案评审，六个人每人电脑上都开着两三个AI聊天窗口。产品经理问“发布方案谁帮我看看风险”，开发说他刚让AI写了一版评估但不知道发给谁，测试那边也攒了一份检查清单，最后所有信息都堆进共享文档，没人分得清哪些内容经过人工确认、哪些是AI直接生成的、哪些已经过时。

这一刻我意识到一件很本质的事：给每个人配一个AI助手，不等于团队能用好AI协作。单人多AI，本质上还是用户自己在多个聊天框之间复制粘贴；真正的多人多AI协同，需要一个不一样的抽象：每个用户拥有一个能代表自己、替自己与其他AI系统沟通的代理（Agent），整个系统围绕“代理间交互”而不是“模型间调用”来设计。

1.1 信息孤岛：每个AI聊天窗口都是一座孤岛

传统用法里，AI服务的边界就是一个聊天会话。用户聊完一个话题，上下文就锁在那个窗口里。团队里A的AI不知道B的AI聊过什么，更不可能主动承接下一个环节的工作。我做过一个小调研，一个10人团队用各类AI助手的场景里，90%的信息流转还是靠人肉搬运——从AI窗口复制到文档，再发到群里，再被别人贴进另一个AI窗口。这种方式有三个硬伤：

• 信息不同步：同一份需求，不同代理基于不同上下文给出互相矛盾的结论；
• 责任不明确：AI生成的建议没人认领，后续没人跟进校验；
• 上下文不连续：跨天、跨任务之后，AI完全不记得自己曾经给过什么结论。

所以这套架构的第一个目标很朴素：打破“一个聊天窗口一个孤岛”的状态，让代理之间通过结构化消息直接对话，把协作链路从“人肉搬运”变成“代理接力”。

1.2 代理代交互：给每个用户配一个“数字秘书”

“代理代为交互”是我在这套系统里反复强调的核心概念。它不是让模型更聪明，而是改变了交互的主体：过去是人直接跟AI对话；现在是人跟自己的代理对话，代理再以你的名义去跟别的代理、别的AI服务交互。你可以把代理理解成一个有身份、有记忆、有权限边界的数字秘书：

• 有身份：每个代理绑定一个真实用户，知道“我是谁”“我能代表谁做决定”；
• 有记忆：它记得用户的长期偏好、历史决策和领域知识，不用每次重新交代背景；
• 有工具：它能调用代码、检索文档、读取数据，不只是输出文本；
• 有边界：关键决策必须回到用户那里审批，代理不能越权承诺。

直接让用户一个人同时操作多个AI，与让用户的代理去跟其他代理打交道，体验上有一个关键差异：前者需要用户自己协调、自己背锅；后者把协调工作下沉到了系统层，用户只需要在关键节点做监督和授权。

1.3 适合与不适合的边界

这套架构适合的领域有一个共同点：任务可以拆解、责任可以明确、过程需要可追溯。比如项目管理、研发协同、市场调研、代码评审、活动策划这类场景就很合适。反过来，高风险决策场景（如医疗诊断、司法判断、财务放款）现阶段不应该让代理自治，即便要用，也必须设计强制人工审批节点，代理只能做信息汇总和风险评估。

2. 动手设计前的三个关键判断：身份、记忆与仲裁

架构图画起来容易，真正动手才发现，有三个问题如果不在设计前期想清楚，后面处处受制：代理的身份怎么建模，记忆归谁所有，多代理意见冲突时听谁的。这三个问题都没有标准答案，我给出我的判断和理由。

2.1 给代理一个“数字人格”

我把代理身份设计成了“用户身份的数字延伸”，而不是一个独立的系统账号。每个代理有一张代理卡（Agent Card），记录四类信息：

这张代理卡的作用不只是给人看的。每次代理调用大模型时，系统会把代理卡里的身份信息注入到系统提示词中，并在代理间消息里附带身份签名。这么做的好处是，从顶层设计上避免“AI不知道自己是谁”的混乱——这个问题在单聊场景下不明显，一旦多代理交互，任何一个代理都可能误解自己的角色。

2.2 记忆管理要回答“这段记忆是谁的”

多代理协同里最常见的认知错误是：只要上下文够长，代理就能做好。实际上，记忆的核心矛盾不是长度，而是归属权。同一个信息放错层级，会导致两种灾难：把该保密的私有信息共享给了所有代理，或者把团队共知的决策锁在一个人的私有记忆里导致重复劳动。

我采用的方案是做三级记忆隔离：

• 私有记忆：只有代理自己可读，包含用户一对一的历史对话、个人草稿、未公开偏好；
• 团队记忆：代理间可共享，包含项目文档、决策记录、进度状态，写入团队记忆需要较高权限；
• 公共记忆：全系统可读，包含制度规范、知识库，由管理员维护。

实际实现时，记忆不是一个大文本，而是按条目存储。每个记忆条目带元数据标签（创建者代理、创建时间、读取权限）。代理读取记忆时，先过一遍权限过滤，再进入向量检索。这一步直接决定了后续协同的可靠程度。

2.3 多代理协同不是并行，是仲裁

业界聊多代理时爱强调“并行调用”“pipeline流水线”，但我做下来最深的体会是：多代理协同的本质是仲裁。因为多个代理各自代表不同用户的利益，目标天生会冲突。比如产品代理要快速上线，研发代理担心质量风险，合规代理要加一堆审核流程——每个都合理，但没法同时满足。

我的设计是让系统层介入仲裁，而不是让代理自己吵出结果。仲裁器的规则如下：

1. 按决策类型划分管辖权：技术方案听研发代理的，体验问题听设计代理的，风险合规听合规代理的；
2. 同一类型意见冲突时，按任务的优先级权重投票，权重由任务发起时用户共同设定；
3. 涉及资源、预算、对外承诺的，一律转人工审批，代理只有建议权。

这套机制看似增加了系统复杂度，却避免了一个更麻烦的问题：代理之间陷入无限沟通却无法收敛。说到底，代理没有真正的利益诉求，它们只是在替不同的用户在表达——那冲突就必须回到用户层的授权关系去解决。

3. 五层架构落地：交互层、代理运行时、编排层、模型网关与基础设施

想清楚上面三个判断之后，我开始搭具体的系统结构。整体上分为五层，每层职责单一、可独立替换，这也是分布式系统架构里反复强调的解耦思路——就像交换机把网络切成可管理的交换域一样，每层只跟相邻层通信，避免大泥球。

3.1 分层总览

依赖方向是单向的：上层依赖下层的接口，下层不反向依赖上层。这意味着我可以随时替换某一层的具体实现，比如把消息总线从一种中间件换到另一种，上层完全无感。

3.2 用户交互层：人的审查比AI的决策更重要

交互层表面上是个聊天界面，实际承担着一个关键职责：代理行为的审查与授权。用户跟代理对话时，系统会同时提供一个“代理近期行为面板”，显示代理刚刚做了什么、调用了什么工具、准备向谁发送什么消息。涉及敏感操作时，代理进入waiting_approval状态，消息不会真正发出，直到用户在面板上点“批准”。

我的理由很简单：代理可以自治，但不能自主到脱离人的监督。多数任务场景下，用户并不想每步都确认，所以我把审批策略设计成三级可配置——全自动、关键节点人工确认、全部人工确认。默认是中间档，代理能自主完成信息收集、草拟、分析；凡是生成外部消息、修改团队记忆、承诺时间节点，必须经过用户确认。

3.3 代理运行时层：状态机、记忆引擎与工具集

每个代理在运行时是一个长驻的服务实例，内部维护一个状态机：idle → receiving → planning → acting → reporting → waiting_approval，任何时刻代理都处于其中一个状态。状态机的好处是可控：系统能清晰知道每个代理在做什么，也能在异常时做状态回退。

记忆引擎是这一层最重的模块。我用SQLite存结构化条目（用户偏好、决策记录），用向量库存非结构化文本（会议纪要、文档段落）。代理读取记忆时先走权限过滤，再做向量检索，最后把命中的条目组装进提示词。工具有些是内置的（代码执行、HTTP请求、文件读写），有些是插件化的（企业内部的API，比如需求管理系统、Bug追踪系统）。

3.4 编排与仲裁层：多代理协作的交通警察

编排层是这套架构里“多人多AI协同”的核心体现。它的职责不是帮代理写内容，而是决定“谁该参与这个任务、以什么顺序参与、意见冲突时听谁的”。路由器的输入是任务的类型标签列表，输出是参与代理的名单和协作模式（后面章节会细说）。仲裁器则维护一组规则和决策记录，每次争议解决后都会把结论写入团队记忆，形成类似判例的沉淀。

任务队列也是这一层的重要部分。多代理不是各自想干就干，所有跨代理任务都进入统一队列，按优先级和依赖关系调度。实测下来这个设计非常必要——没有队列控制，两个代理同时修改一份文档导致的覆盖问题，在多代理场景下会被放大数倍。

3.5 模型网关层：本地模型与云端模型的路由策略

模型网关把五花八门的模型统一成一套接口，内部做路由。这里特别说一下本地模型和云端模型如何混合使用——这是我在预研里花时间最多的一块。策略不是“全上云端”或“全上本地”，而是按任务特征路由：

这里有个不太直观的经验：本地模型的定位不是“平替云端”，而是“就近处理低敏感、高频、高实时要求的任务”。代理之间的很多内部沟通其实只需要中等智力水平，没必要每次都调用最强的云端模型。省下来的token，留给真正需要深度思考的任务，效果反而更好。

3.6 基础设施层：消息、存储与追踪

基础设施层里最重要的组件是消息总线。所有代理间消息都走总线，而不是点对点直连。这样代理之间完全解耦，发送方不需要知道接收方的地址和状态，也方便做消息的持久化、重放和审计。存储方面，除了记忆用的向量库，还需要对象存储保存代理生成的大文件（文档、图片、代码包）。可观测性这块我用了日志追踪系统给每个协同任务打一个全局trace_id，串起所有相关消息和模型调用——没有这个，多代理出问题的时候排查起来就是灾难。

4. 代理间协作机制详解：协议格式、协作模式与异常回退

架构定了之后，真正的硬骨头在协作机制本身。代理之间怎么说话、怎么分工、谈不拢怎么办、有代理失联怎么处理，这些细节决定了系统是“能跑”还是“好用”。

4.1 结构化消息协议：给代理之间定规矩

代理之间不传自然语言碎片，而是传递结构化消息。下面是消息的基本格式示例：

{ "message_id": "msg_8f3a2c", "protocol_version": "1.0", "type": "task.delegate", "sender": "agent:product_po01", "recipient": "agent:tech_lead01", "trace_id": "trace_d4349f", "intent": "请评估发布计划中的技术风险并输出结论", "context_refs": ["mem:team:release_20250115", "mem:public:risk_control_policy"], "permission_required": "read:team_repo, write:risk_log", "deadline": "2025-01-20T18:00:00Z", "priority": 5, "signature": "agent:product_po01:timestamp:sig" }

几个关键字段说明一下。intent是消息的意图，系统会先做一次意图识别，判断该交给哪个代理、属于什么协作模式，这比让模型直接读整条消息更省token也更可控。context_refs是引用记忆条目标识，接收方按标识去取具体内容，而不是把全文塞在消息里——这是避免上下文爆炸的重要手段。permission_required声明这条消息需要什么权限，接收方代理在行动前会校验自己的权限是否覆盖。signature是身份签名，防止身份伪造。

4.2 三种协作模式：委派、协商与黑板

多代理协作不是只有一种形态。我在系统里实现了三种模式，按任务性质选择：

主从委派：任务发起代理把任务拆分，委派给多个执行代理，执行代理完成后回报。适合“老板分活”的结构。比如产品发布计划拆成风险分析（研发代理）、体验检查（设计代理）、宣传物料（运营代理）。执行代理之间不直接交互，由发起代理汇总。

对等协商：多个代理平级讨论一个问题，各自基于自己的用户视角给出意见，由仲裁器做最终裁定。适合意见型任务，比如“版本是否达到发布标准”。每个代理先独立分析，再提交结论和理由，仲裁器按管辖权规则裁决。

黑板共享：多个代理读写一个共享工作区（黑板上的一块空间），谁看到有自己能做的就去补充。适合持续演进型任务，比如联合编辑一份长期维护的文档。黑板是异步的，代理不需要同时在线，我用了带版本控制的对象存储来实现。

4.3 仲裁与权限链：每个决策都要能追到人

多代理协同里最敏感的问题就是责任归属。系统里任何决策记录都保留一条完整的授权链：提议者代理 → 支持该提议的代理们 → 最终确认的用户或仲裁规则。在审计界面上，一条决策可以完整展开“谁提的、谁附议的、根据什么规则定的、哪个环节经过了人工审批”。这样做还有一个额外的好处：仲裁规则本身会沉淀成决策记录，后续遇到类似冲突可以直接复用，不用每次重新吵一遍。

4.4 异常处理与回退

代理毕竟是大模型驱动，天然有不确定性和不稳定性。我预置了三类异常处理机制：

• 超时回退：消息发出后，如果接收代理在设定时间内未响应，发起方按策略升级（重发一次、改派其他代理、转人工）；
• 死循环保护：任何协作链路的迭代步数设上限，超过上限强制进入人工接管流程；
• 状态恢复：代理状态机实现了检查点，进程崩溃后可以从最近一个稳定状态恢复，消息队列里的消息不会丢失。

这三种机制一开始只做了前两种，第三次跑实验时一个代理进程直接崩溃，恢复后它完全不记得自己发了什么，我才明白消息持久化和状态恢复必须一起做。现在每个代理落地时都会先写检查点再更新状态，虽然多了一次写操作，但可靠性大幅提升。

4.5 记忆跨代理共享的脱敏策略

代理之间的记忆共享，安全边界比功能更优先。我给记忆读取加了一道脱敏层：代理A请求读取团队记忆里的某个条目时，系统先把条目通过本地模型跑一遍脱敏识别，过滤掉带私有标签的实体（人名细节、未公开数字、客户编码），输出脱敏版本给代理A。这导致一个意料之中的副作用：读取记忆多了几秒延迟。但因为脱敏是本地模型执行的，不涉及外部调用，延迟可控。

5. 技术选型复盘与踩坑实录：框架、总线、上下文与死循环

这节写的是最折腾人的部分。理论设计再顺，落地时总会碰到一些文档里不会写的问题。我把选型思路和六个最典型的坑都放在这里。

5.1 Agent框架选型：为什么没有直接用AutoGen

市面上Agent框架不少，主流的LangGraph、AutoGen、CrewAI各有优势。AutoGen的多代理对话能力很强，但它的抽象偏重“对话流”，对“代理身份绑定用户”“记忆权限隔离”“审批链路”这类的企业协同需求支持较粗，改造起来不顺手。LangGraph的好处是状态图模型清晰，适合精确定义代理状态流转，但团队需要自己补齐记忆、权限、总线这些外围模块。

我最终的选择是LangGraph做代理内部的状态编排，通信和记忆模块自研。理由很直白：多人多AI协同的复杂点不在“让模型聊天聊得久”，而在“身份、权限、记忆、仲裁”这套协同基础设施。框架只能解决前30%，剩下的还是要自己造轮子。

5.2 消息总线选型：并发实测与教训

消息总线我在NATS、RabbitMQ和Kafka之间比对过。Kafka吞吐高但偏重，团队只有几十个代理的场景用它是杀鸡用牛刀；RabbitMQ功能全，但运维复杂度稍高。NATS轻量、部署快、支持请求-响应模式，符合我这套系统当前阶段的规模。同机环境下做了个快速测试：128个并发消息，端到端延迟稳定在2ms上下，完全够用。

总线选型这里想提醒一句：不要按“以后可能到百万并发”来定，按当前场景的量级选，留好替换接口就行。多代理协同系统真正的瓶颈永远在模型推理延迟，不在消息总线。

5.3 上下文爆炸：最早就踩的坑

第一次联调，两个代理协作分析一份30页的产品需求文档，消息里直接把全文作为context传了过去。结果就是：token消耗暴涨，模型回答质量反而下降（被无关细节干扰），还拖慢了整个链路。后来我彻底改成前面说的context_refs引用机制：消息不传递内容本体，只传引用ID，接收方按需检索后再把必要片段组装进提示词。

配套还做了上下文压缩：代理状态机在每次任务结束后，把本轮对话摘要成一个结构化条目存入团队记忆，新任务开始时不再加载全部历史，只加载摘要和检索命中的相关条目。这两个手段叠加后，同样任务token消耗降了约70%。

5.4 代理死循环：两代代理互相等待

有个经典翻车现场：代理A请代理B确认方案，代理B说需要代理A先提供测试数据，代理A又说测试数据要等B的确认才能生成——两个代理就这么在队列里互相等，直到超时。如果没有迭代上限，这个过程可以无限持续，既浪费token又拖垮整个任务。

修复方案是双管齐下：全局协作链路设置最大迭代步数（默认8步），超出强制转会人工；同时每个消息携带deadline字段，接收方如果预期在deadline前完成不了，必须主动发送阻塞通知，让发起方及时调整策略而不是干等。

5.5 身份边界模糊：代理忘掉了自己是谁

跑协同实验时长文本对话，代理A在引用代理B的建议后，突然以B的口吻继续输出，并且在后来的交互里把自己当成了B去承诺事项。这个问题的根源是上下文里身份信息弱化，模型在长对话中丢失了“我是谁”的锚点。

解决方法是三层加固：代理卡身份信息随每次请求注入系统提示词；消息协议里强制带签名；代理输出模块增加身份一致性校验，发现输出名字与代理身份严重不符时，自动截断并要求重新生成。从此这个现象基本绝迹。

5.6 可观测性：没有Trace就没法排查

这条不是坑，是救命的工具。多代理协同里一个问题可能涉及五六个代理、十几次模型调用和几十条消息。没有全局trace_id之前，每次线上问题排查都是噩梦：不知道哪个环节出的错、模型里发生了什么。现在每个任务从进入队列那一刻就生成trace_id，贯穿所有消息和调用日志。排查问题时按trace_id一搜，整条链路一目了然。这个设计建议所有做类似系统的人从第一天就加上，不要等。

6. 六代理协同实测：一次产品发布任务的完整流转

最后用一个实际跑通的场景收尾。测试团队六个人，每人一个代理：产品、研发、测试、设计、运营、合规。任务是24小时内产出产品发布方案。

6.1 任务拆分与分工

任务进入路由器后，按类型标签拆成了四条子任务链：风险与技术可行性（研发代理）、质量验收标准（测试代理）、发布物料与推广计划（运营代理）、合规审核清单（合规代理）。设计代理没有直接进主线，而是在运营代理生成物料时被动态调用。这个“动态按需加入”的机制是路由器的重要功能——不是所有代理都要参与所有任务。

6.2 关键交互与仲裁流程

最关键的冲突发生在研发代理和运营代理之间。研发代理建议发布日定在25号（因为还有两个bug需要回归），运营代理坚持20号（配合节日营销窗口）。两个代理都给出了自己的理由，消息进入了仲裁器。按我的仲裁规则：发布排期这类任务属于运营管辖权，但涉及阻塞性缺陷，研发风险意见权重更高。最终仲裁结论：23号发布，研发代理在21号前提测修复版本，测试代理同步编排加速回归计划。整个仲裁过程在系统里留了完整记录，包括每个代理的理由摘要和最终确认人。

6.3 实测数据与当前局限

跑完整个流程，记录下几组数据：端到端耗时约47分钟，其中模型推理时间占88%；全部代理合计调用模型约240次，消耗token约21万（含本地模型部分）；团队记忆新增决策条目17条，全部带授权链。对比人力全职做同样方案的历史耗时（大约一个下午），效率提升是实打实的。

但这套系统目前的局限也明确：一是代理的结论质量高度依赖基础模型能力，复杂场景下仍会出现幻觉性建议，只能靠人工审批兜底；二是跨组织场景下的信任问题没解决——两个公司各自部署一套系统，代理之间互信、数据授权都是开放问题；三是仲裁规则目前还是人工配置，规则之间的隐性冲突需要维护者持续调整。

我个人做完这轮预研最大的体会是：多人多AI协同系统架构的难点，技术占一半，组织机制占另一半。代理之间怎么说话是工程问题，代理代表谁的利益、多大权限、冲突听谁的，这些在系统设计前就得想清楚。上面的方案肯定不是最优解，但它把我在实际搭建中踩过的雷、验证过的机制都如实记录下来了。后面我还会继续深挖机器人场景下的多智能体协同，感兴趣的话可以持续关注。