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

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

美国时间7月23日，AI领域的两位重磅人物——吴恩达与Rohit Prasad，在X上联手发布了一款开源的桌面Agent：OpenWorker。按理说，顶流学者背书、开箱即用的桌面形态、模型自由切换，这配置几乎集齐了所有爆款要素。那么，这款产品的实际体验到底如何？

（OpenWorker 生成的 AI 新闻简报）

上图是OpenWorker生成的过去24小时AI新闻简报。从产品形态上看，它已经将过去需要代码配置的Agent工作流，压缩成了一个可以直接操作的桌面应用。然而上线一周后，社区的真实反馈却泼了一盆冷水：

作为一个刚刚开源的桌面Agent，它不仅展示了这类产品正在形成的基本结构，

01

OpenWorker 的架构与工作流程

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

最上层是

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

桌面界面之下，是运行在

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

再向外，则是

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

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

(OpenWorker 工作流程图)

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

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

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

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

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

02

与现有 Agent 相比，OpenWorker 有什么不同？

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

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

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

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

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，自带模型）把模型选择的自由和排查成本一起交给了用户，门槛并没有真正消失：

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

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

相关数据大致分为三类：

• 保存在本机的会话、密钥和任务数据；
• 登录云账户后可能发送给官方服务的使用元数据；
• 调用云模型和 Slack、邮箱、Notion 等连接器时，需要发送给第三方服务的数据。

（GitHub 社区网友反馈）

社区真正关注的是，OpenWorker 项目是否足够清晰地告诉用户：不同数据在不同配置下会保存在什么位置、发送给哪些服务，以及用户能否关闭或替换相应的数据路径。

对于桌面 Agent 来说，“本地优先”只能说明默认架构倾向，不能替代完整的数据流说明。

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

OpenWorker 为写文件、运行命令和修改外部系统等操作设计了审批机制。但社区报告指出，某些配置文件可能在用户尚未信任工作区时，就启动其中定义的外部服务进程。

目前，这一问题主要来自社区报告和复现讨论，并不代表已经发生大规模攻击，也不能直接证明所有版本均受影响。但它揭示了桌面 Agent 的一个普遍风险：权限控制不能只覆盖模型主动调用工具的主流程，还要覆盖配置解析、插件加载、连接器初始化和后台进程启动等旁路。

对于能够访问本地文件、命令行和外部账号的 Agent 来说，真正重要的，是所有执行路径是否都经过统一的授权、记录和限制。

04

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

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

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

它允许用户自行选择云端模型、开放权重模型或本地模型，重要操作还需经过用户审批。对于用户，它提供了封闭办公 Agent 之外的另一种选择；对于开发者，它也是一份可以检查、修改和继续扩展的开源参考实现。

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

因此，OpenWorker 的优点和缺点来自同一个选择：

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

某种意义上，OpenWorker 的粗糙反映出的，不仅是吴恩达等一众顶尖 AI 学者在走向商业化时经常陷入的“科学家魔咒”，更是当下整个 Agent 赛道的集体尴尬：