OpenAI Codex 0.146.0 将 Amazon 与 Anthropic 工作流纳入其插件竞赛

OpenAI 发布了 Codex 0.146.0，其中一项值得关注的竞争性变化是：它能够识别与 Amazon Bedrock 和 Anthropic 的 Claude Code 相关联的插件市场。尽管这些公司之间并未达成新的合作关系，但这一版本仍与关注 Amazon 和 Anthropic 开发者工作流的人密切相关。

此次更新于 2026 年 7 月 29 日推出，涵盖的内容远不止插件兼容性。Codex 现在可以为会话命名并置顶、保留侧边对话、分叉线程历史、连接远程执行主机，并发现由执行器提供的技能。

这些变化重新定位了 Codex：它成为一个能够吸收多个代理环境中工具和上下文的工作空间。OpenAI 正在与 Anthropic、Amazon 及其他提供商竞争，同时降低开发者在它们之间迁移工作流时的摩擦。

真正的竞争已不再局限于哪个模型最会编写函数，而在于哪个代理能够保留工作上下文、连接远程基础设施、继承现有扩展，并在长期项目中保持可管理性。

Codex 0.146.0 扩展代理工作空间

核心变化在于架构：Codex 现在将线程、插件、技能和执行主机视为同一工作环境中相互连接的组成部分。

官方 Codex 0.146.0 release 列出了六类功能。每一类都针对代理辅助开发中的不同摩擦来源。

用户可以在通过 /new 或 /clear 创建会话时指定名称，也可以置顶重要线程，并在不关闭侧边对话的情况下在它们之间切换。

这听起来像是界面层面的优化，但它解决了编码代理长期存在的问题：开发者在完成一项实质性任务时，往往不止有一个问题需要处理。

一个对话可能用于实现功能，另一个用于排查失败的测试，第三个则用于研究架构替代方案或审查安全问题。

失去这些分支会迫使用户重新梳理决策过程。让它们保持可访问，则会使对话列表从一次性聊天记录变成可工作的项目索引。

该版本还新增了带分页历史记录的线程分叉功能。分页会分段加载较长的历史记录，避免界面将整段对话当作不可拆分的单一对象。

分叉会从现有线程创建一条新的工作路径。Codex 0.146.0 还支持不会出现在常规线程列表中的临时分叉。

这一区别在实验过程中很重要。开发者可以测试高风险迁移、替代补丁或不同的指令集，而不会挤占永久工作空间。

Codex 现在可通过 WebSocket 将其应用服务器连接到远程 Code Mode 主机。WebSocket 是一种持久的双向连接，让两个端点无需反复轮询即可交换更新。

这一功能将可见的代理界面与执行代码的机器分离开来。它可支持远程开发系统、托管环境，或拥有自身工具和策略的专用主机。

兼容的自定义模型提供商现在也可以使用独立网络搜索。提供商必须选择启用此功能，因此该版本并未承诺所有模型端点都具备通用搜索能力。

最后，执行器可以提供技能及相关资源。Codex 可以发现这些技能并安全读取其资源，包括用户明确选择的技能。

综合来看，这些新增功能展示了 OpenAI 正在将产品带往何处：Codex 正成为协调对话、可复用流程、外部工具、研究与远程执行的平台。

这一方向也带来了本次发布的竞争张力。如果代理工作空间能够导入其他系统中的有用组件，切换时就不再需要从头重建每一项工作流。

为什么 Amazon Anthropic 兼容性值得关注

Amazon Anthropic 这一角度关乎互操作性，而不是 Amazon、Anthropic 与 OpenAI 之间新近宣布的联盟。

Codex 0.146.0 新增了对 Agent Plugins 清单、工作空间插件发布以及更多市场发现方式的支持。该版本特别提到了 Amazon Bedrock 和 Claude Code。

这些名称代表不同层次。Amazon Bedrock 是 Amazon Web Services 提供的、用于访问和运行基础模型的托管平台；Claude Code 则是 Anthropic 的编码代理产品。

Anthropic 模型可以通过 Amazon Bedrock 提供，但 Codex 的改动描述的是独立的市场集成。读者不应将发布说明解读为三家公司达成商业协议的证据。

