用 —— 第 14 章 可觀測與效果評估)
Flink Agents 與 AI 流式應(yīng)用 —— 第 14 章 可觀測與效果評估章節(jié)定位第 13 章把防線建好了本章解決看得見的問題。傳統(tǒng)流處理監(jiān)控看吞吐、延遲、反壓——Agent 系統(tǒng)還要多回答三個問題它為什么這么決策Trace、決策得對不對效果、花了多少錢成本。本章落地決策 Trace 全鏈路還原、四維效果評估體系、成本歸因到每個 Agent 每個工具、人工反饋閉環(huán)以及 Agent 版監(jiān)控五件套配置。版本基線Apache Flink 2.3.0 Flink Agents 0.3.xJDK 17章節(jié)導(dǎo)讀14.1 決策 Trace全鏈路還原14.2 四維效果評估準確、成本、時效、穩(wěn)定14.3 成本歸因到每個 Agent 每個工具14.4 人工反饋閉環(huán)從糾錯到資產(chǎn)14.5 監(jiān)控五件套Agent 版落地配置14.6 實戰(zhàn)效果評估周報自動化14.7 本章小結(jié)與下章預(yù)告14.1 決策 Trace全鏈路還原14.1.1 Trace 的數(shù)據(jù)源第 12.3 章的 Paimon 審計表就是 Trace 的素材庫: 每個事件的完整 prompt、工具調(diào)用序列、決策、成本、版本 trace_id 串聯(lián)規(guī)則(第 10 章埋的線): 輸入事件生成 trace_id → 全鏈路事件繼承(分診/?？?工單同 trace_id) → MCP 調(diào)用透傳(5.5.2 審計日志同 trace_id) → 一個 trace_id 查出這條告警從進入到建單的全部足跡14.1.2 Trace 查詢工具-- 還原單事件決策鏈(排查它為什么這么判)SELECTstep,action_type,content,cost_tokens,latency_msFROMaudit.agent_decision_detailWHEREtrace_idalm-ALM001ORDERBYstep;-- 結(jié)果示例:-- step1 ChatReq prompt(記憶注入版) 1200 tok-- step2 ToolCall dtc://P0AA6 120ms-- step3 ChatResp ThoughtAction 300 tok-- ...-- step8 Output P2工單 confidence0.8214.1.3 典型排查場景問題Trace 排查路徑誤判看每步 Thought 注入的記憶 → 定位被帶偏的環(huán)節(jié)成本異常按 step 看 token 分布 → 找出失控的循環(huán)延遲超標看每步 latency → 慢在 LLM 還是工具幻覺引用對照 refs 與 ToolCall 記錄6.4.2 的生產(chǎn)復(fù)核14.2 四維效果評估準確、成本、時效、穩(wěn)定14.2.1 指標體系┌──────────┬────────────────────────────┬──────────────────┐ │ 維度 │ 核心指標 │ 數(shù)據(jù)源 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 準確性 │ 復(fù)檢推翻率 / refs 真實率 │ 工單復(fù)檢結(jié)果回填 │ │ │ 分診準確率 / 轉(zhuǎn)人工合理率 │ 抽樣人工核對 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 成本 │ 單事件 token / 日總成本 │ 審計表 cost_tokens │ │ │ 成本分布(分診/?？?工具) │ 14.3 歸因 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 時效 │ 端到端 p50/p99 │ 審計表 latency_ms │ │ │ 平均決策步數(shù) │ step 計數(shù) │ ├──────────┼────────────────────────────┼──────────────────┤ │ 穩(wěn)定性 │ 步數(shù)打滿率 / 降級率 │ 13.4/6.2 標記統(tǒng)計 │ │ │ 同癥狀決策一致率(8.5.3 AB) │ 對照實驗 │ └──────────┴────────────────────────────┴──────────────────┘14.2.2 準確性的特殊難題Agent 準確性 ≠ 模型準確性: 模型對 工具錯 決策錯(檢索回了錯的案例) 模型對 記憶臟 決策錯(8.4 記憶污染) 模型錯 校驗攔 決策對(6.4 語義校驗救回來) → 評估必須歸因到環(huán)節(jié),否則優(yōu)化無從下手 → 這就是 14.1 Trace 的價值: 每個環(huán)節(jié)獨立打分14.2.3 基線與紅線上線前定基線,運行中守紅線(示例值,按業(yè)務(wù)定): 復(fù)檢推翻率 基線 15% 紅線 25% refs 真實率 基線 100% 紅線 100%(不可妥協(xié)) 單事件成本 基線 4k tok 紅線 15k tok 端到端 p99 基線 45s 紅線 90s 步數(shù)打滿率 基線 1% 紅線 2%(6.6.3 驗收值) 轉(zhuǎn)人工率 基線 15% 紅線區(qū)間 10%~25% (過低 校驗失效不敢轉(zhuǎn);過高 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 典型發(fā)現(xiàn)與優(yōu)化動作發(fā)現(xiàn) 1: 絕緣告警 avg_tokens 是其他的 3 倍 → 排查: ?？乒ぞ呙枋霾?LLM 反復(fù)試錯(4.1.1) → 動作: 重寫工具描述,avg 降回基線 發(fā)現(xiàn) 2: 分診占 token 總量 40% → 排查: 分診誤用了大模型 → 動作: 切小模型(10.5.2),成本降 60% 發(fā)現(xiàn) 3: 5% 事件消耗 40% 成本 → 排查: 長尾疑難事件步數(shù)打滿 → 動作: 該類事件直接轉(zhuǎn)人工,ROI 更高的資源分配14.4 人工反饋閉環(huán)從糾錯到資產(chǎn)14.4.1 閉環(huán)設(shè)計人工處置(復(fù)核/糾偏/補償) │ ▼ 反饋結(jié)構(gòu)化: {event_id, agent結(jié)論, 人工結(jié)論, 差異類型} │ ├─→ 差異誤診 → 病程庫 recheck_ok0(8.4 降權(quán)) ├─→ 差異分診錯 → 分診 badcase 集(提示詞優(yōu)化素材) ├─→ 差異工具錯 → 工具契約修復(fù)(4.1 描述重寫) └─→ 人工結(jié)論優(yōu) → 提煉為知識庫新案例(前作 RAG 入庫)14.4.2 反饋回流實現(xiàn)// 人工處置結(jié)果從工單系統(tǒng)回流(Kafka 事件)Action(listenEventTypes{feedback.submitted})publicEventonFeedback(ActionContextctx,FeedbackEvente){// ① 差異分類(確定性規(guī)則,不用 LLM)DiffTypediffclassify(e.agentResult,e.humanResult);// ② 按差異類型回流到對應(yīng)資產(chǎn)switch(diff){caseMISDIAGNOSIS-doris.upsert(recheckFail(e.eventId));// 病程降權(quán)caseTRIAGE_ERROR-badcaseStore.append(triage,e);// badcase 集caseBETTER_SOLUTION-knowledgePipeline.submit(e);// 新案例入庫}metrics.feedback.labels(diff.name()).inc();returnnull;}紀律: □ 反饋必須結(jié)構(gòu)化——判錯了沒有用, 哪一步錯、正確答案是什么才是資產(chǎn) □ 反饋處理零 LLM(分類規(guī)則化),只有知識提煉用 LLM □ badcase 積累到閾值(如 50 例)→ 觸發(fā)提示詞版本迭代14.5 監(jiān)控五件套Agent 版落地配置14.5.1 五件套清單① Metrics(指標): 四維指標全部暴露 Prometheus ② Logging(日志): 結(jié)構(gòu)化 JSON,trace_id 必帶 ③ Tracing(鏈路): 14.1 決策鏈查詢工具 ④ Alerting(告警): 紅線觸發(fā) 熔斷觸發(fā)(13.5.2) ⑤ Dashboard(看板): Grafana 四維分屏14.5.2 關(guān)鍵指標暴露// Agent 作業(yè)內(nèi)暴露(在前作監(jiān)控規(guī)范上擴展 AI 維度)agentDecisionLatency.labels(agent,category)// 時效agentTokenUsage.labels(agent,model)// 成本agentStepCount.labels(agent)// 推理深度agentDegradedTotal.labels(agent,reason)// 降級agentGuardTripped.labels(agent,guard)// 三道閘觸發(fā)agentRefsValidity.labels(agent)// 引用真實率(紅線)costBreakerTripped.labels(job)// 成本熔斷(13.5)14.5.3 告警規(guī)則示例# Prometheus 告警規(guī)則(紅線 14.2.3)-alert:AgentRefsHallucinationexpr:agentRefsValidity 1.0for:1mannotations:summary:幻覺引用出現(xiàn)!refs 真實率跌破 100%severity:P0# 不可妥協(xié)的紅線-alert:AgentCostSurgeexpr:rate(agentTokenUsage[1h])1.5 * rate(agentTokenUsage[1h]offset 1d)annotations:summary:Agent 成本環(huán)比突增 50%severity:P114.6 實戰(zhàn)效果評估周報自動化14.6.1 設(shè)計每周一 09:00,評估 Agent(12.4 數(shù)倉任務(wù)玩法)自動生成周報: ① 跑四維指標 SQL(只讀白名單) ② 對比上周基線,標注超紅線項 ③ LLM 生成分析:絕緣告警成本上升源于工具 X 描述缺陷, 建議重寫描述;分診 OTHER 率 6% 超線,新增 2 個 badcase 歸類 ④ 推送團隊群 歸檔 Paimon14.6.2 核心實現(xiàn)publicclassWeeklyEvalAgentimplementsAgent{OverridepublicvoidonTimer(longts,ActionContextctx){if(!isMondayMorning(ts))return;// ① 四維數(shù)據(jù)(只讀)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 驗收清單□ 周報數(shù)據(jù)與 Grafana 看板一致(同一 SQL 來源) □ 超紅線項 100% 被標注,無漏報 □ 分析建議可操作(指向具體工具/提示詞,不是空話) □ 周報復(fù)讀率 0(冪等生效)14.7 本章小結(jié)與下章預(yù)告本章小結(jié)┌──────────────────────────────────────────────────────────────┐ │ 第 14 章 要點回顧 │ └──────────────────────────────────────────────────────────────┘ ? Trace: trace_id 貫穿全鏈路(含 MCP 透傳), Paimon 審計表是素材庫,單事件決策鏈可完整還原 ? 四維評估: 準確(復(fù)檢推翻率/refs 真實率)/成本/ 時效/穩(wěn)定;準確性必須歸因到環(huán)節(jié); 上線定基線,運行守紅線,refs 真實率 100% 不可妥協(xié) ? 成本歸因: agent × 告警類別熱力圖; 三大典型優(yōu)化——工具描述/模型檔位/長尾轉(zhuǎn)人工 ? 反饋閉環(huán): 結(jié)構(gòu)化反饋按差異類型回流 (病程降權(quán)/badcase 集/知識庫新案例); 分類零 LLM,提煉才用 LLM ? 五件套: Metrics/Logging/Tracing/Alerting/Dashboard; refs 幻覺告警 P0 級;周報 Agent 自動化(自評自診)下章預(yù)告第 15 章 安全權(quán)限合規(guī)看得見的系統(tǒng)還要管得住——動作權(quán)限模型Agent 能做什么的白名單體系、Prompt 注入防護深化、數(shù)據(jù)脫敏VIN/車主信息的最小暴露、憑證最小授權(quán)、審計追溯合規(guī)以及最重要的落地方法論影子→審批→受限自動的三階段漸進放權(quán) SOP。這是 Agent 從Demo 走向生產(chǎn)的最后一道門檻。官方參考資料Flink Agents 0.3 DocumentationFlink 2.3 Metrics DocumentationPrometheus Alerting Rules本章實戰(zhàn)代碼清單序號內(nèi)容說明1trace_id 貫穿規(guī)則與 Trace 查詢 SQL14.12四維指標體系 基線紅線表14.23成本歸因熱力圖 SQL 優(yōu)化案例14.34人工反饋閉環(huán)回流實現(xiàn)14.45監(jiān)控五件套 關(guān)鍵告警規(guī)則14.56效果評估周報 Agent自評自診14.6 Flink Agents 與 AI 流式應(yīng)用 —— 第 14 章 可觀測與效果評估
Flink Agents 與 AI 流式應(yīng)用 —— 第 14 章 可觀測與效果評估章節(jié)定位第 13 章把防線建好了本章解決看得見的問題。傳統(tǒng)流處理監(jiān)控看吞吐、延遲、反壓——Agent 系統(tǒng)還要多回答三個問題它為什么這么決策Trace、決策得對不對效果、花了多少錢成本。本章落地決策 Trace 全鏈路還原、四維效果評估體系、成本歸因到每個 Agent 每個工具、人工反饋閉環(huán)以及 Agent 版監(jiān)控五件套配置。版本基線Apache Flink 2.3.0 Flink Agents 0.3.xJDK 17章節(jié)導(dǎo)讀14.1 決策 Trace全鏈路還原14.2 四維效果評估準確、成本、時效、穩(wěn)定14.3 成本歸因到每個 Agent 每個工具14.4 人工反饋閉環(huán)從糾錯到資產(chǎn)14.5 監(jiān)控五件套Agent 版落地配置14.6 實戰(zhàn)效果評估周報自動化14.7 本章小結(jié)與下章預(yù)告14.1 決策 Trace全鏈路還原14.1.1 Trace 的數(shù)據(jù)源第 12.3 章的 Paimon 審計表就是 Trace 的素材庫: 每個事件的完整 prompt、工具調(diào)用序列、決策、成本、版本 trace_id 串聯(lián)規(guī)則(第 10 章埋的線): 輸入事件生成 trace_id → 全鏈路事件繼承(分診/?？?工單同 trace_id) → MCP 調(diào)用透傳(5.5.2 審計日志同 trace_id) → 一個 trace_id 查出這條告警從進入到建單的全部足跡14.1.2 Trace 查詢工具-- 還原單事件決策鏈(排查它為什么這么判)SELECTstep,action_type,content,cost_tokens,latency_msFROMaudit.agent_decision_detailWHEREtrace_idalm-ALM001ORDERBYstep;-- 結(jié)果示例:-- step1 ChatReq prompt(記憶注入版) 1200 tok-- step2 ToolCall dtc://P0AA6 120ms-- step3 ChatResp ThoughtAction 300 tok-- ...-- step8 Output P2工單 confidence0.8214.1.3 典型排查場景問題Trace 排查路徑誤判看每步 Thought 注入的記憶 → 定位被帶偏的環(huán)節(jié)成本異常按 step 看 token 分布 → 找出失控的循環(huán)延遲超標看每步 latency → 慢在 LLM 還是工具幻覺引用對照 refs 與 ToolCall 記錄6.4.2 的生產(chǎn)復(fù)核14.2 四維效果評估準確、成本、時效、穩(wěn)定14.2.1 指標體系┌──────────┬────────────────────────────┬──────────────────┐ │ 維度 │ 核心指標 │ 數(shù)據(jù)源 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 準確性 │ 復(fù)檢推翻率 / refs 真實率 │ 工單復(fù)檢結(jié)果回填 │ │ │ 分診準確率 / 轉(zhuǎn)人工合理率 │ 抽樣人工核對 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 成本 │ 單事件 token / 日總成本 │ 審計表 cost_tokens │ │ │ 成本分布(分診/?？?工具) │ 14.3 歸因 │ ├──────────┼────────────────────────────┼──────────────────┤ │ 時效 │ 端到端 p50/p99 │ 審計表 latency_ms │ │ │ 平均決策步數(shù) │ step 計數(shù) │ ├──────────┼────────────────────────────┼──────────────────┤ │ 穩(wěn)定性 │ 步數(shù)打滿率 / 降級率 │ 13.4/6.2 標記統(tǒng)計 │ │ │ 同癥狀決策一致率(8.5.3 AB) │ 對照實驗 │ └──────────┴────────────────────────────┴──────────────────┘14.2.2 準確性的特殊難題Agent 準確性 ≠ 模型準確性: 模型對 工具錯 決策錯(檢索回了錯的案例) 模型對 記憶臟 決策錯(8.4 記憶污染) 模型錯 校驗攔 決策對(6.4 語義校驗救回來) → 評估必須歸因到環(huán)節(jié),否則優(yōu)化無從下手 → 這就是 14.1 Trace 的價值: 每個環(huán)節(jié)獨立打分14.2.3 基線與紅線上線前定基線,運行中守紅線(示例值,按業(yè)務(wù)定): 復(fù)檢推翻率 基線 15% 紅線 25% refs 真實率 基線 100% 紅線 100%(不可妥協(xié)) 單事件成本 基線 4k tok 紅線 15k tok 端到端 p99 基線 45s 紅線 90s 步數(shù)打滿率 基線 1% 紅線 2%(6.6.3 驗收值) 轉(zhuǎn)人工率 基線 15% 紅線區(qū)間 10%~25% (過低 校驗失效不敢轉(zhuǎn);過高 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 典型發(fā)現(xiàn)與優(yōu)化動作發(fā)現(xiàn) 1: 絕緣告警 avg_tokens 是其他的 3 倍 → 排查: ?？乒ぞ呙枋霾?LLM 反復(fù)試錯(4.1.1) → 動作: 重寫工具描述,avg 降回基線 發(fā)現(xiàn) 2: 分診占 token 總量 40% → 排查: 分診誤用了大模型 → 動作: 切小模型(10.5.2),成本降 60% 發(fā)現(xiàn) 3: 5% 事件消耗 40% 成本 → 排查: 長尾疑難事件步數(shù)打滿 → 動作: 該類事件直接轉(zhuǎn)人工,ROI 更高的資源分配14.4 人工反饋閉環(huán)從糾錯到資產(chǎn)14.4.1 閉環(huán)設(shè)計人工處置(復(fù)核/糾偏/補償) │ ▼ 反饋結(jié)構(gòu)化: {event_id, agent結(jié)論, 人工結(jié)論, 差異類型} │ ├─→ 差異誤診 → 病程庫 recheck_ok0(8.4 降權(quán)) ├─→ 差異分診錯 → 分診 badcase 集(提示詞優(yōu)化素材) ├─→ 差異工具錯 → 工具契約修復(fù)(4.1 描述重寫) └─→ 人工結(jié)論優(yōu) → 提煉為知識庫新案例(前作 RAG 入庫)14.4.2 反饋回流實現(xiàn)// 人工處置結(jié)果從工單系統(tǒng)回流(Kafka 事件)Action(listenEventTypes{feedback.submitted})publicEventonFeedback(ActionContextctx,FeedbackEvente){// ① 差異分類(確定性規(guī)則,不用 LLM)DiffTypediffclassify(e.agentResult,e.humanResult);// ② 按差異類型回流到對應(yīng)資產(chǎn)switch(diff){caseMISDIAGNOSIS-doris.upsert(recheckFail(e.eventId));// 病程降權(quán)caseTRIAGE_ERROR-badcaseStore.append(triage,e);// badcase 集caseBETTER_SOLUTION-knowledgePipeline.submit(e);// 新案例入庫}metrics.feedback.labels(diff.name()).inc();returnnull;}紀律: □ 反饋必須結(jié)構(gòu)化——判錯了沒有用, 哪一步錯、正確答案是什么才是資產(chǎn) □ 反饋處理零 LLM(分類規(guī)則化),只有知識提煉用 LLM □ badcase 積累到閾值(如 50 例)→ 觸發(fā)提示詞版本迭代14.5 監(jiān)控五件套Agent 版落地配置14.5.1 五件套清單① Metrics(指標): 四維指標全部暴露 Prometheus ② Logging(日志): 結(jié)構(gòu)化 JSON,trace_id 必帶 ③ Tracing(鏈路): 14.1 決策鏈查詢工具 ④ Alerting(告警): 紅線觸發(fā) 熔斷觸發(fā)(13.5.2) ⑤ Dashboard(看板): Grafana 四維分屏14.5.2 關(guān)鍵指標暴露// Agent 作業(yè)內(nèi)暴露(在前作監(jiān)控規(guī)范上擴展 AI 維度)agentDecisionLatency.labels(agent,category)// 時效agentTokenUsage.labels(agent,model)// 成本agentStepCount.labels(agent)// 推理深度agentDegradedTotal.labels(agent,reason)// 降級agentGuardTripped.labels(agent,guard)// 三道閘觸發(fā)agentRefsValidity.labels(agent)// 引用真實率(紅線)costBreakerTripped.labels(job)// 成本熔斷(13.5)14.5.3 告警規(guī)則示例# Prometheus 告警規(guī)則(紅線 14.2.3)-alert:AgentRefsHallucinationexpr:agentRefsValidity 1.0for:1mannotations:summary:幻覺引用出現(xiàn)!refs 真實率跌破 100%severity:P0# 不可妥協(xié)的紅線-alert:AgentCostSurgeexpr:rate(agentTokenUsage[1h])1.5 * rate(agentTokenUsage[1h]offset 1d)annotations:summary:Agent 成本環(huán)比突增 50%severity:P114.6 實戰(zhàn)效果評估周報自動化14.6.1 設(shè)計每周一 09:00,評估 Agent(12.4 數(shù)倉任務(wù)玩法)自動生成周報: ① 跑四維指標 SQL(只讀白名單) ② 對比上周基線,標注超紅線項 ③ LLM 生成分析:絕緣告警成本上升源于工具 X 描述缺陷, 建議重寫描述;分診 OTHER 率 6% 超線,新增 2 個 badcase 歸類 ④ 推送團隊群 歸檔 Paimon14.6.2 核心實現(xiàn)publicclassWeeklyEvalAgentimplementsAgent{OverridepublicvoidonTimer(longts,ActionContextctx){if(!isMondayMorning(ts))return;// ① 四維數(shù)據(jù)(只讀)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 驗收清單□ 周報數(shù)據(jù)與 Grafana 看板一致(同一 SQL 來源) □ 超紅線項 100% 被標注,無漏報 □ 分析建議可操作(指向具體工具/提示詞,不是空話) □ 周報復(fù)讀率 0(冪等生效)14.7 本章小結(jié)與下章預(yù)告本章小結(jié)┌──────────────────────────────────────────────────────────────┐ │ 第 14 章 要點回顧 │ └──────────────────────────────────────────────────────────────┘ ? Trace: trace_id 貫穿全鏈路(含 MCP 透傳), Paimon 審計表是素材庫,單事件決策鏈可完整還原 ? 四維評估: 準確(復(fù)檢推翻率/refs 真實率)/成本/ 時效/穩(wěn)定;準確性必須歸因到環(huán)節(jié); 上線定基線,運行守紅線,refs 真實率 100% 不可妥協(xié) ? 成本歸因: agent × 告警類別熱力圖; 三大典型優(yōu)化——工具描述/模型檔位/長尾轉(zhuǎn)人工 ? 反饋閉環(huán): 結(jié)構(gòu)化反饋按差異類型回流 (病程降權(quán)/badcase 集/知識庫新案例); 分類零 LLM,提煉才用 LLM ? 五件套: Metrics/Logging/Tracing/Alerting/Dashboard; refs 幻覺告警 P0 級;周報 Agent 自動化(自評自診)下章預(yù)告第 15 章 安全權(quán)限合規(guī)看得見的系統(tǒng)還要管得住——動作權(quán)限模型Agent 能做什么的白名單體系、Prompt 注入防護深化、數(shù)據(jù)脫敏VIN/車主信息的最小暴露、憑證最小授權(quán)、審計追溯合規(guī)以及最重要的落地方法論影子→審批→受限自動的三階段漸進放權(quán) SOP。這是 Agent 從Demo 走向生產(chǎn)的最后一道門檻。官方參考資料Flink Agents 0.3 DocumentationFlink 2.3 Metrics DocumentationPrometheus Alerting Rules本章實戰(zhàn)代碼清單序號內(nèi)容說明1trace_id 貫穿規(guī)則與 Trace 查詢 SQL14.12四維指標體系 基線紅線表14.23成本歸因熱力圖 SQL 優(yōu)化案例14.34人工反饋閉環(huán)回流實現(xiàn)14.45監(jiān)控五件套 關(guān)鍵告警規(guī)則14.56效果評估周報 Agent自評自診14.6