CLI、GUI 还是 TUI？AI Agent 应用该选择哪种交互界面？

作者：袖梨 2026-09-13

AI Agent 应用选择 CLI、TUI 还是 GUI，不能只看工具是否“运行在终端”。严格来说，CLI 更偏向一次命令、一次结果的脚本式调用；TUI 是终端内持续运行的交互应用；GUI 则用窗口、指针、可视化差异和预览支撑人的观察与审查。三者解决不同任务，成熟产品通常同时提供多种入口，而不是一种界面。

为什么界面名称经常被混用

日常交流中，人们常把终端、Shell、CLI 和终端 Agent 统称为“命令行”。这在闲聊时问题不大，但会干扰产品选型、安全评审和自动化设计。

一个工具在终端窗口中运行，只能说明它的宿主是终端。它可能是执行后立即退出的 CLI，也可能是带多轮对话、状态区、菜单和权限提示的 TUI。

先拆开三条判断轴

评估 Agent 产品时，至少要区分三条轴：

交互类型：CLI、TUI、GUI 或以对话为核心的 CUI。
宿主环境：终端、IDE、浏览器、桌面客户端或移动端。
机器接入层：API、MCP、SDK、Agent Skill 等。

例如，IDE 中可以嵌入终端 TUI；浏览器 GUI 可以通过 MCP 调用企业工具；同一个 Agent 又能以 headless CLI 进入 CI。它们并不处于同一分类层级。

CLI 在 Agent 场景中是什么

CLI 的典型形态是输入一条命令和参数，程序执行任务、输出结果并退出：

agent run --task "修复 lint 错误" --output json

它适合脚本、管道、定时任务和 CI/CD，因为输入输出边界清晰，无需人在场操作菜单。

CLI 的主要优势

便于自动化和批量执行。
命令可记录、复现和审计。
可通过退出码判断成功或失败。
容易与 Shell、文件和其他工具组合。

CLI 的局限

一次性调用不适合持续展示复杂状态。长时间任务如果只输出滚动日志，人很难理解当前计划、待审批动作和多分支进度。

TUI 在 Agent 场景中是什么

TUI 是运行在终端里的交互式界面。它通常不会在一条命令后立即退出，而是保留多轮会话，展示消息、工具调用、diff、权限确认和任务状态。

许多被口语称为“AI CLI”的编码 Agent，默认工作方式其实更接近 TUI：开发者持续与 Agent 对话，Agent读取仓库、修改文件、运行测试，再根据结果继续。

TUI 的主要优势

保留终端键盘工作流，适合工程师。
能够承载多轮 Agent 循环。
可实时显示工具调用和权限请求。
容易接入本地 Shell、Git 和构建工具。

TUI 的局限

字符布局不擅长复杂图形、像素级预览和大规模并排比较。可访问性、复制选择和滚动行为也可能因终端实现而异。

GUI 在 Agent 场景中是什么

GUI 使用窗口、侧边栏、文件树、差异视图、画布和浏览器预览，让人直接观察 Agent 的工作对象与结果。AI IDE、网页构建器和带 Canvas 的对话产品都属于 GUI 或 GUI 混合形态。

GUI 的主要优势

适合阅读代码结构和可视化 diff。
能直接检查网页、图片、图表和布局。
复杂任务状态可以分层展示。
审批和风险提示更容易被看见。

GUI 的局限

对于无人值守和批量任务，GUI 难以稳定脚本化。Agent 若只能模拟点击，还会受到控件漂移、弹窗和视觉状态变化影响。

CLI、TUI、GUI 对照

维度	CLI	TUI	GUI
交互方式	单次命令或脚本	终端内持续会话	窗口与可视控件
最适合	自动化、CI、批处理	终端开发与委派	审查、探索、视觉任务
人在环路	低或无	中等到高	通常较高
结构化输出	易于强制	常混合状态与日志	偏视觉呈现
脚本集成	最好	需要 headless 模式	通常较弱
视觉检查	弱	有限	最好

Headless 为什么是关键分界

Headless 表示无需可见交互界面即可运行。它通常以 CLI 或 API 形式接收任务，并在结束时返回状态。CI 审查、定时生成变更日志和批量迁移都需要这种模式。

一个终端 Agent 即使拥有漂亮 TUI，也不代表能直接放进流水线。选型时要确认是否提供非交互参数、结构化输出、稳定退出码、超时控制和权限白名单。

CUI 是第四种并列界面吗

CUI 指以自然语言对话为核心的交互。它可以运行在网页 GUI、移动应用或终端 TUI 中，因此更像一种交互范式，而不是单纯的渲染技术。

对话适合表达目标和补充上下文，但不擅长一次展示大量状态。成熟产品会在对话旁加入表格、文件、diff、画布和审批控件。

