我只是想随时随地工作

前段时间，为了更好地使用小龙虾，我开发了一个监控龙虾的工具。当时我的想法很简单：‍能不能把所有工作都迁移到 OpenClaw 上？最好连开发也在上面完成。

那段时间 Copilot 还是按调用次数计费，又可以用 Claude Opus 4.6，体验确实不错。后来 Copilot 改成限流模式，闲鱼上也找不到便宜资源了，我只能转战 GPT。

结果用了 GPT 之后，我发现事情并不简单：‍GPT 还是得配合 Codex 才好用。

这下问题来了。我怎么才能随时随地使用 Codex？最好能在手机上也能操作。

虽然小龙虾也能间接操作 Codex，但很多交互并不自然。比如 skill、resume 这类命令，本质上还是需要一个真正的 terminal 环境。绕一层之后，就会有一种很别扭的感觉：‍明明我想操作的是 terminal，结果却要龙虾代理一手，既不直接也不经济（耗费token）。

所以，这篇文章要讲的不是“我做了一个很酷的系统”，而是一个很具体的痛点：‍我想在任何地方继续控制我的 AI 编程 Agent，但传统 terminal 和 tmux 已经开始扛不住这个工作流了。

问题一：‍多 Session 真的很难维护

最开始我还是老老实实用 tmux。

先看一下tmux里的概念：

我的习惯是，一个 project 放在一个 tmux window 里，多个 Codex session 或 Claude Code session 就放在不同的 pane。刚开始这套方案还挺舒服，因为 tmux 至少解决了会话持久化的问题。电脑合上再打开，任务还在那里。

但并发任务一多，问题就来了。

1. 一个 window 里塞了太多 pane，很快就看不出来哪个是哪个。

2. pane 太小之后，只能看到一点点输出，不知道 session 是卡住了还是已经完成了。

3. 有些任务跑完了，人不在电脑旁边，回来还得一个个 pane 检查。

4. 手机上看 tmux pane，基本就是在考验视力和耐心。

这时候我意识到，terminal 本身没错，tmux 也没错，错的是 Agent 时代的任务数量和持续时间已经变了。

以前 terminal 更像是一个“实时操作窗口”，我敲命令，它给我输出。现在 terminal 里跑的是 Agent，它可能自己工作十几分钟，甚至更久，等待一大段时间后，还需要继续交互。人和 terminal 的关系，从实时操作变成了任务托管。

所以，如果还用一堆 pane 来管理 Agent，就很容易变成“我不知道它们在干什么，但我又不敢关”。

问题二：‍现成工具总是跟不上 Agent CLI

遇到这个问题后，我第一反应当然不是自己造轮子，而是去找有没有现成工具。

我尝试过一些类似的工具。有的功能比较齐全，但是已经停止维护；有的支持手机端应用，也能在网页上开发，还能做 session 管理，看起来已经很接近我的需求。

一开始我还挺高兴，觉得这不就解决了吗？

没想到，真正用起来后，最大的问题不是功能少，而是跟不上 Codex、Claude Code 这类工具的更新节奏。

这类 Agent CLI 自己变化非常快。今天加一个新的 slash command，明天调整一下 resume 方式，后天又多一个 skill 工作流。如果外层工具没有及时适配，体验就会断掉。

我本来也想过二开。毕竟现在有 Codex，改个开源项目听起来应该不难。但看了一圈代码之后发现，它们往往做了比较复杂的 client 设计，测试链路也比较重。我自己只是想解决日常开发痛点，没时间把别人的整套抽象重新理解一遍。

所以，二开这条路也失败了。

柳暗花明：‍我真正需要的是更好管理 terminal

卡住一段时间后，我突然意识到：‍我想要的其实不是一个新的 IDE，也不是一个新的 Agent 平台。

我想要的就是一个更方便的 terminal。

只要 terminal 能被管理好，Codex、Claude Code、Cursor CLI 这些工具完全可以继续用原来的方式跑。这样反而更稳：

1. 不需要追着每个 Agent 工具的内部协议跑。

2. 不替换 shell、tmux、git 这些已经稳定的工具。

3. 浏览器只做控制面，真正执行命令的还是原来的机器。

4. 手机端也能优化交互，因为浏览器比 SSH 客户端更容易做界面。

顺着这个思路，最终形态就很清楚了：‍做一个 Web Terminal。

但这里有一个关键点：‍它不能只是“在网页里打开一个 terminal”。如果只是把 terminal 搬到浏览器里，那只能解决输入输出问题，解决不了多 Session 管理问题。

我真正需要的是一个面向 Agent 工作流的 terminal 控制面。

方案演进：‍从 pane 到 window

一开始我在 tmux 里是用 pane 对应一个 Agent session 的。但做 Web Terminal 后，我很快发现 pane 不适合作为长期管理单元。

原因很简单：‍我需要让网页里的 terminal 和 tmux 里的 terminal 稳定对应起来。pane 更像是一个布局里的位置，它有序号，但不是一个适合长期追踪的实体。窗口布局一变，pane 的语义就容易乱。

所以最后我选择了用 tmux window 对应一个 Web Terminal。

这个选择看起来只是实现细节，但对体验影响很大。因为 window 更像一个独立任务，可以有自己的标题、目录、历史、状态和元信息。用户看到的也不再是一堆挤在一起的小 pane，而是一棵可以整理的 terminal 树。

这样一来，Web Terminal ACP 里的 terminal 就不再只是字符流，而是一个可管理的工作单元。

Terminal 管理：‍先让它有语义

在以前的 tmux 里，最痛苦的一点是没有语义。

我只能看到 Agent 的输出，然后靠观察输出反向推导：‍这个 session 到底是在修 bug，还是在跑测试，还是已经卡死了。

最直接的解决方案当然是给每个 terminal 起标题。比如“修登录问题”“跑构建”“调试移动端样式”。但手动命名有两个问题。

第一，人会偷懒。

这就像维护浏览器标签页和文件夹一样。刚开始大家都很认真，后面一赶进度，就开始随手打开、随手堆着。等反应过来的时候，已经全乱了。

第二，语义会变化。

一个 session 一开始可能是在修 A，聊着聊着变成了 B，再后来又开始排查 C。人往往不会记得及时改标题。

所以这件事最适合交给 LLM。它可以不知疲倦地根据交互内容生成标题、摘要和标签，还可以把 terminal 自动整理到树状结构里。

这一步解决的不是“好不好看”，而是“我能不能一眼知道现在有哪些任务”。

当 terminal 数量从 3 个变成 30 个时，这个差别会非常明显。

Terminal 管理：‍解决舍不得重启的问题

另一个很真实的问题是：‍我舍不得重启。

一旦开了 tmux，里面就会有很多 window，跑着各种任务：‍开发服务、LLM 服务、Agent session、临时调试命令。只要这些东西还在，我就不太想重启机器。

原因也很朴素：‍完整重建一次太麻烦了。

我要先找到对应目录，再启动服务，再恢复各个 Agent session，还要通过 resume 一个个确认哪个 session 是哪个。有时候光是恢复现场，就已经把耐心耗光了。

所以 Web Terminal ACP 里做了一件很重要的事：‍把 terminal 的元信息持久化下来。

既然一个 Web Terminal 已经能对应一个 tmux window，那就可以记录它的目录、标题、分组、命令历史和 Agent session 信息。

这样就算机器重启、tmux 消失，我也不至于从零开始。打开 Web Terminal ACP，看着 terminal 树，就能知道之前有哪些任务、在哪些目录、执行过哪些命令、应该恢复哪个 Agent session。

这不是完全自动化恢复一切，但它把“灾后重建”的成本降了很多。