数字员工运行与前台协作框架产品方案

版本：v1.0 | 创建日期：2026-09-14

需求来源：用户沟通、现有 V3/V4 Demo、业务架构参考材料

优先级：P1

文档状态：草稿（核心产品逻辑已确认）

需求变更记录

依赖需求 Story 列表

一、需求概述

1.1 客户反馈

客户反馈结论： 无关联客户反馈。本方案来自产品方案共创，不将产品讨论改写为客户反馈。

1.2 系统现状

当前数字员工已经形成后台身份、负责对象、Agent 绑定和业务触发的交互 Demo，并在前台尝试覆盖个人工作台、商机详情、业务群和动态等入口。但现有方案仍存在三个根本问题：

1. 数字员工、Agent 本体、业务触发和运行时机制的责任边界尚未形成统一产品定义，容易把任务编排、权限校验、重试等平台能力错误暴露为租户配置。
2. 前台任务曾以固定面板占据业务群聊天区域，干扰原有信息流；不同入口也容易各自表达任务，缺少同一任务在多入口共享状态的统一规则。
3. 现有“修改记录”只表达数据变化，现有“动态”是任务、销售记录、日程等 Feed 的聚合组件，均不能直接代替数字员工的完整任务过程。

现有能力与本期处理边界：

现状依据：

• 数字员工方案/V3_20260909/：V3 保留版管理后台与前台协作 Demo。
• 数字员工方案/V4_20260913/：按设计稿更新后的管理后台 Demo。
• /Users/soren/Downloads/l2c-agent-l1-l6-architecture.html：业务能力分层和运行闭环参考，不作为本方案现有能力证明。
• /Users/soren/Downloads/opportunity-win-coach-agent-prototype.html：商机赢单场景参考，不要求按原架构实现。

1.3 竞品现状

本轮不新增竞品结论。已有 ServiceNow、Zoho、ClickUp 等调研仅作为历史背景，不作为本版产品规则的直接事实依据。

1.4 产品价值

本方案将数字员工从“能够被触发的 Agent 配置”明确为企业中的岗位责任主体，并以统一 CRM 任务承接持续工作。管理员只配置岗位和工作时机，Agent 负责业务判断，运行时负责可靠执行；业务用户在现有 CRM 场景中看到与自己相关的任务、协作和结果，不需要理解底层 Agent 运行过程。

1.5 需求目标

1. 明确 Agent 本体、数字员工岗位、业务触发和运行时的职责边界，避免租户配置侵入平台工程规则。
2. 让数字员工围绕客户、商机等单条业务数据形成可持续、可等待、可恢复、可确认和可验证的完整 CRM 任务过程。
3. 让同一任务按场景投影到个人工作台、商机详情、业务群和现有动态组件，状态一致且不干扰原有信息流。

二、产品方案

2.1 整体产品方案

数字员工是 Agent 在企业中的岗位身份和责任载体。它通过相关团队进入具体客户或商机，在业务事件、定时计划或人工请求发生后创建或关联正式 CRM 任务；Agent 根据本次目标进行分析、规划和执行，运行时负责权限、去重、状态、协作、确认、异常恢复和完成验证。

本方案的五项核心决策如下：

2.2 具体方案说明

2.2.1 适用范围与首期边界

首期以客户和商机作为负责对象，重点验证商机推进官等岗位数字员工。数字员工是岗位型 Agent，不包含个人 Share Agent，也不设计个人 Share Agent 向数字员工自动委派工作的机制。

首期规则：

• 同一租户内，同一种负责对象只允许存在一名启用的数字员工。例如商机相关工作统一由“商机推进官”承担，不再分别建立“重大商机推进官”“报价检查员”等多个负责商机的数字员工。
• 同一数字员工通过多个业务触发场景承担不同工作，并可以并发多个任务。
• 数字员工只有被加入某条客户或商机的相关团队后，才开始为该业务数据工作。该规则属于平台运行机制，不作为触发配置项。
• 首期不建设团队管理者视图，不覆盖移动端和投屏端专项体验。

2.2.2 核心概念

一个数字员工任务可以包含多次执行轮次。收到协作结果、业务事件或定时回查后，只唤醒原任务，不重复创建任务。

2.2.3 框架分层与职责

关键能力归属：

