医疗大模型从小事做起（九）：智能体替我修电脑

对于信息科工程师来说，修电脑是个绕不开的话题。尽管很多人不愿意接这种琐碎的、对自己业务提升不大的活，但很多时候，外界还是认为，修电脑就是信息科分内的事、擅长的事。

这个时候，如果有个“搭子”能帮着信息科把电脑修了，那确实是两全其美的事，既能回应用户需求，也节省了自己的时间，保障自身主线工作不受干扰。

问题是，上哪儿找这么个“搭子”？

最近我用桌面级智能体解决了几件修电脑的琐事，在此做一分享，希望能为大家提供一种新的工作思路。

案例1：电脑夜间自动重启

这是一台实验室同学的电脑，据他本人讲，这台电脑夜间挂机跑深度学习。早上过来一看电脑自动关机了。这个问题每隔一段时间就会发生，非常影响实验进度。

他找到我的时候，我正在做自己的实验，内心也是比较抵触。但人家也说了，听说你是医院信息科出来的，这点小事应该难不倒你。这话一说，我又不好意思拒绝，就勉强接了活。

我扫了一眼，他电脑上装了好几个桌面级智能体。征得他同意后，我打开Kimi Work，简单输入了提示词，说明了情况。

我当时的排查思路是，电脑意外关机，系统事件日志是重要的诊断依据。虽然我没时间，但我可以把这个思路告诉Kimi，让它去替我分析。

果不其然，Kimi Work经过一番分析，给出结论：根据系统事件日志分析，昨晚你的电脑确实发生了自动重启，而且连续重启了两次，两次重启都是Windows自动更新导致的计划内重启，不是故障或异常，并给出了准确的重启时间线和证据链，如下图所示。

看完Kimi给出的结论，我心里大概有数了，但不能照单全收；接下来，我开始跟当事人逐一核对证据：

首先，Kimi给出的重启时间和当事人提供的文档、模型意外关闭的时间对上了；其次，针对“当事人看到关机，Kimi诊断结果却是重启”的疑点进行核实：使用者早晨敲击键盘鼠标后，设备停留在系统登录界面，运行中的程序全部丢失。这正是系统重启后的典型现象，并非断电关机。

最后，为了强化证据链，我让他回忆一下，最近几次发现电脑意外关机的时间。

他也很聪明，从聊天记录里翻出每次跟朋友抱怨电脑意外关机的对话，我让Kimi调取了近期夜间自动重启的时间线，跟他提供的意外关机的时间，都对得上。

至此，问题基本定位。这就是由于Windows自动更新导致的计划内重启，为了避免这种问题再次发生，影响他做实验，我们在Windows更新设置中，关闭了“更新后自动重启”选项。

案例2：电脑启动蓝屏

这是我另一个同学遇到的问题：他的笔记本电脑近期开机的时候，都会先蓝屏一次，然后进入登录界面，这让他感到很不安。电脑里存着大量的实验资料，他担心这样的情况反复发生，影响电脑稳定性。

于是他找到我，还是一样的话术：听说你是医院信息科过来的，应该很擅长处理类似的问题了吧。我只好苦笑着接下这话，心想着怎么能不打断自己的进程，又能尽快给人把事儿处理了。

有了上次的经验，我又想到了桌面智能体。扫了一眼，他电脑上装着WorkBuddy。

于是，故技重施。我把电脑症状和需求打包成提示词，输入给WorkBuddy，然后它开始跑程序，我继续做我的事。几分钟后，WorkBuddy给出了一份详尽的分析报告：包括蓝屏代码、对应问题、建议处理措施等等。

我放下手头的事，开始分析这份报告。

首先，在故障详情中，它提到转储文件未生成，转储初始化失败，并且C盘剩余空间不足。在建议处理措施的第四条，它也建议清理C盘；此外，建议处理措施的第1、2、3条也有一定道理。但是，经我向当事人了解，这台电脑是近期线下购买的，在店里就更新了最新的固件和驱动，并且没有外接任何新硬件，大概率不是这方面的问题。第三，经我询问，当事人说最近几天装了好多软件，都装在了C盘，也就是说，近期确实是C盘空间发生了明显变化。

综合信息判断：C盘空间不足是本次蓝屏的直接触发条件，历史硬件告警为次要背景信息。

于是，我们把首要目标放在了清理C盘。这工作也交给了WorkBuddy，让它帮忙分析C盘可以清理的文件。它很快就给出了答案，但明确提示不会执行删除操作，删除文件操作必须人工确认。

最终，我亲自上阵，把C盘剩余空间从17G清理到35G，然后反复重启测试，开机蓝屏现象消失。在接下来一周内，这台电脑没有再发生蓝屏问题。我也建议电脑的使用者，在日常安装软件时，尽量不要装在系统盘，并且把C盘剩余空间保持在30GB以上。

讨论与启发

这两个案例给我很大启发：

一是智能体的介入，为“修电脑”这种琐碎的活，找到了一个性价比很高的处理路径。运维工程师掌握专业排查方法论，智能体承担日志读取、信息整理、现象推演这类重复性工作；工程师聚焦证据校验、风险判断、最终决策。这种分工模式，大幅降低排障试错成本，琐事处理基本不挤占核心工作时间，很适合信息科面对大量终端桌面问题的场景。

二是智能体输出的标准化排查流程值得沉淀复用。智能体专业的分析思路和分析流程，值得我们借鉴学习。一些院内终端高频故障（更新重启、磁盘爆满、蓝屏报错等），可以整理封装成智能体可调用的Skill，进一步提升问题处理的专业性和效率。

三是客观认清当前方案的局限。桌面智能体工具大多依赖网络运行环境，医院内网隔离环境下会存在部署障碍。文中提到两个案例都属于软件层面、系统日志可采集的常见故障。面对硬件物理损坏、完全无法进系统、无日志可读的故障场景，桌面智能体就很难发挥作用。在上文中我也演示了，智能体提供证据和处理思路，但证据的核实、处理思路的优先级，包括类似删除文件这样的敏感操作，必须由自己把关确认，不能当甩手掌柜。

个人思考，不到之处，敬请批评指正。也欢迎大家在评论中分享自己用智能体辅助运维的实践经验。

作者简介

李楠，CHIMA委员，医院信息化工作者，医学统计学博士在读。作者观点仅代表个人，纯属技术交流，与供职单位无关。