刚把系统从内部测试切到正式环境，趁热打铁把整个设计和落地过程整理出来。我们这个项目叫"多数字人智能体协作办公系统"，简单说就是让一群有独立身份、有分工的AI智能体，以数字人的形态出现在办公流程里，像团队成员一样相互配合着干活，而不是单个ChatBot在对话框里一对一地回答问题。

先说结论：这套东西不是把智能体堆在一起就行，真正难的是协作治理、状态同步、数字人呈现这三块。这篇文章会把我从产品判断、架构设计、技术选型到踩坑复盘整个过程都展开讲，适合正在做AI Agent产品、数字人应用，或者想在企业内部落地智能体协作平台的团队参考。文章偏工程实践，不会只停留在概念层。

1. 为什么是"多数字人"，而不是一个更聪明的智能体

1.1 单智能体的天花板不在智商，在于"角色混串"

去年我们先做了一个单智能体版本的办公助手，用一个大模型实例接上工具调用，可以写周报、查数据、生成会议纪要。上线跑了一个月，收到最多的反馈不是"它不够聪明"，而是"它有时候像个精神分裂患者"。

原因很典型：当你要它同时充当客服话术专家、数据分析师、文案策划时，模型会在同一个上下文窗口里来回横跳。今天你跟它聊客户投诉，明天让它帮你写营销文案，它大概率会把客服场景里那种谨慎保守的语气带到文案里，产出的东西四平八稳但完全没有传播力。更麻烦的是工具权限没法隔离，数据智能体能碰到的接口，文案智能体也能碰到，一旦某个prompt注入成功，整个系统都会暴露。

单智能体的另一个问题是上下文窗口的物理限制。一次复杂协作任务，比如"策划新品发布会并生成全渠道推广方案"，涉及市场分析、物料清单、KOL名单、预算分配、时间排期，这些内容全部塞进一个上下文窗口很容易超过处理上限，即便没有超限，模型也会出现"记了前面忘了后面"的注意力漂移。

所以回到那个核心判断：办公场景需要的不是单体万能智能体，而是一组各司其职、有独立记忆和权限边界的智能体，它们之间通过协议协作，就像一个项目组。

1.2 数字人不是装饰，是协作系统里的"在场证明"

一开始我们内部争论过：既然底层是多智能体协作，为什么前端非要套一层数字人？直接用聊天界面展示过程不就行了？

后来产品团队做了一个小实验：同样一个任务，A组用户面对纯文字界面，智能体之间怎么分工、谁在做什么全都靠日志文字描述；B组用户面对三个不同的数字人形象，每个智能体分配一个角色、一个声音、一种性格化表达。实验结果很有意思，B组用户对系统输出结果的信任度明显更高，而且遇到结果出错时，B组用户更倾向于说"某某个数字人这部分做得不对"，而不是笼统地说"系统有问题"。

这背后的逻辑是：人类在协作场景里需要"在场感"和"归因感"。开电话会你总得知道对面是谁，出了问题你得知道该找谁。数字人就是智能体在办公空间里的具象化主体。它让协作过程从黑盒变成白盒，也让责任边界变得清晰。这不是为了炫技，是真实的管理需求。

1.3 目标场景与用户画像

我们在设计之初锁定了三个核心场景：

• 跨部门任务执行：例如市场部发起一个campaign，需要设计、文案、数据分析、合规四个角色协同。
• 知识密集型的对内服务：例如新员工培训、制度问答、IT支持，多个智能体按知识域分管不同文档库。
• 对外客户服务：例如售前咨询、售后跟进，数字人作为企业统一服务门户，背后按问题类型分发到不同智能体。

目标用户画像也清晰：不是那些有专门AI团队的大厂，而是中小型公司和业务部门——他们有真实需求，有文档积累，但没有足够人力去维护一套复杂的AI中台。所以我们的设计原则是"业务人员能配，技术人员能改，交付时不需要养一支算法团队"。

2. 系统整体架构：从大模型底座到数字人呈现的完整协作链路

2.1 五层架构与各层职责

整个系统按五层来拆，每层只做自己该做的事，层与层之间通过标准接口通信。

第一层是接入层，对接钉钉、飞书、企业微信和Web端，用户在这些入口里发起任务、查看进度、接收结果。接入层做的是统一会话管理，不管用户从哪个入口进来，都能拿到同一个任务ID和协作上下文。

