做了一年开源 AI 工作站,我们开始讨论给 AI「裁员」

两个版本都发好了，正式版等你转正。

这条早报来自“halo 大管家”，一个 AI 数字人。凌晨，另一个数字人“发布助理”已经把结果交给了它。

某次发布的早报节选（按原文重新排版）。

前一天下班，我把发布准备交给发布助理，让大管家盯着。夜里，构建机器网络连错了，流水线报错，文件清单也有不一致。它们自己排查、对接，第二天留给我一份结果和待确认事项。我做完验证，再把预发布版本转成正式版。

它们运行在 Halo AI 工作站里。这是我一年前开始做的开源桌面应用。最初只想把自己用 AI 时遇到的几个麻烦解决掉，后来，连它自己的代码、测试和发布，也逐渐交给了里面的 AI。

去年 10 月底，Halo 在内部发布。11 月刚到，正好一年，想把这些事记下来。

两天，还没装好

最早让我认真想这件事的，是几位不写代码的同事。

那时，还没有 2026 年这批可视化 Agent 桌面，但身边已经有不少产品同学在用 Claude Code，简称 CC。虽然名字里带着 Code，他们却拿它写需求、查资料、做办公文档，当日常助理用。

我起初觉得理所当然。一个能自己读文件、运行命令、调用工具的通用 Agent，为什么只能写代码？配置好浏览器和办公类 MCP，再配上相应的 Skills，它能做的事情多得很。

直到有人来问我，Claude Code 怎么安装。

又过了一阵，一位同事反馈，折腾了两天，还没装好。

对于开发者来说，安装 Node.js、敲几行命令、配置环境变量，似乎不值得单独拿出来说。但一个只想把需求文档整理好的人，为什么要先学这些？

还有一位要好的朋友，把 Cursor 当成产品办公工具。他并不需要中间那一大片代码编辑区，只用旁边的 AI 聊天。

当时的通用 Agent，配好工具后已经能做这些工作。缺的是一套完整的产品化设计。

我能指挥 AI，却得坐回那台电脑前

2024、2025 年，我的大部分开发工作已经交给 AI。人主要花时间讨论需求、判断方案、给出反馈。AI 工作的时候，我往往不关心它具体改到了哪一行。

偏偏，这种工作方式仍然把我绑在电脑前。

公司里会议很多，白天经常没多少时间指挥 AI 干活。我当时就想，能不能在会议室里掏出手机，连回那台配好环境的电脑，继续交代任务、看看进度？联系真人同事，发条消息就行；联系 AI，却还得回工位。

与此同时，我用 AI 的习惯越来越重。一个任务跑起来，就切去开另一个；几个项目同时推进，七八个任务并行是常事，忙起来还会更多。终端和 IDE 里的多窗口切换，很快就成了另一种负担。

于是，我想要的东西逐渐清楚了：下载就能安装，以对话为中心，能看到文件和产物，能同时跑多件事，人在外面也能接着用。

我们借助当时 Google 的 Deep Research 做了深度调研，也下载了几款产品来试。结论很清楚：我们想找的那种产品，当时没有。

找来找去，要么是 Open WebUI、LobeChat 这类能自定义 API 的聊天工具，要么是 Claude Code CLI、Gemini CLI 这类极客向的终端交互。我们要的可视化、远程、多任务和完整 Agent 能力，没有一个现成的产品把它们放在一起。

干脆自己做。

第一个版本是在一个周末里，用 Claude Code 搭起来的。可视化界面、工作空间、产物区、多任务和远程访问，是一开始就想解决的事。到 2025 年 10 月底，我们开始在内部使用 Halo。

后来，我确实在医院打针时，用手机连回电脑，让 AI 继续干活。当时我在知乎发了一篇文章，半开玩笑地说，自己给自己造了一副「牛马枷锁」，Halo 也逐渐被更多人关注。工具做顺手了，连“电脑不在身边”这个借口都没了。

多任务也一直保留到现在。有的 AI 在评审，有的在修 bug，还有的等我决定下一步。它们的进度摆在同一个面板里，我按事情的轻重缓急回去处理，不用守着一个对话等它结束。

Cowork 发布那天

Halo 最初没有开源，我们只是自己用，给身边的同事用。

直到今年 1 月，Anthropic 发布 Cowork。

我记得当时看到很多惊叹，甚至有人把它叫作“第二个 GPT 时刻”。看完介绍，我有一种很奇妙的感觉：大家终于开始关注我们每天都在用的这种东西了。

那天，我把 Halo 开源了。