相反，OpenAI 正在承认开发者已在多个环境中维护扩展。不同组织可能在不同项目中使用一家模型提供商、另一家公司的云基础设施，以及第三种代理界面。

这项 Amazon marketplace change 让 Codex 面向一个由 API 支持的 Amazon Bedrock 插件市场。这为 Codex 在该环境中发现扩展提供了明确路径。

另一项 Claude marketplace change 使 Codex 能够推断 Claude Code 随附的插件市场。其实际目标是在无需用户手动重建每个来源的前提下实现发现。

清单支持是另一项重要组成部分。清单是一种结构化元数据，用于告知主机插件包含什么、应如何识别，以及哪些支持组件属于它。

这项 Agent Plugins update 使 Codex 能够理解这种打包格式。在清单层面实现兼容，比仅仅接受一个脚本目录更有意义。

它为主机提供了可预测的插件表示方式。这有助于发现、呈现、归属、验证，以及后续的策略决策。

工作空间发布则让流程朝相反方向发展。Codex 可以公开发布与工作空间关联插件的能力，使扩展的使用有可能成为协作流程。

团队可以维护一个特定仓库的插件，其中包含命令、技能、集成定义或支持资产。发布可让该软件包无需通过非正式渠道复制内容即可被使用。

这会给封闭式扩展系统带来压力。当竞争性主机能够解析其软件包或连接其目录时，市场的防御性就会降低。

不过，兼容性并不意味着行为完全一致。围绕 Claude Code 假设设计的插件，可能会引用 Codex 以不同方式处理的工具、权限或生命周期事件。

Amazon Bedrock 环境也可能带有组织特定的身份验证与网络规则。发现只是迈向有效执行的第一步。

其战略价值仍然清晰。OpenAI 可以竞争成为主要的开发者界面，同时承认客户基础设施仍将是混合的。

相比要求采用单一提供商技术栈，这是一种更可信的企业定位。大型组织很少会同时替换所有云服务、模型、代理和内部工具。

对开发者而言，这次更新降低了在现有配置之外测试 Codex 的成本。能够找到熟悉的扩展，使评估不再那么依赖于重建数月积累的工作流投入。

插件使可移植性成为主要竞争焦点

OpenAI 和 Anthropic 正在围绕代理工作空间展开竞争，同时让其扩展环境的部分能力变得更具可移植性。

模型性能仍然重要，但模型访问已经更容易与周边基础设施结合。更棘手的问题，是如何保留围绕模型构建的运营体系。

这一体系包括提示词、命令、技能、工具、审批规则、项目约定、外部服务以及积累下来的对话历史，也包括正确调用每个组件所需的知识。

插件打包了这一体系中的一部分。技能打包了可重复执行的指令及其相关资源。线程则保留了从目标走向决策的路径。

Codex 0.146.0 同时推进了这三项能力。这种组合比任何单一的界面变化都更重要。

设想一个使用 Claude Code 和内部部署插件的团队。该插件可能编码了如何检查服务、请求预发布环境部署、运行健康检查并收集日志。

如果 Codex 能够发现这一软件包，团队就获得了迁移或跨代理测试的起点。工程师仍需验证其行为，但不必从一个空工作空间开始。

同样的逻辑也适用于 Amazon Bedrock。一家公司可能通过 Bedrock 运行模型，因为其身份、审计和网络控制已经部署在 AWS 内部。

Codex 对该市场的支持并不会移除这些控制。它为 Codex 主机提供了一种发现参与该托管环境的扩展的方式。

OpenAI 的做法也挑战了简单的产品边界。编码代理不再只是模型加终端。

它日益成为必须管理状态、工具、远程机器、策略和可复用知识的主机。当这些组件能在长期任务中保持一致时，主机就会更具价值。

这也解释了为什么会话命名和置顶会与插件市场出现在同一次发布中。这两项功能都帮助将分散的交互转变为可维护的工作空间。

线程分叉强化了这一工作空间。开发者可以保留稳定的实现路径，同时在分支中测试不同的依赖项、架构或修复策略。

