第一章：全景 — AI 数字员工是什么

---

阅读导航： 本书章节标题暗藏一条线索——我们在造一个"人"。第一章（全景）建立坐标系，第三章（大脑）是技术密度最高的核心章，第四至十二章各拆解一个"器官"，可按兴趣跳读，第十三章换视角讲"一个人加 AI 如何构建这个系统"。贯穿全书的设计原则只有一句话：判断归 AI，执行归脚本。你会在每一章看到它的不同表达。

---

1.1 从 RPA 到 AI Agent 到 AI 数字员工：三代方案的演进

在"AI 数字员工"这个概念出现之前，企业自动化经历了三代方案。三代方案试图解决同一个问题：如何让机器代替人完成重复性工作。每一代都比前一代更进一步，但也都碰上了自己无法逾越的限制。

第一代：RPA——录制回放，规则驱动

RPA（Robotic Process Automation，机器人流程自动化）是一个年规模超百亿人民币的成熟行业。代表厂商 UiPath 已在纽交所上市，Automation Anywhere 估值近 70 亿美元。技术上，RPA 的底层与 Selenium 同源——通过定位 GUI 元素、模拟鼠标点击和键盘输入来驱动应用程序，再将这些操作封装成可视化流程，供不具备编程能力的业务人员使用。

RPA 的存在源于一个普遍的组织困境。大型企业内部往往有几十套独立系统——OA、工单、征信、风控、ERP——分属不同部门，彼此没有 API 互通。一个审批流程可能要跨越三四个系统：从征信系统查询评分，到信贷系统查看申请，到风控系统执行规则校验，再回到信贷系统完成审批操作。要打通这些系统的后台接口，需要跨部门协调，排期往往以月计。而业务人员每天就在这些网页之间重复同样的操作，少则几十次，多则几百次。

RPA 提供了一条不依赖后台改造的路径：在 UI 层模拟人的操作。 录制一遍操作流程，生成脚本，7×24 小时循环执行。不需要 IT 部门配合，不需要系统开放接口，采购 license 后即可部署。银行、保险、证券的运营部门是 RPA 的核心客户群。东方证券曾公开披露，他们通过 RPA 优化了 140 个业务流程，涉及 90 套内外部系统。

在结构固定、界面稳定的场景中，RPA 的表现接近理想。

但它的局限同样明确。RPA 脚本依赖固定的 UI 元素定位——CSS 选择器、XPath 或屏幕坐标。界面一旦改版，元素位置变化，脚本立即失效。页面出现预期之外的弹窗或加载延迟，执行流程中断。更根本的限制在于，RPA 只能执行预定义的规则分支，无法处理需要语义理解的判断——"这笔申请的材料是否完整""这条告警是否需要升级处理"，这类问题超出了规则引擎的能力边界。

维护成本是 RPA 在企业落地后面临的最大挑战。每个新流程需要重新录制，每次界面变动需要人工修改脚本。当企业部署上百个自动化流程后，脚本维护量线性增长，最终成为沉重的技术债务——与维护大规模 E2E 测试套件的困境如出一辙。我在文档团队工作时亲眼见过这种情况：几个人专职维护 RPA 脚本，节省的人力与投入的维护成本几乎相抵。

第二代：纯 AI Agent——每次从零推理

2023 年之后，大语言模型的能力突破催生了第二代方案：让 AI 直接操作浏览器。思路很直接——LLM 能理解自然语言指令，能分析页面截图，能推理下一步操作，那么让它像人一样在浏览器中完成任务，理论上可以绕过 RPA 的所有限制。

我曾经发过一段这样的视频：让 Agent 去京东买一瓶薰衣草香精，"100 ml、法国产、评价 4.8 以上"。屏幕上，浏览器自主弹出，搜索框被敲入关键词，结果一条条滚过；它在第三条停下，点进详情页，比对产地、容量、用户评价；返回列表，再点开另一条做二次对比；筛选条件被调整一次又一次，购物车里的商品被加入又被清空，最后定格在结算页。从输入到结算，全程没有人碰键盘鼠标——单看演示，这条路看起来已经通了。

但从原型到生产环境，四个问题逐一暴露：

延迟。 每个操作步骤都需要重新获取页面状态、调用 LLM 推理。人工 10 秒能完成的操作，Agent 需要 1-2 分钟。LLM 推理耗时叠加网络往返，使得批量处理场景的总耗时远超人工操作。

