OpenWorker：当 AI 不再只是回答问题，而是交付成品

引子：从”回答问题”到”完成工作”

过去几年，几乎所有生成式 AI 产品的默认交互形态都是一问一答：你打字，模型回字，剩下的事——把这段话变成一封邮件、一份报表、一次真正的操作——还是要靠你自己动手。这个形态解决的是”信息获取”问题，而不是”工作完成”问题。

但 2026 年之后，这条产品线正在往前走一步。

从 Chat 到 Copilot，再到 Agent、Worker，每一次跃迁背后，AI 交付物的形态都在变化：从一段文字，变成一次操作建议，变成一个可以自主执行的任务，最终变成一份可以直接拿走用的成品。

这条演进路线里，”Worker”是一个值得单独拎出来说的阶段——它不再满足于给你建议，而是直接把活干完，交回来一个你可以打开、可以转发、可以直接用的文件或消息。这正是 OpenWorker 这个开源项目想要做的事情。

一句话说清楚：OpenWorker 是什么

OpenWorker 是吴恩达（Andrew Ng）团队开源的一款桌面端 AI Coworker，2026 年 7 月发布，MIT 协议，代码全部公开（Python 后端 + React/TS 前端 + Tauri 桌面壳）。它的产品口号很直白：

Ask for an outcome, not just an answer.
——提出你想要的结果，而不是问它该怎么做。

也就是说，用户面对它的方式不是”帮我写一段介绍文字应该怎么开头”，而是”帮我准备好这周的客户续约会议材料”。中间要读哪些资料、调用哪些工具、生成什么格式的文件，都由它自己规划和执行，最后交付一个真正能用的东西——可能是一份 Markdown 报告、一个 PDF、一张图，也可能是一条发到 Slack 的回复。

这是官方对自己工作方式的说明：你提出一个诉求（比如”周一发布进展怎么样了”）→ OpenWorker 在你自己的电脑上运行，模型可以任选（云端、开源权重、或完全本地）→ 调用你已经连接好的工具（Slack、Outlook、日历、Notion、GitHub、HubSpot、Drive 等）→ 交付一个成品（聊天或 Slack 里的回复，或者一份 Markdown / PDF / 图片文件），再交回到你手上。整个链路里没有中间商，产物直接就是可以用的形式。

它有几个特点让这个项目在一众 Agent 产品里显得比较”实在”：

• 本地优先：整个 Agent Runtime 跑在用户自己的机器上，状态、密钥、历史记录都落在本机，不依赖云端托管服务。
• 模型中立：不绑定任何一家模型厂商，内置的策展模型矩阵覆盖了 OpenAI、Anthropic、Google 等一方模型，也支持 GLM、DeepSeek、Kimi、Qwen、MiniMax 等国产模型，还可以通过 Ollama 跑纯本地模型——想省钱换个便宜模型，或者出于合规要求完全离线跑，都不用改架构。
• 权限体系是一等公民：这是它和很多”Agent 套壳”项目最大的区别，后面会用整整一节来讲。

整体架构：四层，职责分明

抛开具体文件和代码行数，OpenWorker 的架构可以简化成一张四层图来理解：

桌面壳负责界面呈现，本地服务负责编排会话与状态，Agent 核心负责”想清楚该做什么、判断能不能做、然后去做”，模型路由层负责把请求发给你选定的那个模型——四层之间边界清晰，状态全部落在本机。

• 最上层是桌面壳：Tauri 2 + React 18，负责界面呈现、系统托盘、自动更新这些桌面应用该有的东西，它本身不参与任何决策逻辑。
• 本地服务层是一个跑在用户机器上的 FastAPI 服务，负责管理会话、任务、审批请求这些状态，前端所有操作最终都落到它暴露的一批 REST 接口上。
• Agent 核心是真正干活的地方，可以理解为三件套：一个负责”想”（规划、调用工具、迭代）的主循环，一个负责”能不能做”的权限判定模块，一个负责”存”的记忆模块。
• 模型路由层基于 aisuite（同样出自吴恩达团队的一个模型路由库）做统一调度，前面提到的三十多个模型选项都是通过这一层被无差别地接入进来的。

这四层组合起来，构成了一个相对完整的”目标 → 规划 → 执行 → 产物”闭环，而不是简单的”模型 + 几个工具函数”。

如果把镜头拉近一层，看一眼源码里这四层具体对应的模块，会更清楚每一层内部是怎么分工的：

桌面壳（surfaces/gui）用 Tauri 2 拉起并监督后端进程；本地 Agent Server（coworker/server）是一个只监听本机地址的 FastAPI 服务，暴露六十多个 REST 端点加 WebSocket；Agent 核心（coworker/）内部又分成三块——负责主循环、中断与恢复的 TurnEngine，负责风险分级与权限判定的 PermissionEngine，以及整合了文件、shell、搜索、MCP、连接器等各类工具的 ToolRegistry；最底下是基于 aisuite 的模型路由层，通过统一的 provider:model 前缀把请求分发给对应厂商，往下则是全部落在本机的状态存储——会话、审计日志、记忆库、密钥库都在这一层。

