1. 为什么是代理代为交互而不是把 AI 们直接连起来1.1 多人多AI协同场景里真正需要协同的是谁最近我在帮团队搭一套多人多AI协同系统起因是产品组每天开完会都会产生一堆散落在各人手里的任务摘要。五个人五台电脑每个人都在用AI助手有人让AI整理用户反馈有人让AI画流程图有人让AI写PRD初稿。听起来效率很高但对齐的时候发现全乱了——A的AI不知道B的AI已经修改过需求背景C的AI生成了一份和D完全矛盾的排期说明。最后大家不得不回到会议室逐段核对哪些是人话哪些是AI各自编出来的。问题出在哪不是某个AI不够聪明而是交互的主体从一开始就错了。每个用户直接跟自己的AI对话AI和AI之间没有任何共同的会话上下文没有消息通道也没有责任边界。真正的协同不是人和AI的聊天而是AI代理之间的协作需要一个明确的机制来管理谁在替谁说话、谁在执行哪部分任务、结果如何汇聚。这也是基于AI代理代为交互的多人多AI协同系统架构这个方向要解决的核心问题。我一开始也天真地以为多人多AI协同不过就是给每个用户配一个AI然后在后端把它们连起来。实际跑过一遍之后才发现这里的系统架构难点比想象的复杂得多。难点不在于某个模型有多强而在于多个用户、多个AI代理、多个任务流同时存在时系统能不能保证它们在一套统一的规则下交互。代理不是聊天机器人它是代表某个用户、某个角色、某个目标参与协作的执行体。如果把交互的对象从人和模型换成代理和代理架构上的很多矛盾就会重新浮现比如状态一致、消息路由、权限控制、失败恢复。所以我决定把整套系统按代理代为交互来设计而不是让模型彼此裸连。1.2 如果让多个AI直接互相调用会出什么乱子最诱人的方案是让AI直接互相调用Agent A把结果传给Agent BB再传给C仿佛一条流水线。我最初的原型就是这么写的用同步HTTP请求让两个模型互聊。结果只跑了十分钟就放弃了。第一模型之间的调用没有天然的终止条件。两个大模型你来我往非常容易陷入我再补充一点我觉得这个问题需要澄清的死循环prompt越滚越长token消耗成指数上涨最后直接卡在上下文上限。第二责任边界彻底消失。任务失败时你不知道是A给B的指令有歧义还是B理解错了A的返回结构。没有调用链记录连日志都难以串起来。第三权限不受控。当AI具备调用工具、读写文件、访问数据源的能力之后让它们随便互相调等于给每个模型发了一张无审计的万能通行证。前阵子我看到有人把AI代理接到ROS上做机器人协同也有人在做OpenClaw这类代理框架思路都是从模型聊天走向代理执行。但一旦代理开始替人做决策、调工具就必须有一个中间层来统一协议、做鉴权、记录全过程。这就是代理代为交互里那个代字的真正含义代理替人和替AI完成交互同时把底层模型不可控的部分关在笼子里。多AI直接互调看起来像是去中心化的民主实际上没有边界和约束的互调很快会退化成消息风暴。1.3 代为交互不是做个转发网关还需要澄清一个常见误解代理代为交互不等于消息转发。如果只是把A的输入原封不动传给B那和直连没有任何区别反而多了一层开销。代理层的核心价值是理解意图、拆解任务、评估结果。举个具体例子用户对用户代理说把昨天会议里提到的风险点整理成待办列表。用户代理要做的不只是把这句话转发给某个任务代理它必须先判断这句话里隐含的需求是什么需要调用会议纪要解析代理还是先用检索组件从知识库里召回昨天那份纪要召回之后会议纪要有三页长里面可能混杂讨论过程和最终结论任务代理需要提取出明确的风险项。最后用户代理还要对返回的待办列表做质量校验比如有没有遗漏日期、风险等级是否被夸大。这些步骤都发生在代理交互的过程中而不是发生在模型推理里。如果代理层只是转发上述任何一个环节出现偏差都无人处理。代理还是一个有身份、有寿命、有状态的实体。它知道自己的角色知道当前会话的目标知道已经完成和正在执行的任务。正因为有状态、有身份它才有资格成为用户在协同系统中的代表。如果设计成无状态转发服务那代理就名存实亡了。2. 架构全景接入层、代理层、能力层以及每层的职责边界2.1 三层加一条总线的整体布局抛开具体技术栈这套系统架构可以清晰分成三层接入层、代理层、能力层。三层之间用一条异步消息总线解耦避免模块之间形成蜘蛛网式的强依赖。接入层解决人怎么进来的问题。它可以是Web页面、企业IM机器人、语音入口也可以是某个机器人网关。接入层不做业务判断它只负责四件事用户身份认证、把用户输入标准化成指令、把代理返回结果渲染给用户、处理连接中断等传输层异常。接入层不应该直接访问模型API否则很容易让业务逻辑泄漏到UI层。代理层是系统的核心。它内部包含协调器、用户代理、任务代理三类角色。用户代理是每个用户的化身持有用户的目标、偏好和授权范围任务代理按领域划分比如文档协作、代码生成、数据分析各一个协调器负责建立会话、维护成员列表、做最粗粒度的路由。代理层不依赖具体的模型厂商它只面向统一的消息协议编程。能力层是真正干活的底层包括模型API、工具执行器、知识库、外部系统适配器等。能力层可以被随时替换今天用闭源大模型明天换成本地部署的开源模型后天再把某个内部系统接入进来都应该只影响能力层内部不会波及代理层和接入层。我用一个表总结各层职责层核心组件主要职责不应该做的事接入层Web端、对话网关用户接入、指令标准化、结果展示不做意图拆解和任务编排代理层协调器、用户代理、任务代理会话管理、任务编排、结果仲裁、权限校验不绑定某个具体模型API能力层模型API、工具、知识库执行推理、调用外部系统、检索信息不做跨代理通信和业务决策消息总线事件队列、路由表、注册表异步传递消息、保存全链路轨迹不解析业务语义只负责投递这个分层的设计原则是上层依赖下层的抽象能力下层不知道上层的具体用户是谁。代理层只通过标准消息总线访问能力层能力层的改变被限制在适配器内部。2.2 代理协调器为什么必须无状态代理层里最早写的是协调器当时我顺手把它做成有状态服务保存了每个会话的消息记录。结果测试时发现一旦协调器实例重启所有正在进行的协作任务全部断掉用户代理根本不知道下一步该发给谁。后来我重新设计把协调器彻底改成无状态所有会话信息、参与者列表、消息路由关系都放到外部存储里协调器实例只负责转发。无状态带来了两个直接好处。第一可以水平扩展。用户从几十涨到几万协调器只需要多部署几个实例前面加一层负载均衡不需要迁移任何本地状态。第二故障恢复非常快。协调器进程挂了新实例启动后从Redis或数据库里读回路由信息用户代理续跑即可。协调器本身的逻辑可以做得非常薄只做四件事校验权限、生成全局唯一的trace_id、记录消息路由、把消息投递到对应主题。真正的协商业逻辑放在用户代理和任务代理里。有人会问协调器无状态那会话状态放哪放到外部存储。注意外部存储只保存会话元数据比如参与者列表、当前阶段、上下文指针而不是保存模型生成的每一条原始消息。原始消息放在消息总线的轨迹存储里按trace_id归档。这样协调器即使重启也能基于元数据快速重建协作现场。2.3 代理角色拆分的粒度太粗和太细都会出问题代理粒度的设计直接影响整个系统能不能长期维护。我早期犯过一个典型的错误只做一个万能任务代理把它当成一个超级Agent用户代理的所有请求都发给它。这个万能代理里的prompt很快膨胀到两三千行既要处理文档又要分析数据又要写代码改一处逻辑要重新测试全部场景。后来改为一个领域一个代理又发现消息在十几个代理之间跳来跳去一个很简单的任务要经历三轮互相调用时延翻了五倍。目前我比较推荐的做法是用户代理始终一个任务代理按业务领域划分而不是按工具粒度划分。比如文档协作、代码生成、数据分析各是一个任务代理。每个任务代理内部可以调用多个工具但它对外暴露的是统一的领域能力。判断粒度是否合适的简单标准是任务代理之间会不会经常互相调用如果A代理有30%的请求都要转给B代理那说明A和B的业务边界没有切干净应该合并。反过来如果一个任务代理内部prompt超过两三千行或者一个请求要处理多个不相干的领域就该拆。在架构研究中代理角色拆分本质上是在职责内聚和消息开销之间取平衡。同一个领域的逻辑放在一个代理里状态容易共享跨领域的交互通过消息总线走链路清晰。但这个平衡不是一成不变的随着业务演化要重新调整。3. 代理之间的消息流转从任务下发到结果回传的完整链路3.1 消息类型与结构设计代理之间不能靠传一大堆自然语言文本来交流必须定义结构化消息协议。我在实践里用的协议包含五种消息类型请求request、响应response、事件event、订阅subscribe、取消cancel。请求是发起一个任务的唯一方式响应是返回任务执行结果事件用于主动通知状态变化比如文档已被修改数据源更新了订阅表达一个代理想持续关注某个主题取消用于终止一个正在执行的任务。每条消息的头部结构尽量精简但有一个字段绝对不能少就是trace_id。一次用户请求可能跨多个代理、多次投递没有trace_id排查链路的成本会高到不可接受。下面是一段消息JSON示例{ message_id: msg_7f3a2c1e, trace_id: trace_f0e4b1a2, sender_id: user_agent_alice, receiver_id: doc_task_agent, conversation_id: conv_20250110_001, message_type: request, payload: { action: summarize_risks, context_ref: [mem_meeting_yesterday, doc_okr_q4], output_format: todo_list }, expire_at: 2025-01-10T12:00:00Z }payload里不直接塞会议纪要全文而是用context_ref指向共享上下文库中的条目。这样消息体小巧也避免上下文副本膨胀。expire_at字段在早期也是被我忽略的后来发现任务代理长时间无响应会让整个流程卡死于是给每条请求都加了超时时间超时后由协调器自动做重试或升级人工处理。3.2 异步消息总线 vs 同步RPC模型推理的时延通常在两秒到三十秒之间协同任务还会涉及多个代理串行或并行调用。如果采用同步RPC一个用户请求会一直占着连接中间任何一个AI卡住整个请求就跟着卡住客户端连接池很容易被打满。所以我在架构里选择了异步消息总线。异步总线解决了三个问题第一削峰。瞬时出现大量任务时消息队列能缓冲不会把下游模型API瞬间打爆。第二重试。消息投递失败或者代理执行超时可以放入延迟队列重新消费。第三并行。用户代理可以同时向多个任务代理发出request各干各的不用串行等待。但异步也带来体验问题用户不再像即时聊天那样立刻收到结果而是先收到已受理再收到进度事件。我的解决办法是在用户代理里做进度事件聚合每收到一个子任务完成事件就向客户端推送一条简短的进度信息。用户看到会议纪要解析完成正在生成待办感知上系统一直在动而不是卡死。一个比较反直觉的经验是不要试图让异步系统看起来像同步而是把异步过程本身变成产品体验的一部分。3.3 一个从用户请求到多代理协作的完整链路用一个完整例子把所有概念串起来。假设用户说把昨天的会议纪要和本周OKR合并成一份周报。链路是接入层收到文本询问会话服务得到conversation_id把消息投递到协调器的输入队列。协调器校验用户权限生成新的trace_id将消息路由给该会话对应的用户代理。用户代理分析意图。它识别出昨天的会议纪要和本周OKR是两个数据源合并成周报是目标。因此它决定并行调用两个能力会议纪要检索和OKR查询。用户代理发出两条request一条发给检索引擎代理一条发给OKR数据代理。两者都通过消息总线并行处理。检索引擎代理返回一份会议纪要的context_refOKR数据代理返回结构化OKR列表。用户代理拿到两批数据后根据用户之前设定的周报模板组装出草稿。用户代理为草稿生成一条审阅前提醒事件推送给接入层用户看到周报初稿已生成请确认是否进一步排版。整个链路涉及协调器、用户代理、两个数据代理和接入层共五个组件。如果没有统一的消息协议和trace_id任一步骤出错都很难定位。协议设计越严谨链路越长就越稳。4. 多人多AI协同最难的一块状态一致性与冲突消解4.1 共享状态模型普通缓存是不够的多人多AI协同和单人单AI最大的区别是同一个资源可能同时被多个代理访问、修改。最简单的例子两个人各自让AI修改同一份产品文档的同一段。如果每个代理都在自己本地维护一份文档副本不存在共享状态库结果必然是按最后写入者覆盖前一个人的修改悄悄消失。只把文档放到Redis里也不是答案。代理从缓存里读、改、写两个代理同时读到同一版本然后各自写回后写的照样覆盖先写的。我用的基础方案是版本号条件更新共享状态存储里每个被操作的实体都带一个version字段代理修改时必须带着自己读到的version发起条件更新写入时如果version不匹配就拒绝做任何修改让代理先重新拉取再更新。这个流程可以用伪代码表示def update_shared_doc(agent, doc_id, changes): current state_store.read(doc_id) if changes[base_version] ! current[version]: raise ConflictError( fbase_version {changes[base_version]} stale, fcurrent version is {current[version]} ) new_version current[version] 1 ok state_store.compare_and_set( doc_id, expected_versioncurrent[version], new_valueapply_changes(current[content], changes[ops]), new_versionnew_version, ) return ok版本号只能发现冲突不能解决冲突。所以下面要有更高层的策略。4.2 冲突消解的三种策略我把实际可行的冲突消解方案整理成三种分别对应不同场景。第一种是命令串行化所有对同一个实体的修改指令都进一个有序队列按顺序执行不并行。这个方法最适合结构化程度高、操作可叠加的场景比如给任务列表添加标签、更新状态字段。命令串行化牺牲了并行度但换来了极强的确定性不会出现两个人各改半个文档的情况。第二种是版本对比人工确认当两个代理修改同一份文档且版本冲突时系统不自动合并而是把两个版本都保留下来生成对比视图请用户在现场确认选择哪一个或者手动合并。这个方法适合长文档、设计稿等语义复杂的场景因为AI自动合并在目前的技术条件下经常越合越糟。第三种是意图合并不直接合并文本而是合并操作意图。比如A代理说把标题加粗B代理说把标题改成蓝色两个都是格式化意图可以同时生效不存在矛盾。这个策略实现成本最高因为它需要代理输出结构化的操作意图而不是自由文本。策略适用场景代价推荐度命令串行化结构化字段、任务状态需要队列吞吐量受限高默认选这个版本对比人工确认长文档、设计稿、合同用户体验重需要审批节点中高风险操作必用意图合并格式化、标签、增量动作实现复杂需要意图理解低系统成熟后再考虑我现在的默认设置所有代理写操作默认走命令串行化队列只有检测到文档类实体且两个版本都修改超过一定比例时才升级到版本对比人工确认。这样既保证大部分场景自动流转又不会在关键决策上让AI说了算。4.3 会话一致性每个代理看到的上下文不能各说各话除了资源状态还有一个隐蔽的一致性问题代理之间对当前会话发生了什么的认知不一致。典型场景是用户代理和任务代理各自维护一份对话历史任务代理看不到其他成员已经做过的决策于是重复提一个已经被否决的方案。我的做法是会话上下文不复制给每个代理而是存在一个共享上下文库里每个代理手里只拿上下文指针即一组context_ref。代理需要具体字段时才去读取而不是把整个历史全部塞进prompt。这样可以避免token爆炸也保证所有代理读到同一版本的事实。当共享上下文库中的信息发生变化协调器会根据订阅关系向相关代理推送增量事件。代理在下一轮处理之前必须先获取增量再更新自己的局部视图防止基于旧信息做决策。这个设计和分布式系统里的最终一致性有点像代理之间不需要实时看到所有变化但同一个代理在一次任务处理周期内看到的上下文必须是某个一致快照。实现上我给每个context_ref配套了一个快照ID代理处理任务时携带自己当前的快照ID如果协调器发现快照ID过期会要求代理先刷新再继续处理。5. 可扩展性设计模型类型、代理数量、用户规模变化时怎么办5.1 代理注册与能力发现系统不可能永远只有固定几个代理所以代理层需要一套注册-发现机制。每个代理启动时向协调器的注册表上报自己的能力描述比如我可以调用代码解释器我可以检索会议记录我可以生成图表。协调器收到用户代理的请求后根据能力描述做语义匹配把任务路由给合适的代理。注册表至少要记录代理ID、能力标签、输入输出格式、当前负载、状态可用/熔断。我遇到过的最典型问题是很多团队把路由规则写死在配置文件里每当新增一个模型或者拆分一个代理就要改一遍所有调用方的代码。用了能力发现后新增代理只是向注册表添加一条记录用户代理完全不需要感知。举个例子如果想新增一个数据分析代理它启动时注册能力数据分析输入格式json表格输出格式markdown报告协调器后续就会把它加入路由候选。能力发现还会帮助我们做代理的版本管理。每个代理启动时可以带版本号注册表里保留灰度状态只有部分会话能路由到新版本。这样低风险地做代理升级而不是一次性全量替换。5.2 模型异构与协议适配多人多AI协同中的AI很可能不是一个模型。有人想用闭源大模型写文档有人希望本地开源模型处理隐私数据还有人想在某些场景接一个专门的判别模型。架构上必须屏蔽模型差异否则代理层会被某个厂商的API格式绑架。做法是在能力层加一个适配器层把不同的模型输入输出统一成代理层用的标准消息格式。适配器要处理的事情包括把自然语言指令组装成对应模型的提示格式解析模型输出为结构化JSON处理模型API的错误和重试计算token用量并上报。在这个设计下代理层不关心底层是哪个模型它们只认标准消息。替换模型时只需要替换对应的适配器不需要改动代理之间的任何一条消息。我也遇到过适配器过于智能的问题适配器为了把模型输出变成结构化JSON私自丢掉了一部分信息。后来在适配器设计里加了一条铁律适配器只能做格式转换不能做内容摘要或内容修改。如果模型的输出本身不符合要求的JSON结构适配器必须返回错误并触发模型重试而不是自己硬编一个JSON。5.3 水平扩展与消息分区当用户量大起来需要做分区。我用的规则是用户代理按user_id哈希到不同的分区保证同一个用户的代理只出现在一个分区内避免多实例同时替一个用户做决策导致状态混乱。任务代理按领域分区比如文档代理一组实例代码代理一组实例。消息总线的Topic也按这些分区拆分比如conversation_id.hash() % N。扩展时把某个分区整体迁移到新节点然后更新注册表里的分区映射。这里有一个容易被忽略的前提代理的个人记忆尽量放在共享存储本地只放临时缓存。否则迁移分区时代理带不走自己的记忆。我在设计用户代理时把用户的偏好、历史决策摘要、常用工具列表都放到了共享用户档案库里用户代理实例本身是无状态的只有需要执行任务时才从档案库加载上下文。分区的另一个好处是故障隔离。一个分区的消息积压不会影响其他分区的消费者。假设文档代理因为模型API抖动全部阻塞代码代理所在的Topic仍然可以正常流转用户至少有一半任务还在推进。6. 可观测性与验证这套架构到底跑得稳不稳6.1 从第一行代码开始就要埋点多人多AI协同系统比单体应用难排查得多因为一次用户请求会拆成多个代理、多次消息投递。没有trace_id和span出问题时只能靠猜。我在设计消息协议时就强制要求消息头里必须带trace_id每次代理处理开始和结束都要记录span包含代理ID、输入消息ID、处理耗时。日志系统里可以按trace_id拉出整条协作链路。我在查一个周报任务卡住的问题时就是靠trace_id发现用户代理在等待会议纪要代理的响应而会议纪要代理已经处理完并发送了response但消息总线在投递时因为序列化错误把它丢了。问题出在消息总线的序列化环节跟两个AI的推理能力完全无关。如果没有全链路日志这个问题可能得排查好几个小时。埋点范围不只是AI模型调用。代理之间的消息投递、队列等待、状态库更新、权限校验、人工审批等待都要记录耗时和结果。这些非AI环节的延迟往往才是系统瓶颈。6.2 核心指标与告警可观测性最终要落到指标上。我长期最关注这五个指标正常范围参考说明任务成功率大于95%失败要能区分是模型错误、超时还是人工拒绝平均完成时延小于30秒单轮模型调用约3-10秒多轮协作会放大冲突率小于5%超过这个值说明操作粒度太粗或上下文不同步消息积压数长时段为0积压持续上涨说明消费能力不足模型成本监控峰值上下文爆炸时token成本会异常飙升指标只是结果告警才是触发动作的关键。我设置了三条比较有效的告警规则第一任务成功率连续五分钟低于90%立即通知研发第二消息队列积压数超过100且持续增长超过两分钟自动增加消费实例第三模型成本在半小时内翻倍就要检查是不是有代理把全文上下文传给了其他代理导致token爆炸。第三条告警几乎是专门为上下文泄漏设计的。6.3 压测与场景模拟我做过一次比较有效的压测构造100个并发用户每个用户同时向两个任务代理发起修改请求而且两个请求的目标是同一个共享文档。压力不均匀地放在模型API上而是放在消息总线和状态库上因为真正的瓶颈往往在这里。测试过程分成两步。第一步用一批假代理模拟消费只做内存操作不实际调用模型快速跑出系统的极限QPS。主要观察消息总线的吞吐量、状态库的CAS冲突率、协调器的路由耗时。第二步用真实模型进行小规模重放比如十个并发用户、每个任务带两轮代理协作检验代理之间的消息协议是否经得住真实输出格式的考验。真实模型调用时延很高异步队列扇出很快必须配合限流。如果没有限流上游同时涌入1000个任务下游模型API很快会被打爆然后触发一堆重试把系统搞得更慢。压测中一个让我印象深刻的结论是状态库的CAS冲突率在并发用户数超过五十之后会快速上升因为多个代理几乎同时读取同一份文档然后各自做修改。这个现象倒逼我把共享文档的修改粒度进一步缩小从整文档版本控制改成段落级版本控制冲突率从15%降到了3%以下。7. 落地时的取舍我踩过的坑和比较务实的建议7.1 先别急着把所有AI接进来刚开始做这个系统时我恨不得把市面上的主流模型全接进来让它们互相博弈、各显神通。事实证明这个想法非常危险模型越多行为越不可控。现在我的建议是先只配两个用户代理、一个任务代理、一个协调器跑通用户A让任务代理做一份摘要用户B能看到摘要改动的最小闭环。协议验证通过后再逐步增加代理。这个过程里最重要的不是模型聪明不聪明而是消息能否稳定送达、状态能否保持一致、任务失败能否自动重试。我见过太多项目一开始就引入三四个模型却连最基本的两个请求串行更新同一个文档都做不稳最后只能推翻重来。架构研究阶段稳定闭环比模型能力优先级高得多。7.2 上下文窗口管理是隐形杀手多代理共享上下文很容易让prompt体积变得巨大。最常见的问题是用户代理为了让任务代理也了解完整背景把整段历史对话原封不动塞给任务代理。两轮之后每个代理手里都有一份完整的历史副本token成本成倍增长而且越往后模型越容易丢失重点。我的做法是只传递结构化摘要和引用任务代理需要会议纪要细节用户代理就给一个context_ref加摘要加关键字段而不是把全文粘过去。只有代理真正需要全文时再通过消息总线发出一次读取请求。上下文窗口这件事不只是在做省钱优化更是为了系统稳定性。prompt一长模型输出质量和响应速度都会明显下降。7.3 权限边界要前置设计代理代替用户操作意味着如果权限没管好AI会把不该做的事也做了。比如用户A的代理请求用户B的私有文档架构上不能依赖用户B的任务代理自己做判断因为模型无法可靠地理解权限规则。正确做法是在代理层统一挂一个权限服务所有跨用户、跨实体的访问请求先经过权限服务校验校验通过才投递到能力层。不要在能力层再依赖模型的自觉。我用的是一套简单RBAC用户代理持有用户身份和角色任务代理不关心身份只接收权限服务签发的一次性访问令牌。令牌里有操作类型、资源ID、过期时间。能力层在执行前校验令牌校验不通过直接拒绝。这套设计花的时间不长但避免了很多后续麻烦。特别是当代理数量变多后如果每个代理各自判断权限很容易出现越权操作。7.4 兜底与人工介入最后一条经验是不要追求全自动。多人多AI协同里AI可以做的事情很多但真正重要的决策——比如合并两个冲突版本、对外发布通知、给客户发送邮件——还是需要人工确认节点。我在流程编排里支持一种特殊的审批等待状态任务代理执行到关键节点时把结果和一个确认按钮一起推到用户端用户点击确认后流程才继续。这个设计看着不酷却能避免大量因为模型误判导致的返工。举个例子两个代理对同一个版本冲突各执一词时系统不强行合并而是把两个版本并列展示给用户。用户确认后整个链路才继续。前几周我又重构了一版消息协议最大的改动是给所有关键消息加了expire_at字段超时未响应的任务会被自动升级到人工队列。一顿操作下来系统的稳定性反而比当初追求全自动时高了不少。多代理协同的架构本质上不是让AI代替人做所有事而是让人在关键节点上以更小的成本介入AI负责把那些需要反复对齐的体力活干掉。