VS Code 的 **Agents Window（智能体窗口）** 和 ChatGPT 桌面端的 **Codex 模式**，表面上看都在做同一件事：把“写代码”从人的主操作，变成由 AI Agent 执行、由人负责目标、监督和验收。
但如果只比较“谁能改代码、谁能跑终端、谁能开浏览器”，很容易得出错误结论。真正决定两者能力边界的，不是聊天窗口长什么样，而是背后的 **Agent Harness、会话编排、工具系统和执行环境**。
截至 2026 年 9 月，OpenAI 已将早期独立的 Codex App 逐步并入新的 ChatGPT 桌面体验；本文所说的“ChatGPT Codex”，指当前 ChatGPT 桌面端中的 Codex 工作模式。VS Code 的 Agents Window 则仍处于 Preview，但已经从“编辑器旁边的聊天框”明显演进成一个独立的 Agent-first 工作台。
先给结论：**VS Code Agents Window 更像一个多 Harness、跨项目、深度连接 IDE 的 Agent Control Plane；ChatGPT Codex 更像一个 OpenAI 原生 Harness 驱动的通用执行环境，正在从 Coding Agent 向“电脑上的工作 Agent”扩张。**
## 一、先把四个概念分开：Surface、Orchestrator、Harness、Execution
理解这场对比，最重要的是先把四层拆开。
1. **Surface（交互界面）**：你看到的聊天区、会话列表、Diff、终端、文件树、浏览器等。
2. **Orchestrator（编排层）**：负责 Session、并行任务、切换项目、Handoff、Fork、状态持久化等。
3. **Harness（智能体运行时）**：真正驱动 Agent Loop，管理上下文、工具调用、权限、模型、恢复与持久化。
4. **Execution / Tools（执行与工具层）**：文件系统、Shell、Git、浏览器、MCP、IDE 工具、Computer Use 等实际能力。
这个区分很关键，因为 **VS Code Agents Window 本身并不是某一个 Agent Harness**。它可以承载 Copilot、Claude、Codex，甚至 BYOK 模型；而 ChatGPT Codex 则是围绕 OpenAI 自己的 Codex Harness 构建的原生体验。
换句话说，比较它们并不等于“Copilot vs Codex”。更准确地说，是：**一个多 Harness 的 Agent IDE 控制面，和一个围绕单一原生 Harness 深度纵向整合的 Agent 工作台。**
## 二、产品定位：一个从 IDE 向 Agent OS 演进，一个从 Coding Agent 向 Computer Agent 演进
VS Code 的历史起点是编辑器。它最强的资产是文件、代码模型、语言服务、调试器、测试、Git、终端、扩展生态和 Remote Development。Agents Window 的意义，是在这些基础设施之上再建立一个 Agent-first 工作入口。
ChatGPT Codex 的历史起点则不同。Codex 从 CLI、IDE Extension、Cloud Agent 一路发展到桌面 App，核心始终是同一套 Codex Harness。OpenAI 后来加入 Computer Use、内置浏览器、Plugins、Skills、Automations、远程控制等能力，本质上是在把这个 Harness 从“代码仓库执行器”扩展为“可以操作整个数字工作环境的 Agent Runtime”。
所以两边的扩张方向不同：
- **VS Code：IDE → 多 Agent 开发控制中心**；
- **Codex：Coding Agent → 通用计算机工作 Agent**。
## 三、Harness：这是两者最值得比较的核心
OpenAI 对 Codex Harness 的定义非常明确：它不只是“把模型接到终端”，而是包含 Thread 生命周期与持久化、配置与认证、工具执行、Sandbox、MCP、Skills 等一整套 Agent Loop 运行逻辑。Codex CLI、IDE Extension、Web 和桌面端通过 Codex App Server 复用这套核心。
这带来的最大好处是**纵向一致性**：同一个 Codex 线程可以在不同客户端之间恢复，权限模型、工具行为、Skill、MCP 和 Agent Loop 的语义尽量一致。桌面 App 不是重新实现一个“像 Codex 的聊天框”，而是原生连接同一套 Harness。
VS Code 的思路则更偏**横向编排**。它建立了 Agent Host 和 Provider-neutral Session 模型，把 Copilot、Claude、Codex 等不同 Harness 适配到统一的 Session、Chat、Changes、Files、Terminal、Browser 和 Review 体验中。
这意味着 VS Code 的核心优势不是“某一个 Harness 比 Codex 更强”，而是：
- 可以在同一个控制面里使用不同 Harness；
- 可以把一个 Session 从 Copilot Handoff 给 Claude 或 Codex；
- 可以让不同 Harness 共用 VS Code 的工作区、Git、Review 和会话管理基础设施；
- 上层 UI 尽量不写死具体供应商逻辑。
从 Harness Engineering 的角度看，这其实是两种不同的路线：**Codex 追求单 Harness 的深度和完整性，VS Code 追求多 Harness 的统一编排与可替换性。**
## 四、一个容易忽略的事实：VS Code 里本身就能运行 Codex
这让“VS Code vs Codex”的问题更有意思。
当前 VS Code 可以通过 OpenAI Codex Extension 使用 Codex，也可以实验性地让 Codex 直接运行在 Agent Host 中。Agent Host Codex 还能直接使用 ChatGPT 账号登录，并提供 Default Permissions、Auto-Review、Full Access 等权限预设。
因此真正的问题不是“我要不要放弃 VS Code 才能用 Codex”，而是：**你希望 Codex 运行在 OpenAI 原生客户端里，还是希望它成为 VS Code 多 Harness 控制面中的一个执行后端？**
目前两者还没有完全等价。例如 VS Code 官方文档明确标注 Agent Host Codex 仍属 Experimental，而且 Agents Window 中部分多 Chat、Plan 等能力对不同 Harness 的支持并不完全一致。这说明“同一个 Codex Harness”在不同宿主里，最终暴露出来的产品能力仍可能不同。
## 五、Session 与多任务编排：VS Code 更像项目指挥中心
VS Code Agents Window 从一开始就把 Session 当作一等公民。它可以跨 Workspace 查看任务，按项目组织 Session，并把 Changes、Files、Terminal、Tasks、Browser 都绑定到当前 Session。
它还支持多个 Session 并行运行、侧边打开对比、Pin/Archive、Fork、Checkpoint、Handoff，以及通过 SSH 或 Dev Tunnel 管理远程机器上的 Agent Session。Copilot 和 Claude 的 Agent Host Session 还可以在同一 Session 内运行多个独立 Chat，共享同一个 Workspace 与 Worktree。
这非常接近一个“开发项目指挥中心”：你管理的不是一段聊天，而是一组正在不同代码库、不同机器、不同 Harness 中执行的工作单元。
ChatGPT Codex 同样强调多 Agent 并行、Worktree 和长任务，但它更像“Agent 工作队列”。Codex App 早期就把多个 Agent 跨项目并行作为核心卖点，后来又加入移动端远程控制：任务可以继续运行在你的 Mac、PC、Devbox 或远程环境中，你从手机查看截图、终端、Diff、审批并继续指导。
两者的区别可以概括成：**VS Code 更擅长把 Session 映射到软件项目结构；Codex 更擅长把 Thread 映射到持续执行的 Agent 工作。**
## 六、Browser Use：现在已经不是 Codex 独占能力
这一点变化很快，很多旧对比已经过时。
VS Code 现在已经内置 Agent Browser Tools，不需要额外 MCP。Agent 可以直接：打开和跳转页面、读取 DOM 和可访问元素、截图、点击、Hover、拖拽、输入、处理 Dialog，甚至执行 Playwright 代码。它可以在“修改代码 → 启动应用 → 打开页面 → 实际操作 → 查看 Console → 修复 → 再验证”的闭环里工作。
而且 VS Code 的 Browser 状态可以按 Session 隔离。Agent 自己打开的页面默认使用私有临时会话；如果需要登录态，你可以显式把已登录的页面 Share with Agent。
ChatGPT Codex 的 Browser Use 则更进一步向“通用网页工作环境”靠拢。它除了内置浏览器和页面交互，还提供浏览器注释、资产提取，并可在 Developer Mode 下通过 CDP 深度检查 Console、Network、页面状态和 JavaScript 性能。
因此如果只是**测试自己正在开发的 Web App**，VS Code 原生 Browser Tools 已经非常完整；如果任务需要跨网站、登录态、网页工具、浏览器调试与更广泛的网页工作流，Codex 的浏览器环境整体更像一个 Agent-native Browser。
## 七、Computer Use：这是 ChatGPT Codex 当前最明显的能力跃迁
Browser Use 和 Computer Use 不是一回事。
VS Code 的内置工具主要围绕开发环境：文件、终端、代码搜索、编辑器、Git、Browser、MCP 和 Extension Tools。它可以通过 MCP 或扩展继续获得更多能力，但 VS Code 当前公开的 Agents Window 能力模型，本身不是一个系统级 GUI 操作器。
ChatGPT Codex 则已经拥有真正的 Computer Use：Agent 可以通过视觉理解屏幕，并使用自己的光标去点击、输入和操作桌面应用。它不再要求目标系统提供 API、CLI 或 MCP 才能工作。
这会直接扩大任务边界。例如一个完整开发任务可以同时涉及：修改代码、打开设计工具核对视觉、操作 Xcode 或其他 GUI 工具、访问后台系统、下载文件、整理本地资料，再回到终端继续验证。
Codex 还加入了 Locked Computer Use：在符合条件的平台上，即使机器锁屏，任务仍可以继续远程运行。再配合移动端远程查看和审批，它已经开始接近一个持续在线的“数字工程师”。
## 八、/goal：Codex 把“长期目标”做成了一等能力
Codex 的 Goal mode 很值得单独讨论。`/goal` 不是普通 Prompt，也不是 Todo List，而是给 Thread 设置一个**持续存在的目标与成功条件**。Agent 可以跨多个 Turn 持续朝这个结果工作，而不是每轮都重新解释“这次要做什么”。
这对长周期任务很重要。传统 Chat Agent 容易出现一个问题：单轮任务完成了，但项目目标并没有完成；随着上下文压缩、插入新问题或多轮纠偏，Agent 逐渐偏离最初目的。Goal mode 的价值，就是把“最终状态”提升为 Harness 级状态，而不只是对话历史中的一句文本。
VS Code 也有 Plan、Autopilot、Automations、Agent Merge、Session 状态和各种 Instructions，但目前没有一个完全等价于 Codex `/goal` 的通用长期目标原语。
Plan 解决的是“先研究再实施”；Automations 解决的是“定时重复执行”；Agent Merge 解决的是“持续处理 PR 阻塞直到可合并”。它们都很有用，但和“给当前 Agent 一个持久成功条件，让它跨 Turn 自己持续逼近目标”不是同一个抽象。
在 Harness Engineering 里，这个差别非常关键：**Goal 不只是提示词功能，而是 Harness 是否把 Objective、Progress、Success Criteria 和 Stop Condition 当作可管理状态。**
## 九、能力拓展：VS Code 胜在生态宽度，Codex 胜在原生能力纵深
两边现在都已经远远超过“加一个 MCP”这么简单。
VS Code 的 Agent 扩展体系至少包括：Built-in Tools、MCP Tools、Extension Tools、Instructions、Prompt Files、Custom Agents、Agent Skills、Hooks 和 Agent Plugins。它甚至建立了 Agent Plugins 的开放打包方式，可以把 Skills 与 MCP Server 作为可移植组件，再通过客户端命名空间加入 Slash Commands、Agents、Rules 和 Hooks。
更重要的是 **Extension Tools**。因为 VS Code 本身就是成熟 IDE，扩展可以利用编辑器、语言服务、调试器、测试、SCM、Notebook 等已有平台能力，再向 Agent 暴露更专业的工具。这种“IDE 原生能力 → Agent Tool”的路径，是普通聊天 App 很难复制的。
Codex 的扩展路线则更偏“把 Agent 带到更多工作里”。它有 Skills、MCP、Plugins、Hooks、Automations、Connected Services，并逐步增加 Sites、Image Generation、Computer Use、Browser Use、Record & Replay 等能力。
其中 Record & Replay 很有代表性：你可以演示一次稳定的 GUI 工作流，再把它沉淀成可复用 Skill。这相当于把原本难以 API 化、难以文字描述的操作流程，也纳入 Agent 能力库。
所以能力拓展可以这样理解：
- **VS Code：最强的是把软件工程世界的专业能力接给 Agent。**
- **Codex：最强的是把现实电脑工作流不断收进 Agent 的可执行边界。**
## 十、Hooks 与确定性：两边都在补“模型不可靠”的最后一公里
真正成熟的 Agent 系统不能只靠 Prompt 说“记得运行测试”“不要提交密钥”。模型驱动行为本质上是概率性的。
VS Code 的 Hooks 可以在 Agent 生命周期关键节点运行确定性的 Shell 逻辑，用于校验命令、执行格式化、阻止违规操作、记录审计等。Codex 也已经把 Hooks 做成正式能力，可用于 Secret 扫描、Validator、日志、Memory 和仓库级行为定制。
这说明两家公司实际上正在收敛到同一个 Harness Engineering 共识：**Instructions 用来引导模型，Skills 用来教工作流，Tools 用来增加行动能力，Hooks 用来保证必须发生或绝不能发生的事情。**
## 十一、IDE 深度：VS Code 依然有不可替代的主场优势
如果任务进入“我要精确理解这个大型代码库”的阶段，VS Code 的优势仍然非常明显。
它本来就拥有成熟的编辑器模型、LSP/IntelliSense、符号导航、Debugger、Test Explorer、Tasks、Terminal、Git/SCM、Notebook、Remote SSH、Dev Containers、Port Forwarding 和庞大的扩展生态。Agent 不需要重新造这些能力，只需要把它们纳入工具和上下文体系。
Agents Window 自己反而刻意做得更轻：没有完整 Activity Bar、Status Bar 等传统 Workbench Chrome，因为它的职责不是取代主编辑窗口，而是负责“派活、监督、比较、验收”。需要精细修改和调试时，可以回到完整 VS Code Workbench。
ChatGPT Codex 的代码体验也越来越强，包括 Diff、PR Review、多文件与终端视图、Git/Worktree、远程 Devbox 等，但它仍不是一个完整 IDE 平台。对于断点调试、语言服务、复杂测试树、扩展化工程工具链这些需求，VS Code 仍然更自然。
## 十二、安全模型：Worktree 不是 Sandbox，Full Access 也不是“更高级模式”
Agent 能做的越多，Harness 的权限设计就越重要。
VS Code 把 Workspace Trust、Tool Approval、URL Approval、Permission Level、Worktree Isolation 等机制组合起来。这里尤其要注意：**Git Worktree 是代码变更隔离，不是安全边界。** Agent 如果拥有系统命令权限，仍可能访问 Worktree 之外的资源。
VS Code Agent Host 中的 Codex 当前提供 Default Permissions、Auto-Review 与 Full Access。Default 会限制 Workspace 外访问和网络；Full Access 则意味着更广泛的磁盘与网络权限。
Codex 原生 Harness 同样以 Sandbox 为默认基础：默认限定工作目录/分支，对需要网络或更高权限的操作进行审批；Rules 可以进一步对白名单命令进行允许、询问或阻止。Computer Use 又增加了一层 GUI 权限，因为“可以点鼠标”意味着它可能触及没有 CLI 安全边界保护的系统。
因此真正专业的 Harness 设计不是“尽量少弹确认”，而是同时具备：**隔离、权限分级、可审计工具调用、可恢复状态、确定性 Hook，以及在需要时让人重新进入控制回路。**
## 十三、多模型与多 Harness：这是 VS Code 的结构性优势
VS Code Agents Window 最独特的地方之一，是它正在把 Harness 本身变成可以切换的执行目标。
同一个任务可以先用 Plan 或 Copilot 做代码库研究，再 Handoff 给 Claude 或 Codex；或者把任务切到 Cloud，让远端 Agent 在 GitHub 仓库上独立工作并提交 PR。切换时，VS Code 尽量保留对话历史与上下文，但工具、权限与模型会随 Harness 改变。
这种模式很像操作系统里的“调度层”：上层是同一个任务和项目，下面可以替换不同执行器。
ChatGPT Codex 的优势则恰恰相反：它不是追求 Harness 中立，而是让 OpenAI 自己的模型、Codex Core、Sandbox、Computer Use、Browser、Skills、Plugins 和跨设备 Relay 深度协同。它牺牲了一部分供应商中立性，换来了更强的纵向一体化。
## 十四、自动化与长周期运行：两边都在向“无人值守”靠近
VS Code Agents Window 已经加入 Automations，可以按小时、每天或每周运行保存的 Agent Prompt；Agent Merge 还能持续观察一个 PR，处理 Review、CI 失败、分支落后和冲突，直到满足合并条件。
Codex 也有 Automations，并且天然和 Skills、Computer Use、Browser、远程机器、移动端监督结合得更紧。再叠加 `/goal`，它在“给定长期目标，然后持续工作”的方向上更激进。
因此自动化能力的差别并不是有没有 Scheduler，而是**Agent 在无人值守期间到底能触达多少真实环境，以及 Harness 能否持续判断‘目标是否真的完成’。**
## 十五、核心能力对比
| 维度 | VS Code Agents Window | ChatGPT Codex |
| --- | --- | --- |
| 核心定位 | 多 Harness 的 Agent 开发控制面 | OpenAI 原生 Agent 工作台 |
| Harness | Copilot / Claude / Codex / BYOK，可 Handoff | 原生 Codex Harness，纵向整合最深 |
| IDE 深度 | **强**：编辑、调试、测试、SCM、LSP、扩展 | 中强：Diff、终端、Git、PR Review，但不是完整 IDE |
| 多项目管理 | **强**：按 Workspace/Repo 管 Session | **强**：跨项目、多 Agent 并行 |
| 多 Harness 编排 | **明显优势** | OpenAI-first |
| Browser Agent | **有**：内置 Browser Tools + Playwright | **有**：内置浏览器、Browser Use、注释、CDP |
| 系统 Computer Use | 不是当前内置核心能力，可通过扩展/MCP拓展 | **明显优势**：视觉、点击、输入、跨 App |
| 长期目标原语 | Session / Plan / Autopilot 等，但无完全等价 `/goal` | **明显优势**：Goal mode / `/goal` |
| Skills | 有，支持开放 Agent Skills | 有，App/CLI/IDE 可复用 |
| MCP | 有 | 有 |
| Plugins | Agent Plugins，可打包 Skills/MCP/Hooks 等 | Plugins，面向更广泛工作流 |
| Hooks | 有，Preview | 有，已用于验证、安全和自动化 |
| Extension Tools | **明显优势**：直接利用 VS Code 扩展平台 | 主要通过 Plugin/MCP/Skill/Computer Use 扩展 |
| Worktree | 有 | 有 |
| 自动化 | Automations、Agent Merge | Automations + Goal + Computer Use |
| 远程 | SSH、Dev Tunnel、浏览器 Agents Window | SSH/Devbox、跨设备 Relay、手机监督 |
| GUI 工作流复用 | 主要靠 Tool/MCP/Extension | **Record & Replay** 可沉淀 Computer Use 工作流 |
| 供应商中立性 | **高** | 低，换来 OpenAI 纵向整合 |
## 十六、到底该选谁？
如果你的工作核心仍然是**大型代码库、调试、测试、Git、多人协作和多个模型/Harness 的调度**，VS Code Agents Window 更像未来 IDE 的正确方向。它不是把聊天框做大，而是在 IDE 上方增加了一个 Agent 调度层。
如果你的任务已经超出代码仓库，需要 Agent **操作浏览器、桌面应用、后台系统、设计工具、文件、远程机器，并围绕一个长期目标持续推进**，ChatGPT Codex 的能力边界更宽。Computer Use 和 `/goal` 尤其改变了它的性质：它不只是“更强的 AI 编程插件”，而是在逐渐成为一个通用执行 Agent。
但现实中最合理的答案很可能不是二选一。
一个成熟工作流可以是：**VS Code 负责项目、代码、调试、Git、Session 和多 Harness 编排；Codex 负责需要原生 Codex Harness、长期 Goal、跨应用 Computer Use 和更复杂浏览器任务的部分。** 甚至可以直接在 VS Code 中运行 Codex，再在需要完整 Computer Use 时切回 ChatGPT 桌面端。
这也是 2026 年 Agentic Coding 最值得注意的变化：竞争焦点已经不再只是“哪个模型更会写代码”，而是**谁能设计出更完整的 Harness、更可靠的反馈闭环、更丰富的工具边界，以及更适合人类监督多个 Agent 的控制面。**
## 结语：未来真正重要的是 Harness，而不是聊天窗口
模型能力越来越接近之后，产品之间的差距会更多出现在模型之外。
Agent 是否能长期记住目标？能不能自动验证结果？失败后能否恢复？能否安全使用终端、浏览器和 GUI？能否调用企业工具？能否把工作拆给 Subagent？能否跨设备继续？人类能否在正确的时间介入？这些都属于 Harness Engineering。
从这个角度看，VS Code Agents Window 和 ChatGPT Codex 其实代表了两种非常有价值的未来形态：**前者在做 Agent 时代的开发控制平面，后者在做可以直接操作计算机与数字工作环境的原生 Agent Runtime。**
它们最终甚至可能不是竞争关系，而是上下层、宿主与 Harness、控制面与执行面的组合关系。
## 参考资料
- [VS Code：Use the Agents window](https://code.visualstudio.com/docs/agents/run/agents-window)
- [VS Code：Choose and use an agent harness](https://code.visualstudio.com/docs/agents/run/agent-harnesses)
- [VS Code：Use browser tools with agents](https://code.visualstudio.com/docs/agents/run/browser-tools)
- [VS Code：Understand agent customization](https://code.visualstudio.com/docs/agents/concepts/customization)
- [VS Code：Agent plugins](https://code.visualstudio.com/docs/agent-customization/agent-plugins)
- [OpenAI：Unlocking the Codex harness](https://openai.com/index/unlocking-the-codex-harness/)
- [OpenAI：Harness engineering](https://openai.com/index/harness-engineering/)
- [OpenAI：Codex for (almost) everything](https://openai.com/index/codex-for-almost-everything/)
- [OpenAI：Work with Codex from anywhere](https://openai.com/index/work-with-codex-from-anywhere/)
- [OpenAI Help：Using Codex with your ChatGPT plan](https://help.openai.com/en/articles/11369540)
- [OpenAI：ChatGPT for your most ambitious work](https://openai.com/index/chatgpt-for-your-most-ambitious-work/)
- [OpenAI Help：ChatGPT Release Notes（Goal mode）](https://help.openai.com/en/articles/6825453-chatgpt-release-notes)
评论