这张图也解释了为什么它能做到”本地优先”：从界面到状态存储，五层里没有一层必须依赖云端服务才能运行。

一轮任务里到底发生了什么

理解 OpenWorker 的执行方式，最好的角度不是看代码，而是想象你交给它一个任务之后，一轮迭代里发生的事情：

1. 模型以流式方式生成这一轮要做的动作（可能是读一份文件，也可能是同时想调用好几个工具）；
2. 如果这些动作里有需要审批的（比如要发一封邮件），系统会依次弹出审批请求——审批本身是人机交互动作，没法一次并发弹出好几个对话框；
3. 审批通过之后，进入执行阶段：只读、搜索这类没有副作用的操作会并发执行，加快速度；但涉及写文件、跑命令这类有副作用的操作，会严格按调用顺序串行执行，避免出现相互踩踏的情况；
4. 执行结果被喂回模型，进入下一轮迭代，直到任务完成或者达到迭代上限。

这套流程里有几个设计细节，虽然不起眼，但恰恰是”能不能在真实场景里稳定跑”的关键：

• 中断恢复不留”孤儿”：如果任务在执行到一半时被打断（用户手动停止，或者程序重启），所有已经发出去但还没执行完的工具调用都会被补写一条”执行失败”的结果，而不是被悬空扔在那里。这不是洁癖，而是因为很多模型厂商的对话模板会直接拒绝一段带着”没头没尾”工具调用记录的历史——留着孤儿调用，下一轮请求可能直接报错。
• 断点续跑：会话状态是持久化的，就算程序重启，也能精确恢复到”卡在等审批”的那个点，重放没有被应答的那部分，已经执行过的不会被重复执行一遍。
• 切换模型时不会读串：每次请求发给模型之前，系统都会按照当前选定模型的能力重新处理一遍上下文——比如附件是不是要转成纯文本、图片要不要用占位符替代，这样即使你在同一个任务中途换了模型（从一个支持读图的模型换成不支持的），行为也依然是正确的。

权限与风险模型：这是它真正的卖点

如果只看”能不能自动执行任务”，今天几乎所有 Agent 产品都能做到。OpenWorker 让人眼前一亮的地方，其实是它把”什么时候才允许做”这件事，当成了和执行能力同等重要的核心设计，而不是加在 UI 上的一层弹窗。

每一次工具调用在真正执行前，都要先过一遍风险分类和权限判定：先看这个动作属于哪一类风险，再看当前权限模式允不允许，最后决定是直接放行、挂起等待，还是弹窗问用户。

具体来说，它把所有工具调用按”副作用范围”分成四类风险：

在这套风险分类之上，用户可以选择五种权限模式，从”只讨论不动手”到”读操作直接放行、写操作和命令逐次确认”，再到”完全自动但依然限定可写目录范围”，颗粒度是比较细的。

这里有个设计思路特别值得记一笔：很多同类产品是按”工具名字”或者”命令白名单”来做权限管理的，比如告诉系统”以后 git status 不用再问了”。这种方式有个天然的漏洞——如果只是简单做字符串前缀匹配，那 git status && rm -rf ~ 也会被一起放行，因为它的开头恰好也是 git status。OpenWorker 的处理方式是：先直接拒绝任何包含分号、管道符、反引号这类”shell 操作符”的命令，然后把剩下的命令按语法正确解析，做逐个词的精确前缀匹配——这样 git status -s 会被放行，但想用操作符拼接别的命令，第一步就会被拦下。

另外两条约束也值得一提：一是”外部副作用”类的操作即使设置了免审批规则，也必须绑定一个精确的目标（比如只对某个具体邮箱地址免审批，而不是对”发邮件”这个动作整体免审批）；二是”无人值守”这个模式本身不会放宽任何权限上限，只是把原本需要弹窗的审批请求，改成放进一个待办收件箱里挂起，等人回来处理——而不是趁没人盯着的时候自动全部通过。这条设计背后的逻辑很朴素：审批的本质是”人类授权”，不是”人类在线”，人不在场的时候，正确的默认行为是等待，而不是自己做主。

模型中立与连接器：不绑定任何一家

OpenWorker 通过 aisuite 做模型路由，内置的策展模型矩阵有三十个左右的条目，横跨十几家供应商——不只是 OpenAI / Anthropic / Google 这几家一方模型，也包括国内常见的 GLM、DeepSeek、Kimi、Qwen、MiniMax 等 OpenAI 兼容接口的模型，还支持通过 Ollama 完全本地跑开源权重模型。这意味着换模型、混用便宜模型和贵模型、纯本地离线跑，都是配置层面的事情，不需要改架构。

