如果你是一名开发者，最近可能已经注意到一个趋势：越来越多的团队开始尝试将国产大模型集成到自己的开发工作流中。无论是出于成本考虑、数据安全需求，还是对特定中文语境的优化，国产模型都展现出了独特的吸引力。然而，一个现实的问题摆在面前：我们习惯了使用像 Codex 这样的成熟编程助手，它们通常深度绑定在特定的生态里，如何让这些“原装”工具无缝、优雅地使用我们自己的模型，而不是依赖复杂的中转代理或魔改客户端？

这正是本文要解决的核心问题。很多人误以为接入国产模型必须搭建复杂的代理服务器、修改客户端源码，或者忍受不稳定的网络转发。实际上，通过深入理解 Codex 这类工具与模型服务的通信协议，我们可以找到一种更“优雅”的路径——直接配置，让 Codex 客户端“认为”它正在与熟悉的服务器对话，但实际上后端服务的是国产模型。这不仅能大幅降低部署复杂度，还能获得更稳定的使用体验。

本文将为你彻底拆解“Codex 无需中转站，优雅接入国产模型”的完整方案。你会看到，这不仅仅是一个配置教程，更是一次对 AI 编程工具底层架构的探索。我们将从 Codex 的基本工作原理讲起，一步步完成环境准备、服务端配置、客户端对接，并提供完整的代码示例和避坑指南。无论你是想为团队搭建内部开发助手，还是单纯想体验国产模型的编程能力，这篇文章都将提供一条清晰、可落地的路径。

1. 这篇文章真正要解决的问题

在深入技术细节之前，我们首先要明确：为什么“优雅接入”如此重要？它解决的远不止“能用”的问题。

痛点一：架构复杂性与维护成本 。传统的“中转站”方案通常需要额外部署一个转发服务器。这个服务器需要处理协议转换、认证转发、流量监控等一系列任务。它成为了整个链路中的单点故障源，一旦出现问题，整个编程助手服务就会中断。同时，维护这个中转服务本身就需要投入额外的运维精力。

痛点二：性能损耗与延迟叠加 。每一个中间环节都会引入额外的网络延迟和序列化/反序列化开销。对于代码补全这种对实时性要求极高的场景，几十毫秒的额外延迟都会严重影响开发者的体验。直接对接可以避免不必要的网络跳转，让请求以最短路径到达模型服务。

痛点三：功能完整性与兼容性风险 。中转服务器在协议转换过程中，可能会丢失或误解原始客户端和服务端之间的一些特定字段或功能，例如流式输出（Streaming）的控制、特定上下文的传递方式等。这可能导致 Codex 客户端的某些高级功能无法正常工作，或者行为出现偏差。

痛点四：安全与权限管理的割裂 。在中转架构下，权限验证往往需要在中转层和模型服务层分别进行，增加了认证逻辑的复杂性，也使得审计日志变得分散，不利于统一的安全管控。

因此，本文的“优雅接入”方案，其核心目标是实现 “客户端无感切换” 。即 Codex 客户端无需任何修改，完全按照其原有的方式发起请求，但这些请求被透明地、高效地路由到我们指定的国产模型服务上。这要求我们对两端的协议有深刻的理解，并能在关键节点进行精准的“桥接”。

2. 基础概念与核心原理

要实现优雅接入，必须理解几个关键角色和它们之间的对话方式。

Codex 客户端 ：这里指的是广义上使用 OpenAI 兼容 API 的编程辅助工具。它可能是一个 IDE 插件（如 VS Code 的 Copilot 插件早期版本）、一个独立的桌面应用（如 Claude Desktop，但通过配置可对接其他服务），或者一个命令行工具。它们的共同点是，都遵循一套与 OpenAI API 高度相似的协议来发送请求和接收响应。

OpenAI 兼容 API ：这是一套基于 HTTP 的 RESTful 接口规范，通常使用 JSON 格式传输数据。核心端点包括：

  • POST /v1/chat/completions : 用于对话补全（Chat Completion），这是目前最主流的交互方式。
  • POST /v1/completions : 用于文本补全（Legacy Completion）。
  • POST /v1/embeddings : 用于获取文本嵌入向量。 其请求体和响应体结构有明确的字段定义，例如 model , messages , temperature , max_tokens 等。

