「从零到 AI 应用工程师」专栏 · 第 19 篇
阶段 3 · 故障诊断 Agent 开篇
RAG 解决的是：有依据地回答私有资料问题 。
但现场告警来了，理想流程往往是：
抽出故障码 → 查码表拿级别与含义 → 再问知识库要处置步骤 → 输出固定格式结论。
这不是单次 /rag/query 能优雅表达的。它更像一条工作流 ，中间要调用多个工具（Tool）。这就是 Agent 篇要做的事。
一、Agent 和「会聊天的模型」差在哪
| 纯对话 / 纯 RAG | Agent | |
|---|---|---|
| 能力 | 生成文本、基于片段回答 | 按目标选用并调用工具 |
| 状态 | 多轮可选 | 常有明确状态（码、分类、步骤） |
| 输出 | 自由文本为主 | 常要结构化（工单 JSON） |
| 失败 | 拒答/报错 | 重试、超时、降级、转人工 |
一句话：
Agent = 目标导向的编排 + 可调用的确定性工具 +（可选）大模型做决策/润色。
本专栏演示场景：设备故障诊断。工具先用手写调用，再挂进状态机；不神话「全自动智能体」。
二、你将搭的最小诊断链路
text
告警原文 / 故障码
→ ingest 抽码
→ classify 规则分类（单体/模组/绝缘...）
→ lookup 查本地故障码表
→ rag 调月2的 POST /rag/query
→ 返回统一 JSON（含 citations / request_id）注意边界：
- 知识库仍归 RAG 服务（冻结契约）；
- Agent 负责编排与诊断 API；
- 两者端口分离（例如 RAG
:8000，Agent:8100）。
三、Tool 是什么（先建立直觉）
Tool = 输入输出稳定的函数 ：查表、HTTP、算数、写库......
不是「再让模型编一段话」。
好的 Tool：
- 参数清晰（如
code: str）； - 返回固定字段（
found/meaning/level）； - 失败可表达（
error/ 超时），供上游分支。
坏的 Tool：
- 返回值今天一个样明天一个样；
- 把幻觉文本包装成「查询结果」。
四、阶段 3 十篇地图
| 篇 | 主题 |
|---|---|
| 19 | Agent 是什么（本篇） |
| 20 | 第一个 Tool：查故障码表 |
| 21 | LangGraph 状态机：ingest→classify→lookup |
| 22 | RAG 变成 Tool |
| 23 | POST /agent/diagnose 串联 |
| 24 | 结构化工单 JSON |
| 25 | 重试、超时、降级 |
| 26 | 全链路 trace |
| 27 | 未知故障升级人工 |
| 28 | 10 用例回归 |
五、带走这三条
- Agent 核心是编排与工具，不是更会聊天。
- RAG 是工具之一，不是被 Agent 取代。
- 先确定性工具 + 状态机，再考虑让模型选工具。
下一篇：实现 lookup_fault_code(E001)，用 JSON 表返回含义与级别。
这是专栏第 19 篇。两到三天一更，查表 Tool 见。