数字员工产品方案 v7.0 · 两类员工与业务群兼容

版本：v6.0 | 创建日期：2026-10-22 | 基线：v5.0（2026-09-23）

需求来源：v5.0 全文 + 2026-10-21 线上 Demo（前台 https://sharecrew-public-collab-v2.pages.dev/ ，后台 /admin，部署 14a4b86c）+ 1021 前各轮用户确认口径

优先级：待确认（本版不调整项目排期）

文档状态：产品方案草稿，交付范围与节奏待确认

旧 v5.0 原稿保留、未修改。本版在 v5.0 基础上按最新 Demo 重写“前台任务组件”主线（2.2.5）、补充任务全景图与后台日志口径（2.2.6）、新增 Demo 差异对照（2.2.8）与 BDD 验收场景（2.2.9），供开发侧作为 Agent 前置输入。Demo 为交互示例，不代表真实 Team 服务已联通。

需求变更记录

变更日期	变更人	变更内容
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. 前台任务的组件，包含 数字员工给自己发的任务和数字员工给人发的，都需要展示在一个组件里，这个组件待决策是谁支持；包括任务的类型，都有哪些需要
0922	孙浩	1. 协同AI 任务不放在任务组件中，该组件主要是给人看的；同时针对围绕业务场景的主子任务，每条子任务就增加一列关联的主任务就可以了，不用大改，还是清爽为主 2. 业务侧需要查看数字员工自闭环的任务执行情况，这块通过【任务视图】来承载，是一个新的列表视图，可参考 AI 平台的审计任务，会包括给 AI 的和给人的，按照树状结构展示，主子任务了；可以参考 team小队 给 人分发的任务事件，界面是我们设计，但是数据可能是 team小队 灌起来，因为都是 agent 触发的 3. 综上，任务组件是有两套，纯给人的一套，agent 和人的事件执行列表，是一套组件 4. 关于数字员工-token 消耗的 budget---scoot 的 credit 的设计，有全局的设计；我们不需要单独设计 5. 每个数字员工的执行日志，其实和任务视图差不多，监听事件或自动化的过程-沉淀日志，每条日志数据，可以查看明细，复用 chat 界面，进入 agent 执行窗口 6. AI任务是在后台跑的，可以通过审计日志去看
0922	孙浩
0923	孙浩	参会人：刘抗、骆晶晶Jingjing、赵鹏欣Paul、郑磊ZhengLei、林松Eric、尚壬鹏、陈旭聪、王毅 会议纪要： 1. 整体方向上优先做 channel 级别的，数字助手，类似商机推进助手之类的，次级再做员工，建议一期先不进入组织架构，概念还是太大，希望能落地 2. 助手在商机详情页工作的方式，不建议是给人派发任务，整个产品的调性会变得让人反感，助手的定位应该还是一个能够自动 推进任务的落地，需要人执行时，派发建议任务给到他，他也可以选择是否接受，同时也可以反过来继续委派给 AI 去执行 3. 本期可能先不做进入组织架构的机制，可能还是先绑定在一个员工上，赋予这个助手的权限
1022	孙浩	1010 会议纪要
1023	孙浩	10.23 showcase 记录
2026-10-26	孙浩	最新两类员工会议笔记（用户原始截图，未经改写）

依赖需求 Story 列表

v7.0 本版说明（AI 方案草案，2026-10-26）

以本次最新会议笔记和用户补充为准，复制自 v6.0；原稿与原 Demo 不修改。上方人工需求变更记录原文保留。新版后台 Demo：../数字员工公共协作_V4_两类员工_20261026/admin.html。

一、需求概述

1.1 项目背景

LTC主流程中，商机推进是一项需要多成员持续协作的工作，也是 CRM 业务中的关键场景。

销售需要补齐客户需求、确认决策关系、协调方案与报价，并安排其他人员完成相应事项。负责人不仅要知道当前记录有哪些信息，还需要知道缺什么、谁在处理、下一步应该做什么，以及哪些工作已经阻塞。

针对目前 Shareagent 的个人级的Agent 的产品能力，这些判断通常需要人员主动发问；分析结论还需要人工转成任务、通知参与人并追踪结果。数字员工希望把这段持续工作接起来：在明确的负责范围内接收业务变化，调用绑定的执行能力判断需要开展的工作，让 Agent 完成可自动执行的部分，让真人通过任务补充事实、作出判断或完成业务操作。

数字员工需要明确的业务责任和权限来源；业务跟进型按业务数据负责人自动建立服务关系，无需先手动加入相关团队。业务人员能知道工作由谁发起、交给谁、现在是什么状态，也能找到执行过程和产出。