• Agent 本体决定“这件业务工作应该怎么做”。
• 数字员工岗位决定“谁以什么企业身份承担什么责任”。
• 业务触发决定“什么时候开始工作”。
• 运行时决定“工作如何可靠、安全地运行并完成”。
• CRM 业务底座提供真实业务数据、权限和操作回执。

权限、高风险和完成判定均采用“定义与执行分离”：数字员工获得岗位权限，运行时强制校验；Agent 判断业务风险，运行时执行强制门禁；Agent 判断目标是否达成，运行时根据完成证据落定任务状态。

2.2.4 数字员工岗位

数字员工岗位只定义：

• 名称、头像、部门和启停状态。
• 岗位使命、职责与工作原则。
• 负责的 CRM 业务对象。
• 绑定的 Agent 或 Agent Team。
• 数据权限、功能权限和相关团队角色。
• 可使用的能力范围。
• 默认业务负责人、确认角色和协作关系。

数字员工后台不配置：

• Agent 如何分析、规划和选择工具。
• 任务重试、幂等、并发数量和运行超时。
• 每次业务事件发生后的单独自然语言工作指令。
• Tool 失败、权限不足等平台异常处理。
• 业务群、动态、工作台等结果渠道的全局勾选。

当管理员创建第二名负责同一对象的数字员工时，系统不允许启用，并提示“商机已由商机推进官负责”。已有 Demo 中多个负责商机的数字员工样例，后续应合并为一名数字员工下的多个业务触发场景。

2.2.5 业务触发

首期支持两类触发：

1. 业务事件
   • 字段变更。
   • 团队人员变更。
   • 关联数据新增。
2. 定时任务
   • 执行频率。
   • 执行时间。
   • 本次定时工作目标。

业务事件可增加选填条件，默认不展开。负责对象直接继承数字员工岗位，不在触发中重复选择。团队角色从当前对象的相关团队角色实时获取并支持多选；关联数据只支持当前对象的一跳关联关系。

人工在业务群、动态、商机详情或工作台中 @ 数字员工，属于系统统一提供的人工唤醒入口，不作为管理员配置的业务事件类型。

数字员工产生的数据变化不允许递归触发当前场景；如果真实落库结果命中了另一个已启用场景，可以创建关联的后续任务。

2.2.6 何时创建任务

是否创建任务以“是否形成需要追踪的业务工作”为准，不以 Agent 实际运行时长作为唯一条件。

同一业务数据、同一目标的后续请求关联原活动任务；不同目标创建不同任务。已经完成的任务不重新打开，新变化产生新任务并关联历史任务。

任务创建时形成：任务目标、完成条件、触发来源、业务对象、数字员工责任主体和本次上下文。写入类任务即使立即完成，也必须保留正式任务记录，但不进入个人工作台的活动列表。

2.2.7 任务状态

“执行失败”不单独作为终态。短期故障自动重试；重试耗尽后进入已阻塞，目标失效时进入已终止。

2.2.8 协作请求与人工确认

协作请求复用 CRM 任务能力，作为数字员工任务下的人工子任务，支持四类：

• 补充信息。
• 业务判断。
• 操作确认。
• 人工执行。

协作请求保存指定处理人、所需输入、截止时间、来源任务和返回结果。人工提交结果后，系统唤醒原数字员工任务，由 Agent 重新读取最新上下文并决定继续、调整或完成；人工子任务完成不等于数字员工任务自动完成。

“负责人确认后执行”统一改为“指定确认人确认后执行”。确认人按动作动态确定：

• 核心字段、阶段、负责人等变化由业务对象负责人确认。
• 对外承诺、客户材料和交易相关动作由业务负责人或既有审批链确认。
• 人工发起且发起人具备确认权限时，可由发起人确认。
• 数字员工主动发现的问题默认由业务对象负责人确认。
• 没有有效确认人时，任务进入已阻塞，不自动放行。

个人工作台“待我处理”是确认请求的正式入口；系统通知负责提醒；业务群、动态和商机详情只显示来源状态和任务入口。确认操作应使用明确动词，例如“确认修改”“确认发送”“编辑后发送”“要求调整”“拒绝执行”。

高风险协作内容需要指定确认人确认后公开；低风险协作信息和普通建议可由数字员工及时进入业务群，不统一等待负责人确认。

2.2.9 权限与责任边界

权限分为四个相互独立的概念：