不稳定。 每次执行都是独立的推理过程，没有对历史执行路径的记忆。同一个任务今天成功、明天可能失败——页面加载时序的微小变化、元素渲染的延迟、网络波动，都可能导致推理路径偏离。

成本。 每个操作步骤都消耗 LLM Token。一次包含二十步操作的审批流程，Token 消耗可达数千乃至上万。当任务量从演示级别扩展到日常业务规模，成本迅速失控。

不可复用。 Agent 在一次会话中积累的操作经验——哪个按钮在哪、接口返回什么格式——存在于当次对话的上下文中。会话结束，经验消失。另一个用户面对同样的系统，需要从头开始。

这些问题指向一个根本矛盾：LLM 擅长理解和判断，但不擅长可靠地重复执行。 每次执行本质上都是一次独立推理，而独立推理意味着不确定性。对于需要日常稳定运行的业务流程，不确定性是不可接受的。

第三代：AI 数字员工——判断归 AI，执行归脚本

Halo 的设计从一个不同的问题出发：能否让 AI 只做它最擅长的事？

有些事需要判断力：这条工单该不该批？金额没超标，但申请人上周刚被风控标记——这类需要综合多个因素、没有固定答案的决策，是 AI 擅长的。另一些事需要可靠性：登录系统、调用接口、提交表单——步骤固定，要的是每次都做对，一段验证过的脚本比 AI 推理更可靠。前两代方案的问题，本质上都是把这两种能力混在了一起——RPA 完全排除了 AI 的判断能力，纯 AI Agent 又把执行的可靠性也交给了 AI。

第三代方案的核心是将两者分离：

第一代 RPA          第二代 AI Agent       第三代 AI 数字员工
────────────       ────────────────     ──────────────────
纯规则驱动          纯 AI 驱动            AI 判断 + 确定性执行
录制回放            每次从零推理           调用预封装的 Skill
稳定但死板          灵活但不可靠           既灵活又可靠
能力不可共享         经验不可复用           两层市场互驱生长

在 Halo 的架构中，AI 负责一件事：根据当前状态和用户设定的规则，决定做什么、什么时候做、做还是不做。"怎么做"交给预先编写并经过验证的 Skill——一段确定性代码，接受配置参数，返回结构化结果，执行过程不依赖 LLM 推理。

这个区分一次性解决了前两代的核心问题。Skill 是确定性的，不存在"推理偏差"；执行不经过 LLM，耗时在毫秒级别；一个人编写的 Skill，所有用户都可以安装使用；LLM 仅在判断环节消耗 Token，执行环节的边际成本为零。

回头审视三代方案的演进脉络，区别不在于技术复杂度，而在于对 AI 能力边界的认知。第一代完全不信任 AI，全靠规则；第二代完全依赖 AI，将判断和执行都交给它；第三代找到了正确的切分点——AI 负责判断，确定性脚本负责执行。这个原则贯穿本书后续每一章的设计决策。

一个数字员工的完整工作周期

以一个具体的业务场景说明第三代方案的完整工作方式。

一个运营人员每天登录公司 OA 系统，逐条检查待审批工单，500 元以下的直接批准，超过 500 元的上报主管。这件事他每天花 40 分钟，重复了两年。

在 Halo 中，他用自然语言创建一个数字员工："每天早上 9 点检查 OA 待审批列表，500 元以下自动批准，超过 500 元通知我。"

这个数字员工不是一段脚本，也不是一次对话。它是一个持续存在的自主 Agent：有自己的工作周期（每天 9 点由调度引擎唤醒），有工作规则（用户用自然语言描述的判断逻辑），有执行能力（已安装的 OA 审批 Skill），有跨次运行的记忆（知道昨天处理到了哪一条），有通知通道（能通过企业微信主动联系用户）。

第二天早上 9 点，调度引擎唤醒它。它调用 Skill 获取待审批列表——这一步是确定性脚本，毫秒级完成，不消耗 LLM。拿到列表后，AI 逐条做判断：金额、类目、申请人历史记录，综合决定批还是不批。12 条自动批准，3 条超过阈值，通过企业微信发送一条汇总消息。整个过程用户没有参与，打开 Halo 可以回看完整的工作日志——每一步调用了哪个 Skill、AI 的判断依据是什么、最终执行了什么操作。