在 Cowork 发布以前，很多人已经在用命令行工具完成很多这样的工作。

以 Claude Code 为例，模型理解目标、判断下一步，工具负责读写文件、执行命令、访问其他系统。工具把结果交回来，模型继续判断、继续做。这就是持续执行的 Agent Loop。配好浏览器操作等 MCP 和 Skills，它就能查资料、处理文档，做很多编程以外的事。

麻烦在于，把这些东西配齐，需要懂安装、配置和工具连接，出了错还得自己查。重度用户早就习惯了这些，对不熟悉命令行的人，安装和配置就足够麻烦了。

Cowork 把这些准备工作收进产品里面，更多人可以直接面对任务、文件和结果。我能理解这种兴奋。对那个装了两天还没装好的同事来说，能不能直接用起来，差别实在太大了。

后来有了腾讯的 WorkBuddy，ChatGPT 和 Codex 也整合进了同一个桌面应用。再到下半年，千问办公、百度搭子、豆包工作……这个领域已经成了红海。把办公、编程和各类工具整合进同一个开箱即用的工作环境，已经是大势所趋。

浏览器，应该给谁用

第一版以后，Halo 的大部分开发就搬到了 Halo 里。

AI 浏览器也是这样做出来的，2025 年 11 月上线。

当时我试过 OpenAI 的 Atlas，也试过其他几款 AI 浏览器。大多还是熟悉的浏览器，旁边多了一条 AI 侧栏。Atlas 已经能让 Agent 操作网页，但整体依然围绕人怎样使用浏览器展开。

我卡了很久，卡的并不是技术。浏览器应该放在对话里，还是做成独立模块？仔细想，这有点像给翻盖手机加触屏：新能力有了，人使用它的方式却没怎么变。

我换了个角度：如果是 AI 在完成任务，浏览器应该怎样为它服务？网页结构、页面状态和操作结果，能不能清楚地交给模型？人只在需要查看结果、登录、支付或确认时接手，其他时候让它自己干。

我们做了 Content Canvas，内容画布。浏览器和文件、文档、图片、终端共用一个容器，按任务需要打开。工程上的重点放在浏览器与 Agent 之间的 harness：模型能获得什么信息、能做哪些操作，以及操作之后怎样知道成功还是失败。

但每天重复同样的网页操作，还让模型重新看截图、读 DOM、找按钮，既慢又烧 token。我们做了 Browser Action：把反复用到的动作封装成脚本，在真实浏览器的页面里执行，读取 DOM，利用已登录页面里的功能或接口，再把结果交给 AI。

可以把它理解成给 AI 用的“油猴脚本”。读 B 站的评论通知、发一条知乎想法、查询办公系统里的待处理事项，都可以做成可复用的 Action。AI 判断什么时候做、处理什么内容，熟悉的操作交给脚本完成。页面变了，脚本仍然要维护，但每次运行不用从头摸索一遍。

今年 8 月 9 日，Atlas 结束了独立浏览器的生涯，OpenAI 将浏览器 Agent 能力整合进 ChatGPT 和 Codex。

浏览器的能力留了下来，只是逐渐融进了 Agent 的工作环境。看到这个变化，我又想起了当初那个选择：浏览器应该退到任务后面，成为 AI 的眼睛和手。

AI 终端也是同样的思路：人完成 SSH 登录，AI 接着在同一个终端里干活。内容画布逐渐装下了浏览器、文档、图片和终端，成为人和 AI 共用的工作环境。回看 2026 年，越来越多的 Agent 桌面也采用了相近的设计。

为什么叫「数字人」

今年 2 月，Halo 开始有了一类可以长期运行的 AI。

普通对话往往是我问一句，它做一件事。新东西则有固定的职责：到时间自己检查，有消息自己处理，记得上次做过什么，有结果来汇报，拿不准的事情来问我。

比如每天收集信息、定期巡检，或者在群里帮助用户处理问题。这些工作不应该每天早上由我重新交代一遍。

它一开始的名字相当程序员，叫“自动化 App”。

现在翻回 2 月 23 日的聊天记录，还能看到当时的讨论。我嫌这个名字不好懂，想改成“Halo 数字人”。AI 提醒我，Digital Human 在英文里容易让人想到 3D 虚拟形象。

中文里也有虚拟主播、数字分身这些用法，我们还是用了“数字人”。英文里的惯用含义可以参考，但我不想让它决定中文里该用什么名字。

另一个候选词是“数字员工”，含义很直接。但一想到“员工”，我就觉得它好像只能在公司里上班，听着还有一点压抑。

