Show HN: TUI-use：让 AI 代理控制交互式终端程序
在 AI 代理日益普及的今天，一个关键的技术瓶颈逐渐浮现：AI 能够执行 shell 命令、调用 API，却难以与那些需要人类键盘输入的交互式程序进行有效沟通。当遇到 REPL（交互式编程环境）等待输入、调试器触发断点，或是 TUI（终端用户界面）应用渲染菜单时，AI 代理往往束手无策。
tui-use 正是为解决这一痛点而生。它允许 AI 代理通过命令行，在伪终端（PTY）中生成任何程序，以纯文本形式读取其屏幕输出，并发送击键指令。这为 AI 代理打开了与一系列原本无法通过 bash 脚本化控制的程序进行交互的大门。
核心能力：填补 AI 与终端交互的空白
tui-use 的核心价值在于其 “智能等待” 机制。传统的自动化方案，如使用 tmux send-keys，无法感知程序何时完成响应。AI 代理只能依赖猜测，例如设置固定的休眠时间或循环轮询屏幕状态，这种方式既低效又不可靠。
相比之下，tui-use 直接观察 PTY 的每一次渲染事件。其 wait 命令会阻塞，直到屏幕状态稳定（可配置空闲窗口进行去抖），从而消除了对休眠或轮询的依赖。更进一步，wait --text <pattern> 允许代理等待特定的语义信号（如提示符 >>>），而不仅仅是程序静默，实现了更精准的交互同步。
主要应用场景
tui-use 的设计瞄准了那些 bash 脚本力所不及的复杂交互场景：
- 科学计算与大型内存状态调试：当你的变量是耗费数小时计算得出的、包含数百万元素的数组时，将其转储到日志文件进行分析是不现实的。tui-use 允许 AI 代理直接进入一个正在运行的 Python 解释器或 pdb 会话，进行实时调试、检查和优化，而无需中断或重启进程。
- 驱动交互式调试器：无论是 GDB、PDB 还是其他调试器，AI 代理都可以通过 tui-use 设置断点、单步执行代码、检查变量，全程无需重启被调试的进程。
- 交互式 REPL 会话：在 Python、Node 等交互式解释器中运行代码、检查输出并继续执行，避免了在需要交互式探索时只能编写一次性脚本的局限。
- 操控 TUI 应用程序：导航 vim、lazygit、htop、fzf 等全屏终端程序，这些程序原本并非为脚本化操作而设计。这对于 Claude Code、Cursor、Codex、Gemini CLI、OpenCode 等 AI 编程代理来说，无疑是极大的能力扩展。
技术实现亮点
为了实现可靠的终端交互，tui-use 在底层做了扎实的工作：
- 完整的 VT 渲染：它通过一个无头 xterm 模拟器处理 PTY 输出，确保 ANSI 转义序列、光标移动和清屏操作都能被正确解析。最终提供给 AI 代理的
screen字段始终是清晰、干净的纯文本，便于理解和处理。 - 为代理而生的设计哲学：与 tmux 等为人类用户设计的工具不同，tui-use 从底层就考虑了程序化交互的需求。其 API 设计旨在提供确定性的反馈，让 AI 代理能够“知道”程序何时准备好接收下一个指令，从而构建稳定、可靠的自动化流程。
行业意义与展望
tui-use 的出现，标志着 AI 代理在软件开发与系统管理领域的操作粒度正在从“命令执行”向“交互控制”深化。它不仅仅是另一个自动化工具，更是连接 AI 智能与复杂、状态化的终端环境的关键桥梁。随着 AI 编码助手和自主代理的快速发展，此类能够突破传统脚本限制的工具，将极大地提升开发、调试和运维工作的自动化水平与智能程度，为构建更强大的 AI 驱动工作流铺平了道路。