第二层是编排层，这是整个系统的大脑。它负责意图识别、任务拆解、智能体路由、依赖调度、结果聚合。用户说"帮我准备一个季度复盘会，输出PPT大纲和发言稿"，编排层要把这个需求拆成：数据分析智能体拉取本季度经营数据、内容智能体撰写发言稿框架、设计智能体生成PPT页面结构，并且规定好依赖顺序——先出数据分析结论，再写进发言稿。

第三层是智能体层，每一个智能体实例有自己独立的身份设定、知识库索引范围、工具权限清单、记忆存储空间。我们目前上线了七个默认角色：客服专家、文案策划、数据分析师、设计师助手、合规审查员、培训讲师、IT支持专员。每个角色都有一套独立的系统提示词、独立的向量知识库集合、独立的工具白名单。

第四层是模型层，做统一的大模型接入网关。底层可以是DeepSeek、通义千问、文心一言或者开源模型，上层业务不直接感知具体模型切换。模型层还负责统一的流式输出处理、函数调用协议规范化、上下文压缩策略。

第五层是呈现层，负责把智能体的输出转化为数字人的语音和动作。这里有语音合成引擎、口型驱动模块、动作库、表情系统，以及一个前端实时渲染引擎。

五层之间最关键的通信设计是：所有协作消息走同一个异步消息总线，每一条消息都带agent_id、task_id、message_type三个字段。有了这三个字段，不管数据流经过多少跳转，都能追踪到是谁、在哪个任务里、发了什么类型的消息。这个设计在后期排查问题时帮了大忙。

2.2 协作编排：任务拆解、角色路由与依赖管理

整个协作流程的核心是编排层里的任务状态机。一个任务从创建到完成，经历这几个状态：pending、scheduling、executing、reviewing、merging、completed、failed。状态机的好处是每个节点都能断点重试，某个智能体超时了，编排层可以重新调度，不会让整个任务卡死。

任务拆解采用的是"意图识别+模板匹配+动态补全"三重策略。第一重，意图识别模型判断用户请求属于哪类任务，比如"写方案""查数据""做培训"，对应到预设的流程模板；第二重，模板匹配把标准流程套上去，确定需要哪几个角色参与、先后顺序是什么；第三重，动态补全解决模板覆盖不了的部分，比如用户说"先看看竞品再写文案"，这就在原有模板里插入一个"竞品调研"子步骤，指定分析师智能体执行，执行结果作为文案智能体的输入。

角色路由采用策略模式。每个智能体注册自己的技能描述和适用条件，路由器根据子任务的语义相似度、历史成功率、当前负载三个维度综合打分，把任务分给最合适的智能体。这里有一个细节：不能只按语义匹配分任务，还要看负载。我们早期试过纯语义路由，结果数据分析智能体永远最忙，其他智能体闲置，整个任务链路被一个瓶颈卡住。

依赖管理是整个编排层最容易出bug的地方。一个任务拆成四个子任务，不一定都是并行关系：数据分析的结果要喂给文案策划，文案要等合规审查通过才能定稿。我们用一个有向无环图来表示依赖关系，图里每个节点是一个子任务，边代表数据流向。调度器只做一件事：找出所有入度为零的节点并发执行，每完成一个就解除依赖，循环直到所有节点完成。

有向无环图这个方案不算新，但在AI协作场景里有一个特殊之处：节点之间的"数据"不只是静态文件，还有一段段对话历史。所以我们在边上额外挂了一个"上下文切片"的引用，下游智能体读取上游结果时，拿到的不是上游的全部记忆，而是一个结构化的摘要。这能有效防止上下文被无关信息污染。

2.3 数字人呈现链路：同一个结果，如何"说"出协作感

结果聚合完成后，呈现层要做两类输出。第一类是标准交付物，比如文档、表格、图片，走正常文件通道；第二类是"汇报型数字人播报"，由数字人把协作结果用口语化方式讲给用户听。

这里值得展开的是"协作感"的呈现。我们不是用一个数字人把最终结果念一遍，而是让每个参与任务的数字人"各自汇报自己负责的部分"。比如复盘会方案这个任务，数据数字人会先说"我拉取了三个渠道的销售数据，发现华东区环比增长12%"，然后文案数字人接话"基于这个增长点，我建议发言稿重点突出华东打法"，最后合规数字人补充"需要提醒：数据披露要避开经销商内部结算口径"。