这就是第三代方案的最终产物。RPA 能做到定时执行和自动点击，但无法根据内容做语义判断。纯 AI Agent 能做判断，但每次都从零推理，不稳定且成本高。数字员工将两者的优势整合在一起：AI 负责理解和决策，Skill 负责可靠执行，调度引擎负责按时唤醒，记忆系统负责跨次连续性，通知系统负责主动汇报。

这还只是单个数字员工的工作方式。多个数字员工之间可以互相通信——审批助手发现一笔异常采购，通知风控助手介入核查；风控助手完成核查后，将结论回传给审批助手继续处理。它们各自有独立的工作规则和记忆，但能在需要时协作，形成跨职能的工作流。第九章会展开数字员工之间的通信机制。

驱动这些数字员工的底层引擎与驱动对话的引擎完全相同——同一个 Agent Loop，同一套工具调用机制，同一个 LLM 推理循环。区别仅在于触发方式：对话由用户输入触发，数字员工由调度引擎按时间或事件触发。这意味着数字员工的能力上限不局限于审批、监控这类定时任务——写代码、生成报告、操作浏览器完成复杂调研，任何 AI Agent 能在对话中完成的事，数字员工都可以自主完成。第三章会展开这个通用引擎的完整架构。

后面每一章拆解的，就是这个场景背后的每一个技术环节。

---

1.2 判断与执行的架构分离

上一节用三代方案的演进引出了一个结论：AI 擅长判断，不擅长可靠地执行。这一节把这个直觉变成一个可操作的架构原则，然后看它怎么落进代码里。

分离确定性操作

判断需要理解力——这条审批单该不该批？这个告警严不严重？没有固定答案，需要语义理解和上下文推理。LLM 是为这个设计的。

执行需要可靠性——调一个接口，填一组字段，点一个按钮。要的是每次都做对，失败了能重试，结果可预期。这是确定性程序的领域。

让 AI 承担执行，等于让一个擅长即兴发挥的演员去当流水线工人。流水线不需要创造性地理解怎么拧螺丝——它需要每次都拧到同样的扭矩。

Halo 数字员工的架构原则由此而来：AI 只管判断，执行交给确定性脚本。

从 Skill 到 browser_skill

Skill 在 Claude Code、Codex 等 Agent 工具中已经是成熟概念。本质上，Skill 是 Agent 的扩展能力包——以文件形式存放于约定目录，运行时加载描述信息进上下文，由 Agent 依据其中的能力描述自主判断何时启用、如何执行。其中的"执行"通常由模型现场生成代码完成：读完描述，写一段 bash 或 Python 丢进沙箱跑。这种通用 Skill，Halo 也直接支持。

Halo 在此之外定义了一种自有形态——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_run({ file: ".claude/skills/oa-approvals/index.js" })

模型不再现场生成执行代码，只决定调用哪个 browser_skill、传什么参数；脚本本身是确定性的、版本化的，与用户登录态、cookie 共享同一份 session。browser_skill 作者只管写"做什么"，"在哪做、以谁的身份做"由 Halo 环境提供。脚本可以人工编写，也可以由 AI 根据用户实际操作自动生成。这套机制依赖 Halo 内置浏览器与脚本运行环境，普通 Claude Code 没有对应承载。第八章会展开这套执行环境。

AI 的角色由此清晰：从 browser_skill 拿到结构化结果，根据用户预设的规则（"500 元以下自动批，差旅费一律通知我"）做判断，再调用另一个 browser_skill 执行审批。判断走 LLM，执行走脚本。

这个切分解掉了纯 AI Agent 的三个核心问题：执行不再依赖 LLM 推理，不会"发挥失常"；速度从秒级降到毫秒级，LLM 只在判断环节消耗；browser_skill 是文件，可被安装、共享、版本化——能力可以跨用户积累。

一个数字员工长什么样

Skill 是执行单元——前面已经看到它的形态（一段 JS 嵌在 .md 描述里）。那判断单元——数字员工本身——长什么样？

一份 YAML。下面是 1.1 那个 OA 审批数字员工的精简定义：

name: OA 审批助手
type: automation
system_prompt: |
  每天早上 9 点检查 OA 待审批列表：
  - 500 元以下且不是差旅费，自动批准
  - 超过 500 元或差旅费，通过企业微信通知我
  - 同一申请人 7 天内第 3 次申请，标记复核
subscriptions:
  - source:
      type: schedule
      config: { cron: "0 9 * * *" }
