AI 数字员工
第三代企业自动化方案的核心形态——将”判断”与”执行”分离：AI 负责理解、推理和决策（判断层），确定性脚本（Skill）负责稳定可靠地完成具体操作（执行层）。本质是一个持续存在的自主 Agent：有自己的工作周期、工作规则、执行能力、跨次运行记忆和通知通道。
简介
AI 数字员工是混沌福王在《从零构建 7×24 小时 AI Agent》一书中提出的第三代企业自动化方案，基于 Halo 数字员工系统。它与前两代方案（RPA、纯 AI Agent）的根本区别在于：不再让 AI 承担它不擅长的”可靠重复执行”，而是将 AI 的语义理解能力和确定性脚本的执行可靠性分离。
核心设计原则只有一句话：判断归 AI，执行归脚本。
与 数字员工（广义概念，以 LLM/Agent 为核心、需要持续培育的智能体形态）和 RPA数字员工（狭义形态，偏截屏识别+模拟点击的跨系统机械搬运）不同，AI 数字员工强调”AI 判断 + 确定性执行”的架构分离，是第三代方案的具体工程实现。
关键信息
| 维度 | 内容 |
|---|---|
| 类型 | 第三代企业自动化方案 / Agent 形态 |
| 核心原则 | 判断归 AI，执行归脚本 |
| 所属系统 | Halo 数字员工系统（开源：github.com/openkursar/hello-halo） |
| 技术架构 | 五层架构（UI → 编排 → 服务 → 平台 → 引擎） |
| 入口方式 | YAML 定义 + system_prompt + cron 调度 |
| 核心创新 | browser_skill（确定性脚本 + 浏览器登录态复用） |
| 生态设计 | Skill 市场 + 数字员工市场，两层互驱 |
| 适用场景 | 审批流程、定时监控、跨系统数据搬运、需要语义判断的重复性工作 |
三代方案对比
| 维度 | 第一代 RPA | 第二代 纯 AI Agent | 第三代 AI 数字员工 |
|---|---|---|---|
| 驱动方式 | 纯规则驱动 | 纯 AI 驱动 | AI 判断 + 确定性执行 |
| 执行方式 | 录制回放 | 每次从零推理 | 调用预封装的 Skill |
| 稳定性 | 稳定但死板 | 灵活但不可靠 | 既灵活又可靠 |
| 延迟 | 毫秒级 | 分钟级（每步都要 LLM） | 判断走 LLM，执行毫秒级 |
| 成本 | 低（维护成本高） | 高（每步消耗 Token） | 中（仅在判断环节消耗 Token） |
| 可复用 | 不可共享 | 经验不可复用 | Skill 可跨用户安装共享 |
| 核心问题 | UI 依赖，界面变脚本崩 | 每次独立推理，不稳定 | - |
核心特性
1. 判断与执行的架构分离
AI 负责”做不做”和”做哪个”，Skill 负责”怎么做”。这不是简单的分工，而是基于对 AI 能力边界的认知：
- 判断需要语义理解和上下文推理——审批单该不该批、告警严不严重、需要综合多个因素的决策→LLM 擅长
- 执行需要可靠性——调接口、填字段、点按钮，要的是每次都做对→确定性程序擅长
边界原则：“能确定性处理的尽量确定性处理。AI 只接手那些真正需要语义理解的部分。“每多一次 LLM 调用就多一份不确定性和 Token 开销。
2. browser_skill：确定性执行单元
在通用 Skill（SKILL.md + 模型现场生成代码执行）基础上，Halo 定义了 browser_skill——带有一份预先编写的 index.js 脚本，由 browser_run 工具注入内置浏览器执行。模型不现场生成执行代码，只决定调用哪个 browser_skill 和传什么参数。
browser_skill 的脚本是确定性的、版本化的，与用户登录态和 cookie 共享同一份 session。这解决了纯 AI Agent 的三个核心问题：执行不再依赖 LLM 推理（不会”发挥失常”）、速度从秒级降到毫秒级、可被安装、共享、版本化。
3. 数字员工的 YAML 定义
一个数字员工用自然语言 + 几行配置定义：
- system_prompt：工作手册——用自然语言定义判断逻辑和行为规则
- subscriptions：调度配置——cron 表达式、文件变动、Webhook 等触发源
- memory_schema：跨次记忆——记录上次处理状态，避免重复
- permissions：能力清单——声明可调用的工具和 Skill
4. 零适配接入：浏览器登录态复用
不对接系统后端 API，而是复用用户在浏览器中的登录态（cookie）。AI 在同一个浏览器中发送 HTTP 请求，内网系统看到的是正常的、有权限的请求。这解决了企业内网系统对接的最大痛点：不需要找后端团队要 API 文档、不需要排期联调、不需要 IT 部门配合。用户能登录什么系统，AI 就能操作什么。
与 RPA 的关键区别：RPA 操作 UI 元素（易崩），AI 数字员工直接调用前端 HTTP 接口（更稳定）。
5. 五层系统架构
用户交互层（UI）→ 数字员工编排层 → 服务层 → 平台基础设施层 → AI 引擎层
依赖方向只能向下。每一层的存在都对应一个具体的隔离需求：
- UI 和后端分离：数字员工可能在后台无人值守运行
- 编排层和服务层分离：“什么时候做”和”怎么做”变化节奏不同
- 平台层独立：不含业务语义，可被所有上层复用
- AI 引擎独立：封装模型和协议差异
关键设计：对话和数字员工共享同一条管道，从 Agent Loop 往下，对话和自动化共享同一个引擎、同一套工具。数字员工的能力上限等于 Agent 本身的能力上限。
6. 两层市场互驱
- Skill 市场：给 AI 装能力——Skill 可独立于特定数字员工存在，被共享、安装、版本化。Agent 社区已有多个 Skill 市场（ClawHub、Smithery、Claude Code Skills Registry 等），各平台合计数万个可安装 Skill
- 数字员工市场：组装好的数字员工本身也可分发——用户安装数字员工后只需填几个配置参数，不需要理解其底层依赖的 Skill、调度配置等工作细节
两层互相驱动：Skill 越多解锁越多数字员工场景；数字员工的需求反过来驱动 Skill 供给。类比 iOS 平台能力+App Store 模型，区别在于 Skill 市场的”消费者”是 AI 而非人。
不同素材中的观点
来自 2026-08-11-ai-digital-employee-halo-overview（混沌福王，《从零构建 7×24 小时 AI Agent》第一章）：
- 三代方案演进的核心规律不是技术复杂度提升，而是对 AI 能力边界的认知深化：第一代完全不信任 AI（全靠规则），第二代完全依赖 AI（判断和执行都交给它），第三代找到了正确的切分点
- “LLM 擅长理解和判断，但不擅长可靠地重复执行”——这是贯穿全书的设计原则。“判断→行动→获取反馈→再判断”的循环让 LLM 拥有了类似人类的反馈闭环
- “正确切分点是：Skill 处理’怎么做’，AI 处理’做不做’和’做哪个’。这条线画在对的位置，整个系统的稳定性上限才能拉上去”
- “传统企业内网对接：拉后端同事开会→要 API 文档→排期→联调→上灰度。一套系统几周，几十套系统几个月。浏览器登录态复用：登录一次，写一个 Skill 调前端接口。核心就一句话：你的浏览器能登录什么，AI 就能操作什么”
- “数字员工的能力上限不局限于审批、监控这类定时任务——写代码、生成报告、操作浏览器完成复杂调研，任何 AI Agent 能在对话中完成的事，数字员工都可以自主完成”
- 对 Halo 选择 Electron 的解释：不是因为轻量（很臃肿），而是因为它提供了打开企业内网的那扇门——内置 Chromium 提供完整的浏览器环境（cookie 隔离、CDP 协议、脚本注入）
- “不分层的代价（改一处崩十处）会随着代码量指数增长”
实用信息
与 RPA 和纯 AI Agent 的选型
| 场景特征 | 推荐方案 |
|---|---|
| 界面稳定、字段级搬运 | RPA数字员工 |
| 需要语义判断但步骤不确定 | 纯 AI Agent 智能体 |
| 需要定期执行、既有判断又有确定性操作 | AI 数字员工（本页） |
入门路径
- 找一个既有语义判断又有重复操作的工作场景（如审批流程、定时监控）
- 用 Halo 的 YAML 定义数字员工的工作规则和调度
- 为核心执行操作编写 browser_skill（直接调接口而非操作 UI）
- 让数字员工跑一个完整周期，根据日志调整判断规则
相关开源项目
- Halo 开源实现：github.com/openkursar/hello-halo
- 全书仓库：github.com/openkursar-flynn/build-ai-agent-platform
- 在线阅读：book.imwangfu.com