OpenAI ChatGPT 新增桌面语音控制，但仍需监督智能体

OpenAI ChatGPT 现在可在其桌面端 Work 和 Codex 体验中接收语音指令，将语音从对话功能转变为智能体控制界面。这项变化让用户无需逐条打字，即可启动任务、请求进度更新、调整工作方向，并协调多个智能体。但这项承诺也带来了一个直接的矛盾：对话的便利性并不能消除审查智能体如何使用计算机访问权限的必要性。

该功能推出前不久，OpenAI 刚刚发布 GPT-Live——其新一代全双工语音模型系列。全双工意味着模型可以同时听和说，而不是等待严格划分的对话轮次。OpenAI 最初将 GPT-Live 用于普通语音对话，如今则将语音接入 Work 和 Codex，使指令能够触发更长时间、影响更大的操作。

这让 OpenAI 置身于更广泛的计算机操作型智能体竞争之中。Google 正将计算机控制能力引入 Gemini 模型，而 Anthropic 则扩大了 Claude 对桌面工具和本地资源的访问范围。OpenAI 的差异化并不只是语音本身，而是试图将语音打造为一种实时控制层，用于管理那些会在初始请求之后继续工作的智能体。

OpenAI ChatGPT Voice 现已覆盖 Work 和 Codex

关键变化在于，语音可以启动和协调工作，而不只是给出语音回答。

OpenAI 于 2026 年 7 月 23 日宣布为 Work 和 Codex 提供桌面语音支持。该公司表示，此功能正通过 macOS 和 Windows 上的 ChatGPT 桌面应用在全球范围内推出。符合条件的 Plus、Pro、Business、Edu 和 Enterprise 账户均可使用，但须受工作区控制限制。

Work 是 OpenAI 面向研究、分析和产出成品材料的通用智能体。它可以创建文档、电子表格、演示文稿、报告和网站。Codex 是该公司的软件开发智能体，旨在检查代码库、编辑代码、运行命令、执行测试和审查变更。

新界面允许用户选择 Work 或 Codex、启用 Voice，并描述希望达成的结果。OpenAI 的桌面智能体指南称，用户可以自然地打断对话、查看实时文字记录，并要求 Voice 启动或协调任务。Voice 会继承所选体验中可用的工具和权限。

这种继承关系至关重要。语音命令并不会创建一个拥有无限访问权限的独立自动化系统。Work 和 Codex 仍会在既有的权限边界、工作区政策和确认流程内运行。如果某项工具无法通过所选体验访问文件、应用程序、网络资源或命令，语音也不会绕过这一限制。

交互可以很简单。开发者可以要求 Codex 检查一个失败的测试、识别最可能的回归问题，并提出补丁方案。智能体工作期间，开发者可以要求更新进展或缩小任务范围。产品经理则可以让 Work 分析多份研究文件、生成摘要，并围绕三个客户问题重新组织结果。

更大的承诺涉及并行工作。OpenAI 表示，Voice 可以帮助用户通过一段对话指挥多个智能体。用户可能会分别分配研究、撰写和验证任务，然后询问哪个智能体受阻。语音由此成为这些流程的监督渠道，取代原本需要反复导航和输入的操作。

这并不意味着每次语音对话都能控制计算机。OpenAI 区分了 Chat 中的 Voice 与 Work 和 Codex 中的 Voice。Chat 中的 Voice 支持自然对话和信息请求；桌面端 Work 和 Codex 体验则将口头指令连接到智能体工具和长时间运行的执行流程。

这一区别也解释了为何该功能的重要性超过又一次语音更新。语音助手多年来一直可以接受命令，但大多数命令都对应狭窄且预先设定的操作。OpenAI ChatGPT 则尝试将持续演变的对话转化为目标、约束、任务调整和工具调用。

口头请求也可能信息不足。“修好这份演示文稿”缺乏可靠执行所需的精确性。智能体仍需要上下文、成功标准和边界条件。Voice 能加快澄清过程，但无法自行让模糊指令变得精确。

OpenAI 的桌面应用结合了 Chat、Work 和 Codex，同时保留了它们各自不同的用途。桌面系统要求规定，Mac 用户需使用 macOS 14 或更高版本。该应用也可在 Windows 上使用，不过某些形式的本地计算机上下文仍具有平台特异性。

结果是，智能体交互有了新的起点。用户不再需要在工作开始前将每项任务都构造成精心撰写的提示词。他们可以讨论任务、观察进度，并随着智能体遇到新信息而调整指令。

为什么 GPT-Live 改变了智能体界面

GPT-Live 将快速的对话层，与负责深度工作的较慢模型和智能体分离开来。

