从网页终端到CLI工具：让AI Agent真正能上手干活

当AI Agent能够编写代码、设计架构时，企业内部系统的可执行接口却往往停留在“点击网页按钮”的层面。这导致一个有趣却尴尬的现象：Agent在旁边“出谋划策”，人类在网页里机械操作。这种“AI时代的纯手工流水线”不仅效率低下，更让Agent的价值大打折扣。本文记录了一次围绕WebTerminal的工具化实践：将其从网页终端演进为支持CLI的执行面，让Agent能够像工程师一样远程执行命令、传输文件、进行交互式调试。

概述

这次改造的核心目标是解决“WebTerminal缺乏Agent友好执行面”的问题。在传统模式下，Agent只能操作浏览器DOM，面对的是按钮、输入框和滚动区域，而非稳定、可组合、可回放的执行协议。因此我们新增了`wsh`（远程shell执行）和`wcp`（文件传输）两个核心命令，将WebTerminal从“打开浏览器点来点去”推进到“直接黑屏操作”。用户只需通过浏览器完成一次官方登录并缓存cookie，后续所有操作均可通过CLI完成，无需再盯着网页终端手搓命令。

架构设计：授权与执行解耦

设计过程中有一个关键原则：授权和执行必须解耦。企业内部WebTerminal通常承载SSO认证、角色选择、审计日志、心跳保活等复杂逻辑，全部重写进CLI既不现实也无必要。正确的做法是让浏览器负责合规授权，CLI只负责命令发送、输出捕获和文件传输。具体实现上，CLI从页面中读取终端实例映射，通过页面暴露的接口发送输入，同时hook终端输出做本地捕获。这种设计保留了WebTerminal的官方连接路径，又将“命令输入/结果输出”抽象成了可编程接口——授权规规矩矩，执行清清楚楚。

动态闭环而非固定套件

在命令执行层面，我们刻意避免做成固定的诊断套件。例如，GPU hang分析不是一条`wt gpu-hang --please-save-me`的神棍命令，而是由Skill给出建议命令后，Agent根据现场状态动态决定后续步骤。工具会在每条命令后追加唯一marker来可靠识别命令完成，输出则分为三份：原始ANSI输出、去ANSI的纯文本、以及终端缓冲区快照。以GPU hang场景为例，Agent先执行环境检查命令，读完结果后再决定是否继续查看wait channel、是否需要gdb attach、是否请求用户批准侵入式操作。关键不是“命令多”，而是“下一步有脑子”。

交互式调试与文件传输

交互式程序（如gdb、emacs、vim）的处理是另一个技术难点。这类工具不是“一条命令一个结果”的模型，下一条命令取决于上一条输出。我们最终将`wt interact`设计为启动一个本地HTTP控制面，远端交互程序保持运行状态，Agent每次只发送下一条命令，拿到结果后再决定下一步。文件传输方面则直接调用WebTerminal文件API，而非模拟DOM点击弹窗。上传下载均做size和md5校验，确保传输可靠性。

如有侵权，请联系删除。