No. 27: 我把 AI Employee OS 第一版砍到只剩一条主线

做 AI Employee OS 的时候，我最早面对的不是技术选型，而是一个更容易失控的问题：第一版到底要证明什么？

AI 员工这个词太大了。记忆、知识库、Skill、Tool、Computer Use、Multi-Agent、自动评估，每一项都可以继续往下拆。如果把它们同时塞进 Demo，最后很可能得到一套看起来完整，却没有一条真实路径能稳定走完的系统。

所以我把第一版砍到只剩一条主线：先创建一个 AI 员工，让它能在 macOS 上持续聊天；需要做事时，再进入一条有权限、有状态、有证据的执行路径。

已经有了 Wukong，为什么还要做 AI Employee OS

这个问题我也反复问过自己。

Wukong 已经是一个可以长期运行的本机个人 Agent。它通过 Telegram 接收我的消息，记住我的偏好和上下文，也能调用受控工具完成事情。对“给自己做一个随时可以找到的 AI 助手”这个目标来说，Wukong 已经走得很远。

但我继续使用之后，发现个人 Agent 和 AI 员工解决的并不是同一个问题。

Wukong 围绕“我”来组织。它只有一个持续成长的身份，记忆来自我与它的长期相处，入口追求随时触达，能力也会跟着我的个人工作流不断扩展。它更像一个长在我身边的助手，知道我在做什么，也知道我习惯怎样做事。

AI Employee OS 围绕“工作角色”来组织。我需要的不只是一个什么都能聊的 Agent，而是能够创建不同员工，给每个人配置清楚的岗位、Identity、Soul、Persona、Skill 和 Tool。AI 产品经理与内容运营不应该共享同一套身份和权限；同一个任务交给不同员工，也应该得到符合岗位边界的处理过程。

两者关心的重点也不同。Wukong 优先解决个人陪伴、长期记忆、主动触达和本机服务；AI Employee OS 更关心员工怎么入职、工作如何发起、权限由谁批准、Tool 是否越界、过程能否审计、失败后怎样恢复、最终交付物放在哪里。

我真正想验证的是：当 Agent 从“我的助手”变成“承担某个岗位的员工”，系统需要增加什么？

答案显然不只是换一段 Prompt。岗位需要独立身份，工作需要生命周期，工具需要权限，副作用需要审批，结果需要验收。多个员工还必须遵守同一套运行规则，否则每增加一个角色，就要重新拼一套 Agent。

这也是我没有直接在 Wukong 里继续加模块的原因。Wukong 应该继续服务我的个人工作流；AI Employee OS 则把我在 Wukong 里验证过的记忆、工具、安全和可观察经验拆开，重新放进一套面向多员工的通用契约中。它们可以共享经验，但不应该被硬塞成同一个产品。

Demo 先回答“它是不是一个员工”

聊天窗口很容易做，但一个能发消息的输入框还不是 AI 员工。

我先给员工建立独立 Profile。Identity 说明它是谁，Soul 约束它如何判断，Persona 决定它怎样表达。这些内容不会只留在界面表单里，而是交给 Rust Runtime 编译成 Effective Prompt。用户可以创建和编辑多个员工，也可以彻底删除默认的 Alex，系统不会在下次启动时悄悄把它种回来。

对话也必须能跨重启恢复。DeepSeek 的 Chat Completions 本身没有会话记忆，每次请求前，Runtime 都要从 SQLite 取回当前 Conversation 的有序消息，再重建上下文。这里没有神秘的“长期记住”，只有明确的数据、顺序和恢复路径。

这些能力看起来没有 Skill 炫，但它们决定了员工是不是一个持续存在的对象。身份会不会漂移，会话能不能回来，用户能不能真正控制它，都比 Demo 里多一个按钮更重要。

同一句话，可能是聊天，也可能是工作

用户说“帮我整理一下这个文件”，系统不能一看到动词就直接调用 Tool。它要先判断这是一句普通对话，还是一个会产生副作用的工作请求。

第一版把这条路径拆成两层。普通聊天留在 Conversation；需要执行的请求进入 Resolver 和 Generic Run Kernel，再形成 Task 与 Action。每一步都有状态，可能等待审批，也可能被取消或失败，最终结果要能回到任务记录里。

这也是我刻意移除 Golden Path 的原因。针对某个固定员工写一条特制流程，确实能更快做出顺滑演示，但它证明不了系统可以承载其他员工。Demo 要验证的是一份通用契约：Agent 接收 Task，Run 调用 Skill 和 Tool，最后交付可以检查的 Deliverable。

模型不应该直接拿到系统权限

AI 员工一旦可以读文件、写文件或搜索网络，产品问题就从“回答好不好”变成了“它能做什么，谁允许的，失败后留下了什么”。

我把权限边界放进 Rust Runtime。SwiftUI 客户端负责界面、本地 Store 和 Keychain；Python Worker 负责意图、上下文、规划和模型调用；所有 Tool 调用必须经过 Rust ToolExecutor。Task、Action、审批、事件、幂等和审计都在这条边界内处理。

API Key 只保存在 macOS Keychain，并通过受控进程环境提供给模型调用。它不会写进 SQLite、日志、Trace、Memory 或 Agent Context。这个设计增加了不少工程工作，却换来了一个很清楚的答案：即使模型判断错了，它也不能绕过系统边界直接动手。

原生客户端不是 Dashboard 换皮

第一版客户端包含办公室、通讯录、工作库、技能库、工具库和设置。做 UI 时我也走过弯路，一度把“有数据的首页”理解成“多放几张卡片”。实际跑起来以后，信息虽然多了，产品职责反而更模糊。

后来我重新划分页面：办公室只看状态、团队、用量和结果；员工身份与创建放在通讯录；对话和工作回到员工与任务的具体语境里。用量数据没有接入时就明确显示未接入，演示 Token 和成本只属于 Demo，不能伪装成真实账单。

界面使用 Claude Cream 的暖色画布、琥珀强调色和少量青色状态点，同时保留 macOS 原生的 Sidebar、Toolbar、列表和窗口行为。视觉统一不等于给所有东西套一层自定义卡片，桌面软件首先要像桌面软件。

第一版完成了什么

现在这套 Demo 已经能够在本机跑通：创建员工、编辑 Profile、多轮对话、识别工作意图、安装受支持的 Package、执行本地文件操作、进入审批与审计流程，并把 Swift 客户端、Rust Runtime、Python Worker 和内置资源打包进一个 macOS App Bundle。

它也有明确的缺口。真实网络搜索依赖本机 mcporter 和 Exa，还不是默认 CI 的完整端到端门禁；Computer Use、Multi-Agent、Cloud Sync、Marketplace、公证发行和自动更新都不在当前 MVP 里。仓库也还没有 License，所以“公开可见”不等于“已经开源授权”。

这些边界不是发布说明里的客套话。它们决定了接下来该验证什么，也防止我把未来计划写成今天已经拥有的能力。

下一步是做对照，不是继续堆功能

下一阶段，我想用同一组任务建立两条基线：一条只有员工身份和对话，另一条接入明确的 Skill 与 Tool。比较它们在完成率、可控性、成本和结果质量上的差异。

如果 Skill 和 Tool 没有让结果变得更稳定、更可验证，它们就只是复杂度。如果它们确实带来提升，我也能知道提升来自哪里，而不是用一次漂亮演示替代判断。

第一版 Demo 的价值，不是证明我已经造出了完整的 AI 员工，而是终于有了一条可以重复运行、逐项比较、不会靠想象补齐的主线。

项目：AI Employee OS

Vibe Coding 项目页：AI Employee OS

← Writing