你有没有遇到过这种场面工位上同时开着四五个AI对话框一个写需求、一个查资料、一个审代码、一个出测试你像个传话筒一样在它们之间搬运信息。一个人这么干还能勉强扛住放到团队协作里就彻底失控了——组里五个人每人各带两三个AI助手十个AI各说各话连需求文档最终版本是谁改的这种问题都要吵半小时。我做这套架构研究的初衷其实很简单把AI从单机工具变成协作网络公民。方案说起来也不复杂——别让AI直接对着AI聊天而是给每个AI引擎套一层代理Agent Proxy让代理代为参与协作。这个代理层负责协议转换、权限校验、任务编排和上下文同步人不再当传话筒AI也不再是信息孤岛。这篇文章会把整套架构的分层设计、通信协议、上下文管理、异构模型接入以及我在实测中踩过的坑完整地拆开讲一遍。如果你也在做多智能体系统或者正准备让手里的AI们开始协作这篇应该能帮你少走不少弯路。1. 为什么必须代理代为交互多AI聚在一起反而更笨1.1 我观察到的六个失控现场还是先说现象。我最早做的原型非常简单——把三个AI拉进同一个会话让它们自由讨论。跑了一个礼拜收集到的不是灵感而是六个反复出现的问题。第一上下文互相踩踏。需求AI把结论写在会话里代码AI根本没看就开写结果实现的需求是两小时前的旧版。第二重复劳动。三个AI都在查同一个接口文档因为没有人或者说没有代理告诉它们这件事已经有人做过了。第三责任追溯困难。线上出了问题查log发现某个方案是AI乙提出来的但AI乙的依据来自AI甲的一段不完整引用谁该负责人和AI都没法界定。第四Token消耗爆炸。一次简单的方案评审三个AI来回讨论了两百多轮烧掉了几十万Token有效信息不到两千字。第五终止条件缺失。AI之间的对话没有天然的够了信号经常出现两个AI互相肯定、来回客套的死循环。第六人为干预困难。我想让AI丙停下来先别发言结果它继续参与了两轮才响应因为会话里根本没有暂停某个参与者的控制面。这六个问题共同指向一个结论多Agent协作不能靠ChatGPT式的自由聊天协议来承载必须要有独立的交互代理由代理来执行纪律。1.2 群聊式架构为什么一定走不通我把市面几种常见做法拉了一张对比表方案Token消耗上下文一致性可追溯性可控性全自由对话AI直接互聊指数增长差各自维护上下文差没有审计链路低很难暂停/撤回中心调度群聊一个编排器转发消息线性但总量大中共享一个会话但信息混杂中有转发记录中编排器能干预代理代为交互每个AI套代理结构化通信可控消息即工单好读写分离共享黑板私有区强每条消息都有信封高代理层可暂停、回滚、仲裁群聊模式最根本的问题在于把人对话的高冗余容错当成了理所当然。人聊天时容忍大量废话、情绪、潜台词但AI协作需要的恰恰是低冗余、高结构化、可校验的信息交换。这套要求只有代理层能提供。1.3 代理层到底代了什么代为交互这四个字我的理解包含两个转变。第一个转变是AI产出从自由文本变为结构化工单。AI引擎的输出先经代理校验合格才进入协作网络不合格就退回重写。这样一来下游Agent拿到的一定是符合Schema的、可程序处理的内容而不是一段可能混着幻觉的散文。第二个转变是人的角色从信息搬运工变为决策节点。人类用户只需要在几个关键点出手——审批方案、裁决争议、调整方向——其余的信息流转全部由代理层代劳。这个转变是整个架构成立的前提。如果理解不了这两点后面所有设计都会走偏。2. 架构分层总览接入层到执行层之间发生了什么2.1 五层架构的划分与职责我做这套系统时没有一上来就写代码而是先把职责边界画清楚。总共有五层第一层接入层。管人的身份、设备、入口。用户通过Web端、聊天客户端、甚至API钩子接入接入层统一处理鉴权不关心背后挂了几个AI。第二层编排层。这是整个系统的大脑皮层。负责把用户的自然语言目标拆解成任务图Task Graph决定任务分给哪个代理、什么顺序执行、状态如何流转。任务状态机是这一层最重要的数据结构。第三层协同层。这是代理代为交互发生的物理位置。包括消息总线、共享黑板Shared Blackboard、仲裁服务。代理之间不直接连接全部通过这层交换结构化消息。第四层执行层。各种AI引擎的适配器。云端大模型、本地小模型、工具类执行器代码解释器、浏览器、API调用器都在这层注册统一暴露成可调用的代理单元。第五层存储层。上下文库、记忆库、审计日志、消息归档。这一层我不建议用同一个库硬抗上下文和审计日志的读写模式完全不同分开存才划算。各层之间通过明确的接口契约通信禁止跨层调用。比如执行层的AI绝对不能直接写存储层它的所有产出都必须回到协同层由协同层决定是否落库。这个约束看着死板实际调试时能省下大量谁动了我的数据的破案时间。2.2 任务状态机一切协作进度的基础任务状态机是编排层的核心。我最终定下来的状态集合是这七个PENDING待分派→ DISPATCHED已派发→ IN_PROGRESS执行中→ REVIEW待评审→ APPROVED已通过→ MERGED已合入项目主线。分支情况时还有 REJECTED被驳回→ REOPEN重新打开。但更重要的是状态之间的合法转换约束DISPATCHED 不能直接跳 MERGED必须经过 REVIEW 和 APPROVED被驳回的任务回到 REOPEN 后只能重新走 PENDING不能插队到 IN_PROGRESS。每个状态都对应着代理层的一个明确动作和一条结构化消息。比如任务进入 REVIEW 状态时协同层会自动给评审代理发一条 APPROVAL_REQUEST 消息评审代理不是AI而是一个人工审批服务——这正是代为交互里代字的分量所在机器把节奏控制好人只在关键节点出手。2.3 为什么任务必须显式建模而不是塞进Prompt这里有一个架构上的取舍我见过很多团队在Prompt里写你负责这个子任务完成后通知下一个Agent让Agent自己理解任务边界。实测下来这种方式在五个Agent以内还能跑超过七个就崩——Agent对完成的定义不一致对上下游职责的理解也会有偏差。任务显式建模的价值在于把谁在做什么、做到什么程度算完从隐含的Prompt语义里拿出来变成程序可校验的状态。代理A说任务做完了系统先看状态机是否允许从 IN_PROGRESS 跳到 REVIEW再看产物Schema是否完整两关都过才算真完成。这套机制从根本上解决了多AI相互等待、互相甩锅的死锁问题。3. 代理间通信协议用工单流取代聊天流3.1 消息信封每一条协作信息都有明确的身份和边界代理之间的所有通信都走消息总线而消息的格式是我反复迭代最多的部分。早期我用过纯文本消息后来发现下游代理解析困难一个好的两个字就会让流程卡住。最终定下的方案是信封规范载荷两层结构。信封是所有消息的公共头字段如下字段作用message_id全局唯一用于追踪整条消息的生命周期session_id所属协作会话隔离不同项目source_agent发送方代理IDtarget_agent接收方代理ID广播场景用通配符msg_type消息类型如TASK_ASSIGNpriority优先级影响路由和处理顺序timestamp生成时间trace_id链路追踪贯穿任务拆解到最终合入载荷部分用JSON Schema定义每个消息类型对应一个Schema版本。代理侧的SDK启动了load schema by msg_type的逻辑收到消息先校验再解析校验失败直接进入死信队列而不是在生产环境里默默吞掉错误。3.2 五类核心消息与它们的消费规则整个协作流程里我用到的消息类型其实只有五类。第一类是TASK_ASSIGN任务指派编排层发给某个执行代理包含任务ID、目标、输入引用、预期产出类型、截止时间。消费规则一个任务只能被一个代理认领重复认领直接抛异常。这是避免多人多AI重复劳动的关键。第二类是TASK_REPORT进度与结果上报执行代理发回编排层包含任务状态、产物引用、置信度、遇到的阻塞项。这一条是让人类监督者随时掌握全局的依据。第三类是QUERY / RESPONSE查询与应答。代理之间可以互相查询信息但查询必须走代理层不能直接翻别人的私有上下文。比如代码代理要问需求代理这个字段的边界值是什么发出的是一条结构化QUERY需求代理的代理层检索自己工作区后把结论封装成RESPONSE返回。第四类是VOTE_REQUEST / VOTE表决请求与表决这是多AI仲裁的基本消息对。当一个决策存在多个方案冲突时仲裁服务向相关代理发起表决请求各代理返回带置信度的表决结果。第五类是APPROVAL_REQUEST人工审批请求。这是唯一一种不发给AI的消息类型它发给人类用户的审批客户端。消息里附带方案摘要、影响面分析、相关上下文引用人只需要点同意/驳回/要求修改。实测发现把审批信息组织得足够清晰人的决策时间能压缩80%。这不是AI的功劳是信息结构的功劳。3.3 消息路由推拉结合避免消息风暴多代理场景下最怕广播风暴。我的路由策略是点对点消息TASK_ASSIGN、TASK_REPORT走推模式由编排层直接投递到目标代理的队列。广播类消息比如需求基线已更新走拉模式协同层把事件写入事件表代理在空闲时按需拉取而不是被实时轰炸。每个代理维护自己的待办队列消费速率可配置。实测中给每个代理设置了每秒最多处理5条消息的限速有效避免了高并发下上下文窗口被稀释的问题。3.4 一次完整协作的时序逻辑用文字复现假设用户发起一个需求为列表页增加批量导出功能。时序如下接入层把目标交给编排层编排层拆解任务图为四个子任务需求细化、技术方案、代码实现、测试设计编排层向需求代理发TASK_ASSIGN随后技术方案代理、代码代理、测试代理依次进入各自状态机各代理执行完毕后向编排层发TASK_REPORT编排层把四个子任务的产物汇总到协同层的评审区仲裁服务做一次交叉检查比如代码实现是否覆盖了全部需求点检查通过后向人类用户发APPROVAL_REQUEST用户确认任务合并入主线全程所有消息落审计库。这条流程里AI彼此之间从未直接对话它们只和编排层、仲裁服务、共享黑板交互。这就是代为交互的完整含义。4. 上下文与记忆管理多AI协同里最大的隐性坑4.1 上下文分裂每个AI都只看到了大象的一条腿这是我把原型推倒重来次数最多的地方。多AI协同环境里上下文不再属于某一个会话而是属于一个协作网络。如果每个代理带着完整的全部上下文Token成本扛不住如果每个代理只带自己的Prompt协作质量就会崩。我尝试过的第一种方案是全量上下文广播每个代理每轮都拿到所有其他代理的完整上下文。跑了几天Token账单告诉我这条路根本走不通——三个代理两百轮对话后单轮输入就已经超过了最先进模型的上下文窗口。第二种方案是最小上下文切割每个代理只带自己任务相关的那部分。结果协作质量崩了代码代理看不到需求变更的原因反复产出和产品逻辑不符的实现。最终落地的是第三种共享黑板私有工作区的双层上下文模型。4.2 共享黑板与私有工作区的读写规则共享黑板是协作网络的公共状态区只存放经过确认的结论。比如需求基线、决策记录、已通过评审的接口定义、争议清单。私有工作区是每个代理自己的推理空间存放过程草稿、临时方案、未定稿内容。这两个区域的读写规则是整个模型的关键私有工作区的东西可以随意写但永远不带入公共区域。只有通过仲裁或者人工审批的结论才允许被写入共享黑板。共享黑板的内容对全体代理可见但只读。修改必须走变更流程不能直接覆盖。提示共享黑板一定不能做成大家都能改。我早期就是没坚持住这条允许代理之间互相改黑板结论结果出现A写了结论B又改掉的互相覆盖事故。黑板必须是只读共识区新结论只能追加不能覆盖。这条规则的价值在于把过程信息和结论信息彻底分离。代理来读共享黑板拿到的一定是可信的、经过确认的结论来写私有工作区不会污染任何人的视野。实测效果非常明显有效Token占比从自由对话模式的不足10%提升到了接近60%。4.3 Token预算与摘要压缩策略即使有了双层上下文大项目的共享黑板还是会膨胀。我的应对策略是三层摘要机制第一层每轮摘要。代理每次交互结束后由代理层把本轮关键信息压缩成300字以内的结构化摘要。第二层任务摘要。子任务完成后把该任务下所有轮次摘要再压缩成一份任务级结论存入共享黑板。第三层会话摘要。整个协作会话的关键里程碑由编排层汇总成会话级快照存长期记忆库。新代理加入时只加载会话快照与自身相关的任务摘要不加载全量日志。我还给每个代理设了Token预算模型上下文窗口的70%用于加载共享黑板任务指令20%用于加载会话历史摘要10%留给工具返回结果。严格执行这条分配是我解决上下文窗口溢出最关键的操作。5. 异构模型接入云端大模型与本地小模型的混合调度5.1 为什么必须支持混合接入不是所有任务都适合丢给云端大模型。我在实际落地时遇到三类场景逼着我把本地模型接入做成了架构的标配。第一类是数据敏感场景。有些企业内部资料不允许出内网涉及这些数据的分析任务只能本地处理。第二类是成本与延迟场景。海量文本预处理、日志初筛这类脏活累活用云端大模型既贵又慢本地小模型虽然笨一点但胜在快和便宜。第三类是离线容灾场景。云端不可用时至少保证基础的协作链路还能运转哪怕用本地小模型扛着也比整个系统瘫痪强。5.2 适配层把每个模型变成可插拔的代理单元接入异构模型的核心是适配层。我给所有模型服务定义了统一接口入参固定为system_prompt, task_input, context_bundle, max_tokens, temperature出参固定为status, content, usage, model_name。任何模型——不管云端还是本地——只要实现这个接口就能注册成执行层的一个代理候选。输出校验是适配层最容易忽略但最重要的部分。云端大模型输出健壮性强本地小模型经常输出乱格式我在适配层加了多层兜底先跑一次JSON Schema校验不过就做正则修复再不过就自动带着错误信息重试一次最后兜底是把输出交给一个专门做格式清洗的小模型重写。这套兜底逻辑上线后本地模型的失败率从18%降到了3%以下。5.3 aarch64架构Linux环境部署代理网关的实测记录代理网关本身我用Node.js写的选择它是因为异步IO模型适合做消息转发而且生态丰富。但部署到aarch64架构的Linux服务器时还是踩了一些环境坑。首先是Node.js版本。系统自带的node往往太旧很多现代依赖包要求Node 18以上。我当时的处理很简单直接从Node官网下载linux-arm64版的二进制包解压使用不要用系统包管理器装老版本。步骤大概是uname -m 确认架构是aarch64。下载 node-v18.x.x-linux-arm64.tar.xz 到 /opt。tar -xf 解压把 bin 目录软链到 /usr/local/bin。node -v 验证版本。如果公司内网有安全限制记得把 npm registry 指向内网镜像源否则依赖安装会卡在超时上。提示在arm64环境下永远优先选择官方预编译二进制不要碰源码编译。一个node-gyp编译失败能消耗掉一整天而换一个带预编译包的依赖只需要两分钟。其次是原生依赖问题。有些包需要编译原生模块aarch64上的工具链不一定齐全遇到过 node-gyp 编译失败的情况。我的经验是优先选用有预编译二进制的包或者把构建镜像改成多架构支持的官方镜像不要在骨架上纠结自己编译。最后是内存和并发配置。代理网关单实例在实测中同时维持50个长连接时内存占用在300MB到500MB之间。我给网关的容器设置了1GB上限、每秒消息吞吐阈值超过阈值先排队而不是直接丢弃——消息丢了可以重发但上下文状态丢了很难恢复。5.4 路由策略什么任务去云端什么任务留本地路由决策我用了一张优先级表按顺序判断条件决策任务涉及敏感数据强制本地本地模型已负载饱和转云端任务需要深度推理或长文生成优先云端大模型任务属于结构化抽取、格式清洗、关键词提取优先本地小模型云端不可用降级本地这张表不是写在代码里的死规则而是做成可配置的策略运维人员可以按月度调。测试期间我把代码审查这个任务强制路由到云端结果发现本地模型在格式检查类审查项上准确率其实完全够用后来调整为结构审查走本地逻辑审查走云端成本降了三成。6. 多人协作中的人类角色监督者而非传话筒6.1 人工审批节点应该插在哪很多做多Agent系统的人容易走向另一个极端过于迷信AI自治什么都要AI自己拍板。我的经验是三个位置必须有人审批。第一方案级审批。技术方案、需求方案这种改错成本高的产物AI可以出草案但最终确认权在人。第二状态级审批。任务要从REVIEW进入MERGED时必须经过人工确认。这个节点防止了AI自认为做完了但其实没对齐的情况。第三争议仲裁。多个AI表决僵持不下时人类是最高仲裁者。审批节点不是越多越好太多人会累太少AI会放飞。结果类产物必审、过程类产物不审是我的原则。6.2 权限矩阵多用户多AI谁管谁多人协作场景下权限设计是整个系统能不能安全运行的地基。我给每个用户、每个代理定义了三个基础维度可见范围用户/代理能看到哪些会话、哪些黑板区域。操作权限谁能指派任务、谁能审批、谁能改写共享黑板。代理绑定关系用户只能操作自己名下的代理组不能直接命令别人的代理。举个例子项目经理能审批全部子任务的MERGED但代码代理只能操作分配给它的任务执行域测试代理可以读取共享黑板上的需求基线但不能修改它。这套矩阵我用一张权限配置表维护和消息信封里的校验逻辑联动——每次消息投递前先查权限没权限的直接丢弃并记审计。6.3 代理的暂停、回滚与重定向人类监督者需要三个急救按钮暂停代理、回滚任务状态、重定向目标。暂停按钮解决的是这个AI跑偏了先别让它继续干活回滚把任务状态机从某个后续状态退回到PENDING或DISPATCHED重定向则是当用户发现任务描述含糊时重新编辑任务目标并重新派发。这三个操作全都在代理层实现不接触AI模型本身。这也是代为交互架构的隐形福利因为AI引擎被代理包裹我们可以自由地做状态控制而不需要去命令一个AI别说话了——直接让它的代理下线即可。7. 一次完整协作流程的实测复盘7.1 从需求变更到测试回归的35分钟我用一套真实项目流程做了压测。场景某管理系统新增批量导入功能两个人类成员产品、开发组长、四个AI代理需求细化、技术方案、代码实现、测试设计。完整流程走下来耗时35分钟其中人工干预三次第一次是产品确认需求范围第二次是开发组长裁定技术选型冲突第三次是最终验收。其余时间里两个人类成员几乎没有主动搬运过任何信息所有跨AI的信息传递都是代理层完成的。最终产物包括一份需求基线、一份技术方案、289行实现代码、23条测试用例全部沉淀在共享黑板和审计库里。我把这次实测的数据和早期自由对话版原型做了对比Token消耗下降约67%上下文一致性问题归零因为结论只从黑板读排错时长从平均40分钟降到了8分钟——现在出问题直接按trace_id查消息链路几分钟就能定位。7.2 实测中踩过的五个坑与修复方案坑现象根因修复代理循环对话两个代理互发QUERY上百轮缺终止条件QUERY设置最大跳数超限转人工上下文窗口溢出大任务跑到一半报窗口超限Token预算未严格执行写进程定时强制压缩摘要权限越界代理B读到了代理A的私有草稿查询路由未查权限表所有QUERY先过权限校验本地模型格式错乱输出JSON频繁缺字段模型能力弱无兜底适配层加Schema校验重试链审批积压人类用户一次收到十几条审批审批粒度太细按结果类产物必审、过程类不审重新梳理这五个坑前三个在架构层面修的后两个是适配层和流程层的优化。整个排查过程给我的最大感受是多AI协同系统出问题很少是模型能力的问题绝大多数是消息链路、上下文状态和权限边界的问题。架构设计时把这三件事做扎实效果比换更强的模型明显得多。7.3 下一步想做的方向这套架构跑通后我脑子里还有三个待验证的方向。第一个方向是让编排层的任务拆解也变成可学习的不再用固定规则而是根据历史协作数据自动调整任务图的粒度——有些任务拆太碎了反而沟通成本高。第二个方向是跨组织的代理联邦。现在这套系统是单机构部署下一步想试多系统之间的代理互认协议让不同组织的AI代理通过统一的信任机制协作。第三个方向是让仲裁服务更有记性。现在VOTE只是简单表决下一步想在仲裁时参考每个代理的历史置信度——一个连续三次被人类驳回方案的代理它的表决权理应被降权。这个逻辑用加权表决就能实现但权重的学习规则还需要更多数据支撑。整套系统跑到现在我最想分享的个人体会其实就一句话我见过太多团队把多AI协同做成一堆Agent在聊天最终收获的不是生产力而是一堆上下文Token账单。代理代为交互这五个字本质上是把人类项目管理里最成熟的纪律——工单化、状态机、权限矩阵、审批节点——平移到了AI协作网络上。给AI之间立规矩比给AI更强的推理能力更能决定协作系统的上限。这个结论是我用将近三个月的原型迭代换来的希望对正在探索多AI协同方向的你有所启发。