Flink Agents 与 AI 流式应用 —— 第 1 章 从实时推理到流式 AgentAI 应用的下一跳章节定位开篇。如果你完成了《Flink 2.3 实时 AI 推理实战》你已经能让数据流经过 Flink 时被模型理解——分类、归因、检索、生成。但理解之后呢告警归因给出了处置建议谁去执行本章从一个真实的最后一公里困境出发讲清单点推理的能力边界、Agent 范式的本质、为什么 Agent 必须长在流上以及 Flink Agents 在三方技术选型中的独特位置。本章纯概念不动手但它决定你后续 17 章的技术判断力。版本基线Apache Flink 2.3.0 Flink Agents 0.3.xJDK 17版本提示Flink Agents 为 Apache 新孵化子项目演进较快。本章只讲稳定的概念与定位具体 API 细节从第 2 章起逐章核实官方文档。章节导读1.1 单点推理的边界理解之后无人行动1.2 Agent 范式感知-决策-行动-验证1.3 为什么 Agent 必须是流式的1.4 Flink Agents 定位1.5 技术选型三方对比1.6 核心能力速览1.7 与前作的关系原子能力与编排层1.8 车联网实战场景预告与学习地图1.9 本章小结与下章预告1.1 单点推理的边界理解之后无人行动1.1.1 回顾前作做到了什么《Flink 2.3 实时 AI 推理实战》第 17 章的告警归因链路: Kafka 告警 → ML_PREDICT → {类别/等级/根因/建议/置信度} → Doris 输出示例: 建议:进站读取单体电压明细,必要时对3号模组均衡充电链路稳定、指标达标。但上线三个月后运营复盘发现一个尴尬事实建议发出去了,然后呢? 谁去查这辆车的历史维修记录? —— 没人,技师自己翻系统 谁去比对同车型相似故障的处置效果? —— 没人,凭老师傅经验 谁去建工单、派单、跟踪闭环? —— 人工,平均延迟 40 分钟 处置完成后谁验证告警是否消除? —— 大部分没人验证1.1.2 边界清单单点推理做不到的四件事边界表现根因无记忆每次推理都是白纸不知道这车上周刚修过电池ML_PREDICT 是无状态函数调用无动作只能输出建议文本不能调 API 建工单没有工具调用能力无多步无法先查档案→再比对→后下结论链式推理一次调用一次输出无闭环处置完不知道结果无法自我校正缺少验证与反馈环节一句话ML_PREDICT 回答了这是什么但业务要的是把它处理掉。理解与行动之间的鸿沟就是 Agent 的战场。1.2 Agent 范式感知-决策-行动-验证1.2.1 什么是 AgentAgent(智能体) 一个能自主完成任务的循环体: ┌──────────────────────────────────────┐ │ │ ▼ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 感知 │──▶│ 决策 │──▶│ 行动 │──▶│ 验证 │ │ 事件输入 │ │ LLM 推理 │ │ 调用工具 │ │ 结果检查 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ ▲ ┌────┴─────┐ │ 记忆/状态 │ └──────────┘用告警场景走一遍这个循环① 感知:P1 电池告警到达 ② 决策:LLM 判断需先查该车历史故障再定级 ③ 行动:调用工具 query_vehicle_history(vin) ④ 验证:查到 3 次同码历史 → 更新认知 → 再次决策升级为 P0,建紧急工单 ⑤ 行动:调用 create_ticket(...) → 验证工单创建成功 → 输出闭环报告1.2.2 LLM 的角色转变单点推理时代:LLM 问答机(输入文本 → 输出文本) Agent 时代: LLM 推理引擎(观察 记忆 → 决策下一步动作) 关键区别: 问答机的输出是终点; 推理引擎的输出是动作指令,执行结果会回来继续喂给它1.2.3 ReActAgent 决策的经典模式ReAct Reasoning Acting,交替进行: Thought: 压差 187mV 超阈值,但需排除传感器误报 Action: query_cell_voltage(vin, module3) Observation: 3 号模组 12 节单体电压离散度大 → 真实故障 Thought: 确认真实故障,查历史是否有同型案例 Action: search_similar_cases(单体压差超限 EV-X9) Observation: 命中 3 条工单,2 条通过均衡充电解决 Thought: 证据充分,按多数案例方案处置 Action: create_ticket(levelP1, plan均衡充电复检) → 任务完成这个思考-行动-观察交替的链条就是 Agent 区别于单次推理的本质形态。第 6 章会深入它的工程控制。1.3 为什么 Agent 必须是流式的Agent 框架很多1.5 详述为什么要在 Flink 里做四个理由13.1 事件驱动是 Agent 的天然形态Agent 的触发源是事件:告警到达、工单更新、定时器触发、 另一条流的状态变化、人工审批完成 批式框架(LangChain 等)的形态:用户提问 → 执行 → 返回 → 适合人找 Agent 流式框架的形态:事件流持续到达 → Agent 持续感知与响应 → 适合Agent 守着业务 车联网场景 99% 属于后者:没有车主会主动问我的车还好吗1.3.2 状态是会话与记忆的载体一个告警诊断 Agent 可能要等: 查档案工具返回(秒级) / 人工审批(分钟级) / 复检结果回流(小时级) 等待期间,决策上下文必须持久化: Flink Keyed State 按 VIN/会话 ID 隔离存储 Checkpoint 保证故障恢复后接着想,而不是从头想 → 这是无状态批式框架给不了的1.3.3 与数据流天然同构告警在 Kafka 里,档案在 Doris 里,审计入 Paimon 湖—— Agent 的输入输出本来就在流上: 批式框架:流 → 攒批 → 调 Agent 服务 → 结果再回流(两次序列化网络跳转) 流式原生:Agent 即算子,事件流经时直接被处理(零搬运)1.3.4 工程能力直接继承Flink 的成熟能力全部白拿: 反压与扩容(12 章) / Exactly-Once 与 Checkpoint(16 章) 监控告警(14 章) / 无限重试与降级(13 章) → 前作整套生产工程经验,全部适用于 Agent 作业1.4 Flink Agents 定位1.4.1 在技术栈中的位置┌─────────────────────────────────────────────────┐ │ 业务系统:告警平台 / 工单 / 客服台 / 运维大盘 │ ├─────────────────────────────────────────────────┤ │ Flink Agents(本课程):Agent 编排层 │ │ Event 驱动 · Action 决策 · Tool 调用 · Memory │ ├─────────────────────────────────────────────────┤ │ Flink 2.3 原生 AI(前作):推理原子能力 │ │ CREATE MODEL · ML_PREDICT · VECTOR_SEARCH │ ├─────────────────────────────────────────────────┤ │ Flink 运行时:状态 · Checkpoint · 反压 · 容错 │ ├─────────────────────────────────────────────────┤ │ 数据底座:Kafka(流) Paimon(湖) Doris(服务) │ │ 模型底座:内网 LLM 网关 / OpenAI 兼容端点 │ └─────────────────────────────────────────────────┘一句话定位Flink Agents 是基于 Flink 运行时的事件驱动 Agent 框架把前作的推理原子能力编排成会行动的智能体。1.4.2 它做了什么、没做什么做了: ✓ Agent 生命周期与事件循环的运行时托管 ✓ Action/Tool/Memory 的抽象与装配机制 ✓ LLM 调用与工具执行的事件化串联 ✓ 状态、容错、扩缩容(继承 Flink) 没做(也不该做): ✗ 不替代 ML_PREDICT——Agent 内部的单次推理仍走模型抽象 ✗ 不做工作流 GUI——它是代码级框架,不是低代码平台 ✗ 不绑定特定模型——一切 OpenAI 兼容端点均可接入1.5 技术选型三方对比维度LangChain/LlamaIndex 类自研异步编排Flink Agents运行形态请求-响应批式自选事件流原生状态管理外挂Redis 等自建Keyed State Checkpoint 内建容错语义进程级重试靠应用自建Exactly-Once 框架级数据源接入需自行桥接自行桥接Kafka/Paimon/Doris 连接器直连扩缩容手动/容器编排自建Flink 反压 弹性伸缩工具生态极丰富无MCP 标准化接入第 5 章适用场景交互式问答/原型轻量定制生产级事件驱动 Agent选型结论: 做 demo、做对话产品原型 → LangChain 类最快 做一个固定流程的自动化脚本 → 自研也够 把 Agent 架在实时数据流上, 要状态、要容错、要审计、要运维 → Flink Agents 是原生解注意认知误区这不是哪个框架更好而是运行形态是否匹配。把请求-响应框架硬架在 Kafka 流上等于自己重新发明一遍状态管理与容错——那正是 Flink 十年磨出来的东西。1.6 核心能力速览Flink Agents 的五大核心概念第 3 章逐一深讲此处建立印象┌─────────────────────────────────────────────────────────┐ │ Event : 一切驱动皆事件 │ │ 输入事件(告警到达) / 工具返回事件 / 内部事件 │ │ │ │ Action : 最小执行单元 │ │ LLM 决策 Action / 工具执行 Action │ │ 一个 Agent 一组 Action 的事件化编排 │ │ │ │ Tool : Agent 的手 │ │ 函数调用 / MCP 工具 / 业务 API │ │ │ │ Memory : Agent 的脑子 │ │ 会话上下文 状态,背靠 Flink Keyed State │ │ │ │ 多Agent : 分诊-专科-执行的协作拓扑(第 10 章) │ └─────────────────────────────────────────────────────────┘事件循环一图流InputEvent ──▶ Agent 事件循环 ──▶ OutputEvent │ ├─ LLM Action(决策:下一步做什么) ├─ Tool Action(执行:调用工具拿结果) ├─ Memory 读写(记住:更新上下文) └─ 内部事件(串联:工具结果喂回决策)1.7 与前作的关系原子能力与编排层前作(实时 AI 推理) 本作(流式 Agent) ───────────────── ───────────────── ML_PREDICT 单次推理 ──▶ Agent 内部 LLM Action 的底层调用 VECTOR_SEARCH 向量检索 ──▶ Agent 长期记忆的检索器(第 8 章) RAG 拼装与引用 ──▶ Agent 上下文工程的组件(第 9 章) 降级/缓存/成本控制 ──▶ Agent 防失控与可靠性(第 13 章) 审计/监控/合规 ──▶ Agent 可观测与安全(第 14/15 章) 告警归因结果 ──▶ 自愈 Agent 的触发事件(第 16 章) 维修知识库 RAG ──▶ Agent 可调用的知识工具(第 5 章 MCP)关键认知前作不是被替代而是被编排。你写的每一个 ML_PREDICT、每一条 RAG 链路都会变成 Agent 手里的工具。两个系列合起来才是完整的实时智能版图。1.8 车联网实战场景预告与学习地图1.8.1 三大终局实战第 16 章 告警自愈 Agent: 告警 → 诊断(查档案/查相似案例) → 处置(建单/通知/审批后远程操作) → 验证(复检数据回流确认消除) → 闭环归档 指标:自愈率 / MTTR / 人工介入率 / 误动作率 第 17 章 车队智能运维巡检 Agent: 定时触发 → 指标采集 → 健康基线比对(长期记忆) → 异常清单报告 → 严重异常自动转告警自愈 Agent 从被动接警到主动巡检 第 18 章 客服 Copilot(终章): 车主来电 → 实时转写流 → Agent 辅助:话术建议 知识召回 一键操作 人在回路:Agent 只建议不执行,人工确认后动作1.8.2 三条贯穿主线主线一 事件驱动优先:先想清楚什么事件触发 Agent, 再设计 Agent 内部逻辑——而不是反过来 主线二 防失控先于智能:步数上限、动作白名单、成本熔断、 人在回路——先装好刹车,再踩油门(第 13/15 章) 主线三 人在回路渐进放权:影子模式(只决策不执行)→ 审批模式 → 受限自动 → 按指标逐步放权(15.6 SOP)1.8.3 学习地图第一篇(1-3) 认知:边界 → 范式 → 抽象 [全员必读] 第二篇(4-6) 行动:Tool → MCP → 决策控制 [Agent 的双手] 第三篇(7-9) 状态:状态 → 记忆 → 上下文工程 [Agent 的大脑] 第四篇(10-12)编排:多 Agent → 流式模式 → 湖仓 [Agent 的组织] 第五篇(13-15)工程:可靠性 → 观测 → 安全合规 [Agent 的刹车] 第六篇(16-18)实战:自愈 → 巡检 → Copilot [总装]1.9 本章小结与下章预告本章小结┌──────────────────────────────────────────────────────────────┐ │ 第 1 章 要点回顾 │ └──────────────────────────────────────────────────────────────┘ ✓ 边界:ML_PREDICT 无记忆/无动作/无多步/无闭环; 理解到行动的鸿沟 Agent 的战场 ✓ 范式:感知-决策-行动-验证循环;LLM 从问答机变为 推理引擎;ReAct 思考-行动-观察交替链 ✓ 流式四理由:事件驱动天然形态 / 状态承载记忆 / 与数据流同构零搬运 / Flink 工程能力全继承 ✓ 定位:Flink 运行时之上的事件驱动 Agent 框架; 不替代 ML_PREDICT,而是编排它 ✓ 选型:批式框架做原型快,流式原生做生产稳; 形态匹配优于功能比较 ✓ 关系:前作全部能力降级为 Agent 的原子与工具; 两条系列合成完整实时智能版图 ✓ 主线:事件驱动优先 / 防失控先于智能 / 人在回路渐进放权下章预告第 2 章 环境准备与第一个流式 Agent动手开始——Flink 2.3 Flink Agents 0.3.x 环境搭建与依赖管理、复用内网 LLM 网关的模型接入、30 分钟跑通Kafka 告警事件 → Agent 诊断 → 输出处置动作全链路、Java API 开发入口、jar 进 lib 与密钥注入等工程规范延续以及决策过程日志与事件追踪的调试技巧。官方参考资料Apache Flink 2.3 Documentation首页Flink 2.1 发布公告ML_PREDICT / Model DDL 能力介绍Flink 2.2 发布公告Table API 推理与 VECTOR_SEARCH 增强Flink Agents 为新孵化子项目官方仓库与文档入口将在第 2 章环境准备中给出编写时以官方最新发布为准。本章关键概念速查概念一句话详解章节单点推理边界无记忆/无动作/无多步/无闭环1.1Agent 循环感知-决策-行动-验证1.2ReActThought→Action→Observation 交替1.2.3 / 第 6 章Event / Action / Tool / Memory四大核心抽象1.6 / 第 3 章流式四理由事件驱动/状态/同构/继承1.3选型结论原型用批式生产上流式1.5三条主线事件驱动/防失控/渐进放权1.8.2