AI 参与说明（Agent：Codex）：本文由 Codex 根据 OpenAI、飞书和腾讯的官方资料协助调研、整理与校验，资料整理于 2026-10-07。跨产品概念归纳与任务示例是本文分析，不代表统一行业标准或产品完成率实测。运行记录：模型
gpt-6.1-sol，reasoning effortultra，执行入口 Codex Desktop，提供方openai，运行记录中的 CLI 版本0.162.0-alpha.2（不代表桌面 App 版本）。
这些产品中的 Work，可以理解为一种围绕工作目标组织 Agent 的产品体验：用户提供目标、资料和完成标准，系统推进多个步骤，最后交付能继续使用和修改的成果。重点从“这一轮回答得怎么样”，扩展到“这件事情完成得怎么样”。
阅读前先看这几个词
下面的名称用于区分产品入口、执行者、工作范围与成果；中文名称只作为导读对照。
| 英文术语 | 中文名称 | 简要解释 |
|---|---|---|
| Chat | 对话 | 通过消息交流问题、要求与反馈的交互方式。 |
| Work | 工作 | 产品围绕目标组织执行与交付的入口或体验；具体含义由各产品定义。 |
| Agent | 智能体 | 根据目标与当前结果选择下一步，并使用可用工具的软件系统。 |
| Task | 任务 | 一次需要推进和验收的具体工作。 |
| Workspace | 工作空间 | 组织相关资料、工具、规则与成果的范围；各产品实现不同。 |
| Artifact | 产物 | 可检查、修改或继续使用的文件、页面、图表等成果。 |
Work 改变了什么
从三家的官方描述可以归纳出一个共同方向：把一个完整目标交给 Agent，减少用户亲自衔接每个步骤的负担。这是一种产品定位与工作方式，不宜仅凭 Work 这个名称判断底层模型、权限或可靠性。
| 比较维度 | 以问答为主的使用方式 | 以 Work 为主的使用方式 |
|---|---|---|
| 用户输入 | 一个问题或一段需要生成的内容 | 最终目标、输入资料、限制与完成标准 |
| 系统推进 | 回答当前问题，再等待下一条指令 | 拆解步骤、使用工具、检查结果并继续执行 |
| 主要成果 | 对话中的解释或建议 | 文件、分析结果、页面、代码变更等 Artifact |
| 用户反馈 | 继续提问或要求重写回答 | 检查具体成果、补充约束并要求局部修改 |
| 工作组织 | 消息历史 | 消息加上资料、进度、执行环境与 Artifact |
这里比较的是使用重心。Chat 也可以搜索、处理文件和调用工具，Work 同样使用对话接收反馈；两者的区别不能只用“有没有工具”来判断。
例如，“怎样分析销售数据？”通常是在索取方法；“读取这些销售文件，按指定口径计算指标，生成图表和分析报告，核对总数后交付”是在委托一个 Task。后者仍需要交流，但交流服务于一个可验收的结果。
下面是本文整理的通用流程，用于解释这种工作方式，并非三家产品内部架构的逐步还原：
flowchart TB
A["用户定义 Task<br/>目标、资料、完成标准"] --> B["Agent 规划步骤"]
B --> C["在授权范围内<br/>读取资料与使用工具"]
C --> D["检查结果<br/>决定下一步"]
D -->|满足完成标准| E["交付 Artifact<br/>用户验收并提出修改"]图中展示交付主线。检查后仍需执行时，Agent 继续规划和使用工具；缺少资料或授权时，需要用户补充信息或作出决定，再推进 Task。
三个产品各自怎样使用这个概念
Codex 与 ChatGPT Work：共享机制，分别组织使用体验
ChatGPT Work supports longer, multi-step tasks using available sources and approved tools, and returns outputs for review. Work and Codex share core execution, isolation, and permission mechanisms. 这是对官方文档的转述。OpenAI：Work admin FAQ、ChatGPT Work Overview
因此，在相关客户端中看到 Work，可以把它理解为通用工作任务的入口：研究、分析、办公文件和跨工具操作都可以成为交付目标。它与 Codex 有共同的执行基础，不能把界面上多出一个入口直接等同于换了一个新模型。
Codex 也已扩展到不依赖代码仓库的 Chat、文件预览、浏览器和其他工具工作流，场景之间有重叠。具体入口与可用能力取决于当前版本和账户配置。OpenAI：Features
豆包工作：把个人任务与飞书协作接起来
飞书将“豆包工作”定义为面向个人、团队和企业的智能体工作平台。它围绕目标读取资料、使用工具，交付文档、表格、PPT 等可继续修改的成果，并在授权范围内接入飞书资料与协作能力。飞书：豆包工作全新发布
官方列出的入口包括独立 PC 客户端、豆包内的工作入口和飞书内入口；各入口的开放范围与功能并不完全一致。这说明“豆包工作”既是正式产品名称，也体现了从单次内容生成扩展到完整 Task 的方向。
WorkBuddy：把自然语言任务变成可验收的工作结果
腾讯将 WorkBuddy 定位为覆盖办公、代码开发和设计创意的 AI 工作台。官方强调自主规划、多步骤工具执行，以及在授权目录内读写文件和交付成果。腾讯：WorkBuddy
它的“办公”范围包含开发和设计。理解其定位时，更适合关注能否把资料处理、执行和成果交付串起来，而不只看能否生成某一种文件。
Work 与本地、云端是不同的维度
Work 描述怎样组织工作；本地与云端描述执行环境。看到 Work，并不能据此推断关掉电脑后 Task 仍会继续，也不能推断它可以直接读取本机资料。
- ChatGPT Work：使用本机资源的步骤需要获准且在线的连接电脑；云端环境不会自动继承本机文件、应用或浏览器登录状态。本地执行也不等于模型推理、对话和上下文只留在本机。OpenAI：ChatGPT Work Overview
- WorkBuddy Enterprise：官方区分本地任务与云端任务。本地任务需要电脑开机且客户端在线；云端任务在隔离沙箱中执行，可使用云端资料和上传文件，无需保持本机开机。这里的执行位置与 AI 推理位置也需分别理解。腾讯：项目／选择任务模式
选择环境时，先确认资料在哪、工具在哪、成果存在哪，再判断能否离开电脑。跨设备接续、定时执行和长期后台运行，还需要对应的产品能力与配置，不能从名称推导出来。
怎样把问题写成适合 Work 的 Task
可以从一个小而可检查的任务开始。下面的 CSV 是虚构数据，保存为 sales.csv 或通过产品支持的文件入口提供：
region,amount
Beijing,100
Beijing,150
Shanghai,80
Shanghai,120
给 Agent 的要求应包含目标、资料范围、交付物和验收方式。下面是可复用的 Prompt，不是产品专用命令：
Use only the attached sales.csv. Create sales-summary.xlsx with the original
data and a regional summary, including formulas and a bar chart.
Create analysis.md explaining the calculation and the final totals.
Keep the original file unchanged. Do not fetch external data or share files.
Verify that all four input rows are included and that the regional totals
add up to the grand total. Report any tool or file-format limitation.
验收时，北京合计应为 250，上海为 200，总计为 450；工作簿应包含 4 行原始数据，公式和图表应引用正确区域，analysis.md 应说明计算口径。仅收到“已完成”的消息不足以验收，还要打开文件检查。如果当前环境无法生成指定格式，应让 Agent 明确说明，并由用户决定是否接受替代成果。
这个例子用于设计可复查的 Task，没有对三家产品逐一实测。更复杂的工作仍遵循同样原则：把“帮我做得好一点”改成可以观察和检查的条件。比如把输入中的上海 120 改为 130 后，上海合计应变为 210，总计变为 460，图表与说明也应同步更新。
判断一个 Work 产品的实际价值
比名称更有用的是检查四个问题：能否接入所需资料与工具；能否处理多步骤中的失败与缺项；是否交付可编辑、可检查的 Artifact；是否支持按反馈继续修改。
本文的判断是：这轮 Work 概念体现了 Agent 产品从回答与建议，扩展到执行与交付，也让原本偏开发的工具进入研究、办公和创作场景。它增加的是一套围绕 Task 的工作体验；能否可靠完成具体工作，仍要看实际执行和成果验收。
关联阅读
- Agent 工程实践导航。
- Agent 开发中的测试方法：Specification、Test Oracle 与验证证据：为什么完成报告需要实际结果支撑。
- Matt Pocock Skills：从需求澄清到工程交付的 Agent 工作流：把目标、执行方法与验收衔接起来。