OpenWorker 上手：把只给建议的 AI 对话换成能交付成品的桌面同事

GitHub 上的 Andrew Ng（吴恩达）主导的开源项目 OpenWorker（andrewyng/openworker），定位是桌面端的「AI 同事」：你给它一个结果目标，它在你的电脑上拆解任务、调用本地文件与已连接的应用，在发送消息、改日历、执行命令前向你确认，最后交给你一份能直接打开和分享的成品——文档、带数据的 Slack 回复、更新好的日历、分拣好的收件箱——而不是一段「接下来建议你……」的回复。

项目当前处于 open beta，v0.2.1 于 2026-08-25 发布，采用 MIT 协议，代码以 Python 64.3%、TypeScript 29.5% 构成，16 位贡献者，截至素材快照拥有 15.5k star、2.1k fork、347 commits。macOS 12+（Apple Silicon）安装包已签名公证并支持自动更新；Windows 10/11 x64 版尚未签名，安装时 SmartScreen 会提示，签名流程进行中。

OpenWorker 的核心判断是：多数 AI 助手停在「分析 + 建议」这一步，真正的价值在交付物本身。它把本地优先、自带模型、执行前审批当作产品三支柱：Agent 循环、对话记录、连接器令牌与模型密钥都放在本机本地存储中，唯一在云端的组件是一个为连接器 OAuth 握手做中转的小服务。

它交付什么

• 产出真实交付物：文档、表格、报告、网页会落成本地文件，直接打开、直接分享。
• 从 Slack 呼出：在频道里 @OpenWorker，桌面端会打开一个会话窗口，用你的工具完成工作，再把结果作为线程回复发回。
• 接日常工具：内置 25+ 连接器，包括 GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、monday.com、Gmail、Google Calendar，终端与本地文件也可用；任何走 MCP 协议的工具都能接入，并支持按工具控制权限。
• 定时自动化：晨报、周报、对某个频道的持续盯守等周期性任务，运行结束后在应用内保留完整记录。
• 执行前审批：发送、写文件、执行 shell 命令都被审批门控拦下；无人值守的自动化会把待批请求放进收件箱，而不是自行行动。

模型自己带

OpenWorker 不绑定任何模型：粘贴 OpenAI、Anthropic、Google Gemini 等提供商的密钥即可使用，也可接入 BytePlus Ark、GLM、DeepSeek、Kimi、Qwen、MiniMax、Mistral、Grok 等，还支持开源权重模型与 Ollama——用 Ollama 时全部推理在本机完成。内置一个经过验证的模型清单，标注了适合工具调用的模型；自填其他模型字符串也可运行，风险自负。

架构：三个本地层

• 桌面壳：Tauri（Rust）壳 + React UI（surfaces/gui/），负责窗口管理与进程守护；另有 Rust 写的语音输入副载（stt/）。
• 本地 Agent 服务器：Python 后端（coworker/），承载 Agent 循环、模型提供商、连接器、MCP 客户端、记忆与自动化。
• 引擎基于 aisuite：aisuite 提供统一的 chat-completions 接口与 agents 层；README 将本仓库标为 aisuite 的 working reference，想自己搭 Agent 框架可以从它入手。

本地优先与隐私

本地优先意味着数据默认不离开你的机器：Agent 循环、对话历史、连接器令牌、模型密钥都存于应用本地密钥库。唯一例外是连接器 OAuth 授权时的中转服务，且你完全可以在不登录的情况下手动创建连接器凭据来使用。项目方对边界的表述是：数据只经由你选择的模型与集成离开机器。

从源码运行

前置依赖：Python 3.10+、Node 20+，桌面壳需要 Rust 工具链（通过 rustup 安装）。

git clone https://github.com/andrewyng/openworker
cd openworker

# 1. 一次性引导：创建 .venv Python 虚拟环境（Windows 上在 Git Bash 或 WSL 中执行）
bash packaging/setup_dev_env.sh

# 2. 启动本地 agent 服务器（Windows 用 .venv\Scripts\openworker-server.exe）
.venv/bin/openworker-server --cwd /some/project --port 8765

# 3. 另开一个终端启动 UI（浏览器模式，走 Vite 开发端口）
cd surfaces/gui
npm install
npm run dev

• --cwd 参数把 Agent 的文件读写与 shell 执行限定在指定目录，是文件系统的安全边界。
• 独立运行服务器时，启动会在状态目录生成一个仅用户可读的一次性令牌 <state-dir>/sidecar-8765.token，直接调用 API 时放入 X-OpenWorker-Token 请求头；桌面应用改用内存令牌、不落盘。
• 要跑完整桌面应用，把第 3 步换成 npm run tauri dev（在 surfaces/gui/ 目录），Tauri 壳会启动窗口并自行守护服务器进程。
• 测试：后端用 .venv/bin/pytest，GUI 用 npm test 与 npm run e2e；macOS 打包脚本为 packaging/build_dmg.sh，Windows 为 packaging/build_windows.ps1。

适用场景

README 的定位是 open beta：功能可用、自动更新、仍在打磨细节。判断是否引入前，需要先确认：是否接受自带模型密钥的成本，是否愿意在正式工作流里承担 beta 阶段的未知风险。对开发者来说，花一个下午用自带密钥或 Ollama 跑起来，验证「交付成品」这个流程是否可靠，是低成本的做法——最终判断依据应该是它交付的成品质量、审批流是否符合你的工作习惯，而不是项目热度。保守的选择是等 Windows 签名完成、beta 期结束再评估。

一句话结论：OpenWorker 值得关注的是三点——交付真实成品而非建议、执行前必须经过审批门控、数据与模型默认留在本机。 这三条都写在其产品定位与功能描述里，适合想体验「AI 交付成品」、愿意自带密钥、接受 beta 阶段的开发者，也适合重视数据留在本机、希望控制 Agent 权限边界的技术团队。