这种多数字人分段汇报的方式，本质上是在重复人类项目例会的结构。用户不需要看复杂的日志就知道谁做了什么、结论怎么来的。技术实现上，编排层会在结果聚合时给每条结论打上agent_id和"汇报顺序"两个标签，呈现层按标签顺序驱动对应数字人逐段出声。如果某个结论被标记为"需要人工审核"，该段播报会在开头加上一句"以下内容建议人工复核"。

这套机制从需求确定到落地花了三周，工作量不大，但用户体验的提升非常明显。

3. 技术选型：框架、模型与数字人方案的取舍过程

3.1 智能体框架：开源平台做底座，协作编排必须自研

立项时我们面临一个选择：用现成的智能体平台比如Dify或者Coze，还是直接自研编排层。当时的评估结果如下：

平台方案的优势在于快，Dify带可视化工作流、RAG管道、插件市场，Coze也有类似的生态，搭一个demo可能一两天就能搞定。但我们的场景有三个特殊要求是现成平台很难满足的：第一，多智能体需要共享一套协作状态，而Dify的工作流更偏向线性管道编排，每个节点做完就往下走，缺少"多个智能体并行工作并动态协商"的能力；第二，数字人播报需要对每一段输出做流式逐句的agent溯源，这个需求平台的工作流节点日志很难直接映射到前端数字人驱动；第三，我们要对接私有化知识库和内部系统API，平台方案里很多能力受托管方限制。

最终敲定的路线是：Dify用作单智能体的基础能力底座，负责RAG、普通工作流、模型路由这些成熟的部分，我们自己开发协作编排层和数字人呈现层。相当于Dify是每个员工的"个人工作台"，我们自研的部分是"项目协作平台"。

如果团队从零开始做，我不建议完全自研智能体框架，那会耗费大量时间在模型调用、上下文管理、工具协议这类重复劳动上。先用成熟平台把单点智能体跑通，把精力砸在协作层，是性价比最高的路径。

3.2 模型层：统一API网关与流式输出的工程化处理

模型接入方面，我们没有绑定单一模型，而是做了一个统一API网关，把DeepSeek、通义千问、智谱等厂商的接口封装成统一的OpenAI风格接口。这么做的原因很实际：不同任务对模型能力的要求差异极大。数据分析类任务对数学推理要求高，我们用DeepSeek或通义千问的旗舰模型；客服话术类任务对延迟敏感，我们用响应更快的模型版本；文案创意类任务需要发散性，可以让模型参数里的temperature调高。

网关内部做了两个通用的东西，值得单独说一下。第一个是SSE流式消息的统一封装，大模型输出是逐字返回的，但不同厂商的SSE数据格式有差异，有的带usage字段，有的不带，有的工具调用是在流中间突然出现的。我们在网关层把这些差异全部抹平，对外输出统一的事件类型：text_delta、tool_call_start、tool_call_end、final_message。下游不管是画聊天界面还是驱动数字人说话，只需要消费这几个事件。

第二个是工具调用的重试与降级机制。智能体经常要调内部API，比如查订单、查库存，这些接口偶尔会超时或报错。我们规定模型层的函数调用不直接在业务层执行，而是发一条工具执行消息到消息总线，由对应的API适配器异步执行，再把结果返回给模型层续写。这样一次工具失败不会打断整个智能体的生成流程，而是在下一次续写时告诉模型"上一轮工具调用失败了，请换一种方式处理"。

3.3 数字人方案：2D拟真优先，别一上来就上3D

数字人呈现层是项目里视觉上最吸引人、但技术坑最多的部分。我们对比过两条路线：3D超写实数字人和2D拟真数字人。

3D方案的优点是形象立体、动作自由度高，但缺点非常致命：开发周期长、GPU资源消耗大、口型同步难度高，而且一旦动作僵硬，用户会产生"恐怖谷"排斥感。2D拟真方案在大多数办公场景下的成本收益比远优于3D。我们最终选了一款2D数字人引擎，形象基于真人生成，用预录的真人形象素材做驱动，口型同步通过对音频特征分析驱动面部关键点变化来实现。

语音合成上纠结最久。市面上TTS产品很多，我们最终以"音色稳定性、流式合成延迟、多情感维度控制"三个标准来做选型。办公场景对声音的要求不是"好听"，而是"稳定"——同一个数字人每次说话的声线不能飘，否则用户会觉得人格分裂。我们选定的方案支持流式合成，也就是文本生成一句、合成一句、播报一句，不用等全文生成完再开口，首句延迟控制在400毫秒左右。

