凌晨两点，服务器 CPU 告警。
你从床上爬起来，迷迷糊糊地 SSH 上去，敲 top 看进程、ps aux 找元凶、tail -f 查日志、free -m 看内存、df -h 看磁盘……每一步都要自己分析输出、决定下一步做什么。
如果有个 AI 能帮你干这些呢？ 不只是聊天——而是直接在你的终端里动手。它自己跑命令、自己看输出、自己判断下一步，直到找到问题根源。
这就是 uniTerm 内置的 AI Agent——当前开源终端工具中，面向运维场景深度设计的 AI 集成方案。
uniTerm 是一款不到 10MB 的开源全能终端，覆盖 20+ 协议，整合 SSH、文件传输、数据库客户端、远程桌面于一体。与市面上将 AI 作为附加功能的终端产品不同，uniTerm 从项目构思之初就是 AI Native 设计——终端连接能力与 AI Agent 并行构建，两者共享同一套会话管理、Shell 感知和工具调用体系，而非在成熟产品上外挂一个聊天窗口。
它和普通 AI 聊天有什么不同？
目前市场上终端的 AI 集成，大致分两类。
一种是研发导向的编码助手，以 Warp 为代表。Agent 在本地运行命令，帮你写代码、debug、跑测试，终端只是开发工作流的载体。这种方案的 AI 服务于"写代码的人"。
另一种是弱 AI 提示功能，以 Termius 为代表。只提供简单的 AI 命令提示，不具备完整的自主执行能力，AI 看到你的终端但动不了手——本质上还是你自己在操作。
uniTerm 的定位与两者都不同：让 AI 在授权前提下自主操作远程服务器。你不是在问 AI "这个命令怎么写"，而是在说"帮我排查一下这台服务器 CPU 飙升的原因"，然后 Agent 自己 SSH 上去跑命令、看输出、判断下一步。它的战场不在本地代码仓库，而在远程服务器——它是运维管理工具，不只是聊天窗口。
它能帮你做什么？
几句话交代，Agent 自己动手：
- 故障定位与排查："CPU 飙升了，帮我查一下原因"——Agent 自动跑
top、分析进程、追溯根源，给出结论 - 服务器巡检："巡检一下这台机器"——检查 CPU、内存、磁盘、网络，发现异常自动深挖
- 系统配置与软件安装："装个 Nginx 并配好 HTTPS"——包管理、配置文件、证书一条龙
- 日志分析："找出最近一小时 ERROR 日志的根因"——自动定位关键错误，关联上下文
下面是一个完整的故障排查演示——
"帮我排查一下服务器 CPU 占用过高的问题"
Agent 的思考和执行过程是这样的：
第 1 轮
🤔 先看看系统整体负载情况
▶ 执行: top -bn1 | head -20
👁️ 观察: CPU idle 仅 2%，load average 8.5，有一个 mysqld 进程占用 320% CPU
第 2 轮
🤔 mysqld 占用很高，看看慢查询和连接数
▶ 执行: mysql -e "SHOW PROCESSLIST;" | wc -l && mysql -e "SHOW FULL PROCESSLIST;" | grep -v Sleep
👁️ 观察: 发现 45 个连接中有 12 个处于 "Sending data" 状态，有一条慢查询正在全表扫描
第 3 轮
🤔 确认了，有慢查询导致 CPU 飙升。看一下慢查询具体是什么
▶ 执行: mysql -e "SELECT * FROM information_schema.processlist WHERE state = 'Sending data'\G"
👁️ 观察: SELECT * FROM orders WHERE created_at > '...' 没有走索引，正在扫描 200 万行
✅ 结论：orders 表 created_at 字段缺失索引，全表扫描引发 CPU 高占用，建议新增对应索引缓解负载。
整个过程，你只需要看着。这是一种全新的交互范式——你从"操作者"变成了"监督者"。
Agent 是怎么工作的？
核心循环：规划 → 执行 → 观察 → 迭代
Agent 的核心是一个自主循环，每轮包含四个阶段：
规划（Plan）：Agent 读取当前终端上下文——Shell 类型、SSH 连接信息、前几轮的输出——动态构建 prompt，让 LLM 基于最新环境信息决定下一步行动。不是凭空猜测，而是根据实时反馈来规划。
执行（Execute）：Agent 调用工具在终端中执行命令。执行前会根据用户设定的确认模式（四档：免确认/仅高危/写操作/全部）判断是否需要用户批准，风险可控。
观察（Observe）：命令跑完后，Agent 读取输出、判断成败、提取关键信息。如果命令失败了，它会分析错误原因，而不是机械地继续。
迭代（Iterate）：根据观察结果，Agent 决定下一步——继续深入、调整方向、还是给出结论。这个过程持续循环，直到问题解决。
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 规划 │ → │ 执行 │ → │ 观察 │ → │ 迭代 │
│ Plan │ │ Execute │ │ Observe │ │ Iterate │
└──────────┘ └──────────┘ └──────────┘ └────┬─────┘
↑ │
└───────────────────────────────────────────────┘
直到问题解决
六种工具，覆盖终端交互的全流程
Agent 不是只能跑命令。它有 6 种工具，覆盖了终端交互的各个层面：
| 工具 | 作用 | 使用场景 |
|---|---|---|
execute_command |
运行命令并等待完成 | 普通命令：ls、cat、ps |
start_command |
启动命令但不等待 | 长时间运行的服务启动 |
capture_terminal |
截取当前终端画面 | 查看当前终端已有的输出 |
collect_output |
收集已启动命令的输出 | 获取 start_command 启动后的结果 |
send_terminal_key |
发送按键 | 响应交互式提示（如确认） |
interrupt_command |
中断运行中的命令 | Ctrl+C 终止 |
execute_command 工具由 LLM 动态判定风险级别——read（只读）、write（写入）、dangerous（高危）——这是安全控制的核心依据。
四种执行模式：你掌控自主权
这是 Agent 安全设计最精妙的地方。不是二元的"自动/手动"开关，而是四档递进的自主权梯度：
| 模式 | 行为 | 适用场景 |
|---|---|---|
| 🟢 免确认 (bypass) | 所有命令自动执行 | 你完全信任 Agent，或在对安全要求不高的测试环境 |
| 🟡 仅高危确认 (confirm_dangerous) | 只有 rm -rf、shutdown、iptables 等需确认 |
日常使用推荐——安全与效率的平衡点 |
| 🟠 写操作确认 (confirm_write) | 所有非只读操作都需确认 | 对变更持谨慎态度，但允许 AI 自由探索 |
| 🔴 全部确认 (confirm_all) | 每一步都等你点头 | 生产环境、对 AI 能力还不够熟悉时 |
风险评估由 LLM 动态判定——每次调用 execute_command 时模型自行标注 risk 字段（read/write/dangerous），Agent 循环在工具执行前检查 shouldConfirm(risk)，与用户设定的确认模式比较决定是否需要批准。
这种设计的好处是：信任是渐进建立的。你一开始用"全部确认"，几轮下来发现 Agent 做得不错，调到"仅高危确认"，最后在测试环境直接"免确认"。自主权始终在你手里。
AI 窗口锁定：跟随操作与分屏协作
uniTerm 支持工作区分屏——一个窗口里并排多个终端面板。问题来了：AI Agent 执行命令时，它该往哪个终端发？
默认情况下，Agent 跟随当前激活的终端——你切换到哪个面板，AI 就往哪个面板发命令，始终与你同步。这适合你全程盯着 AI 操作、随时介入的场景。
另一种模式是 AI 锁定。点击面板标题栏上的锁按钮，Agent 就被固定到该终端，标题栏高亮提示。此后 Agent 所有命令只发往这个面板，你可以自由切换到其他终端继续自己的工作——两边互不干扰。锁定适合让 AI 在一台服务器上长时间执行任务，而你同时在另一台服务器上干别的事情。
对话持久化：重启不丢上下文
Agent 的对话历史独立保存到本地，应用重启后仍在。底层实现了 token 预算管理（160K token 上限），当对话过长时采用后向填充策略——保留最旧和最新的消息，中间部分逐步裁减，确保上下文窗口不溢出。
消息队列
Agent 正在执行或等待确认时，你不需要干等——继续输入新消息，它们会排队等待，在 Agent 循环的下一轮边界自动注入处理。未处理的消息显示为可移除的标签条，随时可以取消。
模型兼容：不绑死一家
uniTerm 的 AI 后端同时支持 Anthropic Messages API 和 OpenAI Chat Completions API 两种协议。这意味着你可以用：
- Claude 系列（Anthropic 原生协议）—— 以强大的工具调用和长上下文著称
- GPT 系列（OpenAI 协议）—— 生态广泛，部署灵活
- 任何兼容接口 —— Ollama 本地模型、DeepSeek、通义千问等
协议转换在 Go 后端完成：ChatCompletion 方法接收统一的前端请求，根据配置的 protocol 字段选择 Anthropic 原生格式或 OpenAI 格式发送 HTTP 请求，返回统一格式的响应流。
AI 工具矩阵：不止一个对话窗口
除了侧边栏的 AI Agent 主对话，uniTerm 还将 AI 能力嵌入到了其他功能模块中。它们不是 Chat，但同样依赖 AI 引擎驱动。
自然语言数据库查询
v1.4 新增。在数据库页面，用自然语言描述查询需求，AI 自动生成 SQL 或 MongoDB 查询语句。
对于关系型数据库，AI 会自动获取表结构作为上下文，包括列名、数据类型、索引信息。比如：
"查一下最近一周订单金额最高的 10 个客户"
不需要告诉 AI 表叫什么、有哪些字段，它会自动探测 orders 表的结构，生成正确的 JOIN 和 GROUP BY。对于 MongoDB，则根据集合结构生成对应的 MQL 过滤器。
智能补全：不只是历史匹配
在 SSH 终端中输入时，系统会同时从三个来源给出建议：
- 命令历史匹配 —— 你输过的相似命令
- 快捷命令匹配 —— 你在侧边栏中预设的快捷命令
- AI 实时建议 —— 根据当前输入和终端上下文，AI 给出命令改写/补全建议
它不是简单的 Tab 补全文件名——AI 能理解"我要把这个目录下的所有 .log 文件打包压缩"这种自然语言意图，给你生成正确的 tar 命令。
信任的边界
AI Agent 直接操作终端是个有争议的话题——支持者说省去重复劳动，反对者担心安全风险。我的看法是：工具本身不危险，危险的是缺少控制粒度。 uniTerm 通过四档确认模式、命令风险动态分级、终端锁定隔离三重机制，把控制权完整交给使用者，做到能力开放、风险可控。
当然，能否放心地把生产服务器交给 AI，每个人心里有自己的判断。我们建议先在测试和研发环境充分验证，生产环境操作务必谨慎。欢迎在评论区聊聊你的看法。
- 官网：uniterm.net
- GitHub：github.com/ys-ll/uniterm
- Gitee：gitee.com/ys-l/uniterm
项目完全开源（Apache 2.0），社区共建，欢迎提交 Issue 和 PR。
如果 uniTerm 对你有帮助，欢迎去 GitHub / Gitee 给个 ⭐ Star。
