OpenWorker：吴恩达的开源 AI 智能体
OpenWorker 是吴恩达推出的开源、本地优先智能体框架，能规划工作流、调度云端与本地模型，并在高风险步骤前要求人工审批。
如果你希望 AI 系统真正把工作做完，而不只是回答提示词，那么 OpenWorker 的核心思路一句话就能说清：它规划任务、调用工具，并在高风险操作前停下来等待审批。
我会这样总结：OpenWorker 是一个开源、本地优先的智能体框架，通过一个桌面应用和一个本地 Python 服务器运行，在云端与本地模型之间调度任务，并用 4 个权限级别来控制文件访问、命令执行和对外消息发送。它适合那些希望更严格掌控数据、降低跨模型接入门槛，并在任何高风险动作发生前有明确人工审查的团队。
简短版本如下：
- 它做什么： 把一个目标转化为多步骤工作流
- 它如何运行： Tauri 2 桌面应用 + React 18 界面 + 本地 FastAPI/Uvicorn 服务器
- 模型接入： 通过
aisuite接入云端厂商和本地模型，并借助 Ollama 实现本地使用 - 安全模型：
read、write_local、exec和external - 人工审查： 每一个
exec和external步骤都要等待审批 - 可连接的工具： 文件、日历、Slack 以及其他团队系统
- 模型端点选项： 通过单一 OpenAI 兼容 API 接入 APIMart
- 最适合的工作： 报告、调研、内容套件、支持任务和媒体流水线
- 生产环境需求： 追踪、评测、提示词版本管理、开支跟踪，以及一套 outbox 审查流程
有几个事实很突出。OpenWorker 使用 4 种动作类型，在有人审批之前会拦截 100% 的 exec 和 external 动作，并且可以在 GPT-5、Claude Sonnet 4.6 和 Gemini 3 Pro Preview 等模型之间切换，而无需改动工作流逻辑。
| 方面 | 我会快速了解的要点 |
|---|---|
| 核心用途 | 目标到成果的智能体系统 |
| 本地部署 | 桌面应用 + localhost 服务器 |
| 风险控制 | 对高风险动作设置审批闸门 |
| 模型调度 | 云端 + 本地 LLM |
| 团队用例 | 运营、内容、调研、支持、媒体 |
| 生产侧重点 | 日志、测试、开支上限、审计 |
如果要判断它是否适合我的团队，我会先看一件事：我是否有步骤清晰、可重复的工作，并且需要在高风险动作上进行人工审批？ 如果是，那么 OpenWorker 就很合适。
吴恩达：AI 智能体现状 | LangChain Interrupt
OpenWorker 如何运作：架构、模型与权限
OpenWorker 的可靠性来自三个层次：本地执行、模型调度和审批闸门。
桌面应用与本地智能体服务器
OpenWorker 作为一个 Tauri 2 桌面应用运行，配有 React 18 界面，并搭配一个使用 FastAPI 和 Uvicorn 的本地 Python 3.10+ 服务器。用大白话说，你在桌面上看到的应用与运行在你机器上的本地服务器并肩工作。
这样的架构让智能体既靠近数据，也靠近用户。从控制角度看它也更严密，因为服务器默认只监听 localhost。
跨云端与本地 LLM 的模型调度
OpenWorker 使用 aisuite 在云端模型厂商与 Ollama 等本地运行时之间调度请求。这让团队可以自行决定每个任务该走哪条路径，而不是把所有请求都塞进同一条通道。
举例来说，团队可以把私密任务留在本地，把风险较低的工作调度到别处。如果数据敏感，任务可以通过 Ollama 发送到本地模型。
任务规划、类型化动作与审批闸门
当你给 OpenWorker 一个目标时，它会把这个目标拆分成一个个离散步骤，并在任何操作运行前为每个动作分配一个权限类型。因此你得到的不是一个大黑箱，而是一系列可以被检查和审查的步骤。
四种权限类型直接对应风险级别：
| 权限 | 允许的操作 | 风险级别 |
|---|---|---|
read | 查看本地文件或数据 | 低 |
write_local | 在机器上修改或创建文件 | 中 |
exec | 运行终端命令或脚本 | 高 |
external | 向 Slack、邮件或其他系统发送数据 | 高 |
审批闸门会拦截每一个 exec 和 external 动作，直到有人审批为止。正是这种控制模型，让下一层集成变得切实可行。
工具、集成与由 APIMart 驱动的模型接入
在文件、日历、Slack 与团队系统之间协作
OpenWorker 通过内置工具、托管集成和连接器连接到本地文件、日历、Slack 以及其他团队系统。[4] 这让它不仅能处理一次性任务，还能自动化各类互联工作。
来看看实际中它是什么样子。一个运营团队请 OpenWorker 准备每周绩效报告并分享给团队。智能体读取本地的分析导出数据，在共享文件夹里整理出一份精美文档，起草一段包含关键指标的 Slack 摘要，然后停下来，在向团队外部发送任何内容之前请求审批。[4] OpenWorker 负责协调，最终发出去什么仍由人来决定。
内容和市场团队可以用同样的架构来制作内容套件。OpenWorker 可以从本地文件中提取原始调研资料，起草一份简报或博客文档，并在团队日历上标注审查截止时间——在有人签字确认之前，全程都不触碰外部系统。[4]
用 APIMart 作为统一模型端点
工具连接好之后，下一步就是模型接入。OpenWorker 可以通过单一的 OpenAI 兼容基础 URL，把 APIMart 用作统一模型端点。[2][3]
配置相当简单：
- 创建一个 APIMart API 密钥
- 为聊天、补全和媒体请求发送标准的 OpenAI 兼容 JSON 负载
在 OpenWorker 看来，APIMart 就像一个稳定的单一厂商。但在这个统一端点背后，团队可以在 GPT-5、Claude Sonnet 4.6 或 Gemini 3 Pro Preview 等模型之间切换，而完全不必改动智能体工作流。这意味着只需一层调度，团队所用各模型的维护成本也随之降低。
面向内容与媒体团队的多模态工作流
同样的调度架构也支持文本之外的多模态工作。借助 APIMart，OpenWorker 可以通过一个端点，从调研走到脚本，再到视频生成。[1]
对于每周制作视频内容的团队，OpenWorker 可以协调整条流水线——调研、编写脚本、素材生成和审查暂存——而 APIMart 在后台负责模型选择。工作流保持不变，改变的只有模型。
在生产环境中可靠地运行 OpenWorker
生产环境的使用需要在模型、任务和团队之间实现追踪、控制和成本可见性。在已经就位的权限与模型调度之上，本节讨论让这些基础在实践中发挥作用的运维层。下一步就是把这套架构变成你在生产中可以观测、审计和控制的东西。
追踪、评测与提示词版本管理
生产可靠性始于对每次运行每个步骤的可见性。
每次智能体运行都应记录完整的运行状态：对话状态、工具输入输出、使用了哪个模型、token 计数以及每步的延迟。没有这些，调试就会变成猜谜。有了它们，你就能准确看到工作流在哪里失败，并在不影响其余部分的情况下修复那一环。
提示词版本管理同样重要。当团队更新系统提示词以提升输出质量时，总有可能破坏原本正常工作的东西。对每次提示词变更运行 golden 测试——一小组已知良好的输入以及期望输出——有助于在这些问题进入生产之前捕获回归。golden 测试能在部署前捕获提示词回归。
| 特性 | 无追踪 | 有追踪 |
|---|---|---|
| 可见性 | 对具体失败点和成本激增一无所知 | 对延迟、token 和错误率有细粒度视图 |
| 调试速度 | 慢；需要手动复现智能体状态 | 快；日志提供完整的对话与工具状态 |
| 可靠性 | 提示词更新期间回归风险高 | 高；golden 测试在 CI/CD 中捕获质量下降 |
| 成本控制 | 被动；只在账单周期结束时才发现 | 主动；按任务的偏移触发告警 |
面向敏感动作的风险控制与人工监督
当智能体可以影响共享系统时，执行需要一个可审查的交接环节。
对于敏感动作，使用 outbox 模式：智能体在执行前先把打算做的动作记录下来以供审查。[5] 这非常适合共享系统，因为人工审查应当发生在执行之前，而不是在造成损害之后。
这直接对应前面设置的 exec 和 external 权限类型——outbox 模式管控着这些较高风险动作的最终交接。在更复杂的多智能体架构中，围绕 inbox/、outbox/ 和 workspace/ 目录构建的文件夹结构能保持数据边界清晰、交接可预测。[5] 每个智能体都知道从哪里读取、往哪里写入，这让整条流水线更易审计。
借助 APIMart 调度进行成本与模型管理
工作流一旦运行起来，成本控制就成了运维上的硬性要求。
以 APIMart 作为中心端点，团队可以在一个地方跟踪开支、设置价格上限并监控延迟。如果你已经在运行多模型工作流，集中式调度能削减为每个厂商分别管理密钥、SDK 和仪表盘的额外负担。
| 指标 | 直连密钥 | APIMart 统一端点 |
|---|---|---|
| 配置工作量 | 高；多套 SDK 和认证流程 | 低；一个 OpenAI 兼容客户端 |
| 可观测性 | 分散在多个仪表盘上 | 集中式；所有模态一个视图 |
| 成本控制 | 各厂商手动设置上限 | 集中式价格上限与调度规则 |
| 维护成本 | 高；每个模型都需要更新 SDK | 低；换模型只是简单改字符串 |
用直连密钥时，成本激增往往要到账单周期结束才被发现。用 APIMart 调度，团队可以在工作流演变成一笔昂贵麻烦之前，就设置好价格上限和调度规则。
实用用例与结语
调研、内容运营与媒体工作流
工作流控制一旦搭建完毕，OpenWorker 往往在重复、高频的工作中大放异彩。当一项任务一次又一次遵循同一套步骤时，它表现最佳。
这正是它如此契合市场、调研和媒体工作流的原因。团队可以通过协调流程的不同环节来自动化内容组装，并对照品牌标准检查最终成果。在一条流水线中，团队可以通过单一端点起草文案、生成图像并制作短视频。
这样的架构让从调研跨越到文本、图像和视频生成变得顺畅得多。团队不必手工把工具拼接起来，而是可以在一个地方跑完整条流程。
支持、运营与内部运营自动化
同样的思路也适用于内部支持和运营。OpenWorker 能做的不止是发送简单回复。它可以对订单状态查询、密码重置和账单请求等常规任务进行回答、核实并采取行动。
对团队而言，这一点很重要，因为大量内部工作并不困难，只是重复。OpenWorker 帮助推进这类工作，同时把敏感动作留在审批闸门之后。
结语：团队今天能构建什么
把这些工作流放在一起，就能看出 OpenWorker 目前最擅长的地方。它的开源设计让团队直接掌控定制、数据和成本。这套架构围绕本地优先的执行和务实的自动化构建——它把工作真正做完，而不只是开个头。
一个聪明的起步方式很简单：从一个高频、重复的工作流开始，验证价值，然后再扩展。
常见问题
OpenWorker 最适合谁？
OpenWorker 最适合那些希望把 AI 从演示推向可靠、生产就绪自动化的跨职能团队、开发者和业务部门。
它非常适合在调研、内容运营、客户支持和业务流程自动化中扩展多步骤工作流的团队——尤其是当他们希望始终掌控定制、集成和成本的时候。
OpenWorker 能把敏感数据保留在本地吗？
可以。开源智能体框架通常支持本地部署，因此开发者可以在把敏感数据保留在自有系统内部的同时，构建和测试智能体。
借助本地部署模型和基于文件的通信协议，团队可以保持严格的数据边界，并让运营保持在内部进行。
团队应该先自动化哪些任务？
从高频、基于规则的工作流开始。最佳的早期切入点是那些重复、易于衡量，并且已经与 CRM、ERP 或工单系统等系统相连的任务。
好的首批用例包括客户支持分诊和发票处理。为什么先做这些？因为它们能快速削减手工工作、降低服务成本，而无需大规模改造流程。
在此基础上，团队可以延伸到文档处理、数据抽取和内容生成。
去模型市场挑选你想要的模型
在 APIMart 模型市场尝试聊天、图像和视频模型，用统一 API 快速体验模型能力。