临时分叉增加了一种有用的可弃用性。并非每次实验都值得与活跃项目线程并列永久保留。

由此产生的工作流类似于推理层面的版本控制。它并不取代 Git，因为对话分叉并不代表权威性的源代码变更。

相反，它让调查上下文附着于不同方案。开发者可以在决定哪些代码变更应被保留之前，比较两条路径为何会分歧。

这同样与知识管理有关。除非团队对其进行保存和组织，否则代理工作流产生的决策可能会消失在冗长的转录记录中。

可搜索的工程知识库可通过在单一代理界面之外保留持久的技术记录，补充线程组织能力。

因此，Anthropic 面临的压力较为微妙。OpenAI 并非只是在复制 Claude Code 的某项可见功能。

它试图让 Claude Code 的扩展投入不再仅限于 Anthropic 的主机。如果这种兼容性能够可靠运行，开发者在选择代理时将拥有更多议价能力。

Amazon 面临的则是另一种压力。Bedrock 受益于其作为托管控制平面的定位，公司通过它访问模型及相关服务。

能够连接 Bedrock 插件市场的主机，可以在不成为 AWS 原生界面的情况下参与这些工作流。这为买方提供了另一种将基础设施选择与代理界面选择分离的方式。

这场竞争的赢家未必会拥有每一个组件。它将使混合组件在保持安全边界和可预测行为的同时，呈现出连贯的使用体验。

远程主机与 Skills 如何改变工作流转

Codex 0.146.0 将可移植扩展与可移植执行连接起来，使界面、知识和运行时可以分别位于不同位置。

远程 Code Mode 连接是这一设计的关键。应用服务器可通过 WebSocket 与远程主机通信，而不再假定所有执行都发生在用户界面旁边。

这种分离支持多种实际场景。笔记本电脑可以控制在性能更强的开发机器上运行的工作。

受监管的团队可以将源代码保留在受管理环境中，同时允许经批准的界面协调任务。项目也可以使用已配置专用编译器、服务或测试基础设施的主机。

此次发布并不意味着所有远程环境都会自动可用。主机配置、身份验证、网络路由和策略执行仍决定 Codex 能访问哪些资源。

OpenAI 将 WebSocket 功能与大量代理修复一同推出。现在，配置的代理会覆盖身份验证、插件下载、MCP 授权、远程执行、重定向、WebSocket 和 LM Studio 连接。

代理会通过中间方转发网络流量，该中间方可执行访问控制、检查或组织策略。代理支持不完整时，智能体可能看似正常运行，直到某个隐藏连接绕过获批准的路由。

这种故障模式在受管理环境中尤其具有破坏性。身份验证可能成功，但插件安装失败；或者普通请求可以完成，但 WebSocket 无法连接。

Codex 0.146.0 旨在让这些路径中的路由行为更加一致。这一说法来自发布说明，实际生产结果仍取决于各组织的网络设计。

该更新还会在身份验证或配置发生变化时刷新 MCP 连接和 Apps 工具。MCP，即 Model Context Protocol，是用于将智能体与外部工具和数据连接起来的标准接口。

Codex 可以替换已关闭的 MCP 连接，而无需重启仍保持正常的连接。这减少了在某项集成发生变化后拆除整个会话的需求。

由执行器提供的 skills 为远程工作增加了一层知识能力。执行器是代表智能体执行工具或代码操作的环境。

该环境现在可以向 Codex 声明 skills。skill 是一种可复用的流程，包含说明，并在需要时提供支持资源。

例如，远程主机可以在其测试配置和部署检查清单之外，提供一项发布验证 skill。Codex 在该主机内工作时可以发现这一能力。

安全地读取资源很重要，因为 skill 可能引用其简短描述以外的信息。Codex 必须获取所需材料，同时不能将所有可用资源都视为不受限制的上下文。

显式选择为用户提供了另一个控制点。开发者可以选择相关 skill，而不是期待系统把每个流程都注入每段对话。

这一设计也有助于应对上下文限制。即使每项资源都在某些场景中有用，无关说明相互争夺注意力时，智能体性能仍可能下降。

