理解 ChatGPT Work
原文由 Simon Willison 于 发布,订阅该博客
OpenAI 于 7 月 9 日发布了 ChatGPT Work,此后一直在对其进行密集迭代。这是一款极其令人困惑、但又非常强大的产品。以下是我目前摸索出的情况。
ChatGPT Work 其实是两款产品
ChatGPT Work 更有意思的版本是运行在云端的那一版。你可以通过 chatgpt.com 或 ChatGPT 手机应用来访问它。我们姑且称之为 Work Cloud。
如果你安装了 ChatGPT 桌面应用——也就是过去叫 Codex 的那个应用——你就能用到一个名为 ChatGPT Work 的功能,它可以直接访问你电脑上的文件并运行程序。我们姑且称之为 Work Local。这一版感觉更像是给普通的 Codex 换了个皮,让非软件开发者不那么望而生畏。
(更新:Work Cloud 在 ChatGPT 桌面应用中也能使用,通过“Where should this chat run?”(这次对话在哪里运行?)下拉菜单。)
本文余下部分将只讨论 Work Cloud。
Work 仅面向付费订阅用户
目前,两种形态的 ChatGPT Work 都仅向 20 美元/月及以上的订阅用户开放。免费用户和 8 美元/月的 Go 用户无法使用。
Work 拥有 Chat 所不具备的功能
访问 Work 的入口是一个标签页切换器,它把 Work 呈现为 Chat 的替代选项:

一个显而易见的问题是:什么时候该用 Chat,什么时候该用 Work?
OpenAI 对这个问题的官方说法是:
当你想要一个答案、解释、头脑风暴或简短草稿时,使用 Chat。当你希望 ChatGPT 完成一项有明确成果的任务时,使用 ChatGPT Work,例如简报、演示文稿、分析、定期更新、工作流或可供你审阅和使用的文件。
我觉得这个说法几乎毫无用处,因为这些类型的任务我多年来一直都是用普通的 ChatGPT Chat 来完成的!
那么,更好的问题是:Work 相比 Chat 多了哪些功能?
经过大量尝试,我想我已经基本搞清楚了:
- 可选用 Luna 和 Terra 替代 Sol
- 具备联网能力的代码执行环境
- 无头 Chrome 浏览器
- 跨会话共享的持久化文件系统
- 发布 ChatGPT Sites 的能力
- 使用 Sol、Luna 和 Terra 运行子代理会话的能力
- 定时提示词自动化(ChatGPT Chat 可能也有)
模型选择
在 Work 中,你可以选择 GPT-5.6 的 Sol、Luna 或 Terra,每个模型都提供 Light、Medium、High、Extra High、Max 或 Ultra 推理级别。你还可以选择 GPT-5.5 的 Light、Medium、High 或 Extra High。
这些看起来和通过 OpenAI API 提供的模型是同一批。
Chat 提供的则是另一套选项:5.6 Instant、Medium、High、Extra High 和 Pro(实际上 Extra High 和 Pro 仅面向 100 美元/月及以上的订阅用户——20 美元/月的订阅用户最高只能用到 High)。它并没有说明这些到底是 Luna、Terra 还是 Sol(我猜是 Sol?)。5.6 Pro 似乎是 Chat 独有的,Work 中没有对应的版本。
根据我使用 Codex 的经验,Ultra 是一种会更积极地将任务委派给子代理的特殊模式。
我认为 ChatGPT Work 会话会计入你的 Codex 额度,而 ChatGPT Chat 会话则有各自独立的额度。这或许可以解释两者在模型可用性上的差异。
具备联网能力的代码执行!
作为代码解释器(Code Interpreter)模式的长期爱好者——该模式由 OpenAI 在 2023 年率先推出——这对我来说是 ChatGPT Work(Cloud)迄今为止最令人兴奋的功能。
代码执行环境现在可以与整个互联网通信了!
ChatGPT Chat 做不到这一点——如果你让它安装额外的软件包或与网站、API 交互,访问请求会被容器代理拦截。
(奇怪的是,早在 1 月它还新增了安装软件包的能力,但现在似乎又不行了。真希望他们能提供更完善的更新日志!)
Claude 的同类容器自去年 9 月上线以来就允许受限的互联网访问。Claude 可以从 PYPI 和 NPM 安装软件包、从 GitHub 克隆仓库。但也就仅此而已:域名白名单非常短。
ChatGPT Work 允许的范围要大得多。它可以配置为仅允许特定域名列表,但默认似乎对所有域名开放。
这让 Work 成了一个极其有用的工具。你可以让它克隆 GitHub 仓库、安装依赖,然后利用它们与整个网络进行交互!
完整的无头 Chrome 浏览器
ChatGPT Work 的另一个杀手级功能是浏览器工具。ChatGPT Work 可以启动一个完整的 Chrome 实例,加载网页、填写表单并截图。

