“外国版”workbuddy被开源了！冲上了12k star

accept 100％

236人浏览 · 2026-08-03 10:41:13

accept 100％ · 2026-08-03 10:41:13 发布

背景：OpenWorker — 吴恩达和 Rohit Prasad（前 Alexa 首席科学家）联合开源的一款桌面端 AI Agent，在 GitHub 已经冲上1.2w Star了。

在这里插入图片描述

一句话定位：他不是聊天机器人，是交付成果的本地 AI 同事。你告诉它要什么结果（比如"准备明天会议简报"“整理日历”），它自己拆任务、跨工具调用，最后交给你一份成品文件，而不是一段对话。

一、转变：战场已经从"谁的嘴更甜"挪到"谁真把活干完"

如果去年大家还在比谁的对话框更会接话，今年桌面 Agent 这条赛道明显换轨了——比的不是聊天水平，而是能不能真的跨软件把一件事从头跑到尾，最后把成品拍在你桌上。

这股风里最扎眼的两个开源项目，正好是一对互补的"邻居"：一个是 Different AI 推出的 OpenWork，靠"把工作流当能力打包、让多个 Agent 共用"的思路，已经攒到约 1.71 万 Star；另一个是吴恩达（Andrew Ng）亲自下场的 OpenWorker，从 7 月底公开测试算起，各来源记录的 Star 数从 5K、7K+ 一路跳到 1.2 万，一周冲上桌面 Agent 顶流。

本文主角 OpenWorker 最不一样的地方在于：它不像那些只会吐一段文字的对话框，而像一个把任务从头跑到尾、最后把成品交到你手上的本地搭档。你丢给它一句"准备明天和客户的会议简报"，它自己拆步骤、自己调工具，交付的是一份能直接用的文件，不是一段需要你再加工的对话。更关键的是，凡是会留后果的动静（发消息、改日程、跑命令），它都先举手等你点头。

下面我们把这间"工作室"从门面拆到地基。

二、谁在造，有什么区别：一个负责定方向，一个负责管落地

一款开源项目刚发布就受关注，背后两个人的履历给了它天然的信任底盘。

吴恩达（Andrew Ng）是 AI 圈的老熟人：DeepLearning.AI 创始人、AI Fund 管理合伙人、斯坦福教授、Amazon 董事会成员，算是 AI 教育与投资领域的一面旗帜。

Rohit Prasad 名气没那么响，但份量不轻：前 Amazon Alexa 首席科学家，后来升任 Amazon AGI（通用人工智能）团队负责人，直接向 CEO Andy Jassy 汇报，去年底离开 Amazon。他是真正在十亿级设备上做过 Agent 交互的工程老将。

一个画蓝图，一个把蓝图落成能跑的系统——这个组合本身就说明 OpenWorker 不是周末玩具。它的代码量也撑得起"产品级"三个字：coworker/ 下约 119 个 Python 文件（约 3.24 万行），surfaces/gui/ 下约 149 个 TypeScript/TSX 文件，外加 78 个后端测试模块，是完整的工程结构。

（邻居 OpenWork 来自 Different AI，走的是另一条路：基于 OpenCode、支持 50+ 模型，对外提供远程 MCP 服务，还有 OpenWork Den 团队管理后台。两者一个偏"共享能力"，一个偏"本地交付"，正好互补。）

三、它到底在解决什么：把"说不清的活"变成"交得出的货"

很多 AI 工具卡在一个断点上：它能给你一段答案，但复制、整理、跨软件搬运的苦力活还得你自己来。OpenWorker 想打通的正是这个断点。

把它当成一间开在你电脑里的工作室就好理解了：你站在门口说一句想要的结果，里面的"主理人"自己把活拆开、派人去本机翻文件、打电话给外部办公软件，最后把报告、消息、整理好的文档、更新过的日程这些"货"交出来。

几个真实可套的场景：