Codex 0.146.0 包含一些修复，旨在在严格的上下文预算下保留更多 skills。当 skill 目录必须被截断时，它也会发出警告。

这一警告很重要，因为静默遗漏会造成错误的信心。智能体可能看起来了解某个组织的流程，但关键 skill 从未进入其可用目录。

这一更广泛的机制类似于分布式工作台。界面管理对话线程，执行器提供运行时，插件连接能力，skills 提供可重复使用的操作知识。

这样的系统可以帮助团队维护跨越多种工具的 AI workflows。但它也增加了管理员必须检查的边界数量。

兼容性仍面临信任问题

Codex 可以发现更多外部组件，但发现并不等于安全性、兼容性或组织批准。

插件包含的不只是描述性元数据。取决于主机和软件包，它们可以引入命令、脚本、工具、集成、skills，或对远程资源的引用。

每一项新增内容都会扩大智能体可能请求或执行的范围。在一个主机中表现安全的软件包，在另一个主机中可能遇到不同的权限和审批语义。

清单兼容性无法解决所有差异。通用的软件包描述并不保证通用的运行时契约。

开发者应预期会在环境变量、文件路径、工具名称、身份验证、网络访问和交互式审批方面遇到边缘情况。Windows、macOS、Linux、容器和远程主机可能呈现不同的行为。

此次发布包含多项保护和可靠性变更。它会在中断、重放、导入和分叉过程中保留审批设置。

它还会将命令执行归因于受信任的插件脚本，并在审批流程中保留插件归因。归因有助于审查者了解某项拟议操作来自用户、智能体还是已安装扩展。

这种上下文能改善审查，但无法消除审查的必要性。受信任的来源仍可能包含错误、过时的假设，或不适用于当前代码库的命令。

市场发现功能带来了供应链方面的考量。目录可能变化，软件包可能更新，仓库引用也可能指向买方组织之外维护的代码。

团队应验证软件包身份、来源、版本、请求的能力和更新行为。它们还应在授权敏感操作前，先在受限环境中测试导入的插件。

工作区发布带来了治理问题。员工可能发布有用的扩展，却没有意识到其资产包含内部路径、说明或组织特定细节。

workspace publishing change 提供的是一项能力，而非完整的治理方案。组织仍需要规定谁可以发布，以及软件包可以出现在哪些位置。

远程执行也会带来类似问题。持久连接可以提升响应速度，但必须遵守与其他网络操作相同的身份验证和路由策略。

因此，代理一致性不只是一次 bug 修复。对于依赖受控出站连接的组织而言，它是安全模型的一部分。

临时线程分叉带来了另一种不确定性。它们不出现在常规列表中，使实验更简洁，但用户需要确信保留和审计行为符合预期。

发布说明称，临时分叉不会出现在线程列表中。但这一表述本身并未定义所有存储、遥测或管理保留条件。

对自定义模型提供商的搜索支持也需要谨慎解读。Codex 允许兼容的提供商选择启用独立网页搜索。

这并不保证每个提供商都会返回等效来源、应用相同策略，或提供同等程度的搜索行为可见性。团队应按提供商测试来源质量和数据处理方式。

Skill 发现带来了相关风险。大型目录可能让智能体看起来能力广泛，但重要资源可能不可用、过时或被截断。

Codex 现在会对目录截断发出警告，从而使这一限制更明显。用户仍应在依赖输出前确认某个指定流程确实已被选择和读取。

这些担忧并不否定此次发布的价值。它们界定了可移植性变得可靠所需的条件。

OpenAI 面临的挑战是让导入的工作流变得可预测，同时不抹去其原始环境之间的差异。Anthropic 和 Amazon 在接受第三方扩展或外部运行时时也面临同样的问题。

竞争优势将属于那个能让边界变得易于理解的主机。用户需要清晰的归因、有限的权限、可见的故障、可复现的配置和可恢复的状态。

缺少这些控制的庞大市场会成为不确定性的来源。相比之下，具备透明执行机制的较小目录可能更适合严肃的开发工作。

Amazon 与 Anthropic 之争接下来会如何发展