memory_schema:
  last_processed_id:
    type: string
    description: 上次处理到的工单 ID，避免重复
permissions: [ai-browser]

一个数字员工的核心定义由这几个部分组成：

• system_prompt 是它的工作手册。用户用自然语言告诉它该做什么、怎么判断、什么情况找人。运行时这段文本被注入 LLM 的 system message，决定每次唤醒后的行为。
• subscriptions 是它的上班时间。这里是 cron 表达式（每天 9 点）；也可以是文件变动、Webhook 调用、关键字订阅等触发源。第六章展开调度引擎。
• memory_schema 声明它需要跨次运行记住的字段。运行结束时由 Agent 自己写回，下次唤醒时自动加载。第七章展开记忆系统。
• permissions 是它的能力清单。声明 ai-browser，它就能调用浏览器相关的内置工具与已安装的 Skill。

一段自然语言加几行配置，就构成了一个会思考、有调度、有记忆、能操作企业系统的数字员工。代码里它对应 AutomationSpecSchema（src/main/apps/spec/schema.ts），第五章展开 App Spec 的完整定义。

边界在哪

判断和执行的分离不是一刀切的。实践中总有灰色地带。

比如"从告警页面找出最近 3 天的 P0 告警并按时间排序"。这件事可以完全写在 Skill 里——确定性地抓取、过滤、排序。也可以只让 Skill 抓取原始数据，排序和筛选交给 AI 处理。

但"帮我调研一下市面上关于 XX 的所有方案"就完全不同。搜什么关键词取决于对问题的初步理解，看哪几条结果取决于标题和摘要是否相关，看完之后要不要换个角度再搜取决于第一轮信息是否充分——每一步都是上一步结果的函数，整个执行路径在过程中才浮现。这种事没法写成 Skill，只能交给 AI 在 Agent Loop 里一步步推理。

我们的取舍倾向是：能确定性处理的尽量确定性处理。 AI 只接手那些真正需要语义理解的部分——"这条告警严重吗"、"要不要半夜叫醒用户"、"这条审批该不该批"。

原因很实际：每多一次 LLM 调用，多一份不确定性，多一笔 Token 开销。确定性代码零成本、行为可预测。判断环节省下来的 Token 预算，可以用在更复杂的推理上——比如让 AI 综合多个 Skill 的返回结果做跨系统的决策。

这个边界的设定不是技术问题，是产品判断。把几乎所有逻辑都扔给 AI，Token 消耗会很快失控，运行一次审批流花掉的钱比让人手动审批还贵；把 Skill 写得过度复杂、内部嵌满条件分支，结果跟 RPA 脚本一样脆弱。

正确的切分点是：Skill 处理"怎么做"，AI 处理"做不做"和"做哪个"。这条线画在对的位置，整个系统的稳定性上限才能拉上去。

执行端被标准化成独立的 Skill，还带来一个延伸效果：可以安装、版本化、跨用户积累，像 npm 包一样在社区流通。下一节展开两层市场如何互相驱动。

---

1.3 两个市场

Skill 市场：给 AI 装能力

1.2 介绍了 Skill 的本质——Agent 的扩展能力包，以文件形式存放，运行时加载进上下文。单个 Skill 解决单个问题：拉一个系统的待办列表，提交一条审批，发一条通知。

当 Skill 可以独立于特定数字员工存在，它就具备了被共享的条件。一个工程师花几小时封装了公司 OA 系统的审批接口，发布成 Skill，团队里所有人的数字员工都能直接调用。下一个想自动化同一套 OA 的人，不需要重做这件事。

这和 npm 生态的逻辑一样：门槛低（一份 .md 描述加一段脚本），解决的是自己的问题，顺手发布出去，别人直接装。npm 2010 年上线时几百个包，2015 年超过 10 万个。增长的关键不是某家公司拼命写包，而是任何人都能贡献。

Agent 社区已经围绕 Skill 的共享建立了多个市场——OpenClaw 的 ClawHub、Smithery、Claude Code Skills Registry 等各自收录数千条目，各平台合计已有数万个可安装的 Skill，且仍在快速增长。方向很明确：Skill 应该像 npm 包一样，写一次，到处装。

但这一层解决的问题有明确边界：它给 AI 装能力，让 Agent 能做更多事。谁来决定做不做、什么时候做、做完告诉谁——这不是 Skill 市场管的事。