OpenAI 于 2026 年 7 月 8 日推出 GPT-Live。该公司将其描述为专为持续交互设计的新一代语音模型。其最初的两个版本是 GPT-Live-1 和 GPT-Live-1 mini。

该模型的全双工架构会在生成回应的同时持续处理音频。它可以决定是否说话、继续聆听、暂停、确认用户表达、打断对话，或调用其他工具。这些决策贯穿整个交互过程，而不是只在检测到静音后才进行。

较早的语音系统通常采用分阶段流程。语音识别先将音频转换为文本，语言模型生成回答，语音系统再将答案朗读出来。每个阶段都会引入延迟，也让打断变得困难。静音常被作为轮次结束信号，因此短暂的停顿可能会触发不必要的回应。

GPT-Live 改变了这种交互模式。用户可以在思考时暂停、打断回答，或要求系统只听不答。模型可以给出简短确认，同时保持对话流畅。OpenAI 表示，它在存在背景交谈或交通噪声时的表现也更好。

自然的时机把握很有用，但对桌面智能体而言，委派架构更为重要。根据 OpenAI 的GPT-Live 概览，语音模型负责持续交互，而前沿模型负责搜索、推理或复杂工作。GPT-Live 可以在更深层的处理过程运行时保持对话活跃。

在发布时，OpenAI 指出 GPT-5.5 是用于委派工作的后台模型。该架构使 OpenAI 可以更新更深层的模型，而无需重新设计语音层。这也意味着，与用户对话的模型不一定是执行任务每个环节的组件。

这种划分形成了实用的控制闭环。语音模型收集意图并传递变更；Work 或 Codex 规划并执行任务；语音层随后报告进度，并在执行继续时接收修正。

设想一名开发者正在调试桌面应用。开发者可以描述可见的故障，要求 Codex 检查相关代码库，并在 GPT-Live 仍可接收后续指令时继续说明 bug 出现前发生的情况。Codex 可以运行测试，而 GPT-Live 则保持可用，以便接收追加指令。

同样的模式也适用于研究。用户可以要求 Work 比较多个来源、找出相互矛盾的说法，并起草简报。处理期间，用户可以增加日期限制或要求使用一手来源。交互由此成为一次动态简报会，而不是输入提示词后长时间等待。

OpenAI 表示，每周有超过 1.5 亿人使用 ChatGPT 中的 Voice 或 Dictation。该数字来自公司自身，尚未经过独立审计。即便如此，它仍显示出 OpenAI 为何将语音交互视为一种成熟行为，而不是实验性的输入方式。

据报道，OpenAI 的内部评估显示，在持续五到十分钟的匹配对话中，GPT-Live 优于 Advanced Voice Mode。该公司评估了轮次衔接、打断处理、对话流畅性和感知自然度。这些结果描述的是受控比较，并不代表多步骤计算机任务的可靠性。

这一边界值得强调。语音模型即使听起来很专注，执行智能体仍可能误解目标。对话流畅性甚至可能让错误的计划显得更可信。GPT-Live 的价值取决于系统能否将对话中的约束准确传递到智能体操作中。

ChatGPT Voice 指南也记录了一些功能限制。同一时间只能运行一个 Voice 对话。Voice 使用时长及其启动的任务可能分别消耗不同的使用额度，具体取决于账户。可用体验也会因套餐、地区、工作区和应用版本而异。

因此，从架构层面解释 GPT-Live 很直接：一个模型管理实时对话，其他模型处理更深入的推理和执行。困难之处在于跨越这一边界保留用户意图。每一次修正、例外和批准都必须以智能体能够应用的形式传达给它。

语音将智能体监督变成一场对话

OpenAI 押注于：当用户能通过对话而非反复切换界面来监督智能体时，智能体将更容易管理。

大多数智能体界面仍类似于任务表单。用户输入指令、附加上下文、启动一次运行并等待结果。如果任务偏离方向，用户就停止它，或再发送一条书面消息。这种工作流适合坐在桌前操作，但当涉及多个智能体或长时间运行的任务时就会变得笨拙。

ChatGPT voice 改变了控制界面。用户可以询问智能体正在做什么、为何选择某种方法，以及是否需要批准。之后，用户无需重新书写整条指令，就能调整工作方向。

这种交互在目标会随执行过程而发展的情况下尤其相关。研究任务可能发现某个来源已经过时；编码任务可能暴露一个未记录的依赖项；文档项目可能发现缺失的数据。Voice 提供了一种低摩擦方式，可在这些问题出现时更新计划。

