用 Codex 配置 NVIDIA Jetson：远程 AI 开发环境搭建全流程

边缘 AI 开发的痛点之一，是设备初始化配置繁琐——SSH、Wi-Fi、驱动、容器运行时、GPU 访问验证，每一步都可能卡住新手。这篇教程演示了一种更省心的方式：借助 Codex（AI 命令行工具与桌面应用）从 Mac 远程配置一台 NVIDIA Jetson，让 AI 代理代为生成命令、验证连接、安装依赖，最终把设备准备到可以直接运行 AI 应用的状态。

整个流程覆盖了从物理连接到 GPU 容器测试的完整链路。下面按实际操作顺序拆解每个关键环节。

通过 USB 建立 SSH 访问

起点是 Jetson 同时连接显示器和 Mac（通过 USB 直连）。第一步不是急着联网，而是先打通本地的安全通道。作者让 Codex 协助配置 USB 连接上的 SSH 访问，Codex 会直接给出所需命令并打开终端会话。

登录 Jetson 后在本地输入密码，Codex 随即在 Mac 上创建一个专用的 SSH 密钥，并把公钥添加到 Jetson。这样做的好处很直接：之后无论是作者本人还是 Codex，都能免密码安全连接设备。配置完成后，Codex 会主动检查连接状态，确认密钥已正确安装、测试通过。

这一步奠定了后续所有远程操作的基础——先有可靠的本地通道，再去碰网络配置，即便联网环节出错也不至于失联。

Jetson 设备通过 USB 暴露 SSH 访问依赖一项称为 USB Gadget / RNDIS（远程网络驱动接口规范） 的技术：设备将自身模拟为 USB 以太网网卡，主机端识别后自动分配一个本地链路 IP（通常是 192.168.55.100/192.168.55.1 这个地址对），从而在无需 Wi-Fi 或有线路由器的情况下建立点对点网络连接。这种方式在设备首次上电、尚未配置任何网络时尤为有价值，相当于一条"带外管理通道"（out-of-band channel）。在嵌入式和边缘设备领域，类似思路也出现在树莓派的 USB OTG 模式、工业设备的 Console 串口等场景中——核心逻辑都是：在主通道（网络）建立之前，先保有一条不依赖主通道的访问路径。

连接 Wi-Fi 并保留 USB 双通道

联网环节体现了一个值得学习的运维思路：保留冗余。作者希望把 Jetson 接入 Wi-Fi，但同时坚持保留 USB 连接作为后备，以防网络配置出问题导致设备无法访问。

把网络信息交给 Codex 后，它准备好连接命令并执行。Jetson 上线后，Codex 检查新分配的 IP 地址，确认设备会自动重连网络，还测试了互联网连通性，并再次验证 USB 上的 SSH 依然可用。

至此，设备拥有两条到达路径：USB 线缆和 Wi-Fi。这种双通道设计在边缘设备调试中非常实用，尤其当你无法随时物理接触设备时，一条备用通道能省去大量重装系统的麻烦。

安装 Codex CLI 并注册远程项目

设备联网后，作者让 Codex 在 Jetson 上安装 Codex 命令行工具，并准备好项目文件夹。安装完成后进入认证环节——Codex 提供一个链接和一次性验证码，作者在 Mac 浏览器中登录账户并输入验证码，就完成了对 Jetson 上 codex-cli 的授权。

这里的设计细节在于：整个授权过程不需要在设备上输入账户密码，避免了凭据暴露在边缘设备上的风险。授权后 Codex 验证 CLI 已登录、项目文件夹就绪。

接下来把项目接入 Codex 桌面应用：注册 Jetson 的 SSH 连接，并指向刚创建的项目文件夹。完成后，"Jetson AI demo" 项目出现在侧边栏，绿色指示灯表示设备已连接可用。

这意味着之后可以在统一界面里操作 Jetson 上的文件、运行命令，不必在多个终端窗口和工具之间来回切换。对远程开发体验来说，这是效率上的明显提升。

安装 Jetson 设备技能与 GPU 验证

在安装更多东西之前，Codex 先检查了 Jetson 上已有的环境。随后作者让它安装 NVIDIA Jetson 设备技能（device skills）——这些技能提供 Jetson 专属的操作指引和辅助工具，用于检查设备状态、管理内存、以及选择 AI 模型的运行方式。

完成 demo 项目的关键一步是搞定 GPU 访问。这里有个重要的架构选择：应用容器自带 CUDA 库和 AI 依赖，因此宿主机上不需要安装完整的 JetPack SDK。Jetson 只需要兼容的 NVIDIA 驱动和 GPU 容器运行时。Codex 检查这些前置条件后，只提出缺失的部分。

检查结果显示大部分配置已经到位，唯一缺的是给 Jetson 用户授予运行 Docker 的权限。由于这会改动系统，Codex 在执行前先展示了确切的命令，由作者本地输入密码运行，再重连使新权限生效。

最后的验证最具说服力：Codex 运行一个小型 CUDA 容器作为测试，容器成功检测到 Jetson Orin 处理器、初始化 CUDA，并完成一次快速的 GPU 内存测试。临时容器测试后被删除，但镜像保留以便复用。

这里涉及一个关键的架构概念值得展开：JetPack SDK 是 NVIDIA 为 Jetson 平台提供的完整软件栈，包含 CUDA 工具链、cuDNN、TensorRT、计算机视觉库等，传统安装方式需要通过 SDK Manager 刷写或配置，体积大且依赖关系复杂。而基于容器的开发模式（即文中采用的方式）将 CUDA 运行时和 AI 框架全部打包进应用容器镜像，宿主机只需保留最小化的驱动层——通常是 L4T（Linux for Tegra）内核驱动和 NVIDIA 容器运行时（nvidia-container-runtime）。这套分层设计的好处是：不同应用可以携带各自版本的 CUDA 和框架，互不干扰，且宿主系统保持精简、易于维护。NVIDIA 在 NGC（GPU 加速容器目录）上提供了大量 Jetson 专用的预构建容器镜像，覆盖从基础 CUDA 环境到 PyTorch、ROS 等完整框架，是这种工作流的重要基础设施。

这套流程说明了什么

走完全程后，这台 Jetson 已经具备进入应用开发阶段的所有条件：安全的 SSH 与 Wi-Fi 双通道、注册好的远程项目、安装完成的设备技能，以及通过容器验证的 GPU 访问。

真正值得关注的，不只是具体命令，而是 AI 代理在设备配置中扮演的角色——它不是无脑执行，而是先探测现有环境、只补缺失项、在改动系统前展示命令供人确认。这种"人在回路"的交互方式，让自动化配置既高效又可控，降低了边缘 AI 开发的入门门槛。对想在 Jetson 这类设备上快速起步的开发者来说，是一条省时省力的实践路径。