商机的推进方法并不统一。有的业务沿用销售阶段，有的依照行业规范或“32 问”等检查方法。如何理解业务、识别缺口和判断目标达成，定义在绑定的业务 Agent / Team 中；数字员工通用产品不把阶段推进器作为必需条件。

1.2 竞品动态

数字员工、数字劳动力及自主 Agent 并非新概念。现有厂商既在建设身份与治理能力，但是 Agent 员工的概念引入到实际业务场景中的，目前暂无成熟的产品设计逻辑可供学习和参考

参照产品	资料	对本方案的启示
Microsoft Entra Agent ID	基于管理中心的组织架构视角的 Agent 员工的概念，非业务场景中的 Agent 员工 区分技术管理者、业务责任人和组织层级中的管理者，为 Agent 建立身份管理关系。 官方说明
Salesforce AIforce		岗位化 Agent 的价值应落到可完成的具体工作，而不止名称、头像或聊天入口

本方案的产品重点：把既有组织与权限、业务数据相关团队、Agent / Team 执行能力，以及真人任务和执行记录连接起来，让数字员工能在具体业务记录上持续承担工作。 差异需要以实际交互和业务闭环验证，不以“数字员工”概念本身作为创新结论。

1.4 产品价值

将数字员工从“阶段流程里的补充任务助手”调整为“围绕业务数据承担责任的 AI 员工”。不同业务可以使用不同推进方法，前台仍用一致的任务入口承接人的工作，并能追溯数字员工的执行过程。

1.5 需求目标

1. 没有启用阶段推进器的业务数据，也能由数字员工按所绑定的业务 Agent / Team 开展工作。
2. 人只在任务组件中处理自己的人工任务；需要了解上下文时，可以查看关联主任务、其他有权查看的子任务及执行过程。
3. 业务侧与平台侧职责可区分：业务侧交付推进方法和业务动作，平台提供通用协作机制，数字员工产品提供身份、部署及工作入口。

二、产品方案

2.1 整体产品方案/架构

数字员工是具有企业人员身份、组织关系和权限，通过绑定的 Agent / Team作为执行能力，围绕所负责的业务数据持续开展工作、协同真人完成业务目标的 AI员工。

数字员工承接员工身份、组织关系、权限与触发配置；理解业务、判断变化、组织任务及持续推进目标，由其绑定的业务 Agent / Team 承担。两者是员工身份与执行能力的绑定关系，不是上下级决策关系。Team 的 Leader 承担小队内的拆解与编排。

数字员工产品架构：从应用入口到通用执行平台

从上到下是前台入口、数字员工、业务能力、平台支撑和业务底座，箭头表示依赖关系，不是审批或执行步骤。数字员工提供身份、组织关系、权限，配置 Agent / Team 执行层绑定与 Signal，并通过启用／停用及任务日志管理运行；SFA 在平台上建设业务 Agent / Team，将业务方法、工具及完成标准落实为执行能力；AI 平台提供通用 Team 和 Task 机制。业务底座独立呈现 IM、任务、业务数据、组织与权限、文件与附件。后台配置和任务日志归入数字员工层，不占前台入口。

业务协作：工作如何发起、派发并继续推进

业务事件、定时任务和人工委派唤起同一个数字员工；绑定的 Agent / Team 判断是否需要行动，按需创建或继续主任务，拆解给 Agent 或真人。主任务承载业务目标，可直接执行，也可拆成多级子任务，并非每次都必须拆分。真人在详情页和个人工作台的任务组件处理任务；人和 Agent 的执行结果均回传给绑定的业务 Agent / Team，由其判断继续执行、重新安排或结束目标。业务群／动态是人工委派入口，同时可以承载沟通和成果。

业务运行原则

过去的方案从“商机在哪个阶段”开始组织工作；新版从“这条业务数据要达成什么目标、还缺什么事实和行动”开始。阶段可以参与判断，但不再是所有数字员工必须依赖的框架。

2.2 具体方案说明

2.2.1 职责分工与真实交付内容

Agent平台解决“怎么协作执行”

业务侧解决“什么工作值得做、怎么判断做好了”

数字员工产品把这些能力以员工身份交付到业务现场。

2.2.2 后台配置与员工管理

数字员工不进入组织架构、不占编制，不作为独立真人账号取得权限。后台先选类型，再按“基本信息 → Agent 与能力 → Signal”创建。编辑页为“基本信息 / Agent 与能力 / Signal / 任务日志”。类型创建后不可修改。列表支持编辑、启用和停用。