这种转变更像是在监督同事，而不是操作传统语音助手。管理者通常不会在一开始就规定每一个机械步骤。管理者会描述结果、回答问题、审查中间成果，并在优先级改变时介入。

这个类比也有局限。AI 智能体不具备可信赖同事所拥有的持久情境理解、责任承担能力和判断力。它通过明确的工具和推断出的指令行动。用户仍需要清晰的记录，了解智能体改动了什么以及为何改动。

文字记录有助于保留这些记录。OpenAI 表示，用户在与 Work 或 Codex 交谈时可以查看实时文本。文字记录让用户更容易确认名称、路径、日期或技术术语是否被正确识别。当智能体的理解与用户意图不一致时，它也能提供参考。

语音可以降低表达上下文所需的精力。口头描述一个复杂的 bug，可能比撰写正式工单更快。讨论一份报告的论证过程，也能在起草前暴露薄弱的假设。用户还可以在查看代理当前输出时提供反馈。

对于知识工作者而言，这带来了一种新的分工。语音适合表达意图、确定优先级和进行纠正。屏幕依然更适合精确审阅、比较与批准。最有效的工作流会结合两者，而不是用其中一个取代另一个。

例如，研究人员可以口头请求一份简报，并让 Work 找出不同来源之间的分歧。研究人员仍会在屏幕上核查引文和证据。软件工程师则可以口头描述预期行为，然后在接受更改前审阅准确的补丁和测试输出。

这一模式也更有利于组织良好的上下文。当项目文件、约束条件和先前决策易于访问时，代理的表现会更好。个人的 AI 知识库 可以帮助人们保留这些支持性材料，但它不能取代针对具体任务的审阅。

在 macOS 上，Codex 可以使用 Appshots 将应用上下文附加到对话线程中。Appshot 会捕获所选窗口的截图和可用文本，帮助 Codex 理解用户正在查看的内容。这可以减少冗长口头描述的需要。

Appshots 并不等同于持续屏幕共享。它们只提供来自所选应用窗口的有限上下文。这一区别很重要，因为 OpenAI 表示，GPT-Live 在最初于 ChatGPT 推出时并不支持视频或屏幕共享。

访问计算机上下文还可能需要 macOS 的屏幕与音频录制权限或辅助功能权限。用户和管理员应将这些权限视为重要的安全决策。它们决定应用可以检查哪些信息，以及能够执行哪些交互。

最具吸引力的使用场景，并不是为了实现免手操作的电脑控制本身。而是在代理执行一项耗时超过单次回复的任务时，用户仍能持续参与。语音降低了检查进度和纠正方向的成本。

这可以促使用户更积极地进行监督。如果自然对话带来了过度信任，也可能产生相反的效果。只有当语音让监督更容易、又不掩盖底层操作时，这一界面才算成功。

Google 和 Anthropic 正在向同一边界施压

OpenAI 面临来自多家公司的竞争；这些公司正将模型推理能力与对软件、文件和计算机界面的直接访问结合起来。

Google 于 2026 年 6 月在 Gemini 3.5 Flash 中加入了内置的计算机使用能力。该能力让开发者能够构建可在浏览器、移动端和桌面环境中查看、推理并执行操作的代理。它可通过 Gemini API 和 Google 的企业代理平台使用。

Gemini computer use 的方案面向构建定制代理的开发者和企业。Google 强调的是可跨平台交互的模型层能力。OpenAI 的桌面语音发布则将代理控制打包进面向消费者的 ChatGPT 应用。

Google 还通过 Android 上的 Gemini 测试了多步骤任务执行。其移动端方案会在受限的虚拟窗口中运行受支持的应用，并要求用户完成敏感步骤。这一设计凸显了行业的核心问题：代理需要足够的访问权限才能行动，但不能对所有内容拥有不受限制的访问权限。

Anthropic 则从另一个方向切入桌面端。Claude Desktop 支持可将助手连接到文件、应用和系统资源的本地扩展。远程连接器可访问云服务，而本地扩展则可以使用用户计算机上的资源。

Claude desktop model 将连接器和扩展置于工具访问的核心位置。Anthropic 也在其移动应用中提供语音对话。不过，其已记录的语音体验侧重于语音交谈、规划和已连接的信息，而不是一个统一的桌面语音层来协调多个编码或工作代理。

这些差异可能会迅速缩小。计算机使用模型、连接器、语音系统和代理运行时都是模块化的。Google 可以将自然语音交互附加到桌面代理上。Anthropic 可以让语音与 Claude 的计算机工具更直接地连接。因此，OpenAI 拥有的是集成领先优势，而非永久性的技术壁垒。