光有 Skill 还不够

传统 Agent 生态只有 Skill 这一层市场。用户想用 AI 自动化一件事，流程是这样的：找到合适的 Skill → 安装 → 写一段 system_prompt 告诉 Agent 工作规则 → 配置调度（什么时候跑）→ 调试参数直到行为符合预期。

这个过程本身是技术性的。你需要知道哪些 Skill 能组合出你要的效果，需要会写提示词，需要理解调度配置的含义。对工程师来说不算难，但对想用 AI 帮忙处理日常事务的运营、行政、财务人员来说，这和"自己写代码"没有本质区别——门槛换了个形式，还是在那里。

类比一下：npm 让你可以安装任何包，但要把十几个包组装成一个能跑的应用，你还是得会写代码。Skill 市场给 AI 装了能力，但把这些能力组装成一个能持续运行的自动化流程，仍然需要专业知识。

数字员工市场：直接雇一个人

Halo 的设计理念是：组装好的数字员工本身也是可分发的。

以"小红书发布助手"为例。这个数字员工底层依赖多个 Skill（登录小红书、发布帖子、监控评论、回复互动），有一段经过调试的 system_prompt 定义它的工作规则和判断逻辑，有预设的调度配置（每天几点运行），有 memory_schema 记录已处理的内容。所有这些已经组装完成、调试通过。

用户从市场安装这个数字员工，需要做的事只有一件：填几个配置参数（账号偏好、发布频率、内容方向）。不需要知道它依赖哪些 Skill，不需要自己写 system_prompt，不需要理解 cron 表达式。

这个体验的区别，就像去人才市场直接雇一个人，而不是自己去买工具、安装它、从零搭建一套流程。你雇的是一个已经具备相关技能的员工，告诉他你的具体要求，他就能开始工作。你不需要关心他是怎么学会这些技能的。

同一个数字员工模板，不同用户可以有不同的行为。用户 A 告诉审批助手"500 以下自动批"，用户 B 告诉同一个助手"采购类一律通知我"——底层调用的 Skill 完全一样，行为由 system_prompt 的自然语言规则决定。

两层如何互相驱动

Skill 市场和数字员工市场不是各自独立的，它们之间有互相驱动的关系。

Skill 越多，数字员工能组合出的场景就越多。今天有人封装了"抓取产品价格"的 Skill，明天就有人基于它构建"竞品价格监控助手"数字员工。一个底层能力的增加，解锁的不是一个场景，而是一类场景。

反过来，当有人想做某个数字员工但发现缺一个特定 Skill——比如"从某个系统导出周报数据"——他去写一个，发布到市场，所有人都能用。数字员工的需求驱动 Skill 的供给。

两层分开，各自积累，互相放大。这和移动平台的模型类似：iOS 提供平台能力（GPS、摄像头、推送），开发者在上面构建 App，App 吸引用户，用户吸引更多开发者。区别在于 Skill 市场的"消费者"不是人，是 AI——给人装能力的是 App Store，给 AI 装能力的是 Skill 市场。

单层做不出这个效果。如果只有数字员工市场、没有 Skill 市场，每个数字员工都得自带所有操作逻辑，无法复用，无法积累。如果只有 Skill 市场、没有数字员工市场，Skill 只是散落的零件，非技术用户无法使用——门槛还是在那里。

这个框架下读后面的章节

后面的章节可以对照这两层来定位：

• 第五章讲 App Spec——"怎么定义一个数字员工"和"怎么定义一个 Skill"的产品契约
• 第六章讲调度引擎——数字员工什么时候醒来做判断
• 第八章讲浏览器工具——Skill 在什么环境里执行
• 第十二章讲 Store 系统——两层的东西怎么分发、搜索、安装

知道你读的技术处于哪一层、服务哪一层，就不会迷路。

---

1.4 系统全景：一个 AI 数字员工系统需要什么

问题：从原型到系统的距离

前三节讲了"AI 数字员工是什么"——AI 做判断，脚本做执行，两层市场互驱。如果你被说服了，想自己造一个，第一个问题是：需要建多少东西？

做一个"能对话的 AI 助手"原型很快。调一个 LLM API，把用户输入发过去，把回复显示出来。一个周末就能跑起来。

但"能对话"距离"能当员工"差了整整一个系统的距离。

