一种基于 LLM 的数字员工 (Digital Employee) 系统框架构想
本文档定义数字员工（Digital Employee，简称 DE）的主体模型、生命周期、系统边界和主要能力范围，作为后续详设的基础，在设计上保留与不同企业数字系统独立对接的能力。
文中出现的具体渠道、控制开关和工具等用于举例说明能力边界，非具体 feature 定义。
1. 数字员工的定义与交互特性
核心定义与基础特性
数字员工的建模起点与核心定义是：一个员工，只不过它不是人。
DE 应当具备以下基础特性：
- 主体性
- DE 在企业数字系统中是独立主体，与人类员工同级，在抽象上同为「员工」，是企业数字系统内的劳动力。
- DE 拥有独立的身份、组织关系、权限、职责和能力。
- DE 以劳动力身份在企业业务系统中「工作」时，由企业组织和具备相应权限的员工「管理」，不被任意交互用户「拥有」。
- 能力开放
- 任何人类员工使用的数字化系统，DE 都应当有能力使用。
- 数字化系统的使用和业务工作的执行，不因主体是 DE 而在架构层面被禁止。
- 某项能力实际 DE 能否使用、某项工作 DE 能否承接，由企业组织体系、规则与权限控制，像管控人类员工一样。
- 多源双向交互
- DE 可以直接与人类员工、其他 DE 双向交流。
- DE 既能被动接收输入，也能主动发起沟通，并通过 IM、文档、需求系统等不同渠道协作。
- DE 能够识别交互对象的身份、与自己的关系以及交互渠道；同一项工作可以跨人、跨渠道延续。
- 系统解耦
- DE 是企业业务系统和资源的使用者，本身不附属于某个已有业务系统。
- DE 系统独立于企业现有系统，负责数字员工的定义、运行与管理，也可以部署在企业私域内。
- 企业保留组织用工和业务管理的决策权，DE 系统通过明确的接入关系支撑这些决策的执行。
- 监管与治理
- DE 系统提供完整、可追溯的运行可观测能力。
- DE 的员工权限应由企业精细管理；DE 系统内的管理权限也应有明确边界。
与单用户助手的交互差异
DE 是一种特殊的 Agent。在交互范式上，与典型的单用户助手式 Agent 应用相比存在根本性差异。
- 典型的单用户助手式 Agent 应用
- Agent 不一定直接参与外部信息交互，也可以作为内部的处理节点或功能模块存在
- 这类应用以当前 user 及其会话为交互中心，通常围绕该用户的输入和助手的响应组织上下文
- DE Agent
- DE 一定拥有自然语言交互能力，DE 本身一定是与用户直接交互的主体
- DE 的中心不是 user，而是 DE 自己，其需要有能力在一个任务周期内，与多个不同的 user、在多个不同渠道内交互，在这种情况下 DE 需要区分「各种不同类型 & 来源的外部信息输入」，此时，扁平的单一 user 语义不再适用
多源双向交互的事件表达
这对应了数字员工基础特性中的第 3 条「多源双向交互」，因此对于 DE 来说，输入不能够是简单的 user input，而是能表达复杂语义的事件（event），每个事件都具备以下几个属性
- 从哪里来（IM / 邮件 / 文档评论 / trigger ……）
- 是谁发的（张三 / 李四 / DE_a / 自动报警 / ……）
- 和我什么关系（直属 leader / 普通协作方 / ……）
- 具体输入内容
相对应的，在 DE 对外响应 & 主动输出时，同样要发送类似的多语义事件
- 通过什么渠道
- 发给谁
- 具体内容
2. 双生命周期与数据归属
主体性是 DE 建模的基石。 它决定了 DE 不再是低人一等的工具/应用，而是可以平等协作的同事。它要求系统同时回答两个问题：谁来定义和维护这个员工本体，以及企业如何管理这个员工的任职与工作。
一个 DE 具有两个平行的管理维度：资源生命周期与劳动力生命周期。本文档也将某段劳动力生命周期称为「任职」。
伴随着两个生命周期的切分，DE 的授权、使用等所有相关行为与数据，也相对应的分成两个维度管控。
资源生命周期
DE 作为一个持续存在的 Agent 资源，在 DE 系统中被创建、定义、配置、发布和管理。
- 起点：在 DE 系统中创建，获得数字员工资源 ID。
- 终点：在 DE 系统中归档或删除。
- 管理内容：DE 本体的能力定义、渠道与工具挂载、版本等。
- 一个 DE 有且只有一个资源生命周期。
资源 ID 指向一个具体、持续存在的数字员工，不是用于生成多位独立员工的模板。
劳动力生命周期
DE 通过 contract 与企业建立任职关系，获得企业内的员工身份，接入企业渠道、工具和权限，开展业务工作。
- 起点：与企业建立任职关系，获得对应岗位的员工身份。
- 终点：离职，结束该段任职关系。
- 管理内容：企业身份、组织关系、企业工具与服务连接、运行状态和任职期间产生的数据等。
- 一个 DE 可以先后经历多段任职，但这些任职互不重叠，同一时刻最多有一段有效任职关系。
离职后，DE 本体仍然存在，之后可以建立新的任职关系。
两个生命周期的关系
两者不是「先完成资源阶段，再进入员工阶段」的串行关系，而是平行的管理维度。
DE 在任职期间，仍然可以被更新和维护。但是不同任职之间需要先后发生。
任职关系与版本
contract 指 DE 与企业建立任职关系的合约，任职关系将「 DE 资源 ID -- 企业及其提供的唯一员工身份 ID、部门、岗位、角色和组织关系」关联起来。
劳动力与资源是同步更新的，其本质上是同一个本体。 资源侧发布新版本后，当前任职中的 DE 同步使用更新后的能力；考虑到复杂度和必要性，不引入「多资源版本发布 - 企业自选劳动力版本部署」的模式。
数据归属
| 归属 | 主要内容 | 生命周期边界 |
|---|---|---|
| DE 资源 | 资源 ID、版本、基础能力配置、事件能力配置 | 随 DE 本体持续存在，由资源侧维护 |
| 任职关系 | 企业身份与连接配置，以及任职期间产生的会话、记忆、待办、业务文件和执行记录等 | 属于该段任职及对应企业，不带入下一段任职 |
举例：DE 资源定义中的 memory 指记忆「能力」和「机制配置」；工作中使用这种能力和机制形成的具体记忆属于任职关系。
当前暂不考虑将工作数据加工、回流到 DE 资源生命周期（例如自迭代）的机制。资源能力的更新通过手动定义、配置和发布完成。
离职后，原任职数据应当仍归对应企业管理。
3. 系统边界与总体架构
DE 系统独立于企业现有系统，专门承载数字员工的定义、运行与管理，覆盖资源和任职两个生命周期。
- 企业现有数字系统负责组织用工与业务管理的决策；
- DE 系统提供数字员工，以及落实这些决策所需的接入、运行和管理能力；
- DE 在企业授予的职责和权限范围内开展工作。
解耦意味着职责和决策权有明确边界，但是不意味着完全隔离，DE 系统承接的是「管理数字员工」这一完整场景。
企业劳动力身份的来源
理想情况下，企业使用与人类员工相同的账号体系管理 DE，并接入 DE 系统。
考虑到实际可行性，在通用抽象上，企业至少需要提供一个唯一、可识别的员工身份，使 DE 的任职、权限和业务行为有明确归属。至于该身份的具体账号形式、组织管理方式和业务权限，由企业自行决定。
DE 系统绑定并使用企业提供的身份，不另行替企业定义一套业务系统权限体系。
两个一级业务模块
一级模块按照双生命周期划分为 DE 资源管理和 DE 任职管理。
| 模块 | 管理对象 | 主要职责 | 主要管理角色 |
|---|---|---|---|
| DE 资源管理 | 持续存在的 DE 本体 | 创建、定义、配置、发布、资源供给与归档 | 资源管理员 |
| DE 任职管理 | DE 在某个企业中的任职关系 | 企业接入、任职建立与结束、企业连接、运行管理、任职数据与权限 | 员工管理员 |
资源管理覆盖 DE 作为 Agent 资源的管理需求；任职管理覆盖企业侧对数字员工的管理需求。
能力挂载与企业连接
资源侧选择给 DE 装配什么能力，任职侧将这些能力实际接入企业。
| 能力 | 资源管理 | 任职管理 |
|---|---|---|
| 事件渠道 | 为 DE 选择、挂载渠道能力 | 配置企业身份、接入鉴权、连接参数及适用于该段任职的渠道控制 |
| 工具 | 为 DE 挂载工具能力 | 配置该工具在当前企业中的身份鉴权及接入参数 |
| 记忆（举例） | 配置记忆能力和机制 | 管理该段任职中实际形成的记忆数据 |
例如，在资源管理中挂载「招聘需求管理」工具，在任职管理中配置当前企业身份对应的鉴权和参数。
具体配置项按生效范围判断归属：
- 对 DE 本体生效、随其不同任职延续的配置，归资源管理。
- 仅针对某段任职或该段任职中的某条连接生效的配置，归任职管理。
企业业务系统中的访问和操作权限由企业负责配置，DE 接入后天生受这些权限限制。
后续新增配置或能力时，继续以管理对象和生效范围判断归属：管理 DE 本体的，归资源管理；管理某段任职及其工作状态的，归任职管理。
管理角色与授权来源
| 身份 | 所属体系 | 职责与权限来源 |
|---|---|---|
| 资源管理员 | DE 系统-资源管理 | 管理 DE 本体的定义、配置、发布及资源生命周期 |
| 员工管理员 | DE 系统-任职管理 | 在 DE 入职时由用人方指定，管理该段任职、运行管理操作及任职数据权限 |
资源管理员与员工管理员是并列的 DE 系统角色，权限分别授予。两种角色可以由同一个人担任，资源管理身份本身不自动带来任职数据的任何相关权利。
员工管理员在 DE 入职时由用人方指定，管理范围限定于该任职。 DE 系统提供这两种角色能力上的区分，但不做所谓企业侧具体授权的接入/确认，换句话说，企业侧自行决定权力人的指定并在 DE 系统中为用户分配对应角色。
上级、隔级上级、协作方等角色属于企业业务语义，不等同于管理角色。DE 系统依据企业输入的组织关系识别这个身份，并在授权范围内向直属上级开放对其所管理 DE 的特定操作；此部分属于「事件语义处理」且需要重点设计，待详设补充。
总体架构与运行支撑
两个业务模块，实际上都会干预作为底层支撑的 Agent harness 配置，进而影响 DE 的实际运行行为；
而任职管理负责的企业数字系统的实际接入，理论上应该经过某种 gateway 类似实现，提供标准化连接和输入输出能力。
4. DE 资源管理
资源管理负责建立、维护和供给一个具体的数字员工，管理其创建、定义、配置、发布及归档。
两类能力定义
对应前述交互需求，我们要在通用 Agent harness 基础上，额外补充「事件语义处理」的能力，一个数字员工的构建就分为了两部分：
- 通用的 Agent 能力定义
- 面向数字员工场景的事件能力定义
| 类别 | 主要内容 |
|---|---|
| 代理能力定义 | model、prompt、skills、tools、subagent、memory 等通用 Agent 能力配置 |
| 事件能力定义 | 为该 DE 挂载的事件渠道，以及适用于该 DE 本体的事件行为配置 |
两者定义完成后，形成一个可管理、可发布的 DE 资源，包含资源 ID、版本、基础能力声明和事件能力声明。
渠道能力的挂载
渠道作为通用能力由 DE 系统预定义并提供，按每个 DE 的定位选择挂载。例如，一个 DE 可以挂载飞书、Jira、Confluence 渠道；另一个以沟通协调为定位的 DE，可以只挂载飞书渠道。
Subagent 与独立 DE
Subagent 是某个 DE 的内部执行分工。DE 可以在配置允许的范围内自主 spawn subagent，其对外行为归属于这个 DE，在该 DE 的任职与授权范围内开展工作。
独立 DE 则有自己的资源身份、任职关系和权限，与其他 DE 通过事件协作。
选择依据是：企业是否需要单独给它派活、管理它、验收它的结果。
- 企业向招聘 DE 交代任务，由它内部调用「简历分析 subagent」完成分析，仍由招聘 DE 对整体交付负责。
- 企业需要其他员工能直接找一位「简历评估员」，为其单独安排工作、配置权限、评价交付，则适合创建新的 DE。
这两种选择分别对应「增强现有员工的内部执行能力」和「增加一个有独立职责的员工」。在两种方案之间，没有明确独立用工需求时，优先采用 subagent。
5. DE 任职管理
任职管理承载数字员工在劳动力周期的管理职责，覆盖企业接入、任职关系、数据治理等。
任职管理的能力范围
| 类别 | 主要内容 |
|---|---|
| 员工身份定义 | 与企业岗位建立 contract，绑定资源与员工身份，关联组织关系等身份相关上下文 |
| 渠道连接 | 配置接入企业侧实际的渠道连接 |
| 工具/资源连接 | 配置接入企业侧实际的工具/资源连接 |
| 数据管理 | 查看管理数字员工在工作期间生产的数据 |
- 接入企业，明确企业身份来源。
- 通过 contract 建立 DE 的任职关系，绑定 DE 资源 ID 与企业内唯一员工身份，并由用人方指定该段任职的员工管理员。
- 接收企业提供的部门、岗位、角色、直属上级等组织信息，使 DE 能够识别自己的任职与交互关系。
- 配置资源侧已挂载的渠道、工具在企业中的实际连接。
- 管理任职结束以及对应企业连接、工作状态和数据的后续处理。
Session 操作与人工干预
日常围绕「单个」持续工作的 session 运行。
系统保留多 session 能力作为人工干预的兜底，DE 工作 session 的新建与切换由有权限的人显式操作，不由 DE 自主决定。任职期间的 session 管理归任职管理，员工管理员可以根据需要，面向特定事件角色开放 session 操作能力。
此类操作由系统校验身份、权限并确定性执行，可以通过明确指令或操作入口触发，不依赖 DE 自行猜测用户是否想切换 session。具体入口与开放范围待详设。
任职数据、可观测与授权
任职管理承载工作中形成的会话、记忆、待办、文件和执行记录等数据的管理，遵循前述双生命周期的数据边界。
系统需要支持对接收事件、执行动作、工具调用、输出结果和运行状态的记录与追溯。可观测是系统能力，谁能查看和使用这些数据由企业授权决定。
员工管理员负责对应任职的数据授权，资源管理员同样需要获得授权。
6. 底层运行与接入
通用 Agent harness
Harness 负责 Agent 的实际执行，是资源管理和任职管理共同依赖的底层能力。资源侧提供 DE 能力定义；任职侧提供任职身份、企业连接、行为约束与工作状态，两侧共同影响运行行为。
通用部分可以评估采用已有的托管式 Agent 构建与运行框架，例如 LangChain Deep Agents，框架设计保留以下基础能力：
- Agent loop：LLM 推理与 Action 执行循环。
- Skills、tools、subagent 等能力装配与调用。
- 执行环境与文件系统。
- 中间件扩展、安全约束与权限控制。
- 人在环机制，以及暂停、确认和续跑能力。
- State、checkpoint 与持久化能力。
Gateway 与企业接入
Gateway 是任职管理的一部分或支撑能力，负责连接 DE 运行环境与企业渠道、业务系统和资源，承担接入鉴权、参数适配、信息转换、交互控制与记录等工作。
它与事件语义处理能力协同，将企业输入传入 DE，并将 DE 的事件输出与工具操作送达企业系统。连接所使用的身份和权限以企业授权为依据。
Gateway 描述的是企业接入能力中间适配层，具体实现方式待技术选型。
事件语义处理
DE 的外部输入应以具有明确语义的事件表达，保留渠道、身份与关系信息，不能只剩下一条不区分来源的「user 指令」。
输入事件至少需要表达以下语义，具体字段和枚举待详设：
| 语义 | 示例 |
|---|---|
| 来源渠道或触发来源 | 飞书、Jira、Confluence、定时触发、自动报警等 |
| 发送者身份 | 某个人类员工、另一个 DE、系统主体等 |
| 发送者与当前 DE 的关系 | 直属上级、同级协作者、外部协作者等，均为示例而非最终枚举 |
| 输入内容 | 消息正文及相关业务信息 |
来源渠道与发送者关系是不同维度。身份及关系由系统依据企业提供的信息确定，消息正文中的自我声明不能自行改变这些属性。组织关系在入职时输入，后续更新机制需要在详设中明确。
DE 响应和主动发起的输出事件，需要表达通过什么渠道、发给谁、发送什么内容，并使用当前任职身份。
事件语义处理不仅负责事件内容构造，还要把企业身份、组织关系转化为 DE 的行为约束。 这一能力范围包括：
- 语义构造：识别并组织渠道、发送者、关系与内容等信息。
- 指令层约束：定义不同关系的输入应如何理解、处理及响应。
- Harness 执行层约束：校验相应控制操作和执行动作的权限，限制、管控 DE 行为。
- 输出处理：构造响应或主动输出事件，并应用相应渠道与行为约束。
工作环境与上下文管理
当前以「DE 有自己的虚拟主机」定义其专属 workspace 和执行环境，实际采用何种运行载体待技术选型。
基于通用的滑动窗口、压缩、剪枝等方式管理上下文大小，使用类似 todo 管理的工具保存和恢复实际在跟进的工作。
具体上下文策略与待办机制尚未确定，不在本框架中展开。专属工作环境中的任职数据仍遵循双生命周期的数据边界，不随 DE 带入后续任职。
7. 关键详设的事项
以下事项已有明确的能力范围，其中第一项是数字员工「能跑起来」的关键实现，具体 feature、交互和技术实现后续展开：
- 事件语义处理：事件结构、来源与关系枚举、关系更新、指令规则与 harness 行为限制，以及事件输出机制。
- 上下文与运行管理：滑动窗口、压缩、剪枝、todo 等机制；人工 session 控制入口、授权范围及切换后的工作衔接。
- 企业接入与授权：企业身份接入、员工管理员的指定与身份确认、直属上级关系输入，以及数据与运行操作的授权流程。
- 生命周期衔接：入职、离职与资源归档的处理流程，资源版本统一更新与运行中工作的衔接，离职后的企业连接及任职数据处理。
- 能力配置与技术选型：主动发事件等控制项的生效范围，渠道与工具的具体接入方案，harness、gateway 和执行环境的实现选择。