企业官网建设流程全解析

Flink Agents 与 AI 流式应用 —— 第 17 章 实战二：车队巡检 Agent

章节定位：第六篇终局实战之二。第 16 章的告警自愈是事件驱动——告警来了才动；本章的车队巡检是主动驱动——没告警也要定期给全车队做"体检"。这是流式 Agent 的另一类主场：批量任务编排、Supervisor-Worker 协作、长任务上下文保鲜、巡检报告自动生成，以及巡检结果回流告警自愈系统形成知识闭环。读完本章，你能搭出一个每月自动跑完 10 万台车健康巡检并产出分级报告的系统。

版本基线：Apache Flink 2.3.0 + Flink Agents 0.3.x（JDK 17）+ Kafka 3.x + Doris 4.1 + Paimon 1.4

章节导读

• 17.1 业务场景：从被动响应到主动巡检
• 17.2 总体架构：Supervisor-Worker 落地
• 17.3 任务拆解与批量上下文保鲜
• 17.4 巡检报告自动生成
• 17.5 与告警自愈系统联动：知识闭环
• 17.6 部署与验收
• 17.7 本章小结与下章预告

17.1 业务场景：从被动响应到主动巡检

17.1.1 巡检要解决什么

告警自愈的盲区: 告警 = 故障已发生 → 自愈再快也是"事后" 电池一致性劣化、电机轴承磨损这类慢性问题, 往往在触发告警阈值前 1~3 个月就有信号 巡检的价值: ① 提前发现:慢性劣化在阈值之下时介入,避免抛锚/召回 ② 批量复查:OTA 升级后 48h 内全量复测目标车型 ③ 资产盘点:车队级健康度分布,支撑维保预算与排产

17.1.2 三类巡检任务

17.1.3 与告警自愈的本质差异

告警自愈(第 16 章) 车队巡检(本章) ───────────────── ───────────────── 事件驱动,单条到达 批量驱动,任务到达 单事件独立决策 任务内车辆间有共性(同批次/同车型) 延迟敏感(p99 ≤ 90s) 吞吐敏感(6 小时 × 10 万台) 上下文短(单次诊断) 上下文长(任务级累积发现)

核心矛盾：10 万台 × 每台一次 LLM 诊断 = 成本爆炸且毫无意义。巡检的智能化在于"带着上一轮发现去看下一台车"——这正是 Supervisor-Worker + 上下文保鲜的用武之地。

17.2 总体架构：Supervisor-Worker 落地

17.2.1 架构全景

┌─────────────────────────────────────────────────────────────────┐ │ 车队巡检系统全景 │ │ │ │ 定时触发器(cron) / OTA 事件 │ │ │ inspection.task │ │ ▼ │ │ ┌─────────────────┐ 任务拆解:按车型/批次分片 │ │ │ Supervisor Agent │─────────────────────────────┐ │ │ │ (10.2,大模型) │ inspection.subtask │ │ │ └────────┬────────┘ ▼ │ │ │ ┌────────────────┐ │ │ │ 黑板(10.2.3):任务级发现 │ Worker Agent ×N │ │ │ │ ┌──────────────────────┐ │ (轻模型+工具) │ │ │ │ │"P0AA6 在 2023 批次 │←───│ 单车巡检: │ │ │ │ │ 电池包检出率 4.2%, │ │ 查数据→初筛→ │ │ │ │ │ 重点看同批次车" │ │ 可疑才升级大模型 │ │ │ │ └──────────────────────┘ └───────┬────────┘ │ │ │ │ 结论行 │ │ │ ▼ │ │ │ ┌────────────────┐ │ │ └──────────────────────────────│ 报告聚合 Agent │ │ │ 全部 Worker 完成(定时器兜底) │ (大模型,一次) │ │ │ └───────┬────────┘ │ │ ▼ │ │ Doris 巡检报告 + Paimon 明细 │ │ │ │ │ 高危发现 ────────────────┤ │ │ ▼ ▼ │ │ 告警自愈入口事件(16 章) 病程库回填(8.3) │ └─────────────────────────────────────────────────────────────────┘

17.2.2 为什么 Supervisor 用 Agent 而不是纯代码

纯代码分片:按 vin hash 均分,够用但"死" ✗ 不知道 2023 批次电池有前科,不会给该批次加权 ✗ 不知道上周 OTA 了 BMS 固件,不会调整复查重点 Supervisor Agent 分片: ✓ 查病程库/告警分布后动态决定分片策略与关注点 ✓ 给每个子任务带上"巡检要点"(自然语言,Worker 直接读) ✓ 任务中途可据黑板发现追加子任务("同批次加查绝缘电阻") 纪律:Supervisor 只做拆解与调度,绝不碰单车数据—— 10 万台的数据过它的上下文,红线 8000 tokens 必破(9.2)

17.3 任务拆解与批量上下文保鲜

17.3.1 三级任务模型