还有一个容易忽略的问题：数字人动作库的设计。我们给每个智能体配了不同的微动作偏好，比如数据分析师说话时习惯性看向侧面的数据面板，客服专家说话时手势幅度小、语速平稳。这种角色化的动作设定让多个数字人同时出现时不会显得像克隆人。动作不是越多越好，关键是和角色的性格设定一致。

4. 工程化落地的三块硬骨头：并发、状态同步与音画时序

4.1 并发控制：智能体太多，先抢的不是CPU而是工具

单智能体并发就是开几个线程池的事，多智能体并发的复杂度在于"工具竞争"。举一个真实踩过的坑：三个智能体同时处理一个任务，都需要调用企业通讯录API拉取人员信息，这个API没有做限流，结果一分钟内被调了八百多次，直接把对方的网关打挂了。

后来我们在编排层加了一个全局工具调用协调器，所有工具调用必须先向协调器申请令牌，令牌池按API的QPS上限动态配置。协调器内部实现是经典的令牌桶算法，每个工具定义独立的速率限制和并发上限。高优先级任务可以申请更高额度的令牌，但不能无限抢占。

工具竞争还有一个隐藏问题：分布式锁的粒度太大导致死锁。早期我们给每个共享资源一把全局锁，客户数据表的写入被锁住后，数据分析智能体等待写库，而另一个智能体拿着数据库连接等待着它释放上下文字段的锁，双方互相等，整个任务卡死到超时。排查半天才发现是锁顺序不一致。解决办法很简单：所有智能体申请多个锁时必须按固定顺序获取编号最小的锁，运行时检测锁等待超时，超时就主动回滚释放，避免死锁拖死任务。

这类问题在单机环境下很难暴露，一旦系统真实承载多个任务、多组智能体并行跑，锁的竞争粒度要提前设计好。

4.2 状态同步：共享记忆与上下文漂移的对抗

多智能体协作需要两种记忆：每个智能体自己的私有记忆，比如某个客服专家在处理这个客户的全程记录；以及多个智能体共享的协作记忆，比如"当前方案版本号是v3，已通过合规初审"。

私有记忆我们直接用各智能体独立的Redis命名空间，按task_id隔离。公共记忆则单独存放在一个共享存储里，只有编排层有写入权限，智能体只能读取与自己相关的公共记忆片段。这样避免了"文案智能体误改数据智能体的中间结论"这类事故。

真正难的是上下文漂移问题。尽管我们给每个智能体做了角色隔离，协作过程中仍然经常出现下游智能体基于"过时"的上游结论继续工作。典型场景：数据分析师的初版结论说"建议预算倾斜到华东区"，文案智能体拿着初版结论写完文案，但此时数据分析师基于新数据修改了结论，建议改为"重点押注华南区"，文案智能体毫不知情，继续用华东区前提工作，最后整份文案作废。

对抗上下文漂移，我们做三件事：第一，所有传向下游的数据必须带version_id，下游生成内容时会在页面侧边栏标注"本内容基于数据V2版本生成"；第二，下游智能体开始工作前，编排层会主动推送一次"协作状态变更摘要"，把上游新增或修改的结论用结构化方式通知到相关角色；第三，在最终结果聚合时加一个"依赖一致性校验"步骤，逐一检查每个子任务依赖的数据版本是否与最终版本一致，不一致的自动触发重算。

这套机制基本解决了漂移问题，代价是系统多跑一些校验时间。办公场景里准确性优先于速度，可以接受。

4.3 音画同步与"抢话"机制，数字人体验的生死线

数字人一旦开口说话，音画同步就成了体验的生死线。早期我们测试时发现，数字人的嘴型和声音经常有200到300毫秒的错位，用户反馈"看得很难受"。

排查链路是这样的：音频是逐句合成的，当模型输出第一句结尾时，TTS引擎已经在合成下一句，我们把下一句的音频立即喂给了播放器，但数字人画面的情绪切换和口型驱动还停留在上一句，于是出现了"声音已经说完了、嘴还在动"的情况。

最终我们把驱动模式改为"音频优先、画面跟随"：播报状态机里，画面帧的切换完全由音频播放进度回调触发，即当某一句音频真正开始播放时，才通知渲染层切到对应的口型动画；口型动画的嘴形参数实时从音频波形中提取，提取间隔不能超过40毫秒。