2.2.2.1 两类员工与基本信息

“负责人”配置决定接收和判断建议、决定采纳并安排执行人的人员字段；与 Signal 权限主体分开。Signal 始终使用当前业务数据负责人的权限。人员字段为空、失效或无法唯一确定人员时，提示待配置，不静默改派；不支持多人员字段作为本期单一接收人。实际任务执行人可在采纳时安排。

2.2.2.2 Agent 与能力

选择一个 Agent 或 Team，显示名称与描述，沿用所选能力的适用范围，不在数字员工再配置一份范围。业务跟进型以当前记录负责人是否在范围内判断服务资格；通用助理型以邀请人、当前提问人是否在范围内判断可用性。适用范围是使用资格，不替代对象、字段、记录或动作权限。

Team 适用范围若平台没有统一口径，作为上线依赖由 AI 平台明确；不得默认把队员范围取并集后扩大权限。后台应支持查看实际生效范围及不可用原因。

2.2.2.3 Signal 配置

列表标题统一为 Signal，创建入口为“新建”。可编辑、启停具体 Signal。

业务跟进型：配置业务事件或定时任务，条件作用于当前记录及有关联的事件；事件条件支持组内且、组间或以及变更前／变更后。定时频率沿用现有时间配置。每条匹配记录独立处理，指令描述本次要达成的目标。

通用助理型：配置名称、执行频率、可选有效期和工作指令。查询对象、时间范围、数据筛选、产出要求写入指令；移除单独“数据范围／查询范围”和“运行方式”。系统按一次批量运行处理，不向管理员展示逐条／批量选择。查询范围仍受指定用户权限约束。无定时任务时无需授权用户，仍可用于对话。

匹配成功不等于立即执行所有工作。记录创建仅建立服务关系；确需创建后执行一次，应明确配置记录创建 Signal。加入群不补跑历史 Signal。重试、去重和执行日志沿用统一运行机制。

2.2.2.4 自动匹配、权限与任务归属

记录创建、负责人变化、能力适用范围变化、数字员工启停时重新检查服务关系。有效员工、对象匹配、负责人有效且在能力适用范围内才可服务；执行动作仍须校验实际权限。对存量记录按同样规则建立关系，但默认不补跑历史事件。

建议每条记录同一服务位置只允许一个有效业务跟进型员工。多个配置命中时显示配置冲突并由管理员处理，不随机选一个、不启动多个群回复者。该唯一性规则为本版建议。

Signal 发起的任务，创建人记录为动作发生时的业务数据负责人。前台展示“陈晨”，附“由商机助手代执行”；详情同时显示触发 Signal、来源证据、代执行数字员工、实际执行方与权限主体。不要把数字员工名称直接写进真人创建人字段。

@ 发起的工作使用本次提问人的权限，并记录请求人、数字员工和动作归属。不得转入负责人权限继续完成原请求。若执行期间用户权限失效，则阻塞该动作。群里能 @ 不等于所有成员都有权看完整回复，涉及受限内容时只给有权接收者展示，群内提示有权限限制。

2.2.2.5 负责人变更的处理建议

新负责人无资格或无权限时显示“已阻塞”，停止新动作。恢复条件满足后重新核验再续跑，不自动重放所有旧事件。权限更新由系统强制执行，不能只靠 Agent 提示词。

2.2.2.6 业务群助手兼容与迁移（本版建议）

现状依据：用户截图确认已有对象级业务群开关、群成员规则、互联业务群开关、助手名称、所属对象事件和相关对象事件订阅。用户确认只有某一租户具备旧群助手绑定 Agent 能力；其他租户以传统订阅为主，不将该能力视为全量能力。

配置归属：

单一入口：保留原群助手身份、历史消息、既有 @ 入口与订阅；接入数字员工后由同一个入口承接智能工作，不往群里再塞第二个同类助手。数字员工显示名在服务信息中说明，避免把原助手身份改成真人权限主体。

三种服务状态（不是三类数字员工）：

订阅决定“群里通知哪些事件”，Signal 决定“数字员工做什么”，不把所有订阅自动转换为 Signal。一个业务事件可分别产生订阅通知和工作结果，但同一通道按事件和动作去重，不重复发两份同内容通知。

业务群开关只管理群入口；关闭群能力不等于停用记录上的数字员工与 Signal。停用数字员工不删除群或历史订阅。群尚未创建时，记录任务可正常产生；不为发工作结果偷偷创建群。

