Flink Agents 与 AI 流式应用 —— 第 17 章 实战二车队巡检 Agent章节定位第六篇终局实战之二。第 16 章的告警自愈是事件驱动——告警来了才动本章的车队巡检是主动驱动——没告警也要定期给全车队做体检。这是流式 Agent 的另一类主场批量任务编排、Supervisor-Worker 协作、长任务上下文保鲜、巡检报告自动生成以及巡检结果回流告警自愈系统形成知识闭环。读完本章你能搭出一个每月自动跑完 10 万台车健康巡检并产出分级报告的系统。版本基线Apache Flink 2.3.0 Flink Agents 0.3.xJDK 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 三类巡检任务任务触发方式规模时效要求月度健康巡检定时每月 1 号凌晨全量 10 万台6 小时内出报告OTA 后专项复查事件OTA 完成广播目标车型 1~3 万台48 小时高危车队盯防定时每周筛选出的 5 千台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 段ListStringvins;// 每片 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 异步工具)VehicleMetricsmtools.queryTelemetry30d(vin);// ② 规则初筛,零 LLM:80% 车辆在此直接出 OK(12.5 前置拦截思想)if(Rules.allGreen(m)){emit(finding(vin,100,OK,各项指标正常,null));continue;}// ③ 可疑车辆才走 LLM:轻模型初判VerdictvlightModel.judge(m,sub.shardFocus,blackboard.read(sub.taskId));// ④ 读任务级发现if(v.levelSUSPECT||v.levelCRITICAL){vheavyModel.deepJudge(m,v);// 大模型复核(三道闸 6.2.2)}emit(finding(vin,v.score,v.level,v.finding,v.refs));// ⑤ 发现反哺黑板:同批次检出率超阈值时,Supervisor 会加权后续分片if(v.levelCRITICAL)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.3Stringprompt [角色] 你是车队健康报告撰写专家,面向运维总监与售后管理层。 [任务] 基于给定统计数据与重点发现,生成月度巡检报告。 所有数字必须原样引用输入,禁止推算未提供的统计值。 [数据] 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_writetrue);-- 明细入 Paimon 审计表(__DT__ 分区硬约束),结论行全量留存可回溯17.5 与告警自愈系统联动知识闭环巡检 → 自愈(发现即告警): CRITICAL 车辆 → 生成 alert.healing 入口事件 → 走第 16 章全链路(防抖/分诊/专科/建单) —— 巡检发现的隐患,享受与实时告警同等的处置基建 自愈 → 巡检(经验变要点): 病程库(8.3)新增 recheck_ok1 的确诊案例 → 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.namefleet-inspection-monthly\-Dexecution.checkpointing.interval30000\-Drestart-strategyfixed-delay\-Drestart-strategy.fixed-delay.attempts2147483647\-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,黑板峰值 6KB17.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 DocumentationApache Flink 2.3 Documentation — State BackendsApache Paimon 1.4 Documentation本章实战代码清单序号内容说明1三级任务事件模型Task/Subtask/Finding17.3.12Worker 三级漏斗规则→轻模型→大模型17.3.23结论行上下文保鲜纪律17.3.34两级聚合 报告 Agent 五段式提示词17.45Doris 报告表 Paimon 明细审计17.4.36巡检⇄自愈双向知识闭环17.57定时调度脚本 验收指标集17.6