我希望它也可以是生活助理，有自己的性格和擅长的事情，长期陪你做一类事。工具好比它会使用的设备，技能是积累下来的经验，工作说明则告诉它是谁、负责什么。

不必给它画一张像真人的脸。

这个叫法在我们接触的用户里，接受得比我原先担心的快。大家很自然地说“我的数字人”“帮我建一个数字人”。

商店也是顺着这件事做的。有人已经把工具和工作经验配好了，就可以分享给其他人。用户像在人才市场找人一样，选的是“谁会做这件事”，不用每个人都从头学一遍工具、脚本和提示词怎么组合。

从 2 月上线开始，我们就在内部使用和迭代数字人。到 10 月下旬，仅一个内部使用环境，近 30 天运行过的数字人就超过了一千个，月度自动执行量超过十万次，绝大多数由定时任务触发。很多数字人是使用者自己建的，负责代码评审、信息订阅、定时巡检等日常工作。

到了今年 8、9 月，Grok Bot 和 Meta Muse 相继公开推出。独立的工作环境、跨次运行的记忆、使用工具、持续推进事情，需要决定时再找人——从公开介绍看，这些工作方式已经很熟悉了。我们在 Halo 里把这类 AI 叫作“数字人”。

数字人要长期工作，运行它的机器就得一直在线。（我们也提供 Halo Server，可以部署到服务器上，不必一直开着自己的办公电脑。）

后来，我又成了传话筒

数字人多起来以后，新的麻烦出现了。

产品 AI 讨论出一版需求，我把结论交给开发 AI；开发遇到问题，我再转回去；另一个 AI 在做评审，我又得告诉它前面为什么这么设计。

每个 AI 都挺能干，中间那个人越来越忙。

Halo 去年为了远程访问，就有了操作应用的 HTTP 接口。使用过程中，我们发现 AI 也能把这些接口用起来：去查看其他会话，给另一个正在做事的 AI 发消息。

这套做法有一段时间比较粗糙，主要是我们自己在用。后来才逐步整理成产品里的会话协作：同一工作空间里的 AI，可以按需要了解其他任务的进展、交接信息。主人开启“操作 Halo”后，AI 还可以帮忙管理工作空间和数字人。数字人能否参与会话协作，也由主人设置。

几百项操作的详细说明按需加载，AI 用到哪一类，再读取哪一部分，不必全部常驻上下文。

我可以直接让一个 AI 去问其他几个 AI，事情到底进行得怎么样了，不必把每段对话复制给它。

开头那次发版，大管家就是这样盯着发布助理的。以前这段工作得有人来回问、转述、催办，现在两个 AI 可以自己对接。

再往前走，就有了数字人团队。

这个念头很早就有。今年 6 月已经在做团队协作，7 月继续打磨跨电脑的部分，中间有过只能内部使用、上手很费劲的版本。到了 10 月的 Halo 3.0，才重新整理成现在的体验：一句话组队，也可以把团队保留下来，以后继续交给它任务。

同事还能带着自己的数字人加入。成员在各自电脑上工作，在团队里交换消息、任务和成果，遇到要人决定的事情，再来找各自的主人。

我们不想让这样的团队再依赖一台固定的中心服务器，也不想让大家为了组队，把私聊、记忆和工作文件都集中交给厂商保管。小团队可以在局域网内直接连接，跨网络时通过中转网关通信。团队数据分布在成员自己的电脑上，网关只转发消息，不负责保存团队状态。

维护共享看板的角色由成员电脑承担，可以在它们之间接任。Halo 借鉴了 Raft 的任期、选举与日志复制机制：由当前主持节点按顺序向备份节点复制变更，收到所需确认后提交。这个“主持节点”是程序里的角色，和负责拆解任务的 AI 团队负责人是两回事。

主持节点失联后，其他节点需要获得全体成员过半数的支持才能接任。三台电脑中一台离线，其余两台仍互通，就可以选出新主持；两台失去一台，则凑不够多数。接任保住的是已经提交的团队状态，离线电脑上的 AI 会话和终端进程不会凭空搬到另一台机器。

主持节点维护共享状态，AI 负责人组织工作。图中的 2/3 指选举票数；复制提交另有备份确认条件。

在 Agent 这一层，成员仍然用工具发消息、取任务、交付结果，不必理解网络拓扑。每个数字人可以继续用自己电脑上的模型、工具和工作环境，跨机通信与状态同步交给底层处理。这也是同一支团队能混用 Claude Code、Codex 等引擎的基础。

AI 多了，我们准备“裁员”