1. 谁可以咨询数字员工。
2. 谁可以向数字员工分配工作。
3. 数字员工自身可以读取和执行什么。
4. 最终结果可以向谁披露。

首期规则：

• 有权查看当前业务数据的用户可以在权限范围内咨询。
• 相关团队成员可以向该记录上的数字员工分配工作。
• 数字员工使用自身岗位身份和已授予权限执行，不因请求人权限更高而扩大权限。
• 人工 @ 产生的查询结果，同时受数字员工可访问范围和请求人可见范围约束。
• 请求人可以委派数字员工有权承担的跨角色工作，但不会因此取得数字员工的底层数据权限。
• 高风险动作仍需业务对象负责人、指定团队角色或既有审批链确认。

“指定团队角色”实时使用当前 CRM 对象的相关团队角色；“被授权人员”沿用既有数据、功能、相关团队和审批权限，不在数字员工首期新增一套人工名单。

业务群中的普通文本对所有群成员保持一致，只表达非敏感的动作和结论摘要；业务数据使用现有动态权限卡片，根据当前查看者权限加载字段和操作。

2.2.10 完成、恢复与后续任务

任务完成采用三层判定：Agent 判断工作是否做完，运行时校验完成证据，高风险或需要人工判断的事项由指定人员确认。

任务衔接分为三类：

• 等待条件满足后恢复原任务。
• 原目标完成但产生新的独立目标时，创建关联的后续任务。
• 本次真实业务结果命中其他触发场景时，由其他场景创建新任务。

同一事件不得重复触发同一场景，当前任务的写入不得重新启动当前任务。后续任务创建成功后，原任务再完成；后续任务记录由哪个任务结果触发。

2.2.11 异常、取消与恢复

异常处理遵循“可恢复则暂停，目标失效则终止，已完成动作不假装回滚”的原则。

任务发起人、当前业务对象负责人、具备相应管理权限的角色和系统管理员可以取消任务。取消后停止未执行步骤和待处理协作请求；已经落库、发送或创建的结果不自动撤销，需要撤销时另建修正任务。取消任务不等于关闭触发规则。

恢复执行前必须重新读取最新业务数据和权限，检查目标是否仍然有效、已有动作是否已经由其他人完成，并由 Agent 重新规划剩余步骤。部分动作已成功时只继续未完成部分，不重复执行成功动作。

2.2.12 并发与优先级

一个数字员工可以并发多个任务；首期不支持多个数字员工同时负责同一种业务对象。

优先级由 Agent 根据业务截止时间、风险影响、任务依赖、人工紧急请求、CRM 对象重要程度和等待时长判断；运行时负责最终排队、并发和抢占。租户管理员不配置优先级公式或最大并发数。

首期使用“紧急、高、普通”三级：普通任务默认不显示标签，高优先级弱提示，紧急任务明显提示。个人工作台按“需要我处理、紧急程度、截止时间”排序。

并发执行规则：

• 不同业务数据上的只读分析可以并行。
• 同一业务数据上的不同分析可以并行。
• 同一业务数据的写入动作在最终落库时顺序执行，并在落库前读取最新值。
• 等待人工、客户或业务变化的任务不占用执行资源。
• 紧急任务在当前最小执行单元完成后抢占，不中断正在提交或不可逆的动作。

任务发起人、业务对象负责人和任务管理角色可以将任务设为紧急。数字员工也可以因业务变化自动提高优先级，但必须说明业务原因。

2.2.13 主动反馈与通知

数字员工持续工作，但不持续打扰。运行记录默认仅在任务详情中查看；任务状态更新默认更新任务卡；只有需要人参与、出现重要变化或形成关键结果时才主动通知。

必须主动通知：

• 协作请求或高风险确认分配给当前用户。
• 用户发起的任务完成或终止。
• 主动任务发现重大风险。
• 任务阻塞并需要人工介入。
• 业务截止时间临近且目标未满足。
• 任务被提升为紧急。
• 新业务数据使原有关键结论发生明显变化。

保持静默：

• 普通自动任务开始。
• 常规分析、步骤切换和 Tool 正常调用。
• 自动重试。
• 没有新结论的周期检查。
• 正常执行且不需要人参与的过程。
• 已经在其他场景反馈过的相同结果。

长任务只在目标变化、等待、恢复、重要风险、人工确认、阶段性业务结果和终态等有效节点更新，不按固定频率发送“仍在处理中”。

