背景我只是想随时随地工作前段时间为了更好地使用小龙虾我开发了一个监控龙虾的工具。当时我的想法很简单能不能把所有工作都迁移到 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 至少解决了会话持久化的问题。电脑合上再打开任务还在那里。但并发任务一多问题就来了。一个 window 里塞了太多 pane很快就看不出来哪个是哪个。pane 太小之后只能看到一点点输出不知道 session 是卡住了还是已经完成了。有些任务跑完了人不在电脑旁边回来还得一个个 pane 检查。手机上看 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 这些工具完全可以继续用原来的方式跑。这样反而更稳不需要追着每个 Agent 工具的内部协议跑。不替换 shell、tmux、git 这些已经稳定的工具。浏览器只做控制面真正执行命令的还是原来的机器。手机端也能优化交互因为浏览器比 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如果长时间没有输出也没有用户重新进入这个 terminalWeb Terminal 可以把当前 agent 进程自动挂起/终止同时记录它的 provider、session id、cwd、项目路径这些恢复入口。下次你重新打开这个 terminal或者窗口需要重新创建时Web Terminal 会自动按对应工具的恢复方式把 session 接回来。比如 Codex 走resumeClaude Code 走自己的 resume 机制。你看到的是同一个任务上下文继续往下走但机器上不需要一直留着一个吃内存的进程。也就是说进程不用永远活着。真正需要长期保存的是任务的语义、历史和可恢复入口而不是一个一直占内存的进程。Terminal 管理最近使用真的很重要在写代码的时候我们经常用“打开最近编辑的文件”。这个功能非常自然也非常重要。但到了 terminal 这边传统工具很少把“最近使用的 terminal”当成一等能力。可是在 Agent 工作流里这件事其实很关键。因为我经常会同时开多个项目、多个任务、多个 session。过一会儿回来我最想知道的不是全部列表而是刚才我到底在哪几个 terminal 上工作所以 Web Terminal ACP 也加了最近使用的 terminal 入口。这不是一个复杂功能但非常实用。它解决的是“回到现场”的问题。很多时候体验提升并不来自特别高级的技术而是来自这种小地方终于顺手了。手机使用Agent 时代的新需求以前我很少认真考虑在手机上写代码。手机屏幕小、键盘难用、terminal 操作别扭怎么看都不像一个适合开发的设备。但 Agent 时代之后这件事变了。因为很多时候我不是要在手机上亲自写代码而是要控制 Agent 去写代码。我只需要发出任务、查看进度、补充信息、偶尔执行几个命令。所以手机端开发变成了一个实实在在的诉求。这里有两个难题手机需要能随时控制 Agent 做各种操作。手机需要能进行功能测试和结果验收。第二点目前还比较难。尤其是桌面端应用、复杂交互、需要多窗口验证的功能手机上还是不方便。现在比较适合在手机上验收的主要还是移动端 Web 应用或者一些简单的命令行结果。但第一步总得先迈出去先让手机能舒服地控制 Agent。手机使用补上 terminal 缺失的快捷键手机上用 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去安装吧Agent Installation GuideGitHub: https://github.com/boydfd/web_terminal_acp#
为了随时随地控制 AI Agent，我做了一个 Web Terminal
背景我只是想随时随地工作前段时间为了更好地使用小龙虾我开发了一个监控龙虾的工具。当时我的想法很简单能不能把所有工作都迁移到 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 至少解决了会话持久化的问题。电脑合上再打开任务还在那里。但并发任务一多问题就来了。一个 window 里塞了太多 pane很快就看不出来哪个是哪个。pane 太小之后只能看到一点点输出不知道 session 是卡住了还是已经完成了。有些任务跑完了人不在电脑旁边回来还得一个个 pane 检查。手机上看 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 这些工具完全可以继续用原来的方式跑。这样反而更稳不需要追着每个 Agent 工具的内部协议跑。不替换 shell、tmux、git 这些已经稳定的工具。浏览器只做控制面真正执行命令的还是原来的机器。手机端也能优化交互因为浏览器比 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如果长时间没有输出也没有用户重新进入这个 terminalWeb Terminal 可以把当前 agent 进程自动挂起/终止同时记录它的 provider、session id、cwd、项目路径这些恢复入口。下次你重新打开这个 terminal或者窗口需要重新创建时Web Terminal 会自动按对应工具的恢复方式把 session 接回来。比如 Codex 走resumeClaude Code 走自己的 resume 机制。你看到的是同一个任务上下文继续往下走但机器上不需要一直留着一个吃内存的进程。也就是说进程不用永远活着。真正需要长期保存的是任务的语义、历史和可恢复入口而不是一个一直占内存的进程。Terminal 管理最近使用真的很重要在写代码的时候我们经常用“打开最近编辑的文件”。这个功能非常自然也非常重要。但到了 terminal 这边传统工具很少把“最近使用的 terminal”当成一等能力。可是在 Agent 工作流里这件事其实很关键。因为我经常会同时开多个项目、多个任务、多个 session。过一会儿回来我最想知道的不是全部列表而是刚才我到底在哪几个 terminal 上工作所以 Web Terminal ACP 也加了最近使用的 terminal 入口。这不是一个复杂功能但非常实用。它解决的是“回到现场”的问题。很多时候体验提升并不来自特别高级的技术而是来自这种小地方终于顺手了。手机使用Agent 时代的新需求以前我很少认真考虑在手机上写代码。手机屏幕小、键盘难用、terminal 操作别扭怎么看都不像一个适合开发的设备。但 Agent 时代之后这件事变了。因为很多时候我不是要在手机上亲自写代码而是要控制 Agent 去写代码。我只需要发出任务、查看进度、补充信息、偶尔执行几个命令。所以手机端开发变成了一个实实在在的诉求。这里有两个难题手机需要能随时控制 Agent 做各种操作。手机需要能进行功能测试和结果验收。第二点目前还比较难。尤其是桌面端应用、复杂交互、需要多窗口验证的功能手机上还是不方便。现在比较适合在手机上验收的主要还是移动端 Web 应用或者一些简单的命令行结果。但第一步总得先迈出去先让手机能舒服地控制 Agent。手机使用补上 terminal 缺失的快捷键手机上用 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去安装吧Agent Installation GuideGitHub: https://github.com/boydfd/web_terminal_acp#
