Amazon 与 Anthropic 的关系面临 OpenAI 考验，AWS Continuum 持续扩展
据报道，AWS 已将 Continuum 与 Claude Code 和 OpenAI Codex 连接起来，尽管这两款编程智能体彼此直接竞争，Amazon 与 Anthropic 的关系也因此进入新阶段。此举将一层独立的安全机制置入能够生成、修改和执行代码的工具中。它也考验着 AWS 能否在 Amazon 与 Anthropic 保持紧密商业关系的同时，维持模型中立性。
与 AWS 对 Claude Code 及其自有 Kiro 环境的支持相比，报道中的 Codex 连接尚未获得同等详尽的公开文档说明。AWS 已发布的材料明确介绍了 Claude Code 集成、模拟漏洞利用验证，以及对多个代码托管平台的支持。这一验证缺口至关重要，因为更大的战略主张取决于 Continuum 能否跨竞争性智能体环境运行。
这并非在开发流水线末端新增的又一个扫描器。AWS 希望 Continuum 能跟踪漏洞从发现、验证、优先级排序到修复的全过程。如果这一方法奏效，编程智能体将负责产出改动，而另一套智能体则判断这些改动是否带来可被利用的风险。
AWS Continuum 将安全带入编程会话
AWS 正将安全审查从独立检查点转移到 AI 智能体编写和修改代码的工作空间中。
AWS 于 2026 年 6 月 17 日在纽约峰会上推出面向代码漏洞的 Continuum。该服务以有限预览形式上线，提供涵盖发现、优先级排序、验证、缓解和修复的持续工作流。
该公司将 Continuum 描述为模型无关型服务。这意味着它可以将不同安全任务分配给不同的前沿模型，并在新模型可用时将其纳入系统。该设计避免将完整的安全流程绑定于单一模型提供商。
AWS 还将 AWS Security Agent 的能力整合进 Continuum 产品家族。这些能力包括代码扫描、渗透测试和威胁建模，可将源代码或设计文档转化为潜在攻击的结构化模型。
文档说明最明确的开发者集成是 Claude Code。AWS 表示，开发者可直接从编程环境发起安全工作，而不必切换至独立的安全控制台。他们可以在这一工作流中创建威胁模型、扫描代码仓库，并处理已验证的发现结果。
Claude Code plugin 也可与源代码控制系统和协作工具配合使用。AWS 列出的受支持集成包括 GitLab.com、自托管 GitLab、GitHub Enterprise、Bitbucket 和 Confluence。
AWS 自有的 Kiro 环境也获得类似支持，形式为 Kiro Power——一种让 AI 智能体访问专业能力的扩展。两项集成都将安全反馈拉近到智能体提出代码改动的时刻。
VentureBeat 在 8 月的报道中将这一策略延伸至 OpenAI Codex。然而，本文审阅的 AWS 6 月发布材料提及的是 Kiro 和 Claude Code，而不是可比的 Codex plugin。AWS 可能正单独推出 Codex 连接，或通过更新的集成层提供该连接。
这一区别并不会否定更广泛的转变。它划定了 AWS 公开记录的内容与媒体报道内容之间的边界。企业采购方在假定三种编程环境具备功能对等性之前，应要求查看产品文档。
眼下的变化依然显著。Continuum 的设计目标并非仅观察孤立的代码片段。它会利用基础设施、权限、网络拓扑、文档、通信记录和业务优先级，评估某项发现是否代表实质性风险。
更广泛的上下文由此形成了本文的核心张力。AWS 希望开发者能借助自己偏好的任意编程智能体快速推进，同时让 AWS 成为决定哪些改动值得信赖的安全权威。
为什么 Amazon 与 Anthropic 的关系不会形成排他性技术栈
战略上的意外在于，Claude Code 获胜会让 AWS 受益，但当 Continuum 支持 Claude Code 的竞争对手时，其价值反而会更高。
Amazon 已对 Anthropic 进行了大量投资，并将 Claude 置于其生成式 AI 产品布局的核心位置。Anthropic 也依赖 AWS 基础设施，而 Claude 模型仍是 Amazon Bedrock 中的重要选择。
这种关系让 Amazon 对 Anthropic 的增长拥有直接利益。Claude Code 已成为开发者使用 Claude 的重要入口，尤其适用于需要规划、编辑、测试和反复执行命令的全仓库任务。
若一款 AWS 安全产品仅限于 Claude Code，将会强化这一合作关系。但这也会缩小 Continuum 的可服务市场，并降低其对采用混合开发环境的企业的实用性。
大多数大型组织不会要求每位开发者统一使用一种编程智能体。团队会按编程语言、代码仓库、风险级别、可用性和内部政策评估模型。一些开发者还会让同一项改动经由多个智能体完成实现和审查。
因此，AWS 有一种不同于 Amazon 投资动机的平台激励。无论由哪种模型编写代码，只要工作负载、安全上下文和修复活动经由 AWS 流动，平台业务便可从中受益。
这解释了为何 OpenAI Codex 属于该战略的一部分。Codex 在开发者界面层面与 Claude Code 竞争，但其用户也为 Continuum 带来了另一批代码仓库、发现结果和安全决策来源。
其结果是一种常见的云服务模式。基础设施提供商支持其基础设施之上的竞争性软件，因为客户选择会增加对提供商底层服务的使用。
这一模式并不意味着 Amazon 与 Anthropic 的关系无关紧要。Anthropic 的安全研究帮助确立了基于推理的漏洞发现为何迫切。AWS 在解释为何旧有安全运营无法跟上节奏时，曾特别提及专业安全模型，包括 Claude Mythos。
Claude Mythos 被定位为专注于网络安全推理的模型。AWS 表示，这类模型能够比传统团队处理由此产生的积压工作更快地发现漏洞，并对复杂攻击路径进行推理。
这带来了双向压力。更强的模型能帮助防御者定位缺陷，但攻击者也可利用类似能力发现并利用这些缺陷。自动化发现能力的每一次提升，都会增加快速验证和修复的价值。
OpenAI 也在通过 Codex Security 追逐同一机会。VentureBeat 报道称，OpenAI 的 beta 版本扫描了逾 120 万次提交，并发现了数千项不同严重程度的问题。这些数据仍属于公司报告的结果，而非独立比较。
Anthropic 同样将 Claude Code Security 宣传为以推理为基础、区别于面向模式的静态分析的替代方案。Anthropic 称，其发布前的研究在成熟开源项目中发现了数百个高严重性漏洞。
AWS 并未在这些安全叙事之间二选一。它正在将 Continuum 定位于其上层。编程模型可竞争谁能发现或修复最棘手的缺陷，而 AWS 则管理上下文、验证、控制措施和企业工作流。
Amazon 与 Anthropic 的战略遇上模型中立的安全层
Continuum 最重要的机制不是漏洞发现，而是将代码生成与安全判断分离。
编程智能体在开发流程中处于一个不同寻常的位置。它们可以读取代码仓库、调用工具、修改文件、运行测试、创建 pull request，有时还可与部署系统交互。
这种访问能力使其富有生产力，但也让其凭据和执行权限成为安全攻击目标。
VentureBeat 记录了数起涉及编程智能体的事件，攻击者瞄准的是凭据或执行路径，而非模型权重。恶意输入并不需要击败模型的智能，只需操纵智能体使用其获授权工具的方式。
一项据报道的 Codex 漏洞涉及对精心构造的 Git 分支名称进行不安全处理。研究人员展示了该值如何进入设置脚本并暴露 OAuth token。据报道，OpenAI 将该问题列为其内部最高优先级，并部署了修复措施。
Claude Code 则因软件包内容和命令控制行为受到单独审查。这些事件的技术原因各不相同，但暴露了同一个架构问题：一旦智能体持有凭据，并在被动聊天窗口之外采取行动，它就可能成为攻击面。
coding-agent exploits 也对传统身份监控提出挑战。即使底层请求遭不受信任的代码仓库内容操纵，有效 token 仍可能认证智能体的操作。
Continuum 试图处理这一风险的不同部分。它利用环境和业务上下文评估代码漏洞，随后在隔离 sandbox 中验证疑似漏洞利用。
sandbox 是一种受控环境，潜在危险代码可在其中运行，同时不会获得正常的生产访问权限。AWS 表示，Continuum 利用这一环境生成可复现的证据，证明报告的漏洞可被利用。
这一步至关重要，因为代码扫描系统经常生成并不代表可触及生产风险的发现结果。某个易受攻击的组件可能从不执行、不会接受外部输入，或不处于通往敏感数据的路径上。
Continuum 的优先级排序流程会考虑受影响组件是否已部署、可被访问以及与生产环境相连。它还会在排列修复工作优先级之前，评估可能的业务影响。
系统随后评估现有保护措施，例如网络控制、政策和检测机制。对于已验证的发现结果，它可建议代码补丁、政策变更或网络变更。
AWS 表示，建议的补丁会通过用于确认原始问题的同一验证机制。系统也可在这些细节可用时显示预期影响和回滚路径。
这一闭环让 AWS 有理由同时集成 Claude Code 和 Codex。编写补丁的模型不必成为判断补丁是否安全的唯一权威。
团队可以让 Claude Code 创建一项功能，请 Continuum 测试由此产生的攻击路径，并在修复过程中使用另一种模型。当 Codex 产出初始改动时，同一流程同样适用。
这种架构还减少了对任何单一模型供应商的依赖。如果某个专业模型在漏洞利用构建或补丁审查方面表现更佳，AWS 可将其加入系统，而无需替换开发者偏好的编程智能体。
对于 Amazon 与 Anthropic 的合作关系而言，模型中立性既是优势，也是约束。Claude 可以贡献专业推理能力，但 AWS 保留了对编排、政策、审计历史和周边云环境的控制权。
安全承诺取决于上下文与控制
Continuum 以部分开发者自主性为代价，换取一个能够看到更多上下文、并最终能够采取更多行动的集中式安全系统。
AWS 认为，过去十年中采用的安全运营模式已显落后。该模式收集遥测数据、进行存储、构建查询，并通过仪表板呈现警报，供人工审查。
Continuum 则将遥测数据与上下文、推理和行动连接起来。这一区别至关重要，因为新增一个仪表板只会向本已拥挤的队列中加入更多发现。
该服务跨越四个持续阶段运行。首先，它会吸收现有的漏洞积压，并自行执行扫描。其次，它会依据技术可达性和业务上下文对发现进行排序。
第三，Continuum 会尝试在沙箱中复现漏洞利用。第四，它会通过代码、网络或策略变更来建议或执行缓解措施。
Continuum 架构最初以人工控制的学习模式启动。其建议会包含系统推理过程的说明，使团队能够在授予更广泛权限前审查相关决策。
此后，组织可以将选定的风险类别转入强制模式。在该模式下，Continuum 可在客户定义的边界内实施更自动化的修复。
这种分阶段设计回应了企业的核心顾虑。安全负责人通常不会希望一个新代理在上线第一天就能对生产系统进行不受限制的变更。
随着权限扩大，可审计性变得至关重要。AWS 表示，每项决策都可解释，每项行动都可审计。它还表示，用户可以了解 Continuum 为何建议某项行动，以及回滚会产生什么效果。
这些均为公司方面的说法，而有限预览阶段几乎没有公开证据表明其在多样化生产环境中的表现。买方应审视解释的质量，而不只是看界面是否能生成解释。
可读的解释仍可能遗漏关键假设。可审计的行动仍可能建立在不完整的上下文之上。当变更影响分布式服务或持久化数据时，回滚方案也可能失效。
上下文质量带来了另一项问题。只有在源代码、权限、拓扑、文档、沟通记录和优先级等输入准确且可访问时，Continuum 才能基于这些信息进行推理。
基础设施清单会偏离实际。文档会过时。权限图中存在例外。业务优先级可能在团队之间发生冲突，尤其是在事故期间。
集中这些输入可以改善安全决策，但也会提高处理这些数据的系统的敏感性。访问控制必须防止某个代码库或团队暴露属于另一个代码库或团队的信息。
开发团队还需要了解代码库内容何时可能影响安全代理。威胁模型、注释、文档和问题描述中都可能包含不可信文本。代理系统必须防止这些文本悄然改变安全策略或工具行为。
这些顾虑并非反对代理式安全的理由。它们说明，强制执行应建立在经过衡量的验证之上，而非营销信心之上。
评估 Continuum 的团队应将其决策与现有渗透测试和人工审查进行比较。他们应衡量已确认发现、误报、遗漏问题、修复质量、回滚成功率，以及分诊过程中节省的时间。
有用的工程知识库也能支持人工审查。团队需要可搜索的记录，将发现与架构决策、责任归属、过往事故和已接受风险关联起来。
真正的考验在于，Continuum 能否在不将这些决策隐藏于代理界面背后的情况下改善它们。如果团队无法重建某项生产变更发生的原因，更快的修复价值就十分有限。
Claude Code、Codex 与传统扫描器仍在竞争
AWS Continuum 进入了一个市场：模型提供商、安全厂商和云平台都希望主导同一项修复决策。
传统静态应用安全测试，通常称为 SAST，会在源代码中搜索高风险模式和已知缺陷类别。它无需执行应用程序，并可融入既有开发流水线。
推理模型采用不同的方式处理这一问题。它们可以追踪跨文件的数据流、推断开发者意图、关联多项弱点，并判断一连串行动是否构成可利用路径。
Anthropic 和 OpenAI 都曾表示，基于推理的扫描器能够检测出基于模式的系统遗漏的漏洞。它们的发布加大了既有应用安全厂商引入更深层上下文分析的压力。
这并不是一个简单的替代故事。传统扫描器提供确定性规则、成熟的策略控制、广泛的语言支持和熟悉的合规报告。其行为在重复扫描中也更容易复现。
基于模型的系统可以审查更模糊的关系，但其输出可能有所变化。它们还要求谨慎处理专有源代码、提示词、执行工具和生成的漏洞利用证据。
独立测试已经发现了局限性。Checkmarx 研究人员报告称，在评估过程中，中等复杂度的漏洞有时会逃过 Claude Code Security 的检测。这一结果并不能确立普遍排名，但它挑战了推理能够消除扫描器盲区的说法。
扫描器比较也说明了企业为何会保留多种控制措施。推理代理可以补充确定性扫描、依赖分析、测试和人工审查，而非立即取代它们。
Continuum 增加了另一层竞争，因为它不只是扫描。它将发现与 AWS 环境上下文结合，然后管理通往修复的路径。
当客户的大部分基础设施已在 AWS 上运行时，这可能会给独立安全厂商带来压力。云服务提供商可以访问配置关系，而外部工具可能需要客户导出或重建这些关系。
独立厂商仍保有重要优势。它们可以支持多云，而不会偏向某一环境。当云服务提供商正在评估其自身服务内部的风险时，它们也可能提供中立评估。
OpenAI 和 Anthropic 面临相关选择。它们可以深化原生安全产品、与外部编排层集成，或同时推进两种策略。
Claude Code Security 让 Anthropic 与开发者和安全团队建立直接联系。Continuum 集成扩大了 Claude Code 的企业覆盖面，但也使 AWS 能够掌握策略和修复历史。
Codex Security 为 OpenAI 带来了同样的张力。集成可以让以 AWS 为中心的组织更容易批准 Codex，也可能削弱 OpenAI 对围绕其代理的安全工作流的控制。
AWS 的模型中立立场只有在客户相信其会一致对待这些工具时才会成立。Kiro、Claude Code 和 Codex 之间的功能差距会削弱这一承诺。
因此，围绕所报道 Codex 集成的公开细节缺失值得关注。买方应验证，Codex 是否支持与 Claude Code 已记录的相同威胁建模、扫描、漏洞利用验证和修复功能。
他们还应询问每项任务在哪里运行、哪个模型会接收代码库内容、工件会保存多久，以及发现是否会改善任何提供商的模型。
Amazon 与 Anthropic 的关系使这些问题更加重要。AWS 必须证明，其与一家模型公司的紧密关系不会使模型中立沦为品牌宣传。
三个信号将显示 AWS 能否赢得开发者信任
下一阶段取决于集成对等性、独立验证，以及客户是否愿意授予 Continuum 有意义的权限。
第一个信号，是针对所报道 OpenAI Codex 连接的完整技术文档。AWS 应说明受支持环境、可用操作、所需权限、区域覆盖范围，以及与 Claude Code 或 Kiro 的差异。
等效的文档将强化模型中立论点。更受限的 Codex 连接器则会表明，Continuum 在 Amazon Anthropic 生态内依然运行得最好。
第二个信号，是对模拟验证的独立测试。安全研究人员需要在真实应用程序中，将 Continuum 的漏洞利用证据与人工渗透测试进行比较。
强劲结果应包括有效发现的高复现率，以及误报的可量化减少。研究人员还应测试生成的漏洞利用尝试是否会在沙箱内引入风险或泄露敏感上下文。
较差的结果不会令该架构失去意义，但会让 Continuum 留在咨询角色，并减缓从学习模式转入强制模式的进程。
第三个信号，是有限预览期间的客户行为。AWS 表示，它在塑造该产品的过程中已与金融服务、汽车和科技领域的组织合作。
具名部署、可衡量的成果和更长的运行历史，比发布演示更有说服力。最具揭示性的指标将是客户实际授予该服务多少修复权限。
将 Continuum 限制为仅提供建议的团队，仍能从优先级排序和验证中获得价值。然而，这种行为也表明，信任尚未达到 AWS 所设想的自动化行动愿景。
进入强制模式将提供更有力的证据。买方仍应审视允许的范围，因为自动化低风险依赖更新与变更网络策略或生产代码截然不同。
更广泛的代理安全发布将 Continuum 与 AWS Context、DevOps Agent、Kiro、Transform 和 Bedrock AgentCore 连接起来。这些服务共同勾勒出一个日益由代理管理的软件生命周期。
一个代理可以编写代码。另一个可以评估发布准备情况。另一个可以现代化老旧依赖。Continuum 则可以评估漏洞，并建议跨整个技术栈的变更。
这种分工可以减少对单一编码模型的依赖。它也可能让 AWS 成为连接原本激烈竞争的各家公司代理的控制平面。
在采纳这一愿景前，开发者应提出一个实际问题：哪个代理被允许评判另一个代理的工作，又有哪些证据支持这一权限？
安全负责人应通过权限、评估数据和可逆工作流来定义答案。他们不应仅仅因为每个工具都带有熟悉的供应商名称就予以信赖。
Amazon 与 Anthropic 的合作关系使 AWS 能够接触重要模型和快速增长的开发者平台。支持 OpenAI Codex 将表明 AWS 希望扮演比发布 Claude 更广泛的角色。
未来几个月请关注文档、独立漏洞利用测试和强制模式采用情况。这些信号将揭示 Continuum 会成为受信任的安全层，还是仍停留在雄心勃勃的预览阶段。
如果你的团队使用 Claude Code、Codex 或 Kiro，请立即梳理这些代理可用的每项凭证和生产操作。然后决定独立验证步骤必须在哪些位置中断工作流。即使在 Continuum 广泛可用之前，这项工作也能立即带来价值。