如果网站需要登录,浏览器会提示你接管操作,自行输入密码和两步验证码,而无需让这些凭证经过模型本身。
它甚至可以直接对已加载页面的 DOM 执行 JavaScript。我输入了这样的提示词:
Load simonwillison.net in your browser and extract the headings using JavaScript
ChatGPT Work 随即启动了一个浏览器实例并运行了如下代码:
await tab.playwright.evaluate(() => {
return Array.from(document.querySelectorAll("h1,h2,h3,h4,h5,h6"), heading => ({
level: heading.tagName.toLowerCase(),
text: heading.innerText.trim().replace(/\s+/g, " "),
id: heading.id || null
}));
});这感觉很像我的shot-scraper javascript 工具,只不过现在我可以在手机上使用它了!
持久化、共享的文件系统
ChatGPT Chat 的每个对话都会获得一个全新的文件系统,其他任何会话都无法访问其中的文件。
在 ChatGPT Work 中,每个会话都会获得自己的临时文件夹——命名类似 /workspace/scratch/e00a0a017944——但这些文件夹会在会话之间持久保存,因此你可以访问之前对话中的文件。我现在在 /workspace/scratch 里就有 171 个文件夹!
据我观察,/workspace 这个存储卷会被挂载到所有正在运行的 Work 会话上——在一个会话中对文件的修改会立刻被其他会话看到。不过,它们似乎并不共享同一个进程空间,在一个会话中运行的 localhost 服务也无法从另一个会话中访问。
ChatGPT Sites
ChatGPT Work 能够使用 Cloudflare Workers 构建并部署完整的网站。这些网站可以包含 HTML 和 JavaScript,还能运行服务端功能,包括基于 Cloudflare D1 和 R2 的有状态功能。
这是我用这个功能搭建的一个简单网站:
london-pelicans-in-her-piety.simonw.chatgpt.site

我的提示词是:
Figure out all of the places in London with a pelican in her piety, then turn that into a JSON file and build a ChatGPT sites site about them
(pelican in her piety(慈爱鹈鹕)是中世纪基督教图像学中一个迷人的意象——一旦你了解它,就会发现它无处不在。)
这些网站默认仅对创建者可见,但你可以将其设为公开,并在团队方案中与特定成员共享。
使用 Sol、Luna 和 Terra 的子代理
关于这一点没什么太多可说的。ChatGPT Chat 无法运行子代理,而 ChatGPT Work 可以。这完全是一个面向高级用户的功能:如果你正在运行一个可以通过多个并行代理协作来获益的复杂项目,Work 就能做到。
定时提示词自动化
这似乎是另一个在某个时间点从常规 ChatGPT 迁移到 ChatGPT Work 的功能。你可以这样向 ChatGPT Work 发出指令:
run a search to see if Waymo have announced a launch date for Half Moon Bay every day at 8am
这会按此频率定时执行该提示词。这些任务可以自行判断是否无事发生,也可以决定向你推送新的信息。
更新:实际上,这在 ChatGPT Chat 中似乎也能用。
不过这里仍然值得一提,因为它可以与其他 ChatGPT Work 独有功能结合使用。例如,你可以设置一个定时任务,每小时更新一次 ChatGPT Site。
这样安全吗?
目前对我来说,一个悬而未决的问题是:所有这些功能到底有多安全。
我的致命三要素(lethal trifecta)模型警告说,任何同时具备访问私有数据、接触不可信内容以及能将窃取的信息传回给攻击者这三项能力的代理系统,都存在固有风险。
而 ChatGPT Work 恰好三者兼具!
我很想听听 OpenAI 会如何说明他们保护 ChatGPT Work 会话免受提示词注入攻击。我猜他们的答案会和 Codex 一样,是那套自动审查机制。
OpenAI 完全可以让这一切不那么令人困惑
要搞清楚这些,本不该花这么多工夫。
我认为这里有两个关键问题:
- OpenAI 总是从“它是用来做什么的”来解释 Work,而不是说明“它实际上能做什么”
- OpenAI 仍然坚持隐藏其系统提示词和工具描述
如果 ChatGPT Work 的文档中包含了代理所使用的确切系统提示词和工具描述,我就根本不需要写这篇文章了。
所有工具一览
发布这篇文章后不久,我有了一个想法。我开启了一个全新的 Work 会话,并输入了如下提示词:
Build a site that lists every one of your tools - nearly grouped into categories - and for each one explain what it does. Try to exactly duplicate arguments and tool descriptions where possible. Design aesthetic should be technical docs, minimal flare
这是它搭建的网站,其中列出了 223 个已注册工具的详情——不过其中有 6 个来自我通过datasette-mcp 提供的个人 MCP。
还有一大堆 Skills
我注意到列表中与浏览器相关的工具只有一个web.run,它提供了执行搜索、打开 URL 和点击链接等方法,但就无头浏览器自动化而言,这看起来并不完整。
这让我怀疑还有遗漏,于是我对那个构建了工具参考网站的 ChatGPT Work 会话说:
Add full copies of every skill to the website (separate pages linked to from the homepage)
结果发现 ChatGPT Work 使用了大量的 skills——足足有 44 个!
control-browser 这个 skill 解释了浏览器的工作原理:
通过 Node REPL 的
js工具运行浏览器初始化代码。在此环境中,可调用的工具 ID 通常显示为mcp__node_repl__js。[...]与浏览器直接交互的能力是通过
browser-client运行时的agent.browsers.*API 暴露的。在尝试与之交互之前,你必须一次性输出并读取await browser.documentation()返回的完整文档。
于是我告诉 Work:
Add the full output of await browser.documentation() to the bottom of the /skills/control-browser page
现在你也可以在/skills/control-browser 上读到它了。
还有几个有趣的 Skills:
- documents 用于创建
.docx文件 - imagegen 包含使用
image_gen工具创建图像的技巧 - pdf 用于读取和渲染 PDF
- Spreadsheets 用于处理
.xlsx、.xls、.csv、.tsv - sites:sites-building 用于创建 ChatGPT Sites
- openai-docs 用于回答关于其自身的问题
- data-analytics:build-dashboard 用于构建数据看板
随机一篇博客
评论
登录后参与讨论