吴恩达开源 OpenWorker：一个交付成品而不是对话的 AI 智能体桌面应用

7 月 23 号，吴恩达在 X 上宣布开源了 OpenWorker - 他和 Rohit Prasad 一起做的一个开源的 AI 智能体桌面应用。用它自己 README 里的话，它交给你的是成品，而不是一份待办清单 - 一份排好版的文档、一条带着真实数字的 Slack 回复、一个理顺的日历、一个筛过的收件箱。

现在的智能体早就不只是聊天了 - Claude Code、Codex、OpenClaw、Hermes 这些做的都是实打实的活：读写文件、执行命令、调用工具。往下拆，agent 干的事无外乎就这几类。所以有意思的问题不是“能不能干活”，而是每一家把这套底层动作做成了什么样 - 差异化恰恰藏在实现方式里。OpenWorker 是桌面应用（macOS 和 Windows）、MIT 协议、代码全开，我把仓库拉下来读了一遍后端，这篇就顺着代码看它在几处关键特性上的实现选择：交付成品的产品形态、分层的风险模型、无人值守、self-wake、本地优先。期望对大家有帮助。

OpenWorker README 里的工作流示意图 - 提问、本机干活（任意模型：云端 / 开源权重 / 全本地）、接你的工具、把成品发回。

交付成品，而不是对话

OpenWorker 的定位差异，在于它把“产出物”当成一等公民。你告诉它一个结果 - “准备一份客户简报”“把我这周的日历理一理”“看看这个版本在 Jira 和 GitHub 上到哪一步了” - 它把任务拆成步骤，跨你的文件、终端和已连接的应用去做，最后落地成文件：文档、表格、报告、网页，都是你能直接打开的成品。

后端为不同场景准备了几种 agent，它们共享同一套引擎，但工具集和人格不同：

• chat - 纯对话，没有文件和 shell 权限，适合随手问答。
• code - 编码用的，带单目录工作区、文件读写、git、持久 shell 和 todo，系统提示词把它约束成一个“先读懂再改、改完要验证”的资深工程师。
• cowork - 面向一次性的知识工作，产出一份具体交付物（备忘、分析、方案、数据），带多目录工作区。
• myhelper - 一个长期在线的个人助理人格，跨时间保持在一条连续线程上，记得住要紧的事，应用里和消息里都能找到它。

值得留意的是 code agent 的系统提示词里已经写进了并行读取的约定 - 多个互不依赖的 read/grep 请求要在一个批次里一起发，而不是一次一个。这类工程习惯直接写进了 prompt，而不是指望模型自己想到。

本地优先，模型随你挑

OpenWorker 跑在你的机器上，不把你锁死在任何一家模型上。你自带 API key - OpenAI、Anthropic、Google 都行，或者用 Ollama 完全本地跑。你的 key、对话、文件都留在本机，数据只经过你自己选的模型和集成往外走。

开箱支持的 provider 相当全：OpenAI、Anthropic、Google Gemini、Inkling（Thinking Machines）、GLM（智谱）、DeepSeek、Kimi（月之暗面）、Qwen、MiniMax、Mistral、Grok（xAI），加上通过 Together 和 Fireworks 接入的开源权重模型，以及本地的 Ollama。

实现上有个干净的设计。所有模型调用都走一个 ProviderRouter，它按模型字符串的 provider: 前缀分发到对应的 provider 客户端：ollama:llama3.3 走 Ollama（用它 OpenAI 兼容的 /v1），裸的 gpt-5.5 走默认的 OpenAI。客户端是按需懒加载并缓存的，改了 key 或换了 Ollama 地址就 invalidate() 掉缓存，现有会话不用重建就能拿到新配置。换模型这件事，因此可以在会话中途随时切。

分层的风险模型

一个真去动你文件、发你消息、跑你终端命令的 agent，最怕的就是它自作主张。OpenWorker 在这里做得很细，值得单独讲。

它先给每个工具标注了一个“风险类别”（RiskClass），这是工具本身固有的副作用等级：

• READ - 没有副作用，永远放行。
• WRITE_LOCAL - 改动工作区，按路径范围 + 模式来卡。
• EXEC - 执行命令，按模式来卡。
• EXTERNAL - 副作用发生在机器之外（发消息这类），这是无人值守 inbox 的挂钩点。

coworker/risk.py 一共 58 行：四个风险类别、一张按名字固定的基础表、一个 classify()。左侧文件树也顺带露出了整个后端 coworker/ 包的结构。

在这之上是运行模式（Mode），决定了同一个风险类别怎么处理：

• discuss - 只读对话，不改动、不进规划流程。
• plan - 只读，外加一套规划契约（探索 → 提方案 → 执行）。
• interactive - 默认模式，读操作自动放行，写操作和命令要你批准。
• auto - 全放行，但写操作仍然限制在路径范围内。
• custom - interactive 加上一份自动放行的工具白名单。

真正巧妙的是“任务级常驻规则”。当一个外部动作（比如往某个 Slack 频道发消息）被你批准后，引擎可以把“这个工具 → 这个目标”记成一条本次任务内的常驻规则，下次同样的目标就不再反复问你。但这条捷径只对 EXTERNAL 风险开放，绝不给 shell 和写文件 - 也就是说，跑命令这件事永远会问你，一次都不放过。安全的边界卡在最危险的动作上，而不是图省事全放开。