员工要有工作时间——谁在什么时候叫醒他？需要一个调度引擎。员工要记得昨天做过什么——跨次运行的状态存在哪？需要一个记忆系统。员工要能操作企业系统——怎么登录、怎么点按钮？需要一个浏览器环境。员工做完事要汇报——通知谁、用什么通道？需要一个通信体系。员工可能同时服务多个用户、多个任务——资源怎么分配、冲突怎么处理？需要并发控制。

这些东西单独拿出来都不难理解，但它们加在一起构成了一个完整系统的骨架。理解这个骨架，是读后面每一章的前提——否则你知道每块砖长什么样，但不知道它砌在哪面墙上。

五层：从上到下

把这些需求按职责分层，大致会落成五个层次：

用户交互层。 用户看到什么、怎么操作。对话界面、文件管理、数字员工的状态面板。这一层不关心 AI 怎么跑，只关心怎么展示结果和接收指令。

数字员工编排层。 一个数字员工"长什么样"（定义）、"什么时候醒"（调度）、"这次做了什么"（运行记录）。这一层回答的是"谁在什么时候做什么事"。

服务层。 具体能力的实现。Agent 对话、AI 浏览器操作、多供应商模型接入、远程访问、健康监控、通知推送。编排层说"现在该用浏览器查一下 OA"，服务层负责"怎么打开浏览器、怎么点那个按钮"。

平台基础设施层。 不含业务语义的通用原语——存储、调度、事件总线、记忆、后台保活。这一层不知道"数字员工"是什么，就像操作系统不知道你装了什么应用。任何上层模块都可以用它，它不依赖任何上层。

AI 引擎层。 Agent Loop 的核心循环——调用 LLM、解析工具调用、执行工具、把结果塞回上下文、再调 LLM。这是整个系统的推理心脏。

依赖方向只能向下。UI 可以调编排层，编排层可以调服务层，服务层可以调平台层和引擎层。反过来不行——平台层不知道服务层的存在，服务层不知道编排层的存在。

但数据流不是单向的——调用向下，事件向上。调度器（平台层）到了 cron 时间，通过运行时（编排层）启动一次执行；执行过程中 Agent Loop（引擎层）调用浏览器工具（服务层），拿到结果后写入运行记录（编排层），前端（UI 层）通过事件订阅实时渲染。向下是请求，向上是推送。这条双向管道贯穿全书。

为什么是这五层而不是别的

分层不是为了画图好看。每一层的存在都对应一个具体的隔离需求：

UI 和后端分离是因为 AI 数字员工可能在后台无人值守地运行——根本没有 UI。如果业务逻辑和 UI 耦合在一起，无界面运行就做不了。

编排层和服务层分离是因为"什么时候做"和"怎么做"的变化节奏不同。用户改了数字员工的工作规则（编排层），不应该影响浏览器怎么打开网页（服务层）。反过来，浏览器工具升级了，不应该影响数字员工的调度逻辑。

平台层独立是因为存储、调度、事件这些原语是所有业务的共同需求。如果调度器代码里写死了"数字员工"的概念，以后想给对话系统也加定时功能，就得复制一份调度代码。平台层不含业务语义，所以它可以被任何业务复用。

AI 引擎独立是因为模型和协议在快速迭代。今天用 Claude，明天可能加 GPT，后天可能换一个开源模型。引擎层封装了协议差异，上层不需要知道底下跑的是哪个模型。

这套分层逻辑不是 Halo 独有的。VS Code 的源码也是类似结构——workbench→platform→base，单向依赖，几百个 contributor 靠这个纪律共存。任何超过一定规模的系统，最终都会走向这种分层——因为不分层的代价（改一处崩十处）会随着代码量指数增长。

对话和自动化共享同一条管道

这五层架构有一个设计后果值得提前说明：对话和数字员工走的是同一条管道。

用户在界面输入"帮我查一下今天的待办"，消息从 UI 层进入服务层的 Agent 模块，Agent 模块启动 Agent Loop，Loop 调用工具、拿到结果、返回给用户。

数字员工的路径完全一样——只是入口不是用户手动发送，而是调度器到了 cron 时间自动触发。从 Agent Loop 往下，对话和自动化共享同一个引擎、同一套工具、同一个执行环境。

这意味着数字员工的能力上限不局限于审批、监控这类简单任务——写代码、生成报告、操作浏览器完成复杂调研，任何 AI Agent 能在对话中完成的事，数字员工都可以自主完成。第三章会展开这个引擎的完整架构。