群指令作用于对应记录的所有数字员工工作，包括详情页和群内触发。记录级统一存储，群里修改后在详情中可查看版本及修改人；强制规则和权限优先，不能用群指令覆盖。原群指令若无法自动映射应原文保留、提示人工核对，不静默丢弃。

迁移前核对绑定关系、订阅、群入口和既有指令；迁移后校验相同事件只由预期服务承接。失败回退到迁移前配置，已创建任务和历史消息保留。互联群中外部成员的智能服务可用性暂不扩大，沿用现有边界，另行评审外部身份权限。

通用助理型承接旧 AI 助理时保留名称、头像、能力绑定、适用范围和既有入口；定时任务默认不启用，避免迁移后意外开始批量动作。

2.2.3 一条商机如何被推进

1. 明确责任。 记录创建后，按负责人及能力适用范围匹配数字员工。建立服务关系后等待 Signal，匹配本身不启动所有任务。
2. 接收触发。 业务事件、定时任务或人工请求形成一次执行输入，包含发生了什么、关联什么数据、本次要做什么。
3. 理解业务。 绑定的业务 Agent / Team 读取商机事实、相关记录和已有工作，按适用业务方法判断当前目标与缺口。
4. 组织任务。 需要行动时创建主任务或继续关联已有主任务，按需拆解为子任务；分别交给 Agent 或真人。无需行动时记录检查结果，不制造待办。
5. 完成动作。 Agent 执行分析或业务操作；真人回答问题、完成普通任务或操作业务数据。
6. 继续判断。 Team 根据结果继续执行；业务策略决定补充信息、重新安排、结束任务或保持阻塞。主任务完成必须具备目标达成依据。

自 v6.0 起，Team 拆给真人的工作先形成“建议（待采纳）”，由业务负责人或建议执行人采纳后才成为正式任务；采纳前不进入任何人的待我处理、不占期限、不计逾期。

主任务的稳定关联是业务记录与业务目标，阶段只是可选的业务上下文。 没有阶段推进器也可以运行；存在阶段时，是否变更阶段仍遵循 CRM 既有动作权限与业务规则，不能把子任务完成当成自动改阶段的依据。

以报价为例，可以由“进入方案／报价阶段”事件唤起，也可以由定时检查发现“客户已要求报价但产品范围不明”唤起。两种触发均可进入“报价方案确认”目标，之后使用相同的协作链路。

2.2.4 Signal、主任务、子任务与会话

同一触发可能涉及多条业务数据，也可能只做检查、不生成任务。一个主任务可因后续业务变化或人工反馈继续推进，不能每来一次信号就重复创建相同工作。具体去重与继续执行机制由 Team 承担，业务侧定义业务目标和重复工作的判断依据。

2.2.5 前台任务组件：任务类型与生成规则

本节按 2026-10-21 线上 Demo 实测重写，替代 v5.0 同名章节。v5.0 的三类交互、人工四态、三个分类已不足以描述当前实现：Demo 增加了建议态（待采纳）、AI 执行分类、生成依据、任务全景图和组件高度约束。

2.2.5.1 组件定位与两个入口

任务组件只承载“给人做的工作”。Agent 自闭环的执行项不作为人工任务出现，通过“AI 执行”分类和任务全景图查看。

两处共用同一份任务数据、同一套渲染与处理逻辑，只有筛选范围和列不同；任一入口处理完成后另一入口同步变化。

组件尺寸（Demo 已实现，作为交互规格）：列表区最大高度 420px，窄屏（≤1000px）360px，低视口按 clamp(240px, calc(100vh - 300px), 360px)；超出在组件内部纵向滚动，表头吸顶；列宽不足时仅在列表区横向滚动（表格最小宽 690px），不得把商机详情页整体撑开。

2.2.5.2 三类任务类型

两个容易混淆的点：

• “商机诊断”不是任务类型，它是场景／标题。AI 自动执行的分析以 商机诊断 为标题、以“AI 执行”方式呈现，不计入三类人工任务。
• AI 执行不是第四类任务。它描述的是执行方式（自动执行／确认后由 AI 执行），与任务类型正交，详见 2.2.5.6。

2.2.5.3 任务从哪来：五条生成来源

端到端链路（后台配置 → 运行 → 前台）：

