手机也能跑编码 Agent：Devx 在 Termux 上的双模式工作流与安全边界
把 Android 手机当成临时开发机，真正困难的往往不是编辑几行代码，而是让终端里的 AI 编码工具稳定完成“理解需求—修改文件—运行检查”这一整条链路。Devx（仓库名 Termux-Dev）选择了一个很直接的入口：它是一个用 TypeScript 编写、通过 npm 分发的终端 AI 编程 Agent，重点支持 Android Termux，同时也支持 Windows、macOS 和 Linux。它的价值不在于把手机变成完整 IDE，而在于把一个可切换的计划层和执行层放进同一个终端会话。
这篇文章依据项目当前仓库的 README、package.json 和许可证文件整理。Devx 的仓库是 apvcode/Termux-Dev，npm 包名是 termux-dev，命令行入口同时提供 devx 与 termux-dev 两个命令；当前 package.json 标出的版本是 1.1.2，运行时要求 Node.js 20 或更高版本，许可证为 MIT。
它解决的不是“手机写代码”
在手机上使用 Agent，最容易遇到三个问题。第一，终端窗口小，需求、计划和命令输出混在一起，误操作的代价比桌面环境高。第二，Agent 如果一上来就获得写文件和执行 Shell 的能力，用户很难在狭窄的屏幕上判断它准备做什么。第三，临时开发机通常缺少完整的项目上下文，下一次打开会话时，Agent 不知道上次改了什么、为什么这样改。
Devx 的设计针对了这三点。它把交互分成 PLAN 和 AGENT 两种模式：PLAN 更像需求澄清和方案设计，AGENT 才执行文件修改、终端命令和包安装。计划确认后，界面提供 Go 入口再进入执行阶段。项目还会在工作区使用 .devx/memory.md 保存项目记忆，并支持 /undo 做快照回滚。对移动端来说，这些机制比“多一个炫酷聊天界面”更实用，因为它们降低了上下文丢失和误改文件的概率。
不过，PLAN 模式不是安全沙箱，也不是形式化验证器。真正执行前仍然要检查工作目录、Git 状态和命令内容。Agent 能执行 Shell，就意味着它继承了当前用户的文件权限；手机上的 SSH 密钥、环境变量和共享存储同样可能被访问。
在 Termux 中安装
项目 README 给出的安装路径是全局安装 npm 包。先在 Termux 中确认 Node.js 版本满足要求，再安装并启动：
node --version npm install -g termux-dev devx
首次运行会打开交互式设置流程，用来选择 AI 提供商并配置 API key。这里有一个容易忽略的事实：Devx 本身是终端客户端，不等于它自带模型服务。模型提供商、网络可达性和 API 费用仍由使用者负责。不要把真实密钥直接写进项目文件，也不要把包含密钥的终端截图上传到 issue 或聊天群。
如果你希望从源码了解实现，也可以按 README 给出的开发流程操作：
git clone https://github.com/apvcode/Termux-Dev.git cd Termux-Dev npm install npm run build npm start
这段流程适合调试项目本身，不是普通用户的首选安装方式。仓库的 package.json 将 start 指向 node ./bin/devx.js，发布包则通过 bin 字段把 devx 和 termux-dev 映射到同一个入口。因此，遇到命令找不到时，先检查 npm 的全局 bin 路径，而不是马上重复安装。
一个适合手机的最小工作流
不要在第一次运行时就让 Agent 重构整个项目。更稳妥的方式是从一个小任务开始，例如给已有 Node.js 项目补一个输入校验函数。
第一步，在项目目录启动 Devx，并明确要求先做计划，不要改文件：
/plan 请检查当前项目结构，为配置文件增加环境变量校验。先列出将读取的文件、验证规则和测试命令，不要写入任何文件。
第二步，检查计划中是否包含了真实存在的文件和可执行的测试命令。如果计划把不存在的 tests/ 目录当成既有目录，或者把项目的包管理器写错，就在 PLAN 阶段纠正。确认后再使用界面中的 Go，或者切换到执行模式：
/agent 根据刚才确认的计划，只修改配置加载和测试文件。完成后运行项目已有的检查命令，并汇报修改文件、命令输出和未解决问题。
README 明确列出了 /plan、/agent 和 /init 等交互命令。/init 用于在项目根目录生成 AGENTS.md 开发指南；如果项目已经有团队维护的 Agent 规则，先读取并合并约束，不要让初始化动作覆盖现有规范。PLAN 与 AGENT 之间也可以使用 Tab 切换，但“能切换”不代表草稿已经经过事实检查，切换后仍要重新确认当前目录和目标文件。
第三步，查看差异，再决定是否保留：
git status --short git diff -- config src test
如果这是一个没有 Git 的临时目录，可以先复制工作区或创建本地提交。Devx 的 /undo 适合撤销它创建的快照，但不应替代 Git。可恢复性最好由两层保证：Agent 自己的快速回滚用于交互试错，Git 用于审计和长期恢复。
代码检查与预览能力怎么理解
项目 README 宣称内置了针对 TypeScript、JavaScript、Python 和 Rust 的检查流程，包括 tsc、node --check、Python 编译检查以及 cargo check。这类能力的正确理解是“Agent 可以在回合结束前尝试运行相应检查”，不是“任何项目都自动拥有完整测试覆盖”。它是否能成功，取决于当前目录是否安装了编译器、项目配置是否完整，以及依赖是否已经准备好。
同样，README 提供了 Web 预览能力：项目可在 3000 端口预览网页应用或 HTML5 游戏，并在 Android 上通过 termux-open-url 打开。移动端使用时，建议把预览服务绑定范围、端口暴露方式和 Termux 网络权限先确认清楚。只为本机查看的开发服务器，不应为了方便而暴露到公共网络；尤其不要把带有管理接口、调试信息或未完成鉴权的服务直接转发到互联网。执行预览前，还可以先让 Agent 只输出“将要运行的命令清单”，把联网、安装依赖或写入系统目录的动作单独标出；这个习惯能让手机端审核更有节奏，也方便在流量受限时删掉不必要的步骤。
多模态视觉输入也被列为项目能力之一，但它依赖所选模型提供商和当前客户端配置。写工作流时最好把它当作“可选输入通道”，而不是所有模型都支持的固定保证。对于手机截图，发送前应遮挡 API key、个人信息、内部域名和私有代码。
与桌面编码 Agent 的取舍
Devx 最适合三种场景。第一，电脑不在手边，需要用手机查看一个小项目、改配置或处理简单故障。第二，已经习惯 Termux，希望让 Agent 代替重复的文件浏览、命令执行和基础检查。第三，需要一个带计划确认和回滚入口的轻量 CLI，而不是启动完整 IDE。
它不适合作为无审查的生产部署机器人，也不适合直接接管包含生产凭据的目录。Android 的存储权限、Node.js 原生依赖、网络状态和后台进程限制，都可能让桌面上顺畅的工作流在手机上失效。跨平台支持说明项目提供了相应入口，不代表每个平台拥有完全相同的终端体验。
另一个现实取舍是项目成熟度。当前 GitHub API 显示仓库只有少量 stars，虽然 README 功能说明很完整，但这不能替代真实项目中的长期稳定性验证。把 Devx 引入日常工作前，应固定 npm 版本、在无敏感数据的测试仓库演练，并记录模型配置、命令权限和回滚办法。对于重要修改，仍然由人审查 git diff 和测试结果。
结语：把“先计划”当成手机端默认策略
Devx 的核心思路可以概括为：用 PLAN 模式把需求变成可检查的行动列表，再由 AGENT 模式执行，最后用检查命令、差异和回滚收尾。它没有消除终端 Agent 的权限风险，却把最容易失控的“从一句话直接跳到大规模修改”拆成了几个可观察步骤。
如果你的目标是在 Android 上处理小型修复、配置调整或原型任务，Termux 加 Devx 是一个值得试验的组合。最安全的起点不是让它“自动完成一切”，而是给它一个干净的测试仓库、一个范围明确的任务和一个必须经过人工确认的 PLAN。这样，手机才是便携的开发终端，而不是一把无法追踪的远程 Shell。