想亲手参与AI相框开发？这篇文章带你从零开始，将OpenAI Codex装进一块Android开发板，打造一个能自主调试的AI硬件工作台。
核心内容：
1. 将AI开发环境移植到Android硬件的背景与思路
2. 在Orange Pi 5 Max上部署Termux和开发工具链的详细步骤
3. 构建一个能直接参与项目开发与调试的设备端工作台

我把 Codex 装进了 Pi 5 Max：一块 Android 开发板，开始自己参与 AI 相框开发

如果说电脑是 AI 项目的“办公室”，那真实硬件就是它的“施工现场”。

这一次，我没有只在 Mac 上写代码、跑脚本、模拟设备效果，而是把开发环境直接搬进了一块 Orange Pi 5 Max Android 设备里。

目标很简单，也很有意思：

让这块 Android 开发板自己跑起 Termux、Node.js、Python、Rust、Git，最后再装上 OpenAI Codex CLI。

这样一来，它就不只是一个被动显示内容的屏幕，而是可以直接参与 AI 相框项目开发、调试、排障和验证的设备端工作台。

◆为什么要这么折腾？

AI 相框听起来像一个“展示照片”的产品。

但真正做起来，它更像一个小型的边缘智能终端：

• 要能管理本地图片、视频和文案素材。
• 要能生成播放列表。
• 要能运行展示页面或播放器。
• 要能排查网络、缓存、文件权限和设备状态。
• 以后还可能接入家庭相册、语音、传感器和 Agent 自动化。

如果所有调试都只发生在电脑上，等到上真机时，很多问题都会变成“它在我电脑上明明可以”的经典现场。

所以这次的思路是：把 Codex 带到设备上。

让 AI 不只在桌面开发环境里给建议，而是在真实硬件里参与排查和改代码。

◆第一步：确认我们操作的是哪一台设备

这一步看起来很基础，但它决定了后面会不会误伤别的 Android 设备。

本次目标设备是：

ADB 地址：192.168.99.73:XXXX 型号：orangepi5max 产品：rk3588_t Android：13 架构：arm64 内核：Linux 5.10.157 内存：约 8GB 屏幕：1024x600 GPU/OpenGL：OpenGL ES 3.2

本机 ADB 路径：

/Users/XXX/Library/Android/sdk/platform-tools/adb

同一局域网里还出现过另一台 Android 设备，所以所有 ADB 操作都明确带上 -s 192.168.99.73:5555。

在硬件开发里，这不是洁癖，是保命习惯。

◆第二步：给 Android 装上 Termux

Pi 5 Max 的 Android 系统里原本没有 Termux，所以直接安装 F-Droid 官方签名版本。

版本信息：

包名：com.termux 版本：0.118.3 versionCode：1002 架构：arm64-v8a

安装完成后，Termux Activity 可以正常启动。也就是说，这块 Android 开发板已经有了一个接近 Linux 的终端入口。

接下来就可以在设备上准备开发工具链。

◆第三步：把基础工具链补齐

Termux 初始化后，先更新包，再安装基础工具：

pkg update -y pkg install -y curl tar coreutils pkg install -y nodejs-lts python rust git

最终验证到的版本是：

Node.js v24.15.0 Python 3.13.13 rustc 1.95.0 cargo 1.95.0 git version 2.54.0

这里有一个小插曲。

原本希望精确使用 Node.js v24.14.1，但 Termux 当前可维护的 LTS 包安装到的是 v24.15.0。中间也短暂试过当前版 nodejs，会安装到 v26.2.0。

最后选择 nodejs-lts。

做硬件端环境，稳定和可维护比“版本数字刚好一致”更重要。

◆第四步：安装 Codex CLI

优先尝试官方 standalone installer：

curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh

安装器在 Termux 里识别为：

Linux (ARM64)

安装后得到：

Codex CLI 0.138.0 安装路径：~/.local/bin/codex

把路径加到当前会话：

export PATH="$HOME/.local/bin:$PATH"

验证：

codex --version

输出：

codex-cli 0.138.0

到这里，事情已经成功了一半。

但 Android/Termux 毕竟不是标准 Linux 发行版，后面还有一个平台识别的小坑。

◆第五步：补上 npm 方式，绕过 Android 平台识别问题

为了让 Termux/Android 下的可执行文件更稳，后续又补了一次 npm 安装：

npm install -g @openai/codex

问题来了：Termux 会把平台识别成 android，导致 npm 可选 native 包不会按普通 Linux 方式自动安装。

处理方式是强制补装官方 Linux ARM64 native 包：

npm install -g --force @openai/codex-linux-arm64@npm:@openai/[email protected]

最终验证路径：

