Moonshot 向 Codex 和 Claude Code 开放 Kimi，重新定义 Anthropic 与 Moonshot 的冲突
尽管 Anthropic 与 Moonshot 围绕模型训练和访问权限的争议尚未解决，Moonshot AI 仍于 9 月 2 日向两套竞争性编程环境开放了 Kimi。Kimi API 现可接收来自 Codex 的 OpenAI Responses API 请求，以及来自 Claude Code 的 Anthropic Messages API 请求。Moonshot 表示，开发者无需格式转换器或本地代理即可完成连接。
这项变化听起来像是一次兼容性更新。但其影响更为深远，因为编程智能体依赖的不只是普通的文本补全，而是细致的协议行为。客户端会发送工具定义、接收结构化调用、返回执行结果，并不断重复这一循环，直至任务结束。
因此，Moonshot 正试图将编程接口与创建该接口的公司分离开来。Codex 可以继续作为开发者的客户端，而 Kimi 模型则可替代 OpenAI 模型。Claude Code 也能保留熟悉的工作流，只是请求不再发往 Anthropic，而是发往 Moonshot。
这一策略让 OpenAI 和 Anthropic 面临另一类压力。两家公司并未失去对客户端或协议的所有权，但如今都要面对另一家提供商借助兼容性，在它们参与建立的工作流中展开竞争。
Kimi API 对 Codex 的支持消除了一个实际障碍
Moonshot 的关键变化是原生协议支持，而不是推出新的编程界面。
Moonshot 在 9 月 2 日的公告中表示，Kimi 支持 Codex 使用的 Responses API 格式，也支持与 Anthropic 和 Claude Code 相关联的 Messages API 格式。该公司分别发布了两条路径的配置指南。
对于 Codex，Moonshot 说明了如何通过其 API 基础 URL 和 Responses 线格式配置自定义提供商。自定义提供商会告知客户端模型请求应发送至何处，以及应使用哪种协议。开发者随后便可在继续使用 Codex 的同时选择 Kimi 模型。
Moonshot 将 kimi-k3、kimi-k2.7-code-highspeed、kimi-k2.7-code 和 kimi-k2.6 列为兼容选项。实际可用性仍可能取决于账户、端点、客户端版本以及当前平台配置。
Codex 配置值得关注，因为它移除了早期集成通常需要的转换层。本地适配器需要接收一种请求格式，将其改写为另一种 API 格式，再把流式响应转换回来。
每个适配器都会成为额外的活动部件。它可能错误处理工具调用、遗漏某类事件、暴露凭据，或在客户端更新后不再匹配。它也会增加调试难度，因为故障可能源于客户端、适配器、网络或上游模型。
原生 Responses 支持缩小了这一集成面。它并不保证与 OpenAI 托管模型的行为完全相同，而是意味着 Moonshot 的服务器接受客户端所预期的线协议契约。
这一差异很重要，因为 Codex 并非只是发送提示词再输出答案。OpenAI 对 Codex 智能体循环的说明描述了模型推理与工具执行之间反复进行的交互。客户端会在这些交互中传递消息、指令、工具定义、与推理相关的项目以及工具结果。
兼容服务器必须保留足够的结构，才能让这一循环继续运行。仅生成文本并不足够。流式事件、工具调用标识符、输入项目和终止行为，都会影响客户端能否可靠运行。
因此，Kimi API 的 Codex 路径面向的是那些已经喜欢 Codex 界面、但希望采用其他模型后端的开发者。它也让团队能够在不替换终端工作流或重建周边脚本的情况下比较不同模型。
当支持自定义提供商时，同样的逻辑也适用于桌面端体验。根据 Moonshot 的文档，即使配置的后端是 Kimi，模型选择器也可能显示通用的自定义标签。这一界面限制使验证变得重要。
开发者应通过配置、请求日志和受控测试确认当前提供商。仅凭一次成功的回答，并不能证明请求由哪个后端处理。
Moonshot 还表示，其 Responses 实现接受文本和图像输入，但目前不支持视频输入。这一限制缩小了原生支持的含义。协议兼容性可以足以支撑编程工作，却未必覆盖所有可能的输入或平台功能。
直接收益依然明确：开发者不再需要为文档所述路径维护本地协议桥接。这减少了配置工作，也让 Moonshot 更直接地进入成熟的智能体工作流。
Kimi 对 Claude Code 的支持让客户端成为分发渠道
Claude Code 的可配置 API 路径使 Moonshot 无需打造同样熟悉的客户端，也能在推理服务上展开竞争。
Kimi 的 Claude Code 设置使用 Moonshot 的 Anthropic 兼容端点。Claude Code 发送 Messages API 请求，由所选 Kimi 模型进行推理。客户端则继续管理文件、工具、权限和交互式工作流。
Moonshot 的 Claude Code 指南说明了所需端点和凭据。这取代了此前仅为转换请求格式而安装本地中继的做法。
Anthropic 的 Messages API 是面向对话、内容块和工具使用的结构化接口。支持其形式，便可让其他提供商接收围绕该契约设计的软件请求。这并不会让 Kimi 模型变成 Claude，也不会转移 Anthropic 的模型行为。
这一差异应保持清晰。Claude Code 是智能体客户端；Claude 是 Anthropic 的模型家族。用户可以让该客户端对接兼容的外部端点，但最终输出来自所配置的提供商。
Anthropic 自己的 网关文档承认，受支持的 API 格式可将 Claude Code 连接至网关。文档也指出，Anthropic 不会认可、维护或审计第三方网关产品。更明确地说，Anthropic 表示不支持通过网关将 Claude Code 路由至非 Claude 模型。
Moonshot 并未声称 Anthropic 支持 Kimi。它实现的是客户端所期望的请求格式。这一区别将技术互操作性与商业合作关系区分开来。
这一配置为开发者提供了实际用例。团队可以保留一个编程客户端，将测试环境指向 Kimi，并针对同一代码仓库任务运行另一套后端。借助熟悉的控制方式，他们可以比较补丁质量、工具可靠性、延迟和故障恢复能力。
这一工作流也降低了切换成本。此前，评估另一款模型可能意味着采用其专属客户端，或维护一个代理。原生兼容性让这一决定更接近于一次配置变更。
这会给模型提供商带来压力，因为用户忠诚度可能依附于智能体外壳，而非底层模型。开发者可能偏好某一界面，同时针对代码审查、代码仓库探索、图像辅助调试或长时间编辑选择不同模型。
因此，协议成为分发渠道。一旦客户端接受自定义端点，每一家兼容程度足够的提供商都可以争取接触其用户。原始厂商仍掌控客户端的演进，但不再掌控每一次推理请求。
这也存在限制。Claude Code 会不断增加功能，外部实现必须跟上这些功能所需的请求和响应字段。Anthropic 警告称，如果网关无法转发新行为，可能会破坏功能。
直接第三方端点面临相同的兼容性负担。如果 Claude Code 引入新的工具架构、请求头、内容块或流式事件，Moonshot 必须正确实现。“原生”描述的是当前集成路径，而不是永久的功能对等。
身份验证同样改变了信任边界。发送至 Moonshot 的请求受 Moonshot 的服务、数据处理、留存规则和区域可用性约束。仅因 Claude Code 仍显示在屏幕上，这些请求并不会在 Anthropic 账户下处理。
团队应将提供商选择视为基础设施决策。源代码、提示词、工具输出和代码仓库上下文都可能经过配置的端点。安全审查必须跟随接收这些材料的后端。
因此，Kimi 的 Claude Code 路径既比普通插件更简单，也更具影响力。它让 Moonshot 得以进入一个与竞争对手紧密关联的工作流，同时承担其底层模型服务的责任。
Anthropic 与 Moonshot 的冲突关乎控制权，而非兼容性
核心张力在于，技术开放可以与商业不信任并存。
核心关键词 anthropic moonshot 指向的是一种对抗性而非合作性的关系。Moonshot 对 Messages 的兼容性不应被误解为与 Anthropic 达成了协议。
2026 年 2 月 23 日，Anthropic 公开指控 Moonshot、DeepSeek 和 MiniMax 进行了其所谓的工业规模蒸馏活动。蒸馏是指利用一个模型生成的输出来训练另一个模型，但在访问权限和授权允许的情况下，这种方法也可以是合法的。
Anthropic 声称，这三家公司通过约 24,000 个欺诈账户，共生成了逾 1,600 万次 Claude 交互。其中超过 340 万次交互被归因于 Moonshot，且相关活动涉及编程、工具使用、推理、数据分析、计算机使用和视觉任务。
这些是 Anthropic 的指控，并非本文审阅材料中独立确认的事实。Moonshot 新近宣布的 API 兼容性既未证实也未解决这些指控。不能仅凭其支持 Anthropic 的消息格式，就推断 Kimi 的训练情况。
不过，这段历史改变了本次发布的解读方式。Anthropic 认为，模型输出和访问限制需要更严格的保护。与此同时，Moonshot 正让与 Anthropic 相关联的接口更容易与竞争模型配合使用。
因此，Anthropic 与 Moonshot 的冲突存在两个层面。其一涉及谁可以访问模型能力，以及应遵循何种条款；其二涉及客户端协议是否能够作为被广泛实现的接口运行。
Anthropic 的蒸馏指控强调了第一层。Moonshot 的兼容性发布则强调了第二层。双方都在争夺控制权，但针对的是技术栈中的不同部分。
协议本身并不包含模型的完整行为。它定义的是请求、内容、工具和响应如何在客户端与服务器之间传递。多家提供商可以实现相似接口，同时产生不同结果。
这种分离在其他计算市场中并不陌生。应用程序可以使用共享的数据库协议，却不使用同一个数据库引擎。云服务可以提供兼容的对象存储接口，却不必在每项运营细节上保持一致。
AI 智能体让这种分离变得更困难，因为模型行为会影响客户端循环。编程智能体需要模型选择工具、解读结果、产出有效修改，并在出错后恢复。正式的 API 兼容性不可或缺，但决定体验是否仍然实用的是行为兼容性。
如果开发者将 Codex 和 Claude Code 视为中立的外壳，Moonshot 将从中受益。如果用户将这些客户端与专门为其优化的模型联系在一起，OpenAI 和 Anthropic 将从中受益。竞争的关键在于，哪一种观点会占据主导地位。
如果外壳变得独立，模型路由就会更容易。企业可以协商供应商访问权限、执行不同的区域政策，或将模型分配给特定工作负载。开发者则可以在更换推理供应商的同时保留既有操作习惯。
如果深度的模型—客户端调优胜出，兼容的竞争对手可能仍会处于次要地位。工具调用、上下文管理、缓存、推理控制和错误恢复方面的细微差异，可能比共享端点带来的便利更重要。
这正是为什么 9 月 2 日的这项变化不仅仅是又一个 API 勾选项。它检验的是，编程智能体的分发能否与模型所有权脱钩。
原生格式仍不保证原生表现
连接能够成功建立，仍可能在智能体运行中要求最高的环节失败。
Moonshot 的公告确立了一条有文档记录的接入路径。但它并未提供独立证据，证明所有 Codex 或 Claude Code 功能在所列 Kimi 模型上的表现都完全一致。
第一个不确定性是协议覆盖范围。Responses 和 Messages 并非单一文本字段。它们涵盖流式传输、多模态内容、工具架构、工具结果、元数据、用量报告和错误结构。
供应商可能接受主请求，却以不同方式处理边缘情况。并行工具调用的到达顺序可能不同。流可能遗漏客户端预期的事件。取消操作在长时间命令执行期间的行为也可能不同。
第二个不确定性是行为适配度。编程客户端依赖模型遵循专门指令并谨慎操作工具。即使模型在编程基准测试中得分很高，也仍可能难以应对特定客户端的提示词或代码仓库工作流程。
因此，有效评估应衡量任务完成情况，而非连接是否成功。团队需要测试模型是否修改了正确文件、是否遵守项目指令、是否正确解读命令输出，以及是否会在需要审批时停止。
第三个不确定性是客户端演进。随着新能力的到来，OpenAI 和 Anthropic 可以修改其客户端。外部供应商必须跟上这些变化，却无法控制其节奏。
OpenAI 对 Codex 的描述显示，智能体循环已经变得多么细致。工具调用输出会被附加到后续请求中，随着多轮交互，对话上下文也会不断扩展。即使端点仍是 /responses，这些对象的变化也会影响兼容性。
Anthropic 也向网关运营者发出了类似提醒。其文档指出，当网关未能转发新功能时，新的 Claude Code 能力可能会失败。直接实现该格式的供应商承担着类似的维护风险。
第四个不确定性是数据治理。替换后端会改变代码和上下文的传输路径。组织不能假设，附加在 OpenAI 或 Anthropic 账户上的控制措施会随请求一同延续到 Moonshot。
安全审查应涵盖凭证存储、保留策略、日志记录、地理处理、事件响应和访问控制。团队还应在发送真实生产任务前，确认智能体能够读取哪些代码仓库文件。
第五个不确定性是可观测性。通用模型标签可能让实际使用的后端变得不那么明显。组织需要日志，将每项请求关联到供应商、模型标识符、开发者、代码仓库和策略。
这正是内部工程知识库可以发挥作用的地方。团队可以记录已批准的配置、评估结果、已知不兼容问题和回滚步骤，而不必依赖个人记忆。
这些担忧都不会否定这次发布。它们界定了“原生支持”在实践中应有的含义：供应商移除了一个必需的转换组件，而不是每项客户端功能都已实现永久性的对等表现。
负责任的试用应从具有代表性的代码仓库和有限权限开始。测试应包含涉及文件搜索、多文件修改、测试执行、命令失败、图像输入和长工具调用序列的任务。
团队应比较最终补丁及其生成过程。即使结果正确，如果它是通过不必要的文件访问或反复执行失败命令获得的，仍然表明存在运营风险。
最有力的证据将来自客户端更新过程中的持续使用。Moonshot 让采用变得更容易。它现在必须证明，在首次提示词成功之后，兼容性仍然可靠。
开发者在 9 月 2 日之后应关注什么
三个信号将决定这次发布会改变模型竞争格局，还是仅仅成为一个便捷的集成选项。
第一个信号是客户端更新后的功能对等性。开发者应关注，新的 Codex 和 Claude Code 功能能否通过 Moonshot 的端点及时运行。
其中包括新的内容类型、工具定义、流式事件、推理控制和身份验证行为。快速支持将强化 Moonshot 作为一流供应商的主张。反复出现的故障则会削弱这一主张。
公开文档将提供早期指标。清晰的兼容性矩阵、版本要求、已知限制和带日期的更新，比笼统的支持声明更重要。
第二个信号是经过验证的工作负载表现。独立测试应考察完整的代码仓库任务，而非孤立的编程问题。有用的衡量指标包括成功补丁、测试通过率、不必要的工具调用、延迟、命令出错后的恢复能力，以及人工修正时间。
相关比较并不只是聊天窗口中 Kimi 与 Claude 或某个 OpenAI 模型的对比，而是 Kimi 在开发者打算使用的确切客户端循环中的表现。
不同模型可能会在不同工作负载上胜出。快速模型可能适合代码仓库搜索和常规转换。更审慎的模型或许更擅长架构变更或复杂调试。原生兼容性让这些比较更容易，但并不能替代比较本身。
第三个信号是 OpenAI 和 Anthropic 如何回应供应商可移植性。它们可以加深模型—客户端优化、收紧受支持供应商政策、改进企业路由，或让官方云端选项更具吸引力。
Anthropic 已经划定了其记录在案的网关与其不支持的非-Claude 模型之间的界线。尚未解决的 Anthropic 与 Moonshot 争议，也让人们有理由关注这条界线是否会变得更加严格。
OpenAI 已明确表示，Codex 的 Responses 端点可配置。这种架构选择支持可移植性，尽管实现细节和受支持配置可能发生变化。Moonshot 的发布正在检验开发者会在多大程度上使用这种灵活性。
对个人开发者而言，眼下的行动很直接：将 Kimi 视为另一个需要评估的后端，而不是可直接替换的身份。先从可丢弃的分支开始，确认实际启用的模型，限制凭证权限，并检查每一份补丁。
对工程负责人而言，更大的问题关乎依赖关系。组织是希望依赖一家一体化供应商，还是希望拥有一个可在多家供应商之间路由的客户端层？兼容性让第二种方案更可行，但也将测试和治理工作转移给客户。
在个人知识库中保留简短的评估记录。记录客户端版本、所选模型、代码仓库类型、任务、观察到的故障，以及最终的人工审查结果。在更新后重复相同测试，将揭示兼容性是否正在改善。
Moonshot 已移除了 Kimi、Codex 和 Claude Code 之间的一道显性障碍。接下来需要跨越的是通过反复智能体运行赢得的信任。当客户端发生变化、任务变得更长，以及 Anthropic 与 Moonshot 的冲突持续让访问与控制问题受到关注时，原生协议支持是否仍会保持可靠？
