OpenWorker 开源：桌面 AI 同事开始交付成品

如果说过去一年大家都在做更强的聊天助手，OpenWorker 想回答的问题更直接：AI 能不能住在你的电脑里，替你把日常工作真的做完？

OpenWorker 是 Andrew Ng 账号下新开源的桌面 AI coworker 项目。截至 2026 年 7 月 26 日，仓库显示约 5,800 Star、778 Fork、165 个开放 Issue，默认分支最近一次推送发生在 2026 年 7 月 25 日。项目仍处在 Beta 阶段，但 README 里已经给出了清晰定位：它不是只返回建议的聊天机器人，而是面向文档、表格、报告、网页、Slack 回复、日历整理、收件箱分拣这类“可交付结果”的本地优先 AI 同事。

— OpenWorker 工作方式

01PART

它到底解决什么问题

OPENWORKER

OpenWorker 的核心卖点不是“又接了一个模型”，而是把模型、桌面环境、文件系统、终端和常用 SaaS 工具放到同一条工作流里。用户只需要说出结果，例如“准备一份客户简报”“整理周一发布进展”“把日历冲突理顺”“检查 Jira 和 GitHub 上的版本状态”，系统会拆解步骤、调用工具，并在需要执行关键动作前让用户确认。

这背后有一个很朴素但重要的产品判断：很多知识工作不是问答，而是交付。你最后要拿到的不是“你可以这样做”的清单，而是一份能打开的文件、一条带数据的 Slack 回复、一个更新过的日历安排，或者一份已经整理好的报告。

02PART

功能特点

OPENWORKER

1. 本地优先，不绑定单一模型

OpenWorker 的 Agent 循环、会话、连接器 Token、模型 Key 都放在本地应用的 secret store 中。README 里明确说，数据只会通过你自己选择的模型和集成流出本机。它支持 BYO model key，可以接 OpenAI、Anthropic、Google Gemini、GLM、DeepSeek、Kimi、Qwen、MiniMax、Mistral、Grok，也可以通过 Together、Fireworks 使用开源权重模型，或者直接使用 Ollama 做完全本地推理。

这让它更像一个“模型无关的桌面工作台”。你可以根据任务敏感度、成本、工具调用能力切换模型，而不是被某个闭源桌面助手锁死。

2. 真正连接日常工具

README 提到 OpenWorker 内置 25+ 个连接器，包括 GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、monday.com、Gmail、Google Calendar，还包括终端、本地文件和 MCP。代码目录也能对应上这条线：coworker/connectors/ 放连接器适配层，coworker/mcp/ 放 MCP 客户端、配置、OAuth 与工具桥接，coworker/tools/ 放文件、Shell、Git、搜索、待办、子任务等本地工具。

对开发者来说，这个设计的价值在于扩展边界比较清楚：传统 SaaS 工具走 connector，本地能力走 tool，外部标准工具协议走 MCP。

3. Slack 不是通知入口，而是工作入口

OpenWorker 支持在 Slack 里提及 @OpenWorker。它会在桌面上打开一个会话，用你本机的工具做事，然后把结果回到 Slack thread。这个细节挺关键，因为团队协作里很多任务不是从 IDE 或专用 Agent App 发起的，而是从 Slack 的上下文里冒出来的。

如果一个 Agent 只能在自己的窗口里工作，它会不断要求用户复制粘贴上下文。OpenWorker 想把入口放回真实协作场景里。

4. 定时自动化与完整记录

它内置自动化能力，可以做 morning brief、weekly report、频道监控这类周期任务。代码里有 coworker/automation/models.py、scheduler.py、store.py 和 tools.py，对应数据模型、调度器、存储和自动化工具。README 也强调，自动化运行结果会落在 App 里，并保留完整 transcript。

这让它不只是“你问一句我答一句”的助手，而是能承担部分固定工作节奏。

5. 写入、发送、命令执行都有审批门控

OpenWorker 没有把 Agent 直接放飞。README 里写得很清楚：发送消息、改日历、运行命令等有后果的动作都会先询问用户。代码中的 coworker/permissions.py 也能看到权限模式：plan、interactive、auto、custom；低风险动作可以自动执行，高风险工具调用会进入审批。coworker/engine.py 里则有工具调用授权、审批请求、并发低风险工具执行、durable resume 等逻辑。

这类门控不是锦上添花，而是桌面 Agent 能不能长期使用的前提。能帮你动文件、发消息、跑命令的东西，必须先学会停下来问你。

03PART

功能架构图

OPENWORKER

— OpenWorker 功能架构图