国产模型服务 ：指国内公司或开源社区提供的大语言模型服务，例如 DeepSeek、通义千问、文心一言、智谱 GLM 等。这些服务通常也提供了自己的 API，但其接口地址、请求/响应格式、认证方式可能与 OpenAI API 标准存在差异。

“优雅接入”的核心原理 ：在 Codex 客户端和国产模型服务之间，我们不插入一个功能完整的、沉重的“中转站”，而是部署一个轻量的 “协议适配层” 或直接利用模型服务本身的 “兼容模式” 。

  1. 协议转换 ：当客户端向一个特定的 URL（例如 https://api.your-company.com/v1 ）发送标准的 OpenAI API 格式请求时，这个适配层负责将请求体字段映射为国产模型 API 所需的格式，然后将请求转发给真正的模型服务端点。收到国产模型的响应后，再将其转换回标准的 OpenAI API 格式，返回给客户端。
  2. 透明代理 ：另一种更理想的情况是，国产模型服务原生提供了“OpenAI 兼容模式”。此时，我们只需要将 Codex 客户端的 API Base URL 直接配置为该服务的兼容端点即可，无需任何额外的转换层。这实现了真正的“直接接入”。

理解了这个原理，我们就能明白，工作的重点在于： 找到或构建这个“协议适配层”，并正确配置客户端指向它 。

3. 环境准备与前置条件

在开始动手之前，请确保你已准备好以下环境。我们将以一种通用的、基于轻量级适配器的方案为例进行演示，该方案具有最好的普适性。

3.1 基础运行环境

  • 操作系统 ：Linux (Ubuntu 20.04+ / CentOS 7+)、macOS 或 Windows (WSL2 推荐)。本文示例以 Linux/macOS 命令行环境为主。
  • Python 环境 ：Python 3.8 或更高版本。这是运行大多数适配器工具和脚本的基础。
  • 包管理工具 ： pip 已正确安装并更新至最新版。

3.2 国产模型 API 访问权限

  • 你需要拥有一个目标国产模型的 API 访问权限。例如：
    • DeepSeek ：在官方平台注册并创建 API Key。
    • 通义千问 ：在阿里云灵积平台开通服务并获取 API Key。
    • 智谱 GLM ：在开放平台申请并获得授权。
  • 请妥善保存你的 API Key 和模型的 API Base URL （例如 https://dashscope.aliyuncs.com/compatible-mode/v1 ）。

3.3 网络连通性

  • 确保你的服务器或本地开发机能够稳定访问目标国产模型的 API 端点。这可能涉及到网络策略调整。
  • 如果你在本地开发，Codex 客户端（如 IDE）需要能访问到你即将部署的适配器服务（通常运行在 localhost 或某个内网地址）。

3.4 工具选择：为什么是 “OpenAI-Forward” 或 “LLMProxy”？ 我们将使用一个现成的开源工具来作为协议适配层。这类工具专门为解决此问题而生，它们：

  • 轻量级，资源消耗小。
  • 配置简单，通常只需一个配置文件或环境变量。
  • 活跃维护，能跟上 OpenAI API 和各大国产模型 API 的变更。 在本文中，我们将以 OpenAI-Forward 这个项目为例，因为它配置清晰，支持模型广泛。你可以在 GitHub 上搜索到它。

4. 核心流程拆解：四步实现无缝接入

整个接入过程可以清晰地分为四个步骤，我们将逐步拆解。

步骤一：部署协议适配器服务 这是整个架构的核心。我们将适配器服务部署在一台你能控制的服务器或本地机器上。它的作用是“冒充”OpenAI API 服务器。

步骤二：配置国产模型后端 告诉适配器，当收到请求后，应该将请求转发到哪个国产模型的哪个接口，并使用哪个 API Key 进行认证。

步骤三：修改 Codex 客户端配置 让 Codex 客户端（如 VS Code Copilot、Cursor、Claude Desktop 等）将其请求的目标地址，从官方的 api.openai.com 改为我们部署的适配器服务的地址。

步骤四：验证与测试 发起一个真实的代码补全或对话请求，检查整个链路是否畅通，响应是否符合预期。

