知乎第7名：OpenAI 说下一代 Harness 不止一台笔记本，Codex 真要离开 PC 了吗？
围绕知乎热榜第7名，核对 OpenAI 负责人原帖与官方 App Server、Ona、Symphony 资料：Codex 正从单机工具转向可持久、可编排的执行环境，但没有证据表明本地工作方式会在两三个月内被淘汰。
热榜覆盖说明
2026 年 8 月 6 日 00:00 档，知乎实时热榜接口返回 30 条可见条目；「怎么看 OpenAI 提到下一代 Harness 将脱离 PC，两三个月后现在的 Codex 工作方式会淘汰？」排在第 7 位，显示热度为 178 万，页面显示 45 个回答、231 名关注者。本文只追踪这一条，因为它有明确的原始帖、官方工程资料和可讨论的产品路线；没有用热榜中的泛观点话题凑数。12
先给判断
「两三个月后，今天的 Codex 会显得原始」是 OpenAI Codex 负责人 Thibault Sottiaux 在 X 上的个人判断，不是产品发布日期，也不是「两三个月后关闭本地 Codex」的公告。他在北京时间 8 月 4 日 11:37 发帖，原文说 Codex 现在是一套不错的 Harness，但下一代模型需要的不只是用户的笔记本电脑。3
但这句话也不是凭空出现的预言。OpenAI 过去半年已经公开了几块拼图：把同一套 Codex Harness 接到网页、CLI、IDE 和桌面端；让网页任务在服务器容器里持续；宣布收购 Ona，把执行环境推进到客户控制的云；再用 Symphony 把项目任务变成多个 Agent 的调度入口。456
我的结论是：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 路线图。
Loading content card…
- 本轮抓取时，Hacker News 上「Building an Advanced Agentic Harness」的讨论页显示 41 points、22 条评论。原文提出 Planner、Worker、Critic、DAG、分层记忆、追踪器和不可逆操作人工审批等设计，说明行业共同面对的是调度、状态和安全边界，而不只是模型回答质量。它是社区方案，不能当作 OpenAI 已采用的实现。910
知乎公开可见回答受限版
问题页显示 45 个回答，但本轮没有稳定公开每个回答的实时赞同数，也无法确认按点赞排序的完整前三。以下是页面公开展示的三条代表性观点，受限版，非实时全量最高赞前三；它们用于呈现讨论方向，不等于知乎排名结论。2
- 草木小丁认为，「两三个月淘汰现有工作方式」更像媒体加工，较可信的解释是执行层逐步迁到云端，PC 继续承担兼容和交互。该答主提到的内部分享、闭门沙龙等信息，目前没有独立公开证据；下文只把它作为个人判断处理。
- 恋猫从使用现场出发，认为更强的子 Agent 和长程任务会继续压榨本地 CPU、磁盘和散热，因此服务端混合执行很可能增加；他把独立服务环境、并行工作区和手机审批视为可能的下一步。这是架构推测，不是已发布功能清单。11
- 第欧根尼的判断是，Harness 可能从单机环境进入多实例云端，PC 或手机转为任务发起、状态监控和路由设备。这个观点与 OpenAI 已公开的远程、持久和编排方向相容，但仍不能证明某个具体 MCP 版本或产品会按该路径落地。
三条观点的共同点是「本地设备不再独占执行权」，分歧在于云端会承担多少工作，以及企业是否愿意把代码、凭据和测试环境交给平台托管。后一个问题不是模型能力能单独回答的。
未来三个月看什么
Sottiaux 给出的「两到三个月」应当被当作观察窗口，而不是倒计时。判断这条路线是否真的进入产品阶段，可以盯五个可验证节点：
- Ona 收购是否完成，以及并入 Codex 后有没有正式的产品、文档或安全边界说明。
- 远程 App Server 是否成为稳定入口，而不是只存在于工程文章或实验性客户端里。
- 任务界面是否从单一聊天线程转向工作项、依赖图和并行工作区，用户能否看到重试、失败原因和审批点。
- 企业控制面是否说清楚：代码和凭据放在哪里，网络访问如何限制，日志保存多久，哪些动作必须人工批准。
- 成本和可靠性是否公开：长任务的并发上限、冷启动时间、失败恢复率、存储成本和本地工具兼容性，都会决定云端 Harness 能否成为日常基础设施。
当前可以确认的，是 OpenAI 已经在把 Codex 从「会写代码的界面」做成「能持续完成工作的系统」。还不能确认的，是这套系统何时足够稳定、足够便宜，也不能确认本地 Codex 会被彻底替代。对开发者来说，下一次升级最值得关注的可能不是模型名字，而是任务能否在电脑合上后继续运行，并在需要人判断时准确停下来。
References
- 1知乎实时热榜
zhihu.com
- 2知乎问题页
zhihu.com
- 3
- 4OpenAI：Unlocking the Codex harness
openai.com
- 5OpenAI：OpenAI to acquire Ona
openai.com
- 6
- 7
- 8
- 9Hacker News 讨论页
news.ycombinator.com
- 10Building an Advanced Agentic Harness
data4sci.com
- 11知乎回答公开页面
zhihu.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.