vue-tui：用 Vue 组件同时写浏览器终端和 CLI TUI
很多内部工具和 agent 控制台都会碰到同一个尴尬点：数据流像终端，交互却被拆在两套 UI 里。浏览器里要做 log viewer、streaming markdown、tool-call status；命令行里又想复用类似的 layout、输入框、列表和表格。最后常见结果是，Web 端写一套组件，CLI 端再用 Ink、Blessed、raw ANSI 或一堆 stdout helper 重写一遍。
今天看的是 Simon-He95/vue-tui。它试图把这个分叉收回来：用 Vue 3 组件描述 terminal-style UI，同一套模型可以渲染到浏览器 DOM、真实 CLI stdout 和 headless tests。README 里列出的目标场景包括 browser terminal dashboards、Vue-powered CLI apps、streaming markdown transcripts、log viewers、virtual lists 和 AI agent consoles。
按 GitHub repository API、README、LICENSE、Languages API、Commits API、Tags API 和 Releases API 在 2026-08-25 18:04 Asia/Shanghai 能核验的公开信息，Simon-He95/vue-tui 当前有 230 stars、10 forks。仓库主语言是 TypeScript，Languages API 里还有少量 JavaScript。许可证是 MIT。仓库创建于 2026-04-30 16:01:22 UTC，最近公开 push 是 2026-08-25 09:42:25 UTC，默认分支是 main。GitHub Releases API 当前没有 latest release；Tags API 显示最新 tag 是 v0.0.8。package.json 里的 npm package 名是 @simon_he/vue-tui，版本是 1.1.6，安装方式是 pnpm add @simon_he/vue-tui vue，Vue peer dependency 范围是 >=3.3.0 <4，CLI/runtime consumers 支持 Node.js >=16.17。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | Simon-He95/vue-tui |
| 定位 | Vue 3 terminal UI toolkit，支持 DOM、CLI stdout 和 headless tests |
| Stars | 230 |
| Forks | 10 |
| 主要语言 | TypeScript |
| 许可证 | MIT |
| 创建时间 | 2026-04-30 16:01:22 UTC |
| 最新 push | 2026-08-25 09:42:25 UTC |
| 默认分支 | main |
| 最新 Release | GitHub Releases API 无 latest release |
| 最新 tag | v0.0.8 |
| 当前 package version | 1.1.6 |
| 安装方式 | pnpm add @simon_he/vue-tui vue |
| 关键词 | Vue、terminal UI、DOM renderer、CLI、markdown、logs、agent console |
终端界面不一定只能活在终端里
vue-tui 的核心判断是：terminal-style UI 是一种信息组织方式，而不只是一个运行环境。很多工具确实需要 terminal 的密度和持续输出：build log、agent transcript、搜索结果、任务列表、状态表格、markdown 流式响应。但这些东西不一定只出现在 shell 里。它们也会出现在浏览器里的调试台、后台面板、内部 dashboard 和 agent playground。
如果 Web 和 CLI 分别建模，重复会很快出现。你会有两套列表、两套输入处理、两套状态展示、两套 markdown 渲染降级。vue-tui 选择用 Vue 组件当共同语言：TerminalProvider 管 buffer、DOM renderer、event manager、scheduler 和 input plugins；TBox、TInput、TList、TTable、TText 这些组件负责描述 terminal surface。CLI 侧再用 createTerminalApp、createStdoutRenderer 和 stdin driver 把同样的概念接到真实 stdout。
这个设计不适合所有应用。普通表单、管理后台和营销页不需要终端抽象。但如果你的产品本来就是 command output、log stream、agent session 或开发者 console，统一模型就有价值。你可以先在浏览器里调布局和交互，再把核心组件迁到 CLI；也可以先做 CLI 工具，之后给它补一个 browser console，而不是从零重画一套 UI。
为什么它对 agent console 有意义
现在很多 agent UI 的问题不是“能不能显示文字”，而是状态太碎。一次 agent run 里可能同时有用户输入、模型输出、tool call、文件 diff、错误、引用、markdown、progress、日志和后续输入框。用普通聊天气泡装这些信息会变得很松；用裸终端输出又很难维护选择、链接、折叠、虚拟列表和 structured status。
vue-tui 的 README 把 agent console 单独列成 showcase，并把 @simon_he/vue-tui/agent 放在 experimental entrypoint。它可以把 agent output、markdown content、tool-call status 和 input chrome 放进同一个 terminal surface。这个方向很实用：agent 不是纯聊天，也不是传统 REPL，而是一个不断追加、局部可交互、需要高密度阅读的工作台。
更关键的是，项目没有把所有东西都塞进 root import。README 明确把 stable surface 和 experimental surface 分开：root entrypoint 保留 browser-safe terminal core、DOM renderer、稳定 Vue 组件和 input host plugin factory；CLI-only APIs 放到 /cli；markdown 放到 /markdown；agent 聚合、virtual list、transcript view、log view、charts、3D、video 等放在 /experimental 或 /agent。对一个还年轻的 UI toolkit 来说，这种边界比“所有组件一次性稳定”更可信。
Entry points 的边界比较清楚
我比较喜欢它的 entrypoint 设计，因为它在 README 里直接告诉你哪些东西是 public、advanced 或 experimental。@simon_he/vue-tui 是浏览器安全的稳定入口；/core 暴露 buffer-facing types、ANSI/theme/path/hyperlink helpers；/renderer/dom 用于 DOM renderer；/cli 放 Node-only runtime、stdin driver 和 stdout renderer；/markdown 处理 streaming markdown block sources；/mermaid 是可选 Mermaid bridge。
这解决了一个 terminal UI library 常见问题：host 能力差异太大。浏览器能开链接、能处理 DOM event、能用 CSS；终端能用 OSC8 hyperlinks、stdin、stdout、terminal graphics protocol；headless tests 又希望没有真实 terminal 也能跑。vue-tui 通过 entrypoint 把这些能力拆开，至少让消费者知道哪些 import 会带来 Node-only 或 experimental 约束。
README 对链接安全也写得很细。DOM renderer 的 link rendering 需要 opt-in；CLI/stdout 侧默认只发出安全的 https:、http: 和 mailto: OSC8 hyperlinks；file: URL 需要 terminal-specific opt-in。对开发者工具来说，这不是小事。Agent console 很容易把来自模型、日志或远端仓库的字符串变成链接，如果链接策略不清楚，安全边界会变得含糊。
实际能改善哪些工作流
第一类是内部开发者面板。比如你要做一个浏览器里的构建面板：左侧是任务列表，中间是 append-only log，右侧是失败摘要和 retry 输入。传统 Web UI 当然能做，但如果核心体验就是 terminal-like output，TBox、TList、TTable、TLogView 这类组件会比普通 div 更贴近问题。
第二类是 CLI app。Vue 生态里的开发者如果想写 TUI，不一定愿意离开熟悉的响应式模型。vue-tui 让他们可以把组件、状态和事件处理继续留在 Vue 思维里，再通过 stdout renderer 输出到终端。这和 React 开发者用 Ink 写 CLI 的动机类似，只是落在 Vue 这边。
第三类是 agent transcript。Agent run 通常是长列表，而且会不断追加。README 里提到 virtual lists、append-only logs、streaming markdown 和 agent transcripts，这些正是长会话最容易卡住的地方。虚拟化和流式 markdown 如果能在同一套 terminal buffer 模型下工作，比到处拼 textarea、pre、markdown renderer 和 scroll hack 更稳。
第四类是文档和测试。因为它把 headless tests 放进目标渲染场景，组件不必只依赖真实 terminal 或浏览器截图验证。对 UI toolkit 来说，这会影响维护成本：terminal rendering 很容易出现宽度、ANSI、Unicode、resize、selection 等细节问题，如果测试只能靠人工看，很难长期可靠。
最近维护信号
从 Commits API 看，最近一次提交是 af238f5，提交时间 2026-08-25 09:42:25 UTC，主题是给 TUI 增加 interactive terminal browser，并修复相关 review finding、稳定 agent console profiling。再往前的提交在 2026-08-13，主题是优化 terminal image rendering，并补充 graphics placement、profile gate 等工作。这个节奏说明项目不是只有 README，而是在持续打磨 terminal graphics、agent console performance 和示例。
仓库目前有 709 commits，文件结构里能看到 docs、examples、e2e、test、apps、terminal-flappy-bird、terminal-nes 等目录。这里面有一点实验味很重：terminal 里跑 3D、video、NES、Flappy Bird 不是每个业务都需要。但这些示例也能反过来压测 renderer、input、graphics protocol 和性能边界。对一个 terminal UI toolkit 来说，夸张示例有时不是噱头，而是暴露渲染系统问题的压力测试。
可以怎么试
如果你在 Vue 项目里想做 browser terminal panel，可以从 README 的 browser usage 入手：安装 @simon_he/vue-tui 和 vue，用 TerminalProvider 包住固定 cols/rows 的 surface，再放 TBox、TText、TInput、TLink 等组件。先把输出、输入和链接跑起来，再考虑日志虚拟化、markdown 或 agent transcript。
如果你想做真正的 CLI，可以看 /cli entrypoint：用 createTerminalApp mount Vue component，用 createStdoutRenderer 接 stdout，用 stdin driver 处理输入，并在退出时做 cleanup。这里要注意，它不是把 DOM app “搬到终端”，而是把 Vue component model 接到 terminal buffer 和 stdout renderer。
如果目标是 agent console，我建议只把 /agent 和 /experimental 当成可试验层。核心运行面板可以先依赖 stable root、/cli 和 /markdown，把 agent-specific aggregator 包在很薄的一层里。这样项目 API 变动时，迁移面积不会太大。
Caveats
第一，项目还很年轻。仓库创建于 2026-04-30，当前 230 stars，package version 虽然已经到 1.1.6，但 GitHub Releases API 没有 latest release，Tags API 也只看到 v0.0.8。发布流程和语义版本策略需要继续观察。
第二，很多最吸引人的能力还在 experimental 或 agent entrypoint 下。3D、video、charts、virtual list、transcript、log view、agent aggregation 都很有意思，但如果你在生产应用里使用，要把 import 边界隔离好，不要把 experimental API 铺满业务代码。
第三，terminal graphics protocol 有现实限制。README 明确说 kitty 或 iTerm2 能获得更好的像素级图形输出，没有 graphics protocol 时会退化成 ASCII。Linux arm64 / musl 场景下，Bun-only WebGPU renderer 也没有预编译二进制，需要源码构建。跨平台 CLI 发布前必须在目标终端里实测。
第四，Vue 是前提。对于已经在 React、Solid、Svelte 或纯 Go/Rust TUI 生态里的团队，迁到 Vue 组件模型未必值得。vue-tui 最适合的是已经喜欢 Vue，或者想让 Web terminal panel 和 CLI app 共用一套组件思维的团队。
总结
Simon-He95/vue-tui 有意思的地方，是它没有把 TUI 限定成“终端里的 UI”，而是把 terminal-style interaction 抽象成 Vue component surface。浏览器 DOM、真实 stdout、headless test、markdown transcript、log view 和 agent console 都围绕同一套 terminal buffer 与组件模型展开。
它还年轻，experimental surface 也不少，不适合无脑压进生产。但如果你正在写 agent console、内部 log dashboard、Vue CLI app，或者想把 Web 面板和命令行界面收敛到同一种 UI 语言，vue-tui 值得试一次。它解决的不是“终端更酷”，而是“同一类开发者工作台不该被 Web 和 CLI 分裂成两套代码”。