抢话问题发生在多数字人接力汇报时。两个数字人的汇报内容有重叠，编排层的汇报顺序标签没来得及更新，结果前一个数字人还没说完，下一个就开麦了，听起来像吵架。我们加了一个"主持人"机制：任何时刻系统只有一个数字人处于active状态，激活权由编排层的会话控制器持有。数字化播报前先发出intent_to_speak请求，会话控制器根据汇报顺序和优先级裁决，裁决通过后才返回speak_granted授权，拿到授权才能开麦。

一个更细的细节是"打断"策略。用户随时可以打断当前播报，说"停一下，我要问一下刚才数据部分的内容"，系统要把当前播报暂停、记录断点、把用户问题路由给对应的数字人，等回答结束再从断点继续。这个需求看着简单，实现上涉及音频流暂停、视频帧冻结、数字人表情切换成"倾听"状态、问题转写与路由，串起来是一个完整的状态机流转。我们在这个功能上花了两天调试状态流转，但做完之后整个系统才真正像个"可对话的协作团队"而不是"自动播放的录音机"。

5. 实际效果：一个完整协作任务的拆解与量化结果

5.1 跑通一次跨职能任务的全过程

拿我们系统上线后做得最多的一个任务来举例："生成新品发布会的全渠道推广方案，包括文案、预算分配、风险点提示"。

这个任务在编排层被拆成四个子任务：

• 数据分析智能体：拉取近六个月各渠道推广数据，产出性价比排名和预算倾斜建议，标记高转化渠道。
• 文案策划智能体：基于数据分析结论撰写三套推广文案，分别针对品牌号、短视频、社群渠道。
• 合规审查智能体：审核文案里的极限词、数据引用口径、代言人素材版权风险，输出修改意见清单。
• 汇总智能体：把前三者的产出合并成一份推广方案文档，并生成一页数字人播报脚本，由三个数字人分角色汇报。

任务跑起来的实际过程是：数据分析先跑，耗时约1分20秒，产出带version_id的结论；文案智能体在数据分析完成后启动，耗时约2分钟；合规审查在文案第一版定稿后启动，返回了两处需要修改的风险点，文案智能体收到修改意见后自动改了一版，再去送审，这次通过；最终汇总和数字人播报在全部完成后生成，总计耗时约4分钟。

这个任务如果人工来做，协调三个同事，等各自排期，顺利的话要一整天。系统把长尾沟通成本打掉了，用户只需要在最后审一遍方案是否可用。

5.2 关键指标与真实改进幅度

系统正式运行两个月后，我们统计了几个核心指标：

平均任务完成时长从人工基线的大约6到8小时降到了4到6分钟，指的是标准协作任务比如推广方案、周报汇总、培训材料生成。

人工介入率从初期的每次任务平均3.2次降到了0.8次。初期介入多是因为智能体工具调用失败或格式错误，两个月的工具缓存和策略优化后稳定下来。

结果采纳率，就是用户直接采用系统输出、不修改的比例，目前是六成左右。剩下四成中，一半是用户会在文案细节上做风格微调，一半是数据口径需要按业务部门自己的规则修订。

满足度回访里，用户提到最多的正面反馈是"能知道是谁负责哪部分"，归因清晰；提到最多的负面反馈是"合规审查有时候偏保守，把一些行业惯例表达也标记为风险"。后者我们已经在调合规智能体知识库里的规则粒度。

坦白说，系统现在的表现还远谈不上"替代一个团队"，它的核心价值是让确定性高、流程固定、文档密集的任务实现自动化协作，把人从重复协调中释放出来。真正需要创意判断和人际博弈的工作，系统依然只做辅助。

6. 复盘：那些文档里不会写的坑与应对思路

6.1 提示词注入与工具越权，安全要从第一版就考虑

多智能体系统的一个隐形安全风险是提示词注入被放大。单一智能体被注入，影响范围只有它自己；多智能体系统里，如果每个智能体的工具权限没有隔离干净，一个智能体被恶意注入后可能操纵另一个智能体的工具去做越权操作。

我们对工具权限做了三层隔离：每个智能体有一个明确的工具白名单；工具调用必须带上发起智能体的身份令牌；协作总线上的工具执行器会在执行前校验"发起者身份+目标资源归属"，如果不匹配直接拒绝。这个设计相当于给系统加了最基础的访问控制。

