Flink Agents 与 AI 流式应用 —— 第 1 章 从实时推理到流式 Agent：AI 应用的下一跳
章节定位：开篇。如果你完成了《Flink 2.3 实时 AI 推理实战》，你已经能让数据流经过 Flink 时被模型理解——分类、归因、检索、生成。但理解之后呢？告警归因给出了处置建议，谁去执行？本章从一个真实的"最后一公里"困境出发，讲清单点推理的能力边界、Agent 范式的本质、为什么 Agent 必须长在流上，以及 Flink Agents 在三方技术选型中的独特位置。本章纯概念，不动手，但它决定你后续 17 章的技术判断力。
版本基线：Apache Flink 2.3.0 + Flink Agents 0.3.x（JDK 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 什么是 Agent
Agent(智能体) = 一个能自主完成任务的循环体: ┌──────────────────────────────────────┐ │ │ ▼ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 感知 │──▶│ 决策 │──▶│ 行动 │──▶│ 验证 │ │ 事件输入 │ │ LLM 推理 │ │ 调用工具 │ │ 结果检查 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ ▲ ┌────┴─────┐ │ 记忆/状态 │ └──────────┘用告警场景走一遍这个循环：
① 感知:P1 电池告警到达 ② 决策:LLM 判断"需先查该车历史故障再定级" ③ 行动:调用工具 query_vehicle_history(vin) ④ 验证:查到 3 次同码历史 → 更新认知 → 再次决策"升级为 P0,建紧急工单" ⑤ 行动:调用 create_ticket(...) → 验证工单创建成功 → 输出闭环报告1.2.2 LLM 的角色转变
单点推理时代:LLM = 问答机(输入文本 → 输出文本) Agent 时代: LLM = 推理引擎(观察 + 记忆 → 决策下一步动作) 关键区别: 问答机的输出是终点; 推理引擎的输出是"动作指令",执行结果会回来继续喂给它1.2.3 ReAct：Agent 决策的经典模式
ReAct = Reasoning + Acting,交替进行: Thought: 压差 187mV 超阈值,但需排除传感器误报 Action: query_cell_voltage(vin, module=3) Observation: 3 号模组 12 节单体电压离散度大 → 真实故障 Thought: 确认真实故障,查历史是否有同型案例 Action: search_similar_cases("单体压差超限 EV-X9") Observation: 命中 3 条工单,2 条通过均衡充电解决 Thought: 证据充分,按多数案例方案处置 Action: create_ticket(level=P1, 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.1 Agent 循环 感知-决策-行动-验证 1.2 ReAct Thought→Action→Observation 交替 1.2.3 / 第 6 章 Event / Action / Tool / Memory 四大核心抽象 1.6 / 第 3 章 流式四理由 事件驱动/状态/同构/继承 1.3 选型结论 原型用批式，生产上流式 1.5 三条主线 事件驱动/防失控/渐进放权 1.8.2