下面，我们进入具体的实操环节。

5. 完整示例与代码实现

我们将以 OpenAI-Forward 工具和 DeepSeek 模型为例，展示完整的配置过程。假设我们的适配器服务将运行在 http://localhost:8080 。

5.1 安装与启动适配器服务

首先，通过 pip 安装 openai-forward 工具包。

# 安装 openai-forward
pip install openai-forward

安装完成后，我们可以通过命令行快速启动一个转发服务。但为了更灵活的配置，我们更推荐使用配置文件的方式。

创建一个名为 config.yaml 的配置文件：

# config.yaml
# 适配器服务监听的地址和端口
host: “0.0.0.0”
port: 8080

# 日志级别
log_level: “info”

# 模型路由配置
# 这里我们设置一个路由规则：所有请求都转发到 DeepSeek
routes:
  - path: “/v1” # 匹配所有 /v1 开头的请求
    backend: “deepseek” # 使用名为 ‘deepseek’ 的后端配置

# 后端服务配置
backends:
  deepseek:
    # DeepSeek 的 OpenAI 兼容端点 (请以官方最新文档为准)
    api_base: “https://api.deepseek.com/v1"
    # 你的 DeepSeek API Key
    api_key: “your-deepseek-api-key-here”
    # 可选：模型名称映射。将客户端请求的 ‘model’ 字段映射到 DeepSeek 支持的模型。
    # 如果不需要映射，可以删除此行，或设置为 null。
    model_mapping:
      “gpt-3.5-turbo”: “deepseek-chat”
      “gpt-4”: “deepseek-coder”

关键解释 ：

  • host: “0.0.0.0” 表示服务监听所有网络接口，方便同一网络下的其他设备访问。如果仅在本地使用，可改为 “127.0.0.1” 。
  • routes 定义了请求路径的转发规则。 /v1 匹配了所有 OpenAI 兼容 API 的请求。
  • backends 定义了真正的模型服务。 api_base 必须是国产模型提供的 OpenAI 兼容端点 。DeepSeek 官方提供了这样的端点。 api_key 需要替换成你自己的。
  • model_mapping 非常有用。因为 Codex 客户端可能固定请求 gpt-3.5-turbo 或 gpt-4 模型，而国产模型有自己的命名（如 deepseek-chat ）。这个映射表在转发前会自动修改请求体中的 model 字段。

保存配置文件后，使用以下命令启动服务：

# 指定配置文件启动服务
openai-forward run --config config.yaml

如果启动成功，你将看到类似以下的日志输出：

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

至此，你的本地“伪 OpenAI API 服务器”已经运行在 http://localhost:8080 了。

5.2 配置 Codex 客户端（以 VS Code 为例）

不同客户端的配置方式不同，但核心都是修改其 API Base URL。我们以 VS Code 中常见的 AI 插件为例。

对于 CodeGPT、Continue 等插件 ： 这些插件通常在设置中提供了 API Base URL 或 Custom Endpoint 的配置项。

  1. 打开 VS Code 设置 (Ctrl+,)。
  2. 搜索插件名称，如 “CodeGPT”。
  3. 找到 API Base URL 或类似字段。
  4. 将其值从 https://api.openai.com/v1 修改为 http://localhost:8080/v1 。
  5. 在 API Key 字段中，理论上可以填写任意值（因为认证已由适配器后端的 api_key 处理），但有些插件校验格式，可以填写一个符合格式的假 Key，如 sk-fake123456789 。 更佳实践 ：某些适配器支持传递 API Key ，此时可以填写一个在适配器配置中定义的转发密钥，具体需查看 openai-forward 的认证转发配置。

对于 Copilot 等深度集成的插件 ： 像 GitHub Copilot 这类插件，其端点通常是硬编码或通过复杂机制配置，直接修改比较困难。此时，一种系统级的方案是修改 hosts 文件，将 api.openai.com 域名解析到你部署的适配器服务的 IP 地址。 此方法需谨慎，可能影响其他使用 OpenAI 服务的应用。

更通用的方法：使用环境变量 许多遵循 OpenAI Python 库规范的客户端会读取 OPENAI_API_BASE 环境变量。

