AI 数字员工是什么 —— 《从零构建 7×24 小时 AI Agent》第一章
混沌福王在掘金发表的《从零构建 7×24 小时 AI Agent》一书第一章，系统梳理了从 RPA 到纯 AI Agent 再到 AI 数字员工的三代自动化方案演进脉络，提出核心设计原则”判断归 AI，执行归脚本”，并展开 Halo 数字员工系统的五层架构全景。
核心观点
1. 三代自动化方案的演进
文章将企业自动化分为三代，每一代都试图解决”让机器代替人做重复性工作”，但各有不可逾越的局限：
- 第一代 RPA（录制回放，规则驱动）：底层与 Selenium 同源，通过定位 GUI 元素模拟鼠标点击和键盘输入。代表厂商 UiPath 已在纽交所上市，Automation Anywhere 估值近 70 亿美元。优势是不需要 IT 部门配合、不依赖后台改造；致命缺陷是 UI 依赖——界面改版脚本立即失效、维护成本线性增长。
- 第二代 纯 AI Agent（每次从零推理）：2023 年后 LLM 能力突破催生，让 AI 直接操作浏览器。作者以”让 Agent 去京东买薰衣草香精”为例展示了从原型到生产的四个问题：延迟（每步都要 LLM 推理）、不稳定（每次执行独立推理，无历史记忆）、成本（每步都消耗 Token）、不可复用（会话结束经验消失）。
- 第三代 AI 数字员工（判断归 AI，执行归脚本）：将”做不做”和”怎么做”分离——AI 负责判断（审批是否该批、告警是否严重），Skill（确定性脚本）负责执行（登录系统、调接口、填表单）。一次性解决了前两代的核心问题：Skill 确定性执行、不消耗 LLM（毫秒级）、可共享安装、LLM 仅在判断环节消耗 Token。
2. “判断归 AI，执行归脚本”的核心原则
这不是简单的分工，而是将 AI 放到它最擅长的位置上：
- AI（判断）：需要理解力——审批单该不该批、告警严不严重、需要综合多个因素的决策
- Skill（执行）：需要可靠性——调接口、填字段、点按钮，要的是每次都做对
关键边界判断：“能确定性处理的尽量确定性处理。AI 只接手那些真正需要语义理解的部分。“每多一次 LLM 调用，多一份不确定性，多一笔 Token 开销。这个边界的设定不是技术问题，是产品判断。
3. browser_skill：判断与执行分离的工程实现
Halo 在通用 Skill（SKILL.md + 模型现场生成代码执行）基础上定义了自有形态 browser_skill——在 SKILL.md 外多带一段事先写好的脚本（index.js），由内置工具 browser_run 注入 Halo 内置浏览器的当前页面执行：
// .claude/skills/oa-approvals/index.js
async (params) => {
const resp = await fetch('/api/oa/approvals/pending',
{ credentials: 'include' })
return (await resp.json()).items
}模型不再现场生成执行代码，只决定调用哪个 browser_skill、传什么参数；脚本是确定性的、版本化的，与用户登录态和 cookie 共享同一份 session。AI 从 browser_skill 拿到结构化结果，根据用户预设规则做判断，再调用另一个 browser_skill 执行审批。
4. 两层市场的互驱模型
文章提出一个完整的生态设计：
- Skill 市场：给 AI 装能力——Agent 社区已有多个 Skill 市场（OpenClaw 的 ClawHub、Smithery、Claude Code Skills Registry 等），各平台合计数万个可安装 Skill
- 数字员工市场：组装好的数字员工本身也是可分发的——用户从市场安装数字员工，只需填几个配置参数，无需知道它依赖哪些 Skill、不会写 system_prompt、不需要理解 cron 表达式
两层互相驱动：Skill 越多，数字员工能组合出的场景就越多；数字员工的需求反过来驱动 Skill 的供给。类比：iOS 提供平台能力，开发者在上面构建 App，App 吸引用户，用户吸引更多开发者。区别是 Skill 市场的”消费者”不是人而是 AI。
5. 五层系统架构
Halo 系统按职责分五层，依赖方向只能向下：
用户交互层（UI —— 对话界面、文件管理、状态面板）
↓
数字员工编排层（定义、调度、运行记录 —— "谁在什么时候做什么事"）
↓
服务层（Agent 对话、AI 浏览器操作、多供应商模型接入、远程访问、通知推送）
↓
平台基础设施层（存储、调度、事件总线、记忆、后台保活 —— 不含业务语义）
↓
AI 引擎层（Agent Loop 核心循环 —— LLM 调用、工具解析、结果回传）
关键洞察：对话和数字员工共享同一条管道——从 Agent Loop 往下，对话和自动化共享同一个引擎、同一套工具、同一个执行环境。这意味着数字员工的能力上限等于 Agent 本身的能力上限。
6. 零适配接入企业内网：浏览器登录态复用
核心思想：不对接系统后端 API，而是复用用户浏览器的登录态（cookie）。AI 也在同一个浏览器里操作——cookie 在那里，网络请求从用户自己的电脑发出，内网系统看到的和员工自己操作完全一样。
与 RPA 的关键区别：RPA 依赖 UI 元素定位（CSS 选择器、XPath），界面改版脚本就崩；浏览器登录态复用走的是直接调用前端 HTTP 接口，接口比 UI 元素稳定得多。
工程上需要解决两个问题：①Electron 的反检测（注入 stealth 脚本修正浏览器指纹）；②AI 如何理解页面内容（无障碍树比截图 Token 消耗小一个数量级，但日常跑业务主路径仍是 Skill 直接调接口）。
7. 数字员工的 YAML 定义
一个数字员工的核心定义由四部分组成：
name: OA 审批助手
type: automation
system_prompt: |
每天早上 9 点检查 OA 待审批列表：
- 500 元以下且不是差旅费，自动批准
- 超过 500 元或差旅费，通过企业微信通知我
subscriptions:
- source:
type: schedule
config: { cron: "0 9 * * *" }
memory_schema:
last_processed_id:
type: string
description: 上次处理到的工单 ID
permissions: [ai-browser]一段自然语言加几行配置，就组装成一个会思考、有调度、有记忆、能操作企业系统的数字员工。
实操内容保留
数字员工定义 YAML 模板
name: <名称>
type: automation
system_prompt: |
<自然语言工作规则>
subscriptions:
- source:
type: schedule
config: { cron: "<cron 表达式>" }
memory_schema:
<需要跨次运行记住的字段>:
type: string
description: <字段说明>
permissions: [ai-browser]browser_skill 脚本模板
// .claude/skills/<skill-name>/index.js
async (params) => {
const resp = await fetch('<API 端点>',
{ credentials: 'include' })
return (await resp.json()).items
}调用方式：browser_run({ file: ".claude/skills/<skill-name>/index.js" })
原文精彩摘录
RPA 的存在源于一个普遍的组织困境。大型企业内部往往有几十套独立系统——OA、工单、征信、风控、ERP——分属不同部门，彼此没有 API 互通。一个审批流程可能要跨越三四个系统：从征信系统查询评分，到信贷系统查看申请，到风控系统执行规则校验，再回到信贷系统完成审批操作。要打通这些系统的后台接口，需要跨部门协调，排期往往以月计。而业务人员每天就在这些网页之间重复同样的操作，少则几十次，多则几百次。
这些问题指向一个根本矛盾：LLM 擅长理解和判断，但不擅长可靠地重复执行。每次执行本质上都是一次独立推理，而独立推理意味着不确定性。对于需要日常稳定运行的业务流程，不确定性是不可接受的。
Skill 处理”怎么做”，AI 处理”做不做”和”做哪个”。这条线画在对的位置，整个系统的稳定性上限才能拉上去。
传统企业内网对接：拉后端同事开会→要 API 文档→排期→联调→上灰度。一套系统几周，几十套系统几个月。浏览器登录态复用：登录一次，写一个 Skill 调前端接口。门槛从”需要 IT 部门配合”降到”会用浏览器开发者工具就行”。核心就一句话：你的浏览器能登录什么，AI 就能操作什么。
分层不是为了画图好看。每一层的存在都对应一个具体的隔离需求……不分层的代价（改一处崩十处）会随着代码量指数增长。
关键概念
- AI 数字员工（第三代自动化方案）
- 数字员工（更新：三代演进与技术架构）
- RPA数字员工（更新：与 AI 数字员工的对比）
- AI Agent 智能体（更新：纯 AI Agent 的局限性分析）
- Skill（更新：browser_skill 形态）
- AI办公自动化（主题关联）
相关资源
- 全书在线阅读：book.imwangfu.com
- 全书仓库：github.com/openkursar-flynn/build-ai-agent-platform
- Halo 开源实现：github.com/openkursar/hello-halo
- 博客原文：imwangfu.com/2026/05/ai-digital-employee-overview.html