1. 后台 Signal 命中：携带“发生了什么（含字段变更前／变更后）、关联哪条数据、本次要做什么”。
2. 数字员工把执行输入交给绑定的 Agent／Team；Team 先判断是否需要行动。
3. 需要行动时创建或续接主任务，写入工作目标与完成条件；无需行动则只留触发记录。
4. Team 拆子任务：可自动执行的交给 Agent；需要人判断或补数据的形成建议。
5. 建议进入任务组件的“待采纳”，同时出现在关联主任务的全景图里。
6. 负责人采纳后转正式任务，进入执行人“待我处理”；完成结果回传 Team，由 Team 判断继续、追问、重排或结束。
7. 后台“任务日志”按主任务留痕，前台按权限展示。

2.2.5.4 建议态与正式任务的区别

采纳前不产生正式执行责任，也不能被转派；这是“助手先建议、人来决定”的产品约束，不允许实现成“先生成待办再让人取消”。

2.2.5.5 采纳规则

采纳是建议变成任务的唯一入口。采纳动作会创建一条正式任务数据（新任务记录），原建议置为“已采纳”并保留，两者双向关联（任务记录保留建议 ID，建议可回到原任务）。

采纳弹窗字段：任务标题、任务内容、执行人、截止时间（均可编辑）；采纳后直接交给指定执行人，无需执行人再次接收。

约束：

• 采纳人与执行人可以不同；业务负责人可代采纳并分派。
• 无权限时弹窗提示“当前身份无权采纳此建议”，不隐藏按钮也不静默失败。
• 采纳后证据、来源、Signal 全部保留，不因转正式任务而丢失。
• 建议与任务是两类数据：任务被拒绝、取消或超期，都不回写建议状态；建议一旦采纳不可二次采纳，改派走任务的转派。
• 被拒绝的正式任务不改成已完成；需要重排时生成新建议，原拒绝记录保留。

2.2.5.6 状态与状态机

前台状态分属两套数据：建议四态（待采纳／已采纳／不采纳／已撤销）与正式任务四态（待处理／已完成／已拒绝／已取消），与 Agent 任务的七态分开，不互相顶替。采纳只改变建议状态并创建任务，不把同一条记录改写成任务。

显示规则：回答问题类在待处理时显示为“待回答”，状态值仍为待处理；其余按状态值直出。

关闭页面、保存草稿、超期未处理、不回复，都不构成状态变化。

2.2.5.7 列表结构与五个分类

建议被采纳后从任务列表移出，正式任务进入对应分类；建议记录与任务的对应关系在主任务会话和后台任务日志中可追溯。

类型筛选独立于分类：全部任务类型／CRM任务／回答问题／业务数据。计数按当前范围实时计算，筛选后计数不改变口径。

按钮文案按状态与执行方式切换，不允许一个“处理”通吃：

行内还提供：关联主任务链接（↳ 主任务名）、数字员工发出任务的“查看依据”、更多操作（更换处理人／更换回答人、拒绝任务／拒绝问题）。空态文案为“暂无符合条件的任务”。

2.2.5.8 生成依据

仅数字员工发出的任务展示“查看依据”，内容固定为三块，不展示模型推理：

权限规则：无权限的来源不展示内容，替换为“部分来源无查看权限，请联系有权限的同事核实”；“查看原文”只展示已存片段，不声称跳转真实 CRM 原文。判断说明与待确认项已从依据中移除，避免与任务内容重复。

2.2.5.9 完成、写回与回流

• 业务数据任务：保存成功但未满足任务要求时，保留已保存结果，任务仍待处理并指出尚缺内容，不要求重复执行已成功的动作。
• CRM任务：完成结果至少保留文本、执行人、完成时间；可附附件。点击完成不等于主任务目标达成。
• 回答问题：回答正文、补充说明、提交人、时间全部留存；只读查看，不覆盖已提交答案；需要追问时新建追问任务，不把原任务改回待处理。
• 问题转任务：问题可由回答人转成关联任务建议（核查类），采纳后执行；结果回流原问题，原问题仍需明确回答。
• 主任务：单条人工任务完成不改变主任务状态；主任务完成必须有目标达成依据（完成条件被满足的证据）。

2.2.5.10 权限与可见范围

2.2.5.11 去重与继续执行

• 同一业务目标（同一记录 + 同一工作语义）只保留一个进行中的主任务；后续 Signal 续接该主任务，不新建。
• 同一 Signal 短时间内多次命中（批量改字段、连续编辑）应合并为一次执行；建议以“记录 + Signal + 业务时间窗”作为幂等键。
• 已被拒绝或已取消的工作，重排必须生成新记录并保留原记录，不复用原任务状态。
• 建议被采纳前，同一建议不重复推给同一个人；拒绝后重排只生成一条新建议。