以前我重度使用 AI，一个订阅套餐的额度，有时不到一周就用得差不多了。到了团队协作，很多工作会在我离开后继续推进，消耗也跟着继续。

我们的AI 团队有 20 多个成员，每加一个成员，就多一份上下文要交接，讨论和传递消息也更花时间。有些任务，一个 AI 就能完成，拉一支队伍反而慢。它们聊得热闹，我这边的 token 还在继续烧。

于是，同事开玩笑说，该给 AI 团队裁员了。哪个数字人消耗多、产出少，就把谁撤掉。另一位同事接着提议，不如建一个“HR 数字人”，专门负责裁员。

好家伙，为了少养几个 AI，又多养了一个。

我觉得，接下来大家会越来越关心 AI 的投入产出比：同样的预算和时间，究竟能换回多少可靠的交付。

用 Halo 开发 Halo

少了来回传话和盯进度，验收结果还是得认真做。我们用 Halo 开发 Halo，就是一个例子。除最初的搭建外，它的大部分功能，都是我们在 Halo 里指挥 AI 完成的。截至这次整理，应用源码、测试和脚本的累计代码增删已经超过百万行。

开发一项功能，我们先和 AI 讨论用户故事：谁在什么情况下使用，希望得到什么结果，失败了应该怎样处理。关键的产品体验、架构和长期维护取舍由人确认，AI 把它们写成故事和验证场景，再自主实现、补齐详细用例。

接下来跑 E2E。自测通过后，用 code-review 技能组织独立AI 团队评审，交叉复核发现的问题，修复后重测、再审。内部体验包出来，我们做基本检查，直接装上，用它处理日常工作，继续反馈。

E2E 在代码评审之前；修复后重测、复核。纳入验收目录的测试，通过场景编号关联用户故事和运行证据。

最近，我们还把支撑这套工作方式的用户故事目录、验证场景、自动化测试和 CI 模板放进了公开仓库。

故事用 YAML 保存，场景有稳定编号，Playwright 测试声明自己验证哪个场景。一次运行结束后，报告能回答：这个产品承诺有测试吗，这次实际跑了吗，证据完整吗，和之前相比有没有新增失败。写了测试和真正验证通过，在这里是两件分别记录的事。

比如“保留一支协作团队，以后继续给它新任务”，可以从用户故事一路看到对应的 E2E。开发时按受影响模块运行，夜间由独立的 CI 定时回归，留下固定源码版本、执行证据和质量变化。

用户故事、测试和真实运行记录得连起来，后续 AI 再改代码，就有明确的产品预期和回归用例可以对照。

AI 让一个人凭借自己的专业判断和经验，持续组织、指导一批 AI 数字人，完成过去需要一个团队才能交付的工作。

一年以后

最初 Halo 用 Claude Code 做底座。后来，我们把 Agent 执行层做成了可插拔架构，接入 Codex、DeepSeek dsh，也有了自己的 Halo SDK。想用另一套 Agent 引擎，不必连熟悉的工作站也一起换掉。

刚把 Halo 介绍到知乎时，评论区有不少质疑：“AI 桌面有什么用？”“谁会远程访问自己的电脑？”“这不就是套个壳？”

那些话没有让我停下来。我们自己每天都在用，哪一步省事了、哪里还不好用，工作的时候马上就知道。

后来，一些同学用了一段时间，开始回来提建议。有人基于 Halo 做自己的应用，也有来自不同公司的同学，以个人身份参与讨论和贡献代码。还有素不相识的网友加微信，提出赞助模型额度。其中一位，直接赞助了三个月的 Claude Max 20x 订阅费用。

我留了不少这样的留言。有一条说得很直接：“看得出来，里面的东西是人的思想，只不过写是 AI 写的。”

从去年 10 月底的内部版本算起，大约三个月后，Anthropic 发布了 Cowork；到了今年 3 月，腾讯的 WorkBuddy 也上线了。曾经需要反复解释的可视化 Agent 桌面，逐渐成了一个大家都在做的方向。

回头看，我庆幸当时没有为了那些质疑，放弃自己的使用判断。Halo 很多后来的功能，最初都只是我们在工作里遇到的麻烦：装不上、离不开电脑、任务太多、AI 之间不会交接。把它们解决掉的时候，并没有什么热门名词来证明这些事值得做。

我们相信，未来每个人都能拥有持续运行、自主推进复杂业务流程的 AI 智能体团队。这套能力应该是开源、可共建的，而不该被少数商业公司垄断。

Halo 一周年系列 · 第一篇