本地优先：数据在你的机器上

这套系统的数据架构做了一个有意识的选择：所有数据都在本地。

没有云数据库，没有账号系统，断网照常运行。API Key 存在本地配置文件里，对话记录存在本地工作空间目录里，数字员工的运行日志存在本地 SQLite 里。

这个选择有明确的产品理由：如果你的数据存在别人的服务器上，你的 AI 就受制于别人的定价和规则。本地优先意味着用户完全控制自己的数据和运行环境。

代价同样明确：多设备同步需要额外机制。Halo 的解法是远程访问——通过隧道把桌面端暴露到网络，从手机或浏览器连进来。数据始终在一台机器上，访问可以在任何地方。第十一章展开。

这张地图和后面的章节

后面每一章对应这张地图的一个或多个区域：

章	对应层次	核心设计问题
第二章	全局	三端统一的应用骨架怎么搭
第三章	AI 引擎	Agent Loop 怎么让 AI 可靠地完成工作
第四章	AI 引擎	多家模型的协议差异怎么消化
第五章	编排层	一个数字员工的完整定义是什么
第六章	平台+编排	调度引擎怎么可靠地按时唤醒
第七章	平台	跨次运行的记忆怎么设计
第八章	服务层	AI 浏览器怎么构建
第九章	服务层	数字员工怎么主动联系人
第十章	UI 层	流式渲染和交互工程
第十一章	服务层	远程访问和稳定性保障
第十二章	平台	Skill 和数字员工怎么分发

知道你读的技术处于哪一层、解决的是什么设计问题，就不会迷路。

---

1.5 零适配接入企业内网：复用浏览器登录态

问题：对接一个内网系统要多久

任何成规模的企业里都有几十套系统——OA、工单、知识库、发布平台、监控面板。每套系统都是 Web 页面，每套都有自己的接口格式。

想让 AI 自动化操作其中一个系统，传统做法是什么？找那个系统的后端团队，要 API 文档，排期联调。一套系统对接下来，几周算快的。企业里有几十套系统，要做几十次。MCP 协议火了之后换个说法——"给每套系统写个 MCP Server"——本质没变，还是一个一个对接。

这条路的成本之所以高，是因为它要求目标系统配合——开接口、给文档、联调。而内网系统的后端团队通常有自己的排期，你的自动化需求在他们那里排不上优先级。

但退一步想：你的员工每天是怎么用这些系统的？打开浏览器，登录，点按钮。浏览器里存着 cookie，系统认的是 cookie，不是人。

设计思想：不对接系统，复用浏览器

如果 AI 也在同一个浏览器里操作呢？

cookie 在那里，网络请求从用户自己的电脑发出去，内网系统看到的和员工自己操作完全一样。不需要开 API，不需要写适配器，不需要 IT 部门配合。

这个思路的核心是把浏览器的登录态当作 AI 进入企业系统的通道。用户在浏览器里手动登录一次，cookie 存下来，之后 AI 的所有操作都复用这个身份。内网系统不知道请求来自 AI——它看到的是一个正常的、有权限的、从员工电脑发出的 HTTP 请求。

权限边界天然清晰：AI 用的是你的账号，做的是你有权限做的事。不可能越权，因为 cookie 代表的就是你自己。

这和 RPA 有什么不同

RPA 也是在 UI 层操作，但它依赖固定的元素定位——CSS 选择器、XPath、屏幕坐标。界面改版，脚本就崩。

浏览器登录态复用走的是另一条路：不操作 UI 元素，而是直接调用前端页面背后的 HTTP 接口。任何 Web 系统的前端页面都在调接口——打开 F12 就能看到。Skill 做的事就是复用这些接口，带着浏览器里已有的 cookie 发请求。

接口比 UI 元素稳定得多。按钮位置挪了、页面样式改了，接口通常不变。接口变更的频率远低于 UI 变更——这就是为什么这种方式比 RPA 脚本更健壮。

当然，接口也可能变。内网系统升级改了接口路径或参数格式，Skill 跟着要改。但这个维护成本和"从零对接 API"不在一个量级——你改的是一个 fetch 调用的 URL，不是重新走一遍联调流程。

两个需要解决的工程问题

思路很简单，但落地有两个工程问题。