Canvas 仍然属于 GUI

Canvas 通常意味着为文档、代码或应用预览提供更大的工作区。它改变的是布局和内容承载方式，底层仍然通过图形界面呈现，不应被当作与 CLI、TUI 并列的新类别。

MCP、API 和 Skills 为什么不是用户界面

API 与 MCP 是机器接入层，解决 Agent 如何发现并调用能力；Skill 通常封装任务说明、流程、约束和工具使用方法。它们可以被 GUI、TUI 或 headless Agent 使用。

人类界面：GUI / TUI / CUI
        ↓ 提交目标与审批
Agent 运行时：计划 / 工具选择 / 状态管理
        ↓ 调用能力
机器接入层：API / MCP / CLI / Skills

把 MCP 当作界面会导致错误问题。例如真正需要评估的是参数 schema、认证和权限，而不是按钮放在哪里。

按任务选择，而不是按产品站队

自动化流水线优先 CLI 或 API

任务应可无人值守、可超时、可重试，并返回机器可读结果。不要依赖交互菜单或人工输入。

仓库级开发优先 TUI Agent

跨文件修改、运行测试和连续修正需要多轮循环。TUI 可以让工程师留在终端，同时保留审批和状态反馈。

细粒度审查优先 GUI IDE

逐行 diff、文件导航、断点调试和布局预览依赖视觉空间，GUI 更能降低认知成本。

非技术用户原型优先 GUI 加 CUI

自然语言描述配合可点击预览，能让用户快速验证想法。后续进入工程化阶段时，再导出代码并接入版本控制和测试。

同一产品为何需要多种模式

Agent 的核心循环可以复用，但不同使用阶段需要不同入口：

在 GUI 中选择任务和查看上下文。
在 TUI 中持续委派仓库工作。
用 headless CLI 在 CI 中复跑验证。
通过 API 或 MCP 接入组织内部系统。
回到 GUI 检查差异并做最终审批。

这是一条组合工作流，不是重复建设四个 Agent。

选型前要问的十个问题

任务是单次执行还是持续会话？
是否必须无人值守运行？
结果主要是文本、代码还是视觉内容？
人需要多频繁地审批工具调用？
是否要接入 CI、cron 或批处理？
能否返回 JSON 和稳定退出码？
权限是否可以按工具和目录限制？
失败后能否恢复或继续会话？
是否需要审查大型 diff 和页面预览？
组织能力通过 API、MCP 还是本地命令提供？

权限模型会随界面改变

GUI 通常假设人在场，可以通过弹窗确认高风险动作；TUI 也能逐项请求权限。Headless CLI 无法等待随意弹窗，因此必须预先定义允许的工具、目录、网络和凭据范围。

不能为了自动化简单打开“跳过所有权限”。更稳妥的做法是给无人值守任务专用身份、隔离环境和只够完成任务的权限。

日志和可观测性如何设计

不同界面可以呈现不同层次，但必须引用同一权威状态：

CLI 返回简洁 JSON 和退出码。
TUI 展示实时步骤、工具调用和可展开日志。
GUI 汇总计划、diff、测试和风险。
后台统一记录操作 ID、输入摘要和副作用。

否则同一任务在不同入口会显示互相矛盾的结果。

常见概念误区

“打开 CLI”

更准确的说法通常是打开终端模拟器，再由 Shell 解释命令。终端只是宿主。

“终端 Agent 都是 CLI”

若它维持多轮会话、显示面板并等待交互，默认形态更接近 TUI；只有一次性非交互调用才是严格的 headless CLI。

“IDE 有终端，所以它是 CLI 产品”

嵌入一个终端面板不会改变 IDE 的主要 GUI 形态。应分别记录主界面和附加入口。

“API 与 CLI 二选一”

API 是程序接入方式，CLI 可以是 API 的本地包装。两者经常共同存在。

如何落地界面组合

为任务建立统一状态模型和操作 ID。
把业务能力从界面事件中抽离。
先提供稳定 API 或命令契约。
为交互开发实现 TUI 状态与审批。
为视觉审查实现 GUI diff 和预览。
为流水线实现 headless 参数与 JSON 输出。
统一认证、权限、日志和幂等机制。
分别测试有人值守与无人值守场景。

总结

AI Agent 应用没有唯一最佳界面。CLI 适合单次调用、脚本和无人值守自动化；TUI 适合终端中的多轮委派与工具循环；GUI 适合视觉探索、差异审查和高风险审批。CUI 描述对话范式，API、MCP 与 Skills 属于机器接入层，都不应与三种界面简单混为一谈。正确做法是先拆清交互类型、宿主环境和接入层，再按任务组合：GUI 做理解与审查，TUI 做持续协作，headless CLI 做自动化，API 与 MCP 连接业务能力。