★ FEATURED ARTICLE 说起来你可能也遇到过这一幕早晨到工位把笔记本从休眠里唤醒外接显示器死活不亮OSD 菜单翻了一圈最后停在那行刺眼的“无信号”。以前我的流程是掏手机、打开搜索引擎输入“HDMI 无信号 怎么办”然后在一堆三天两头过时的帖子里翻找最后大概率靠“拔插一下”解决问题。现在我换了思路让一个Agent去干这件事。我给 Agent 准备了查询显卡状态、读取显示器连接、切换显示模式、重启显卡驱动的工具剩下的判断逻辑全交给它自己跑。说实话这两年Agent 开发是个热词各种Agent 框架也层出不穷但很多演示都停在“天气查询”“发邮件”这种低风险场景。真正让我觉得 Agent 有价值的恰恰是“外接屏无信号”这类看起来小、实际琐碎又需要动态判断的硬件问题。这篇文章我会把这个项目完整拆开为什么“无信号”难排查、Agent 跟搜索引擎的本质差异、工具层怎么设计、Agent 主循环怎么搭以及我踩过的坑。不吹概念直接给你能参考的代码和判断逻辑。1. 外接屏“无信号”为什么难查先看清问题的七寸1.1 成因分类不只是“线没插好”很多人一提“无信号”第一反应就是线材接触不良。但一个工作几年的工程师都会告诉你这只是概率最高的原因之一远不是全部。我归纳下来“无信号”这句话背后大致有四大类成因。第一类是物理连接问题包括 HDMI / DP / Type-C 线没插紧、接口氧化、线材本身损坏、转接头供电不足、显示器输入源选错。这一类的特点是系统里可能根本看不到这台显示器。第二类是输出模式问题Windows 上常见的“仅第二屏幕”模式一旦选错笔记本内置屏会黑、外接屏也没画面表现也像“无信号”。第三类是驱动与状态问题显卡驱动偶发崩溃、显示器 EDID 读取失败、分辨率刷新率超出面板支持范围系统能看到设备但输出不正常。第四类是电源管理问题笔记本在合盖/休眠/唤醒过程中丢失了 DP 链路外接屏需要重新“握手”。我用一张表把常见症状和怀疑方向放在一起这套分类后来也直接成了 Agent 的“先验知识”。症状表现大概率原因手动排查动作外接屏完全黑系统只显示内置屏线材/接口/输入源问题或“仅第二屏”模式残留重新插拔切换显示模式屏幕亮一下然后黑或花屏分辨率刷新率超出支持范围、驱动问题降低分辨率重启驱动笔记本合盖再打开后无信号电源管理导致 DP 链路丢失重新唤醒/切换模式让系统重新握手接上转接头后无信号转接头供电不足或 EDID 解析失败换直连/外接供电转接头1.2 传统“搜索引擎修电脑”模式的三个硬伤传统搜索引擎这套老办法能用但用起来很憋屈。最核心的问题是搜出来的是“通用知识”而你遇到的是“特定状态”。搜索引擎给你返回一百篇教程讲的是别人机器上的情形它不知道你当前是 A 卡还是 N 卡、驱动版本多少、系统有没有检测到显示器、EDID 有没有读出来。于是实际排查变成了一场“人肉翻译”你要先自己想办法收集信息再把症状翻译成搜索词然后过滤掉和你不匹配的帖子最后再照着操作。这个过程中最容易翻车的就是“上下文割裂”——你查到了一个“禁用再启用显卡”的操作但你不确定当前驱动状态适不适合这样干一个参数填错本来只是黑屏可能变成分辨率混乱。另一个硬伤是信息滞后。很多高排名的帖子是七八年前的那时候还是 Win7、VGA 时代现在满地都是 Type-C 转 DP、多显示器拓扑老经验不但帮不上忙还会误导。再加上搜索结果的排序更多依赖点击热度而非时效性你翻半天根本分不清哪些结论还适用于 2026 年的系统。所以我把搜索引擎这套模式看成一个“只给菜谱、不看你库存”的顾问。它能告诉你世界上有哪几种情况但没法替你确认你属于哪一种。这也正是 Agent 能切入的地方它不仅能拿到“菜谱”还能自己走进厨房看存货、尝味道、改火候。2. Agent 凭什么能“修好”从“搜答案”到“跑流程”2.1 Agent 到底是什么LLM 工具 闭环验证如果你去翻各种Agent 平台的文档会发现定义五花八门。剥掉包装我理解的 Agent 就三样东西一个大模型做“大脑”一组工具当“手脚”一个循环负责“观察 - 决策 - 行动 - 看结果”。它跟普通问答的本质区别是问答只在“说”Agent 在“做”。类比一下就很清楚搜索引擎是给你一本《故障排查手册》让你自己按图索骥Agent 是给你派了一个实习生他手里拿着手册自己会去查设备管理器、会跑命令、会看结果然后把每一步做了什么、为什么要这样做汇报给你。你要做的只是批准那些有风险的写操作以及在他卡住的时候给他一个方向。那么要修“外接屏无信号”我们需要这个 Agent 手上有什么工具呢我认为最少得有这些读取当前系统识别到的显示器列表包括连接端口、分辨率、EDID 信息读取显卡及显示驱动的设备状态判断有没有异常查询系统电源状态和显示日志看看是不是休眠/唤醒搞丢了链路切换屏幕模式和分辨率比如从“仅外接”切回“扩展”或者强制外部输出重启显卡驱动设备处理驱动崩溃导致的输出异常。有了这五个能力Agent 就不再是“纸上谈兵”。它可以先读状态判断是“根本没识别到”还是“识别到了但没输出”然后决定是提示你物理插拔还是自己去切换模式、重启驱动。2.2 诊断型 Agent 的四大能力边界真正动手之前你得给 Agent 划好边界否则它能把自己和你的电脑都折腾够呛。我按重要性排了四件事。第一工具集要抽象得“集中”。不要把底层命令直接全量暴露给模型而是封装成get_displays()、switch_mode(extend)这样的语义化函数。模型不需要知道 PowerShell 参数怎么写它只需要知道“我想扩展屏幕”。这既降低了模型的出错率也方便你做权限控制。第二操作顺序要“先读后写”。任何写操作切模式、重启驱动都必须建立在读操作的基础上。Agent 先收集证据再下判断没有证据就直接操作很容易越修越坏。第三权限要收敛。Agent 能执行的命令应该是白名单里的少数几个而且重启驱动这类高风险动作我会在代码层面要求二次确认或者干脆让它输出“需要你手动执行 X”而不是自己偷偷调管理员命令。第四输出要可解释。Agent 不能只甩给你一句“已经修好了”它必须输出完整的推理链检查了什么、发现了什么、做了什么、结果如何。这既方便你复核也方便你事后复盘哪里出了问题。这几条边界与其说是技术约束不如说是工程习惯。你不需要一次全做完但至少在项目一开始就要把“不能让 Agent 乱动系统”这个底线立住。3. 从零搭一个能修外接屏的 Agent工具层和主循环3.1 工具层设计先让排查动作变成可调用函数先声明一下环境我的主力机是 Windows 11外接屏通过 HDMI 和 DP 混合连接所以工具层用 Python 调 PowerShell 实现。如果你是 macOS 或者 Linux 用户思路完全一样只需要替换底层命令。第一个工具是列出当前系统识别的所有显示器。Windows 下最省事的是用 WMI 查询 PnP 设备拿到显示器实例、状态和 EDID 信息import subprocess import json def get_displays(): ps Get-CimInstance -Namespace root/wmi -ClassName WmiMonitorID | Select-Object InstanceName, Active, {NManufacturer;E{($_.ManufacturerName -join )}}, {NProduct;E{($_.UserFriendlyName -join )}}, {NSerial;E{($_.SerialNumberID -join )}} | ConvertTo-Json -Depth 3 res subprocess.run( [powershell, -NoProfile, -Command, ps], capture_outputTrue, textTrue, timeout15 ) if res.returncode ! 0: return {error: res.stderr.strip()} return json.loads(res.stdout or [])这个函数的返回值是 JSON 数组每个元素对应一台“活跃”或“已连接”的显示器。Agent 拿到它就能回答一个关键问题“系统到底有没有看到外接屏”。如果这里只有内置屏那大概率是物理链路或者输入源的问题如果外接屏出现在列表里但写着 ActiveFalse那问题可能在输出模式或驱动侧。第二个工具是查询显卡状态。重点是设备状态码Code 43 或 Code 31 基本就是驱动崩了def get_gpu_status(): ps Get-PnpDevice -Class Display | Select-Object FriendlyName, Status, ProblemCode | ConvertTo-Json -Depth 2 res subprocess.run( [powershell, -NoProfile, -Command, ps], capture_outputTrue, textTrue, timeout15 ) if res.returncode ! 0: return {error: res.stderr.strip()} return json.loads(res.stdout or [])第三个工具是切换显示模式。Windows 自带的DisplaySwitch.exe就够用参数分别是/internal、/external、/extend、/clone。封装时注意执行这个命令后屏幕可能短暂闪烁这是正常的def switch_mode(mode: str): allowed {internal, external, extend, clone} if mode not in allowed: return {error: finvalid mode: {mode}, allowed: {allowed}} res subprocess.run( [DisplaySwitch.exe, f/{mode}], capture_outputTrue, textTrue, timeout10 ) return {mode: mode, returncode: res.returncode}重启驱动的工具稍微特殊因为常规 PowerShell 命令需要管理员权限。我在代码里会先尝试Restart-PnpDevice如果抛异常就返回“需要手动操作”而不是强行提权def restart_gpu_device(instance_id: str): try: ps fRestart-PnpDevice -InstanceId {instance_id} -Confirm:$false res subprocess.run( [powershell, -NoProfile, -Command, ps], capture_outputTrue, textTrue, timeout30 ) if res.returncode 0: return {success: True} return {success: False, error: res.stderr.strip()} except Exception as e: return {success: False, error: str(e), hint: 需要管理员权限请手动重启显卡}3.2 Agent 主循环结构化输出与工具调用工具层准备好之后真正的 Agent 主循环其实不复杂。核心是把用户的问题、系统提示词、可用工具的描述一起丢给大模型让模型以结构化格式返回“我要调用哪个工具、参数是什么”然后代码去执行工具把结果回填给模型如此循环直到模型决定给出最终结论。一个极简循环可以写成这样import json def run_agent(question: str, tools: dict, max_steps8): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question}, ] for _ in range(max_steps): resp llm_chat(messages, toolstools_schema()) # 你的 LLM 调用函数 if resp.get(finish_reason) stop: return resp[message][content] # 解析模型产出的工具调用 tool_call resp[message][tool_calls][0] fn_name tool_call[function][name] fn_args json.loads(tool_call[function][arguments]) # 执行真实工具 result tools[fn_name](**fn_args) # 把观察结果回填到对话上下文 messages.append(resp[message]) messages.append({ role: tool, content: json.dumps(result, ensure_asciiFalse), tool_call_id: tool_call[id], }) return 超过最大步骤数请人工介入注意这里的llm_chat是抽象函数实际接入 OpenAI、通义、DeepSeek 或者本地 Qwen 都行关键是你的 LLM 必须支持函数调用 / tool calling。现在主流的Agent 框架大都内置了这个循环但你如果只是做一个小工具手写这个循环完全足够还能帮你彻底搞懂框架背后的原理。SYSTEM_PROMPT 我会写得非常细把排查顺序、边界、安全规则都写进去下面这段是我在项目里用的核心提示词你可以直接抄你是一个电脑外接显示器故障排查助手。你必须遵循以下规则 1. 先用 get_displays 和 get_gpu_status 收集信息禁止凭空猜测。 2. 如果 get_displays 里看不到外接屏优先怀疑物理连接或输入源 输出建议让用户重新插拔线材然后重新调用 get_displays 验证。 3. 如果能看到外接屏但 Active 为 false可以尝试 switch_mode(extend) 或 switch_mode(external)执行后再次调用 get_displays 验证。 4. 如果 get_gpu_status 返回 ProblemCode 不为 0优先建议重启显卡驱动 但必须告知用户此操作会导致屏幕短暂黑屏。 5. 禁止执行除 get_displays、get_gpu_status、switch_mode、restart_gpu_device 以外的任何系统命令。 6. 每次操作后必须验证结果并输出结论和完整操作记录。这套提示词看起来很朴素但它最大程度规避了我在第四部分要讲的很多坑。3.3 实测三个典型故障场景的完整推演工具和循环都齐了我给你演示一下实际跑起来是什么样子。我挑了三个最常见的场景。场景 AHDMI 线松了。Agent 第一步调用get_displays()返回结果里只有内置屏外接屏完全不在列表里。按照提示词里的规则它不会去瞎切换模式而是直接输出未检测到外接显示器请检查 HDMI 线是否插紧、显示器输入源是否为 HDMI。然后它调用get_displays()再次确认如果列表里出现外接屏就会补一句“已检测到显示器问题解决”。这个场景里 Agent 最大的价值是“克制”。搜索引擎给你的可能是一大堆驱动重装教程但 Agent 基于当前状态直接把范围缩小到物理链路省掉你至少半小时的折腾。场景 B输出模式残留在“仅第二屏幕”。这时候get_displays()能看到外接屏但内置屏状态和输出布局不对劲或者 Agent 结合用户描述“笔记本内置屏也不亮”判断模式异常。它调用switch_mode(extend)屏幕闪一下再调用get_displays()和一次屏幕状态确认输出已将显示模式切换为扩展模式内外屏均正常输出。我实际跑的时候这个场景最让人舒服的是——你完全不用记快捷键。以前遇到这种情况我可能要找另一块屏幕或者盲按WinP摸半天现在 Agent 自己就把模式切回去了。场景 C显卡驱动偶发崩溃输出异常。get_gpu_status()返回某个显卡设备 ProblemCode 为 43。Agent 判断是驱动故障它不会直接调用重启命令而是先告诉你“检测到显卡驱动异常建议重启显示设备这会导致屏幕黑屏几秒是否继续”这一步是我在提示词里埋的确认机制。你输入“继续”它再调用restart_gpu_device()最后拉一次get_gpu_status()确认问题代码归零输出修复成功。这三个场景实测下来成功率最高的其实是 A 和 B因为它们的判断依据非常明确。C 的成功率会受驱动本身状态影响但至少 Agent 能做到“有证据地猜、有步骤地试、有结果地验证”而不是无头苍蝇。4. 踩坑实录Agent 修电脑时最容易翻车的地方4.1 坑一Agent 把“上网搜”当作“排查”这是我第一次跑 Agent 时遇到的最典型问题。模型拿到“无信号”三个字第一反应不是调用get_displays()而是试图“联网搜索一下无信号怎么解决”——哪怕我根本没有给它搜索工具它也会在回复里输出一段“常见原因包括……”的通用废话。根子在于大模型的训练数据里“问题 - 原因 - 解决”的关联太强了它习惯于直接生成答案而不是通过工具去核实现状。我的解决办法就是强行把流程前置在 SYSTEM_PROMPT 第一行就写死“禁止在执行工具前输出任何排查结论”同时在代码层面对“没有工具调用记录的回复”一律判定为无效回答要求模型重新思考。这个约束加上之后废话率大幅下降。4.2 坑二subprocess 的 PATH 和权限黑洞有几次 Agent 明明逻辑正确却调用失败排了半天发现是subprocess.run([powershell, ...])在当前环境找不到 powershell。最典型的是我用系统服务方式启动 Agent 时PATH 环境变量被精简过很多命令根本不在可用路径里。这是非交互环境下跑 subprocess 的经典问题。我最后的处理是在工具函数里不依赖 PATH而是用绝对路径拼接import os, sys def powershell_cmd(script: str): pwsh rC:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe if not os.path.exists(pwsh): return {error: PowerShell not found} return subprocess.run([pwsh, -NoProfile, -Command, script], ...)同理DisplaySwitch.exe 也用了绝对路径。另外重启显卡驱动这个操作经常因为权限不足直接失败Windows 普通权限跑Restart-PnpDevice基本会报 access denied。我的处理是让 Agent 检测到失败后自动降级为“输出手动操作指引”把这个动作交给用户来完成而不是悄悄用提权命令——毕竟你也不希望一个 Agent 在没和你商量的情况下就自作主张重启显卡。4.3 坑三硬件限制不会消失Agent 需要“人工协助”协议Agent 再聪明也不可能亲自帮你把 HDMI 线重新插一遍更不可能去按显示器 OSD 菜单切换输入源。所以项目里必须有一套“人工协助协议”当 Agent 判断问题出在物理层时它就输出明确的操作指令然后等待用户回复“好了”再重新读取状态确认。这个协议的实现很简单就是在提示词里加一条“当你怀疑物理连接时输出请用户执行的操作并等待用户确认后再验证。”但它的意义很大——它把 Agent 从“全能维修工”的角色拉回到“诊断助手”避免 Agent 在一个它无法触碰的问题上反复死循环。我有一次测试时没加这条Agent 连续三次调用get_displays()检查同一个未插紧的 HDMI 线还输出“建议重试”完全没有意义。4.4 快速判断表症状、Agent 怀疑、Agent 动作最后整理一张我项目里常用的判断表你可以把它当成 Agent 提示词的补充知识也可以当成自己手动排障时的速查卡症状Agent 通过工具观察到什么Agent 的动作预期结果无信号内置屏正常外接屏不在 get_displays 列表提示检查线材/输入源等待确认后复查重插后列表出现外接屏无信号内置屏也黑外接屏存在但 Actviefalse切换 switch_mode(extend) 后复查恢复正常显示间歇性黑屏/花屏get_gpu_status 返回 ProblemCode43提示重启显卡驱动用户确认后执行问题代码归零输出稳定休眠唤醒后无信号显示器处于 Activetrue 但无输出先 switch_mode(internal) 再 switch_mode(extend) 强制重新握手屏幕恢复转接头连接无信号列表中外接屏信息异常/EDID 为空提示更换直连或外接供电转接头信息可正常读取这张表不是万能药但能覆盖我真实遇到过九成以上的“无信号”情况。Agent 的价值恰恰在这张表之上它能在每一行判断之前先用真实数据告诉你“你属于哪一行”。5. 最后想说的这个项目做下来我最大的体会不是 Agent 有多聪明而是它能逼着我把“排查经验”翻译成“可执行的工具和规则”。以前我修显示器靠的是脑子里那点模糊记忆现在我把同样的知识沉淀成了一组函数和一段提示词下次遇到同类问题Agent 可以五秒钟之内完成“读状态、做判断、给结论”的闭环。哪怕它判断错了输出的操作记录也能让我一眼看出问题出在哪一步这比我在搜索链接里反复横跳高效太多。如果你也想在自己机器上跑这套东西我的建议是从小处动手先只做get_displays()和switch_mode()两个工具让 Agent 解决 80% 的显示模式问题跑顺了再加驱动重启和电源管理。工具越少Agent 越不容易出错你也越容易看懂它在干什么。最后提醒一句任何让 Agent 执行系统级操作之前务必留一道人工确认的闸门。相信模型一次不难难的是让每个误操作都有后悔药可吃。
阅读完成 · 觉得有帮助？