/data/data/com.termux/files/usr/bin/codex

最终版本：

codex-cli 0.138.0

这一步的意义是：以后在设备端调试，不用担心某次 PATH 或 native 包选择导致命令不可用。

◆第六步：登录认证，遇到真正的坑

原计划使用设备码登录：

codex login --device-auth

但在 Pi 5 Max Termux 中多次失败，错误指向设备码接口请求失败：

Error logging in with device code: error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

尝试过 CA 证书路径、网络连通性和 DNS 方向排查后，设备码登录仍没有成功。

最后采用了本机已有 Codex 登录缓存迁移方式：

源文件：/Users/XXX/.codex/auth.json 目标位置：/data/data/com.termux/files/home/.codex/auth.json

权限设置：

chmod 700 ~/.codex chmod 600 ~/.codex/auth.json

这里必须强调：这不是通用首选方案。

通用首选仍然是设备码登录。只有在设备码网络请求失败，并且本机已经有可信 Codex 登录状态时，才考虑迁移认证缓存。

认证文件不能写进文档、Git 仓库、聊天记录或任何项目文件。

◆第七步：验证 Codex 已经在设备端跑起来

认证完成后，在 Pi 5 Max Termux 中执行：

command -v codex codex --version codex doctor --summary codex debug models

关键结果：

• codex 命令可以被找到。
• 版本为 codex-cli 0.138.0。
• codex debug models 能返回模型能力 JSON。
• 返回内容包含上下文窗口、输入模态、搜索工具支持等字段。

这说明 Codex CLI 已经能读取认证，并且可以访问 OpenAI 服务。

换句话说，Pi 5 Max 不再只是一个“被电脑控制的屏幕”，它已经具备了设备端 AI 开发节点的雏形。

◆接下来，AI 相框可以怎么跑？

后续可以在 Pi 5 Max 上建立一个设备端项目目录：

mkdir -p ~/ai-frame cd ~/ai-frame codex "检查当前目录，并帮我规划 AI 相框的设备端项目结构"

建议的目录结构是：

~/ai-frame/   content/        # 图片、视频、文案、展示素材   scripts/        # 拉取内容、生成播放列表、清理缓存等脚本   renderer/       # 相框页面或播放器逻辑   agent/          # Codex/LLM 驱动的决策逻辑   logs/           # 运行日志   config/         # API、设备、显示、网络配置，不提交密钥

第一阶段不用一下子做得很复杂。

最小闭环可以是：

1. 设备启动后进入一个固定展示页面。
2. 本地 content/ 目录里的图片可以轮播。
3. 用脚本生成 playlist.json。
4. 用 Codex CLI 辅助修改脚本和排查运行错误。
5. 再逐步接入联网内容、家庭相册、语音或传感器输入。

这样做的好处是，每一步都发生在真实硬件上。

不是先幻想一个完整系统，而是让设备自己先跑起来。

◆这次最值得记住的几个坑

第一，ADB 网络连接可能不稳定。

安装过程中 Pi 5 Max 一度从 ADB 设备列表里消失，ping 和 ARP 也出现过异常。恢复后，192.168.99.73 可以 ping 通，但 ADB TCP 5555 一开始仍然 Connection refused。

所以不要省略确认步骤：

adb connect 192.168.99.73:5555 adb devices -l

第二，Termux 不是标准 Linux。

它足够强，但在平台识别、native 包选择、路径权限和登录请求上，都会有 Android 自己的差异。

第三，认证文件必须谨慎处理。

不要把 auth.json、API Key、Cookie 或 token 写入项目，也不要为了“方便复现”把它们贴到文档里。

第四，真实设备开发一定要带设备 ID。

多台 Android 设备同时在线时，ADB 命令不带 -s 就是在和运气合作。

◆结论：这块屏幕开始变得不一样了

这次的结果是：

• Pi 5 Max Android 可通过 ADB 访问。
• Termux 已安装。
• Node.js、Python、Rust、Git 已安装。
• Codex CLI 已安装。
• Codex CLI 版本为 0.138.0。
• Codex CLI 已完成认证。
• codex debug models 已能返回 OpenAI 模型能力信息。

它还不是一个完整的 AI 相框产品。

但它已经从“一块能显示内容的 Android 板子”，变成了“可以在设备端开发、调试、验证 AI 相框逻辑的边缘节点”。

这一步很关键。

因为真正的 AI 硬件产品，不是 PPT 里的能力堆叠，而是一个个能在真实设备上跑通的小闭环。

电脑负责规划，设备负责验证。

当 Codex 也能进入设备现场，AI 相框项目就开始离真实产品更近了一点。

登录查看剩余 70% 内容