知乎第7名：OpenAI 说下一代 Harness 不止一台笔记本，Codex 真要离开 PC 了吗？ (2026)

热榜覆盖说明

2026 年 8 月 6 日 00:00 档，知乎实时热榜接口返回 30 条可见条目；「怎么看 OpenAI 提到下一代 Harness 将脱离 PC，两三个月后现在的 Codex 工作方式会淘汰？」排在第 7 位，显示热度为 178 万，页面显示 45 个回答、231 名关注者。本文只追踪这一条，因为它有明确的原始帖、官方工程资料和可讨论的产品路线；没有用热榜中的泛观点话题凑数。1 2

先给判断

「两三个月后，今天的 Codex 会显得原始」是 OpenAI Codex 负责人 Thibault Sottiaux 在 X 上的个人判断，不是产品发布日期，也不是「两三个月后关闭本地 Codex」的公告。他在北京时间 8 月 4 日 11:37 发帖，原文说 Codex 现在是一套不错的 Harness，但下一代模型需要的不只是用户的笔记本电脑。3

但这句话也不是凭空出现的预言。OpenAI 过去半年已经公开了几块拼图：把同一套 Codex Harness 接到网页、CLI、IDE 和桌面端；让网页任务在服务器容器里持续；宣布收购 Ona，把执行环境推进到客户控制的云；再用 Symphony 把项目任务变成多个 Agent 的调度入口。4 5 6

我的结论是：Codex 的执行中心正在从「一台机器上的交互式工具」转向「可持续运行、可恢复、可编排的工作环境」，但没有证据表明本地 CLI、IDE 或桌面工作方式会在两三个月内被淘汰。未来更像是本地与云端并存，电脑和手机越来越像发起任务、查看状态和作出审批的控制面板。

Harness 不是聊天界面

很多讨论把 Harness 当成一个更好用的聊天壳，这会低估它的作用。OpenAI 2 月的工程文章说，网页、CLI、IDE 扩展和 macOS App 虽然长得不同，底层共享同一套 Codex Harness；App Server 是它们之间的双向接口。4

这套运行层至少要处理四类事情：

层次	它要解决的问题	OpenAI 已公开的实现线索
Agent 循环	模型何时读取文件、调用工具、修改代码、继续判断	Codex core 负责 Agent loop，App Server 对外传递事件
状态与线程	任务能否暂停、恢复、分叉，客户端断开后能否接着看	Thread 会保存历史，可创建、恢复、分叉和归档
工具与权限	Shell、文件、MCP、Skills 怎样在沙箱和审批策略下运行	工具调用可以触发客户端审批，未获允许时暂停当前 turn
客户端与运行环境	网页、IDE、终端和桌面端怎样共享一套逻辑	客户端通过双向 JSON-RPC 接收进度、差异和审批事件

这也是为什么「离开 PC」不是简单地把聊天窗口搬到手机上。真正要迁移的是文件系统、依赖、测试环境、凭据、线程状态、日志和失败恢复机制。模型变强之后，瓶颈未必是再写一段代码，而是让几十个长任务在不同工作区里同时推进，还能知道每一步发生了什么。

OpenAI 已经走到哪一步

1. 统一 Harness：先把客户端和 Agent 循环拆开

App Server 的价值，是把 Codex 的核心 Agent 循环从具体界面中抽出来。一个请求不只返回一段文字，还会连续产生工具执行、差异、审批和完成事件；客户端可以据此渲染进度，也可以在需要人决定时暂停任务。

OpenAI 还明确写到，Codex Web 会在容器里启动 App Server，浏览器只是连接它的界面。网页标签关闭或网络中断时，服务器上的状态和线程仍可以保存，新的客户端重新连接后继续显示进度。对本地 TUI，OpenAI 也描述了连接远程 Codex Server、让电脑休眠后任务仍继续的方向，但这段文字是工程计划和能力说明，不等于所有用户已经获得同样的远程执行入口。4

2. 持久云端工作区：Ona 是已宣布的交易，不是已完成的普及

6 月 11 日，OpenAI 宣布计划收购 Ona。官方给出的理由很具体：Ona 的技术可以提供安全、持久、由客户控制的云端环境，让 Agent 在用户合上笔记本后继续工作，并处理长达数小时或数天的任务。OpenAI 同时写明，这项收购仍需满足监管审批等交割条件，在完成前两家公司保持独立。5

这里有三个不能混为一谈的层级：

已确认：OpenAI 已宣布计划收购 Ona，方向是把 Codex 扩展到客户控制的持久云端环境。
已存在：Codex Web、远程 SSH 和手机端已经让用户从别的设备查看、引导或审批运行中的工作，但很多场景仍依赖一台机器或一个远程环境。
尚待验证：Ona 技术何时全面并入 Codex、哪些计划可用、云端执行如何计费、企业如何配置网络和凭据。

所以「Harness 脱离 PC」目前最稳妥的解释是：单机不再是唯一的执行地点，而不是「用户电脑以后没有用」。本地项目、企业内网、私有凭据和需要实时调试的任务，仍然有理由留在本地或受控环境中。

3. 任务编排：Symphony 把控制对象从会话换成工作项

4 月 27 日，OpenAI 公开了 Symphony 的开源规格。它把 Linear 这类项目管理系统变成 Agent 的控制面：每个开放任务对应一个隔离工作区，调度器持续拉取任务，Agent 崩溃或卡住时重启，任务完成后由人审阅结果。OpenAI 称，部分团队在前三周的已合并 PR 数量增加了 500%；这是 OpenAI 自己的内部案例，不能直接外推成所有团队的生产力提升。6

