最近做多人协同空间时，我反复碰到一个看似很小、实际很难的问题：数字人到底该不该在群里说话？
这个问题不解决，后面的数字人能力再强，也很难进入真实业务。因为业务协作不是一个人问 AI，再等 AI 给答案。真实业务更像一个群聊：采购、法务、风控、财务、数据合规、业务负责人都在同一个空间里，有人补材料，有人确认边界，有人提醒风险，有人推动下一步。有些消息只是同步，不该打扰；有些消息没有明确 @ 数字人，但语境已经很清楚，它应该主动接上。所以这类系统的关键词，不是问答。
是磋商。
这篇文章真正要讲的是：多人协同数字人的核心能力，不是生成一段漂亮回复，而是在真实群聊上下文里判断“我该不该介入、以什么身份介入、要不要交给更专业的数字人”，并且让每一次介入都能被追踪、复盘和评价。
这次项目给我的最大感受是：数字人不是一个聊天气泡，而是一个有身份、有边界、有运行状态、有审计记录的协同参与者。
一、这不是聊天机器人，而是业务磋商空间
如果只是把一个 AI 助手拉进群聊，它不会自然变成数字同事。
普通聊天机器人通常是一问一答。你问，它答；你不问，它最好别出声。但业务协同空间不是这样。这个空间里既有人，也有多个数字人。每个数字人不是同一个模型换个名字，而是有自己的职责边界：采购数字人负责供应商准入、采购推进、授权材料、比价和采购口径；合同审批数字人负责合同主体、授权链路、条款风险、转授权和签署材料；风控数字人负责风险等级、阻断条件、缓释措施和审批建议；数据合规数字人负责数据使用边界、隐私合规、权限范围、数据出境和留痕。
财务结算数字人负责付款节点、发票、授信额度、账期和结算风险。所以产品定义不能是“一个 AI 助手进入群聊”。更准确的定义是：多个数字员工进入一个业务协同空间。一旦这样定义，最重要的问题就变了，不再是“数字人会不会回答”，而是“它有没有资格在这一刻发言”。
二、第一条产品规则：空间主责方优先
没有明确 @ 的时候，不能让所有数字人一起抢答，必须先有空间主责方。
真实业务空间通常有主责方。采购协同空间里，采购数字人就是空间主责数字人。它不一定回答所有问题，但它应该优先判断是否需要介入。比如有人在群里问：
“谁能告诉我，当前这个单子最大的风险是啥？”
这里的“谁”不是只指人类成员，也可能指数字人。系统不能简单把这句话判成人对人聊天，而要看上下文：前面是不是在讨论供应商授权材料、合同主体、数据出境、提前付款或发票风险？如果这是采购空间，采购数字人应该先给出整体判断；如果判断里涉及合同条款，就 @ 合同审批数字人；如果涉及阻断条件，就 @ 风控数字人；如果涉及数据出境，就 @ 数据合规数字人。我们最后确定了一条朴素但有效的规则：无 @ 时，空间主责方先判断。
主责方不接时，专业数字人补位。显式 @ 数字人时，被 @ 的数字人必须进入处理流程，但不等于无条件给结论；如果缺少材料，就先澄清；如果涉及高风险动作，就进入人工确认。数字人回复中 @ 了其他数字人，对方必须接力。最多 5 轮，防止数字人之间互相循环。
三、意图识别不能靠关键词，要靠分类引擎
只靠关键词召回数字人，容易造成误唤起；真正可靠的是结合上下文判断意图。
我们一开始也遇到过这个问题。如果系统只看关键词，很容易过度积极。群里出现“风险”，风控数字人就想说话；群里出现“合同”，合同审批数字人就想进场。看起来灵敏，实际并不稳定。因为同一个词在不同上下文里，含义完全不一样。“这个风险先等法务确认”，可能是在安排人类同事工作，这时数字人不应该插话；“谁能判断当前最大风险”，则是开放式任务请求，这时数字人应该介入。所以我们做的是分类引擎，而不是关键词命中。
分类引擎读取最新消息、最近 8 条上下文、当前空间主责方、候选数字人身份、群成员列表、结构化 @ 信息、最近是否有数字人回复过，以及规则层的初步判断。然后输出一个结构化结论：是否应该回复、属于哪类意图、把握有多大、目标对象是人还是数字人、应该自动回复还是静默、澄清、人工审核，以及判断证据是什么。
我们把常见意图分成几类：明确 @ 当前数字人、明确希望数字人做任务、对数字人上一轮回复追问或修改、明确发给人类成员、普通群聊同步，以及不适合自动回复的高风险场景。这样一来，系统判断的不是“有没有某个词”，而是“这句话在当前协同空间里到底想让谁做什么”。
这里还有一个重要边界：模型判断不能直接进入业务动作。分类结果必须经过结构校验，意图类型、置信度、目标对象和回复方式都要落在预设范围内。把握不足、解析失败、没有证据、目标对象冲突时，默认走静默、澄清或人工审核，而不是强行自动回复。有了这层约束，系统才不是“命中规则就回答”，而是把语境理解变成可控决策。
四、智能路由解决的是“谁有资格进场”
主责方优先不是主责方独占，专业数字人也要能被语境召回。
早期版本里，如果没有 @，我们先让当前采购数字人判断。这个逻辑能跑，但不够细。比如在采购空间里，用户突然问：
“这个数据出境风险怎么控？”
采购数字人是空间主责方。但数据合规数字人明显也应该进入候选队列。如果只看空间主责方，系统会漏掉专业问题；如果只看关键词，系统又会过度唤起。所以我们加了一层智能路由。它不负责生成回复，只负责判断哪些数字人值得进入候选队列。它读取空间主责方、群成员、最新消息、最近上下文、显式 @、业务对象，以及各数字人的职责描述，然后输出候选数字人列表、优先级和理由。关键词召回仍然保留，但只作为兜底。最后是否回复，仍然交给分类引擎判断。这套设计更接近真实群聊。
不是谁看到关键词就抢答。而是谁在当前语境下最应该参与。
五、真实项目里，数字人回复走的是服务端运行链路
数字人不是前端页面里的一个角色名，而是后端真正调度起来的运行单元。
在这个项目里，前端只负责两件事：把群聊消息提交上来，并把服务端返回的结果展示出来。真正的判断、路由、会话复用和数字人回复，都在服务端完成。
一条群聊消息进入后，服务端会先读取当前业务线程、空间主责方、群成员、最近上下文和结构化 @ 信息。随后进入计划阶段：先判断哪些数字人应该进入候选队列，再对每个候选数字人做意图分类，决定它应该自动回复、保持静默、先澄清，还是进入人工审核。
如果某个数字人被确认需要回复，服务端会找到它绑定的运行配置，并按当前业务线程、数字人身份、运行配置和运行环境查找可复用的运行会话。命中已有会话时，就继续沿用；没有命中时，再创建新的会话。这里不能只做简单查询，还要处理重复提交和同时创建的问题，避免同一个数字人在同一线程里被创建出多个会话。
随后，服务端把用户消息发送到对应会话，接收真实数字人返回的过程结果，并把回复实时推回前端。如果返回结构化产物，就转成群聊里的卡片；如果某个外部动作需要人工确认，就返回确认卡片并暂停当前动作。运行结束后，服务端再补写本轮状态，记录最后位置、耗时、结果类型和错误信息。
这样做的好处很直接：前端不保存模型密钥、平台访问凭证或第三方工具凭证；数字人的回复也不是页面本地生成，而是来自真实运行的数字人会话。更重要的是，整条链路能记录会话、过程、耗时、错误和决策证据，后面才能做审计和回放。
六、运行会话复用，是从单次回复走向连续协作的关键
如果每次回复都新开一个运行会话，数字人就没有连续工作状态。
最早版本里，每次数字人回复都会新建一个运行会话。真实业务线程不适合这样做。同一个数字人应该有连续状态，否则长期上下文、外部工具状态、排障和成本都会变差。所以我们改成了复用策略：同一个业务线程、同一个数字人、同一套运行配置和同一个运行环境，复用同一个运行会话。
在同一个业务线程里，采购数字人一直使用自己的同一个会话；合同数字人、风控数字人也各自有自己的会话。服务端会保存这组映射关系，记录会话编号、业务线程、数字人身份、运行配置、运行环境、创建时间、更新时间、最后返回位置和轮次计数。
我们实际验证过：同一个业务线程连续两轮调用，使用的是同一个运行会话，轮次计数从 1 增加到 2。这一步很关键。数字同事不应该每次开口都像刚刚进入这个空间，它要知道自己在同一个业务线程里刚才做过什么。
七、真正像产品的地方，在异常和同时触发处理
一个看起来能跑的数字人系统，和一个能上线的数字人系统，中间差的往往不是模型能力，而是运行控制。
多人协同空间里，消息不是整齐排队出现的。用户可能连续发送两条消息，也可能刷新页面重复提交；两个数字人可能几乎同时被唤起；同一个数字人可能正在输出，用户又补了一句“等一下，我刚才说错了”。如果系统只按“收到消息就调用模型”来做，很快就会出现重复回复、上下文错位、旧结果覆盖新结果的问题。
所以这里必须有几条底线。第一，用户消息要有唯一标识，同一条消息重复提交时不能触发两次有效运行。第二，会话创建要可重复校验，同一个业务线程、同一个数字人、同一套运行配置和同一个运行环境，只能稳定落到一个会话。第三，返回过程要有顺序控制，前端展示的是当前轮次的输出，旧轮次迟到的结果不能覆盖新状态。第四，超时、断开、外部工具失败都要能落到可见状态，而不是让界面一直转圈。
人工确认也不能只是一个按钮。它要绑定具体外部动作、参数摘要、风险说明和发起轮次。人确认的是这一轮、这个数字人、这一次动作，而不是泛泛地点了一个“同意”。只有这样，后面审计时才说得清楚：谁在什么时候批准了什么动作，数字人依据什么继续往下走。
八、审计决定系统能不能上线
多人协同里最危险的不是数字人说错一句话，而是你不知道它为什么说。
多人协同系统里，有两个问题一定会出现。第一个是：数字人为什么突然说话？第二个是：为什么该说话时它没说？如果回答不了这两个问题，系统就很难进入生产。所以我们加了审计。每一轮运行都会写入服务端审计存储。审计内容包括用户输入、当前空间主责方、群成员、最近上下文、初始候选队列、每个数字人的判断结论、是否自动回复、置信度、意图类型、证据、数字人回复内容、卡片产物、会话编号、耗时、用量和成本估算，以及错误信息。
这意味着以后出现误唤起、漏回复、循环 @、接口失败，都可以回放。审计不是锦上添花，它是上线前的稳定性能力。企业级数字人不是“模型表现好”就够了，它必须能被认证、授权、约束、暂停和追责。
九、评价集让模型调优不靠感觉
意图识别如果没有评价集，很容易依赖主观判断；评价集就是把主观判断拉回稳定工程。
今天改一个提示词，明天加一条规则，每次改动看起来都合理，但很可能把别的场景打坏。所以我们做了 60 条业务群聊评价集，覆盖采购空间、合同空间、风控空间、数据合规空间、财务空间、显式 @ 数字人、@ 人类成员、开放式“谁/哪位/有没有人”、连续追问、静默场景和多数字人接力场景。每条样本都标注期望结果：谁应该第一个回复，或者是否应该保持静默。
我们还做了一个只跑计划阶段的检查入口，专门验证路由和意图判断，不触发真实数字人回复。这样可以低成本做回归测试。最终结果是 60/60 通过，中间也抓到过真实问题。比如 @采购负责人 曾经被错误识别成 @采购数字人，原因是“采购”也是采购数字人的短别名。后来我们按完整 @ 对象识别，而不是按文字包含判断，避免短别名误伤人类成员。还有一句：
“那就把上面的采购结论改成可以补正后推进。”
它曾经因为里面有“可以”，被误判成普通人类确认。后来我们把“上面、刚才、继续、补充、改成、调整、结论、口径”这类连续任务表达单独识别。这样主责数字人才能继续响应。这些问题如果没有评价集，很难稳定发现。
十、前端体验要让它像一个正式产品
用户不会因为你接了真实数字人运行链路就自动信任产品，他先看到的是体验是否像一个正式系统。
前端上，我们也做了几条关键约束。输入框固定在底部，不会被消息往下顶；对话区域高度固定，历史消息内部滚动；数字人回复支持边生成边展示，并清理多余格式符号，像真实群聊成员说话。输入框用 @ 唤起成员选择，符合群聊习惯。
显式 @ 数字人时，对方必须回复。数字人回复中 @ 其他数字人时，对方接力。运行监控面板要展示关键运行状态，而不是用普通信息卡片替代。配置入口放在右上角齿轮里。模型密钥、平台访问凭证和外部工具凭证只放在服务端，不进入前端本地存储。这些细节看起来分散，但它们共同决定一件事：用户会不会把它当成一个真实产品，而不是一个只适合展示的页面。
十一、这套系统可以拆成五层架构
如果把多人协同数字人只理解成一个群聊页面，就会低估它背后的系统复杂度。
这套系统真正稳定下来后，可以拆成五层。第一层是协同空间，它定义当前业务场景，比如采购协同空间、合同协同空间、风控协同空间、数据合规协同空间。每个空间都有一个主责数字人。主责数字人不是最高权限，它的意义是先承担上下文判断责任。第二层是群聊上下文，它包括最新消息、最近 N 条消息、群成员、结构化 @、上一轮数字人回复、业务对象和当前线程状态。没有这一层，数字人只能看一句话；看一句话，就一定会误判。
第三层是智能路由，它不写答案，只判断谁有资格进候选队列。空间主责数字人通常会进入候选；显式 @ 的数字人一定进入候选；语境强相关的专业数字人也进入候选。关键词召回可以给智能路由提示，但不能直接决定发言权。第四层是意图分类引擎，它对每个候选数字人做独立判断：该不该说话，为什么该说，置信度多少，是回复、静默、澄清，还是要人工审核。第五层是真实运行层。如果确定要回复，就调用真实数字人运行会话。
运行层负责会话复用、返回过程监听、产物卡片、人工确认暂停、实时输出和审计写入。这五层缺一不可。少了协同空间，数字人没有组织位置。少了上下文，意图判断会变成猜测。少了智能路由，候选召回会过宽或过窄。少了分类引擎，数字人会抢答。少了真实运行层，系统就只剩下页面交互。
十二、介入模式不能只有“回复”和“不回复”
真实业务里，数字人不应该只有开口和闭嘴两个按钮。
很多误唤起问题，来自产品把决策做得太粗。系统如果只判断“回复”还是“不回复”，在简单问答里够用，放到多人协同空间里就不够。因为真实业务至少有四种介入模式。第一种是自动回复。适合明确 @ 数字人、明确派任务、对数字人上一轮结果做连续追问，且风险等级可控的场景。比如“@合同审批数字人 看一下这个转授权有没有问题”。这类消息不需要再犹豫。被 @ 的数字人应该直接进入回复流程。第二种是静默。适合人类成员之间安排工作、普通同步、情绪表达、寒暄、无关讨论。
比如“这个风险先等法务确认”。这句话里有“风险”。但它是在安排人类同事。风控数字人不应该因为看到关键词就跳出来。第三种是澄清。适合任务方向像是给数字人，但关键输入缺失。比如“帮我看看这个供应商能不能推进”。如果上下文里没有供应商名称、授权材料、采购金额、交付范围，数字人不该硬答。它应该先问缺口。第四种是人工审核。适合高风险动作。比如自动发起付款、批准合同、写入外部系统、发送正式邮件、触发付费工具调用。这类动作可以由数字人准备材料和建议。但不能直接执行。
必须返回提示卡片，等待人确认。所以分类引擎的输出不能只是一句“要回复”，还要同时说明意图类型、置信度、目标对象、回复方式、判断证据和风险等级。这样系统才能把“说话权”“执行权”和“审核权”分开。
十三、数字人接力必须有刹车
多数字人协同最容易被低估的风险，是它们彼此 @ 到停不下来。
单个数字人误回复，问题还比较容易定位。多个数字人互相接力，复杂度会突然上升。采购数字人 @ 风控数字人。风控数字人又 @ 合同审批数字人。合同审批数字人再 @ 采购数字人补材料。如果没有控制，这个链条可能一直循环。所以我们给接力机制加了几道刹车。第一，轮次上限。同一条用户消息触发的数字人接力，最多 5 轮。超过后必须停止，并把当前状态交给人。第二，已访问数字人集合。同一轮链路里，已经回复过的数字人不能被无条件重复唤起。除非用户显式 @ 它，或者分类引擎给出高置信连续追问。
第三，接力原因必须写入证据。数字人不能只是写“建议风控看一下”。它要说明为什么需要风控。比如“涉及预付款比例高于常规账期，需要判断是否形成阻断条件”。第四，接力对象必须有职责匹配。采购数字人不能随便 @ 财务。只有付款节点、发票、授信额度、账期、结算风险相关时，财务结算数字人才应该进入。第五，链路结束要有收敛输出。不能让每个数字人都只补一段建议。最终主责方要把结论收束成一句能推进业务的话。
比如“当前可补正后推进，但合同签署前必须补齐授权链路，并由数据合规确认是否涉及出境”。这就是多人协同和多人发言的区别。多人发言只是在群里堆答案。多人协同要让答案收敛成业务结论。
十四、上线前要检查的不是模型分数，而是运行闭环
多人协同数字人能不能上线，不能只看几次回答好不好。
真实场景里，最容易让人误判，因为你会遇到混乱群聊：有人说半句话，有人 @ 错对象，有人把人类成员和数字人混着叫，有人连续追问，有人只是同步信息，也有人要求数字人做一个不该自动做的高风险动作。所以我更建议用一张上线检查表。第一，空间模型是否清楚。每个空间有没有主责数字人？它的职责是什么？什么情况下可以不回答？第二，成员模型是否清楚。人类成员、数字人成员、群组别名、短别名、结构化 @ 是否能准确区分？
第三，上下文窗口是否可解释。最近 8 条消息够不够？是否要按线程、业务对象、附件、审批状态补充结构化上下文？第四，智能路由是否只做候选召回。它不能直接生成回复，也不能绕过分类引擎。第五，分类引擎是否输出证据。没有判断证据的结论，不应该进入自动回复。第六，运行会话是否复用。同一个业务线程、同一个数字人、同一套运行配置和运行环境，是否稳定命中同一个会话？
第七，密钥是否只在服务端。模型密钥、平台访问凭证、第三方工具凭证都不应该进入前端本地存储。第八，审计是否足够回放。误唤起、漏回复、接口失败、人工暂停，能不能根据审计记录复盘？第九，评价集是否覆盖静默场景。很多系统只测“应该回答”，但真正难的是“应该不回答”。第十，前端体验是否像真实工作台。输入、实时输出、@ 选择、消息滚动、配置入口、运行监控都要稳定。这张检查表比单次模型分数更重要，因为它检查的是系统能不能进入组织流程。
十五、真正的落点：治理数字人的发言权
未来的难点不是让 AI 能说话，而是让 AI 知道什么时候该闭嘴。
这次项目表面上是在做一个群聊协同空间，本质上是在研究一个更重要的问题：当业务协同从人与人，走向人与数字人共同磋商时，系统应该如何决定数字人的发言权？数字人不能太沉默，太沉默就没有价值；数字人也不能太积极，太积极会干扰人类协作。所以关键不是“让 AI 会回答”，而是“让 AI 知道什么时候该回答”。我们最后形成了几条原则：明确 @，必须回应；无 @，空间主责方优先判断；开放式“谁/哪位”，不等于人类专属；判断必须结合滑动窗口上下文；专业数字人按语境补位。
数字人接力必须受轮次控制。所有介入都要可审计、可回放、可评价。这些原则让数字人不再只是一个被动工具，它更像业务协同空间中的数字同事。它知道自己什么时候该说话，什么时候该闭嘴，什么时候该把问题交给另一个更专业的数字人。如果你明天就想把这套方法迁移到自己的业务里，不要先问“我要几个数字人”。先选一个真实协同空间，写清楚主责方是谁，再列出人类成员和数字人成员，接着定义 20 条典型群聊样本。每条都标注：谁该回应、谁该静默、谁该接力、什么时候必须人工审核。
然后再去做智能路由、分类引擎、运行会话复用、审计和评价集。这条路径并不复杂。它就是把“会聊天的 AI”，一步一步变成“有组织位置的数字同事”。
这也是我认为多人协同模式最有价值的地方。它不只是让数字人进群，而是在给数字人建立一套组织协作规则。当规则、运行链路、审计和评价集都建立起来，数字人就不再是一个“随时可能插话的机器人”。它开始像真实同事一样参与磋商：该说的时候说清楚，该等的时候保持安静，该接力的时候把问题交给更专业的人或数字人。这才是企业 AI 从问答工具走向协同系统的关键一步。
想体验或者交流的，加微信找我。