2.2.6 前台任务入口与主任务会话

任务全景图规格（Demo 已实现）：

• 表格列：任务名称（可展开）、状态、发起数字员工、执行方、最近更新；主任务行带子任务数。
• 筛选：搜索（任务名／执行方）、状态（人取人工态集合、Agent 取七态集合，选“全部执行方”时取并集）、执行方（全部／人／Agent）、重置。
• 主任务会话：触发区（触发类型、Signal 名称、关联数据、本次工作要求）→ 工作目标与完成条件 → 拆解说明 → 进度条与子任务卡片 → 执行进展 → 事件流。
• 子任务会话：显示所属主任务、分派说明、本次执行结果；失败时显示“本次执行未完成，暂无有效产出”，不伪装成完成。
• 会话输入框允许补充要求或追问，回复不改变任务状态。

2.2.6.1 后台任务日志

后台保持“单个数字员工、跨业务数据”的范围，解决“这个员工做过什么、哪里异常、依据是什么”。

Demo 的“演示场景”下拉（初始任务／完成后继续／拒绝后重新安排／业务变化后取消）只是本地数据开关，不是产品能力。

2.2.7 状态和三条闭环

Agent 任务（非给人的任务）沿用平台七态，不另造状态：

三套状态的关系：Agent 与主任务用七态；人工正式任务用四态（待处理／已完成／已拒绝／已取消）；建议用四态（待采纳／已采纳／不采纳／已撤销）；“不采纳”是人拒绝，“已撤销”是发起方撤回，二者不合并。同一任务在不同入口显示同一状态，不按查看者身份转换。

正常等待人工依赖用“等待中”，并在原因里注明所等任务；失败不得显示为“已拒绝”；页面点击取消要等平台确认，不本地假定已终止。

2.2.8 与上一版差异

2.2.9 BDD 验收场景

以下场景供研发拆解验收用例；Demo 仅模拟部分流程，不能替代真实权限、事件订阅及迁移验收。

A. 三类任务

场景: 业务数据任务按字段条件判定完成
  假设 王磊收到业务数据任务「明确本次报价涉及的产品范围」，要求填写报价产品范围并保存
  当 王磊只填写了变更说明、未填写产品范围就保存
  那么 业务数据保存结果保留
  并且 任务仍为待处理
  并且 提示尚缺产品范围，不要求重复保存

场景: CRM 任务完成不改变主任务
  假设 主任务「报价方案确认」还有 1 条待处理人工任务
  当 王磊完成 CRM 任务「核对报价折扣与审批要求」并提交处理结果
  那么 该任务变为已完成，退出待我处理
  并且 主任务仍为已阻塞
  并且 主任务原因更新为仍缺的条件

场景: 回答问题必须填写正文
  假设 刘倩收到回答问题任务「客户的关键采购决策人是谁？」
  当 刘倩只输入空格并提交
  那么 提交被拒绝并提示回答必填
  并且 任务仍为待处理、显示为待回答

B. 生成与后台结合

场景: 业务事件 Signal 生成建议而非直接任务
  假设 商机处于「需求确认」，数字员工已自动匹配且负责人在能力适用范围内
  当 销售阶段变更为「方案报价」并命中 Signal
  那么 创建 1 个主任务「报价方案确认」，状态为等待中
  并且 拆出的人工工作为待采纳，建议执行人为商机负责人
  并且 该建议不出现在任何人的待我处理中
  并且 任务组件“待采纳”计数加 1

场景: 定时任务每条数据独立处理
  假设业务跟进型 Signal 为每天 09:00，按每条数据独立处理，命中 12 条停滞商机
  当 定时任务触发
  那么 生成 12 个主任务，每条商机一个
  并且 每个主任务的触发来源显示为定时任务
  并且 不得合并成一个没有业务归属的任务

场景: 定时任务批量一次处理
  假设通用助理型 Signal 为每周一 09:00，按指令批量一次处理，命中 12 条商机
  当 定时任务触发
  那么 生成 1 个主任务，包含 12 条数据的工作项
  并且 主任务可追溯到 12 条业务数据

C. 建议与采纳

场景: 采纳并安排
  假设 王磊是商机负责人，收到待采纳建议「明确本次报价涉及的产品范围」
  当 王磊采纳，确认标题、内容、执行人和截止时间
  那么 建议状态变为已采纳，建议记录保留可追溯
  并且 新建正式任务记录，状态待处理，进入执行人的待我处理
  并且 任务记录保留建议 ID，可与原建议互查
  并且 记录采纳人与执行人，二者可以不同
  并且 生成依据与来源证据保留
  并且 执行人无需再次接收