这一步很关键：如果用户始终要打开一个窗口、盯着一个线程、手动把下一个任务交给 Agent，模型能力越强，人反而越容易变成调度瓶颈。Symphony 的思路是让人管理目标、优先级和审批边界，让系统负责派发、并行、重试和收敛。

为什么是现在，而不是一句营销话

OpenAI 2 月发布的「Harness engineering」文章，已经描述了这种工作方式的内部版本：三名工程师驱动一个约百万行代码的产品，代码、测试、CI 和文档都由 Codex 生成；单次 Codex 运行可以持续六小时以上，团队把主要精力放在设计环境、工具、文档和反馈回路，而不是手写每一行代码。OpenAI 同时提醒，这种结果高度依赖特定仓库的结构和工具，不能直接假设会普遍复现。7

这解释了 Sottiaux 那条 X 帖的逻辑：当模型能够完成更长、更复杂的任务时，旧式「笔记本 + 一个终端会话」会暴露三种限制：

资源限制：一台电脑的 CPU、磁盘、网络和本地依赖，限制了同时运行的工作区数量。
状态限制：任务一旦依赖某个窗口、某个进程或某个人的记忆，电脑休眠、网络中断或上下文过长都会让任务难以恢复。
管理限制：多个 Agent 同时修改不同模块时，需要依赖图、并发控制、测试反馈和人工审批，而不是更多聊天消息。

这三点指向的是工程系统升级，不是单纯换一个更大的模型。模型是执行能力的一部分，Harness 决定它看见什么、能做什么、失败后怎么恢复，以及人在哪些节点介入。

海外平台的补充信号

这些材料不能替代 OpenAI 的正式资料，但能帮助理解这个词为什么在开发者圈迅速变热。

X 上一条中文讨论把 Harness 的价值放在前端界面之外，强调工具、上下文和后端编排才决定 Agent 能否稳定工作。这是个人观点，不是对 Codex 的独立性能测评。8
YouTube 上一支 4 月发布的独立解说把 Symphony 分为 Agent 内层、外层和更高的调度层，讨论了 DAG、传感器、审查和并发 Agent。视频是二次解释，不是 OpenAI 路线图。

Click to open on YouTube

Loading content card…

本轮抓取时，Hacker News 上「Building an Advanced Agentic Harness」的讨论页显示 41 points、22 条评论。原文提出 Planner、Worker、Critic、DAG、分层记忆、追踪器和不可逆操作人工审批等设计，说明行业共同面对的是调度、状态和安全边界，而不只是模型回答质量。它是社区方案，不能当作 OpenAI 已采用的实现。9 10

知乎公开可见回答受限版

问题页显示 45 个回答，但本轮没有稳定公开每个回答的实时赞同数，也无法确认按点赞排序的完整前三。以下是页面公开展示的三条代表性观点，受限版，非实时全量最高赞前三；它们用于呈现讨论方向，不等于知乎排名结论。2

草木小丁认为，「两三个月淘汰现有工作方式」更像媒体加工，较可信的解释是执行层逐步迁到云端，PC 继续承担兼容和交互。该答主提到的内部分享、闭门沙龙等信息，目前没有独立公开证据；下文只把它作为个人判断处理。
恋猫从使用现场出发，认为更强的子 Agent 和长程任务会继续压榨本地 CPU、磁盘和散热，因此服务端混合执行很可能增加；他把独立服务环境、并行工作区和手机审批视为可能的下一步。这是架构推测，不是已发布功能清单。11
第欧根尼的判断是，Harness 可能从单机环境进入多实例云端，PC 或手机转为任务发起、状态监控和路由设备。这个观点与 OpenAI 已公开的远程、持久和编排方向相容，但仍不能证明某个具体 MCP 版本或产品会按该路径落地。

三条观点的共同点是「本地设备不再独占执行权」，分歧在于云端会承担多少工作，以及企业是否愿意把代码、凭据和测试环境交给平台托管。后一个问题不是模型能力能单独回答的。

未来三个月看什么

Sottiaux 给出的「两到三个月」应当被当作观察窗口，而不是倒计时。判断这条路线是否真的进入产品阶段，可以盯五个可验证节点：

Ona 收购是否完成，以及并入 Codex 后有没有正式的产品、文档或安全边界说明。
远程 App Server 是否成为稳定入口，而不是只存在于工程文章或实验性客户端里。
任务界面是否从单一聊天线程转向工作项、依赖图和并行工作区，用户能否看到重试、失败原因和审批点。
企业控制面是否说清楚：代码和凭据放在哪里，网络访问如何限制，日志保存多久，哪些动作必须人工批准。
成本和可靠性是否公开：长任务的并发上限、冷启动时间、失败恢复率、存储成本和本地工具兼容性，都会决定云端 Harness 能否成为日常基础设施。

当前可以确认的，是 OpenAI 已经在把 Codex 从「会写代码的界面」做成「能持续完成工作的系统」。还不能确认的，是这套系统何时足够稳定、足够便宜，也不能确认本地 Codex 会被彻底替代。对开发者来说，下一次升级最值得关注的可能不是模型名字，而是任务能否在电脑合上后继续运行，并在需要人判断时准确停下来。