Codex 定位与统一智能体框架
本次演讲由 OpenAI 伦敦开发者体验团队的 Katia Gil Guzman 和 VB 带来，旨在深入解析 Codex 这一开放软件工程智能体。Katia 指出，Codex 并非仅局限于代码生成的工具，而是一个能够执行命令、运行测试、探索代码库的全能型软件工程师代理。其核心优势在于基于 OpenAI 最新模型（如 GPT-5.3 和 GPT-5.4）构建，并依托于一个统一智能体框架（Unified Agent Harness）。该框架不仅管理工具执行和环境设置，还内置了安全机制，确保智能体能够平稳、安全地运行。
“It's not just a coding agent... It can run commands. It can run tests. It can explore code bases. It can really do everything that a software engineer would do.”
用户可通过多种界面与 Codex 交互，包括独立的 Codex App、IDE 插件、命令行界面（CLI）以及 Slack 和 GitHub 等服务集成。这种多端互通的设计使得开发者可以将 Codex 融入现有工作流，例如在 Slack 中直接指令其修复问题，或在 Figma、Linear、Notion 等工具中实现深度集成，从而最大化提升开发效率。
模型演进与性能加速技术
VB 详细回顾了 OpenAI 在模型层面的快速迭代历程，展示了从 GPT-5.2 到 GPT-5.4 的演进路径。早期发布的 GPT-5.2 Codex 专为长周期任务优化，随后推出的 GPT-5.3 Codex 进一步增强了持续运行能力。近期发布的 GPT-5.4 代表了当前最先进的基础模型，同时为了适应不同场景，OpenAI 还推出了针对短任务及子智能体（Sub-agents）的 GPT-5.4 Mini 和 GPT-5.4 Nano 版本。这种分层模型策略确保了资源的高效利用。
在性能优化方面，OpenAI 引入了 WebSockets 技术，建立了设备与 API 之间的持久连接，实现了约 1.75 倍 的 Token 生成速度提升，且未增加用户成本。此外，通过开启“快速模式（Fast Mode）”，用户可获得额外的 2 倍 Token 生成速度。这些技术共同构成了模型与框架的“飞轮效应”，旨在以最快的速度将前沿技术交付给开发者。
Codex App 的多任务工作流
随着 Codex App 在年初的正式推出，VB 分享了他从重度 CLI 用户转变为 App 重度依赖者的体验转变。Codex App 的核心价值在于其强大的多项目与多任务并行处理能力。用户可以在左侧侧边栏中独立管理不同的项目（如 Codex 项目、ChatGPT、Sora 等），而在单个项目内部，则可以通过工作树（Work Trees）功能，同时处理多个功能请求或特性开发。
这种架构允许开发者在同一项目下隔离不同的开发分支，避免了上下文切换带来的混乱。Katia 和 VB 强调，这种设计不仅提升了代码管理的清晰度，还使得智能体能够在不同的工作树中并行执行任务，极大地优化了复杂软件工程的协作流程。通过这种结构化的工作流，开发者可以更高效地利用 Codex 进行大规模代码重构和新功能开发。
Codex 应用功能升级与跨平台支持
OpenAI 近期对 Codex 应用进行了多项核心功能升级，旨在提升开发者在多任务处理时的效率与体验。原生工作树（Work Tree）支持是其中一项关键改进，它允许用户在同一个项目中并行处理多个任务，如同时修复 Bug 和回答技术问题，而无需频繁切换上下文。原生 Git 支持的加入进一步增强了这一能力，用户可以根据需要选择不同的 Git 身份推送更改，从而更灵活地管理跨项目的工作流。
"providing a native work tree support helps you um do the same task and do multiple tasks at the same time without really having to context switch as much."
此外，自动化（Automations）功能的引入极大地扩展了 Codex 的使用场景。用户可以将重复性的工作流程打包，设定在特定时间（如每天上午 9 点或晚间）自动运行。例如，Codex 可以读取用户的日历并自动生成简报，所有操作均在 Codex 应用内完成，无需外部干预。这种后台运行的定时任务机制，类似于传统的 Cron Job，但通过 AI 实现了更智能的内容生成与处理。
在平台兼容性方面，Codex 应用已从年初仅支持 macOS 扩展至原生 Windows 支持。OpenAI 强调，这是市场上首个提供原生 Windows 沙箱（Sandbox）支持的 AI 编码工具，其他竞争对手尚未提供此类功能。这一举措确保了 Windows 用户也能享受到安全、隔离的代码执行环境，标志着 Codex 在跨平台覆盖上的重要里程碑。
插件系统与模型优化策略
为了进一步丰富 Codex 的能力边界，OpenAI 推出了插件（Plugins）系统。插件将技能（Skills）、应用集成（Apps）、MCP 服务器以及提示词（Prompts）打包成可复用的工作流 bundle。这种设计简化了用户的配置过程，无需手动安装多个技能或连接多个外部服务，只需添加一个插件即可实现复杂的功能集成。技能本质上是针对特定流程的可复用指令包，用户甚至可以让 Codex 自动生成这些技能，从而避免重复劳动。应用则负责连接 Notion、Linear 等日常使用的服务，而 MCP 服务器则通过暴露外部系统的工具来扩展 Codex 的能力。
在模型层面，OpenAI 近期发布了迷你模型（Mini Models），这些模型与子代理（Subagents）功能紧密结合。通过并行化处理特定功能、Bug 修复或问答请求，迷你模型能够在保证速度的同时显著降低使用成本。这种架构允许用户以更低的费用获得更高的吞吐量，特别适合需要大规模并行处理的开发场景。
"plugins is a way that you can bring together skills uh MCPS as well as prompts and you know any other thing really uh together in one bundle."
除了上述新功能，Codex 在代码审查和安全性方面的表现也备受推崇。OpenAI 强调，这些功能并非孤立存在，而是通过插件和自动化系统相互协同，形成一个完整的开发辅助生态。这种整合不仅提升了单个任务的执行效率，还通过标准化的工作流降低了人为错误的可能性。
用户增长里程碑与社区反馈
OpenAI 社区对 Codex 的接纳程度超出了预期，数据显示，Codex 的周活跃用户数（WAU）已突破 300 万大关。这是一个具有里程碑意义的数字，表明 AI 辅助编程工具正在从早期采用者阶段迅速走向大众化。Katia Gil Guzman 指出，这一数字自今年 1 月以来增长了超过三倍，短短几个月内实现了爆发式增长。
| 指标 | 数值 | 备注 |
|---|---|---|
| 周活跃用户数 (WAU) | 3,000,000+ | 截至演讲时最新数据 |
| 自1月以来的增长率 | > 300% | 反映短期内的爆发式增长 |
这种快速增长得益于 OpenAI 对开发者社区、初创企业和大型企业的持续支持。演讲者强调，Codex 不仅仅是一个编码工具，更是一个能够融入开发者日常工作的智能助手。通过提供Web 应用和游戏开发的专用技能插件，OpenAI 进一步满足了垂直领域开发者的需求。特别是 Playwright Interactive 技能，被描述为视觉开发中的“游戏规则改变者”，它极大地简化了前端交互和测试流程。
"the three million weekly active users thing is really it's really cool to see and it's crazy to think that it's also more than tripled since January."
OpenAI 表示，将继续倾听社区反馈，优化现有功能，并探索新的应用场景。无论是通过插件扩展能力，还是通过自动化提升效率，Codex 的目标都是让开发者能够专注于创造，而非重复性劳动。这种以用户为中心的发展策略，正是其用户基数迅速扩张的核心驱动力。
游戏开发自动化：Playwright 与 Image Gen 的深度整合
在演示游戏开发场景时，演讲者展示了如何利用 Code Studio 插件 将多个 AI 能力串联起来。其中，Playwright 被用作一个无头浏览器沙盒，允许 Codex 在虚拟环境中运行应用程序。通过这种交互模式，AI 不仅能打开应用，还能执行点击、导航等操作，并截取屏幕截图进行分析，从而实现对游戏逻辑的自动化调试。与此同时，Image Gen 被用于生成游戏所需的视觉资产，如精灵图（sprites）。这种组合使得从代码构建到视觉素材生成，再到功能验证，形成了一个完整的自动化闭环。
"Playwright essentially is like a headless browser... that Codex can just run and use that to see what it's doing."
为了展示这一流程，演讲者启动了一个耗时较长的游戏构建任务。该任务调用了 Game Studio 插件包，其中包含了多种针对游戏开发优化的技能。Codex 被指示使用 Image Gen 创建游戏精灵，并利用 Playwright 的交互功能来确保游戏运行正常。虽然这个特定的构建过程可能需要长达一小时，但演示的重点在于展示 AI 如何逐步执行这些复杂的、多步骤的开发任务，而无需人工持续干预。
数据同步自动化：从代码库到 Google Sheets 的高效更新
第二个演示案例聚焦于开发者网站的数据维护。演讲者展示了一个包含所有 Codex Meetup 活动的页面，这些数据最初以 YAML 文件格式存储在代码库中。为了自动化这一繁琐的数据同步过程，演讲者连接了 Google Drive 插件，并创建了一个名为 "Codex events" 的电子表格，包含活动名称、日期和城市字段。
当 Codex 执行此任务时，它首先深入分析代码库，定位到存储活动信息的 YAML 文件源。随后，它自动提取数据并更新电子表格。整个分析过程仅耗时 2 分钟，Codex 成功识别并写入了 57 行 活动数据，与网站上当前列出的活动数量完全一致。这一案例证明了对于任何涉及数据审查和同步的重复性工作，Codex 都能通过访问代码库和外部输入（如 CSV 或电子表格）来高效完成，从而节省大量人工时间。
"Codex took two minutes to actually analyze the codebase... it wrote the 57 event rows."
日常办公自动化：Slack 与 Gmail 的智能摘要与筛选
除了项目级任务，Codex 还具备强大的后台自动化（Automations）能力，可以设置为在特定频率下运行，而无需用户实时交互。演讲者分享了两个提升日常工作效率的自动化设置：
- Slack 消息管理：Codex 每天上午 9:00 自动检查 Slack 消息，标记出需要回复的敏感或紧急信息，并按主题对前一天发生的事件进行总结。特别关注那些包含公司重要信息的频道，防止关键信息遗漏。
- Gmail 邮件筛选：面对大量邮件，Codex 自动检查是否需要回复，并判断邮件的时效性和真实性，过滤掉非必要的请求，从而每天节省数小时的处理时间。
这些自动化任务可以通过应用界面手动创建，也可以直接通过自然语言指令生成。例如，演讲者尝试让 Codex 创建一个自动化任务，用于扫描 Slack 中提及 "Codex use cases" 的内容，并列出重要的用例以更新网站。尽管在实时演示中遇到了一些界面交互的小插曲，但手动创建流程同样清晰：只需指定插件（如 Slack）、运行频率和项目范围即可。
"I'm asking that to bucket it per topic... important company information is in there and so I just want to make sure that I don't miss anything here."
最终成果验证：视觉资产生成与数据准确性
在演示的最后，演讲者回头检查了之前启动的两个长期任务的最终结果。对于游戏开发任务，Codex 已经利用 Image Gen 生成了全套的游戏精灵和资产，视觉效果符合预期。虽然生成过程仍在后台持续进行，但初步结果展示了 AI 在视觉内容创作上的潜力。
对于数据同步任务，电子表格已准确更新了所有 57 个活动的详细信息。这一结果不仅验证了 Codex 在代码理解方面的准确性，也证明了其在跨平台数据操作上的可靠性。这两个案例共同表明，无论是复杂的多模态开发任务（代码+图像+交互测试），还是结构化数据处理任务（代码库+电子表格），Codex 都能通过插件生态和自动化机制，将原本需要数小时的人工操作压缩至分钟级，并保证结果的精确性。
"It generated some pretty cool sprites... we have 57 events currently listed on the website and so let's check let's see our spreadsheet and yeah we can see that it was updated."
零输入生成完整平台游戏案例
视频展示了一个由 Codex 在零人工干预下生成的完整平台游戏案例。演示者仅输入了“用砖块制作平台的平台游戏”这一句指令，Codex 便自动生成了所有资产，包括五个以上不同的角色精灵图、游戏逻辑及界面元素。演示者强调，虽然整体 UI 可能需要后续迭代，但游戏核心机制和素材生成完全由 AI 完成，无需手动绘制或编写基础代码。
“我给了零输入。我只是说做一个用砖块做平台的平台游戏。就这样。是的，它生成了所有东西。”
这一案例展示了 Codex 结合 Playwright 技能、图像生成技能以及 Game Studio 插件的强大能力。用户甚至可以将自己的面部照片作为输入，利用图像生成技能创建 2D 版本的角色，体现了多技能协同工作流在创意开发中的潜力。这种自动化生成不仅节省了美术资源制作时间，还验证了 AI 在复杂项目结构搭建上的可行性。
Codex 代码审查的多端集成
在回顾 Codex 生态系统后，演讲者重点介绍了 Codex Code Review 功能，称其为“目前行业中最优秀的代码审查工具之一”。该功能支持多种集成方式，首先是在 GitHub 上，用户可将 ChatGPT 账户与 GitHub 连接，设置 Codex 自动审查每个 Pull Request (PR)。
审查结果会以具体的优先级标记（P0、P1、P2）呈现，指出缺失项或建议修复的内容。此外，用户可通过 Codex CLI 或 Codex App 使用 /review 命令启动审查流程。最近，OpenAI 还推出了 Clot Code 插件，允许开发者在 Clot Code 会话中直接调用 Codex，实现无缝的代码审查体验。这种多端覆盖确保了开发者在不同工作流中都能获得一致的高质量审查服务。
深度上下文感知与内部强制审查机制
Codex Code Review 的核心优势在于其深度上下文感知能力。当审查未提交的更改时，Codex 会启动一个全新的进程，不仅分析代码差异（diff），还会结合整个模型仓库的上下文进行综合评估。这意味着它能发现仅看局部差异无法察觉的二阶效应，即当前修改可能对他未触碰的模块产生的潜在影响。
“Codex 代码审查非常有效，OpenAI 所有员工（包括 Greg）提交的所有 Pull Request 默认都经过 Codex 代码审查。”
目前，OpenAI 内部已强制实施这一机制，100% 的员工 PR 均默认经过 Codex 审查。在实际演示中，Codex 在一分钟内生成了详细的审查报告，包括 P1 级别的本地化建议和 P2 级别的翻译优化。这种自动化且深度的审查流程，解决了随着项目规模扩大后人工无法逐行检查代码的痛点，为代码质量提供了第一道也是最重要的保障。
子代理（Subagents）的核心机制与并行优势
子代理（Subagents）是 Codex 的一项关键功能，其核心在于将主任务分解为可并行、独立运行的子任务。正如演讲者所言："Sub agents is the um is essentially the ability uh wherein you can spin off um a master task into decomposible parallel and independent tasks"。这种架构允许用户启动任意数量的代理（受限于 API 密钥或订阅计划的配额），每个代理在独立环境中工作，最终将结果汇总回主线程。这种并行处理能力极大地扩展了 Codex 处理复杂任务的边界，使得原本需要串行处理的长链条任务得以加速完成。
实际案例：自动化审查 45 个子代理角色定义
演讲者展示了一个具体的实战案例：审查一个包含多个“子代理角色”（Sub-agent Personas）的代码仓库。该仓库中定义了诸如文档审查员、测试用例创建者等角色，每个角色都有对应的配置文件。演讲者指出："I wanted um it to do is to go through all of these 40 50 different sub aent personas, review them and and make sure that they are up to spec"。若不使用子代理，Codex 需逐个文件串行审查，效率极低；而使用子代理后，系统自动创建了审查切片，将任务分发给多个代理并行处理。
任务执行流程：从自动规划到并行执行
当向 Codex 发出“启动 20 个子代理审查所有子代理”的指令时，系统展现了高度的自动化智能。首先，Codex 自动识别任务复杂性并启动 Plan Mode，无需用户显式调用。它分析出仓库中有 45 个经过策划的角色文件（curated persona files），并制定了包含五个步骤的计划。随后，系统将任务分区并分派给 20 个审查员。尽管受限于本地设置，当前仅并发运行了 6 个代理线程，但系统清晰地展示了每个代理（如 Jason、Hume）的工作状态。
子代理的上下文隔离与结果聚合
在并行执行过程中，主模型不仅分配任务，还为每个子代理定制了特定的角色Persona，并精确指定了需要审查的文件列表。此外，系统还会注入仓库的指导文档（如 repo.md, contributing.md, skills 目录等）作为上下文，确保审查的准确性。演讲者强调："the main codex model over here um essentially created a persona, right? Um and not just that, it doubled down and it gave the exact files that this particular sub aent should review"。当所有子代理完成审查后，主线程会拆解这些子代理，并汇总所有反馈结果，形成最终的审查报告。
扩展应用场景：安全分析与头脑风暴
除了代码审查，子代理模式在网络安全和创意构思中也有广泛应用。例如，在安全领域，可以启动多个子代理从不同假设或视角对同一 Git 提交或仓库进行漏洞分析，从而构建全面的漏洞地图。在功能开发阶段，演讲者提到："I would just spin up multiple codec sub aents to sort of look through how I would approach a problem"。通过让多个子代理并行探索不同的解决方案路径（如 5-10 种不同方法），用户可以高效地进行头脑风暴，评估各种技术方案的可行性与优劣。
默认子代理的三种核心角色与权限配置
Codex 默认内置了三种具有不同职能定位的子代理（Subagents）角色，旨在通过分工协作提升开发效率。首先是通用回退代理（Default General Purpose Fallback Agent），它作为基础兜底方案处理常规任务；其次是执行型代理（Worker），专注于代码实现，适用于用户要求 Codex 编写特定功能或修改现有代码的场景；最后是探索型代理（Explorer），主要用于代码库的深入分析与理解。这种角色划分允许系统根据任务性质自动匹配最合适的代理，从而优化资源分配。
"By default we ship three sub agents personas. One is like a default general purpose fallback agent. Another is a worker which is sort of execution focused."
在权限控制方面，不同角色需要严格区分读写权限以保障安全。审查代理（Review Agent）和网络安全漏洞分配代理必须设置为只读模式（Readonly Mode），绝对禁止其执行任何代码，以防止潜在的安全风险或意外修改。相反，对于文档编写代理（Docs Writer）或需要生成 bug 报告的代理，则应赋予写入权限（Write Access），使其能够执行操作并创建相关文件。这种精细化的权限管理确保了代理在各自职责范围内安全高效地运行。
高级定制：MCP 访问、技能扩展与模型选择
除了基础角色，用户可以对子代理进行深度定制，包括指定底层模型、推理强度（Reasoning Effort）以及沙箱模式。更重要的是，可以通过赋予子代理 MCP（Model Context Protocol）访问权限来扩展其能力边界。例如，可以将子代理连接到 Sentry，使其能够直接查阅所有错误报告；或者连接 Linear，让代理读取、分类和整理积压的任务列表。这种集成方式使得代理能够直接交互外部工具，获取实时上下文。
"You can also give them skills. So really you can if you really want to you can quite heavily customize this entire setup for your own use case."
此外，还可以为子代理分配特定的技能（Skills），进一步定制其行为逻辑。这种高度可定制化的架构允许开发者根据具体用例构建专属的工作流。例如，在之前的演示中，Codex 自动创建了多个子代理来分析 README 和贡献指南，并发现了诸如“性能调查员权限过大”或“验证器沙箱不匹配”等具体问题。这种自动化发现机制不仅节省了手动逐一检查的时间，还提高了代码库维护的准确性和效率。
自定义子代理实战：文档研究员的创建与应用
在实际操作中，推荐用户创建自定义子代理以适配特定工作流。一个典型示例是创建文档研究员（Docs Researcher）子代理。该代理被配置为使用 GPT-5.3 Codex Spark 模型，这是一个仅文本的研究预览模型，部署在 Cerebras 硬件上，具有极快的响应速度，非常适合快速探索任务。其沙箱模式被设定为只读，并附带明确的指令：保持在探索模式，追踪执行路径，不提出修复建议，仅专注于查找和理解问题。
"In this particular case, this is this uses the docs MCP server which we created from the DX theme which packages all the API references, all the docs, all the guides, all the you know toolkits and so on and so forth."
当用户请求 Codex 创建此类子代理时，Codex 会自动生成相应的 TOML 配置文件。在上述案例中，系统自动集成了之前创建的文档 MCP 服务器，该服务器打包了所有 API 参考、文档、指南和工具包。这使得新创建的子代理在回答诸如“如何最好地使用 GPT-5.4 配合 WebSockets”或“如何为 GPT Realtime 创建 React 插件”等问题时，能够直接引用这些权威资料。这种自动化配置过程极大地降低了自定义代理的门槛，使得开发者可以快速构建具备特定知识库的专用代理。
子代理的自动化场景与未来展望
子代理的应用场景远不止于代码审查和文档研究，还可以扩展到自动化工作流的各个环节。例如，可以设置一个子代理在本地运行测试用例，确保代码变更后的稳定性；或者配置另一个子代理在每次从 GitHub 拉取最新代码时自动执行特定任务。此外，还可以让子代理快速从 Linear 问题中提取上下文信息，从而加速问题排查过程。
"The best thing that I like to do is to just ask codeex to look through my past sessions and recommend me certain automations certain sub agents and so on and so forth that I can use."
为了简化这一过程，最推荐的做法是让 Codex 分析用户过去的会话记录，并据此推荐合适的自动化方案和子代理配置。这种方法利用了历史数据中的模式识别能力，能够精准地捕捉用户的工作习惯和痛点，从而提供个性化的优化建议。随着技术的演进，这种基于子代理的自动化架构将成为提升开发效率的关键手段，尽管目前仍处于早期阶段，但其潜力巨大，值得开发者深入探索和实践。
Guardian Approvals：自动化特权任务审批机制
Guardian Approvals 是 OpenAI 推出的一项实验性功能，旨在解决开发者在使用 Codex 时因过度信任而导致的安全风险与人工审批疲劳问题。在默认模式下，开发者往往开启“YOLO 模式”（即无限制访问），允许编码代理执行任何操作，这种做法存在显著的安全隐患。Guardian Approvals 的核心逻辑在于：当 Codex 需要执行特权任务（如删除特定目录、启动服务器或将文件暴露于互联网）时，系统会自动启动一个新的子代理（Sub-agent）。该子代理会根据特定提示词验证该操作是否真正需要人类介入。在大多数情况下，子代理会判定无需人工干预，直接批准执行，从而大幅减少开发者在每次运行 Bash 脚本或执行危险命令时的打断频率。
“Guardian Approvals 旨在减少由始终需要批准执行特定任务（如运行 Bash 脚本）所带来的人类疲劳感。”
尽管该功能目前仍处于实验阶段，需通过 /experimental 命令激活，但其设计初衷是平衡安全性与工作流效率。通过引入自动化验证层，Codex 能够在保持对代码库控制权的同时，避免开发者陷入无休止的确认弹窗中。这种机制特别适用于那些需要频繁执行系统级操作的开发场景，使得代理能够在受控范围内自主完成高风险操作，仅将真正不确定的情况留给人类决策。
Hooks 机制：基于事件的程序化工作流控制
Hooks（钩子）是另一项实验性功能，允许开发者通过编程方式定义 Codex 在特定事件发生时的行为。目前支持三种类型的 Hook：启动时（Start）、每次工具使用后（After Tool Use）和停止时（Stop）。例如，开发者可以设置一个启动 Hook，让 Codex 在会话开始时自动从 GitHub 仓库拉取最新代码；或者为研究人员设置一个工具使用后的 Hook，用于自动记录每次工具调用的详细日志。这种机制极大地增强了 Codex 的可定制性，使其能够适应复杂的工作流需求。
“Hooks 允许你根据特定事件，程序化地要求 Codex 执行特定操作。”
其中，Stop Hook 是演讲者个人最常用的功能，特别适用于长运行任务。通过配置 hooks.json 文件，开发者可以定义一个 Python 脚本（如 keep_going_ui.py），当 Codex 遇到停止信号时，该脚本会指示 Codex 继续执行一轮操作：运行一个验证命令、输入更多内容，然后再次停止并输出结果。这种“持续迭代”的模式使得 Codex 能够在无人值守的情况下，自动完成需要多轮验证的复杂任务，显著提升了长周期任务的处理效率。
个性化与安全增强：人格设定及漏洞扫描
除了工作流自动化，Codex 还引入了人格化设置和安全增强功能。开发者可以通过个性化设置调整 Codex 的交互风格，例如设定为“友好型”或“务实型”，并添加自定义指令（如要求 Codex 始终引用其操作依据）。此外，OpenAI 发布了 Codex Security，这是一款基于最先进模型的漏洞检测工具。它能够逐 commit 扫描 GitHub 项目，识别潜在漏洞并生成补丁，随后利用 Codex 自动应用这些更改。这一功能将安全审计直接集成到开发流程中，实现了从发现到修复的闭环。
“Codex Security 能够逐 commit 扫描，创建漏洞补丁，并使用 Codex 应用这些更改。”
最后，Cloud Code 插件的发布使得开发者可以在 Cloud Code 环境中直接使用 Codex。该插件在社区中获得了广泛使用，主要功能包括代码审查、对抗性审查以及恢复已做的更改。在 Q&A 环节，演讲者澄清了如何扫描历史会话：用户只需在 Codex 文件夹中使用 CLI 或 App，指示其扫描 .sessions 目录即可获取推荐建议。这一功能支持跨线程的项目级分析，为大型代码库的历史回溯提供了便利。
云端任务卸载与并行执行策略
在开发过程中，用户常面临需要暂时离开电脑（如合上笔记本）的场景，此时将任务卸载至云端代理（Cloud Agent）成为关键需求。OpenAI代表确认，这一功能已直接集成在Codex应用及IDE扩展中。用户无需复杂配置，只需在界面中选择“Cloud”选项，即可将本地任务无缝迁移至云端环境执行。这种设计不仅支持基础的远程运行，还内置了并行化执行机制，即“Best of N”策略。用户可指定任务在云端并行运行的次数（例如四次），系统会同时生成多个结果，用户随后从中挑选最优输出。这种机制显著提升了代码生成或复杂任务处理的容错率与质量，且该功能既可通过IDE扩展访问，也可直接通过Web界面操作。
“You can also just select cloud here and you can select the number of uh times this task should run like you can parallelize we call that like best of n so you can like run it four times in the cloud and then just pick the best output.”
云端子代理与仓库技能的兼容性现状
关于云端子代理（Sub-agents）是否支持调用仓库内的本地技能（Skills），OpenAI代表澄清了当前的限制逻辑。目前，云端任务尚不支持直接调用本地Skills，主要原因在于安全信任机制的缺失。本地Skills通常包含Python脚本或可执行文件，虽然这些资源在代码库中可见，但云端沙箱环境无法自动验证这些技能是否可信。若允许随意执行，可能带来安全风险。因此，尽管云端代理可以读取代码库中的指令和上下文信息，但在执行涉及本地脚本或特定CLI工具的技能时，仍受限于沙箱的信任边界。用户目前无法像本地环境那样，让云端代理直接复用经过验证的本地技能包。
“The reason why we don't allow it on cloud is because there's no way for um the sandbox to know whether or not a skill is trusted or not.”
未来路线图：信任机制与SSH代理支持
针对用户对云端功能扩展的期待，OpenAI透露了明确的后续开发计划。虽然短期内可能不会立即支持云端调用本地Skills，但添加受信任的MCP服务器、CLI工具以及SSH代理支持已被列为最高优先级的改进方向。未来，用户将能够配置自己的可信MCP（Model Context Protocol）服务器，并在云端安全地运行特定的命令行工具。此外，团队正在探索允许用户通过SSH代理将特定任务分发至虚拟机（VM）执行的能力，这将极大增强云端代理的灵活性和企业级适用性。这些改进旨在解决当前云端环境在工具链集成上的痛点，为用户提供更接近本地开发体验的云端能力。
“We do want to sort of add uh you know give you the ability to sort of like have your own trusted MCP servers to be able to run there or CLIs and so on.”