工具接入这一侧同样走的是”配置驱动”路线：新增一个连接器，本质上是写一份声明式的描述文件——声明这个服务怎么认证、需要用户填哪些字段、怎么一步步引导授权、以及一个用真实 API 调用来验证 token 有效性的校验逻辑，而不是每接入一个新服务就要专门写一遍 UI 代码。目前它已经覆盖了大约四十个连接器，包括 Slack、Gmail、Google Calendar、GitHub、GitLab、Jira、Confluence、Notion、Salesforce、HubSpot 等常见办公与协作系统，同时也支持标准的 MCP 协议接入更多工具。

值得一提的是，走 MCP 协议接入的连接器，暴露给模型的工具面是被明确限定的一个子集，而不是把对方服务的全量能力都摊开——好处是就算上游的 MCP 服务发生变化，也只会让能力变少，不会突然多出模型可以调用、但你并不知道的新能力。

Artifact-First：产物才是核心，而不是聊天记录

如果说权限模型是 OpenWorker 的”安全观”，那 Artifact-First（以产物为先）就是它的”工作观”。

任务的核心不是那段来回对话，而是最终产出的成品；产物应当能够被独立引用、复用，并且和产生它的任务、审批记录关联起来，可以追溯。

这个理念背后的判断是：会话记录是”过程”，产物才是”结果”。如果把系统设计成以聊天记录为核心、文件只是附件，那这些产物就很难被跨任务检索和复用，也没法衡量”这次任务到底完成得好不好”。OpenWorker 把产物当作独立的一等对象来处理，这也是为什么它交付的从来不是一段话，而是一份 Markdown、一个 PDF、一张图，或者一条已经真正发出去的消息。

它适合谁用

从目前的产品形态看，OpenWorker 比较对味的场景大致是这几类：

• 个人知识工作者：产品经理、销售、运营、创业者这类角色，日常工作里有大量”整理资料、准备会议、写周报、做客户分析”这类重复性强、但又需要接触多个信息源的任务，是它目前展示得最顺手的用例。
• 小团队：当团队规模还没有专职的行政、运营、调研岗位时，把这类工作交给一个本地跑的 AI Worker 去分担，投入产出比是划算的。
• 对数据隐私敏感、又想用 AI 处理办公任务的用户：本地优先加上模型中立的组合，意味着数据不需要经过某一家厂商的云端才能被处理，也不需要把公司数据绑定在单一模型供应商身上。

它目前不太适合的场景也很明确：它不是编程助手的替代品——虽然内置了代码相关的能力，但明显弱于 Claude Code、Codex 这类专门做代码的 Agent；它也还没有面向企业组织的多用户协作、统一审计、单点登录这些能力，更适合个人或者小团队自己搭起来用，而不是直接拿来做一个组织级的平台。

现状：一个”设计成熟、产品早期”的项目

诚实地说一下它目前所处的阶段：截至发布后的这几周，版本号还停留在 0.1.6，项目自称处于 open beta。macOS 安装包已经签名并通过公证，Windows 安装包还没有代码签名，安装时系统会弹出安全告警；Linux 平台官方还没有发行版本，不过社区已经有开发者在提交打包 PR，只是还没有合并进主线。

权限模型的设计思路虽然清晰，但也有一条边界目前还没完全补上：审批引擎管的是”工具调用”这个层面的动作，而像 MCP 工具服务器这类在会话刚建立、还没轮到任何审批发生之前就已经启动的进程，暂时不在这套审批机制的管辖范围内。这也是社区里安全研究者最近讨论比较多的一个话题——审批门禁能拦住”模型想做危险的事情被人拦下来”，但拦不住”一个还没被审批看到的进程本身带来的风险”，这提示了一个更普遍的道理：审批只解决”模型层面的决策是否被允许”，执行环境本身要不要有一层独立的隔离（比如容器、沙箱），是另一个需要单独补上的问题，而不能指望审批机制一并兜底。

这大概也是理解这类”AI Worker”项目最实在的一个视角：架构上的新意其实并不多，本地优先、模型无关、审批门禁这套组合，放在 2026 年已经算是这类产品的标配。真正拉开差距的，是那些看起来不起眼的细节工程——中断了会不会留下没处理干净的状态、切换模型会不会读错上下文、权限设计有没有把”人不在场”和”权限放宽”这两件事分开处理。这些正确性没法靠一张架构图拿到，只能一处一处地填坑，这也正是这类项目里最值得花时间读一读的部分。

小结

OpenWorker 提供了一个相对完整、可以直接读源码验证的样本，说明”AI Worker”这个正在成型的产品形态，落地时到底需要解决哪些具体问题：怎么规划和执行一个目标而不是回答一个问题，怎么设计一套不会随便被绕过的权限体系，怎么在中断、恢复、换模型这些边界情况下保持正确，怎么把”产物”而不是”对话”当作系统的核心对象。它自己作为一个产品还处于早期阶段，但它对这几个问题给出的具体做法，很值得所有在做 Agent 类产品的人认真读一遍。

相关链接