1. 我和「三开」搏斗的那半年先还原一个真实场景。凌晨三点线上流量比平时高出一截某个服务的错误日志突然开始刷屏。我当时的屏幕是这样分布的左边是一个SSH终端日志在飞快滚动右边是一个记事本文件里面记着几台机器的IP、先后顺序、试过的命令和还没验证的推测再往边上还有一个聊天框里面是AI助手正等着我把报错信息复制过去。这画面看着很高效实际上糟透了。终端里滚出来的报错格式又长又乱我要先截取关键字段去掉时间戳和重复刷屏的行才能黏贴给AIAI给出一段分析之后我还要回到记事本里找之前记录的命令再看一眼是哪台机器然后切回终端执行。如果执行结果不理想整个流程再循环一遍。最崩溃的是切窗口那几秒钟里日志已经滚过了我又得重新翻屏或者加grep再查一次。三开不是三个工具并存的问题而是信息在三个窗口之间反复搬运的问题。每一次搬运都有损耗格式会乱、重点会丢、上下文会断。更隐蔽的成本是人肉记忆——机器A试过什么方案机器B的报错和机器C有什么关联全都得靠脑子和记事本。时间一长我就在想为什么不能让AI直接长在终端旁边让它自己看着日志、自己记住排查进度而不是等我手动喂给它这个念头就是Mini Assistant的起点。我不是要做一个大而全的运维平台只是想把SSH客户端 记事本 聊天框这三个窗口的事情合并成一个有上下文的AI运维工作台。折腾了大概两个月我自己日常排查故障基本不再三开了也算达到当初的目标。这篇文章把整个设计思路、关键实现和踩过的坑都写出来给同样被三开折磨的运维或后端同学做个参考。1.1 一次深夜故障处理的完整还原拿我遇到最多的一类情况举例接口超时率升高。传统模式下我的操作路径大概是这样的登录跳板机再SSH到目标机器开始看应用日志确认是不是出现大量超时报错。发现报错堆栈里有数据库连接池相关的关键字复制这段报错到聊天框里问AI。AI让我查一下连接池配置和当前活跃连接数我切回终端敲jstat或者翻配置文件。拿到结果后把输出头尾截取一段再贴回对话里追问AI这个数据正常吗。中途电话进来处理完继续结果忘了刚才看到哪一行只能重新滚动日志。这套流程走下来少则二十分钟多则一个小时。最消耗精力的不是查日志本身而是每次切换窗口之后都要重新找状态AI不知道我刚才已经确认过数据库连接池没问题于是又建议我去查连接池我就得解释一遍刚才查过了参数正常。这种重复沟通在当地方很常见本质原因是AI没有我的会话记忆也没有终端输出的实时数据。1.2 三开模式的隐性成本清单我把传统三开的成本整理成了一张表给自己一个动手改造的理由成本类型具体表现后果上下文断裂AI不知道你查过什么、确认过什么、正卡在哪一步重复沟通、建议失焦、排查路线反复格式转换损耗终端日志需要清洗后才能贴给AIAI命令要人肉校验后才能执行大量时间花在复制粘贴和人工翻译上人肉记忆负担机器信息、排查顺序、已验证假设都靠脑子和记事本容易遗漏、容易搞混环境、换个人接不了手安全隐患记事本里堆着明文命令和IP临时敲的高危命令没有记录误操作难以追溯也没法复盘现在回头看第四条才是真正让我下定决心改造的。记事本记东西没错可是每台机器干了什么操作、谁执行的、执行前后状态如何没有一个可审计的链路。如果AI能成为中间层替我做记录、替我做初步校验、把高危操作拦下来确认我一个人在夜里值班的底气会足很多。1.3 我需要的不只是一个聊天框市面上并不缺AI聊天工具我也装过不少插件。但尝试一圈之后我发现一个核心问题大多数AI工具是问答导向的不是排查导向的。问答导向的意思是你给我一段文本我给你一段回答。它不关心你在哪台机器上、你当前在查什么问题、你前面执行过几条命令、日志还在滚动。运维排查恰恰最需要过程信息——人和AI的对话只是一小部分更多上下文藏在终端输出、历史命令和操作顺序里。我需要的不是把聊天框搬得更近而是让AI接入一条完整的会话流水线像一位坐在我旁边的同事那样从头到尾看着我在干什么并且能在我询问时给出基于真实情况的建议。这就是Mini Assistant在设计上和普通AI终端插件最大的差异点先有会话上下文再有AI对话。上下文是第一公民聊天只是消费上下文的接口之一。2. 现成方案为什么打动不了运维决定自研之前我把市面上能试的方案都试了一遍。不是说它们不好而是它们的定位和我的诉求错位。梳理一下不合适的点也方便后面设计时绕开同样的问题。2.1 通用聊天框的三个盲区最直接的方案当然是让AI帮忙查资料、解释报错。问题在于这种工具存在于终端之外和我的实际操作是脱节的。盲区一是没有实时终端数据。我必须手动复制输出给它而且只能复制一个片段。问题是排查故障时经常是日志持续滚动多窗口输出互相印证的状态靠截图和复制信息永远不全。盲区二是没有记忆。同一个故障背景下每次开新对话都像来了一个失忆的新人我得从头讲项目背景、机器环境、观察到的现象。盲区三是不给执行反馈闭环。它告诉我可以试试这个命令但试完之后结果怎么样、下一步该怎么做它不知道。真正的排查是假设-验证-修正的循环通用聊天框只能覆盖其中一步。2.2 运维平台为什么又太重还有一类现成品是运维自动化平台自带堡垒机、监控告警、CI/CD、工单系统。功能确实全但部署和配置成本很高通常需要一个专职团队维护。对只有几台到几十台机器、以业务开发兼运维的小团队来说拆一个完整的CMDB出来有点杀鸡用牛刀。我不是否定平台的价值而是觉得中间还缺一层东西一个轻量的、长在终端旁边的智能助手。它不做资产管理不做告警聚合只专注我正在排查一个问题AI帮我承接上下文、解读输出、生成命令并安全执行。这个定位比完整平台小得多但对日常效率的提升更直接。2.3 Mini Assistant 的定位与取舍所以Mini Assistant从第一天起就明确不做以下事情不做监控数据采集不替代Prometheus之类已有的监控体系。不做CMDB不维护机器资产清单。不做发布系统不管上线部署流程。不接工单系统不做审批流。它只做一件事在你打开终端排查问题时AI能看见你现在所处的环境、正在滚动的日志、前面跑过的命令并且能基于这些信息给出诊断建议和可执行命令。如果需要更全面的平台能力它能通过API把只读数据拉进来辅助分析但绝不会反向去修改别人系统的配置。这个取舍很重要。把边界划清楚之后整个工具的技术形态就变得很轻一个命令行工具加上一个AI调度核心可以运行在任意一台开发机或跳板机上不需要部署一堆服务。2.4 技术选型与架构骨架架构上我把Mini Assistant分为四层每层职责单一终端桥接层负责和真正的shell会话交互。它启动一个伪终端PTY把用户的所有输入输出都记录成事件流同时支持向该会话注入命令。选PTY而不是普通管道是为了拿到完整的终端交互体验比如某些命令需要交互式确认、需要观察颜色输出和进度条。上下文引擎把事件流加工成AI能理解的会话上下文。它维护一个按时间排序的事件列表做去重、裁剪、摘要化并按固定模板拼装Prompt。决策与安全层凡是AI生成的命令都先经过命令分类器判断风险等级再决定是自动放行、提示确认还是直接拒绝。所有执行操作都写入审计日志。LLM网关层适配不同的大模型API。本地测试可以直接连开源的量化对话模型有条件的团队也能接更强的商业模型网关层统一了请求格式。在语言选型上我用了Python做原型因为LLM相关的SDK和数据处理生态最成熟。终端桥接用了第三方库来做PTY管理避免自己踩系统调用的坑。整个工作台以TUI形态起步界面分成三个区域上方是实时终端输出中间是AI建议列表下方是命令输入框。跑通之后再考虑要不要加Web界面。3. 核心设计AI是怎么看懂你正在排查的问题这一节是整个工作台的核心也是和普通聊天框区别最大的地方。我花了很多时间打磨上下文引擎因为AI回答质量的下限由模型决定上限由上下文决定。3.1 会话上下文引擎把排查过程变成一条事件流水线我的第一个版本很简单把终端输出全部塞给AI让AI看着原始日志回答。结果很快发现不行打开调试日志五分钟就刷了几万行模型根本抓不住重点而且费用也扛不住。于是改成事件流水线的思路。终端里发生的每一件有意义的事都记录成一条结构化事件。事件的类型包括用户输入的命令、命令的输出摘要、用户标注的备注、系统自动抓取的错误片段、AI自己执行的命令与结果。事件流按时间排序就是整个排查过程的时间线。这样做的好处是AI能知道用户先查了磁盘使用率然后看到了报错接着执行了重启命令之后观察了两分钟。这种过程感对判断问题非常关键。比如日志里出现某个报错AI看到你是重启之后才出现的就会优先怀疑重启没拉起来新配置而不是建议你重复重启。3.2 上下文注入策略窗口、裁剪、摘要三层处理事件流水线不能全量进Prompt需要做信息减负。我采用的是窗口 裁剪 摘要三层处理窗口由于上下文长度有限默认让AI看到最近50条事件。更早的事件即使重要也已经被摘要化处理过了。裁剪同一行日志重复刷屏超过三次就折叠成[相同日志重复N次]超长输出只保留头部和尾部中间用[已省略M行]占位。摘要每当事件条数超过窗口上限就把最早的一批事件丢给模型做一次压缩总结生成一条早期排查摘要保留在上下文里。举个实际例子用户执行了tail -f app.log刷了五分钟屏。事件流水线里存的不是五万行原始日志而是前50行日志采样、高频错误列表去重计数、最后30行日志尾部。当用户问这个日志正常吗AI看到的是提炼后的关键信息而不是被海量重复日志淹没。3.3 命令生成与执行回路从建议到反馈完整闭环最初我对AI的期望只是能解释报错后来发现运维场景真正需要的是一个执行闭环AI给出建议命令、用户确认、命令执行、输出回传、AI根据输出继续判断。如果AI只能给建议而没有执行反馈它永远不知道自己的命令到底跑出了什么结果。在Mini Assistant里AI生成命令不是直接扔给用户一行文本而是生成一张结构化的命令提案包含命令内容执行目的为什么要跑这条命令预估影响是只读操作还是会改状态可能的风险等级用户看到提案后可以选择跑、改、或者拒绝。同意执行后命令通过终端桥接层注入会话执行输出再作为新事件进入流水线AI就能继续分析。比如AI建议df -h看看磁盘输出显示/dev/vda1使用率百分之九十五AI就能直接接一句确认根分区磁盘使用率过高下一步建议查一下哪个目录占用最大不用用户再手动复制结果去追问。这一套回路跑通之后我才真正感受到工作台这个词的分量AI不再是被动问答的字典而是能主动引导你去验证假设的同事。4. 安全护栏AI 接管终端之前必须想清楚的三道闸让AI生成命令不难难的是让一个可能产生幻觉的模型安全地在生产环境执行命令。我在这块踩过坑也报废过一台测试机的数据虽然能恢复但教训深刻。所以后来专门做了三道安全闸。4.1 第一道闸命令风险分级所有AI生成的命令必须先过一次分类器归入四个等级等级典型命令类型处理方式L0 只读命令ls, df, ps, free, tail, netstat直接执行无需确认L1 常规命令查看配置、重启应用、清理临时文件用户确认后执行L2 高风险命令删除数据、修改iptables、格式化分区、重启核心库双重确认必须输入原因留审计记录L3 禁用命令清空全部数据、批量kill核心进程、未知来源脚本AI无权生成直接拦截分类器是规则和模型结合的。先用正则和命令名匹配快速拦截明显的危险命令再交给一个专用的小模型做语义分类。比如rm -rf /data/cache这种正则层就会拦住要求二次确认。我见过不少工具只用正则做安全结果AI换个写法就绕过去了所以在规则层之上加模型层是有必要的。4.2 第二道闸Dry-run 优先与等价替换凡是支持--dry-run或试运行模式的命令AI必须优先走试运行。比如iptables相关规则、容器编排工具的变更操作很多都有dry-run能力先跑一遍拿到预期结果再问用户是否真的要执行。对于不支持dry-run的操作采用等价只读查询代替。比如用户想清理一天前的临时文件AI不建议直接find /tmp -mtime 1 -delete而是先跑find /tmp -mtime 1 -exec ls -lh {} \;把将被删除的文件列出来给用户确认。确认之后再执行删除并且执行前自动把文件清单存储到一个备份目录里万一删错还能恢复一部分。4.3 第三道闸全程审计与状态快照每一项执行动作都会写入审计日志字段包括时间、会话ID、用户、命令全文、风险等级、确认状态、执行结果摘要、耗时。日志以JSONL格式落盘方便后续用工具分析。对于可能改变系统状态的操作执行前还会做一次快速状态采集。比如抓住关键文件的md5、当前开放端口列表、正在运行的进程列表。排查结束之后这些快照可以用来对比操作前-操作后的差异从被动防守变成主动复盘。三道闸都上线之后我心里那块石头才算落了地。AI接管终端不是把钥匙直接交给它而是一层层确认后在可审计的轨道上让它帮我把活干了。5. 落地实测效率提升与踩坑教训工具做出来是拿来用的不是拿来展示架构的。我在自己负责的几台业务服务器上实际用了两个月也踩了不少坑这里挑几个典型记录一下。5.1 实测对比一次故障处理到底快了多少我专门记录过两周的数据对比用传统三开和用Mini Assistant处理同一类业务报错的时间。样本不算大但趋势很明显指标传统三开Mini Assistant平均单次故障处理时长约35分钟约15分钟需要切换窗口的次数12到20次2到4次重复向AI解释上下文的次数4到6次基本为0需要翻记事本查找信息经常很少最明显的变化不是打字快了而是重新进入状态的时间大幅减少。以前每次切回终端都要花二十秒回忆刚才做到哪一步现在AI自己就是那个记忆体我从聊天界面里最新的建议接着往下走就行。5.2 踩坑之一模型幻觉生成的路径根本不存在有一次排查一个服务配置文件加载失败的报错AI一本正经地给出一个修复方案让我去修改某个路径下的配置文件。我复制路径到终端准备打开时发现这个路径根本不存在。后来分析原因是模型在训练数据里见过类似场景于是脑补了一个常见路径而它并没有真正查看当前这台机器上的文件结构。解决办法是给Mini Assistant加了一个只读文件检索工具当AI需要引用配置文件路径时必须先去目标机器的常见目录里检索真实存在的文件再基于检索结果回答。同时要求AI在不确定时标注未验证不能把推测当事实输出。5.3 踩坑之二上下文污染让AI回答明显跑偏有次排查网络抖动终端在持续刷一条非关键日志刷屏频率特别高。结果AI被高频刷屏信息带偏判断问题的注意力全部集中在无关日志上忽略了真正需要关注的超时记录。这让我意识到上下文窗口里的存在感不等于重要性。高频率出现的日志并不代表它就是根因反而可能是噪音。修复方法是调整裁剪策略对重复日志做加权降噪按行内关键字聚类而不是按出现次数排序。AI只有在用户明确指定关注某类日志时才会提高对应内容的权重。5.4 踩坑之三过度自动化差点惹出大麻烦有一次AI检测到某个应用进程占用内存过高主动生成的命令是把该进程重启一下。命令本身不算高危风险分级是L1我习惯性按了确认结果按完才反应过来那是生产环境的进程。虽然没造成大事但吓出一身冷汗。之后我把默认策略从执行提效改成保守优先AI生成的所有命令默认进入待确认状态只有L0只读命令可以直接跑。L1及以上的命令必须点击确认并附带目的说明。虽然多了一步确认操作但心里踏实得多。自动化追求的是让人少重复劳动不是让人失去控制。6. 后续可以扩展的方向与我的使用体会工具目前已经稳定跑了一段时间但我清楚它的能力边界还很大只是没有必要在一开始全做完。挑几个我自己觉得值得做的扩展方向聊聊。6.1 三个值得做的扩展方向一个是定时巡检与自动小结。让AI按照固定的时间窗口扫描日志把高频告警、异常趋势自动整理成一段简报运维上班打开终端就能看到昨夜发生了什么。这个功能做出来的话会让值班效率大幅提升。另一个是和已有监控系统的只读打通。比如从监控API拉取指标曲线AI结合指标趋势和终端日志一起分析判断资源瓶颈在应用层还是系统层。只读方向打通就不做反向控制避免多套系统互相干扰。还有一个是多主机会话聚合。把几台机器的终端会话并列接进一个工作台AI可以跨机器比对日志时间线定位分布式问题。这里面会话隔离和权限控制比单机要复杂但值得慢慢做。6.2 我最后想说的几个体会回到标题里的三开问题。这个工具做下来我最大的体会是问题从来不在工具的数量而在于信息是否共享同一个上下文。记事本里记的是线下笔记聊天框里是碎片化问答SSH终端里才是现场——三套信息各说各话效率一定上不去。AI最有价值的地方不是帮你打字而是它能成为那个始终知道我们查到哪一步的人。如果你也想试着做类似的工作台我的建议是从小切口开始先做一个能抓取终端事件并把它变成会话上下文的工具不需要AI的部分光是自动记录排查时间线这一个功能就能省不少事。然后再加上AI建议、命令执行和安全护栏一步一步迭代。别一开始就想着做完整平台工具是自己用的好用比完整重要得多。