大模型驱动的对话式设备诊断：从AI Agent到工程落地

最近关于安卓硬件与 AI 结合的消息不少其中谷歌为 Pixel 11 系列测试 Gemini 驱动“设备帮助”工具这件事挺值得从技术实现角度聊一聊。它表面上是一个“手机里的智能客服”但背后的对话式故障排查机制、端侧与云端模型的分工、工具调用与权限控制对做 AI 应用、智能助手、运维诊断系统的开发者都有参考价值。本文不讨论爆料本身的真伪而是结合这类“对话式设备诊断”产品的通用技术形态拆解它的核心能力、架构思路与实际工程实现。如果你正在做智能客服、运维排查助手或者想在应用里接入大模型做“自然语言驱动排障”这篇文章可以给你一个比较完整的落地方案参考。1. 设备帮助工具是什么从“查手册”到“对话式排障”1.1 传统手机故障排查的痛点回顾一下我们平时用手机遇到问题时的处理路径手机突然发热、耗电变快大部分人先重启。重启没用开始到设置里翻电池统计、应用耗电排行。找不到原因只能去搜索引擎或社区搜关键词。更复杂的情况需要进入开发者选项抓取日志或者双清、刷机。这个过程存在几个明显问题信息分散系统设置、厂商帮助文档、社区教程、客服话术分布在多个渠道用户很难快速找到匹配自己机型的准确方案。诊断链路长用户需要自己理解“耗电异常”“发热”“卡顿”这些现象背后的可能原因再手动进入对应设置页排查专业性要求高。工具门槛高真正有用的诊断数据如电池健康度、后台唤醒次数、系统崩溃日志藏在开发者选项或隐藏菜单里普通用户不敢动也不会看。传统在线客服的体验则是先回答一串固定的“您是否尝试过重启手机”然后让你去官网下载驱动或者约线下检测。整个过程是静态流程没法根据用户回复动态调整排查方向。1.2 Gemini 驱动的设备帮助如何改变体验谷歌测试的这类“设备帮助”工具核心变化是把上面这条静态路径变成一次多轮对话式诊断用户直接用自然语言描述问题“手机最近待机一晚掉电 30%而且背面发烫。”系统通过大模型理解意图识别是“异常耗电”类问题。助手引导用户做进一步确认同时在后端或端侧调用诊断接口读取电池统计、CPU 占用、后台应用唤醒记录。根据诊断数据给出针对性的处理建议比如限制特定应用后台活动、关闭异常唤醒、检查是否安装了可疑应用。如果问题复杂还可以引导用户配合采集日志并生成一条结构化摘要方便后续人工客服或维修人员接手。这个模式下的设备帮助不再是一个“帮助文档的搜索入口”而是一个能理解设备状态、能执行诊断动作、能把结果翻译成人话的 AI 排障助手。1.3 为什么这件事值得开发者关注抛开手机厂商的身份这类产品本身代表了一种通用技术范式大模型 系统级工具调用 领域知识库 垂直场景智能体。它和最近讨论很多的 Agent 概念完全吻合。你可以把“设备帮助”理解为一个运行在手机上的垂直 Agent感知层获取设备状态、日志、应用信息。推理层Gemini 负责理解问题、制定排查计划。行动层调用系统诊断接口、执行修复动作。表达层用自然语言输出结论和操作建议。这套架构完全可以迁移到其他领域例如企业 IT 运维助手、智能硬件客服、云平台故障诊断机器人。下面我们会按这个思路逐步拆解技术实现。2. 对话式设备排查的系统架构为了让后面的实战部分更清晰先把架构分层讲清楚。一个完整的对话式设备排查系统通常包含以下模块。模块职责关键技术点对话入口接收用户语音/文本描述语音识别、多轮对话管理意图理解判断问题类型和紧急程度大模型 Prompt、意图分类槽位提取抽取设备型号、系统版本、问题现象等关键信息结构化输出、函数调用诊断执行调用系统接口、读取设备数据系统 API 封装、工具注册表知识检索匹配官方文档、已知问题、解决方案RAG、向量检索结果生成生成排查建议或修复动作大模型摘要、操作指令生成人机协同复杂问题转接人工、生成工单工单系统、会话摘要用一张简化的流程图表示用户描述问题 ↓ 语音转文本 / 直接文本 ↓ 意图识别 槽位提取 ↓ ┌─────────────┐ │ 需要诊断数据吗 │ └─────────────┘ ↓ 是 ↓ 否 读取设备诊断接口 直接检索知识库 ↓ ↓ 结合诊断结果推理 生成处理建议 ↓ 生成回答 操作引导 ↓ 用户反馈是否解决 ↓ 未解决 采集日志 / 转人工这个流程看起来不复杂但实际工程化时要考虑很多细节比如多轮对话的上下文管理、诊断接口的权限控制、大模型输出不稳定的兜底策略等。接下来逐个拆解。3. 核心能力拆解从自然语言到系统动作3.1 意图识别与槽位提取对话式排查的第一步是把用户的自然语言转换成结构化指令。这一步适合交给大模型完成借助 Function Calling 能力输出结构化的 JSON。以“手机待机耗电快”为例模型需要输出{ intent: battery_drain, slots: { device_model: Pixel 11, system_version: Android 16, phenomenon: 待机掉电快, duration: one_night, additional_info: 手机背面发烫 }, confidence: 0.92, requires_diagnosis: true }这段 JSON 就是“意图 槽位”的结构化表达。系统拿到之后可以决定调用哪些诊断模块。3.2 工具调用让大模型“动手检查”只让大模型聊天是没有意义的真正有价值的部分是让模型能调用系统诊断工具。这在实现上可以抽象为一个工具注册表每个工具包含名称、描述、输入参数和输出格式。{ tools: [ { name: get_battery_stats, description: 获取电池健康度、剩余容量、最近24小时耗电排行, parameters: { time_range: string }, returns: battery_stats_json }, { name: get_cpu_usage, description: 获取CPU实时占用率和占用最高的进程列表, parameters: {}, returns: cpu_usage_json }, { name: get_running_apps, description: 获取当前正在运行的应用列表包含后台唤醒统计, parameters: { sort_by: string }, returns: running_apps_json }, { name: check_system_logs, description: 检查系统错误日志和崩溃日志, parameters: { keyword: string, time_range: string }, returns: log_list_json } ] }当大模型判断需要读取电池信息时它会生成一次工具调用请求。系统在本地执行并返回结果模型再基于结果进行下一轮推理。这种“模型决策 → 工具执行 → 结果回传 → 继续推理”的循环就是 Agent 最核心的运行机制。3.3 本地优先与云端协同手机上运行的 AI 排障助手和纯云端产品不同必须考虑离线可用性、隐私和延迟。合理的做法是分级处理一级完全本地规则。比如读取电池状态、应用列表、存储空间这些简单信息不经过大模型直接通过系统 API 获取。二级端侧小模型处理。意图分类、槽位提取这类轻量任务可以在端侧跑一个小模型速度快且保护隐私。三级云端大模型深度推理。遇到复杂归因、需要综合多份日志判断时再请求云端 Gemini配合 RAG 检索官方知识库。这种分级架构下大量简单问题不需要上传任何数据就能在本地解决隐私体验更好也减轻了云端压力。涉及云端时对用户隐私数据的处理就要格外谨慎遵循最小化原则只上传与本次排查相关的必要数据。4. 实战设计一个简化版“设备帮助”系统下面我们抛开手机厂商的具体实现用通用开发思路设计一个简化版的对话式设备排查系统。这个实战示例可以用在电脑、手机应用甚至 IoT 设备上。4.1 系统模块划分整个系统分为三层数据层负责采集设备信息包括电池、CPU、网络、应用列表、日志。决策层调用大模型进行意图识别、诊断推理、方案生成。交互层管理多轮对话上下文输出结构化回答。考虑到不同平台的系统 API 差异很大这里我们把“数据采集”和“模型决策”解耦提供一个清晰的接口层。实际项目中你只需要把采集端替换成目标平台的 SDK 即可。4.2 设备信息采集层先定义诊断数据采集接口。下面是一个 Python 风格的抽象实现重点是接口设计思路具体系统调用需要根据实际平台调整。# 文件路径device_diagnosis/collector.py from abc import ABC, abstractmethod from dataclasses import dataclass, asdict from typing import Dict, Any dataclass class DiagnosisData: device_model: str system_version: str battery_level: int battery_temperature: float cpu_usage: float memory_usage: float top_apps: list error_logs: list class DeviceDataCollector(ABC): 设备数据采集器抽象接口 abstractmethod def collect_basic_info(self) - Dict[str, Any]: 采集设备基本信息和系统版本 pass abstractmethod def collect_battery_info(self) - Dict[str, Any]: 采集电池状态、温度、耗电排行 pass abstractmethod def collect_performance_info(self) - Dict[str, Any]: 采集 CPU、内存、磁盘使用情况 pass abstractmethod def collect_logs(self, keyword: str ) - list: 采集系统日志和崩溃记录 pass class AndroidCollector(DeviceDataCollector): Android 平台采集实现示意 def collect_basic_info(self) - Dict[str, Any]: # 实际项目中这里调用 Android SDK 的 Build、Settings 等接口 return { device_model: Pixel 11, system_version: Android 16, build_number: BP11.240111.001 } def collect_battery_info(self) - Dict[str, Any]: # 实际项目中通过 BatteryManager 获取电池状态 return { battery_level: 68, battery_status: DISCHARGING, battery_temperature: 38.5, health: GOOD, screen_on_time: 6h 20m, app_drain_ranking: [ {app: com.example.video, usage: 32.0}, {app: com.example.chat, usage: 18.5}, {app: com.android.systemui, usage: 9.2} ] } def collect_performance_info(self) - Dict[str, Any]: # 实际项目中通过 Debug.MemoryInfo、CpuUsage 等获取 return { cpu_usage: 23.5, memory_usage: 61.0, storage_usage: 72.0, thermal_state: WARM } def collect_logs(self, keyword: str ) - list: # 实际项目中通过 Logcat 读取系统日志 return [ { timestamp: 2026-01-10 22:31:45, level: WARN, tag: PowerManagerService, message: WakeLock acquired for 300000ms: com.example.video }, { timestamp: 2026-01-10 22:45:12, level: ERROR, tag: ActivityManager, message: ANR in com.example.chat (background) } ] def collect_all(self) - DiagnosisData: 汇总所有诊断数据 basic self.collect_basic_info() battery self.collect_battery_info() performance self.collect_performance_info() logs self.collect_logs() return DiagnosisData( device_modelbasic[device_model], system_versionbasic[system_version], battery_levelbattery[battery_level], battery_temperaturebattery[battery_temperature], cpu_usageperformance[cpu_usage], memory_usageperformance[memory_usage], top_apps[item[app] for item in battery[app_drain_ranking]], error_logslogs )4.3 意图识别与诊断决策模块采集到设备数据后下一步是把用户问题映射到对应的排查策略。这里采用“先规则路由再模型推理”的双层策略兼顾速度与灵活性。# 文件路径device_diagnosis/intent_router.py import re from typing import Dict, Any class IntentRouter: 意图识别路由器先用规则快速匹配再考虑模型兜底 BATTERY_KEYWORDS [耗电, 掉电, 待机, 续航, 电池, 发热, 发烫] PERFORMANCE_KEYWORDS [卡顿, 慢, 卡死, 无响应, cpu, 内存] NETWORK_KEYWORDS [断网, 连不上, wifi, 网络, 信号] APP_KEYWORDS [闪退, 打不开, 崩溃, 应用] def rule_based_route(self, user_input: str) - str: 基于规则快速路由到对应排查意图 text user_input.lower() if any(k in text for k in self.BATTERY_KEYWORDS): return battery_drain if any(k in text for k in self.PERFORMANCE_KEYWORDS): return performance_issue if any(k in text for k in self.NETWORK_KEYWORDS): return network_issue if any(k in text for k in self.APP_KEYWORDS): return app_crash return general_query def route(self, user_input: str) - Dict[str, Any]: intent self.rule_based_route(user_input) return { intent: intent, strategy: self._get_strategy(intent) } def _get_strategy(self, intent: str) - str: 根据意图返回排查策略 strategies { battery_drain: collect_battery_stats_check_wakelocks, performance_issue: collect_cpu_memory_check_running_apps, network_issue: check_wifi_signal_switch_data, app_crash: check_recent_crash_logs_clear_cache, general_query: retrieve_knowledge_base } return strategies[intent]这种规则路由的好处是快、可控、不依赖模型结果。但它覆盖不了复杂的表达方式所以在实际产品里通常会让大模型对规则路由的结果做二次确认或者在规则无法匹配时由大模型兜底做意图分类。4.4 基于大模型的对话决策引擎下面是大模型驱动的核心决策模块。它以“用户问题 设备诊断数据 可用工具列表”作为上下文让模型输出下一步动作。# 文件路径device_diagnosis/agent.py import json from typing import Dict, Any, Optional class GeminiDiagnosisAgent: 基于大模型的诊断推理引擎示意实现 实际项目中需要接入具体大模型 API并按官方文档调整调用方式 def __init__(self, api_key: str, model_name: str gemini-2.0-flash): self.api_key api_key self.model_name model_name def build_prompt(self, user_input: str, device_data: Dict[str, Any], conversation_history: list) - str: 构造诊断 Prompt system_prompt 你是一名专业的移动设备诊断专家。你的任务是帮助用户排查手机故障。 请基于用户描述和设备诊断数据判断问题原因并给出可执行的排查步骤。 要求 1. 先分析最可能的原因不要直接下结论。 2. 给出的建议必须具体、可操作。 3. 如果需要更多信息明确告诉用户下一步需要确认什么。 4. 判断是否需要调用诊断工具如果需要使用指定的工具调用格式。 工具调用格式JSON {action: call_tool, tool_name: 工具名, parameters: {参数名: 参数值}} 可用工具 - get_battery_stats: 获取电池详细耗电数据 - get_cpu_usage: 获取CPU占用率和进程列表 - get_running_apps: 获取运行中的应用及后台唤醒次数 - check_system_logs: 检查系统异常日志 user_prompt { user_input: user_input, device_data: device_data, conversation_history: conversation_history } return system_prompt \n\n json.dumps(user_prompt, ensure_asciiFalse, indent2) def run(self, user_input: str, device_data: DiagnosisData, conversation_history: list) - Dict[str, Any]: 执行一次诊断决策 prompt self.build_prompt(user_input, device_data.__dict__, conversation_history) # 实际项目中这里调用大模型 API拿到模型返回的文本或结构化结果 # 此处给出一个模拟返回便于理解整体流程 mock_response { analysis: 检测到后台视频应用长时间持有唤醒锁是导致待机耗电快的主要原因。, next_action: { action: call_tool, tool_name: check_system_logs, parameters: {keyword: WakeLock, time_range: 24h} }, suggestion: 建议限制 com.example.video 的后台活动我们会引导你完成设置。 } return self._parse_model_response(mock_response) def _parse_model_response(self, response: Dict[str, Any]) - Dict[str, Any]: 解析模型返回结果补充兜底逻辑 if response.get(next_action, {}).get(action) call_tool: # 在实际项目中这里需要校验工具名称是否在白名单中 tool_name response[next_action][tool_name] allowed_tools [get_battery_stats, get_cpu_usage, get_running_apps, check_system_logs] if tool_name not in allowed_tools: response[next_action] { action: respond, message: 抱歉我无法执行这个操作请尝试描述更具体的问题现象。 } return response这个模块体现了几个关键设计点Prompt 中明确规定了输出格式方便结构化解码。工具调用结果在上一次模型输出中并没有直接混入用户输入而是作为设备数据的一部分提前注入。下线了工具白名单校验防止模型生成非预期工具调用。这类安全校验是生产环境的必需项。4.5 多轮对话管理设备排查很少一轮对话就能结束。用户可能会补充信息也可能会在执行操作后反馈结果。因此需要一套对话状态管理机制。# 文件路径device_diagnosis/session.py from dataclasses import dataclass, field from typing import Dict, Any, Optional import uuid dataclass class DiagnosisSession: 诊断会话实体 session_id: str field(default_factorylambda: uuid.uuid4().hex) user_id: Optional[str] None device_model: Optional[str] None intent: Optional[str] None collected_data: Dict[str, Any] field(default_factorydict) conversation_history: list field(default_factorylist) step: int 0 status: str ongoing # ongoing | resolved | escalated | canceled class SessionManager: 会话管理器负责维护多轮对话上下文 def __init__(self): self._sessions: Dict[str, DiagnosisSession] {} def create_session(self, user_id: Optional[str] None) - DiagnosisSession: session DiagnosisSession(user_iduser_id) self._sessions[session.session_id] session return session def get_session(self, session_id: str) - Optional[DiagnosisSession]: return self._sessions.get(session_id) def append_history(self, session_id: str, role: str, content: str): 往会话中追加一条对话记录 session self.get_session(session_id) if session: session.conversation_history.append({ role: role, content: content, step: session.step }) session.step 1 def update_intent(self, session_id: str, intent: str): session self.get_session(session_id) if session: session.intent intent def update_collected_data(self, session_id: str, data: Dict[str, Any]): session self.get_session(session_id) if session: session.collected_data.update(data) def resolve_session(self, session_id: str): session self.get_session(session_id) if session: session.status resolved def escalate_session(self, session_id: str): 升级为人工处理保留完整对话上下文 session self.get_session(session_id) if session: session.status escalated多轮对话管理的关键是把“用户说了什么”“诊断出什么”“系统做了什么”“当前处于哪个阶段”这几类信息统一记录在同一会话结构里。这样即使对话中断也能断点续聊转人工时也能把完整上下文交接过去。4.6 运行一个完整排查流程把上述模块组合起来跑一次完整的模拟对话。# 文件路径main.py from device_diagnosis.collector import AndroidCollector from device_diagnosis.intent_router import IntentRouter from device_diagnosis.agent import GeminiDiagnosisAgent from device_diagnosis.session import SessionManager # 初始化各模块 collector AndroidCollector() router IntentRouter() agent GeminiDiagnosisAgent(api_keyYOUR_API_KEY) session_manager SessionManager() # 1. 用户开启会话 user_input 我的手机待机一晚上掉电30%而且有点发烫不知道是什么原因 session session_manager.create_session(user_iduser_001) session_manager.append_history(session.session_id, user, user_input) # 2. 意图识别 intent_result router.route(user_input) session_manager.update_intent(session.session_id, intent_result[intent]) print(f[意图识别] {intent_result}) # 3. 采集设备数据 device_data collector.collect_all() session_manager.update_collected_data( session.session_id, { battery_level: device_data.battery_level, battery_temperature: device_data.battery_temperature, top_apps: device_data.top_apps } ) print(f[设备数据] 电量{device_data.battery_level}%, f温度{device_data.battery_temperature}°C, f耗电Top应用{device_data.top_apps}) # 4. 模型推理决策 agent_result agent.run(user_input, device_data, session.conversation_history) session_manager.append_history(session.session_id, assistant, agent_result[suggestion]) print(f[模型分析] {agent_result[analysis]}) print(f[下一步动作] {agent_result[next_action]}) print(f[建议] {agent_result[suggestion]}) # 5. 模拟用户完成操作后反馈 user_feedback 我已经限制那个应用的后台活动了今晚再看看效果 session_manager.append_history(session.session_id, user, user_feedback) # 6. 判断是否结单 session_manager.resolve_session(session.session_id) print(f[会话状态] {session_manager.get_session(session.session_id).status})预期输出逻辑[意图识别] {intent: battery_drain, strategy: collect_battery_stats_check_wakelocks} [设备数据] 电量68%, 温度38.5°C, 耗电Top应用[com.example.video, com.example.chat, com.android.systemui] [模型分析] 检测到后台视频应用长时间持有唤醒锁是导致待机耗电快的主要原因。 [下一步动作] {action: call_tool, tool_name: check_system_logs, parameters: {keyword: WakeLock, time_range: 24h}} [建议] 建议限制 com.example.video 的后台活动我们会引导你完成设置。 [会话状态] resolved到这里一个简化版“对话式设备排查系统”就跑通了。可以看到核心不是模型本身而是数据采集、意图路由、工具调用、会话管理这些工程模块的协作。5. 常见问题与排查思路在实际开发和部署这类 AI 排障系统时会遇到不少工程问题。下面整理几类高频场景。问题现象常见原因解决思路模型把耗电问题误判为网络问题规则路由关键词覆盖不全模型上下文缺少设备数据结合规则 模型双重判定模型推理时注入关键设备指标多轮对话中用户改了话题系统还按原意图处理会话状态没有及时重置或更新每轮对话都做一次意图更新当置信度足够高时切换意图诊断工具返回大量日志模型处理超时日志未做截断和摘要直接整包塞给模型先做日志预处理按级别/关键字过滤必要时先做本地摘要模型建议用户执行高风险操作例如清除全部数据缺少安全边界约束在 Prompt 中禁止高危操作同时建立动作白名单和人工确认机制离线场景下核心功能不可用完全依赖云端模型设计分级处理简单规则本地兜底复杂场景才请求云端用户情绪激烈需要转人工缺少情绪识别和升级机制在决策层加入情绪判断识别到强烈不满时直接转人工同一用户频繁问相同问题缺少会话级缓存和结果记录建立“问题指纹”命中历史问题直接复用方案5.1 模型输出 JSON 不稳定怎么办大模型输出 JSON 时偶尔会出现字段缺失、格式破损的情况。工程上通常采用三层兜底正则修复尝试修复明显的引号缺失、花括号不匹配。重试机制设置最大重试次数让模型基于上次错误重新生成。规则兜底当模型连续输出无效回退到纯规则推荐的静态排查流程。import json import re def safe_parse_model_json(text: str) - dict: 安全解析模型输出的 JSON带多层兜底 # 第一次尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 第二次尝试提取第一个 { } 包围的内容 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass # 最终兜底返回默认结构 return { action: respond, message: 抱歉我正在重新整理排查建议请稍后再试。 }5.2 诊断数据的隐私合规在设备上采集诊断数据隐私合规是绕不开的问题。无论做手机厂商还是第三方产品都建议遵守以下原则最小化原则只采集当前问题最相关的数据不批量拉取全部用户信息。明确告知在采集前明确说明采集了什么数据、用于什么目的。本地优先优先在端侧完成数据处理原始日志不出设备。脱敏处理上报云端前对账号信息、通讯录、消息内容等敏感字段做脱敏。保留期限设定诊断数据的保留时限过期自动清理。这也是为什么很多设备 AI 助手采用“端侧小模型 云端大模型”的混合架构既保证复杂问题处理能力又尽量降低隐私暴露面。6. 工程设计层面的最佳实践6.1 用“工具注册表”替代硬编码函数调用在设计智能体时建议把模型可调用的能力抽象成“工具注册表”而不是让代码里到处写 if-else 判断模型要调用哪个函数。好处有几点新增诊断能力时只需要往注册表里增加一个工具定义不需要改动对话逻辑。可以对工具做统一的权限控制、速率限制、审计日志。模型可以动态感知工具列表而不是依赖代码写死的行为。# 文件路径device_diagnosis/tool_registry.py from typing import Callable, Dict, Any class ToolRegistry: 工具注册表 def __init__(self): self._tools: Dict[str, Dict[str, Any]] {} def register_tool(self, name: str, description: str, handler: Callable, required_permission: str normal): 注册一个工具 self._tools[name] { name: name, description: description, handler: handler, required_permission: required_permission } def get_tool(self, name: str) - Dict[str, Any]: return self._tools.get(name) def list_tools(self) - list: return [ {name: t[name], description: t[description]} for t in self._tools.values() ] def execute(self, name: str, parameters: Dict[str, Any], user_permission: str normal) - Any: 执行工具前检查权限 tool self.get_tool(name) if not tool: raise ValueError(f未知工具: {name}) if user_permission ! admin and tool[required_permission] admin: raise PermissionError(f工具 {name} 需要管理员权限) handler tool[handler] return handler(**parameters)6.2 Prompt 设计给模型“边界感”设备诊断场景的 Prompt 设计建议把以下边界写清楚角色边界模型是设备诊断助手不是心理医生也不是通用百科。动作边界能操作什么、不能操作什么。信息边界哪些情况必须询问用户、哪些情况可以直接读设备数据。升级边界什么时候必须转人工。示例 Prompt你是设备诊断助手。你的职责是帮助用户排查手机故障。 你可以 - 读取设备电量、CPU、应用列表、系统日志等信息。 - 根据诊断数据给出排查建议。 - 引导用户完成系统设置操作。 你不可以 - 执行恢复出厂设置、清除应用数据等高风险操作。 - 在没有用户确认的情况下修改任何系统设置。 - 回答与设备故障排查无关的问题。 当出现以下情况时立即转人工 - 用户情绪激动或要求投诉。 - 故障可能涉及硬件损坏。 - 用户连续两次反馈建议无效。 回答要求 - 使用简体中文。 - 每次只给一个核心结论和下一步建议。 - 如果信息不足明确说明需要补充什么。这种“边界感”式 Prompt 能显著降低模型乱说话的概率也方便后续做安全审计。6.3 人机协同与工单交接对话式排障系统免不了出现模型解决不了的情况。这时候最重要的是平滑转人工而不是让用户在一片迷茫中重新描述一遍问题。工程上推荐的做法是在会话管理器中记录完整的诊断链路包括用户描述、设备数据快照、模型分析结论、已尝试的修复动作。转人工时自动附上这份摘要人工客服一眼就能接上。# 文件路径device_diagnosis/summary.py def build_handoff_summary(session) - dict: 生成人工交接摘要 return { session_id: session.session_id, user_id: session.user_id, device_model: session.device_model, intent: session.intent, status: session.status, conversation_history: session.conversation_history, collected_data: session.collected_data, tried_actions: session.collected_data.get(tried_actions, []), suggested_next_steps: session.collected_data.get(suggested_next_steps, []) }6.4 监控与效果评估AI 排障系统上线后需要持续监控几个核心指标指标说明参考正常范围意图识别准确率用户意图判断正确的比例越高越好建议 90%首轮解决率第一轮回答能否直接解决问题跟问题复杂度相关多轮解决率经过多轮对话后问题是否解决目标 70%转人工率需要人工介入的比例越低越好平均会话轮数每个问题平均对话次数通常 3~8 轮工具调用成功率诊断工具执行成功率 95%用户满意度对话结束后用户评分持续监测建议在每轮对话结束时让用户点选“解决 / 未解决 / 需要人工”这是最直接的反馈信号。在转人工前也要让用户确认模型方案是否有效方便后续分析模型薄弱点。7. 从设备帮助到通用 AI 排障智能体谷歌在 Pixel 上测试这种 Gemini 驱动的设备帮助工具放在整个行业背景里看其实是一个信号AI 服务正在从“回答问题”走向“诊断并解决问题”。这套范式并不局限于手机企业 IT 运维助手让员工用自然语言描述“连不上打印机”“电脑蓝屏”AI 读取设备状态并给出修复步骤。云平台故障诊断用户描述“数据库连接超时”AI 自动拉取监控指标、慢查询日志定位瓶颈。智能硬件客服用户说“扫地机器人老是卡住”AI 远程读取运行日志、传感器状态判断是异物卡住还是电机故障。车机智能助手用户说“车辆启动时有异响”AI 结合故障码读取、行驶数据分析原因。这些场景共用同一套核心架构自然语言交互 设备数据采集 模型推理决策 工具执行 会话管理。如果你这次把这套逻辑梳理清楚了将来不管做什么垂直行业的“AI 排障员”都能快速复用。从工程经验来看决定这类系统成败的关键往往不是大模型的推理能力而是数据采集的准确性、工具权限控制的安全性、以及多轮交互中状态管理的完整性。模型可以换、Prompt 可以调但这些工程底座烂了整个系统就用不起来。如果你接下来想深入我建议优先研究这几个方向本地方向研究 Gemini Nano 等端侧小模型的意图识别效果以及端侧 embedding 与向量检索。工具方向完善工具注册表的权限模型、审计日志、限流与熔断机制。上下文方向学习长上下文压缩、关键信息抽取、摘要结构化等技术控制成本与延迟。评测方向构建一个覆盖高频故障场景的评测集自动化评估每个版本的效果防止模型升级带来回归。整体来看AI 驱动的设备故障排查还处在早期但技术路径已经比较清晰。对开发者来说现在正是把思路落地成原型的好时机尤其是把自己熟悉的业务场景先跑通一遍会在下一波 AI 应用落地中积累很实在的经验。如果这篇文章对你有帮助可以收藏起来后续做智能诊断助手时直接当参考资料。