针对模型层面的注入攻击，比如用户通过对话历史诱导智能体输出系统提示词，我们在输入端加了一个分类器，检测对话中的可疑指令模式，命中后停止响应并转为人工接管流程。2026年智能体应用相关的安全清单已经在业界形成共识，其中提示词注入、不安全的输出处理、过度智能体授权这几项是最高发风险。我们的排查顺序就是照这个清单走的。

6.2 数字人形象、声音版权的合规细节

数字人项目有一个容易被技术团队忽略的环节：形象和声音的版权合规。我们初期直接采购了一批商业数字人形象素材，但没仔细审授权范围，后来法务提醒才发现其中两个形象的非商用授权不允许用于对客服务场景，紧急替换后损失了一周的工作量。

建议所有做数字人项目的团队，在立项时就把形象授权、声音版权、生成内容的使用范围一次性理清。尤其注意三个条款：是否允许用于商业用途、是否允许二次加工改造、是否限制在特定行业使用。如果数字人要做成"员工虚拟分身"，还需要取得对应真人的肖像授权和语音授权，并明确员工离职后该数字分身如何处理。

6.3 知识库冷启动：别让智能体"一本正经地胡说"

系统跑通之后我们发现一个尴尬情况：知识库冷启动阶段，由于没有足够的历史文档，数字人在培训场景里的回答经常编造流程，而且因为数字人表达自信，用户很难辨别真假。

解决办法：先给每个智能体划定"可信知识范围"，只允许引用已经完成清洗和向量化的文档库内容；当用户问题超出知识库覆盖范围时，数字人必须明确回答"这块内容我还没学习过，已为你转接人工"，不允许用模型先验知识补全。这个"不确定就承认不确定"的规则写进了每个智能体的系统提示词，并在知识库侧加了一个覆盖率检测，低于阈值时系统自动进入"半辅助模式"，优先转人工。

这个取舍牺牲了一部分"智能感"，但换来了可信度。办公场景里，一次胡说八道的代价可能抵消十次正确回答积累的信任。

6.4 数字人集群的渲染成本优化

多数字人同时在线时的渲染开销比预想的大。我们一开始每个数字人都是独立渲染实例，三个数字人同时在线时GPU占用率直接飙升到90%以上。

优化方案有两个：第一个是按需唤醒，没有发言权的数字人进入轻量状态，关闭口型驱动只保留头像和呼吸动画，这让常规场景下的渲染开销降低了60%以上；第二个是合批渲染，把多个数字人画面合成到同一张画布的不同区域，共用渲染上下文。这两个方案都做完以后，一台推理GPU可以稳定支撑5到6个数字人同时在线，基本满足一个中型部门同时并发的需求。

7. 下一步迭代方向与开放问题

系统当前状态可以正常支撑内部业务运转，但我们很清楚，距离一个"开箱即用的协作办公产品"还有不少路要走。

第一个方向是让编排层支持用户自定义协作模板。目前任务拆解依赖预设模板，业务人员想调整流程需要开发介入。我们正在把模板编辑器可视化，让运营人员可以直接拖拽生成"角色+子任务+依赖关系"的流程图，系统自动生成编排配置。这一步做通，才能算真正让业务自运转。

第二个方向是记忆增强。当前智能体的长期记忆还是基于向量数据库的显式存储，跨任务的隐性经验积累几乎没有。比如合规审查智能体每次修正一个风险点，下次面对相同问题时能不能借鉴上次的判断逻辑，我们希望引入轻量的经验回放机制，把每次人工修正记录转化为后续决策的参考示例。

第三个方向是现有办公软件生态的集成深度。现在接入了消息通知和文档同步，但离真正的办公自动化还有距离：我们希望数字人能主动在钉钉群里发起协作、@具体人员进行审批、根据会议日历自动准备材料。这些场景在技术上都是可以实现的，主要挑战在权限边界与人工确认的衔接设计上。

如果你们也在做类似的系统，我的个人建议是：先别贪多，把一个"三位智能体协作完成一个高频任务"的闭环打磨到极致，再横向扩展角色和场景。多智能体系统的复杂度是指数增长的，每多一个角色，状态同步和冲突处理的工作量都会翻倍。先从三个角色、一个核心任务、一套完整的数字人呈现链路开始，跑通之后你自然会知道下一个瓶颈在哪里。