Apple 和 Microsoft 也塑造着这场竞争，因为它们控制着主要的桌面操作系统。系统级助手可以获得对通知、应用和个人上下文的特权访问。第三方 AI 公司则必须申请权限，并在平台限制内运作。

OpenAI 的优势在于熟悉的 ChatGPT 界面、GPT-Live 对话、用于通用任务的 Work，以及用于软件开发的 Codex 的组合。用户无需通过 API 和工具自行组装代理，就能选择专为特定用途设计的环境。

其劣势则是复杂性。Chat、Work、Codex、Live、Advanced Voice、本地会话、云端会话、权限和工作区控制构成了多个相互重叠的概念。用户需要理解每种体验可以访问哪些资源。

Google 面向开发者的计算机使用模型提供了灵活性，但需要实施工作。Anthropic 的连接器让工具边界更清晰，但依赖于扩展的可用性和配置。OpenAI 的集成应用减少了设置工作，但也将更多能力集中在单一的对话界面之后。

企业买家不太会在意哪一种语音听起来最自然。他们会审查访问控制、审计记录、数据保留、部署选项以及审批机制的可靠性。当语音能够满足这些治理要求时，它才具有商业相关性。

开发者会评判另一组细节。他们需要准确的代码仓库上下文、清晰的差异、可复现的命令，以及任务失败时可靠的恢复能力。愉悦的语音无法弥补错误的补丁，或无法保持状态的代理。

对于日常用户而言，可发现性可能决定采用率。说话比构建自动化更容易上手。如果 OpenAI 能让从提出请求到受监督执行的过渡变得易于理解，它就能将代理工作流带给从不打开开发者控制台的人。

因此，这场竞争并不只是 OpenAI ChatGPT 与 Gemini 或 Claude 的对决。它争夺的是将工作委托给软件代理时的主导界面。语音是候选方案之一，但其成功取决于它能否保留可见性和控制权。

便利伴随着权限与准确性风险

自然的语音界面可能掩盖不确定性，因此明确的权限和可见的验证比以往更加重要。

能够使用计算机的代理可以修改文件、执行命令、访问私密材料，并与外部服务交互。这些操作比生成一段对话式回答风险更高。因此，一条被误解的语音指令可能造成超出不准确段落的后果。

语音识别也有其自身的失败模式。专有名称、文件路径、账户标识符、技术缩写和数字都可能被错误转写。背景噪声或重叠的对话可能改变被捕获的指令。实时转写有所帮助，但前提是用户会检查它。

对话上下文也可能变得模糊。“那个文件”或“上一个版本”之类的代词依赖于双方的共同注意力。如果用户和代理正在查看不同的窗口或任务状态，最终操作可能会指向错误对象。

Appshots 可以通过附加所选窗口的内容，减少 macOS 上的这种歧义。但它们无法保证代理理解每个可见元素的重要性。截图可能遗漏隐藏对话框、先前决策，或所选窗口之外的依赖项。

代理的执行计划会带来另一层不确定性。用户可能只请求某种结果，而未说明禁止的操作。代理可能选择一种高效方法，却违反未明确表达的偏好，例如替换配置文件或联系外部服务。

用户应将边界作为口头请求的一部分说明。“起草修改，但不要发送任何内容”比“处理我的电子邮件”更安全。“准备一个补丁并运行本地测试，但不要部署”则将可逆工作与有重大后果的操作区分开来。

系统也应在高影响步骤前请求确认。发送消息、进行购买、发布内容、更改账户设置或删除信息，都应保持可见的门控。语音确认可能有用，但界面应显示准确的操作和目标。

工作区管理员面临更广泛的问题。Work 和 Codex 可以继承对本地文件夹、代码仓库、终端和应用的访问权限。组织需要基于角色的控制措施，以决定谁可以使用这些能力，以及哪些环境仍不可用。

OpenAI 为 Work、Codex Local、浏览器使用和网络访问分别记录了控制措施。管理员还可以为模型和推理级别设定初始默认值。这些控制有所帮助，不过每增加一项设置，配置出错的概率也会提高。

数据保留同样值得关注。OpenAI 表示，通过桌面应用发起的本地聊天会保留在计算机上，而云端 Work 对话则可以跨平台同步。用户应在讨论敏感材料前确认自己正在使用哪种模式。

语音还具有额外的隐私维度，因为麦克风会捕获环境声音。同事的对话、会议或通知都可能无意间进入会话。用户应有意识地启用 Voice，并在任务结束后将其停止。

OpenAI 表示，一次只能运行一场 Voice 对话。该限制简化了交互，但并未消除会话内多个代理之间的混淆。用户需要清晰的标签，显示每项任务由哪个代理负责，以及它可以访问哪些工具。

