下午三点半笔记本往扩展坞上一插外接显示器直接显示“无信号”电源灯一橙一橙地闪。我打开搜索引擎把“外接屏 无信号 HDMI 合盖 黑屏”这几个词来回换着花样本搜了一下午得到的是二十几条互相矛盾的“标准答案”。最后真正解决问题的不是搜索引擎里某一条被顶到最前面的帖子而是我把整件事丢给了一个具备工具调用能力的 Agent它自己查日志、自己搜资料、自己执行命令、自己做完验证前后十分钟收工。这篇文章就把这次从“搜索引擎排障”到“Agent 排障”的完整过程拆开来讲顺便聊聊在这类实操场景里Agent Skill 到底应该怎么设计才不会被模型用成一坨废纸。1. 故障起点一块不认账的扩展屏1.1 现场现象与我的第一轮手工排查先说环境笔记本是 Linux 系统通过扩展坞上的 HDMI 口接了一台 4K 外接屏平时合盖外接使用。当天下午合上笔记本盖子之后外接屏虽然能点亮背光但一直显示“无信号”OSD 菜单里的输入源也确认过是 HDMI无论怎么按都没反应。我的第一反应和别人一样先怀疑线材和接口。我把 HDMI 线换成了另一根没用把扩展坞重新插拔了一遍没用把显示器电源彻底断电一分钟再开还是没用。接着我试了系统层的操作用快捷键触发一次显卡驱动重置屏幕黑了一下又恢复正常但外接屏依然“无信号”。这时候我意识到问题可能不在物理链路而在显示输出的配置状态系统可能在外接屏和内置屏之间把主显示输出搞乱了尤其是合盖状态下内置屏被禁用但外接屏并没有被系统重新设为主输出于是信号虽然到了显示器却因为输出模式不匹配而完全不出画面。1.2 搜索引擎给我的“标准答案”为什么全都失效打开搜索引擎输入“外接屏无信号”后排在前面的无非是这么几类换一根 HDMI 或者 DP 线优先买“认证线材”重新插拔清理接口灰尘在显示器 OSD 菜单里切换输入源更新或回退显卡驱动关闭显示器节能模式使用“显卡驱动重置快捷键”检查扩展坞固件或驱动。这些东西单拎出来每条都不算错但它们有一个共同问题它们是在给一个“平均化的人”讲“平均化的解决方案”而我的电脑是什么显卡、我的显示器 EDID 能不能被正确读到、我的电源管理策略合盖之后到底做了什么、我当前的 xrandr 输出是什么状态——搜索引擎完全不知道。搜索结果里的答案摆在那里但我需要自己判断哪一条适用于我的环境判断不了就去试试错了再换。一个下午耗下来我的感觉是搜索帮我节省了“找到答案”的时间却完全没有帮我节省“验证答案是不是我的答案”的时间。2. 卡壳的真正原因搜索引擎缺少“执行闭环”2.1 搜索结果缺的不是信息而是“你的机器上下文”搜索引擎本质上是一个信息分发系统它不会去读你机器上的/sys/class/drm下的连接状态不会去看你的内核日志里有没有 HDMI 报错也不清楚你合上盖子的一瞬间 systemd 的电源管理把哪条输出链路关掉了。它能给我的只是一堆“可能原因”的列表。所以哪怕我看到某条回答写得再专业也得自己动手把“通用答案”翻译成“我的机器上的命令”。比如看到别人说“用 xrandr 强制切换输出”我首先要跑一下xrandr --query看看接口名到底是 HDMI-1 还是 HDMI-A-1看看当前 primary 是哪个 output再看看当前分辨率是不是已经越界。搜索引擎告诉我“应该用 xrandr”但不会替我把命令跑出来更不会告诉我跑完之后的回滚命令是什么。2.2 网页信息到系统命令之间隔着一个人传统排障链路是这样的搜索发现候选方案 → 人判断方案 → 人在终端复制执行 → 人看输出 → 判断是否生效 → 没生效再继续搜。这个循环里最花时间的不是“搜”而是每一步之间的人工翻译和人工验证。我自己试过的方案里有一部分甚至根本没有任何输出变化。比如修改显示器输入源之后画面一直黑着我根本不知道是显示器没切过来还是显卡没有输出。搜索帮不了我因为屏幕是黑的我能交互的唯一窗口只有一个终端——可是我在那个时刻没想起来先看一眼xrandr的输出。人一着急动作就会变形。2.3 换个思路把“搜索、判断、执行、验证”全部交给 Agent事后回头问题的本质不是我缺知识而是我缺一个能够把“知识”和“操作”串起来的执行闭环。搜索引擎不执行命令终端不搜索资料最后只剩下我在中间当翻译机。Agent 的价值恰恰就在这里它一个大模型可以做判断和检索同时又能通过工具调用去执行命令、读文件、看日志然后把执行结果拿回来继续推理。这就像把一个只会告诉你怎么修车的搜索引擎文章替换成一个站在你旁边、手上有扳手、还能跑诊断程序的修理工。我当时把问题转化成一句对 Agent 说的话“外接屏无信号请你帮我排查注意我合上了笔记本盖子。所有会改变显示输出的操作先告诉我再执行。”这句话之后就基本是它自己在跑完整链路了。3. 准备环境把 Agent 接进真实系统3.1 我选择的 Agent 工作台和它的 harness平时我尝试过不少 Agent 框架这次用的是一款叫 Hermes Agent 的第三方工作台。它给我最大的体感是“工具感清晰”不是把整个电脑交给模型随便折腾而是通过配置文件告诉模型它有哪些工具可用、哪些目录可以读写、哪些命令需要人工确认。这个概念在 Agent 圈里经常叫 harness——就是连接大模型、工具和本地环境的那层脚手架。我更推荐新手从这样的工作台起步而不是直接裸写代码调用大模型接口去“哈喽世界”。因为显示排障这种场景里模型最需要的不是复杂的 Agent 算法而是安全可控的 Shell 执行能力该跑的命令能跑不该跑的命令跑之前必须停下来问我。3.2 给 Agent 配齐排障需要的四类工具我的技能包最终只用了四类工具Shell 命令执行器跑xrandr、lspci、journalctl、cat /sys/class/drm/*/status这些诊断命令网页搜索工具让 Agent 在定位到某个具体现象之后去检索“这个现象通常怎么修”而不是凭模型记忆瞎猜文件读取工具读取系统日志、显示输出相关状态文件用户确认接口在执行修改性命令前Agent 需要回到对话里征求我的同意。这里有一个很容易被忽略的细节很多 Agent 框架默认给的是“一个 bash 终端”但排障场景不建议给完整交互式终端。完整终端意味着模型可以执行任何命令包括rm、shutdown、dd。我更倾向于用命令白名单或者只读模式起步把真正需要写操作的命令单独列出来。第一次跑这个技能包的时候我把写操作全部关掉了只允许读取等确认流程正常了再放开。3.3 用 Skill 定义排障流程而不是把命令硬写进提示词一开始我也想偷懒直接把一大段命令塞进系统提示词里。后来发现这样不可行每个用户的接口名不一样每个系统的日志路径不一样硬编码的命令在换一台机器之后就失效了。所以我改用“Skill”的方式把一次排障过程写成一个特定格式的 Markdown 文件里面包含触发条件、诊断步骤、关键命令、回滚方案。Agent 在收到“外接屏无信号”这类请求时会自动读取这个技能文件然后按步骤执行。核心文件长这样--- name: external_display_diagnosis description: 排查外接显示器、扩展屏无信号/黑屏/无法识别的问题适用于笔记本合盖后外接屏不亮的情况 tools: - shell - web_search - ask_user platform: linux --- ## 使用时机 - 用户报告外接屏无信号 - HDMI/VGA/DP 接口检测不到显示器 - 合盖后外接屏黑屏 - 显示输出切换后找不到画面 ## 第一步收集系统信息 1. 运行 xrandr --query记录 primary、connected/disconnected、当前分辨率模式 2. 运行 lspci -nnk | grep -iA3 vga 确认显卡型号与驱动 3. 读取 /sys/class/drm/*/status 下的所有连接状态 4. 从 journal 中提取最近一次 HDMI/DRM 相关日志 ## 第二步判断故障类别 - 如果 HDMI-1 显示 disconnected优先怀疑物理链路、EDID 读取、线材 - 如果 HDMI-1 显示 connected 但没有任何模式被标记为 primary怀疑合盖后主输出未接管 - 如果日志中有分辨率/刷新率超限考虑降级输出模式 ## 第三步最小变更修复 - 任何修改显示输出的命令先向用户确认 - 保存/显示当前 xrandr 配置后再改动 - 不要同时修改多个输出参数 ## 回滚策略 - 记录修改前的 output 模式 - 如果执行后无信号恢复原模式 - 恢复 eDP 或内置屏输出确保不会彻底黑屏这个文件看起来简单但实际价值很大它把一次性的“搜索-执行-验证”流程固定成了可复用资产下次再遇到同类问题Agent 不需要从头推理而是直接进入这套诊断流程。4. 修复实录Agent 从发现到处理的全过程4.1 第一轮对话Agent 先告诉我“它不知道问题在哪”我把问题发给 Agent 后它没有立刻给我甩一个“建议换线”的答案而是先说了一段让我当时有点意外的话“我先看一下当前的显示输出状态和最近的日志再给你判断。可以吗”这个设计点很重要。真正能做排障的 Agent应该先承认“信息不足”然后主动去采集而不是靠大模型里的记忆硬答。很多 Agent 写失败就失败在模型太自信一上来就说“你需要更新驱动”然后开修最后把系统搞得更糟。我同意之后它连续执行了几条只读命令把输出丢给我看同时自己也根据输出生成下一步计划。整个过程非常像一位谨慎的运维同事先取证再下结论。4.2 数据采集xrandr 与内核日志里的蛛丝马迹Agent 先跑的xrandr --query输出里有两个关键信息eDP-1 connected primary 1920x108000 HDMI-1 connected 1920x108000eDP-1 是笔记本内置屏它被标记为primaryHDMI-1 是外接屏它虽然显示connected却没有任何 primary 标记。在合盖场景下系统默认关闭内置屏但主输出仍然停留在 eDP-1 上HDMI-1 没有接管主输出的职责。于是外接屏虽然“收到了信号”但信号内容本身是异常的显示器就给出“无信号”。Agent 接着读了/sys/class/drm/card0-HDMI-A-1/status内容也是connected说明物理链路和 EDID 是通的。它又翻了内核日志找到几条和 HDMI 输出切换相关的消息但没有发现硬件报错。到这里Agent 的判断就变得很聚焦不是线不是接口不是驱动崩溃而是输出主次配置问题。4.3 搜索引擎成了 Agent 的“第二大脑”Agent 在这时候做了一件很有意思的事它没有直接凭记忆去改xrandr而是先调用网页搜索工具检索了“笔记本合盖外接屏无信号 xrandr primary”相关的资料。我当时好奇地问它为什么要搜。它给出的回答是“这类问题在不同桌面环境和内核版本下的表现差异很大我想确认一下当前这个现象最常见的标准修复方式再结合日志判断。直接改 primary 有风险想看看有没有其他已知坑。”这是搜索引擎在这里扮演的角色不是替代 Agent 的判断而是为 Agent 的判断提供额外证据。搜索结果里确实有几条帖子提到合盖后需要手动把外接屏设为 primary 并关闭 eDP但也有人提到如果直接--off内置屏会导致下一次开盖时登录界面跑到一个不存在的显示器上。Agent 看到这些之后把风险判断加入了回滚策略这个细节我一开始自己手动搜的时候根本没注意到。4.4 执行修复与回滚设计Agent 没有急着执行而是把将要运行的命令先展示出来要我确认# 记录当前输出状态便于回滚 xrandr --query /tmp/xrandr_before.log # 将外接屏设为主输出并关闭内置屏输出 xrandr --output HDMI-1 --primary --auto xrandr --output eDP-1 --off我确认之后才看到它在终端里逐条执行。执行第一句xrandr --output HDMI-1 --primary --auto后外接屏大约一两秒后突然亮了起来但是背光还在闪分辨率看起来也没有完全正确。Agent 没有马上宣布成功而是继续往下执行xrandr --output eDP-1 --off这一步之后画面稳定下来显示输出的模式也正常了。整个过程中最让我满意的是回滚设计Agent 在改动前先保存了修改前的状态并且明确告诉我如果最终结果是“内置屏和外接屏同时黑掉”它会执行xrandr -s 0或者重新打开 eDP 输出而不是放任黑屏让我去盲修。4.5 验证闭环外接屏重新出现了命令执行完之后Agent 没有直接说“修好了”而是做了一次完整的验证重新执行xrandr --query确认 HDMI-1 已经被标记为primary读取/sys/class/drm/card0-HDMI-A-1/status确认状态仍然是connected打开系统显示器设置页截图核对分辨率与刷新率在对话里询问我“现在外接屏画面是否稳定如果合盖后依然有问题我会继续检查 logind 的 HandleLidSwitch 配置。”我把笔记本电脑盖子再合上、打开各试了一遍画面都正常。到此故障才算真正闭环。对比我之前的“搜索结果”之旅区别一目了然搜索引擎只告诉我世界上的其他人可能遇到什么问题Agent 告诉我我面前的这台机器此刻到底发生了什么并把它修好了。5. 事后复盘Agent 能修但不能瞎修5.1 哪些环节最容易判断失误这次成功并不代表 Agent 在显示排障里无所不能。我复盘时列出了几个它仍然容易翻车的点“已连接”不等于“有信号”xrandr 显示connected只说明 EDID 链路通不代表显示模式被正确应用Agent 必须结合分辨率模式、日志和用户反馈综合判断接口名会变有些机器上 HDMI 显示为HDMI-1有些是HDMI-A-1如果技能文件写死了接口名在别的机器上就会失效盲目执行 “--off” 会害死人如果 Agent 在无桌面对话环境下把内置屏关掉而外接屏又没起来用户只能盲操作驱动问题不能全靠 xrandr 解决如果日志里出现 TDR 或者 GPU hangAgent 需要先去定位显卡驱动状态而不是直接改输出。这些判断失误的根源基本都是 Agent 过早进入“开修模式”没有先做足信息采集。我的经验是在技能文件里必须把“先采集信息”写成强制第一步并且给模型一个“如果信息不足就继续采集”的提示而不是让它基于猜测下结论。5.2 给 Agent 设好权限边界和人工确认Agent 修电脑本质上是在替用户执行命令。根据实际操作经验我会强烈建议至少在排障场景里做三件事默认只读让 Agent 一开始只能跑xrandr --query、journalctl、lspci、cat这类只读命令修改命令必须展示并确认凡是涉及--output、--mode、--off、重启服务、加载内核模块这类会改变系统状态的操作在执行前必须把命令原文发给用户确认提供回滚命令每次执行修改前Agent 必须给出“如果失败怎么办”的恢复命令。在实际配置里我把技能文件分成两个阶段第一阶段只读诊断第二阶段才是确认后的修复。Agent 不会跨过第一阶段直接进入第二阶段这样可以大幅降低误操作风险。提示如果你管的是一个多用户系统或者一台你不方便反复重启的机器千万别图省事省掉人工确认。黑屏状态下的“无头排障”是最考验回滚设计的一个没有回滚策略的 Agent 比病毒还危险。5.3 这次方案里值得复用的排障思路把这次的经验抽出来它不只是一个“外接屏修复”任务而是一个通用的“排障 Agent”模板明确故障边界用户看到的“无信号”可能对应十种不同的原因先收集物理层信息线材/接口/连接状态再收集系统层信息显卡、驱动、日志、当前输出配置把已知原因和实际数据匹配缩小范围执行最小变更且必须有回滚用命令输出加用户确认双重验证。这套方法换成帮别人排查打印机、网络、声卡也一样成立。Agent 之所以能在这次任务里起到作用不是因为它有大模型里的“通用知识”而是因为它把这套方法论真正落到了“读、搜、命令、验证”四个动作上。6. 沉淀把一次修复变成一个可复用的 Skill6.1 Skill 文件要放在哪里以及怎么被加载很多 Agent 框架都支持“Skills 目录”的概念。以 Hermes Agent 为例我习惯把所有技能文件放在用户的~/.hermes/skills/目录下每个技能一个子目录里面放一个skill.md和可能附带的脚本。运行时 Agent 会扫描这些文件把它们作为工具上下文注入给模型当用户请求命中 description 中的场景时模型就会主动去调用这个技能。我这次的完整技能目录大概是这样的~/.hermes/skills/ └── external-display-diagnosis/ ├── skill.md └── scripts/ └── collect_display_info.shcollect_display_info.sh负责把关键信息一次性采集好避免 Agent 在对话里一条一条执行太多命令导致上下文混乱。脚本内容不复杂就是把xrandr --query、lspci -nnk | grep -iA3 vga、cat /sys/class/drm/*/status、最近的 HDMI/DRM 日志都输出到一个文本块里Agent 一次读取就能了解全貌。6.2 描述词的写法直接决定了技能会不会被调用很多人写 Skill 最大的问题是 description 写得太空。比如写“显示器问题排查”就不太好因为模型无法判断这个技能具体在什么时候该用。更好的写法是把触发场景、错误现象、硬件类型都写进去description: 当用户报告外接显示器无信号、黑屏、HDMI接口检测不到显示器、 笔记本合盖后外接屏不亮、开机后只有内置屏被识别等问题时 使用本技能进行系统诊断与最小变更修复。 适用于 Linux X11/Wayland 环境下的常见显示输出故障。描述词越具体Agent 在遇到类似问题时就越容易把用户请求和这个技能匹配起来。反之一句“修复显示器”会让模型要么乱调用、要么干脆不调用。我的另一个经验是skill 文件里的步骤描述不要写成“教科书”要写成“决策分支”。模型不是人类它最容易照着顺序一路执行到底所以你应该在文件里明确写清楚“什么情况下执行 A什么情况下停止并回到询问用户”。这一步能让技能在不同环境下都相对安全。6.3 后续还能怎么扩展这次只是一个显示输出故障的最小闭环。实际操作中我已经在这个基础上做了两件事把日志采集脚本扩展到显卡厂商维度比如 NVIDIA 额外查nvidia-smiIntel 查intel_gpu_top的可用性和驱动状态AMD 查amdgpu内核日志把“回滚策略”做成一个独立的通用技能任何会修改系统状态的 Agent 任务都会先去调用它再执行主流程。我也在考虑把这类诊断任务拆成多个 Agent 协作一个 Agent 只负责采集信息并输出结构化结果另一个 Agent 负责根据结构化结果搜索和推理修复方案最后一个 Agent 负责执行和回滚。这种多 Agent 编排比单 Agent 每次都从头读日志要稳定得多但代价是需要额外的消息协议和状态管理目前还在试。个人体会是别一开始就想做“万能修电脑 Agent”从一个具体的、反复出现的故障开始做出一个能用的 skill然后再慢慢长成一个工具集这才是 Agent 项目最务实的落地路线。最后再分享一个小技巧。写这种排障类技能时一定不要只给模型“命令清单”要给它“验证标准”。比如修改完显示器输出后什么状态才算修复成功接口要显示 connected目标输出要标记 primary用户要确认画面稳定。没有验证标准Agent 往往会“执行完就宣布胜利”而真正的故障并没有解决。这套思路换到网络、外设、存储这类问题上一样好用。