吴恩达开源的OpenWorker，为什么「不 Work」了？

AIGC行业资讯13小时前发布 zhang

2 0 9

指望 Agent 替人上班之前，它们还得自己先去上个班

美国时间 7 月 23 日，人工智能领域的著名学者吴恩达与 Rohit Prasad 在 X 上正式发布了一款开源的桌面 Agent：OpenWorker。

顶流学者背书、开箱即用的桌面形态、模型自由切换……OpenWorker 几乎集齐了所有爆款的要素。那么，这款产品的实际体验如何呢？

（OpenWorker 生成的 AI 新闻简报）

上图是OpenWorker生成的一份过去 24 小时的 AI 新闻简报。从产品形态上看，它已经把过去需要代码配置的 Agent 工作流，压缩成了一个可以直接操作的桌面应用。

然而上线一周，社区的真实反馈却明确指出，从“极客的玩具”到“普通人的数字员工”，中间还隔着一条巨大的产品化鸿沟。

作为一个刚刚开源的桌面 Agent，它不仅展示了这类产品正在形成的基本结构，更暴露出多模型兼容、数据流向和权限控制仍未解决的问题。

01 OpenWorker 的架构与工作流程

更准确地说，OpenWorker是一套运行在桌面端的Agent工作台。从整体结构来看，OpenWorker 大致可以分为三层。

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

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

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

它的基本工作流程大致可以简化成下图：

(OpenWorker 工作流程图)

(OpenWorker 官网工作流程示意图)

OpenWorker 的模型层建立在吴恩达团队此前开源的 aisuite 之上。不同模型厂商在接口格式、参数和调用方式上并不完全一致。如果应用分别对接每一家模型服务，开发者往往需要重复适配。aisuite 在模型和应用之间提供了一层统一接口，让上层 Agent 可以用相近的方式调用不同模型。

这也是 OpenWorker 所强调的“模型无关”：它的模型层和任务执行层相对分离，用户可以更换底层模型，而不必重新搭建整套 Agent 工作流。

（“模型无关”部分源码）

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

02 与现有 Agent 相比，

OpenWorker 有什么不同？

如果把目前常见的 Agent 产品放在一起看，它们大致可以分为三类。

第一类是软件工程 Agent。Codex、Claude Code 等产品主要围绕代码仓库、终端、测试和版本管理展开。它们的任务边界相对清晰，结果也更容易验证：代码能否运行、测试是否通过、文件修改了什么，都可以通过编译结果、测试记录和代码差异直接判断。

第二类是长期个人 Agent。OpenClaw、Hermes 等项目更强调长期在线、跨会话记忆和 Skills 扩展。它们不仅完成一次任务，还试图记住用户的偏好、历史信息和处理方法，在后续任务中持续复用，目标是成为一个越用越熟悉用户的个人助手。

第三类是一体化办公 Agent。以 WorkBuddy 为代表的产品，将模型、云服务、账号体系、连接器和技术支持打包在同一套商业产品中。用户不需要自行选择模型、配置 API 或处理不同服务之间的兼容问题，打开产品后即可使用，但相应地也需要进入厂商提供的封闭生态。

OpenWorker 选择的是另一条路线：开源的通用办公 Agent。

OpenWorker 允许用户自行选择模型、部署方式和连接器，这种开放性给了用户更多控制权。用户可以替换模型、检查源码，也可以根据自身需求修改工具和执行流程。但同样的自由也意味着，API Key、模型费用、接口兼容、连接器授权和故障排查，都可能需要由用户自己处理。

因此，OpenWorker 与其他 Agent 产品的差异，并不只是功能数量多少，而是它选择了不同的产品责任边界。商业办公 Agent 通过封闭的一体化服务替用户吸收复杂性，OpenWorker 则把更多选择权交还给用户，也把一部分配置和维护成本一起交了出去。