场景: 无权限采纳
  假设 当前身份既不是业务负责人也不是建议执行人
  当 打开待采纳建议
  那么 显示“当前身份无权采纳此建议”
  并且 不展示采纳、不采纳按钮
  并且 不因为点击而静默改变状态

场景: 不采纳
  当 有权限的人选择不采纳并确认
  那么 建议状态变为不采纳
  并且 不创建任务
  并且 原建议记录与证据保留

场景: 任务取消不回写建议
  假设 某条建议已被采纳并生成正式任务
  当 因客户撤回需求，该正式任务被取消
  那么 任务状态为已取消，已完成的结果保留
  并且 建议仍为已采纳，不被改回待采纳或标成不采纳

D. AI 执行

场景: 自动执行项不进入待办
  当 Agent 自动完成「分析商机资料并生成诊断报告」
  那么 任务状态为已完成、执行方式为自动执行
  并且 只出现在“AI 执行”分类
  并且 不进入任何人的待我处理，不计逾期
  并且 按钮为“查看结果”

场景: 确认后由 AI 执行
  假设 建议的执行方式为“确认后由 AI 执行”
  当 负责人确认更新
  那么 记录确认人与时间
  并且 由 Agent 执行后续动作，人工不再重复填写

E. 权限与证据

场景: 来源无权限时遮蔽
  假设 生成依据中的某条来源不在当前查看人的数据权限内
  当 打开“查看依据”
  那么 不展示该来源的标题、时间与片段
  并且 显示“部分来源无查看权限”
  并且 其余有权限的来源正常展示

场景: 来源更新提示
  假设 任务生成后来源记录发生了更新
  当 再次打开生成依据
  那么 显示“生成后信息已有更新，请重新核对依据”
  并且 不静默替换旧证据

F. 去重与界面约束

场景: 同一目标重复命中不重复建主任务
  假设 主任务「报价方案确认」仍在进行中
  当 同一商机再次命中同一 Signal
  那么 续接原主任务
  并且 不新增第二个同语义主任务
  并且 触发历史保留两条记录

场景: 任务组件不撑开页面
  假设 当前商机有 11 条任务
  当 打开商机详情任务组件
  那么 列表区最大高度 420px，超出在组件内部滚动
  并且 表头滚动时吸顶
  并且 商机详情页整体高度不随任务数量增长

G. Signal 变更判定（From / To）

场景: 单选字段按变更前后命中
  假设 Signal 监听当前商机的销售阶段，变更前=需求确认，变更后=方案报价
  当 销售阶段从需求确认改为方案报价
  那么 命中该 Signal，生成一次执行
  当 销售阶段从方案报价改回需求确认
  那么 不命中
  当 销售阶段从商务谈判改为方案报价
  那么 不命中，因为变更前不匹配

场景: 只限定变更后
  假设 变更前=任意，变更后=赢单
  当 任一阶段改为赢单
  那么 命中
  当 赢单改为其他阶段
  那么 不命中

场景: 文本字段精确匹配
  假设 监听名称，变更前=待补充，变更后=已确认
  当 名称从「待补充」改为「已确认」
  那么 命中
  当 名称从「待补充报价」改为「已确认报价」
  那么 不命中，文本按精确值比较，不做包含

场景: 数值字段按值比较
  假设 监听商机金额，变更前=任意，变更后=1000000
  当 金额从 800000 改为 1000000
  那么 命中
  当 金额从 800000 改为 1200000
  那么 不命中
  并且 需要“变动超过 20%”这类规则时，本期不支持，见待确认 14

场景: 切换字段清空变更前后
  假设 已为销售阶段填好变更前=需求确认、变更后=方案报价
  当 把监听字段改为商机金额
  那么 变更前、变更后清空
  并且 控件切换为数值输入，不保留旧字段的选项值

场景: 团队人员变更按动作判断
  假设 团队角色=售前顾问，动作=加入
  当 为商机新增一名售前顾问
  那么 命中
  当 移除一名售前顾问
  那么 不命中

本版补充验收场景

