OpenWorker：AI办公助手的harness工程与国产模型支持

今年年中，两款主打“直接交付工作成果”的AI办公工具先后亮相：5月海外推出的办公助手与7月开源的AI工作搭档，不约而同打出了“不止聊天，直接交活”的产品理念。其中吴恩达团队推出的OpenWorker上线不到两个月，就在GitHub收获超11400枚星标与1500余次复刻，成为AI代理领域的热门项目。

OpenWorker的核心能力与设计逻辑

简单来说，这是一款可以部署在本地的开源AI办公同事。用户只需要提出需求，比如“帮我准备Northwind客户的续约电话会简报”，它就能自动调取HubSpot的客户记录、过往邮件线程等数据，最终生成一份带有数据图表的完整HTML简报——而非仅仅列出待办事项的草稿。

它的核心设计有四个关键特点：

1. 直接交付成品而非聊天交互：无论是文档、表格、报告还是网页，都会以完整文件的形式保存到本地磁盘，甚至支持在协作工具中直接@它，任务在本地完成后以标准化形式反馈结果。

2. 模型自由选择，自主掌控密钥：用户可以使用自己的API密钥调用任意模型，不仅支持主流厂商的产品，还直接兼容国内多款主流模型，甚至可以通过本地工具实现完全离线运行，无需依赖云端服务。

3. 丰富的工具集成与权限管控：内置官方连接器，同时支持通用协议的任意工具，覆盖日常办公常用的各类平台，每个工具的访问权限都可以单独配置开关。

4. 严格的操作审批机制：所有涉及操作风险的任务，比如发送邮件、修改日历安排、执行系统命令等，都需要经过用户手动确认后才能执行，确保操作安全可控。

底层架构：兼顾安全与灵活的工程设计

通过分析项目的Python后端源码可以发现，这款工具的架构设计非常注重数据主权与工程规范：

代理只是表层形式：项目中定义了多种类型的助手，其中协作助手仅包含四项核心能力，依靠任务编排实现复杂功能，而非依赖单一模型的能力。

内置工程纪律约束：系统提示词中明确要求，执行任务前必须先生成任务计划，让用户可以通过进度面板查看实时进展；同时禁止在系统终端中直接粘贴多行脚本，必须先将脚本写入文件再执行，确保操作可追溯、审批提示清晰简洁，最终交付的文件都会以可直接访问的链接形式提供。

审批是引擎级功能：每个工具都带有风险等级和审批要求的元数据，高危操作需要强制审批，普通只读操作则可以直接放行。当执行到高危工具时，任务会暂停等待用户确认。

兼容现有技能体系：技能模块直接复用行业标准格式，支持结构化元数据与可扩展内容，并且采用渐进式披露的加载方式，用户在其他平台积累的技能包可以直接迁移使用。

预留沙箱扩展接口：系统操作基于抽象层实现，当前版本使用本地持久化终端，可以跨命令保留配置信息，注释中明确提到这是为未来的容器化、虚拟化执行环境预留的接口，当前的本地直连只是过渡方案，后续将支持更安全的隔离运行环境。

两款产品的路线差异

两款产品看似理念一致，但实际走了完全不同的路线：一款主打全场景生态整合，依靠平台优势实现深度的办公工具联动；另一款则选择开放自托管的模式，将数据控制权和使用信任作为核心卖点，更适合注重数据隐私和自定义能力的用户。

最后

不要仅仅关注OpenWorker本身，项目README中的一句话才是核心：“如果你想搭建自己的AI代理框架而非使用我们的产品，就从aisuite开始”。OpenWorker其实是aisuite的演示样板，团队通过这个项目向开发者传递了一个明确的信号：AI代理的核心竞争力不再是模型本身，而是工具连接、审批流程、任务编排、权限控制这一套工程化框架。随着AI模型的逐渐商品化，谁能提供更完善、更安全、更灵活的代理框架，谁就能在这场AI办公革命中占据先机。

https://github.com/andrewyng/openworker
https://medium.com/@sudarshan-koirala/openworker-andrew-ngs-open-source-ai-coworker-that-delivers-finished-work-84509e57330c