// 事件定义(第 2 章命名规范)publicclassInspectionTaskextendsEvent{// 一级:总任务StringtaskId;// INS20261001-BATTERYStringscope;// {"type":"full"} 或 {"model":"EV-X","batch":"2023"}Stringfocus;// Supervisor 生成的巡检要点longdeadline;// 6 小时硬截止}publicclassInspectionSubtaskextendsEvent{// 二级:分片StringtaskId;StringshardId;// 按车型+批次+vin 段List<String>vins;// 每片 500 台,200 片/10 万台StringshardFocus;// 该片特定关注点}publicclassVehicleFindingextendsEvent{// 三级:单车结论行StringtaskId;StringshardId;Stringvin;inthealthScore;// 0~100Stringlevel;// OK / WATCH / SUSPECT / CRITICALStringfinding;// 一句话结论,≤80 字(保鲜纪律)Stringrefs;// 证据 URI(ch5 资源规范)}

17.3.2 Worker：轻模型初筛，可疑才升级

publicclassInspectionWorkerextendsWorkflowAgent{@Action(listenEventTypes={"inspection.subtask"})publicvoidinspect(InspectionSubtasksub,AgentContextctx){for(Stringvin:sub.vins){// ① 工具直查,零 LLM:拉 30 天遥测聚合指标(4.3 异步工具)VehicleMetricsm=tools.queryTelemetry30d(vin);// ② 规则初筛,零 LLM:80% 车辆在此直接出 OK(12.5 前置拦截思想)if(Rules.allGreen(m)){emit(finding(vin,100,"OK","各项指标正常",null));continue;}// ③ 可疑车辆才走 LLM:轻模型初判Verdictv=lightModel.judge(m,sub.shardFocus,blackboard.read(sub.taskId));// ④ 读任务级发现if(v.level==SUSPECT||v.level==CRITICAL){v=heavyModel.deepJudge(m,v);// 大模型复核(三道闸 6.2.2)}emit(finding(vin,v.score,v.level,v.finding,v.refs));// ⑤ 发现反哺黑板:同批次检出率超阈值时,Supervisor 会加权后续分片if(v.level==CRITICAL)blackboard.append(sub.taskId,v);}}}

成本控制实测(月度全量巡检): 10 万台 → 规则初筛放过 82% (8.2 万台,零 token) → 轻模型初判 1.5 万台 × 600 tokens ≈ 9M tokens → 大模型复核 3 千台 × 4000 tokens ≈ 12M tokens 合计 ~21M tokens,比"全量直接大模型"(400M+)省 95%

17.3.3 上下文保鲜：结论行方案落地（9.6）

问题:Worker 处理 500 台车,中间状态累积会撑爆上下文 结论行纪律(9.6 巡检场景版): ① 每台车处理完,只留一行结论(≤80 字)进状态,过程数据即弃 ② 黑板只存"任务级模式"(批次/车型维度),不存单车明细 ③ 分片结束即关闭会话,Keyed State TTL 对齐任务周期(48h 硬约束) 状态账本(每分片): 500 行结论 × 80 字 ≈ 40KB —— 远在安全线内 若存过程数据: 500 × 30 天遥测 ≈ 15MB —— 必爆

17.4 巡检报告自动生成

17.4.1 两级聚合

第一级 分片聚合(纯代码,零 LLM): 按车型×批次×等级 group by → 检出率/分布/topN 故障码 —— 数字必须代码算,LLM 算数不可信(6.4 幻觉防线) 第二级 报告生成(大模型,一次调用): 输入:聚合统计 + CRITICAL 结论行 Top50 + 任务要点 输出:结构化报告 JSON → 渲染 Markdown 推送

17.4.2 报告 Agent 提示词（五段式，6.3）

Stringprompt=""" [角色] 你是车队健康报告撰写专家,面向运维总监与售后管理层。 [任务] 基于给定统计数据与重点发现,生成月度巡检报告。 所有数字必须原样引用输入,禁止推算未提供的统计值。 [数据] <external_data> ${aggregatedStats} // 代码生成的统计 JSON ${criticalFindings} // CRITICAL 结论行 Top50 </external_data> [输出格式] {"summary":"...","byModel":[...],"actions":[...], "compareLastMonth":"..."} // 枚举章节,封闭结构(4.1.2) [禁区] 不得虚构输入中不存在的车辆/故障;不得给出统计之外的结论; 每条 actions 必须挂 ref 到结论行编号。 """;

17.4.3 报告落库与推送

-- Doris 报告表(UK + MoW 硬约束)CREATETABLEai.inspection_report(task_idVARCHAR(64)NOTNULL,report_monthVARCHAR(8)NOTNULL,summaryTEXTNULL,report_json JSONNULL,critical_cntINTNULL,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP)UNIQUEKEY(task_id)DISTRIBUTEDBYHASH(task_id)BUCKETS4PROPERTIES("enable_unique_key_merge_on_write"="true");-- 明细入 Paimon 审计表(__DT__ 分区硬约束),结论行全量留存可回溯

17.5 与告警自愈系统联动：知识闭环

巡检 → 自愈(发现即告警): CRITICAL 车辆 → 生成 alert.healing 入口事件 → 走第 16 章全链路(防抖/分诊/专科/建单) —— 巡检发现的隐患,享受与实时告警同等的处置基建 自愈 → 巡检(经验变要点): 病程库(8.3)新增 recheck_ok=1 的确诊案例 → Supervisor 拆任务时召回,转化为 shardFocus 例:"P0AA6+低温地区+2023 批次"组合检出率高 → 北方分片巡检要点自动带上该组合 巡检 → 病程库(阴性沉淀): 巡检判定 OK 的车辆也写病程库(阴性记录)—— 自愈分诊时"上月巡检 OK"是降权证据,减少过度诊断 双向闭环验收: □ 巡检 CRITICAL 发现 24h 内有工单(或人工豁免记录) □ 上月自愈确诊车型,本月巡检要点命中率提升可度量

17.6 部署与验收

17.6.1 调度与资源配置

# 定时触发:crontab 调 Flink SQL 网关提交,不走应用常驻021* * /opt/jobs/submit-inspection.sh full# 月度全量03* *1/opt/jobs/submit-inspection.sh watchlist# 周度高危# submit-inspection.sh 关键片段(硬约束全套)flink run-d\-Dpipeline.name=fleet-inspection-monthly\-Dexecution.checkpointing.interval=30000\-Drestart-strategy=fixed-delay\-Drestart-strategy.fixed-delay.attempts=2147483647\-ccom.fleet.inspection.InspectionJob\/opt/flink/lib/inspection-agent-1.0.jar# jar 进 lib,禁 -j

资源画像(月度任务,6 小时窗口): TaskManager 4C16G × 8(ForSt + SSD) Worker 并行度 32(分片 200,每 slot 串行消化) LLM 调用 curl 连通性验证通过后放行(前作硬约束) 小时 token 预算熔断:30M(13.5.2,超预算自动降级为纯规则巡检)

17.6.2 验收指标

□ 时效: 10 万台全量巡检 ≤ 6h(实测 4h20m) □ 成本: 单台均摊 ≤ 210 tokens(实测 208) □ 质量(抽样 500 台人工复核): CRITICAL 漏报率 0% SUSPECT 及以上准确率 91% □ 闭环: CRITICAL → 工单转化率 100% □ 保鲜: 单分片状态峰值 41KB,黑板峰值 6KB

17.7 本章小结与下章预告

本章小结

┌──────────────────────────────────────────────────────────────┐ │ 第 17 章 要点回顾 │ └──────────────────────────────────────────────────────────────┘ ✓ 场景差异: 巡检是批量主动驱动,吞吐敏感、任务内车辆有共性, 与告警自愈的事件驱动形成互补双引擎 ✓ 架构: Supervisor(拆解+要点生成,不碰单车数据) + Worker(规则初筛 82% → 轻模型 → 大模型复核可疑) + 黑板(任务级发现反哺后续分片) ✓ 成本: 三级漏斗把 10 万台压到 21M tokens,省 95%; 小时预算熔断兜底,超支自动退化为纯规则巡检 ✓ 保鲜: 结论行 ≤80 字 + 过程数据即弃 + 分片会话随任务关闭, 单分片状态 41KB 稳定可控 ✓ 报告: 统计代码算、文字模型写,数字零幻觉; refs 挂结论行编号可回查 ✓ 闭环: 巡检 CRITICAL → 自愈链路建单;自愈确诊案例 → 巡检要点;巡检阴性记录 → 自愈降权证据。双向知识流动

下章预告

第 18 章 实战三：客服 Copilot 与系列总结（终章）

最后一个实战回到"人"：客服 Copilot 不自动处置，而是坐在人工客服旁边实时出建议——Mem0 长期记忆记住每位车主，多轮对话状态机管理会话，人在回路做到底。随后是全系列总结：18 章知识地图、三条主线回顾、与前作《Flink 2.3 实时 AI 推理实战》的资产关系图，以及 Flink Agents 版本演进展望。

官方参考资料

• Flink Agents 0.3 Documentation
• Apache Flink 2.3 Documentation — State Backends
• Apache Paimon 1.4 Documentation

本章实战代码清单

序号	内容	说明
1	三级任务事件模型（Task/Subtask/Finding）	17.3.1
2	Worker 三级漏斗（规则→轻模型→大模型）	17.3.2
3	结论行上下文保鲜纪律	17.3.3
4	两级聚合 + 报告 Agent 五段式提示词	17.4
5	Doris 报告表 + Paimon 明细审计	17.4.3
6	巡检⇄自愈双向知识闭环	17.5
7	定时调度脚本 + 验收指标集	17.6