Remote Agent Workflow on Armstrong Yan

远程智能体工作流（五）：Codex Mobile 之后，什么依然重要

Mon, 20 Jul 2026 23:52:52 +0800

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

最初搭建这套远程 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 的介绍，你可以跨线程处理任务、检查输出、批准命令、切换模型、发起新任务，还能实时收到终端输出、差异内容、测试结果、截图和审批请求等更新。

远程智能体工作流（四）：在仓库中，而非聊天中

Mon, 20 Jul 2026 23:33:28 +0800

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

我的远程 AI 开发环境，第一层解决连接问题。

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

有了这条链路，我可以用手机访问 Mac，也能让耗时较长的本地任务持续运行。

第二层解决控制问题。

手机 -> Telegram Bot -> 本地 Codex 运行时 -> 选定的仓库

这样一来，手机就成了控制入口，而不再是一台屏幕很小的终端。

但这两层都没有触及更深的问题。

远程访问让我能连上机器。

远程控制让我能启动任务、查看进展。

而长时间运行的智能体开发还需要记忆。

智能体可能在我离开后继续运行，也可能从中断处恢复、换一个会话接着做，或者由我通过手机操控。既然如此，整个项目就不能只存在于一条聊天线程里。

于是，我给自己定了一条规则：

聊天用来传达指令。
仓库用来保存记忆。

更准确地说，仓库不只是存放代码的地方。它还承载着智能体的记忆和操作约定，并为智能体提供持续的反馈机制。

为什么聊天记录不能充当项目状态链接到标题

聊天很适合表达意图。

我可以在聊天里说明目标、提出问题、纠正方向，或者做出产品决策。

但要长期保存项目状态，聊天并不可靠。

聊天内容难以比较差异，也不便验证；它依附于某一条线程，后续会话中的智能体很容易误解，甚至根本看不到。想法、日志、猜测、决定和已经过时的背景信息，往往全都混在同一条信息流里。

如果只是一次性的小改动，这样做未尝不可。

可一旦智能体需要长时间工作，问题就会暴露出来。

项目必须能稳定回答以下问题：

这个系统应该做什么？
哪些内容已经实现？
以前在哪里失败过？
什么证据能证明这些行为现在仍然正常？
下一个智能体在修改文件之前，应该先读什么？

这些答案应该和代码放在一起。

让仓库同时承担记忆与 Agent Harness 链接到标题

在我的项目里，智能体需要长期保留的状态通常分散在以下文件和记录中：

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

文件具体叫什么并不重要，重要的是分清职责。

远程智能体工作流（三）：把 Telegram 变成本地 Codex 的控制面

Mon, 20 Jul 2026 23:20:13 +0800

这是「远程智能体工作流」系列的第三篇。

前两篇文章里，我先搭出了一条实用的远程终端链路：

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

有了这条链路，我就能可靠地从手机连接自己的 Mac。

但新的局限很快就暴露出来：手机并不好用来操作终端。

移动端 SSH 适合救急，但我不想靠它处理需要长时间运行的 AI 开发任务。我不想在狭窄的手机屏幕上敲 shell 命令、连接 tmux 会话、翻找长篇日志，再一点点拼凑出当前状态。

我真正想要的，是下面这样的链路：

手机 -> 任务式接口 -> 本地智能体运行时 -> 仓库状态

于是，我做了一个小型 Telegram Bot，把它用作本地 Codex 的控制面。

关键不在于 Telegram 有多特别。

真正重要的是：手机成为控制界面，而 Mac 仍然负责执行工作。

为什么选 Telegram 链接到标题

Telegram 很适合用来做这个实验，因为它已经具备：

移动端通知
简短的命令消息
回复串
内联按钮
跨设备历史记录
成熟的 Bot API

更重要的是，Telegram 支持两种截然不同的部署模式。

第一种是 webhook 模式：

远程智能体工作流（二）：从远程 Shell 到智能体控制面

Mon, 20 Jul 2026 22:33:24 +0800

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

上一篇文章里，我搭建了一套实用的远程终端工作流：

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

这套方案解决了第一个问题：离开书桌后，怎样连回自己的 Mac；手机断开后，怎样让本地智能体继续执行耗时较长的任务。

它很快就派上了用场。

但在实际使用后，我又发现了第二个问题。

SSH 解决了连通性，却不会自动带来一套好用的远程开发工作流。

移动端 SSH 用得越多，它的边界就越清楚：

手机不该被当成一台微型终端。
手机应该成为本地智能体工作流的控制面。

第一层解决的是基础设施链接到标题

远程终端这套配置仍然不可或缺。

我需要：

用 Tailscale 连接手机与 Mac，又不把 SSH 暴露在公网上。
用 SSH 安全登录。
用 tmux 保证耗时较长的任务不会因连接断开而终止。
用 caffeinate 防止 Mac 在智能体工作期间休眠。

这样，我就有了一套可靠的基础能力：

我可以连上机器。
我可以启动工作。
我可以断开连接。
我可以稍后再连回来。

这是很实在的一步。

但它只回答了基础设施层面的问题：

我能连到这台机器吗？

它没有回答工作流层面的问题：

我能顺畅地用手机推动耗时较长的 AI 开发工作吗？

对我来说，答案是否定的。

手机并不是一台好终端链接到标题

移动端 SSH 很适合应急访问。

远程智能体工作流（一）：用手机连接 Mac 运行 Codex

Mon, 20 Jul 2026 22:15:53 +0800

本文是“远程代理工作流”系列的第一篇。

这篇指南将介绍如何用手机操作 Mac 终端，并让 Codex、自动化脚本、本地开发代理等长时间任务持续运行。

我们要搭建的不是远程桌面，而是一套可靠的远程终端工作流：

手机 -> SSH -> Mac -> tmux -> Codex / 代理任务

配置完成后，Mac 就会成为一个轻量的远程执行节点。无论身在何处，你都可以用手机接入。

各个工具分别做什么链接到标题

SSH 链接到标题

SSH 是一种安全的远程登录协议，可以让你从手机进入 Mac 的终端。

在这套工作流中，SSH 负责：

安全访问 Mac 的命令行。
使用密码或 SSH 密钥验证身份。
从手机远程执行命令。

不过，SSH 一旦断开，并不能保证任务继续运行。这正是我们还需要 tmux 的原因。

Tailscale 链接到标题

Tailscale 会在你的设备之间建立私有网络。即使 Mac 和手机接入不同的网络，两台设备也能通过稳定的私有 IP 地址互相访问。

在这套工作流中，Tailscale 负责：

让你通过 4G、5G、酒店 Wi-Fi、公司 Wi-Fi 或家庭 Wi-Fi 远程访问 Mac。
为 Mac 提供稳定的 100.x.x.x 地址。
加密设备之间的网络通信。
避免将 SSH 直接暴露在公网上。

本文默认使用官方 Tailscale macOS 客户端。在这种配置下，后台服务、登录状态和菜单栏状态都由该应用管理。