吴恩达开源的OpenWorker，为什么「不Work」了？
指望 Agent 替人上班之前，它们还得自己先去上个班（雷峰网 (公众号：雷峰网) ）
作者丨 李娜
编辑丨 岑峰
美国时间 7 月 23 日，人工智能领域的著名学者吴恩达与 Rohit Prasad 在 X 上正式发布了一款开源的桌面 Agent：OpenWorker。
顶流学者背书、开箱即用的桌面形态、模型自由切换……OpenWorker 几乎集齐了所有爆款的要素。那么，这款产品的实际体验如何呢？ （Open
Worker 生成的 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 则把更多选择权交还给用户，也把一部分配置和维护成本一起交了出去。
这条路线更开放，却也更难。 它既要保留开源产品的可控性和可扩展性，又要让非开发者不必理解底层模型和接口，也能稳定完成任务。后续社区暴露出的模型兼容、数据流向和权限问题，正是这种产品路线必须承担的代价。
换言之， 开放源码不等于交付产品。把一堆标准化的乐高积木倒在桌面上，并不能自动拼成一个能替你打工的机器人。