文章

tui-use:让 AI Agent 终于能控制交互式终端了

tui-use:让 AI Agent 终于能控制交互式终端了

今天在 HN 上看到一个项目,解决了一个我一直觉得很痛的问题:AI Agent 能跑 shell 命令,但碰到需要人类交互的程序就傻眼了

项目叫 tui-use,口号是”Like BrowserUse, but for the terminal”。BrowserUse 让 Agent 能控制浏览器,tui-use 让 Agent 能控制 REPL、调试器、vim、htop 这些交互式终端程序。

Agent 的盲区

现在的 coding agent(Claude Code、Cursor、Codex 等)在执行 shell 命令时已经相当溜了。但有一类场景它们完全无能为力:

  • Python 调试器 pdb 停在断点,等你输入命令
  • Node REPL 等待你的下一行代码
  • vimlazygit 这样的全屏 TUI 应用
  • 任何需要”等待人类输入”的交互式程序

Agent 执行 python -i script.py 进入交互模式后,就卡住了。它不知道程序在等输入,不知道屏幕上显示了什么,也不知道该按什么键。

这在实际工作中非常痛。比如你有一个科学计算脚本,跑了一小时才把几百万条数据加载到内存。中间出了问题想调试?对不起,Agent 帮不了你,因为它没法进入那个运行中的 Python 进程的交互环境。

tui-use 怎么解决

核心思路很简单:在 PTY(伪终端)层做文章。

1
2
3
程序输出 → PTY → xterm 模拟器 → 渲染事件
                              → 每次变化重置 debounce 计时器
                              → 100ms 稳定 → wait 返回 ✓

tui-use 在 PTY 事件流上直接监听,用一个 headless xterm 模拟器处理所有输出。这意味着:

  1. ANSI 转义序列正确处理 —— 屏幕内容永远是干净的纯文本
  2. 智能等待 —— wait 命令会阻塞直到屏幕稳定,不用瞎猜 sleep 2
  3. 语义信号 —— wait --text ">>>" 等待特定提示符出现,比”安静了一会儿”更可靠

比 tmux send-keys 好在哪

tmux 是给人用的,不是给 Agent 用的。

tmux send-keys 最大的问题是没有反馈机制。你发了键,但不知道程序什么时候处理完。Agent 只能盲猜:sleep 2 然后祈祷;或者疯狂轮询 capture-pane

tui-use 的 wait 命令直接解决这个问题。它监听每一个渲染事件,只有屏幕真正稳定后才返回。不用 sleep,不用轮询。

还有个细节很赞:highlights 字段。很多 TUI 程序用反白表示当前选中项,tui-use 会自动提取这些高亮区域,Agent 不用自己解析文本去猜”哪个菜单项被选中了”。

实际用例

几个我觉得最有价值的场景:

科学计算调试

1
2
3
4
5
tui-use start "python -i heavy_computation.py"
tui-use wait --text ">>>"
tui-use type "print(large_array.shape)\n"
tui-use wait
tui-use snapshot

几百 MB 的 numpy 数组在内存里,不用 dump 到文件,不用重新跑,直接在 live session 里检查。

交互式 git rebase

1
2
3
4
tui-use start "git rebase -i HEAD~5"
tui-use wait
tui-use type "cwip\x1b:wq\n"  # 修改 commit message
tui-use wait

自动化那些”必须在编辑器里操作”的 git 流程。

调试器会话

1
2
3
4
5
6
tui-use start "python -m pdb buggy_script.py"
tui-use wait --text "(Pdb)"
tui-use type "n\n"  # next
tui-use wait --text "(Pdb)"
tui-use type "p some_variable\n"
tui-use snapshot

Agent 终于能单步调试、检查变量了。

架构简洁

tui-use 的实现很干净:一个 daemon 进程管理所有 PTY session,CLI 只是发命令。Session 在 CLI 调用之间持久化,这意味着你可以在不同的 Agent turn 之间保持同一个终端会话。

已经有 Codex 插件了,Claude Code、Cursor、Gemini CLI 也都能用。

我的看法

这个工具填补了一个真实的空白。BrowserUse 让 Agent 能操作 Web 界面,tui-use 让 Agent 能操作终端界面。两者结合,Agent 的能力边界又扩展了一圈。

当然也有局限:复杂的 TUI 交互(比如 vim 的 modal editing)还是需要精心设计 prompt 和 keystroke 序列。但至少技术层面的障碍扫清了。


如果你在多个 AI 模型之间频繁切换测试这类 Agent 工具,推荐试试 OfoxAI(ofox.ai)— 一个账号搞定 Claude、GPT、Gemini 等主流模型,省掉管理多个 API key 的麻烦。

本文由作者按照 CC BY 4.0 进行授权