最近一段时间，我大部分精力都放在一个课题上：基于AI代理代为交互的多人多AI协同系统架构。说白了就是——多个人，带着多个AI，在一个统一架构里协同干活，不是一人一个对话框轮着问，而是让AI代理作为中间层，完成请求路由、上下文管理、任务仲裁和结果汇聚。这个方向解决什么问题？一句话：单点智能不稀缺，稀缺的是把多个AI组织成一支队伍。
这个课题适合谁参考？做AI中台、智能体平台、企业协同工具、客服调度系统的人，或者手里捏着好几个大模型API、想统一纳管又不想写一堆胶水代码的开发者，都可以看下去。本文不会贴十亿行源码，也不会讲那些人人都能搜到的概念定义，而是把架构拆开，讲清楚每一层为什么存在、核心模块怎么落地、实际跑起来会踩哪些坑。
先给结论：这里说的“协同”，不是把几个AI拉到一个群里互聊。没有中间层管理，多模型对话很快就会变成噪声制造机。这是我一开始踩坑之后最深刻的判断。
1. 这个项目到底在研究什么
1.1 一台AI好说，一群AI难聊
单个AI的使用方式非常成熟：人发一条指令，AI回一段文字，需求对上就完事。但一旦引入“多人”和“多AI”两个维度，情况立刻复杂起来。
先看“多人”。不同的人有不同的目标、表达习惯、权限范围和对结果的验收标准。同一个问题，产品经理问出来的角度和技术负责人问出来的角度完全不一样，如果两个人都各自去跟同一个AI对话，得到的是两份互相割裂的答案，没人负责合并、对齐和消解矛盾。
再看“多AI”。不同模型的擅长领域不同：有的代码生成质量高，有的长文本总结能力好，有的看图理解强，有的本地部署后隐私性强。把它们简单堆在一起，让用户自己选，成本就全转移给了用户。更麻烦的是，多个AI之间的知识不互通，信息在模型之间传递时，没有一个统一的结构来承载，最终很容易变成“句子的接力”，而不是“任务的协同”。
所以这个课题的真正切入点，不是“把AI做得更聪明”，而是“把AI组织得更合理”。AI代理在这里承担的就是组织者的角色：替人说话，也替AI传话，同时保证这两套交流不会乱套。
1.2 “代交互”不是传话，而是调度与仲裁
很多人看到“代为交互”四个字，会理解成一个简单的消息转发层：人说了什么，代理转给AI，AI回了什么，代理再转给人。如果只是这样，那这架构根本不需要专门研究，写一个消息队列就够了。
实际设计里，代理要做的远不止转发。它需要理解这条消息是谁发的、要干什么、应该发给哪个AI、需要附带什么上下文、希望在多长时间内拿到结果、如果多个AI分别返回了不同结论，由谁来裁决。
举个我经常用的类比：这不是传声筒，而是会议主持人。主持人不是把每个人都的话原样重复一遍，而是控制发言顺序、归纳分歧点、引导下一步讨论，并在最后整理出会议纪要。AI代理在这套系统里的定位，就是那个主持人。
我见过一些团队前期没想清楚这一点，把代理设计成纯透传管道，结果系统一上线就出问题：两个AI回答矛盾时没人判，用户反复在不同模型间切换时上下文彻底错乱，权限控制形同虚设。所以在这个项目里，代理的“调度”和“仲裁”职责，从一开始就必须写进架构设计里，而不是事后再补。补一次，伤一次，这是真话。
1.3 核心目标与技术边界
这个架构最终要达成几个核心目标。第一，多个人可以共享同一批AI资源，但彼此之间的会话和上下文完全隔离，不会出现“A问的问题在B的会话里突然冒出来”这种恐怖场景。第二，系统能根据任务的类型、难度和领域，自动把请求路由给最合适的AI，而不是永远依赖用户手动选择。第三，当多个AI协作处理同一个任务时，系统能够监控进度、聚合结果、处理分歧，让最终输出稳定可靠。
技术边界也要提前划清楚。我不主张在项目初期就把所有AI接入进来，也不建议一上来就追求所谓“全自动、零人工”。架构的价值是降低复杂度，不是消灭复杂度。初期目标应该是先做一个能跑通“多人分工、多AI分责、代理仲裁”的框架，然后再逐步增加新模型、新能力和新场景。边界划清楚，后面才不会做成了永无止境的“接模型大赛”。
2. 系统架构的总体设计与分层思路
2.1 四层架构到底怎么分
整套系统我按四个层来组织：接入层、代理中枢层、AI适配层、数据与记忆层。每一层的职责边界必须非常清晰，否则代理逻辑和业务逻辑一旦纠缠在一起，后续几乎没法维护。
接入层负责把人“接进来”。无论是网页端、聊天客户端、企业IM机器人，还是API调用，都通过统一的网关接入。接入层不处理具体任务逻辑，只做三件事：身份认证、会话建立、请求格式标准化。
代理中枢层是整套系统的核心，也是最值得花力气设计的地方。它接收接入层传来的标准化请求，分析任务类型，拆解任务步骤，选择合适的AI模型，分发任务，收集结果，处理冲突，并最终把结果聚合后返回。后面章节讲的核心模块，基本都生活在这一层。
AI适配层解决的是“模型各异”的问题。不同AI厂商的API格式不同、限流策略不同、计费方式不同、上下文窗口大小不同，适配层把这些差异封装起来，向上层提供统一的调用接口。每接入一个新模型，只需要写一个适配器，不需要动代理中枢的逻辑。
数据与记忆层负责所有状态的存储。包括会话历史、任务记录、AI返回的中间结果、用户偏好、权限配置、向量化记忆等等。这一层很考验细节：哪些数据该存长期库，哪些只放在缓存里给当前会话用，这些要在设计阶段就定下来。
四层架构听起来平平无奇，但它在工程上带来一个直接好处：每一层都可以独立替换。今天代理中枢层用了一个轻量级实现，明天可以升级成带复杂规划和记忆的版本；今天接的是线上大模型API，明天可以在适配层插一个本地方案的适配器，接入层和代理中枢层完全不用动。
2.2 为什么把代理中枢单独拎出来
这是我在设计过程中反复权衡过的一个决定：代理逻辑作为独立进程存在，而不是嵌在某个业务服务内部。
嵌入式的做法在早期看起来省事：用户请求来了，直接在业务代码里调用模型API，然后把结果返回。但一旦任务复杂，比如需要多个AI协作完成，业务代码里就要充斥着任务状态管理、上下文拼接、结果仲裁的逻辑，业务逻辑和AI编排逻辑混在一起，代码会迅速腐化。
把代理中枢单独拎出来之后，整个系统变成了一个类似“发布-订阅”的形态。业务侧只负责提交任务和接收结果，代理中枢负责一切AI相关的编排。好处有三点：
一是可以单独扩展。AI编排是重负载，任务多的时候需要更多的计算资源，独立部署就随时可以横向扩容。二是方便灰度验证。新的路由策略或仲裁算法先在代理中枢上小流量跑，出问题回滚也快。三是职责分明。团队分工时，有人专注业务接入，有人专注AI编排，互相不干扰。
当然也有代价：多了一层网络调用，链路变长，延迟会略微增加。但对比它带来的维护性收益，这点延迟完全可以接受。实测下来，在大部分任务场景里，真正耗时的还是模型推理本身，代理中枢的处理时间通常可以控制在几十毫秒以内，不是瓶颈。
2.3 协作模式的设计取舍
多人多AI协同不是只有一种模式，实际场景里需要支持几种典型的协作逻辑。
第一种叫“委派式”，一个发起人提交任务，代理判断需要几个AI分工完成，分别委派出去，再汇总结果。比如做一份市场分析报告，可以拆成数据搜集、竞品分析、文案润色三个环节，分别交给不同AI，代理最后汇总成一篇完整报告。
第二种叫“评审式”，同一个任务发给多个AI独立处理，代理收集所有结果后做差异对比，找出共识和分歧点，再请求人工或者规则引擎进行最终裁决。这种方式适合答案没有绝对标准的场景，比如方案评审、设计稿反馈、技术选型讨论。
第三种叫“流水线式”，任务被拆成有先后顺序的多个阶段，每个阶段的输出是下一个阶段的输入。这种方式最适合那些“链式加工”的流程，比如先写代码，再自动生成注释，再生成测试用例。
实际系统中，这三种模式经常组合出现。代理中枢的设计不能只支持其中一种，而是要支持可配置的协作管线。这也是为什么我在架构设计时坚持把“任务结构化”做好，因为只有任务的结构清晰，才能在不同的协作模式之间自由切换，否则每个新场景都要重新造一套轮子。
3. 核心模块解析：路由、上下文与仲裁
3.1 统一任务信封
在多人多AI协同系统里，消息在层与层之间传递，最怕的就是各写各的格式。今天这个模块用了三个字段描述任务，明天那个模块又用了另外五个字段，联调的时候就是一场灾难。所以我在设计时做了一个强制规定：所有进出代理中枢的请求和响应，必须遵循统一的任务信封格式。
任务信封是一个带有完整元数据的标准包装结构，核心部分大概长这样：
{ "task_id": "task_20250116_001", "session_id": "session_team_a_01", "sender": { "user_id": "zhangsan", "role": "product_manager" }, "recipients": ["ai_code_reviewer", "ai_architect"], "intent": "tech_scheme_review", "context_ref": ["memory_ctx_001", "memory_ctx_002"], "content": { "input_text": "评估一下当前方案能否满足日活十万的需求", "attachments": [] }, "constraints": { "deadline_ms": 30000, "priority": "high", "max_tokens": 2048 }, "callbacks": { "on_success": "notify_webhook_scheme_review", "on_failure": "notify_webhook_error" } }看着字段很多，但每个字段都有存在的理由。task_id用来追踪全链路，session_id用来做会话隔离，sender带上用户和角色信息是为了后续做权限判断，recipients明确任务发给谁，constraints里是超时和优先级，callbacks则定义了任务完成或失败之后系统怎么通知业务侧。
这里有一个很容易忽略的细节：context_ref不是直接把上下文内容塞进来，而是引用上下文的存储ID。这样设计的原因是我吃过亏——有一次为了省事，直接把一大段上下文文本塞到消息里，结果多个任务并发时，上下文内容在传输中大量重复，消息体膨胀了好几倍，处理速度直线下降。改成引用ID之后，代理中枢按需从记忆层拉取上下文，传输效率和灵活性都提升了一个档次。
3.2 路由策略：把任务分给对的人
路由是整个代理中枢里最核心的策略模块。任务信封进入中枢后，第一步不是直接调用AI，而是要回答一个问题：这个任务该给哪个AI？
我一开始想得很简单，给每个AI打上标签，然后做规则匹配。比如标签是“代码生成”的任务就发到代码模型，标签是“总结”的就发到总结模型。但跑了一段时间后发现问题：实际任务的意图往往不是单一的。用户说“帮我看下这段代码，然后把问题总结一下”，这里面既有代码分析，又有文本总结，单纯靠标签匹配会丢需求。
后来我把路由改成了“多标签评分制”：每个AI注册时声明自己的能力标签和擅长程度，路由模块根据任务内容提取多个候选标签，分别计算每个AI的匹配分，再结合当前负载和成本约束做最终决策。匹配分计算公式大致是：
score = 能力匹配度权重 * 0.5 + 历史效果权重 * 0.3 + 响应速度权重 * 0.2历史效果权重来自每次用户反馈或任务完成效果的记录，这样用得多的AI如果效果一直好，权重就会慢慢上升，形成正向循环。当然，也要防止“强者恒强”，所以路由里还会加一点随机性或者轮换策略，避免某个AI永远被选中、其他AI长期闲置。
实际落地时，我建议先把路由规则做成可配置的。至少预留一张类似下面的映射表，方便初期调试：
| 任务类型 | 首选AI | 备选AI | 路由规则 |
|---|---|---|---|
| 代码审查 | ai_code_model | ai_general_model | 代码上下文优先 |
| 方案对比 | ai_architect | ai_general_model | 按评分路由 |
| 快速答疑 | ai_general_model | ai_local_model | 低延迟优先 |
| 隐私数据处理 | ai_local_model | 无 | 硬性约束 |
路由是代理中枢里迭代最频繁的部分，不要幻想一次设计到位。先跑起来，收集数据，再逐步优化权重和阈值，这才是务实的做法。
3.3 上下文管理与会话隔离
多人在同一个系统里使用多个AI，最容易出事故的地方就在上下文管理。Profile A和Profile B的会话如果稍有混杂，轻则答非所问，重则数据泄露。这个必须从底层上做好隔离。
我的方案是“两层隔离、按需共享”。第一层是会话级隔离，每个session_id拥有独立的上下文空间，不同会话之间完全不可见。第二层是团队级共享空间，同一个项目组可以配置共享的知识库或记忆片段，代理在分发任务时，会从共享空间里拉取相关背景信息，注入到任务上下文中。
这样做的好处是兼顾私密性和协作性。各人自己的对话历史、草稿、偏好设置都存在私密空间，别人看不到；而项目背景、结论文档、经验总结这类需要共享的信息，则统一放在共享空间里，代理负责在这两层之间做整合。
还有一点值得强调：上下文不是越长越好。很多人做Agent项目时习惯把所有历史对话都塞给模型，结果token费用高、响应慢，而且模型容易被无关信息干扰。我在这个项目里做了一个简单但有效的限制：默认只保留最近10轮对话作为上下文，加上与当前任务直接相关的共享记忆摘要。项目组需要更长时间线信息时，可以通过显式的检索指令来扩展上下文，而不是默认全量加载。实测下来，准确率没有下降，成本倒是省了一大截。
3.4 仲裁机制：多AI意见不一致时听谁的
多人多AI协同里，最精彩也最让人头疼的场景，就是多个AI给出不一致甚至相反的答案。如果没有仲裁机制，系统就会变成一个甩锅现场：用户拿着两个AI的结论，不知道该信谁。
仲裁我分为两个级别。第一级是规则仲裁，适合答案可以被自动化评判的场景。比如代码类任务，可以自动跑测试用例来验证结果；算数类任务，可以自动验算答案。规则能判定的，就不需要人来介入。
第二级是人工仲裁，适合那些规则无法自动判别的高风险场景。比如架构方案评审，AI-A说方案可行，AI-B说风险很大，两者各有依据，这时就需要把两个结论连同依据一起打包，呈现给有权限的决策者。但这里也有一条原则：不能让用户自己去拼凑信息。代理中枢应该先把AI之间的共识部分自动合并成一段概述，再把分歧点单独列出来，标明分歧各方的主要论据和关键支撑材料，让决策者快速看到焦点，而不是一上来读两篇长篇大论。
仲裁过程记录也很重要。谁的结论被采纳了、依据是什么、最终决策是什么，这些都要沉淀下来，作为后续路由权重调整的训练素材。说白了，每一次仲裁都是在教系统下次如何做得更好。
4. 实操过程与核心环节实现
4.1 第一版落地：从场景拆解开始
很多人拿到一个架构题目会急着写代码，但我建议先做场景拆解。我当时的做法是选了一个有代表性的内部场景：三人小组进行一次技术方案评审。三人的角色分别是产品经理、后端工程师、运维工程师，系统里接入了三个AI：一个负责方案生成，一个负责风险排查，一个负责代码层面的可行性分析。
业务流程是这样的：产品经理通过接入层提交一个需求方案评审请求，代理中枢把任务拆解为三路并行的子任务，分别发给三个AI，然后收集结果。如果三个AI给出的结论一致，代理做一次统一摘要返回；如果结论有分歧，代理先把两份结论做成对比视图，并自动列出各自的适用条件，最后推给项目负责人做人工拍板。
选这个场景的原因是它足够典型，覆盖了多人、多AI、任务拆解、并行处理、结果聚合、仲裁这几条主线。而且场景规模不大，出了问题好定位。项目初期不建议直接往仓库里塞几十个AI和上千个并发用户，那样出了问题你根本分不清是架构问题还是模型问题。
4.2 环境准备与基础组件选型
整个系统我用了比较轻量的一套基础组件组合：FastAPI做接入层的后端服务，Redis处理任务队列和轻量状态缓存，PostgreSQL存持久化数据，向量数据库用来存储共享记忆片段，代理中枢本身用Python实现。
组件选型的逻辑很简单：优先选择我熟、生态成熟、出问题资料多的东西。这个阶段不需要追求极致性能，稳定和顺手的价值更大。
FastAPI本身支持异步请求处理，实测单机扛住几百路并发问题不大。Redis在这里的定位很关键：所有进入代理中枢的任务先落到Redis队列里，由中枢的工作进程消费。这样即使某个AI调用超时或失败，任务也不会直接丢失，可以在队列里做重试。
代理中枢的进程模型是典型的消费者模式：一个主进程监听队列，拿到任务信封后根据intent字段分发给相应的worker，每个worker负责调用对应AI适配器。这种模型的好处是如果一个worker挂了，其他worker不受影响。我还要强调一点：不要一开始就上K8s之类重编排平台，单机加进程管理器，足够撑过整个早期验证阶段。
4.3 关键流程的代码骨架
整个链路里最核心的编排逻辑，我简化后大概长这样：
def handle_task_envelope(envelope): # 1. 解析任务信封 task_id = envelope["task_id"] intent = envelope["intent"] recipients = determine_recipients(intent, envelope) # 2. 分发任务到多个AI sub_tasks = split_task(envelope, recipients) futures = [dispatcher.submit(ai_adapters[sub_task["recipient"]], sub_task) for sub_task in sub_tasks] # 3. 收集结果 results = [] for future in as_completed(futures, timeout=envelope["constraints"]["deadline_ms"]): results.append(future.result()) # 4. 结果聚合与仲裁 final = aggregate_and_arbitrate(results, envelope) notify_callback(envelope["callbacks"]["on_success"], final)这段骨架不完整，但它体现了几个核心原则：确定接收者、拆分任务、并行分发、收集与仲裁。在实际项目里，dispatcher背后是一个线程池加信号量控制的并发管理器，每个AI适配器的调用都会记录详细的指标，包括耗时、token消耗、成功状态。
这里有一个我调试了很久的细节：超时控制。模型调用有时会因为服务端排队或网络抖动变得很慢，如果没有超时控制，一个慢任务会拖住整个会话流程。我的方案是在任务信封的constraints里带上deadline_ms，代理中枢在拿到结果前会启动一个计时器，超过时限的任务直接标记为失败，转而走降级策略，比如启用备选AI或者请求用户确认是否继续等待。
4.4 联调测试的节奏控制
联调阶段我有一个很深的体会：先打通一条最简链路，再横向扩展。第一次联调只测一个用户、两个AI、一个最简单任务类型，就是从提交任务到拿到返回结果，确保全链路是通的。跑通之后，再逐步加第二个用户、第三个AI、更复杂的协作模式。
测试数据也很重要。我专门准备了一批“带坑”的测试任务，比如带有隐含指令的长文本、需要跨会话上下文才能回答的问题、以及多个AI可能给出冲突结论的评审场景。这些测试用例的价值是能让代理中枢的薄弱环节尽早暴露。
比如我第一次测跨会话上下文时，发现用户A在会话甲里创建的方案背景，完全无法在会话乙中被用户B的AI引用，哪怕他们都是同一个项目组成员。后来才意识到问题出在共享记忆空间没有正确关联到项目组。这类问题如果不靠精心设计的测试用例去触发，很难在开发阶段被主动发现。
5. 常见问题与排查经验实录
5.1 多AI同时响应导致的冲突
第一次让两个AI并行处理同一个问题的时候，常见的现象是：一个AI说“方案可行”，另一个AI说“建议重新设计”，两个结果都原样呈现给用户，用户直接懵了，反问系统“到底听谁的”。
排查思路是确认仲裁模块没有生效。我后来发现原因是任务拆解时把两个AI定义为“协作关系”，但实际上它们处理的是同一个决策点，应该被定义为“竞争关系”，走评审式协作模式。把协作模式调整清楚之后，冲突问题就变成了正常的“提交分歧结果供人工决策”，而不是一个BUG。
5.2 记忆污染与上下文偏移
多人多AI系统里有个特有现象：AI在回答某个问题时，突然提到了另一个用户在其他会话里聊过的东西。用户会觉得毛骨悚然，第一反应就是“系统是不是在偷听我”。
这个问题几乎全是上下文管理没做好导致的。有的是共享空间和私密空间没有隔离，有的是在拼接上下文时错误地把全局记忆当成了当前会话记忆。排查时，我会先查任务信封里的context_ref是否引用了正确的记忆ID，再查代理中枢拼接段上下文时是否做了权限过滤。修复方法是强制在上下文拼装前执行一步权限校验，只有当前用户或当前项目组有权访问的记忆片段才会被注入。
5.3 权限失控
代理作为中间人，有一个被忽略的隐患：它可能无意中继承权限。如果用户在请求里附带了一个“删除项目配置”的指令，代理会忠实地转发给AI，AI也会忠实地执行。但用户本身不一定有删除权限。
这个问题在个人使用场景里不存在，但在多人协同场景里极其致命。我的解法是在接入层就做一次显式的权限判定，解析出请求的动作类型，然后对照用户角色权限表，没有权限的操作在进入代理中枢前就被拦截，同时返回一个清晰的“无权限”提示。代理中枢本身不承担权限决策的职责，它只负责执行已经被授权过的任务。
5.4 回调风暴与消息乱序
当多个AI的输出通过回调返回时，如果不做顺序控制，用户界面上的消息会乱跳：先出现的结果可能反而是后提交的任务产生的。排查时发现，问题出在任务并发提交后，各个AI的响应时间差异太大了，快的几秒，慢的要一分钟。
解决方案是引入事件序号机制。代理中枢在分发任务时为每个子任务生成序号，结果汇聚时按序号重组消息流，并且只有全部子任务都返回或超时后，才产生最终的聚合输出。这样用户看到的永远是有序的、完整的结论，而不是碎片化输入。
5.5 典型问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决方案 |
|---|---|---|---|
| 多AI答案冲突 | 协作模式配置错误 | 检查任务拆解与协作类型 | 改用评审式协作并启用仲裁 |
| 用户看到别人的记忆 | 上下文权限过滤缺失 | 检查context_ref与权限校验 | 拼接前强制权限过滤 |
| 代理执行了越权操作 | 接入层未做权限判定 | 检查接口层动作解析 | 在接入层拦截未授权操作 |
| 界面消息乱序 | 回调无序号管理 | 检查结果汇聚逻辑 | 引入事件序号与聚合输出 |
| 任务超时无响应 | 没有deadline控制 | 检查调度器超时机制 | 按任务信封约束设置超时 |
| 某个AI永远不被选中 | 路由评分固化 | 检查历史效果权重 | 增加轮换策略或随机性 |
6. 我的实操心得与后续扩展建议
6.1 三个关键认知
做了这么多轮迭代之后，我有三个非常明确的认知。
第一个认知：代理层的核心价值是结构化和可追溯，不是“智能”。很多人指望代理中枢自己会思考，其实代理的价值在于把无序的交互变成有序的流程，让每一次AI调用都有清晰的意图、输入、输出和归属。
第二个认知：多人多AI协同最大的风险不是技术，而是混乱。权限混乱、上下文混乱、结果混乱，任何一种混乱都可能让系统失去信任。架构设计时要优先防御混乱，其次才考虑效率和智能。
第三个认知：一定要给人工介入留好位置。完全自动化的协同看起来很酷，但在关键决策节点上，没有人的参与，系统就缺少权威性。代理要做的是把决策所需的素材整理好，然后交给合适的人来拍板，而不是自己假装能拍板。
6.2 基于这个架构还能怎么扩展
这套架构目前跑通了核心链路，后续有几个方向值得继续深化。
一是让代理具备更强的主动规划能力。现在的任务拆解主要靠规则和模板，后续可以引入AI规划器，让代理根据任务目标自主决定拆分成哪些步骤、调用哪些AI、使用哪些工具。
二是更细粒度的成本控制。不同AI的定价差异很大，代理在路由时可以加入预算约束，在满足质量要求的前提下尽量选择成本更低的方案，把多个模型统一纳入成本感知调度。
三是接入更多本地化模型。现在的适配层已经预留了这个能力，后续可以针对隐私敏感场景配置本地推理实例，让敏感数据完全不出内网的情况下完成协作任务。这类需求在企业和政企场景中越来越多，也是整个架构价值最明显的地方。
四是团队层面的效能分析。当所有任务都经过代理中枢后，每次交互的耗时、成本、质量、用户满意度都会被记录下来。基于这些数据，可以做团队级AI使用效能分析，比如哪些环节最耗时、哪些AI效果最好、哪些流程可以固化下来反复复用。坦白说，做到这一步，代理层才算真正从“工具管理者”变成了“组织协作者”。
最后分享一个我自己的体会：做这种架构，最忌讳的是贪多。今天想接十个模型，明天想做全自动规划，后天想上大规模并发，很容易把自己拖垮。我的做法是先挑一个真实场景，用最朴素的规则实现把架构跑通，让团队真正用起来，然后根据反馈一点点迭代。所有看起来精巧的能力，比如自动规划、动态路由、主动记忆，都是在架构有了稳定骨架之后才一枝枝长出来的。多人多AI协同的终极目标，不是让AI取代人的判断，而是让人更容易拿到高质量的判断依据。想清楚这一条，方向就不会跑偏。
