去年我在公司内部搭一个“多AI协作原型”时踩了一个特别大的坑把任务拆成几步、分别丢给几个不同的聊天机器人去跑结果每个模型各答各的既看不到别人已经结论也不记得上下文里的约束条件最后我不得不人工把几份回答拼在一起。那会儿我才意识到真正要做的不是“同时调用多个AI”而是把“AI代理人”本身当成系统的一等公民设计出一套让多个代理能通过消息机制相互代传、协同分派的架构。这也是本文想聊的核心题目——基于AI代理代为交互的多人多AI协同系统架构研究。文章里没有太多玄学重点是把系统分层、消息拓扑、代理注册路由、状态同步、任务编排和性能取舍讲清楚适合正在做多代理工作台、企业级AI助手聚合层、或者想给自己的AI Agents集群搭骨架的同学参考。1. 为什么单代理撑不起“多人多AI”这件事一个发布会案例把问题全暴露了1.1 发布会筹备案例里的三类协作诉求假设一个市场团队要筹备一场新品发布会参与的人有策划、设计、开发和运营。传统AI助手模式下每个人各自打开一个聊天窗口问自己那个AI得到的答案互相同步靠人肉复制粘贴效率极低。换一种设想系统里有“设计代理”“开发代理”“运营代理”三个专业AI外加一个“主调度代理”人在网页端像拉群一样把这三个代理拉进同一个会话。在这个会话里设计代理先产出一版主视觉概念开发代理根据设计稿给出前端实现的可行性评估运营代理再把排期和投放渠道建议贴上去。三个代理之间需要互相读懂对方产出的结构还要能围绕同一份“发布会筹备计划表”做增量修改。与此同时人类成员不是旁观者——策划要随时对某个方案拍板并在关键节点插入自己的意见。这套流程背后涉及三类协作诉求多人之间的协作各岗位人类通过同一套系统共享目标、追踪进度。人与多AI之间的协作人负责定方向、做裁决AI负责分头执行和提供专业建议。AI代理之间的协作代理需要理解彼此的输出结构并按任务依赖关系接力或并行完成工作。如果只做“每人对一个AI”第二类和第三类诉求基本落空。这也是标题里强调“AI代理代为交互”的核心含义——人与专业代理之间隔着一个调度层由代理替人去分派、汇总、确认而不是让所有AI直接暴露给人。1.2 “代为交互”到底代的是什么“代为交互”这个词我第一次看到时也觉得绕拆开其实很简单。用户不直接跟某个专业AI聊天而是把目标告诉主代理主代理解析意图后把子任务分派给对应专业代理专业代理处理完后把结果交回主代理主代理汇总、校对、整理后再反馈给人。整个过程像公司里秘书替老板去跟各部门沟通老板不会自己跑遍所有部门秘书负责传达、催办、汇总。这个模式带来的第一个好处是交互入口收敛。人只需要面对一个会话窗口不用记住哪个问题该找哪个AI。第二个好处是任务链路可追踪。分派记录、代理间往来的每条消息都在系统里留存出了问题能回放。第三个好处是负载可路由。主调度代理可以根据各专业代理的繁忙程度、历史成功率和上下文适配度选择最合适的接单方而不是写死调用某一个模型。1.3 这个架构研究要解决的三个核心问题把上面的场景抽象一下做多人多AI协同系统架构本质上要解决三个层次的问题连通层代理之间如何通信消息怎么定址是点对点直连还是走消息中枢组织层代理怎么注册自己的能力一个会话里的消息如何路由到正确的代理多个代理各说各话时听谁的状态层所有代理共享哪份事实上下文怎么保存代理并发修改同一份文档时怎么避免互相覆盖这三个问题正好对应本文后续的几个章节。如果只想跑通一个Demo连通层随便用HTTP轮询都能撑住但要做到“多人多AI”真正协同工作组织层和状态层的设计才是成败关键。我见过不少项目死在第三步——代理们都接上了消息也能互发但因为没有共享上下文和冲突处理机制跑几轮就开始自相矛盾。2. 消息骨架怎么搭点对点直连会先崩总线加队列才是底座2.1 多代理互通的拓扑困境很多第一次设计多人多AI系统的人第一反应是给每个代理配一套HTTP接口A代理要问B代理就直接调B的API。这个方案在有2到3个代理时确实简单但代理数量稍微涨起来就会很痛苦。假设系统里有5个专业代理两两之间都要通信链路数是 C(5,2)10 条加到10个代理就是45条。每条链路都得维护地址、鉴权、重试策略、超时配置每加一个新代理都要去通知所有老代理“我上线了”。更麻烦的是代理之间点对点调用天然形成网状依赖编排逻辑散落在各代理内部外部根本看不清一条任务到底经过了哪些环节。这在系统架构上是最典型的“连接爆炸”问题早期原型看不出来一上生产就成运维噩梦。解决方案是引入消息中枢。所有代理只跟中枢通信不直接互相感知对方的存在。发布者把消息丢给中枢订阅者从中枢拿消息连接数从 N×(N-1)/2 直接降到 N。这正是网络工程里“交换机架构”的思路——交换机不关心帧内容只按转发表把帧投递到对应端口。消息中枢也一样不解析业务逻辑只负责两点知道谁订阅了什么事件把消息高效转达。2.2 事件总线与命令队列的分工消息中枢也不是一个东西就能全包实际工程里要区分两种语义完全不同的通道。一种叫事件总线它的语义是“发生了某事但不指定谁去处理”。比如“发布会日期改了”这条事件设计代理、运营代理、开发代理都应该感知到各自去调整自己的计划。事件总线天然适合广播适合状态同步和通知类消息。另一种叫命令队列它的语义是“这个任务必须被某个代理处理掉”。比如“请生成一版主视觉概念”这条命令只能被设计代理消费不能广播给所有人。命令队列天然适合任务分派适合点对点的异步调度和负载均衡。两者的差异决定了消息的投递方式、确认机制和重试策略。用错语义是常见坑把命令广播出去所有代理都会去生成主视觉然后处理碰撞、幂等、重复消费的问题会把人逼疯。反过来把事件点对点投递又会导致事件消费者不明确新增代理后它永远收不到本该感知的变化。2.3 借鉴ROS的topic/service/action分层设计我第一次看到标题里那串热词里混着一个“openclawros”第一反应是机器人领域的朋友也在关注多代理协同因为ROS的通信机制跟多人多AI协同的通信需求高度相似。ROS里分了三种通信原语topic用于持续发布数据流service用于短促的请求响应action用于长时间运行的任务跟踪。映射到多AI协同系统里这几乎是现成的设计纲领topic对应事件流——代理状态的变更、会话中新增的消息、任务进度的里程碑都通过topic广播。service对应同步查询——主调度代理需要立刻知道“设计代理当前是否可用、正在做几个任务”一次调用拿一个结果。action对应异步长任务——分派给设计代理的“生成三版主视觉方向”显然不是秒回的操作代理先ack“接单”然后持续上报进度最后回报结果或失败原因。这套三原语的分层要比统一用“消息队列”更精细。很多人搭多AI系统时只考虑“把消息发出去”完全没区分消息是“通知”还是“任务”。结果就是同一个通道里既跑状态心跳又跑重计算任务互相挤压优先级队列一堵全链路超时。2.4 消息中枢技术选型参考热词里出现了好几次“分布式交换机系统架构”我理解它强调的就是消息转发层绝不能成为单点瓶颈。实际选型需要结合代理数量、消息体大小、吞吐量要求来定。直接给一张我在项目中做过的对比表组件适合规模投递语义主要优势主要限制Redis Streams几十个代理以内至少一次部署简单、延迟极低、自带过期管理消息量过大时内存吃紧持久化较弱NATS JetStream百个代理以内至少一次/精确一次可选轻量、云原生友好、支持请求响应模式高级管理功能弱于KafkaRabbitMQ百到千个代理至少一次手动确认路由规则丰富、管理界面成熟可靠高吞吐场景性能弱于Kafka配置略重Kafka大规模事件流至少一次/精确一次超高吞吐、可重放、持久化强运维成本高topic数量多时内存开销大我的建议是企业内部原型的多人多AI协同先用Redis Streams把链路跑通因为它足够轻改起来快。真正要上生产、有几百个代理高频交互且需要审计回放时再切到Kafka用Kafka承担事件总线的角色配合Redis做低延迟命令队列。系统架构早期最重要的不是选最强的组件而是把消息语义和代理接入协议定义清楚组件随时可以替换。3. 代理怎么接入、注册和路由先让系统搞清楚“谁在说话”3.1 代理注册协议与能力描述消息中枢搭好以后下一个问题就是一个新代理进来系统怎么知道它能干什么怎么知道哪个会话该找它这就是代理注册的活。我建议给每个代理设计一份能力描述文件注册时上报给中枢。字段不需要太复杂关键是让路由层能做决策。一个典型例子{ agent_id: design-agent-01, name: 设计代理-主视觉, capabilities: [视觉概念生成, 海报排版, 品牌一致性检查], models: [本地多模态v3, cloud-image-gen], preferred_session_types: [发布会筹备, 品牌VI], load_threshold: 5, status_endpoint: ws://agent-host:9002/status }这里的capabilities是硬标签路由层靠它做粗筛load_threshold是代理自己声明的最大并行任务数status_endpoint让调度层可以实时拉取代理的健康状态避免把任务分给已经挂了或正在满负荷跑的代理。注册过程可以做成动态的代理启动时向中枢发起注册请求每隔几秒上报一次心跳。心跳超时就自动标记为offline不再参与路由。这个机制在机器人分布式系统里很成熟搬到多AI协同里一样管用。我见过有人把代理列表写死在配置文件里新加一个代理要重启整套系统这种做法在原型期还能忍代理数量一多必然出事。3.2 会话路由三要素与动态权重注册解决的是“系统里有哪些代理”路由解决的是“一条消息该交给谁”。多人多AI协同场景下我认为消息路由必须基于三个要素组合判断会话归属当前消息属于哪个sessionsession对应的参与角色有哪些。比如发布会筹备会话参与者是设计、开发、运营三个角色那路由范围就被限制在这三个代理类型提示后的实例里。能力匹配消息经过意图识别后挂上任务类型标签比如“生成视觉概念”对应“视觉概念生成”这个capability。负载状态多个代理具备同一能力时优先选当前空闲的。这里有几种策略——最简单的是轮询进阶的是看历史响应质量比如过去24小时该代理产出被用户采纳的比例。路由决策不该放进每个代理内部也不该用硬编码的if-else写完就再也不动。我比较推荐按权重分层先按能力过滤出候选集再按负载和信誉分加权排序。这样可以做到“能力优先负载次之信誉兜底”随时能人工调整权重系数来改变调度倾向。3.3 本地模型接入的统一化处理热词“ai代理助手加本地模型”也指向一个现实问题很多团队想跑本地模型来降低成本和数据外溢风险但是本地模型和云端模型的接入方式完全不同——云端是HTTP API本地可能是Ollama的localhost也可能是llama.cpp的启动参数还有的是ROS节点那样持续输出的模型服务。在多代理架构里我们不能让上层路由兼容每一个模型后端的差异。正确做法是做一个代理网关层给每个本地模型加一个薄薄的适配器统一暴露成全系统标准的代理协议接口。适配器负责把内部推理结果翻译成标准消息格式再按capability标签挂载到代理注册表里。这样设计有个很实用的好处代理实例可以随时在本地模型和云端模型之间切换。测试时用本地小模型跑链路上线高精度任务时换成云端大模型上层路由根本无感知。真正做到了“模型和代理解耦”——模型是引擎代理是带能力的服务身份两者不该被绑死。3.4 一个注册与路由的骨架代码下面是一段很简化的Python骨架展示了代理注册、能力过滤、负载加权三件事如何配合class AgentRegistry: def __init__(self): self.agents {} def register(self, agent_info: dict): agent_info[last_heartbeat] time.time() self.agents[agent_info[agent_id]] agent_info def route_candidates(self, task_label: str, session_type: str): candidates [] for agent_id, info in self.agents.items(): if task_label not in info[capabilities]: continue if session_type not in info[preferred_session_types]: continue candidates.append((agent_id, self._weight(info))) candidates.sort(keylambda x: x[1], reverseTrue) return candidates def _weight(self, info): load_score max(0, 1 - info.get(current_load, 0) / info[load_threshold]) health_score 0.5 if time.time() - info[last_heartbeat] 10 else 0 return 0.6 * load_score 0.4 * health_score实际生产会比这复杂但核心思想就是候选集靠硬条件过滤排序靠软指标打分。硬条件错了会分配错任务软指标错了只是效率降低所以先保证硬过滤准确再慢慢调算法权重。4. 任务编排与跨代理仲裁多个AI意见不一致时谁来拍板4.1 四种编排模式及使用时机代理接入了路由也有了接下来就是最关键的编排。编排不是把任务一股脑丢给代理就完事而是要设计任务的执行拓扑。常见的多代理执行模式有四种。顺序链式A完成以后把结果交给BB基于A的输出继续处理。典型场景是“设计稿→开发评估→运营排期”后一个代理必须以前一个代理的输出为输入。这种模式简单可靠但总耗时为各环节之和。并行扇出一个任务拆分成多个独立子任务分给不同代理同时执行最后汇聚结果。典型场景是“用三个不同模型各自给一份活动方案”然后汇聚比较。这种模式延迟最低但需要处理结果汇合时的格式不一致。编排者—工作者主代理负责任务拆分、分派、校验、聚合工作者代理只负责执行单一子任务。这是整个系统最推荐的模式因为控制逻辑集中在编排者一处方便加监控和人工介入。黑板模式所有代理共享一块“工作区”各自把产出物贴上去其他代理基于工作区当前内容继续加工。适合多人多AI围绕同一份文档/方案反复迭代的场景但需要额外的冲突控制设计。实际项目中一套完整流程很少只用一种模式。发布会筹备就是混合案例先并行扇出“让三个模型各自给一版主视觉方向”然后人工/仲裁选定一个方向再顺序链式“设计→开发→运营”期间所有进展同步到黑板共享区。4.2 仲裁策略多数决、专家优先、人工裁决多个AI给出不一致结果这是协同系统绕不开的坎。我发现很多团队在这一步犯一个认知错误幻想某个模型永远是对的然后给该模型最高权重。现实是不同模型在不同任务上各有擅长一成不变的硬优先级并不可靠。我的建议是仲裁策略要与任务类型绑定。如果任务是结构化分类比如给用户评论打情感标签可以通过多数决或加权投票——三个模型两票以上一致就采信。如果任务类型是创造性设计比如主视觉方向多数决没意义这时候要看角色权威度——人类策划当初指定“主视觉由设计代理主导”那设计代理的意见就应拥有更高决策权重。如果任务涉及金钱、排期、对外承诺等高风险事项任何模型都不该独断必须进入人工裁决流程。每次仲裁都应该沉淀一条“仲裁记录”内容包括输入、各代理输出、仲裁策略、最终结论。这条记录既是制造一致性的证据链也是后续复盘模型能力的素材。我自己用下来最大的体会是没有仲裁记录的多AI系统跑半年后你根本不知道哪个模型在哪些场景下更可靠只能凭感觉调权重非常虚。4.3 任务状态机与human-in-the-loop设计多代理协同的任务不能像传统后端请求那样只有“成功”“失败”两个终态。中间必须有足够的状态位让调度层和人类都能感知任务走到哪一步。我常用这套状态迁移状态含义可流转到pending任务已创建等待调度dispatcheddispatched已分派给代理等待确认running, rejectedrunning代理执行中周期上报进度waiting_approval, completed, failedwaiting_approval已产出结果等待人类裁决approved, rejected, reworkcompleted已确认完成-failed执行失败带原因pending(重试), rejected这个状态机里最重要的设计就是waiting_approval——它天然实现了human-in-the-loop。代理可以包办90%的常规工作但在高风险节点上走到“等待审批”就停下等人类在界面里看到汇总简报后点击“通过”或“返工”。这个状态让系统既保持了AI的高效率又留住了人的最终决策权避免全自动跑飞。5. 上下文共享与状态一致性多代理最容易翻车的地方5.1 为什么多个AI会“各说各话”我见过很多多AI项目跑起来以后最大的问题不是技术链路而是代理之间的记忆是割裂的。每个模型对话窗口自带上下文但这个上下文默认只属于当前那个会话。设计代理产出了“主视觉用深空蓝渐变”结果开发代理后续根本不知道这个结论自己重新定了一个“科技紫渐变”。设计代理问“你为什么不按主视觉走”开发代理说“没人告诉过我啊”。这个问题的本质是模型输入里缺少共享事实。每个代理在生成回复时只看到了自己最近几轮对话没有看到整个会话空间里其他代理写下的关键决议。解决思路不是让模型自己“记性好一点”而是在架构层面强制注入共享上下文。5.2 共享上下文仓库与命名空间设计我的做法是建一个共享上下文仓库所有代理在生成回复前必须从仓库里拉取当前会话的“事实快照”。快照包括会话目标、已定决策、关键约束、各代理最近一次输出摘要。这个仓库可以按会话维度组织每个会话下按命名空间隔离不同代理的私有工作区session:{id}:facts—— 全局事实表所有代理可读仅限调度层写入。session:{id}:agents:{agent_id}—— 代理私有工作区只有对应代理可写。session:{id}:public—— 公共工作区所有代理可写可读用版本号解决冲突。在实现上Redis Hash 或 PostgreSQL JSONB 都可以承载这套结构。代理在每次被调用时上下文构建器先读facts和public区糅合成一段“当前会话状态摘要”再把它拼进模型输入。这样即使代理本身是零记忆的按需模型也能站在全局视角产出结果。5.3 写冲突与权限隔离乐观锁是底线共享仓库一旦支持多个代理并发写入就会遇到经典的并发冲突问题。两个代理同时修改发布会排期表后写的覆盖先写的前期工作全部白费。应对办法很简单但必须做所有公共区域的写操作都带版本号使用乐观锁。代理在写入前先读出当前版本号写入时带条件更新——如果版本号已经变了说明有人抢先改了内容写请求直接失败代理需要重新拉取最新状态再决策。虽然这会让少量写操作需要重试但在多AI协同场景里它比悲观锁好得多因为没有全局阻塞不会出现一个代理长时间占着锁导致其他代理排队卡死。更重要的一层是领域写权限隔离。给每个代理按角色规划可写字段运营代理只能改排期和预算开发代理只能改技术方案字段设计代理只能改视觉字段。权限隔离能砍掉80%的冲突来源——很多时候冲突不是“并发写同一行数据”而是“越权写本来不该自己碰的字段”。5.4 事件溯源保留完整交互链路最后多AI协同里经常被忽略的是审计与回放能力。这个系统里信息在多个代理间流转最终结论往往需要回溯“它到底是怎么得出来的”。如果只存最终状态出问题后无从定位责任和推理依据。我建议采用**事件溯源Event Sourcing**的思路不覆盖历史记录而是把所有代理交互写成append-only事件流。每条事件至少包含session_id、触发代理、目标代理、消息类型、负载内容、时间戳。代理每次生成的完整回复、每次裁决记录、每次上下文快照都作为事件追加存储。需要重建某个时间点的事件时把事件流按时间顺序重放到那一刻即可。这套设计带来的额外好处是可重放训练数据——系统沉淀的大量代理交互记录本身就是微调专业代理模型的黄金语料。不过要注意事件表增长很快需要按时间做归档和压缩定期把旧事件汇总成摘要只保留摘要指向的原始事件存储位置。6. 性能瓶颈在哪显存、上下文长度和本地模型混编的取舍6.1 时间开销到底花在哪多人多AI系统看起来复杂但压测后你会发现瓶颈基本集中在模型推理端。我搭过一版全链路的监控记录从用户发消息到最终回复的所有环节耗时结论非常清晰环节耗时占比说明模型推理60%-75%本地模型和云端API均在推理阶段消耗最多时间上下文构建5%-10%需要读取共享仓库并拼装快照优化后占比不高代理间网络传输5%-8%内网或云上消息中枢延迟工程化后很低排队等待5%-15%代理被前序任务占用或触发限流等待人审环节依赖流程这是产品设计时无法完全消除的等待成本模型推理的时间占比决定了优化策略的第一优先级。架构设计得再好如果上下文越拼越长推理延迟就会指数级恶化。实际压测中同样一个本地模型上下文从4千字符涨到2万字符单次推理耗时大约会翻两倍以上所以我强烈建议在上下文构建器里做裁剪摘要把旧事件摘要化只保留与本任务强相关的事实而不是把整个历史全部塞进提示词。6.2 本地模型与云端模型混编的路由降级策略热词里“ai代理助手加本地模型”背后其实是一种很典型的混合部署诉求能本地跑就本地跑敏感数据不出内网模型能力不够时再临时切云端。我的实践方案是给每个代理配置模型等级和降级链路。常规请求走本地模型速度快、成本低当任务复杂度或上下文长度超过阈值时自动升级云端模型云端模型也不可用时降级回本地模型并附上“当前结果置信度降低”的提醒。这个设计有两个技术细节要注意。第一切换必须对上层透明代理身份不变变的只是内部推理引擎路由层不需要感知。第二切换决策必须在任务开始前完成不能在模型运行到一半时换引擎否则状态无法衔接。可以在注册协议里带上模型能力描述让调度层根据任务标签、上下文长度、已有快速模型容量综合判断走哪条推理路径。6.3 限流、批处理与资源隔离多代理并发调用模型时本地GPU显存和云端API配额都有限不做限流一定会被打爆。热词里提到的“linux系统iommu软件架构分析”其核心思想是讲DMA资源隔离——大流量设备通过IOMMU被限制在特定内存区域避免越界访问。多AI系统里的资源隔离思路完全一致让每个代理或会话占用固定的显存/API额度谁也不能超量占用拖垮整体。具体做法有三个信号量限流给每个模型引擎配一个并发槽位计数超过N个并发请求就直接排队而不是把请求打给已过载的模型。请求合并同会话内多个代理都要读取同一事实快照时在上下文构建器层做缓存和合并避免重复查询。队列背压消息中枢到代理之间的消费队列要支持动态调节消费速率代理负载过高时自动降低拉取频率配合拒绝和重试机制保护整体稳定性。我把这些内容统称为“让每个代理都有呼吸空间”。系统空闲时它们可以尽情协同高负载时段宁可让某些任务排队也不要让所有代理在OOM和超时中反复挣扎。7. 从零搭一个最小骨架模块划分、请求流和扩展方向7.1 最小骨架的模块划分讲了这么多架构设计最终都要落到能跑的代码上。我给一套最小骨架的建议目录结构适合快速验证上面的理念multi-agent-core/ ├── agents/ # 各专业代理适配器 │ ├── base.py # 统一代理接口 │ ├── design_agent.py │ ├── dev_agent.py │ └── ops_agent.py ├── gateway/ # 代理接入网关统一暴露协议 ├── registry/ # 代理注册表 心跳 ├── router/ # 路由决策器 ├── orchestrator/ # 编排器任务拆分、状态机 ├── context_store/ # 共享上下文仓库 ├── event_store/ # 事件溯源存储 ├── arbiter/ # 仲裁策略 └── web/ # 人机交互界面会话、审批这套目录没有引入太重的框架每个模块都是一份独立职责。对于几十个代理规模的内部系统这个粒度已经足够新增一种专业代理核心是写一个agent适配器并在registry里注册其他模块几乎不用改。7.2 一条请求的完整流转链路从用户发消息到最终收到回复完整链路我描述一遍方便对照目录结构去读代码用户在Web端输入“帮我们规划发布会主视觉的三个方向”消息进入编排器。编排器做意图识别拆解出子任务“生成三个主视觉方向”并在上下文仓库建立session记录。路由决策器查询注册表按能力过滤出3个具备视觉生成能力的候选代理按负载权重排序选定当前最空闲的一个。编排器把任务分发给该代理代理接单后从上下文构建器拿到共享快照开始本地模型推理。代理产出三个方向后上报结果并进入waiting_approval状态。用户在Web端看到结果选择其中一个或让代理返工重做。仲裁器记录本次决策事件存储追加完整链路事件。与此同时运营代理和开发代理的上下文快照里自动包含“主视觉方向已定”这条新事实。整条链路下来用户感知只有一个会话背后却是消息中枢、注册表、路由、编排、共享仓库、仲裁、事件存储七个模块协同工作。这也是为什么说架构设计决定系统能力的上限——不是一个模型够不够聪明而是整个协同系统的结构能不能承载多人多AI的信息流转。7.3 后续可以往哪些方向扩展最小骨架跑通以后扩展方向基本是沿着三个维度走。一是多模态协同现在多数代理只处理文本后续可以把图像生成、语音识别、视频理解作为新的代理能力类型接入注册协议里扩展能力枚举就行。二是自适应路由基于仲裁记录和用户采纳率让路由权重能自动学习动态调整不同模型在不同任务上的派单偏好。三是可观测性基建把事件存储里的事件序列做可视化按session回放整个代理链路。对排障的价值极大对非技术背景的运营同事也更容易理解“为什么AI做了这个决定”。我自己实际维护这套系统半年来的体会是多AI协同真正的复杂度不在模型而在系统结构。模型能力可以迭代架构的通信语义、状态一致性、人工介入机制才是最需要花心思的骨架。先把骨架立稳再谈模型越换越强方向才不会跑偏。