AI运维工作台Mini Assistant：终端内嵌CLI，解决运维三开痛点

前阵子某个工作日的下午我盯着监控屏上一条告警左手在 SSH 窗口里敲命令右手在记事本里翻昨天刚记的报错片段脑子还在回想聊天框里 AI 助手给的上一条分析建议——那一刻我决定做一款 AI 运维工作台也就是现在要聊的 Mini Assistant。“三开”状态听起来不算什么大事但真正跑到生产环境里信息每多跨一个窗口人的注意力和判断力就多流失一分。这篇内容不是产品发布会更像一次项目复盘我会说清楚 Mini Assistant 到底解决了什么问题、核心模块怎么设计、在真实故障处理里怎么跑通以及上线之后踩过的几个教训。如果你是运维、SRE、DevOps或者只是喜欢给终端加效率工具的开发者应该能从中找到一些可复用的思路。现在我把整件事从痛点开始讲起。1. 运维日常的「三开」痛点为什么需要把 AI 塞进终端1.1 三开状态里的信息碎片化先还原一下大多数运维值班时的真实画面SSH 客户端连着服务器这是“事实发生地”所有状态都以命令输出为准记事本里存着各种临时记录昨天改过的配置、某个服务的端口号、上次类似故障的处理顺序旁边再开一个聊天框把报错贴给 AI 助手等它给分析建议。这三样工具单拎出来都很好用问题出在它们之间没有信息通道。处理一个稍微复杂的故障我要在终端里取状态、复制到记事本里暂存、提炼后贴给聊天框、拿到结论再切回终端执行命令。一次值班下来光窗口切换就有几十次这种“复制粘贴式排障”消耗的耐心比故障本身还让人疲惫。更隐蔽的损失是上下文丢失。聊天框里的 AI 只看到你贴给它的那一段文字它不知道你刚刚执行了什么命令、上一次的判断是什么、服务器当前的真实负载如何。于是经常出现这样的情况AI 给了一个看似合理的建议但实际上遗漏了前面已经确认过的关键事实。1.2 我试过的“轻量替代方案”为什么没走通在动手做 Mini Assistant 之前我并不是没试过更省事的办法。第一个想法很简单把日志和报错复制到聊天框里问。问题很快暴露——日志一长聊天框的上下文窗口就被撑爆日志太短模型又看不到全貌。而且问完之后结论和建议还是手动复制回终端执行链路没有变短只是从“三开”变成了“还是三开但聊天框更忙”。第二个想法是搭一个内部 Web 面板把日志、监控、AI 问答放到同一个网页里。这个方案技术上可行但落地成本偏高要给面板做权限管理、做前端交互、考虑到不同团队的访问方式。更关键的是运维最熟练的操作界面始终是终端放着一个网页在另一边本质上还是“多开一个窗口”。第三个想法更朴素——写一堆固定脚本把常见故障的排查命令串起来。但这个方案只适合重复场景比如日志清理、磁盘检查一旦遇到没见过的问题脚本就不知道该怎么办了。试过这几轮之后我得出的结论是我们缺的不是“更聪明的 AI”而是一个能感知终端上下文、能执行命令、能持续参与排障的工作台。AI 本身不会“三开”它需要被放进运维工作的主流程里。Mini Assistant 就是冲着这个目标去的。2. Mini Assistant 的核心设计不是聊天框而是工作台2.1 三个能力模块拆解Mini Assistant 之所以叫“工作台”而不是“聊天机器人”是因为它的核心不是对话而是围绕终端场景组织信息流和工作流。它的整体架构可以拆成三个模块上下文装配器、策略执行器、会话中枢。上下文装配器负责从服务器上采集状态信息包括告警内容、最近日志、系统指标、服务进程状态等然后把它们按固定的模板组装成一段结构化的文本交给模型分析。这个模块还负责控制信息量——不是把所有内容都塞给模型而是按当前问题筛选最相关的一段。策略执行器是安全闸门也是 Mini Assistant 与普通聊天框最大的区别。模型输出不能直接变成命令执行而是先经过本地策略层的校验命令是否在允许列表内、参数是否符合规则、路径是否指向受保护目录。校验通过后还要推给工程师确认确认了才会真正执行。会话中枢负责多轮对话的连续性。排障通常不是一次问答能搞定的模型需要知道上一步已经排查过什么、结果如何。会话中枢会把每一轮的执行结果回填到上下文里并通过摘要机制避免历史内容占用过多 token。三个模块串起来Mini Assistant 做的事情是自动看现场、给出判断、生成可执行动作、由人确认后执行、再把结果反馈给下一轮分析。这正好对应一个运维工程师实际排查问题时的思考链路。2.2 为什么我选择终端内嵌 CLI 而不是 Web 服务设计初期我曾经纠结过形态问题要不要做成一个 Web 服务后来还是选了终端内嵌 CLI。原因很实际。第一SSH 是运维人员唯一不会离开的界面。如果工作台做在网页里我处理故障时还是要在终端和网页之间来回切和不做没有本质区别。而 CLI 形态可以直接跑在跳板机或本地终端里天然就在工作现场。第二CLI 的启动成本极低。一个命令ma就能唤起不需要打开浏览器、不需要登入面板。第三CLI 更容易和现有工具链组合比如放进 tmux 的分屏里、通过别名集成进现有脚本。代价也很明确CLI 的交互不可能像 Web 面板那样炫酷多轮对话也只能以文本流形式呈现。但对运维场景来说文本就是最高效的信息载体命令输出本身就是文本模型分析结果也以文本返回这样反而省掉了大量接口封装。2.3 对话上下文与命令空间的边界Mini Assistant 中最需要划清界限的是“对话”和“命令”的边界。模型在对话里说得再热闹也不代表它可以动服务器。我定了一条铁律模型只生产建议终端只执行经过策略器放行并人工确认的命令。所以 Mini Assistant 内部有两种模式默认是“建议模式”。在这个模式下模型可以自由输出分析、解释日志、推荐命令但这些命令一律只展示不执行。只有切换到“执行模式”并且命令经过策略器校验、用户手动确认后才会真正在目标主机上运行。这个边界看起来简单实际操作中非常重要。有一次模型建议用一条带管道符的命令查看某个服务日志策略器通过后推给我确认我一看发现管道符后的grep模式写错了。如果工具自动执行这条命令虽然不会造成破坏但会白白浪费时间。把最终确认权留给人是这类工具最不该省的一步。3. 让模型读得懂服务器上下文装配与工具调用的实现3.1 上下文装配把告警、日志、指标、拓扑打包成结构化文本模型本身不感知服务器状态Mini Assistant 要做的第一件事就是把“现场信息”整理成模型能直接理解的语言。这里的重点不是采集而是筛选和结构化。我设计了一套上下文模板按场景自动填充。比如收到一条 502 告警时上下文装配器会收集告警原文、最近 100 行 Nginx 错误日志、当前 Nginx 和上游服务的进程状态、最近 5 分钟系统负载与连接数、可疑服务的健康检查结果。这些信息被组装成固定格式后作为首轮对话的背景送给模型。下面是我常用的一份 prompt 模板去掉了具体服务器信息保留了结构[告警摘要] {alert_message} [系统状态] {load / memory / disk} [最近日志] {log_tail} [已确认事实] {context_summary} 请基于以上信息分析可能原因并给出排查计划。 要求 1. 先给出最可能的 3 个原因按概率排序。 2. 每个原因附一条验证用的只读命令。 3. 不要执行任何变更操作只做分析。这个模板的价值在于它给模型划定了输出格式和分析边界。实际使用中我发现模板里明确写“不要执行任何变更操作”能显著降低模型在前几轮对话里擅自建议危险命令的频率。模型的输出风格在很大程度上是被 prompt 结构塑造的。3.2 用函数调用Function Calling而不是纯文本来驱动命令执行第一版 Mini Assistant 用的是纯文本对话模式模型在回复里输出命令我手动复制执行。这种方式很快暴露问题——命令字符串经常被格式符号、缩进各种东西污染复制出来不是缺个空格就是多了隐藏字符还要人工清洗。后来我改成函数调用方式把“命令执行”声明成两个可调用的工具让模型直接输出结构化参数而不是自由文本。TOOLS [ { type: function, function: { name: run_readonly_command, description: 执行只读命令并返回输出用于排查状态, parameters: { type: object, properties: { command: {type: string, description: 只读命令}, reason: {type: string, description: 执行目的} }, required: [command, reason] } } }, { type: function, function: { name: propose_change, description: 生成拟变更命令需要人工确认后才执行, parameters: { type: object, properties: { command: {type: string, description: 变更命令}, rollback: {type: string, description: 回滚方案} }, required: [command, rollback] } } } ]两个函数的职责分得很清楚run_readonly_command可以自动执行但只限只读命令propose_change只生成变更建议永不自动执行。模型返回一个 JSON 结构比如{ action: run_readonly_command, params: { command: tail -n 100 /var/log/nginx/error.log, reason: 检查最近错误日志 } }Mini Assistant 的任务就是把解析出的action路由到对应模块。这比从散文里提取命令可靠得多模型不需要猜测执行意图策略器也能对结构化字段做更严格的校验。3.3 输出解析与命令执行闸门拿到模型输出的 JSON 之后不能直接执行。Mini Assistant 的命令执行链路上埋了三道闸门。第一道是白名单校验。run_readonly_command只允许命中命令白名单比如tail、grep、df、free、ss、ps、systemctl status以及带安全参数的journalctl。白名单之外的一律拒绝。第二道是参数校验。有些命令虽然安全但参数很有杀伤力比如find / -name *.log可能会全盘扫描需要在参数层面拦截。第三道是人工确认。只读命令会直接执行但系统会把命令、执行原因、输出摘要记录到审计日志propose_change产生的命令则必须等工程师敲y才会真正跑。这个设计最大的好处是模型的自由度被大幅度收窄但它能做的事仍然足够覆盖大多数排查场景。它负责“看”和“想”人负责“拍板”。4. 从告警到闭环一次完整故障处理的工作流实测4.1 一次真实感十足的告警输入与自动装配说一个典型场景。某天监控面板弹出一条告警“网关 502 比例 5 分钟内超过 8%”。如果按我以前的工作方式这会儿已经进入三开状态。用 Mini Assistant 之后我只需要在终端里输入一句话ma 分析一下网关 502 升高的问题接下来 Mini Assistant 自动完成几件事往上下文装配器里填入告警摘要、系统负载、Nginx 错误日志最近 100 行、以及当前所有 upstream 服务的健康检查状态然后把组装好的 prompt 发给模型。模型返回的第一轮分析结果通常是这样的格式最可能原因排序 1. 某个 upstream 节点异常error.log 中 connect() failed 集中在 service-b 2. 网关与上游之间网络延迟升高 3. 后端服务处理超时导致网关主动断开 建议执行 run_readonly_command: systemctl status service-b run_readonly_command: tail -n 50 /var/log/service-b/app.log这段分析不是拍脑袋想出来的它的依据都来自装配器填入的真实日志和指标。Mini Assistant 的价值在于模型在回答之前已经“看过现场”而不是等我贴给它一段孤立的报错。4.2 多轮排查中的上下文接力排障不会止步于第一轮。我确认service-b确实挂了端口监听后继续输入ma 看下 service-b 是不是被 OOM 杀过这里如果 Mini Assistant 不做上下文管理模型就不知道上一轮已经确认过“端口无法连接”这个事实。会话中枢的作用就是把每一轮的关键结论提取出来整理成“已确认事实”列表在下一轮提问时自动附加到上下文最前面。实际效果是模型不会重复问我已经确认过的问题也不会把时间浪费在无关的排查路径上。有一次真实排障里模型根据前几轮的事实直接建议查dmesg里的 OOM 记录一条命令就定位到了进程被系统杀掉的直接证据。整个过程没有一次多余的复制粘贴。这个“排查轨迹”还会被记录成本地文件。处理完一天的事后复盘时我可以直接回溯当时的每一条命令、每一次判断相当于给故障处理过程自动做了文档。4.3 安全确认与审计闭环再强调一次Mini Assistant 不会自动变更任何系统配置。即使模型已经给出了非常明确的修复建议比如“重启 service-b”这条命令也会走propose_change通道在我看到回滚方案并输入确认后才会执行。每一轮命令执行都会留下一行审计记录包含执行人、时间、命令原文、模型给出的原因、执行结果摘要。比如2025-05-20 14:32:10 || operator: alice || run_readonly_command || tail -n 100 /var/log/nginx/error.log || 检查 502 相关错误 || status: ok, 12 lines这套审计不是为了追责而是给自己留一条回头看的线索。排障过程中我经常发现半小时前一条命令的输出当时没在意后面再想找就找不到了。有了审计日志每一处现场都留下痕迹复盘效率高很多。5. 工具化之后我踩过的几个关键坑5.1 模型幻觉命令白名单怎么兜底Mini Assistant 上线没多久我就遇到一次模型幻觉。当时我让它分析一个 Java 服务频繁报错的问题模型给出的分析倒是像模像样但附带的一条命令长这样jstat -gcutil $(pgrep -f myapp.jar | head -1) 1000 5这条命令本身没问题问题在于它在我这套环境里根本没有意义——目标机器装的是精简版 JDKjstat不存在。如果工具直接把命令抛出去返回的只能是 “command not found”白白浪费一轮交互。后来我在策略器里加了一层命令可用性预检命令先在本机执行一次command -v检查不存在就直接提示模型更换验证手段。这个改动看起来不起眼但对排障体验的提升非常明显减少了大量“模型推荐了工具链里根本不存在的命令”的噪音。5.2 上下文过长被截断摘要压缩才是关键Mini Assistant 早期版本有个让我很头疼的问题排障到第三四轮时模型开始“忘记”前面的结论。原因很简单——上下文里塞了太多日志原文把模型的有效注意力挤没了。我最开始的做法是让装配器把日志全文放进去几百行实时日志加上系统指标再叠加几轮对话很快就贴近上下文窗口上限。模型虽然不会报错但回答质量明显下降开始重复提问和说车轱辘话。后来我改成“滚动窗口 多级摘要”策略。日志只保留最近 200 行每轮对话结束时会话中枢会把当前的结论压缩成一个“事实卡片”下一轮请求不再携带完整历史对话而是携带这张卡片。[已确认事实] 1. service-b 端口 8080 监听失败14:10 确认 2. systemctl status 显示进程处于 active(exited) 状态 3. dmesg 未见 OOM 记录 4. 服务配置文件最近一次修改时间5 月 19 日 22:30实测下来这个做法让模型在多轮排障中的稳定性提高了很多。它不需要记住每一句对话只要不断吸收最新的“事实卡片”就能保持思路连贯。5.3 别让 AI 直接改配置边界感比效率更重要这是我最有体会的一条经验。Mini Assistant 处理只读排查已经很顺手了但一旦涉及变更哪怕只是重启服务这种常见操作我都会强制切到人工通道。原因是运维环境里的“变更”远比表面看起来复杂。同样的重启命令在低峰期执行和高分期执行影响完全不同同一个配置参数对不同业务模块的敏感性也不一样。模型无法感知这些隐性约束它只能基于当前读到的状态做决策。所以我把 Mini Assistant 的定位严格限定为“排查助手”变更动作一律由人发号施令。我还做了一个小设计所有propose_change命令都必须附带回滚方案否则拒绝生成。这约束了模型在提出变更建议时必须多想一步也让我在确认时能快速评估操作风险。下面是我整理的变更操作分级表可以给你做个参考操作类型示例Mini Assistant 策略只读查询tail、ps、df、ss白名单校验后自动执行低风险排查systemctl status、journalctl白名单校验后自动执行变更操作systemctl restart、修改配置生成提议人工确认后执行高风险操作删目录、清日志、改防火墙直接拒绝提示人工介入6. 这个工作台适合谁、不适合谁用了几个月之后我对 Mini Assistant 的适用边界有了比较清晰的认识也经常被同事问到“这东西我能直接用吗”。说实话它的定位更像一个趁手的排障辅助不是万能运维平台。适合的人群和场景包括日常值班时需要快速定位日志问题的 SRE手里维护着三五台机器、不想为每次排查都开聊天框的开发者团队里已经有基础监控和日志采集能力、缺一个“AI 分析层”的运维小组。这些场景的共同点是人需要完整掌控终端但希望省去信息搬运的体力活。不太适合的场景我也说直白一点如果你下面管理几十上百台机器依赖集中编排平台做批量变更那 Mini Assistant 这种以单机排查为主的工具明显不够如果你的工作流里有严格的变更审批系统需要把每次操作对接进合规平台那本地 CLI 形态需要额外做对接层如果你期望 AI 直接搞定所有故障并且自动修复那我劝你还是趁早打消这个念头——至少在运维领域把最终执行权交给模型的风险和收益完全不成比例。Mini Assistant 的定位是让模型“看到现场再说话”而不是让模型“替代工程师做决定”。最后分享一点我自己的体会。Mini Assistant 上线到现在经常被问“AI 到底替你干了多少活”。我的答案一直没变——它干的是信息搬运和初筛的活做判断的仍然是我。运维这个岗位最大的风险不是工具不够聪明而是在错误信息上做出自信的决定。所以我真心建议如果你也被“三开”状态折磨别急着做一个大而全的 AI 平台先挑一个最频繁的痛点把最小闭环跑通就好。我个人的起点就是从“tail 日志 问 AI 一句话”这个动作开始一点一点把更多排查能力装进去的。