吴恩达的 OpenWorker 为何“不 Work”？

吴恩达与 Rohit Prasad 于 7 月 23 日在 X 上正式发布开源桌面 Agent：OpenWorker。顶流学者背书、开箱即用的桌面形态、模型自由切换……这款产品几乎集齐了爆款要素。上线一周，社区的真实反馈却指出：从“极客的玩具”到“普通人的数字员工”，中间还隔着一条巨大的产品化鸿沟。

三层架构

OpenWorker 是一套运行在桌面端的 Agent 工作台，整体分三层。

最上层是桌面界面，用户可以创建晨间简报、周报、频道监控等自动化任务，也可以自行填写任务名称和指令。任务开始后，模型的思考过程、工具调用记录和最终结果都会展示在应用中。

中间是本地 Agent 服务，负责接收用户目标、调用模型、管理任务循环，并根据模型判断读取文件、执行命令或调用外部工具。会话记录、记忆、任务状态和权限审批等功能，也主要由这一层负责。

最外层是模型和连接器。OpenWorker 可以接入 OpenAI、Gemini、Ollama 等不同模型，也能连接 Slack、GitHub、Jira、Notion、Outlook 等办公工具。当模型判断任务需要查询消息、读取项目状态或处理文件时，本地 Agent 服务会调用相应工具，再把返回结果交给模型继续处理，直到任务完成或操作被权限机制拦下。

模型层建立在吴恩达团队此前开源的 aisuite 之上。不同模型厂商的接口格式、参数和调用方式并不一致，aisuite 在模型和应用之间提供了一层统一接口，让上层 Agent 可以用相近的方式调用不同模型。这也是 OpenWorker 强调的“模型无关”：模型层与任务执行层相对分离，用户可以更换底层模型，而不必重搭整套工作流。

因此，OpenWorker 的特点，是把模型路由、工具调用、权限审批和自动化任务这些逐渐标准化的 Agent 组件，组装成一款可以直接安装、修改和审查的开源桌面产品。

和现有 Agent 有什么不同

目前常见的 Agent 产品大致可以分为三类。

第一类是软件工程 Agent。Codex、Claude Code 等产品围绕代码仓库、终端、测试和版本管理展开，任务边界相对清晰，结果也容易验证。

第二类是长期个人 Agent。OpenClaw、Hermes 等项目强调长期在线、跨会话记忆和 Skills 扩展，目标是成为越用越懂用户的个人助手。

第三类是一体化办公 Agent。WorkBuddy 等产品把模型、云服务、账号体系、连接器和技术支持打包在同一套商业产品中，用户开箱即用，但需要进入封闭生态。

OpenWorker 选择的是另一条路线：开源的通用办公 Agent。用户可以自行选择模型、部署方式和连接器，也可以检查源码、按需修改执行流程。但同样的自由也意味着，API Key、模型费用、接口兼容、连接器授权和故障排查，都可能需要由用户自己处理。

商业办公 Agent 通过一体化服务替用户吸收复杂性，OpenWorker 则把更多选择权交还给用户，也把一部分配置和维护成本一起交了出去。开放源码不等于交付产品，把一堆标准化的乐高积木倒在桌面上，并不能自动拼成一个能替你打工的机器人。

上线一周，三个问题被集中讨论

GitHub 上的反馈主要集中在三个方面：多模型兼容、本地数据边界，以及权限审批能否覆盖全部执行路径。

“模型无关”的幻觉：API 兼容不等于开箱即用

有用户尝试接入自建的 OpenAI-compatible 接口，配置页面通过连接检测，新会话却显示没有可用模型。也有用户反馈，本地 Ollama 服务运行正常，OpenWorker 却无法加载其中的模型。不同服务即便声称兼容 OpenAI 接口，也不代表在模型发现、工具调用和流式输出等环节具有一致的行为。

实际测试自动晨报时，还会遇到更直接的情况：模型账户额度不足，系统连续返回三次相同错误，既不自动停止，也不提示换模型或查余额。对开发者还好排查，但面向普通办公用户，不应要求大家先弄懂 API Key、模型名和计费额度，才知道任务为什么失败。BYOM（自带模型）听起来是把自由还给用户，实际上是把排错的灾难抛给了用户。

“本地优先”的数据就绝对安全吗？

OpenWorker 强调“本地优先”，Agent 服务运行在用户设备上，会话、密钥、记忆和部分任务数据主要保存在本地。数据大致分为三类：保存在本机的会话、密钥和任务数据；登录云账户后可能发送给官方服务的使用元数据；调用云模型和 Slack、邮箱、Notion 等连接器时需要发送给第三方服务的数据。

社区真正关心的是，OpenWorker 是否足够清楚地告诉用户：不同数据在不同配置下保存在哪里、发送给哪些服务，以及用户能否关闭或替换相应的数据路径。对桌面 Agent 来说，“本地优先”只能说明默认架构倾向，不能替代完整的数据流说明。

谁在后台“静默”跑了代码？

OpenWorker 为写文件、运行命令和修改外部系统等操作设计了审批机制。但社区报告指出，某些配置文件可能在用户尚未信任工作区时，就启动其中定义的外部服务进程。目前这主要来自社区报告和复现讨论，不代表已发生大规模攻击，但它揭示了桌面 Agent 的一个普遍风险：权限控制不能只覆盖模型主动调用工具的主流程，还要覆盖配置解析、插件加载、连接器初始化和后台进程启动等旁路。

开源的代价：自由向左，复杂向右

OpenWorker 使用的模型路由、工具调用、记忆、连接器和权限审批机制并不新鲜，这些能力正在成为 Agent 产品的常见组件。吴恩达在发布时强调，OpenWorker 不应只与用户聊天，而要交付文档、消息、日程等“完成的工作”。它真正想解决的，是如何把这些能力组合成一套可以直接使用的工作系统。