这条路线更开放，却也更难。它既要保留开源产品的可控性和可扩展性，又要让非开发者不必理解底层模型和接口，也能稳定完成任务。后续社区暴露出的模型兼容、数据流向和权限问题，正是这种产品路线必须承担的代价。

换言之，开放源码不等于交付产品。把一堆标准化的乐高积木倒在桌面上，并不能自动拼成一个能替你打工的机器人。

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

OpenWorker 开源后，不少开发者开始检查它的源码，并尝试接入不同模型和连接器。GitHub 上出现的反馈主要集中在三个方面：多模型兼容、本地数据边界，以及权限审批能否覆盖全部执行路径。

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

OpenWorker 以“模型无关”为卖点，用户可以接不同模型。但是从社区反馈来看，架构层面的可替换，并不等于使用层面的完全兼容。

有用户尝试接入自建的 OpenAI-compatible 接口。系统配置页面能够通过连接检测，但进入新会话后，依然显示没有可用模型。另有用户反馈，本地 Ollama 服务本身运行正常，OpenWorker 却无法正确加载其中的模型。

这类问题可能涉及接口格式、模型名称、能力声明或返回字段之间的差异。即便不同服务都声称兼容 OpenAI 接口，也不代表它们在模型发现、工具调用和流式输出等环节具有完全一致的行为。

（GitHub 社区网友反馈）

笔者测试自动晨报时遇到更直接的情况：模型账户额度不足，系统连续返回三次相同错误，既不自动停止，也不提示换模型或查余额。对开发者这还好排查，但作为面向普通办公用户的工具，不该要求大家先弄懂 API Key、模型名和计费额度，才知道任务为什么失败。BYOM(Bring Your Own Model,自带模型) 把模型选择的自由和排查成本一起交给了用户，门槛并没有真正消失：BYOM听起来是把自由还给用户，但实际上是把排错的灾难抛给了用户。

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

OpenWorker 还强调“本地优先”。它的 Agent 服务运行在用户设备上，会话、密钥、记忆和部分任务数据也主要保存在本地。

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

OpenWorker 使用的模型路由、工具调用、记忆、连接器和权限审批机制并不新鲜，这些能力正在成为 Agent 产品的常见组件。

吴恩达在发布 OpenWorker 时强调，它不应只是与用户聊天，而要交付文档、消息、日程等“完成的工作”。因此，OpenWorker 真正想解决的，正是如何把这些能力组合成一套可以直接使用的工作系统。

这也体现了 OpenWorker 背后的产品理念：降低 Agent 的使用和开发门槛，同时把模型选择权与数据控制权留给用户。它允许用户自行选择云端模型、开放权重模型或本地模型，重要操作还需经过用户审批。对于用户，它提供了封闭办公 Agent 之外的另一种选择；对于开发者，它也是一份可以检查、修改和继续扩展的开源参考实现。

但开放并不会自动消除复杂性。封闭产品由厂商统一处理模型、账号、计费和兼容问题，OpenWorker 则把更多控制权交给用户，也把 API 配置、故障排查和数据流判断的一部分责任交了出去。项目官方也明确将其定义为公开测试版本，并承认仍在处理产品中的粗糙环节。

因此，OpenWorker 的优点和缺点来自同一个选择：开放让它更自由、更透明，也让它更难做到开箱即用。它没有发明新的 Agent 范式，但进行了一次更有现实意义的尝试——把已经逐渐标准化的 Agent 组件装进桌面产品。接下来真正决定它能否成立的，不是还能增加多少模型和连接器，而是能否把兼容、错误恢复、数据披露和权限控制一并做成用户不需要理解的基础能力。

某种意义上，吴恩达的 OpenWorker 的粗糙反映出的，不仅是吴恩达等一众顶尖 AI 学者在走向商业化时经常陷入的“科学家魔咒”，更是当下整个 Agent 赛道的集体尴尬：在指望 Agent 真正‘替人上班’之前，这些 Agent 们自己还得先上个班，学会如何成长为一个成熟的‘产品’。