销售：读本地客户资料 + HubSpot 数据，自动生成客户简报；
运营：汇总 Slack 信息 + 日历日程，自动输出周报；
办公：整理本地文档、起草邮件、更新会议日程。

注意它的边界：目前是 Open Beta，官方 Demo 校准过的任务大致在 5–9 步，末尾常有外发批准。它适合个人和小团队的生产力框架研究，不是无人值守的交易系统。

四、四层解剖：把它想象成一间本地工作室

OpenWorker 的技术栈能压成四层，全部默认跑在你本机。我们借用一间工作室的比喻来拆解——L1 到 L4 各司其职：
在这里插入图片描述

1、L1 门面与前台（Tauri 2 + React 18）。

Tauri 是原生容器，React 负责画面。它做的是"前台"的活：承载会话、把需要你签字的待批单据亮出来、收着无人值守时的信箱；同时它还盯着里面的主理人进程有没有失控——否则就会出现"你关了窗，里面的循环还在偷偷跑"的尴尬。

2、L2 主理人（FastAPI + aisuite）。

这是工作室真正动脑子的一层，用 Python 写，FastAPI + uvicorn，默认绑在 127.0.0.1:8765。它建在吴恩达的另一个开源项目 aisuite 之上——aisuite 提供跨厂商的统一 chat-completions 接口，外加 Agent 层、工具层和 MCP 支持。OpenWorker 的 README 说得很直白：想自己搭 Agent 框架，先看 aisuite。L2 负责拆活、跑多轮循环、调工具和模型、给每次操作过审，还留着完整的工作记录（transcript）方便复盘。

3、L3 跑腿与外接线路。

主理人自己不伸手，得靠这一层去碰真实世界：本机手脚包括文件系统、Git、ripgrep 搜索、终端；外接线路有 25+ 个，GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、monday.com、Gmail、Google Calendar 都在列；不够再接任意 MCP 工具。官方的扩展哲学很清楚——优先拉外接线路、接 MCP，而不是去改主理人的工作方式本身，这样工作室才好维护。

4、L4 背后的智库。

经 aisuite 把 L2 的请求转给配置好的模型或本机 Ollama。预置 30 个验证过适合工具调用的模型，覆盖 OpenAI、Anthropic、Gemini、DeepSeek、Kimi、GLM、Qwen、MiniMax、Mistral、xAI Grok，以及 Together / Fireworks 的开源权重和 Ollama 本地模型；v0.1.7 又加进 AWS Bedrock、Google Vertex AI、OpenRouter、Meta Muse Spark。OpenWorker 不抽成、不托管推理——换的是智库，门面和工作方式不变。

一次任务在工作室里怎么流转：你在 L1 报出想要的结果（或在 Slack @OpenWorker 触发）→ L2 拆活进入"模型 ↔ 工具"多轮循环 → 要碰真实世界就派 L3，每次出动先过权限关 → 每轮思考走 L4 → 需你签字的动作退回到 L1（你不在就进信箱）→ 成品经 L1/L3 交到你手（md / pdf / Slack 线程 / 日历）。

隐私地基也提一句：整间工作室没有云端推理层；唯一上云的是可选的 OAuth 握手中转，而且手贴凭证就能绕开。本地优先是实打实的承诺。

五、权限引擎：给 Agent 配一把"分档钥匙"

这是 OpenWorker 最该被单独拿出来说的设计。多数 Agent 处理权限很粗：要么全放，要么每步都弹窗。OpenWorker 把权限做成了 L2 执行路径上的一套分类 + 裁决机制，是代码里的硬约束，不是界面上贴的创可贴。

源码里 coworker/risk.py 给每次动作贴危险标签，coworker/permissions.py 再按模式给出"放行 / 需人审 / 拒绝"的裁决。每次工具调用都先分类、再裁决。

四档"危险等级牌"：

等级	含义	例子
read	看了看，没留痕迹，永远放行	不写不发的只读工具
write_local	改本机工作区，且路径得在允许圈内	写文件、打补丁
exec	跑命令	执行 shell（默认长期要签字）
external	东西出了本机，可挂"常驻规则"	连外部应用 / 需审批的动作

