这是“远程智能体工作流”系列的第五篇。

最初搭建这套远程 AI 开发环境时，我想解决一个很实际的问题：

离开 Mac 以后，怎样让本地 Codex 继续干活？

于是有了第一层方案：

手机 -> Tailscale -> SSH -> Mac -> tmux -> Codex

后来我发现，手机上的 SSH 不适合充当日常操作入口，于是又搭了一个 Telegram 控制面：

手机 -> Telegram Bot -> 本地 Codex 运行时 -> 指定代码仓库

再往后，我意识到背后还有一条更根本的原则：

放在代码仓库里，不要放在聊天里。

代码仓库必须保存持久的项目记忆。

更准确地说，它应该承载项目记忆、运行约定和反馈机制。

走到这一步，一个很自然的问题随之而来：

既然官方已经推出 Codex Mobile，自定义远程智能体工作流还有必要吗？

我的答案是：有。但理由变了。

它的价值不再只是让人远程接入 Codex。

更重要的是让 Codex 按照项目自己的方式工作。

Codex Mobile 解决了什么 链接到标题

2026 年 5 月 14 日，OpenAI 宣布在 ChatGPT 移动应用中以预览形式推出 Codex。

通过官方移动端，用户可以随时在手机上接入 Codex。按照 OpenAI 的介绍，你可以跨线程处理任务、检查输出、批准命令、切换模型、发起新任务，还能实时收到终端输出、差异内容、测试结果、截图和审批请求等更新。

OpenAI 还介绍了 Codex Relay 层：不同设备可以借此访问受信任的机器，而不必把机器直接暴露在公网中。

这一点很重要。

这意味着，远程控制中的大部分通用问题，官方产品已经解决了。

我此前试图用下面这套结构实现近似的效果：

Telegram 移动端
  -> Telegram 服务器
  -> 本地轮询机器人
  -> Codex 运行时

现在，官方提供的架构是：

ChatGPT 移动端
  -> Codex Relay
  -> 受信任的机器
  -> Codex 应用或运行时

对很多人来说，这才是合适的答案。

它是一体化的。

它理解 Codex 线程。

它支持审批。

它能呈现 Codex 所在机器上的实时上下文。

它还省去了大量串联各个环节的代码。

这是好事。

Telegram 机器人真正教会了我什么 链接到标题

现在回头看，Telegram 机器人不只是一件工具。

它还是控制面的原型。

为了把它做出来，我不得不拆开不同层次的问题：

  • 移动端界面
  • 授权
  • 代码仓库选择
  • 任务执行
  • 运行时日志
  • 会话绑定
  • 审批转发
  • 项目记忆

其中有些层次，显然更适合交给官方 Codex 移动端。

比如：

  • 接入正在进行的 Codex 工作
  • 查看线程的实时上下文
  • 检查输出
  • 批准命令
  • 在不同线程或主机之间切换
  • 让移动端界面始终贴合 Codex 的内部机制

如果官方工具能把这些事做好，我就没必要再做一遍。

不过，这个机器人也暴露了另一组问题。官方提供远程控制，并不会自动解决这些问题。

因为它们属于我为代码仓库建立的 Agent Harness。

官方应用是 Codex 的操作界面 链接到标题

Codex Mobile 为 Codex 提供了更好的操作界面。

这是它的长处。

它回答的是这些问题：

  • 怎样随时接入活跃的 Codex 线程？
  • 怎样用手机批准一项操作？
  • 离开办公桌后，怎样检查输出？
  • 怎样在受信任的机器上启动或继续工作？

对于一款通用的 Codex 移动应用，这些正是它应该解决的产品问题。

但我的工作流还要回答另一组问题：

  • 每个新的智能体会话开始工作前，应该先读什么？
  • 新需求怎样才能沉淀下来？
  • 怎样避免智能体把聊天记录当成项目记忆？
  • 怎样把工作对应到稳定的功能 ID？
  • 怎样记录验证证据？
  • 哪条命令可以判定代码仓库是否健康？
  • 一项功能满足什么条件，才可以标记为完成？
  • 一次运行中断后，怎样恢复？

这些不只是 Codex 界面需要考虑的问题。

它们属于项目自身的工作流与 Agent Harness。

自定义层变成了工作流适配层 链接到标题

我真正看重的区别在这里：

官方 Codex Mobile 是操作界面。
我的自定义系统是项目侧的工作流适配层。

官方操作界面与项目侧 Agent Harness

操作界面帮助我使用 Codex。

工作流适配层则帮助 Codex 按照正确的方式参与项目。

也可以把它称为 Harness 适配层：它负责向 Codex 提供这个代码仓库特有的规则、记忆、检查方法和反馈闭环。

对我来说，这意味着代码仓库里仍然要保留这些文件和记录：

  • AGENTS.md
  • SPEC.md
  • feature_list.json
  • progress.md
  • test_plan.md
  • init.sh
  • orchestrator.py
  • git 历史

它们规定了长期运行的智能体工作该怎样展开。

它们不是 Codex Mobile 的替代品。