内置的 ops 人格把这套安全约束又用自然语言强化了一遍：先调查再动手、优先只读和可逆的步骤、任何有后果或不可逆的操作（重启服务、改基础设施、删数据）都要先说清楚再拿批准，而且明确要求把来自工具、日志、网页、文件、消息的内容当作不可信的数据，而不是指令。这一条正好挡住 prompt 注入。

无人值守

“交付成品”真正要跨过的坎，是让它在你不盯着的时候也能干活，同时又不失控。OpenWorker 用三块设计凑齐了这件事。

第一块是无人值守 inbox。当一个会话在无人看管的情况下跑，遇到需要批准的写、发、shell 动作时，它不会自作主张，而是把这些请求“停”在一个 inbox 里，等你回来处理。审批请求带着 tool_call_id，是幂等的，因此可以安全地持久化和恢复。

第二块是定时自动化。一个常驻在服务里的调度器负责跑周期任务 - 早间简报、每周报告、对某个频道的长期盯守。它的策略也考虑到了现实：宕机期间错过的任务，重启后补跑一次（run-once-catch-up），不会把积压的全堆上来；如果上一次还没跑完，这一次就跳过，不叠加（skip-on-overlap）。每次运行都带完整的执行记录落到应用里。

第三块最有意思，叫 self-wake。它把一个“一直在线”的 agent 变成了“挂起 / 恢复”：会话可以主动休眠，运行时在触发条件满足时再把它唤醒，空闲期间几乎零开销。触发有两种 - 定时器（sleep_for / sleep_until），和“等某个后台任务跑完”（wake_on）。它和定时调度器共用同一个 tick 循环：每一拍检查有哪些唤醒到期了，把对应会话恢复起来。一个要等三小时后再继续的任务，因此不用真的占着一个进程空转三小时。

接入你的工具

OpenWorker 自带 25+ 个集成，覆盖了日常工作里常见的那批：GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、monday.com、Gmail、Google Calendar，还有 Datadog、PagerDuty、Asana、Salesforce、Zendesk、Confluence、ClickUp、Discord、Telegram 等等，外加你的终端和本地文件。

除了内置连接器，任何能通过 MCP（Model Context Protocol）访问的工具都能插进来，而且是逐工具粒度的控制。MCP 的配置刻意做成了和 Claude Desktop、Cursor、Codex 互通 - 用的就是同一份 mcpServers JSON 格式，你从别处复制过来直接能用。配置分两层：全局的 ~/.config/coworker/mcp.json 和工作区级的 .coworker/mcp.json，同名时工作区覆盖全局。配置里的 ${VAR} 引用在加载时通过 SecretStore 解析，token 不会明文躺在配置文件里。HTTP transport 的 MCP 服务还支持 OAuth 2.1 + PKCE 加动态客户端注册的浏览器授权。

一个具体好用的场景是“从 Slack 工作”：你在频道里 @OpenWorker，它会在你桌面上开一个会话，用你本机的工具完成任务，结果作为线程回复发回来。集成不是单向的读，而是双向的工作入口。

Skills 与 Personas

OpenWorker 直接采用了 Anthropic 的 SKILL.md 格式来做技能扩展。一个 skill 就是一个文件夹，里面有 SKILL.md（YAML frontmatter 声明 name、description、可选的 allowed-tools）加一段 markdown 正文，外加可选的资源和脚本。它用的是“渐进式披露”：会话开始时只把技能目录（名字 + 描述）注入上下文，完整正文按需通过 load_skill 工具再加载。这样一堆技能不会一次性把上下文撑爆。

Personas 则是把 agent 的身份、推荐模型、默认权限模式、推荐连接器打包成一份带 frontmatter 的 markdown。内置的 ops 人格就是个好例子 - 它声明了自己适合 claude-opus-4-8 或 gpt-5.5、默认 interactive 模式、核心推荐 GitHub / Slack / Datadog 连接器，正文则是一整套“运维工程师该怎么谨慎干活”的行为准则。给不同工种配不同人格，比让一个万能 prompt 硬撑要清楚得多。

建立在 aisuite 之上

OpenWorker 的引擎建立在吴恩达团队的 aisuite 上 - 一个轻量的 Python 库，提供跨 provider 的统一 chat-completions 接口，以及一层带工具、工具箱和 MCP 支持的 agents 抽象。OpenWorker 最早就是在 aisuite 仓库里孵化的，后来才搬到独立的家。

仓库主页：后端 Python 占大头、前端 TypeScript，贡献者里能看到 Rohit Prasad 和 Andrew Ng。

反过来说，如果你想自己搭一套 agent 骨架，而不是直接用这个应用，README 明确建议从 aisuite 起步，把 OpenWorker 这个仓库当成“aisuite 能撑起多复杂的东西”的参考实现。引擎那层也不含糊 - 流式输出是把 provider 的阻塞式生成桥接到异步循环上，中断可以从任意状态（流中、工具执行中）随时打断并把用户已经看到的内容如实持久化，会话挂起后能做幂等的持久化恢复，还支持在一轮进行中插入 steering 消息纠偏。这些是“桌面 agent 用起来顺手”背后真正吃工程量的地方。

现在它还在 open beta，应用会自更新，所以修复能很快到达安装。想跑的话，桌面版直接下载，或者从源码起 - 后端一个常驻的本地 agent 服务（Python），前端是 React UI 加一个 Tauri 壳。

---

• 官网：openworker.com
• 源码：github.com/andrewyng/openworker