1. 创建页只显示两类；组织型不填工作原则、不配 Signal 也可保存为对话助理。
2. 创建业务记录但无创建 Signal，仅建立服务关系，不产生执行任务。
3. Signal 创建任务显示当时负责人及代执行员工；切换当前负责人不改历史创建人。
4. 待执行 AI 动作遇负责人变更，按新负责人重新校验；范围不满足显示阻塞，不能继续使用旧负责人权限。
5. 组织型有定时任务但未选授权人不能保存；没有单独查询范围与运行方式控件。
6. 普通租户保留旧订阅，没有历史 Agent 模式入口；原灰度租户可保持旧绑定或明确切换。
7. 切换智能服务后相同 @ 仅响应一次；停用员工后原订阅仍有效。
8. 群指令变更在记录工作上下文同步生效；不扩大任何用户权限。
9. 旧版文件不变，新版演示状态隔离；个人与详情任务仍遵循同一展示／操作规则。

2.3 待确认事项

本版需评审：同一对象多配置重叠的唯一性策略；Team 适用范围统一口径；运行中写操作身份切换与结果核查；旧绑定回退机制；互联群外部成员边界。已确认的两类划分、负责人权限和 @ 提问人权限不再作为待定问题。

三、规范检查项

3.1 业务文案多语言 Key

建议四态（含已采纳、已撤销）、人工四态、Agent 七态、任务类型、Signal 命名、任务日志及拒绝说明等新增词条需纳入现有文案维护；Key 与英文文案随交互定稿，不在本轮虚构。

3.2 需求埋点

本轮无新增埋点方案。

3.3 沙盒/更改集能力

触发配置与 Agent / Team 能力配置的迁移方式随所属平台能力；本轮未验证，不承诺新增沙盒或更改集支持。

3.4 PaaS 国际化兼容检查

前台任务、状态、通知及日志文案需沿用原有语言机制；任务名称、回答与会话属于业务内容。翻译工作台等具体接入范围随首期页面确认，不新增独立翻译体系。

3.5 新对象/新字段 BI 分析申请

本轮未申请新的 BI 对象或字段；主子任务视图不等同新增 CRM 业务对象。

3.6 操作日志说明

任务日志展示触发依据、任务分工、状态、结果及执行会话；数字员工业务操作沿用既有操作归属与审计。触发检查未形成任务时仍需保留运行结果，避免日志只显示成功创建的任务而遗漏检查或异常。

3.7 需求风险点检测

3.8 上线策略

3.8.1 收费标准

待确认；Token／预算沿用平台全局设计，不单独设计数字员工计费体系。

3.8.2 上线节奏

待确认。建议以一条真实商机闭环为首期配套交付范围；具体上线日期以配套能力就绪及验收结果确定。

3.8.3 适用版本

适用版本与资源包待确认。

群级配置与权限边界（本轮收口）

• 群设置只保留群本身的成员范围、互联群开关、事件订阅和可选的群级工作指令。群级指令只能补充本群业务表达与协作约定，不能扩大数据权限、改变执行身份或覆盖数字员工强制规则。
• Agent/Team 选择、能力适用范围、数据对象权限、写入权限、Signal 执行身份和业务数据负责人解析，统一在数字员工后台配置；业务群不再重复维护一套权限配置。
• 群助手继续作为原生入口和消息承接身份保留，但不等同于数字员工成员。相关团队只展示真实员工；数字员工是否工作由当前对象负责人命中适用范围后决定，并在任务中显示“Agent 驱动”和实际执行人。
• 事件订阅与 Signal 分开管理：事件订阅决定群里通知什么，Signal 决定数字员工做什么；停用群入口不自动删除或停用业务数据上的数字员工配置。
• V1 群聊 Demo 中的“群级业务对象权限、自动化预设、工作机制”作为历史方案保留用于对照，不再作为 V4 的群内配置入口。

本轮交互补充（AI 方案建议）

• 类型暂推荐命名“通用助理型”，创建卡片标注“原 AI 助理”，说明“对话协作 + 定时批量任务”。批量作业仅是其中一种能力，不作为类型名。
• 类型选择用并列图文卡片：业务记录→数字员工→持续跟进；对话/定时→数字员工→答疑/汇总。窄屏纵向排列。
• 工作权限、群内 @ 规则收进可聚焦的问号帮助；选择 Agent/Team 页删除重复说明。
• 定时 Signal 有效期默认关闭，关闭表示持续有效。开启后开始/结束日期必填，结束不得早于开始；包含结束当天，按企业配置时区判断。单次执行时间必须在范围内。到期后不再触发新运行，已开始任务继续；有效期不等于任务完成期限，不补跑有效期之外的历史触发。Demo 演示表单与校验，不提供真实调度服务。
• 选择对象后再选择负责人字段；切换对象清空不适用的字段。权限仍固定跟随业务数据负责人，配置字段变化只影响建议处理路由。