从仓库结构看，OpenWorker 大致可以拆成四层： 桌面体验层：surfaces/gui/ 是 React + Tauri 应用，负责聊天界面、审批卡片、收件箱、连接器配置、自动化视图和本地路径授权等用户界面。 本地 Agent Server：coworker/server/ 提供本地服务入口，coworker/engine.py 负责模型与工具之间的循环，coworker/permissions.py 负责权限判断。 工具与连接器层：coworker/tools/ 管本地文件、Shell、Git、搜索、计划和子任务；coworker/connectors/ 管 Slack、Gmail、GitHub、HubSpot、Calendar 等外部服务；coworker/mcp/ 负责 MCP 接入。 模型与状态层：coworker/providers/ 把不同模型提供商抽象成统一接口；coworker/memory/、coworker/sessions.py、coworker/secrets.py 处理记忆、会话和密钥。

这个架构的关键不是某个单点能力，而是边界划分：模型只负责推理和工具选择，Server 负责编排和风控，GUI 负责呈现和审批，连接器负责接真实世界。

04PART

一次任务的运行流程

OPENWORKER

— OpenWorker 任务流程图

一次典型任务大概是这样跑的： 用户在桌面 App 或 Slack 里描述想要的结果。 Agent 把目标拆成步骤，并决定需要哪些上下文和工具。 低风险读取类工具可以直接执行，例如搜索、读文件、查状态。 涉及写入、外发、Shell 命令、日历修改等动作时，系统触发审批。 用户批准、拒绝或重定向后，Agent 继续执行。 最后交付文件、回复、报告、日历变更或线程回复，并保留完整记录。

这条链路的产品取舍很清楚：效率不是靠取消用户控制换来的，而是把用户从“手动搬运上下文”里解放出来，同时把高风险动作留给人确认。

05PART

安装和运行方式

OPENWORKER

OpenWorker 提供 macOS Apple Silicon 和 Windows 10/11 x64 下载。macOS 版本已经签名、公证并支持自动更新；Windows 构建目前还未完成代码签名，所以 SmartScreen 可能会警告。

如果想从源码运行，需要 Python 3.10+、Node 20+，桌面壳还需要 Rust 工具链。README 给出的本地开发流程是：

如果要跑完整桌面应用，可以在 surfaces/gui/ 下用 npm run tauri dev。测试方面，后端使用 .venv/bin/pytest，GUI 使用 npm test 和 npm run e2e。

06PART

我会怎么理解它的架构模式

OPENWORKER

OpenWorker 代表的是一种正在成型的桌面 Agent 模式：本地运行时 + 多模型路由 + 工具连接器 + 审批门控 + 周期自动化。

它不像 IDE 内部的 coding agent 那样只盯代码，也不像通用聊天产品那样把所有东西都包在一个输入框里。它更接近“个人工作系统的本地控制层”：模型只是脑子的一部分，真正有价值的是它能触达哪些上下文、能操作哪些工具、在什么地方停下来让人确认。

这类产品的长期难点也在这里。连接器越多，权限边界越复杂；自动化越强，失败恢复和审计越重要；模型越自由，越需要可解释的审批和本地日志。OpenWorker 目前的 README 和代码结构已经把这些问题放在了中心位置，这比单纯堆模型能力更值得关注。

07PART

适合谁关注

OPENWORKER

如果你是普通用户，OpenWorker 值得关注的点是：它能否成为一个真正跑在你电脑上的 AI 工作助手，而不是另一个云端聊天入口。

如果你是开发者，它更像一个可读的桌面 Agent 参考架构：Python Agent 后端、React/Tauri 桌面前端、模型 provider 抽象、MCP 接入、审批系统、连接器注册、自动化调度，这些都在一个仓库里。

如果你在做企业内部 Agent，OpenWorker 也提供了一个提醒：越靠近真实业务系统，越不能只讲“智能”。权限、审计、本地密钥、审批队列、连接器边界，才是这类工具能不能进入日常工作的关键。

///LAST

结语

SUMMARY

OpenWorker 现在还在 Beta，Windows 签名、连接器细节、自动化稳定性、模型工具调用质量，都还有继续打磨的空间。但方向很清楚：桌面 Agent 不应该只是“会聊天”，而应该把上下文、工具和人类审批串起来，交付一个能直接用的结果。

这也是我觉得它值得单独拆一篇的原因。Agent 真正进入工作流时，最大的变化不是多了一个对话框，而是电脑开始有了一个会请求权限、会跨工具干活、会把结果带回来的本地协作者。

///LAST

声明

SUMMARY

本文由山行整理自：[andrewyng/openworker](https://github.com/andrewyng/openworker)，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～