第一：Electron 不是真正的 Chrome。 带反爬虫机制的站点会检测浏览器指纹——navigator.webdriver 被设成 true、window.chrome 对象缺字段、WebGL 渲染器字符串不对。这些细节暴露了自动化工具的身份。解决方案是注入一组反检测脚本，在页面 JavaScript 执行之前修正这些指纹，让 Electron 在目标系统面前等同真实 Chrome。思路来自 puppeteer 社区的 stealth 插件，不是原创，但集成进 Electron 桌面应用并对用户透明，这个工程整合是必须做的。第八章展开实现。

第二：AI 怎么理解页面内容。 截图是最直觉的方案——但一张截图几千 Token，十几步操作下来成本积累很快，而且视觉定位存在坐标偏差。更高效的方案是利用浏览器的无障碍树（Accessibility Tree）——本来是给屏幕阅读器用的，描述页面上每个可交互元素的角色、名称、状态。AI 看到的是结构化文本（"button '审批'"、"textbox '备注'"），不是像素。Token 消耗小一个数量级，定位精度也更高。第八章展开完整实现。

但需要强调：无障碍树和截图都是探索和兜底手段。日常跑业务的主路径是 Skill——一段写好的脚本直接调接口，AI 不需要"看"页面，也不需要"点"按钮。只有在目标系统还没人写过 Skill、需要 AI 从零摸索流程时，才用无障碍树引导操作。

边界

"零适配"有明确的适用条件，不是万能的。

要先手动登录一次。 用户在内置浏览器里手动登录目标系统，cookie 才会存下来。session 过期了，需要重新登。这和用真浏览器一样——没有什么系统能永远保持登录态。

只能做你有权限做的事。 AI 用的是你的账号。你看不到的页面、你点不了的按钮，AI 也做不到。这既是限制，也是安全保障——不存在越权的可能。

依赖前端接口的稳定性。 Skill 调的是前端页面使用的接口，没有版本保证。但如前所述，接口变更频率远低于 UI 变更，维护成本可控。

需要 Electron 才能实现。 这个方案依赖内置 Chromium 提供的完整浏览器环境——cookie 隔离、CDP 协议、脚本注入。纯 Web 应用做不到本地浏览器的 session 管理，原生 GUI 框架做不到内嵌 Chromium。这也解释了为什么 Halo 选了 Electron——不是因为它轻量（它很臃肿），是因为它提供了打开企业内网的那扇门。

从三个月到三分钟

传统企业内网对接：拉后端同事开会→要 API 文档→排期→联调→上灰度。一套系统几周，几十套系统几个月。

浏览器登录态复用：登录一次，写一个 Skill 调前端接口。门槛从"需要 IT 部门配合"降到"会用浏览器开发者工具就行"。

核心就一句话：你的浏览器能登录什么，AI 就能操作什么。

---

本章回顾

本章五节画了一张地图。

三代方案的演进给出了第一个结论：AI 擅长判断，不擅长可靠地重复执行。把"做不做"和"怎么做"拆成两个独立决策，整个系统的可靠性、成本、可复用性同时解锁。Skill 做执行，数字员工做判断，两层通过文件系统解耦。

Skill 市场给 AI 装能力，数字员工市场把这些能力组织成可调度的工作单元。两层互相驱动，缺一不可：只有 Skill 而没有数字员工，非技术用户用不起来；只有数字员工而没有 Skill，能力无法跨场景积累。

一个完整的 AI 数字员工系统需要五层——UI、编排、服务、平台、引擎——依赖只能向下。这种分层不是 Halo 的发明，是任何超过一定规模的系统最终都会走向的结构，因为不分层的代价会随代码量指数增长。对话和数字员工共享同一条管道，意味着数字员工的能力上限等于 Agent 本身的能力上限。

零适配接入是这套系统最直接的落地方式。不对接系统的后端 API，复用用户浏览器的登录态，让 AI 通过 cookie 进入企业内网。你能登录的系统，AI 就能操作。代价是需要 Electron 提供完整的 Chromium 环境，以及 session 过期时需要重新登录。

这五件事构成后面所有技术章节的坐标系。读每一章时，可以对照定位：这个模块属于哪一层，处理的是判断还是执行，解决的是什么设计问题。

下一章拆开工程地基——运行时 Adapter、声明式能力边界、分层与依赖方向、性能预算、命名空间迁移。这些不是 AI 相关的技术，但没有它们，后面所有 AI 能力都无处安放。