数字员工运行与前台协作框架产品方案
版本：v4.0 | 创建日期：2026-09-20
需求来源：用户沟通（2026-09-17 / 18 多轮）、现有 V4/V5 后台 Demo、v0.7 前台 Demo
优先级：P1
文档状态：草稿（后台配置规则、补充任务机制、闭环与防线、界面承载方式已确认）
本次变更：v2.0 → v3.0 分两段处理。前置表、一、需求概述、2.1 整体产品方案、2.2.1 后台保持 v2.0 原文（含示意图与设计图地址），只做小逻辑修补与补回被删信息；2.2.2 前台及之后为深度改造，内容以 2026-09-17 / 18 多轮沟通结论为准。v2.0 原文归档保留。
需求变更记录
| 变更日期 | 变更人 | 变更内容 |
|---|---|---|
| 0917 | 孙浩 | 9 月底 demo 核心场景 后台的部分 1. 组织架构 -人员页面适配数字员工不做特殊调整，对象详情页都与人员一致；所有数字员工的编辑都在数字员工一侧 2. 新建规则-触发时间可 先仅字段变更 3. 执行日志 9 月份不必须 4. 数字员工后台的编辑页，参考 agent，左右结果，顶部的步骤栏没有 5. 数字员工没有删除，只能停用； 6. 一期可能也先做一个 agent，不必等 sfa 侧的 agent出来 7. 前台的触发先都靠自动化，后期主动的部分再和 sfa 沟通 前台的阶段流程 8. 需要决策是单独的任务组件还是关联到阶段流程上，待讨论，一期先成本最小化，可先以动态-承载任务的方式承载 9. 需要 demo 新建销售记录填表单的任务场景，ask user question 不在 demo 的必要场景中 10. @和企信里@ 数字员工的交互场景 11. 数字员工需要适配产出物的形态，例如 md、html 的效果，文字的部分是 rtc 卡片，附件可以单独消息发出来 |
| 0920 | 孙浩 | 和 sfa 对齐数字员工的背景，结论 1.工作时机部分，区分自定义的和开箱的，需要 sfa 业务侧提供预设的触发场景，这些是当选择了商机对象时，默认展示出来的，租户管理员可以关闭部分预设时机 2. 商机不一定所有都需要有阶段推进器的，实际上根据不同的行业，商机推进的规范都不同，比如制造业推进商机的规范是满足 32 问，解决了， 商机的数据就流转完了；因此数字员工对商机的理解，也根据不同的行业不同，这层规范是定义在 agent 一层的， 数字员工不需要理解这层； 3. 前台任务的组件，包含 数字员工给自己发的任务和数字员工给人发的，都需要展示在一个组件里，这个组件待决策是谁支持；包括任务的类型，都有哪些需要 |
依赖需求 Story 列表
| ID | 需求描述 | 涉及端与开发人员 | 是否有依赖项 | 备注 |
|---|---|---|---|---|
| 无 | 当前为产品框架方案，尚未进入研发 Story 拆分 | 不涉及 | 否 | 后续交互稿确认后再拆分 |
本版说明（v3.0，2026-09-18）：用户 2026-09-18 明确划分范围——「后台及后台之前」是用户整体 review 过的内容，结构与示意图不得改动，只允许小逻辑修补与补回被删信息；「后台之后」（2.2.2 前台及之后）才是本轮要深度改造的部分。v3.0 初稿曾把 2.1 与 2.2.1 一并重写，已按上述范围回退为 v2.0 原文。v2.0 原文完整归档在
历史版本/。
>
关联材料：
地基决策清单.md（决策依据与逐条结论）、前台Demo改造清单.md（前台改造逐项对照）、数字员工方案重构评估与框架提案_v1.0_20260917.md（v2.0 的结构性评估）。
>
后台 DEMO：
数字员工V5_整体交互Demo.html；前台 DEMO：数字员工阶段推进与业务群协同样稿_v0.7.html。
一、需求概述
1.1 产品背景
数字员工是本期从零打造的新产品，当前没有正式客户立项，属于产品方向验证。
下表为需求共创中收集到的典型反馈。这是整合稿，不是特定客户的原文记录；正式立项前需替换为真实反馈原话与截图。
| 需求编号 | 反馈角色 | 业务场景 | 反馈要点 | 示意图 |
|---|---|---|---|---|
| FB-01 | 销售经理 | 商机阶段推进 | 团队对商机当前阶段的认知不统一：推进了十天，也说不清现在是在方案准备还是价格谈判 |  |
| FB-02 | 一线销售 | 堵塞与任务 | 知道卡住了，但说不清卡在哪、该谁处理；阶段任务经常逾期了才被发现 | 无 |
| FB-03 | 一线销售 | AI 工具 | 用过 Agent 侧边栏，要自己想出问题才能问；问出来的结论只有自己知道，还得再同步给团队其他人 | 无 |
强协作型的业务场景，例如【商机】推进缺一个主动性的「项目经理」
商机不是线索那种模糊信号，它是一个明确的、需要按阶段推进的打单机会。它的推进天然是多人协作：每个阶段都有不同的堵塞点、不同的待完成任务、不同的责任角色。
它必须有一条主线——阶段流程（阶段推进器），商机天然关联完整的阶段流程。没有这条主线，团队对商机的认知就是散的：推进了十天，也说不清现在是在方案准备阶段还是价格谈判阶段。
现有 Agent 产品为什么解决不了
业务侧已经有预设 Agent（如商机赢单教练、客户经营助手），但它是一个侧边栏：需要团队成员主动提问，产出（方案文档）只有提问的人看到，还要由提问的人再同步给其他人。
这类赋能的本质是多角色对 Agent 的单向互动。它是闭塞的，没有打通角色之间的协作关系，缺一个主动协作的角色。
数字员工的定位
补上那个缺失的「项目经理」：围绕业务的阶段流程主动工作——按每个阶段的定义推动任务执行，把任务分派给对应的团队角色，按预定时限跟进，并主动推动阶段流转。团队不需要各自闭塞地盯着阶段，由数字员工全程把控。
| 对象 | 价值 |
|---|---|
| 团队角色 | 不用各自盯阶段，任务直接派到手上，明确什么时候要交 |
| 销售经理 | 阶段推进有统一主线，堵塞点、逾期和数据缺口自动浮出来 |
| 组织 | 推进方法从“个人经验”变成“可复用的岗位能力”，换人不断档 |
未来的价值
用户对 AI 越熟练，越不愿意主动去“问”。他们更希望 Agent 在工作过程中就预设地完成上下文思考、给出初步结果，人只需要确认。
数字员工就是这个方向：从「人找 Agent 问」变成「Agent 先做、人来确认」。
1.2 竞品现状
数字员工这个概念不新，但把它真正落到业务系统里、成熟可用的产品确实很少。需要区分两个层次：
| 层次 | 成熟度 | 代表产品 |
|---|---|---|
| 身份与治理层：跨产品的 Agent 身份与治理平面，本身不是业务产品 | 已有正式商用产品 | Microsoft Entra Agent ID 与 Agent 365（2026-05-01 正式商用，IT/安全侧控制平面） |
| 业务场景层：有组织身份的数字员工被任命到具体业务记录，并持续驱动该记录的流程 | 未找到成熟产品 | — |
两点必须说清楚：
- 第一层的产品形态是"身份平面"，不是业务产品。 Entra Agent ID 服务于 Copilot Studio、Foundry、Teams、Dynamics 以及第三方 Agent，是一层跨产品的身份与治理基础设施。它跟"某个业务系统里的岗位数字员工"不是一回事。
- 所以第一层的成熟只验证了机制，没有验证产品形态。 它说明「Agent 需要独立身份、需要有人对其存续和权限负责」这个判断成立，不能说明「CRM 里应该有一个岗位数字员工」被验证过。
本方案落在第二层：机制上复用第一层，产品形态上没有现成参照。
身份与治理层参照
| 竞品 | 相关能力 | 对本方案的启示 | 官方来源 |
|---|---|---|---|
| Microsoft Entra Agent ID | Agent 拥有独立身份对象与独立用户账号；必须指定一名 Sponsor（业务责任人）对其生命周期与权限负责，Sponsor 离职时自动转给其上级；另有 Manager 表示组织层级中的汇报关系 | 机制上「Agent 需要有人对其存续与权限负责」成立；本方案已有汇报对象，把归属职责挂到该字段即可，不新增字段 | Microsoft Learn |
| Microsoft Agent 365 | 提供 Agent 注册表、统一可观测、生命周期与安全治理；按人头授权 | 治理能力由平台统一提供、不由租户逐项配置，与本方案运行时的定位一致 | Microsoft Learn |
| Workday Agent System of Record | 在员工系统记录中为 Agent 建立档案 | 「把 Agent 纳入组织」在 HR 语境下已有产品化尝试（正文未取得，待验证） | Workday |
业务流程层参照
| 竞品 | 相关能力 | 对本方案的启示 | 官方来源 |
|---|---|---|---|
| Salesforce Path | 按销售阶段展示关键字段和 Guidance for Success | 阶段事实与行动指导可以同屏，但指导不替代阶段状态 | Salesforce Help |
| Dynamics 365 Business Process Flow | 流程实例关联业务记录，阶段由步骤和必填条件控制 | 阶段实例应继续作为稳定控制面，不宜用 AI 任务替代 | Microsoft Learn |
| Dynamics 365 Opportunity Research Agent | 围绕商机生成摘要、洞察和可执行建议 | AI 更适合形成解释和下一步建议层，而不是重复流程对象 | Microsoft Learn |
| HubSpot Playbooks | 支持结构化问答、更新关联属性和创建记录 | Ask、字段编辑和创建/关联数据应区分任务类型并复用业务组件 | HubSpot Knowledge Base |
| SAP Joule Agents | 以业务流程知识驱动的 Agent，官方定位为“像同事一样工作” | Agent 嵌在业务流程里执行是可行路线，但这些 Agent 没有组织身份 | SAP |
上述资料于 2026-09-17 核验。共同趋势是“确定性流程和业务数据负责状态，AI 负责摘要与建议，具体动作复用已有业务能力”；这也是本方案不建立阶段 Agent 主任务的外部参照。
二、产品方案
2.1 整体产品方案
数字员工：是一名真正进入企业组织架构、有独立权限的、且围绕数据进行业务推进 AI 员工。
五层职责
| 层级 | 核心职责 | 作用 | 租户是否可配置 |
|---|---|---|---|
| CRM 业务底座 | 对象、字段、相关团队、数据权限、任务、动态 | 提供真实业务数据、权限和操作回执 | 沿用现有 CRM 配置 |
| Agent 本体 | 业务理解、规划、推理、Skill/Tool 使用方法、内容与操作意图生成 | 决定“这件业务工作应该怎么做” | 跟随 Agents 平台 |
| 数字员工岗位 | 员工身份（基本信息）、岗位使命、负责对象、Agent 绑定、数据和功能权限 | 决定“谁以什么企业身份承担什么责任” | 是 |
| 业务触发部署 | 业务事件/定时任务 | 配置阶段之外的额外目标或补偿检查，不定义当前阶段该做什么 | 是 |
| 数字员工运行时 | 阶段常驻、理解任务类型，创建任务、状态、去重、鉴权、协作、确认、重试、恢复、审计和结果投影 | 决定“阶段工作如何持续、工作如何可靠安全地运行并完成” | 否，平台统一提供 |
2.2 具体方案说明
2.2.1 后台：怎么创建和管理一个数字员工
身份、岗位与组织继承
创建入口与组织落地
数字员工只在 AI 平台的「数字员工」入口创建，不在组织架构中手工新建人员。只有完成创建流程的固定三步，发布成功后，才生成业务数据进入到组织架构中
设计图地址如下：
后台 DEMO 如下：
| 步骤 | 描述 | 示意图 |
|---|---|---|
| 1 平台基本信息 | 1. 姓名、头像、 2. 不配置手机、登录账号、密码和个人邮箱；数字员工不通过登录方式进入系统。 3. 同一主属部门内，同一种负责对象只允许存在一名启用的数字员工。例如商机相关工作统一由“商机推进官”承担；“报价核验 Agent”可以作为其调用的专业能力，但不能成为第二名负责商机的数字员工。（可参考 claude tag 的产品设计） 4.当管理员创建第二名负责同一对象的数字员工时，系统不允许启用，并提示“[业务对象]已由[数字员工名称]负责”。；在数字员工列表中，支持对数字员工启用、停用；停用时，不支持删除（等同于人员的逻辑），即使某对象的数字员工已被停用，也无法继续再创建一个数字员工 5. 创建完成后，在列表中点击编辑后，数字员工的编辑页，为左右布局 |    |
| 2 选择执行能力 | 1. 绑定单个 Agent 或 Team 小队 2. Teams 目前AI 平台正在建设，参考图如下 3. 一期demo 可先不支持小队 4. 编辑数字员工时，可调整执行的 agent/小队，仅对新建工作生效，正在执行的 Run不中断、跑完为止；   |   |
| 3 配置工作时机 | 1. 主要分为业务事件、定时任务两类触发规则 2. 业务事件的触发时机类型分为【字段变更】、【团队人员变更】、【关联数据新增】；可配置当前业务对象所属的业务数据过滤条件范围；包括设置本次触发要做什么 3. 定时任务的区别是，增加一个查询与运行方式，定义 AI 处理定时任务的查询方式 4. 触发规则，仅对新建工作生效，已触发前台任务不受影响 |      |
| 4 完成创建，进入组织架构 | 1. 一次性生成数字员工身份，并同步写入人员组织架构，数字员工进入到人员组织架构之后，没有什么特殊的逻辑，继承人员的一些列表页、详情页相关的一些逻辑。 |   |
数字员工在权限上完全等同一名真人员工，沿用现有「岗位业务角色 + 数据共享规则 + 相关团队角色」三件套，不对数字员工新增一套权限模型。全部动作经运行时执行，动作的发起人记录在数字员工名下。
与真人员工的差异
| 项 | 真人员工 | 数字员工 |
|---|---|---|
| 登录方式 | 账号与密码 | 无登录能力，仅运行时调用 |
| 创建逻辑 | 组织架构新建人员 | AI 平台「数字员工」入口创建，创建完成后落入组织架构 |
| 审计归属（同） | 记在本人名下 | 同样记在数字员工名下 |
| 停止工作（同） | 离职或停用 | 停用；已有工作记录不受影响，继续保留在对应业务数据上 |
| 通用选人范围 | 可被任意业务场景的选人组件选中 | 只出现在业务数据「相关团队」选人组件；不进入企信单聊与普通群聊的选人列表 |
岗位职责-负责对象适用范围与首期边界
首期以客户和商机作为负责对象，重点验证商机推进官等岗位数字员工。
| 业务对象 | 是否强制绑定阶段推进流程 | 首期阶段推进增强 | 说明 |
|---|---|---|---|
| 商机 | 是 | 是 | 代表一次有明确成交目标和起止边界的交易，贯穿生命周期 |
| 客户 | 否 | 否 | 承载长期关系及多条并行业务过程，只在明确场景按需启动流程 |
| 线索/线索池 | 否 | 否 | 处于资格验证阶段，以状态、负责人、跟进时限和转化结果管理 |
补充触发配置
管理员首期只配置两类后台规则，每条规则除触发条件外必须填写“本次工作目标”。
| 规则类型 | 配置项 |
|---|---|
| 业务事件 | |
| 定时任务 | 执行频率、执行时间；本次定时工作目标 |
业务触发与阶段流程的六条
同一事件 ID、同一商机、同一触发场景和同一阶段下的重复消息必须合并；阶段常驻与配置触发命中同一件事时也只保留一条活动工作。定时扫描发现已有活动工作项时只更新关注时间，不重复派活。数字员工产生的数据变化不允许递归触发当前场景；如果真实落库结果命中了另一个已启用场景，可以创建关联的后续工作，并记录与原工作链的关系。
配置权限
| 事项 | 谁 |
|---|---|
| 创建数字员工 / 改它的配置 | AI 管理员 |
| 把它拉进某条业务数据的相关团队 | 该业务数据的负责人 |
| 在业务上指挥它做事 | 相关团队成员（受它自身权限上限约束） |
补充任务机制
数字员工进入某条商机后，读当前阶段的阶段描述（管理员写的自由文本）与这条商机的业务上下文（动态、商机信息、群内协作过程），判断"当前阶段要求做的事，现有固定任务是否覆盖全"。
它推出来的事分三级处置（这是"任务可能是错的"的防线。没有"待确认/去确认"这一级：需要人拍板的转 Ask，需要外部沟通的转 CRM 任务，依据不足的不建任务）：
| 级别 | 触发条件 | 系统行为 | 界面表现 |
|---|---|---|---|
| 直接派 | 依据是结构化事实（字段为空、关联缺失、任务未完成） | 直接建任务，交给人做 | 正常任务行 |
| 需人介入 | 依据来自对话或推断，不是结构化事实；或涉及金额、对外承诺；或会给多人派活 | 不建"待确认项"，按性质转成既有载体： · 需要人拍板/回答一个问题 → 转 Ask（按钮「回答」） · 依赖外部沟通才能推进 → 转 CRM 任务（按钮「完成」） | 就是一条普通 Ask 或 CRM 任务行，不出现"待确认"状态 |
| 只写入概览 | 依据薄弱，只是"可能需要关注" | 不建任务，只在概览里留一句 | 概览里的一行文字 |
| # | 约束 | 为什么 |
|---|---|---|
| 1 | 补充任务关联阶段，但不参与阶段完成判定、不阻塞阶段流转 | 阶段是稳定产物，不能被推测性判断影响 |
| 2 | 补充任务可以跨阶段存活：商机推进到后面的阶段后，点阶段条切回该阶段仍可见、可做 | 避免"阶段一过，活就没了" |
| 3 | 每条补充任务必须带可追溯依据（为什么认为要做这件事） | 人看到依据才能判断对不对 |
2.2.2 前台：怎么工作
DEMO 交互：
2.2.2.1 入口：负责人把它拉进相关团队
数字员工进入某条业务数据工作的前置条件只有一个：负责人通过该业务数据的「相关团队」选人组件把它拉入，并分配一个团队角色。完成这一步之后，下面这些事情才会自然发生。
| # | 环节 | 说明 | 示意图 |
|---|---|---|---|
| 1 | 唯一入场动作 | 负责人或团队成员在业务数据的「相关团队」选人组件中拉入数字员工并分配团队角色。这是它开始为该记录工作的唯一入口 |  |
| 2 | 自动进入业务群 | 业务群成员由「相关团队成员 + 其他成员」构成，其中相关团队成员实时取自当前业务数据的相关团队。因此拉入相关团队后，它自动出现在该数据关联的业务群里（现状逻辑） | |
| 3 | 可在业务群与动态被@ | 业务群和业务动态都挂在具体业务记录上，在其中发内容时可以@ 到它，数字员工会进行问题回复 | |
| 4 | 不能进入通用聊天 | 企信单聊、普通群聊的选人组件里选不到它，写信和工作圈 Feed 同样选不到。这些场景没有记录级锚点，无法判定应作用于哪条业务数据，也无法按记录权限校验， 注：一期 DEMO 先不设限制，后期再收拢限制的场景 |
一句话：先有「拉进相关团队」，才有业务群和动态里的 @。
2.2.2.2 它怎么干活
1. 两条运行通道：主流程+自定义触发分支流程
数字员工背后的 agent 会分析当前的商机的跟进规范是根据阶段还是 32 问等方式，根据不同的商机规范，预设一些触发机制进行主动工作
| 运行通道 | 发起来源 | 谁配置 | 示意图 | 边界 |
|---|---|---|---|---|
| 开箱的规范化触发机制（依据商机阶段常驻通道/32 问等） | 数字员工加入相关团队；根据阶段或 32 问的状态 | 运行时开箱内置，管理员无需配置 |  | 只围绕当前阶段目标、条件和已有工作，不凭空扩展其他业务目标 |
| 后台自定义配置的触发时机 | 管理员配置的业务事件、定时任务； | 管理员 |  | 仍受当前阶段、权限、任务选型和去重约束，不能创建平行阶段流程 |
2. 任务如何闭环
它入场后，围绕当前阶段的预设阶段任务判断还缺什么，把缺的事派给人，人做完再回到它这里复核。
| # | 步骤 | 系统做什么 | 结果 |
|---|---|---|---|
| 1 | 入场 | 负责人把它拉进商机相关团队 | 建立「商机 + 阶段实例」关系 |
| 2 | 读阶段 | 读当前阶段描述、阶段必做任务、当前业务事实 | 得到"这个阶段要求做到什么" |
| 3 | 找缺口 | 阶段目标 − 已满足事实 − 已被覆盖的工作 | 得到"还缺什么" |
| 4 | 去重 | 与预设阶段任务、已有工作项、历史工作三层比对 | 命中不建；疑似重复转 Ask |
| 5 | 选类型 | 按事情性质选 Ask / CRM 任务 / 业务数据任务 / Agent 内部工作 | 得到一条工作项 |
| 6 | 派给人 | 处理人判定 | 工作项落进对应入口 |
| 7 | 完成回流 | 人完成后，结果作为事件信号回到它这里 | 它复核这件事是否真的做完 |
| 8 | 复核 | 刷新阶段事实与概览 | 继续下一轮；或满足条件后由有权限的人推进阶段 |
判断：当前的商机状态还缺什么
缺口 = 阶段目标 − 已满足的业务事实 − 已被覆盖的工作（固定阶段任务 / 活动中的补充任务 / 待回答 Ask / Agent 工作）
三条边界：只针对当前阶段；判断依据必须可回溯；没有缺口时只刷新概览，不硬造工作。
去重：同一件事不派两次
| 层 | 比谁 | 比对键 | 命中后 |
|---|---|---|---|
| ① 同一性 | 当前阶段的预设阶段任务 | 对象 + 动作 + 目标字段 / 关联对象（+ 阶段） | 视为已被覆盖，不建任务 |
| ② 覆盖性 | 已有的补充任务 / Ask / Agent 工作 | 同一业务结果（动作可不同） | 关联已有工作项，不重复派 |
| ③ 历史性 | 已完成 / 已取消 / 被拒的同类工作 | 对象 + 动作 + 阶段 + 结果 | 不重复派；业务事实再次变化才允许重建 |
- 比对键必须结构化；语义只用于"疑似重复"的判断
- 疑似重复但不确定 → 转 Ask 让人拍板，不自行决定
- 每次判定留存依据快照（比中了谁、按什么键比中）
- 被预设任务覆盖的不建、也不显示（冗余信号不进界面）
承载：通过任务类型
| 类型 | 什么时候用 | 谁来做 | 前台操作 |
|---|---|---|---|
| Ask 问询 | 需要人给一个明确答案才能继续 | 指定回答人 | 回答 |
| CRM 任务 | 一件可独立完成的事（补数据、对结论、找人确认） | 指定执行人 | 完成 |
| 业务数据任务 | 要改业务数据：编辑字段、关联 / 新建数据、批量编辑从对象 | 指定执行人 | 真实动作名 → 进业务数据页操作，保存成功即完成 |
| Agent 内部工作 | 它自己或小队内 Agent 能做完的分析、核对 | 它自己 | 查看进展（不进个人待办） |
派给谁
四层判定：① 任务有明确业务责任人 → 交该记录负责人；② 阶段角色已定义 → 按阶段角色；③ 需要专业角色 → 相关团队成员；④ 判不出来 → 交商机负责人，允许事后转派。
补充任务与阶段的关系
- 只关联阶段，不计入阶段必须完成条件、不阻塞阶段流转
- 可跨阶段存活：点阶段条切回该阶段即可查看与继续完成
- 每条必须带可追溯依据
完成回流与阶段推进
| 完成类型 | 回流内容 |
|---|---|
| 字段类 | 新值 + 完成人 + 完成时间 |
| 关联 / 新建数据 | 关联或新建了哪条记录 |
| 填写结论 | 结论文本 |
| Ask | 答案 + 回答人 |
| Agent 内部工作 | 分析结论 + 依据 |
| 产物 | 文件引用（名称 / 类型 / 大小） |
阶段推进只看阶段必做任务是否全部完成；补充任务完成与否都不影响该判断，也不阻塞流转。
2.2.4 前台：不同场景下的工作规范
任务组件的两种承载（布局差异，规则相同）
- 独立组件：阶段推进器不动，任务看板挂在商机详情右侧栏（相关团队之下）
- 合并承载：任务看板吸在阶段推进器内的预设阶段任务下方，视觉上是一个组件
两种形态只影响布局：任务类型、交互、去重、回流规则完全相同。最终用哪种由 demo 评估决定，本方案不锁定。
任务看板
| 元素 | 规则 |
|---|---|
| 组件头 | 员工名 + 在岗状态；不出现"AI"字样 |
| 概览 | 一句话：当前阶段结论 + 阻塞 / 风险 |
| 收件范围 | 只放它生成的工作：Ask / CRM 任务 / 业务数据任务 / Agent 内部工作。管理员预设的阶段任务不在其中 |
| 默认条数 | 3 条，按「回答问题 → CRM 任务 → 处理业务数据」各取一条；「查看全部 N 项」展开 |
| 每行 | 标题 / 执行人 / 截止时间 / 操作按钮（按钮名 = 动作） |
预设阶段任务
由管理员在阶段流程模板中配置，展示在阶段推进器内的原生「该阶段任务」区（含完成 / 更换处理人与业务动作按钮）；业务数据类动作进入对应业务数据页，保存成功即完成。
四个入口各放什么
| 入口 | 放什么 | 不放什么 |
|---|---|---|
| 商机详情 | 阶段推进器 + 预设阶段任务 + 任务看板 | — |
| 业务群 | 只投递强阻塞 / 强协作 / 强时效的协作卡；右侧为商机侧边栏 | 不投递全部任务，不做工作项清单 |
| 动态 | 阶段性结论单独一条； 人 @ 它之后的回答作为该条动态的回复（回复里带 rtc 文字卡 + 附件） | 回答不另起动态 |
| 个人工作台 | 当前用户有责任关系的工作项：待我处理 / 我发起的 / 已完成 | 不放 Agent 内部工作 |
产物
- 形态：MD / HTML 文件，作为附件卡挂在产生它的那条回复里
- 业务群：文字部分用 rtc 卡片样式，附件单独一条消息
2.2.5 运行保障
| 一级状态 | 业务含义 | 退出条件 |
|---|---|---|
| 进行中 | 仍可自主向前推进 | 转为等待 / 阻塞 / 完成 / 终止 |
| 等待中 | 下一步依赖明确的人或业务条件 | 收到有效输入或目标事件后回到进行中 |
| 已阻塞 | 当前没有可执行的恢复路径 | 原因解除后回到进行中，或由有权人员终止 |
| 已完成 | 目标达成且证据校验通过（终态） | — |
| 已终止 | 目标不再继续（终态） | — |
沿用现有五级状态，不新增状态机；进入一级状态时必须同时写入状态原因。
| 异常 | 处理 |
|---|---|
| 临时超时 / 网络失败 | 自动重试；多次失败后进入已阻塞 |
| 权限不足或被收回 | 停止后续操作并进入已阻塞 |
| 缺少业务信息 | 创建协作请求并等待 |
| 完成证据冲突 | 进入已阻塞，由负责人处理 |
| 业务对象被删除 / 作废 | 已终止 |
| 数字员工被停用 | 停止新触发；在途任务保留，由负责人处理 |
| 被移出当前记录相关团队 | 停止该记录的新触发与内部执行；任务与 Ask 保留；概览停止刷新 |
并发与优先级：一个数字员工可并发多个任务；首期不支持多个数字员工同时负责同一种业务对象；优先级由它按截止时间、风险、依赖、人工紧急请求和等待时长判断。
三、规范检查项
3.1 业务文案多语言 Key
本轮先确定中文产品逻辑。任务状态、协作类型和操作按钮需在交互稿定稿后统一申请多语言 Key。
| 模块 | 功能点 | 示意图 | 中文 | 英文 | 多语言 Key |
|---|---|---|---|---|---|
| 数字员工任务 | 一级状态 | 无 | 进行中、等待中、已阻塞、已完成、已终止 | 待翻译 | 待分配 |
| 协作请求 | 类型 | 无 | 补充信息、业务判断、操作确认、人工执行 | 待翻译 | 待分配 |
| 任务操作 | 确认 | 无 | 确认修改、确认发送、要求调整、拒绝执行 | 待翻译 | 待分配 |
3.2 需求埋点
无。本轮不定义产品埋点；进入试点方案后再确定任务受理、协作响应、完成和阻塞等效果指标。
3.3 沙盒/更改集能力
| 模块 | 功能点 | 是否支持沙盒 | 是否支持更改集 | 说明 |
|---|---|---|---|---|
| 数字员工配置 | 岗位与触发配置 | 待确认 | 待确认 | 沙盒不得触发生产业务任务；发布方式待技术评审 |
| 数字员工任务 | 运行实例 | 隔离 | 不迁移 | 任务、权限和业务数据仅在当前环境运行 |
3.4 PaaS 国际化兼容检查
| ID | 多语接入事项 | 是否需要 | 注意事项 |
|---|---|---|---|
| 1 | 接入翻译工作台 | 是 | 数字员工后台、任务状态、协作请求和操作文案 |
| 2 | CRM提醒 | 是 | 按接收人语言展示任务和确认提醒 |
| 3 | 企信消息提醒 | 是 | 固定摘要与业务数据卡片分离 |
| 4 | 过程记录 | 是 | 展示数字员工身份及真实确认人 |
| 5 | 审计日志 | 是 | 状态码稳定，展示文案可翻译 |
| 6 | 支持快捷翻译能力 | 沿用现有能力 | 本方案不新增独立翻译入口 |
| 7 | 支持数据多语能力 | 沿用现有能力 | 业务数据按原对象规则展示 |
| 8 | 预置配置多语 | 待确认 | 如提供岗位或触发范例则需维护 |
| 9 | 预置示例数据多语 | 不涉及 | 首期 Demo 固定中文样例，不代表生产预置 |
3.5 新对象/新字段 BI 分析申请
| 对象/字段 | 是否已做流程支持申请 | 是否已做 BI 分析申请 | 内容 |
|---|---|---|---|
| 数字员工动态任务来源扩展 | 未申请 | 未申请 | 建议新增阶段、来源、生成依据和去重语义；物理字段待技术设计 |
| Agent 内部工作委派扩展 | 未申请 | 不涉及 | 建议记录业务责任数字员工、实际执行 Agent、父子 Run、授权范围、结果和证据 |
3.6 操作日志说明
数字员工任务需要保留身份、任务来源、业务对象、关键状态、权限判定、人工确认、转派前后处理人、业务动作回执、完成证据和任务衔接。由业务群发起或投递时补充来源群、原消息、讨论串和投递去重键；普通聊天内容仍保留在群会话，不逐条复制到任务日志。Team 小队执行时同时记录业务责任数字员工、实际执行的 SubAgent、版本、关联 Run 和结果。Agent 内部思维过程不进入用户可见操作日志；Tool 原始参数、模型上下文和敏感数据按平台审计与安全规范处理。
3.7 需求风险点检测
| ID | 风险分组 | 风险类型 | 有无该风险 | 涉及风险的功能点 | 影响的企业数 | 是否报备 | 响应策略 |
|---|---|---|---|---|---|---|---|
| 1 | 对现逻辑有影响的风险点 | 交互体验有变化 | 有 | 业务群阶段区增加紧凑概览，消息流增加协作卡 | 待确认 | 待评审 | 右侧只显示三项关键工作，消息流只投递强协作事项 |
| 2 | 对现逻辑有影响的风险点 | 功能有减少 | 无 | V3/V4 既有 Demo | 不涉及 | 不涉及 | V3 冻结保留，V4 独立迭代 |
| 3 | 对现逻辑有影响的风险点 | 功能逻辑的调整 | 有 | 过程记录、任务、相关团队和前台展示 | 待确认 | 待评审 | 复用现有对象和权限，先验证单客户/商机闭环 |
| 4 | 新能力风险点 | 逻辑不完善 | 有 | 越权、错误转派、执行身份混淆、错误完成 | 待确认 | 待评审 | 受限委派、双主体审计、幂等、完成证据和阻塞状态 |
| 5 | 新能力风险点 | 有性能压力 | 有 | 多任务并发、定时触发和多入口状态同步 | 待确认 | 待评审 | 运行时统一调度、事件合并和按任务投影 |
| 6 | 新能力风险点 | 数据泄露 | 有 | 群成员通过阶段区或群卡读取业务数据 | 待确认 | 待评审 | 群身份不授予 CRM 权限，按查看人加载字段和操作 |
| 7 | 新能力风险点 | 错误回写 | 有 | 普通聊天被误识别为正式答案或完成结论 | 待确认 | 待评审 | 仅结构化提交回写，责任人明确确认后完成 |
| 8 | 新能力风险点 | 重复打扰 | 有 | 群投递与个人通知重复 | 待确认 | 待评审 | 状态节点去重，个人责任通知作为明确例外 |
3.8 上线策略
3.8.1 收费标准
- [ ] 不收费
- [ ] 收费
待确认。本方案不根据模型调用成本推导产品定价。
3.8.2 上线节奏
- [ ] 全网
- [X] 灰度
| 灰度发布的原因 | 数字员工涉及独立身份、业务权限、自动触发、数据写入和人工确认，需要先验证单对象闭环 |
|---|---|
| 预计全网时机 | 待确认 |
| 期间分几次灰度 | 待确认 |
| 各灰度批次的时间节点及灰度的客户范围 | 建议先内部试点，再选择已确认权限边界的客户试点；具体范围待确认 |
3.8.3 适用版本
| 资源名称 | 标准版 | 专业版 | 旗舰版 | 无限版 | 扩展资源包 |
|---|---|---|---|---|---|
| 数字员工运行与前台协作框架 | 待确认 | 待确认 | 待确认 | 待确认 | 待确认 |