五种"授权尺度"（Mode）：

discuss / plan：纯旁观（plan 另带规划契约），只分析不动手；
interactive（默认）：读自动过，写 / 命令 / 外发都要你确认；
auto：全放行，但仍画着路径圈，出圈不行；
custom：你点名哪些工具自动过。

三个反直觉却关键的决定：

你不在场，不等于它权限更大。你让工作室后台跑个定时任务（比如每天自动整理简报），遇到要签字的动作，它不会自作主张，也不会跳步，而是把单据塞进信箱、把这次会话挂起，等你回来批。大多数框架把"在不在人"和"能干什么"混为一谈——你一走，它就默认能多干。OpenWorker 把两件事拆开：你不在只改变它"找你的方式"，不改变它能动的边界。就像请假条不会因为你出差就自动生效。
“常驻规则"只管外发，电闸永远要你亲手合。站好"一次批准"不会蔓延成"永久放行全世界”。而且 shell 的放行名单会拒绝带 ; & | > < \ $ ( (` 的命令串，防前缀绕过。换句话说，凡是动命令（电闸），任何模式下都得你合，没有例外。
内外两把锁。外部送进来的工具结果、网页、消息，一律当"匿名信"先核验再采用；而真正执行动作那一步，钥匙在你手里。两道锁一里一外，是 Agent 安全里最容易被省掉、却最致命的一环。

把这套放进"安全审批机制"的语境：本质就是所有会改、会发、会写的敏感动作，执行前强制等你签字，从源头堵住 AI 擅自乱动的风险。

六、openworker的开源

官网喊"100% open source"，仓库根目录放的是标准 MIT License。这两套话不是一回事："100%"是官网的强调语气，真正管你能不能商用的，是 MIT 那一纸证。MIT 明文允许你使用、复制、修改、合并、发布、分发、再许可乃至出售副本，只要求保留版权与许可声明。对比强 copyleft（GPL），MIT 不逼你开源自己的修改，也不拦你拿去卖产品。

打个比方：很多项目像"只租不卖的店面"——你能进去看，但规矩全房东定，想改想转手都不行；有的像"能参观但不能营业的样板房"——源码看得见，License 却卡商用。OpenWorker 的 MIT 则像你拿到了带使用权的地契：照着盖、改了卖、转手分都行，只需在副本里留着原署名。所以更稳的说法是：OpenWorker 开源，且 MIT 允许商用与二次分发；"100% 开源"当官网金句，判断时仍用"开没开源 × 许不许可商用"两问。真要上生产，仍建议法务过一遍依赖与第三方 ToS。

七、同台对比：谁是正面对手，谁只是长得像

桌面办公 Agent 已经分出两条路线。把 OpenWorker 和正面竞品摆一起：

维度	OpenWorker	GPT Work（OpenAI）	Marvis（腾讯）	QoderWorker（阿里）
协议	MIT，可商用可分发	闭源	闭源成品	闭源商业产品
部署	本地优先	云端优先	本地读文件	桌面端
模型	模型无关（BYOK / Ollama）	强绑 OpenAI	绑腾讯生态	多模型，国内连接器强
私有化	可私有化	不可	不可	不可
连接器	25+ + MCP	本地文件弱	腾讯生态内	飞书 / 钉钉更强

路线对立很清楚： GPT Work 是"豪华但只能进特定商场的会员制服务"，闭源云端；Marvis 是成熟商用成品，但锁在腾讯生态；QoderWorker 本土化办公更强，但仍是闭源。OpenWorker 的卖点是开源、本地、模型自由。

容易被认错的那位"守夜人"——OpenClaw。两者常被放一起，但形态不同：OpenWorker 像前台有人值班的门店，你坐电脑前临时起意派活，偏前台日常；OpenClaw 像埋在服务器里、常年不关机的守夜人，以 CLI / 服务端部署为主，擅长定时任务和 7×24 监听。一个白天陪你办公，一个后半夜替你守着——不是同胞，是邻居。

OpenWork（Different AI）则是另一种互补。它基于 OpenCode、支持 50+ 模型，对外暴露两个 MCP 工具：search_capabilities（查当前账号能用什么能力）和 execute_capability（调用能力执行任务）。接到 Codex / Claude Code / OpenCode 后，原本在 OpenWork 里配好的 Skills、插件、MCP 连接都能接着用；还有 OpenWork Den 团队后台统一管理模型供应商、成员和权限。

再往外一圈，是"长得像但根本不是一路"的工具，别认错：

代码专用 Agent（Cursor、Copilot、Claude Code）：像只接裁缝活的师傅，专写码，用户群完全不同；
云端浏览器智能体（Operator、BrowserUse）：像只能在网页橱窗里转悠的导购，碰不到你本机文件；
传统自动化平台（Zapier、n8n、Make）：像按固定菜单走的流水线，缺大模型自主拆解的能力；
纯对话 AI（Kimi 桌面端、ChatGPT 桌面版）：像只会动嘴的参谋，不能跨应用把整条链路跑完；
Agent 开发框架（LangChain、AutoGen、CrewAI）：像卖零件不卖成品的建材市场，要工程师自己搭。

八、动手跑起来：三种上手路径

路径一：下载桌面客户端（最省事）。

官方提供 Apple Silicon Mac 和 Windows 10/11 安装包，去 openworker.com 下载，装好填一个模型 API Key 就能用。提醒：Mac 已签名公证、支持自动更新；Windows 包有但未完成代码签名，安装会弹 SmartScreen 警告；暂无 Linux 版；暂无中文界面。

路径二：从源码跑（想改造框架的开发者）。

需要 Python 3.10+、Node 20+；跑完整桌面版还要 Rust 工具链。

git clone https://github.com/andrewyng/openworker
cd openworker
bash packaging/setup_dev_env.sh          # 初始化环境（建 .venv）
.venv/bin/openworker-server --cwd ~/your/project --port 8765  # 起本地主理人
cd surfaces/gui && npm install && npm run dev  # 起门面
# 要完整桌面版而非浏览器 UI，最后一步换成：
npm run tauri dev

路径三：把 OpenWork 当 MCP 接进现有工具流（在用 Codex 时）。

  codex mcp add openwork --url https://api.openworklabs.com/mcp/agent
  codex mcp login openwork

这样在 OpenWork 里配好的会议简报 Skill，就能让多个 Agent 调用，换模型换客户端都不用重新搬工作流。

实战建议（综合多篇实测）：

授权尺度保持 interactive：读自动过，写 / 命令 / 外发都确认，最稳；
先跑通一条端到端再铺开：部分连接器还标 “soon”，从稳的链路起步；
场景直接套第三节的销售 / 运营 / 办公模板。

九、冷静一下：它现在适合谁，不适合谁

优点说够，也要泼点冷水：

仍是 Open Beta，边角在快速打磨，PR 可能和内部路线图冲突；
模型成本和密钥运维在你自己肩上，模型与 SaaS 的协议独立于 MIT；
无官方 task benchmark，质量绑定你选的模型；
可选 OAuth 云握手不在"本仓 100% 开源"叙事里自动覆盖，敏感环境优先手贴凭证。

所以更适合：重视办公数据隐私、常用海外 SaaS、想自己改造 AI 工作流的从业者，拿来体验和小规模测试。暂时不建议直接塞进核心生产业务。

小总结：

长久以来，开源本地 Agent 大多写给程序员，缺一个普通业务人员也能上手的可视化成品。OpenWorker 的价值，是把"本地优先、开源可私有化、模型自由"这套能力，封装成普通人能开的"工作室"——而且用一套真正能审计、能 fork 的权限引擎，把"Agent 安全"从口号做成了代码里的分档钥匙。

对于想脱离大厂封闭生态、又要真把活干完的人，它确实给了条新路。