# 在启动 VS Code 的终端中设置环境变量
export OPENAI_API_BASE=“http://localhost:8080/v1”
code . # 然后在这个终端里启动 VS Code

这样，VS Code 内部插件使用的 OpenAI 库就会自动将请求发送到我们指定的地址。

5.3 使用 Python 代码进行测试验证

在配置好客户端之前，我们可以先用一个简单的 Python 脚本直接测试适配器服务是否工作正常。

创建一个测试文件 test_adapter.py ：

# test_adapter.py
from openai import OpenAI

# 注意：这里指向我们本地运行的适配器服务
client = OpenAI(
    base_url=“http://localhost:8080/v1”, # 关键配置：指向适配器
    api_key=“fake-key-or-your-forward-key”, # 如果适配器需要认证，则填对应的key
)

# 发起一个简单的聊天补全请求
try:
    response = client.chat.completions.create(
        model=“gpt-3.5-turbo”, # 客户端请求的模型名，会被适配器映射
        messages=[
            {“role”: “system”, “content”: “你是一个编程助手。”},
            {“role”: “user”, “content”: “用Python写一个快速排序函数。”}
        ],
        stream=False, # 先测试非流式
        temperature=0.7,
    )
    print(“测试成功！”)
    print(f”模型回复：{response.choices[0].message.content}“)
except Exception as e:
    print(f”请求失败：{e}“)

运行这个脚本：

python test_adapter.py

如果一切配置正确，你将看到 DeepSeek 模型生成的快速排序 Python 代码。这证明从客户端请求到适配器转发，再到国产模型返回结果，整个链路已经打通。

6. 运行结果与效果验证

成功运行上述测试脚本后，你得到的输出应该类似于以下内容（具体代码可能因模型版本而异）：

测试成功！
模型回复：当然，这是一个经典的快速排序函数的 Python 实现：

```python
def quicksort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[len(arr) // 2]
    left = [x for x in arr if x < pivot]
    middle = [x for x in arr if x == pivot]
    right = [x for x in arr if x > pivot]
    return quicksort(left) + middle + quicksort(right)

# 示例用法
if __name__ == “__main__”:
    my_list = [3, 6, 8, 10, 1, 2, 1]
    sorted_list = quicksort(my_list)
    print(f”原始列表：{my_list}“)
    print(f”排序后列表：{sorted_list}“)

这个实现使用了列表推导式，思路清晰易懂。注意，这不是原地排序的版本。如果你需要原地排序的版本，我可以为你提供。


**如何验证成功？**
1.  **响应结构**：`response` 对象的结构应符合 OpenAI API 规范（如 `response.choices[0].message.content` 存在且包含文本）。
2.  **内容相关性**：返回的内容确实是关于“快速排序”的 Python 代码，这证明请求中的 `messages` 上下文被正确传递给了国产模型。
3.  **日志确认**：查看运行 `openai-forward` 服务的终端窗口，应该能看到详细的转发日志，包括接收到的请求和转发状态码，这能帮助你确认转发过程是否顺利。

**进阶验证：流式输出测试**
许多编程助手依赖流式输出（Streaming）来实现打字机效果。修改测试脚本，启用流式输出：

```python
# test_adapter_stream.py
from openai import OpenAI