它们构成了 Codex 在项目侧应当遵循的协议，也构成了 Agent Harness。

代码仓库的记忆与 Agent Harness 仍然重要 链接到标题

官方移动端控制不会改变那条核心原则：

聊天用于下达指令。
代码仓库用于保存记忆。

即使手机端体验非常出色，我也不希望项目事实只存在于某个聊天线程里。

代码仓库仍然需要承载智能体的记忆、运行约定和反馈机制。

它仍然应该回答这些问题：

  • 产品原本应该做什么
  • 哪些工作已经完成
  • 哪些工作遇到了阻碍
  • 以前失败过什么
  • 哪些测试覆盖了已完成的工作
  • 下一个智能体应该先读什么
  • 哪条命令能够证明项目处于健康状态

移动控制越方便，这些问题反而越重要。

如果无论身在何处都能轻易发起任务，也就同样容易制造出四处分散、定义不清的工作。

代码仓库里的持久记忆和运行规则，恰好能抵消这种倾向。

它们能防止移动端的便利慢慢把工作流带偏。

我的机器人可能不再那么重要 链接到标题

Telegram 机器人以后可能不再占据中心位置。

这没什么问题。

它之所以有用，是因为它给了我这些能力：

  • 无须开放公网入站访问的轮询机制
  • 受约束的命令入口
  • 从代码仓库白名单中选择项目
  • 任务记录
  • 本地日志
  • Codex 会话绑定实验
  • 审批转发实验

但如果官方 Codex Mobile 能更好地处理远程访问、实时上下文、审批和线程控制，我就应该把这些事交给官方工具。

我不是为了保住自定义基础设施而强行维护它。

真正应该留下的，是搭建这些基础设施时发现的工作流原则。

我会保留什么 链接到标题

即使有了 Codex Mobile，我仍然会保留：

  • 代码仓库级别的智能体规则
  • 能够长期留存的规格说明
  • 结构化的功能清单
  • 进度记录
  • 验证计划
  • 一条命令即可执行的健康检查
  • 自动化无法覆盖实际行为时使用的人工验证清单
  • 运行时状态与项目状态之间清晰的界线
  • 把失败转化为更完善的代码仓库规则、脚本和检查项的反馈闭环

我还会保留这种边界明确的执行循环：

读取项目状态
选择一个工作单元
完成实现
独立验证
记录结果
提交变更

这套循环究竟由终端、Telegram、Codex Mobile 还是桌面应用触发，并没有那么重要。

重要的是，中断之后能够恢复。

哪些事情我不再想自己维护 链接到标题

下面这些东西，我更愿意不再自行维护：

  • 通用移动端界面
  • Codex 线程的实时呈现
  • 命令审批交互
  • Codex Relay
  • 主机连接管理
  • 模型切换界面
  • 原始终端输出或差异内容的实时传输

这些属于产品界面层的问题。

由 OpenAI 在 Codex 内部解决更合适。

我的自定义层应该贴近项目本身，回答的是：

这个代码仓库应该怎样引导智能体工作？

而不是：

我该怎样重新做一个 Codex 移动客户端？

界线就在这里。

我现在如何理解这套技术栈 链接到标题

现在，我这样理解这套技术栈：

Codex 官方入口
  -> 移动端、桌面端、CLI、IDE

项目工作流与 Harness 适配层
  -> AGENTS.md、SPEC.md、feature_list.json、progress.md、test_plan.md、init.sh

执行循环
  -> Codex、编排器、评估器、测试

持久记忆
  -> 代码仓库文件与 git 历史

官方入口让人更容易接入 Codex。

工作流适配层让项目更容易接着做下去。

Agent Harness 让工作更容易验证，也更容易在实践中不断改进。

它们彼此互补。

这不是要和 Codex 竞争 链接到标题

如果得出下面这个结论，就理解错了：

既然有了官方 Codex Mobile，自定义工作流就过时了。

反过来，下面这个结论也不对：

我已经做了 Telegram 机器人，所以不需要官方应用。

更合理的理解是：

通用操作界面交给官方工具。
项目特有的连续性，交给代码仓库级别的工作流规则。

官方产品可以显著改善 Codex 的远程控制体验。

我的代码仓库工作流，则能让长期运行的智能体任务在中断后更容易恢复。

代码仓库里的 Agent Harness 还能把智能体的失败转化为更完善的项目规则、工具和检查项。

它们解决的是不同的问题。

最终形态 链接到标题

这个系列最初要解决的是终端问题。

但它没有停在那里。

整个演变过程其实是：

远程终端
  -> 远程运行时
  -> 移动控制面
  -> 代码仓库记忆
  -> Agent Harness
  -> 工作流适配层

有了 Codex Mobile 以后，我最在意的依然是最后这一层。

不是因为我想重新打造一个 Codex。

而是因为我希望 Codex 在一套符合我软件开发方式的工作流里运行。

手机端可以由官方提供。

智能体可以是 Codex。

操作界面也可以不断进步。

但项目仍然需要自己的记忆、规则、验证方式和历史。

这些都应该留在代码仓库里。

资料来源 链接到标题