前段时间，为了更好地使用小龙虾，我开发了一个监控龙虾的工具。当时我的想法很简单：能不能把所有工作都迁移到 OpenClaw 上？最好连开发也在上面完成。
那段时间 Copilot 还是按调用次数计费，又可以用 Claude Opus 4.6，体验确实不错。后来 Copilot 改成限流模式，闲鱼上也找不到便宜资源了，我只能转战 GPT。
结果用了 GPT 之后，我发现事情并不简单：GPT 还是得配合 Codex 才好用。
这下问题来了。我怎么才能随时随地使用 Codex？最好能在手机上也能操作。
虽然小龙虾也能间接操作 Codex，但很多交互并不自然。比如 skill、resume 这类命令，本质上还是需要一个真正的 terminal 环境。绕一层之后，就会有一种很别扭的感觉：明明我想操作的是 terminal，结果却要龙虾代理一手，既不直接也不经济（耗费token）。
所以，这篇文章要讲的不是“我做了一个很酷的系统”，而是一个很具体的痛点：我想在任何地方继续控制我的 AI 编程 Agent，但传统 terminal 和 tmux 已经开始扛不住这个工作流了。
最开始我还是老老实实用 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，就很容易变成“我不知道它们在干什么，但我又不敢关”。
遇到这个问题后，我第一反应当然不是自己造轮子，而是去找有没有现成工具。
我尝试过一些类似的工具。有的功能比较齐全，但是已经停止维护；有的支持手机端应用，也能在网页上开发，还能做 session 管理，看起来已经很接近我的需求。
一开始我还挺高兴，觉得这不就解决了吗？
没想到，真正用起来后，最大的问题不是功能少，而是跟不上 Codex、Claude Code 这类工具的更新节奏。
这类 Agent CLI 自己变化非常快。今天加一个新的 slash command，明天调整一下 resume 方式，后天又多一个 skill 工作流。如果外层工具没有及时适配，体验就会断掉。
我本来也想过二开。毕竟现在有 Codex，改个开源项目听起来应该不难。但看了一圈代码之后发现，它们往往做了比较复杂的 client 设计，测试链路也比较重。我自己只是想解决日常开发痛点，没时间把别人的整套抽象重新理解一遍。
所以，二开这条路也失败了。
卡住一段时间后，我突然意识到：我想要的其实不是一个新的 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 控制面。
一开始我在 tmux 里是用 pane 对应一个 Agent session 的。但做 Web Terminal 后，我很快发现 pane 不适合作为长期管理单元。
原因很简单：我需要让网页里的 terminal 和 tmux 里的 terminal 稳定对应起来。pane 更像是一个布局里的位置，它有序号，但不是一个适合长期追踪的实体。窗口布局一变，pane 的语义就容易乱。
所以最后我选择了用 tmux window 对应一个 Web Terminal。
这个选择看起来只是实现细节，但对体验影响很大。因为 window 更像一个独立任务，可以有自己的标题、目录、历史、状态和元信息。用户看到的也不再是一堆挤在一起的小 pane，而是一棵可以整理的 terminal 树。
这样一来，Web Terminal ACP 里的 terminal 就不再只是字符流，而是一个可管理的工作单元。
在以前的 tmux 里，最痛苦的一点是没有语义。
我只能看到 Agent 的输出，然后靠观察输出反向推导：这个 session 到底是在修 bug，还是在跑测试，还是已经卡死了。
最直接的解决方案当然是给每个 terminal 起标题。比如“修登录问题”“跑构建”“调试移动端样式”。但手动命名有两个问题。
第一，人会偷懒。
这就像维护浏览器标签页和文件夹一样。刚开始大家都很认真，后面一赶进度，就开始随手打开、随手堆着。等反应过来的时候，已经全乱了。
第二，语义会变化。
一个 session 一开始可能是在修 A，聊着聊着变成了 B，再后来又开始排查 C。人往往不会记得及时改标题。
所以这件事最适合交给 LLM。它可以不知疲倦地根据交互内容生成标题、摘要和标签，还可以把 terminal 自动整理到树状结构里。
这一步解决的不是“好不好看”，而是“我能不能一眼知道现在有哪些任务”。
当 terminal 数量从 3 个变成 30 个时，这个差别会非常明显。
另一个很真实的问题是：我舍不得重启。
一旦开了 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也可以自动恢复，体验真的提升了一大截。
还有一个问题，很多人可能都遇到过：舍不得关 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”当成一等能力。
可是在 Agent 工作流里，这件事其实很关键。因为我经常会同时开多个项目、多个任务、多个 session。过一会儿回来，我最想知道的不是全部列表，而是：刚才我到底在哪几个 terminal 上工作？
所以 Web Terminal ACP 也加了最近使用的 terminal 入口。
这不是一个复杂功能，但非常实用。它解决的是“回到现场”的问题。
很多时候，体验提升并不来自特别高级的技术，而是来自这种小地方终于顺手了。
以前我很少认真考虑在手机上写代码。
手机屏幕小、键盘难用、terminal 操作别扭，怎么看都不像一个适合开发的设备。
但 Agent 时代之后，这件事变了。
因为很多时候，我不是要在手机上亲自写代码，而是要控制 Agent 去写代码。我只需要发出任务、查看进度、补充信息、偶尔执行几个命令。
所以手机端开发变成了一个实实在在的诉求。
这里有两个难题：
1. 手机需要能随时控制 Agent 做各种操作。
2. 手机需要能进行功能测试和结果验收。
第二点目前还比较难。尤其是桌面端应用、复杂交互、需要多窗口验证的功能，手机上还是不方便。现在比较适合在手机上验收的，主要还是移动端 Web 应用，或者一些简单的命令行结果。
但第一步总得先迈出去：先让手机能舒服地控制 Agent。
手机上用 terminal，一个很大的痛点是快捷键缺失。
在电脑上，我想找之前敲过的命令，按一下方向键就行。想中断任务，按快捷键就行。想移动光标，也有成熟的键盘操作。
但在手机上，这些操作都不自然。
所以 Web Terminal ACP 给手机端加了常用快捷键和虚拟按键。方向键、控制键、常用操作都可以直接点。
这类功能看起来很小，但没有它们，手机 terminal 基本只能应急。有了它们，才开始像一个可以长期使用的工具。
手机屏幕能装下的内容很有限。
Claude Code、Codex 这类工具又会输出大量信息。如果直接看原生命令行输出，很快就会 lost。你不知道哪一段是模型思考，哪一段是工具执行，哪一段是最终结果。
所以手机端不能只做一个缩小版 terminal，还需要把 session 的输入和输出用更适合阅读的方式展示出来。
简单说，就是 terminal 仍然在那里，但旁边要有更清晰的任务记录。
这样我在手机上就不需要盯着密密麻麻的字符流猜进度，而是可以快速判断：Agent 现在在做什么，刚刚完成了什么，是否需要我介入。
还有一个特别影响体验的问题：远程输入延迟。
既然是手机使用，大概率是在外面连家里的电脑，或者连某台远程机器。这种情况下，敲一个字可能隔几十甚至上百毫秒才显示。
连接过高延迟远程服务器的人都知道，这种体验非常折磨。
所以 Web Terminal ACP 做了 quick input：先在本地输入框里把内容写完，再一次性发送给 terminal。
这对于 Agent 场景尤其重要。因为我经常不是输入一个短命令，而是输入一大段 prompt。如果每个字都走远程 terminal 回显，那体验会非常糟糕。
有了 quick input 后，手机端控制 Agent 才真正顺畅起来。
当然，现在它还不完美。
首先，手机端验收能力还比较弱。控制 Agent 已经比较顺畅了，但真正要看 UI 效果、做复杂交互测试，很多时候还是需要电脑。
其次，多 Agent 状态展示还可以继续加强。现在能看到标题、历史、session 和一些状态，但如果未来同时跑更多 Agent，可能还需要更清晰的任务看板。
第三，恢复能力还可以更自动化。现在已经能保留目录、历史和 session 信息，但重启后哪些服务该自动拉起、哪些应该只提示用户，仍然需要更细的判断。
最后，安装和多 client 管理还可以继续简化。这个工具本来就是为了解决“随时随地工作”，如果安装过程太折腾，就有点违背初衷。
这次做 Web Terminal ACP，最大的感受是：Agent 时代不一定需要一个全新的开发入口，但一定需要一个更适合长期任务管理的控制面。
传统 terminal 适合人实时操作，tmux 适合让进程长期存在，而 Agent 工作流需要在这两者之上再加几层东西：任务语义、运行状态、历史记录、最近访问、session 恢复和手机端交互。
单独看每一项都不复杂，但组合在一起后，使用体验会发生很明显的变化。
对我自己来说，它解决的是一个很具体的问题：我终于可以在浏览器和手机之间切换，继续管理同一批 Agent 任务了。再也不用盯着一堆 tmux pane 猜哪个任务还活着，也不用担心某个 session 跑完后找不到上下文。
如果你觉得这个工具有用的话，赶紧让你的agent去安装吧：
Github: https://github.com/boydfd/web_terminal_acp
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。