问题一：‍多 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。

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

以前重启像搬家，现在至少像照着清单复原桌面。

​这个功能甚至让我在实际工作中感受到了惊艳，上周我的电脑忘记充电，重启了，然后我重新打开我的web terminal，很快就恢复了之前的工作状态，不需要一个个打开terminal重新构建，按照分组以及web terminal里的历史命令，三两下就把需要的服务启动了，Agent的session也可以自动恢复，体验真的提升了一大截。

Terminal 管理：‍别让 Agent session 把内存吃爆

还有一个问题，很多人可能都遇到过：‍舍不得关 Claude Code 或 Codex session。

因为你总觉得后面可能还会用到这个上下文，可能还要补充一句话，可能还要让它继续改一点东西。于是一个 session 不关，两个 session 不关，最后几十个 session 都挂在机器上。

我自己之前在使用 OpenClaw 的时候，因为 harness 做得不够好，Claude Code 调用完成后，session 经常还停留在机器上。隔一段时间就要清理一遍，不然内存会爆炸。

所以 Web Terminal ACP 后来加的不是“永远保活”，而是“可回收、可恢复”：‍针对 Agent CLI，如果长时间没有输出，也没有用户重新进入这个 terminal，Web Terminal 可以把当前 agent 进程自动挂起/终止，同时记录它的 provider、session id、cwd、项目路径这些恢复入口。

下次你重新打开这个 terminal，或者窗口需要重新创建时，Web Terminal 会自动按对应工具的恢复方式把 session 接回来。比如 Codex 走 ​resume，Claude Code 走自己的 resume 机制。你看到的是同一个任务上下文继续往下走，但机器上不需要一直留着一个吃内存的进程。

也就是说，进程不用永远活着。真正需要长期保存的是任务的语义、历史和可恢复入口，而不是一个一直占内存的进程。

Terminal 管理：‍最近使用真的很重要

在写代码的时候，我们经常用“打开最近编辑的文件”。这个功能非常自然，也非常重要。

但到了 terminal 这边，传统工具很少把“最近使用的 terminal”当成一等能力。

可是在 Agent 工作流里，这件事其实很关键。因为我经常会同时开多个项目、多个任务、多个 session。过一会儿回来，我最想知道的不是全部列表，而是：‍刚才我到底在哪几个 terminal 上工作？

所以 Web Terminal ACP 也加了最近使用的 terminal 入口。

这不是一个复杂功能，但非常实用。它解决的是“回到现场”的问题。

很多时候，体验提升并不来自特别高级的技术，而是来自这种小地方终于顺手了。

手机使用：‍Agent 时代的新需求

以前我很少认真考虑在手机上写代码。

手机屏幕小、键盘难用、terminal 操作别扭，怎么看都不像一个适合开发的设备。

但 Agent 时代之后，这件事变了。

因为很多时候，我不是要在手机上亲自写代码，而是要控制 Agent 去写代码。我只需要发出任务、查看进度、补充信息、偶尔执行几个命令。

所以手机端开发变成了一个实实在在的诉求。

这里有两个难题：

1. 手机需要能随时控制 Agent 做各种操作。

2. 手机需要能进行功能测试和结果验收。

第二点目前还比较难。尤其是桌面端应用、复杂交互、需要多窗口验证的功能，手机上还是不方便。现在比较适合在手机上验收的，主要还是移动端 Web 应用，或者一些简单的命令行结果。

但第一步总得先迈出去：‍先让手机能舒服地控制 Agent。

手机使用：‍补上 terminal 缺失的快捷键

手机上用 terminal，一个很大的痛点是快捷键缺失。

在电脑上，我想找之前敲过的命令，按一下方向键就行。想中断任务，按快捷键就行。想移动光标，也有成熟的键盘操作。

但在手机上，这些操作都不自然。

所以 Web Terminal ACP 给手机端加了常用快捷键和虚拟按键。方向键、控制键、常用操作都可以直接点。

这类功能看起来很小，但没有它们，手机 terminal 基本只能应急。有了它们，才开始像一个可以长期使用的工具。