下一阶段将检验 Codex 的兼容性功能是否能带来真正的工作流可移植性，还是仅仅提供更广泛的发现菜单。

第一个信号是导入插件的行为。开发者应观察 Claude Code 和 Amazon Bedrock 市场软件包能否在只需有限修改的情况下于 Codex 中运行。

仅能成功发现还不够。实用的兼容层必须保留预期的命令、资源、身份验证路径和审批行为。

频繁的主机特定故障会削弱 OpenAI 的可移植性论点。能在代表性插件间稳定执行，则会强化这一论点，并鼓励更多团队评估多个智能体。

第二个信号是工作区发布的采用情况。Codex 现在提供了发布与工作区关联插件的能力。

关键问题在于，团队是否会用它维护共享且针对代码库的智能体软件包。可见的采用将使插件从个人定制转变为受管理的开发基础设施。

OpenAI 还需要展示管理员如何控制目标位置、更新、权限和软件包来源。企业买家对发布的评判将同样基于治理与便利性。

第三个信号是跨远程主机的可靠性。WebSocket 传输、一致的代理处理和实时 MCP 刷新共同构成一条运营链路。

用户应关注身份验证变化、网络中断、服务器刷新和长时间运行任务期间的连接稳定性。这些条件将揭示远程 Code Mode 是否已准备好用于日常工作。

Anthropic 的回应同样重要，但不仅仅是功能清单的比较。Claude Code 可以通过让自己的主机成为面向 Claude 扩展的最佳环境来巩固其地位。

它还可以深化软件包可移植性，并在信任、易用性或执行质量方面竞争。过度限制扩展会有激怒开发者的风险，因为他们期待工具能跟随自己的项目。

Amazon 的激励不同。当其受管理环境能在多种模型和智能体选择中保持实用时，Bedrock 就会受益。

能够与外部主机协作的市场，可以巩固 AWS 作为智能体层之下基础设施的地位。只要 Bedrock 仍是企业执行的核心，Amazon 并不需要由单一编码界面占据主导。

因此，OpenAI 的举措形成了三方动态。Codex 希望掌握工作界面，Anthropic 希望 Claude Code 仍是首选智能体主机，而 Amazon 希望 Bedrock 成为受管理访问的锚点。

当这些层保持可分离时，开发者将从中受益。他们可以根据每个项目的需求选择模型、主机、云和扩展系统。

但他们也承担了更多集成责任。每一种额外组合都需要测试、策略审查，以及对代码和上下文传输路径的清晰理解。

amazon anthropic 搜索短语捕捉到了真实的市场重叠，但它可能掩盖实际情况。Amazon 和 Anthropic 并未在 Codex 0.146.0 中被呈现为同一款产品。

OpenAI 支持的是与 Amazon Bedrock 和 Claude Code 相关联的不同扩展来源。当团队规划身份验证、治理和兼容性测试时，这一区别至关重要。

因此，Codex 0.146.0 与其说是推出了一项重磅功能，不如说是一次协同转变：线程更易维护，分支更易测试，插件更易发现，执行任务也可以转移到远程主机。

尚未解答的问题是：当这些部分组合在一起时，是否仍然可靠？从其他市场发现的插件，仍必须适应目标主机的工具、策略、网络和审批系统。

评估此次发布的团队应从一个边界明确的工作流开始：导入一个具有代表性的插件，派生一个测试线程，连接一台已获批准的远程主机，并记录该流程所需的每项权限。

随后，将结果与原始环境进行比较。该软件包是否保留了原有含义，还是主机特定的假设需要进行大量修复？

这种比较揭示的信息将超过模型基准测试。它将显示，编程智能体是否正在成为可移植的工作空间，还是仅仅变成了规模更大的专有集成集合。

对 OpenAI 而言，成功意味着开发者能够将既有投入带入 Codex，而不必放弃控制权。对 Anthropic 而言，考验在于：当其扩展格式能够迁移时，Claude Code 是否仍然更具吸引力。

对 Amazon 而言，机会在于让 Bedrock 在任一界面之下都保持相关性。接下来几个 Codex 版本应会显示，互操作性会成为常态，还是仍停留在早期兼容性承诺阶段。