client = OpenAI(base_url=“http://localhost:8080/v1”, api_key=“fake-key”)

stream = client.chat.completions.create(
    model=“gpt-3.5-turbo”,
    messages=[{“role”: “user”, “content”: “简述 Python 的 GIL。”}],
    stream=True, # 启用流式
    temperature=0.5,
)

print(“开始流式接收：”)
for chunk in stream:
    if chunk.choices[0].delta.content is not None:
        print(chunk.choices[0].delta.content, end=“”, flush=True) # 逐字打印
print(“\n流式接收结束。”)

运行此脚本，你应该看到回答内容是一段段实时显示出来的，而不是一次性全部出现。这验证了适配器对流式传输的支持是完整的，这对于 IDE 插件的流畅体验至关重要。

7. 常见问题与排查思路

在实践过程中，你可能会遇到一些问题。下表列出了常见问题及其解决方法：

问题现象 可能原因 排查方式 解决方案
启动 openai-forward 失败，提示端口被占用。 端口 8080 已被其他程序使用。 运行 lsof -i:8080 (Linux/macOS) 或 netstat -ano | findstr :8080 (Windows) 查看占用进程。 1. 终止占用进程。2. 修改 config.yaml 中的 port 为其他空闲端口（如 8081）。
测试脚本报错 ConnectionError 或超时。 1. 适配器服务未启动。
2. 防火墙/网络策略阻止连接。
3. 配置的 host 不正确。		 1. 检查 openai-forward 进程是否在运行。
2. 使用 curl http://localhost:8080/health (如果适配器提供健康检查) 或 curl http://localhost:8080/v1/models 测试服务可达性。
3. 检查 config.yaml 中的 host 。		 1. 确保服务已启动。
2. 检查本地防火墙设置。
3. 本地测试时 host 建议用 127.0.0.1 。
测试脚本返回错误，如 404 Not Found 或 Invalid API Key 。 1. 请求路径 ( base_url ) 配置错误。
2. 后端 api_base 配置错误。
3. 国产模型 API Key 无效或未传递。		 1. 查看适配器日志，确认收到的请求路径。
2. 核对 config.yaml 中 backends 下的 api_base ，确保是完整的 OpenAI 兼容端点 URL。
3. 检查 api_key 是否正确，并确认该 Key 有调用对应模型的权限。		 1. 确保 base_url 以 /v1 结尾。
2. 查阅国产模型官方文档，确认其 OpenAI 兼容端点的确切地址。
3. 在模型官方控制台重新生成或检查 API Key。
请求成功，但返回内容乱码或非预期。 1. 模型映射 ( model_mapping ) 错误，导致请求了不支持的模型。
2. 国产模型 API 的响应格式与 OpenAI 不完全兼容。		 1. 查看适配器日志，看转发给后端的实际 model 参数是什么。
2. 直接使用 curl 或 Postman 调用国产模型原生 API，检查其响应格式。		 1. 修正 model_mapping ，或关闭映射，在客户端直接使用国产模型的模型名。
2. 可能需要调整适配器的版本，或寻找其他兼容性更好的适配工具。
VS Code 插件提示 “Invalid API Key” 或无法连接。 1. 插件未正确读取环境变量。
2. 插件对 API Key 格式有强校验。
3. 适配器服务需要特定的认证头。		 1. 确认启动 VS Code 的终端已设置 OPENAI_API_BASE 。
2. 尝试在插件设置中，API Key 字段填写一个符合 sk- 格式的字符串（即使它是假的）。
3. 查看适配器文档，了解其认证转发机制。		 1. 尝试重启 VS Code。
2. 在适配器配置中启用并配置认证转发，然后在插件中使用适配器分配的 Key。
3. 考虑使用支持修改 Base URL 更灵活的插件。
流式输出不工作，响应一次性返回。 1. 适配器配置或版本不支持流式转发。
2. 国产模型后端不支持或未启用流式。		 1. 检查 openai-forward 日志，查看转发请求中是否包含 “stream”: true 。
2. 查阅国产模型 API 文档，确认其 /chat/completions 端点是否支持 stream 参数。		 1. 确保使用最新版 openai-forward 。
2. 在国产模型控制台或文档中确认流式功能已开通。

8. 最佳实践与工程建议

将 Codex 类工具接入国产模型用于生产环境或团队协作时，以下最佳实践能帮助你构建更稳定、安全、高效的体系。

8.1 安全与认证

  • 隔离适配器密钥 ：不要在客户端配置中直接使用国产模型的原始 API Key。应该使用适配器提供的二次鉴权机制（如果支持），为每个客户端或用户分配一个中间密钥，由适配器负责映射到真实 Key。这样便于权限管理和吊销。
  • 使用 HTTPS ：在生产环境，务必为适配器服务配置 SSL/TLS 证书（例如使用 Nginx 反向代理并配置 HTTPS），避免 API Key 和传输内容被窃听。
  • 限制访问 IP ：在适配器服务或前置的 Web 服务器（如 Nginx）上配置防火墙规则，只允许受信任的 IP 段（如公司内网）访问，防止服务被滥用。

8.2 稳定性与高可用

  • 进程守护 ：使用 systemd (Linux)、 supervisord 或 pm2 等工具来管理 openai-forward 进程，确保服务崩溃后能自动重启。
  • 多实例与负载均衡 ：如果团队用户量大，可以部署多个适配器实例，并使用 Nginx 等负载均衡器进行分发，提高并发处理能力。
  • 后端熔断与降级 ：适配器应具备一定的容错能力。当某个国产模型后端服务不稳定或超时时，可以快速失败或切换到备用后端（如果配置了多个）。一些高级的适配器工具支持此类功能。

8.3 监控与日志

  • 结构化日志 ：配置 openai-forward 输出 JSON 格式的日志，便于使用 ELK（Elasticsearch, Logstash, Kibana）或 Loki 等日志系统进行收集、检索和分析。
  • 关键指标监控 ：监控适配器服务的请求量、响应时间、错误率。同时监控国产模型 API 的调用额度和延迟。
  • 审计日志 ：记录所有请求的元数据（如请求时间、客户端 IP、模型、Token 使用量），以满足安全审计和成本分摊的需求。

8.4 配置管理

  • 环境变量化 ：将 config.yaml 中的敏感信息（如 api_key ）替换为环境变量引用。例如： 
    backends:
  deepseek:
    api_base: ${DEEPSEEK_API_BASE}
    api_key: ${DEEPSEEK_API_KEY}
    然后在启动时注入环境变量。
  • 版本控制 ：将非敏感的配置文件纳入 Git 版本控制，方便跟踪变更和团队共享。

8.5 客户端部署策略

  • 统一配置分发 ：对于团队，可以编写统一的客户端配置指南脚本，或使用内部工具自动为成员的 IDE 配置正确的 OPENAI_API_BASE 和环境变量。
  • 提供备选方案 ：可以同时配置多个后端（如 DeepSeek、GLM），并在适配器层面或客户端层面提供简单的切换机制，以应对某个服务商不可用的情况。

遵循这些实践，你就能将一个简单的“对接”方案，升级为一个适合团队使用的、稳健的企业级 AI 编程辅助基础设施。

9. 总结与后续学习方向

通过本文的详细拆解，你应该已经掌握了让 Codex 类编程助手直接、优雅地使用国产大模型的核心方法。我们回顾一下关键路径： 理解协议 -> 部署轻量适配器 -> 配置模型路由 -> 修改客户端指向 。这个方案的精髓在于“透明”和“直接”，去除了冗余的中转层，让开发工具能以最原生的方式利用国产算力。

更重要的是，这个过程揭示了一个通用模式：任何遵循 OpenAI API 标准的客户端，理论上都可以通过同样的方式接入任何提供兼容接口的模型服务。这为我们在 AI 工具链中实现“供应商无感”切换提供了可能。

接下来，你可以从以下几个方向进行更深入的探索：

  1. 探索其他适配器与方案 ：除了 openai-forward ，社区还有像 LLMProxy , LocalAI 等更多功能丰富的项目。它们可能提供了模型管理、缓存、配额限制、更细粒度的路由等高级特性，适合更复杂的场景。
  2. 深入研究协议细节 ：尝试阅读 OpenAI API 和国产模型 API 的官方文档，理解它们在参数支持（如 function calling , json_mode ）、响应格式上的细微差异。这能帮助你在遇到兼容性问题时，有能力进行更深层次的调试或定制。
  3. 构建企业内部 AI 编码平台 ：将本文的方案与内部用户系统、计费系统结合，可以打造一个团队私有的、可控的 AI 编程助手平台。你可以集成多个模型，让开发者根据任务类型自由选择。
  4. 性能调优与成本控制 ：监控不同模型在不同任务（如代码补全、注释生成、代码审查）上的效果、延迟和 Token 消耗。通过数据分析，制定最优的使用策略，在效果和成本间取得平衡。

技术的价值在于解决真实问题。希望这篇从原理到实践的长文，能帮助你顺利跨过接入国产模型的门槛，不仅“能用”，更能“用好”，真正提升你和团队的开发效率与创造力。如果在实践中遇到新的问题，不妨回到协议原理和日志分析这两个基本点，它们往往是破解复杂问题的钥匙。建议收藏本文，以备在搭建和调试过程中随时查阅。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区