Flink Agents 与 AI 流式应用 —— 第 14 章 可观测与效果评估章节定位第 13 章把防线建好了本章解决看得见的问题。传统流处理监控看吞吐、延迟、反压——Agent 系统还要多回答三个问题它为什么这么决策Trace、决策得对不对效果、花了多少钱成本。本章落地决策 Trace 全链路还原、四维效果评估体系、成本归因到每个 Agent 每个工具、人工反馈闭环以及 Agent 版监控五件套配置。版本基线Apache Flink 2.3.0 Flink Agents 0.3.xJDK 17章节导读14.1 决策 Trace全链路还原14.2 四维效果评估准确、成本、时效、稳定14.3 成本归因到每个 Agent 每个工具14.4 人工反馈闭环从纠错到资产14.5 监控五件套Agent 版落地配置14.6 实战效果评估周报自动化14.7 本章小结与下章预告14.1 决策 Trace全链路还原14.1.1 Trace 的数据源第 12.3 章的 Paimon 审计表就是 Trace 的素材库: 每个事件的完整 prompt、工具调用序列、决策、成本、版本 trace_id 串联规则(第 10 章埋的线): 输入事件生成 trace_id → 全链路事件继承(分诊/专科/工单同 trace_id) → MCP 调用透传(5.5.2 审计日志同 trace_id) → 一个 trace_id 查出这条告警从进入到建单的全部足迹14.1.2 Trace 查询工具-- 还原单事件决策链(排查它为什么这么判)SELECTstep,action_type,content,cost_tokens,latency_msFROMaudit.agent_decision_detailWHEREtrace_idalm-ALM001ORDERBYstep;-- 结果示例:-- step1 ChatReq prompt(记忆注入版) 1200 tok-- step2 ToolCall dtc://P0AA6 120ms-- step3 ChatResp ThoughtAction 300 tok-- ...-- step8 Output P2工单 confidence0.8214.1.3 典型排查场景问题Trace 排查路径误判看每步 Thought 注入的记忆 → 定位被带偏的环节成本异常按 step 看 token 分布 → 找出失控的循环延迟超标看每步 latency → 慢在 LLM 还是工具幻觉引用对照 refs 与 ToolCall 记录6.4.2 的生产复核14.2 四维效果评估准确、成本、时效、稳定14.2.1 指标体系┌──────────┬────────────────────────────┬──────────────────┐ │ 维度 │ 核心指标 │ 数据源 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 准确性 │ 复检推翻率 / refs 真实率 │ 工单复检结果回填 │ │ │ 分诊准确率 / 转人工合理率 │ 抽样人工核对 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 成本 │ 单事件 token / 日总成本 │ 审计表 cost_tokens │ │ │ 成本分布(分诊/专科/工具) │ 14.3 归因 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 时效 │ 端到端 p50/p99 │ 审计表 latency_ms │ │ │ 平均决策步数 │ step 计数 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 稳定性 │ 步数打满率 / 降级率 │ 13.4/6.2 标记统计 │ │ │ 同症状决策一致率(8.5.3 AB) │ 对照实验 │ └──────────┴────────────────────────────┴──────────────────┘14.2.2 准确性的特殊难题Agent 准确性 ≠ 模型准确性: 模型对 工具错 决策错(检索回了错的案例) 模型对 记忆脏 决策错(8.4 记忆污染) 模型错 校验拦 决策对(6.4 语义校验救回来) → 评估必须归因到环节,否则优化无从下手 → 这就是 14.1 Trace 的价值: 每个环节独立打分14.2.3 基线与红线上线前定基线,运行中守红线(示例值,按业务定): 复检推翻率 基线 15% 红线 25% refs 真实率 基线 100% 红线 100%(不可妥协) 单事件成本 基线 4k tok 红线 15k tok 端到端 p99 基线 45s 红线 90s 步数打满率 基线 1% 红线 2%(6.6.3 验收值) 转人工率 基线 15% 红线区间 10%~25% (过低 校验失效不敢转;过高 Agent 能力不行)14.3 成本归因到每个 Agent 每个工具14.3.1 归因维度-- 成本热力图: 哪个 Agent 哪类事件最烧钱SELECTagent_name,alert_category,COUNT(*)ASevents,SUM(cost_tokens)AStotal_tokens,AVG(cost_tokens)ASavg_tokens,AVG(step_count)ASavg_stepsFROMaudit.agent_decision_logWHEREdtDATE_SUB(CURDATE(),7)GROUPBYagent_name,alert_categoryORDERBYtotal_tokensDESC;14.3.2 典型发现与优化动作发现 1: 绝缘告警 avg_tokens 是其他的 3 倍 → 排查: 专科工具描述差,LLM 反复试错(4.1.1) → 动作: 重写工具描述,avg 降回基线 发现 2: 分诊占 token 总量 40% → 排查: 分诊误用了大模型 → 动作: 切小模型(10.5.2),成本降 60% 发现 3: 5% 事件消耗 40% 成本 → 排查: 长尾疑难事件步数打满 → 动作: 该类事件直接转人工,ROI 更高的资源分配14.4 人工反馈闭环从纠错到资产14.4.1 闭环设计人工处置(复核/纠偏/补偿) │ ▼ 反馈结构化: {event_id, agent结论, 人工结论, 差异类型} │ ├─→ 差异误诊 → 病程库 recheck_ok0(8.4 降权) ├─→ 差异分诊错 → 分诊 badcase 集(提示词优化素材) ├─→ 差异工具错 → 工具契约修复(4.1 描述重写) └─→ 人工结论优 → 提炼为知识库新案例(前作 RAG 入库)14.4.2 反馈回流实现// 人工处置结果从工单系统回流(Kafka 事件)Action(listenEventTypes{feedback.submitted})publicEventonFeedback(ActionContextctx,FeedbackEvente){// ① 差异分类(确定性规则,不用 LLM)DiffTypediffclassify(e.agentResult,e.humanResult);// ② 按差异类型回流到对应资产switch(diff){caseMISDIAGNOSIS-doris.upsert(recheckFail(e.eventId));// 病程降权caseTRIAGE_ERROR-badcaseStore.append(triage,e);// badcase 集caseBETTER_SOLUTION-knowledgePipeline.submit(e);// 新案例入库}metrics.feedback.labels(diff.name()).inc();returnnull;}纪律: □ 反馈必须结构化——判错了没有用, 哪一步错、正确答案是什么才是资产 □ 反馈处理零 LLM(分类规则化),只有知识提炼用 LLM □ badcase 积累到阈值(如 50 例)→ 触发提示词版本迭代14.5 监控五件套Agent 版落地配置14.5.1 五件套清单① Metrics(指标): 四维指标全部暴露 Prometheus ② Logging(日志): 结构化 JSON,trace_id 必带 ③ Tracing(链路): 14.1 决策链查询工具 ④ Alerting(告警): 红线触发 熔断触发(13.5.2) ⑤ Dashboard(看板): Grafana 四维分屏14.5.2 关键指标暴露// Agent 作业内暴露(在前作监控规范上扩展 AI 维度)agentDecisionLatency.labels(agent,category)// 时效agentTokenUsage.labels(agent,model)// 成本agentStepCount.labels(agent)// 推理深度agentDegradedTotal.labels(agent,reason)// 降级agentGuardTripped.labels(agent,guard)// 三道闸触发agentRefsValidity.labels(agent)// 引用真实率(红线)costBreakerTripped.labels(job)// 成本熔断(13.5)14.5.3 告警规则示例# Prometheus 告警规则(红线 14.2.3)-alert:AgentRefsHallucinationexpr:agentRefsValidity 1.0for:1mannotations:summary:幻觉引用出现!refs 真实率跌破 100%severity:P0# 不可妥协的红线-alert:AgentCostSurgeexpr:rate(agentTokenUsage[1h])1.5 * rate(agentTokenUsage[1h]offset 1d)annotations:summary:Agent 成本环比突增 50%severity:P114.6 实战效果评估周报自动化14.6.1 设计每周一 09:00,评估 Agent(12.4 数仓任务玩法)自动生成周报: ① 跑四维指标 SQL(只读白名单) ② 对比上周基线,标注超红线项 ③ LLM 生成分析:绝缘告警成本上升源于工具 X 描述缺陷, 建议重写描述;分诊 OTHER 率 6% 超线,新增 2 个 badcase 归类 ④ 推送团队群 归档 Paimon14.6.2 核心实现publicclassWeeklyEvalAgentimplementsAgent{OverridepublicvoidonTimer(longts,ActionContextctx){if(!isMondayMorning(ts))return;// ① 四维数据(只读)EvalDatadatarunEvalQueries();// ② 与基线对比(代码,确定性)ListAnomalyanomaliesdata.compareWithBaseline(BASELINE);// ③ LLM 只做分析与措辞(低温度)Stringreportmodel.chat(buildReportPrompt(data,anomalies));// ④ 推送 归档(幂等: 周期键 weekId 去重)dingTalk.send(report);paimonWriter.write(WeeklyReport.of(weekId(ts),data,report));}}14.6.3 验收清单□ 周报数据与 Grafana 看板一致(同一 SQL 来源) □ 超红线项 100% 被标注,无漏报 □ 分析建议可操作(指向具体工具/提示词,不是空话) □ 周报复读率 0(幂等生效)14.7 本章小结与下章预告本章小结┌──────────────────────────────────────────────────────────────┐ │ 第 14 章 要点回顾 │ └──────────────────────────────────────────────────────────────┘ ✓ Trace: trace_id 贯穿全链路(含 MCP 透传), Paimon 审计表是素材库,单事件决策链可完整还原 ✓ 四维评估: 准确(复检推翻率/refs 真实率)/成本/ 时效/稳定;准确性必须归因到环节; 上线定基线,运行守红线,refs 真实率 100% 不可妥协 ✓ 成本归因: agent × 告警类别热力图; 三大典型优化——工具描述/模型档位/长尾转人工 ✓ 反馈闭环: 结构化反馈按差异类型回流 (病程降权/badcase 集/知识库新案例); 分类零 LLM,提炼才用 LLM ✓ 五件套: Metrics/Logging/Tracing/Alerting/Dashboard; refs 幻觉告警 P0 级;周报 Agent 自动化(自评自诊)下章预告第 15 章 安全权限合规看得见的系统还要管得住——动作权限模型Agent 能做什么的白名单体系、Prompt 注入防护深化、数据脱敏VIN/车主信息的最小暴露、凭证最小授权、审计追溯合规以及最重要的落地方法论影子→审批→受限自动的三阶段渐进放权 SOP。这是 Agent 从Demo 走向生产的最后一道门槛。官方参考资料Flink Agents 0.3 DocumentationFlink 2.3 Metrics DocumentationPrometheus Alerting Rules本章实战代码清单序号内容说明1trace_id 贯穿规则与 Trace 查询 SQL14.12四维指标体系 基线红线表14.23成本归因热力图 SQL 优化案例14.34人工反馈闭环回流实现14.45监控五件套 关键告警规则14.56效果评估周报 Agent自评自诊14.6 
长河君 · 2026/10/18 6:01:01 · 阅读 1.2k Flink Agents 与 AI 流式应用 —— 第 14 章 可观测与效果评估
Flink Agents 与 AI 流式应用 —— 第 14 章 可观测与效果评估章节定位第 13 章把防线建好了本章解决看得见的问题。传统流处理监控看吞吐、延迟、反压——Agent 系统还要多回答三个问题它为什么这么决策Trace、决策得对不对效果、花了多少钱成本。本章落地决策 Trace 全链路还原、四维效果评估体系、成本归因到每个 Agent 每个工具、人工反馈闭环以及 Agent 版监控五件套配置。版本基线Apache Flink 2.3.0 Flink Agents 0.3.xJDK 17章节导读14.1 决策 Trace全链路还原14.2 四维效果评估准确、成本、时效、稳定14.3 成本归因到每个 Agent 每个工具14.4 人工反馈闭环从纠错到资产14.5 监控五件套Agent 版落地配置14.6 实战效果评估周报自动化14.7 本章小结与下章预告14.1 决策 Trace全链路还原14.1.1 Trace 的数据源第 12.3 章的 Paimon 审计表就是 Trace 的素材库: 每个事件的完整 prompt、工具调用序列、决策、成本、版本 trace_id 串联规则(第 10 章埋的线): 输入事件生成 trace_id → 全链路事件继承(分诊/专科/工单同 trace_id) → MCP 调用透传(5.5.2 审计日志同 trace_id) → 一个 trace_id 查出这条告警从进入到建单的全部足迹14.1.2 Trace 查询工具-- 还原单事件决策链(排查它为什么这么判)SELECTstep,action_type,content,cost_tokens,latency_msFROMaudit.agent_decision_detailWHEREtrace_idalm-ALM001ORDERBYstep;-- 结果示例:-- step1 ChatReq prompt(记忆注入版) 1200 tok-- step2 ToolCall dtc://P0AA6 120ms-- step3 ChatResp ThoughtAction 300 tok-- ...-- step8 Output P2工单 confidence0.8214.1.3 典型排查场景问题Trace 排查路径误判看每步 Thought 注入的记忆 → 定位被带偏的环节成本异常按 step 看 token 分布 → 找出失控的循环延迟超标看每步 latency → 慢在 LLM 还是工具幻觉引用对照 refs 与 ToolCall 记录6.4.2 的生产复核14.2 四维效果评估准确、成本、时效、稳定14.2.1 指标体系┌──────────┬────────────────────────────┬──────────────────┐ │ 维度 │ 核心指标 │ 数据源 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 准确性 │ 复检推翻率 / refs 真实率 │ 工单复检结果回填 │ │ │ 分诊准确率 / 转人工合理率 │ 抽样人工核对 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 成本 │ 单事件 token / 日总成本 │ 审计表 cost_tokens │ │ │ 成本分布(分诊/专科/工具) │ 14.3 归因 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 时效 │ 端到端 p50/p99 │ 审计表 latency_ms │ │ │ 平均决策步数 │ step 计数 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 稳定性 │ 步数打满率 / 降级率 │ 13.4/6.2 标记统计 │ │ │ 同症状决策一致率(8.5.3 AB) │ 对照实验 │ └──────────┴────────────────────────────┴──────────────────┘14.2.2 准确性的特殊难题Agent 准确性 ≠ 模型准确性: 模型对 工具错 决策错(检索回了错的案例) 模型对 记忆脏 决策错(8.4 记忆污染) 模型错 校验拦 决策对(6.4 语义校验救回来) → 评估必须归因到环节,否则优化无从下手 → 这就是 14.1 Trace 的价值: 每个环节独立打分14.2.3 基线与红线上线前定基线,运行中守红线(示例值,按业务定): 复检推翻率 基线 15% 红线 25% refs 真实率 基线 100% 红线 100%(不可妥协) 单事件成本 基线 4k tok 红线 15k tok 端到端 p99 基线 45s 红线 90s 步数打满率 基线 1% 红线 2%(6.6.3 验收值) 转人工率 基线 15% 红线区间 10%~25% (过低 校验失效不敢转;过高 Agent 能力不行)14.3 成本归因到每个 Agent 每个工具14.3.1 归因维度-- 成本热力图: 哪个 Agent 哪类事件最烧钱SELECTagent_name,alert_category,COUNT(*)ASevents,SUM(cost_tokens)AStotal_tokens,AVG(cost_tokens)ASavg_tokens,AVG(step_count)ASavg_stepsFROMaudit.agent_decision_logWHEREdtDATE_SUB(CURDATE(),7)GROUPBYagent_name,alert_categoryORDERBYtotal_tokensDESC;14.3.2 典型发现与优化动作发现 1: 绝缘告警 avg_tokens 是其他的 3 倍 → 排查: 专科工具描述差,LLM 反复试错(4.1.1) → 动作: 重写工具描述,avg 降回基线 发现 2: 分诊占 token 总量 40% → 排查: 分诊误用了大模型 → 动作: 切小模型(10.5.2),成本降 60% 发现 3: 5% 事件消耗 40% 成本 → 排查: 长尾疑难事件步数打满 → 动作: 该类事件直接转人工,ROI 更高的资源分配14.4 人工反馈闭环从纠错到资产14.4.1 闭环设计人工处置(复核/纠偏/补偿) │ ▼ 反馈结构化: {event_id, agent结论, 人工结论, 差异类型} │ ├─→ 差异误诊 → 病程库 recheck_ok0(8.4 降权) ├─→ 差异分诊错 → 分诊 badcase 集(提示词优化素材) ├─→ 差异工具错 → 工具契约修复(4.1 描述重写) └─→ 人工结论优 → 提炼为知识库新案例(前作 RAG 入库)14.4.2 反馈回流实现// 人工处置结果从工单系统回流(Kafka 事件)Action(listenEventTypes{feedback.submitted})publicEventonFeedback(ActionContextctx,FeedbackEvente){// ① 差异分类(确定性规则,不用 LLM)DiffTypediffclassify(e.agentResult,e.humanResult);// ② 按差异类型回流到对应资产switch(diff){caseMISDIAGNOSIS-doris.upsert(recheckFail(e.eventId));// 病程降权caseTRIAGE_ERROR-badcaseStore.append(triage,e);// badcase 集caseBETTER_SOLUTION-knowledgePipeline.submit(e);// 新案例入库}metrics.feedback.labels(diff.name()).inc();returnnull;}纪律: □ 反馈必须结构化——判错了没有用, 哪一步错、正确答案是什么才是资产 □ 反馈处理零 LLM(分类规则化),只有知识提炼用 LLM □ badcase 积累到阈值(如 50 例)→ 触发提示词版本迭代14.5 监控五件套Agent 版落地配置14.5.1 五件套清单① Metrics(指标): 四维指标全部暴露 Prometheus ② Logging(日志): 结构化 JSON,trace_id 必带 ③ Tracing(链路): 14.1 决策链查询工具 ④ Alerting(告警): 红线触发 熔断触发(13.5.2) ⑤ Dashboard(看板): Grafana 四维分屏14.5.2 关键指标暴露// Agent 作业内暴露(在前作监控规范上扩展 AI 维度)agentDecisionLatency.labels(agent,category)// 时效agentTokenUsage.labels(agent,model)// 成本agentStepCount.labels(agent)// 推理深度agentDegradedTotal.labels(agent,reason)// 降级agentGuardTripped.labels(agent,guard)// 三道闸触发agentRefsValidity.labels(agent)// 引用真实率(红线)costBreakerTripped.labels(job)// 成本熔断(13.5)14.5.3 告警规则示例# Prometheus 告警规则(红线 14.2.3)-alert:AgentRefsHallucinationexpr:agentRefsValidity 1.0for:1mannotations:summary:幻觉引用出现!refs 真实率跌破 100%severity:P0# 不可妥协的红线-alert:AgentCostSurgeexpr:rate(agentTokenUsage[1h])1.5 * rate(agentTokenUsage[1h]offset 1d)annotations:summary:Agent 成本环比突增 50%severity:P114.6 实战效果评估周报自动化14.6.1 设计每周一 09:00,评估 Agent(12.4 数仓任务玩法)自动生成周报: ① 跑四维指标 SQL(只读白名单) ② 对比上周基线,标注超红线项 ③ LLM 生成分析:绝缘告警成本上升源于工具 X 描述缺陷, 建议重写描述;分诊 OTHER 率 6% 超线,新增 2 个 badcase 归类 ④ 推送团队群 归档 Paimon14.6.2 核心实现publicclassWeeklyEvalAgentimplementsAgent{OverridepublicvoidonTimer(longts,ActionContextctx){if(!isMondayMorning(ts))return;// ① 四维数据(只读)EvalDatadatarunEvalQueries();// ② 与基线对比(代码,确定性)ListAnomalyanomaliesdata.compareWithBaseline(BASELINE);// ③ LLM 只做分析与措辞(低温度)Stringreportmodel.chat(buildReportPrompt(data,anomalies));// ④ 推送 归档(幂等: 周期键 weekId 去重)dingTalk.send(report);paimonWriter.write(WeeklyReport.of(weekId(ts),data,report));}}14.6.3 验收清单□ 周报数据与 Grafana 看板一致(同一 SQL 来源) □ 超红线项 100% 被标注,无漏报 □ 分析建议可操作(指向具体工具/提示词,不是空话) □ 周报复读率 0(幂等生效)14.7 本章小结与下章预告本章小结┌──────────────────────────────────────────────────────────────┐ │ 第 14 章 要点回顾 │ └──────────────────────────────────────────────────────────────┘ ✓ Trace: trace_id 贯穿全链路(含 MCP 透传), Paimon 审计表是素材库,单事件决策链可完整还原 ✓ 四维评估: 准确(复检推翻率/refs 真实率)/成本/ 时效/稳定;准确性必须归因到环节; 上线定基线,运行守红线,refs 真实率 100% 不可妥协 ✓ 成本归因: agent × 告警类别热力图; 三大典型优化——工具描述/模型档位/长尾转人工 ✓ 反馈闭环: 结构化反馈按差异类型回流 (病程降权/badcase 集/知识库新案例); 分类零 LLM,提炼才用 LLM ✓ 五件套: Metrics/Logging/Tracing/Alerting/Dashboard; refs 幻觉告警 P0 级;周报 Agent 自动化(自评自诊)下章预告第 15 章 安全权限合规看得见的系统还要管得住——动作权限模型Agent 能做什么的白名单体系、Prompt 注入防护深化、数据脱敏VIN/车主信息的最小暴露、凭证最小授权、审计追溯合规以及最重要的落地方法论影子→审批→受限自动的三阶段渐进放权 SOP。这是 Agent 从Demo 走向生产的最后一道门槛。官方参考资料Flink Agents 0.3 DocumentationFlink 2.3 Metrics DocumentationPrometheus Alerting Rules本章实战代码清单序号内容说明1trace_id 贯穿规则与 Trace 查询 SQL14.12四维指标体系 基线红线表14.23成本归因热力图 SQL 优化案例14.34人工反馈闭环回流实现14.45监控五件套 关键告警规则14.56效果评估周报 Agent自评自诊14.6