对话质量与任务成功之间还存在验证缺口。OpenAI 已发布 GPT-Live 交互风格的偏好结果，以及推理和搜索方面的基准声明。这些测量并不能证明语音指挥的桌面任务能在各种应用中可靠完成。

独立评估应测试完整工作流。有用的指标包括完成率、纠正频率、非预期操作、审阅后的节省时间，以及从模糊指令中恢复的能力。一个虽能快速完成任务、却需要大量清理的系统，价值有限。

人类倾向于信任流畅的语音，这使得这些测试尤为重要。一段自信的口头更新听起来可能像是任务完成的证据。用户仍应检查代理生成的文档、差异、测试输出、浏览器状态或审计日志。

因此，语音控制应被视为输入和监督渠道，而不是系统已正确理解的证明。最安全的模式是通过对话委派任务，随后进行可见的、基于产物的验证。

桌面语音推出后值得关注的事项

下一阶段将取决于任务可靠性、更丰富的屏幕上下文，以及竞争对手将语音连接到自身代理系统的速度。

第一个信号是，用户是否会将 Voice 用于持续监督，而非一次性下达命令。通过语音启动任务很容易演示。更难验证的是，人们是否会持续启用 Voice 来请求更新、澄清目标并协调多个代理。

OpenAI 尚未公布关于桌面端语音指挥代理采用情况的独立数据。其每周 Voice 和 Dictation 数据涵盖的是更广泛的 ChatGPT 使用行为。未来披露的数据应当将普通对话与 Work 和 Codex 的任务协调区分开来。

第二个信号是更丰富的视觉上下文是否会出现。OpenAI 表示，GPT-Live 在推出时不支持视频或屏幕共享，尽管此前的语音体验保留了一些视觉能力。Appshots 可在 macOS 上提供经过选择的上下文，但并非对桌面的持续视图。

如果 OpenAI 为 GPT-Live 加入受控的屏幕共享功能，用户就能在讨论任务时指向界面元素。这将使语音更适合设计评审、故障排查和跨应用协作。但这也会提高隐私风险，因为持续的视觉访问暴露的信息多于经过选择的快照。

关注 OpenAI 如何区分观察与操作。用户需要知道 ChatGPT 何时能够看到屏幕、何时会捕捉窗口，以及代理何时获准进行交互。随着模型准确性日益提升，持续提示标识和清晰的会话控制将同样重要。

第三个信号是竞争对手的回应。Google 已经提供了一种内置计算机使用能力的模型，可跨浏览器、移动设备和桌面设备运行。Anthropic 也已将 Claude Desktop 连接到本地应用和资源。两家公司都可以将这些能力与更持续的语音层结合。

强有力的竞争回应会削弱 OpenAI 的界面领先优势。反应缓慢则意味着，将全双工语音、代理编排和桌面权限结合起来，比为助手添加语音识别更困难。

开发者还应关注 GPT-Live 是否会进入 API。OpenAI 表示，API 发布计划将在 ChatGPT 推出之后进行。API 访问将让软件团队能够构建专门的语音指挥代理，并配备自己的权限、审查系统和行业工作流。

这种扩展的影响可能比桌面功能本身更为深远。医疗文档系统、工程工具或内部研究平台可以将 GPT-Live 用作对话层，同时将执行过程保留在受控应用内。

企业采用将取决于证据，而非演示。采购方应要求提供任务级审计轨迹、明确的批准策略、留存控制和错误恢复指标。他们还应在扩大访问权限前，针对真实的内部工作流测试该系统。

个人用户可以进行更小规模的实验。选择一项可逆任务，说明期望结果和禁止操作，然后审查每一项产物。将所需时间与书面工作流进行比较，包括纠正错误所花的时间。

尚未解决的问题是，对话是否真的改善了对代理的控制，还是仅仅让委派显得更轻松。这两种结果并不相同。如果模糊性增加了返工，更快的指令方式就没有太大价值。

OpenAI ChatGPT 已通过将实时语音与能够执行多步骤桌面工作的代理连接起来，跨越了一个重要的界面边界。下一项考验是运营层面的，而非表演性的。用户能否持续掌握情况、有效打断，并在不失去语音便利性的前提下验证结果？

尝试一项边界明确的任务，并让屏幕始终参与其中。要求代理说明其计划、告知它无法访问什么，并在任何不可逆操作前停止。随后检查结果，而不是接受口头总结。如果这种工作流既能节省时间又能保持控制，桌面语音就找到了自己的角色。如果审查变得更困难，更好的界面仍然是那个最容易让人看清代理工作过程的界面。