2.2.14 前台场景映射

CRM 任务是唯一任务实体，四个前台场景是同一任务的不同投影。

个人工作台只收录分配给本人、本人发起、影响本人负责业务、本人关注或需要本人确认的任务，不因用户有查看权限而展示全部可见任务。当前不建设团队管理者视图。

商机详情中的“数字员工协作”默认采用紧凑摘要，不放置占据主区的大型固定卡片；展开后查看当前商机的完整数字员工任务。

业务群不再使用阻挡聊天信息流的固定任务面板。人工 @ 后先获得即时回应；形成持续工作时，在原消息处显示紧凑任务卡，点击打开统一任务详情抽屉。只有多人协作、共同风险、群内发起并期待群内结果等信息进入业务群。

动态继续使用现有右下角 Feed 组件，不新增“商机动态”组件。首期不建设新的数字员工业务结果 Feed；数字员工创建 CRM 任务、销售记录或其他现有 Feed 时，继续按现有 Feed 类型展示。未来可增加专门的数字员工业务结果 Feed，用于沉淀具有持续价值、可独立理解且需要后续回复的阶段性业务结果。

2.2.15 统一任务详情

四个场景打开同一任务详情抽屉，包含：

• 数字员工身份与业务对象。
• 任务目标、触发来源和触发原因。
• 当前状态、下一步和最近一次有效更新。
• 关键业务判断与依据摘要。
• 正在等待的协作或确认。
• 已执行的业务动作及回执。
• 完成条件和完成证据。
• 前序、后续任务关系。
• 当前用户有权使用的取消、补充和确认操作。

任务详情不展示模型思维链、底层提示词、原始 Tool 参数和无业务意义的内部日志。

2.2.16 修改记录、Feed 与后续“业务历程”

数字员工对业务数据的实际修改并入现有修改记录，操作者显示“商机推进官（数字员工）”。经过人工确认的操作同时记录确认人，不能把数字员工执行的修改记到人工名下。

数字员工任务、修改记录和 Feed 分别承担不同职责：

• 数字员工任务记录工作目标和执行过程。
• 修改记录记录具体字段变化。
• Feed 表达值得业务人员关注、回复和继续协作的业务内容。
• 动态组件聚合不同 Feed 类型。

“业务历程”是修改记录未来升级方向的暂定名称。后续可以将数据变化、协作、确认、外部动作、阶段结果和任务衔接整合为统一业务时间线，但不纳入首期范围。

2.2.17 Demo 优化范围

后续 V4 Demo 只做桌面端，并保留 V3 冻结版本。管理后台沿用已经确认的 V4 右侧数字员工交互和 V3 左侧菜单结构；前台重点演示三条链路：

1. 自动触发闭环：商机变化创建任务，向销售发起协作，销售在个人工作台补充，Agent 恢复执行，更新数据和修改记录，任务完成。
2. 业务群协作闭环：群内 @ 数字员工，当场回答或升级任务，原消息出现紧凑任务卡，协作结果返回原消息。
3. 高风险确认闭环：数字员工提出修改，指定确认人在个人工作台确认，系统执行并回查，修改记录显示数字员工和确认人。

并发能力通过个人工作台同时展示多个不同状态的任务体现，不单独增加演示流程。动态继续使用现有组件，不制作新的动态卡片容器。

2.3 待确认事项

三、规范检查项

3.1 业务文案多语言 Key

本轮先确定中文产品逻辑。任务状态、协作类型和操作按钮需在交互稿定稿后统一申请多语言 Key。

3.2 需求埋点

无。本轮不定义产品埋点；进入试点方案后再确定任务受理、协作响应、完成和阻塞等效果指标。

3.3 沙盒/更改集能力

3.4 PaaS 国际化兼容检查

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

3.6 操作日志说明

数字员工任务需要保留身份、任务来源、业务对象、关键状态、权限判定、人工确认、业务动作回执、完成证据和任务衔接。Agent 内部思维过程不进入用户可见操作日志；Tool 原始参数、模型上下文和敏感数据按平台审计与安全规范处理。

3.7 需求风险点检测

3.8 上线策略

3.8.1 收费标准

• [ ] 不收费
• [ ] 收费

待确认。本方案不根据模型调用成本推导产品定价。

3.8.2 上线节奏

• [ ] 全网
• [x] 灰度

3.8.3 适用版本