云栖实录｜阿里云 Flink + Fluss 年度发布：Streaming Agent 与湖流一体

当 AI 从回答问题走向持续参与业务，挑战就不再只是“能否理解一次输入”，而是逐渐向24小时在线的 Streaming Agent 演进：赛事实时解说需要跟上每一次比分变化，门店实时巡检需要从连续画面中发现异常，实时决策则需要结合最新订单与历史记录作出判断。支撑这些场景，既要让视频、音频、文档等多模态数据在流动中被理解，也要让 Agent 随时获取新鲜、完整且可快速访问的业务上下文。

围绕这两项需求，阿里云实时计算 Flink 通过 Streaming Agent 串联数据接入、模型理解与业务行动，Fluss 则通过湖流一体打通实时状态与历史数据。本文将结合赛事解说、短剧营销、AI 巡店与淘宝闪购等实践，展开介绍这套从持续感知、多模态处理到实时上下文服务的技术路径，探讨数据平台如何从支撑分析，进一步走向支撑 Streaming Agent 的持续运行与行动。

在 AI 时代，传统 Lakehouse 正在向 Agentic Lake 的范式演进。传统的数据使用者主要是人，面向的是表、结构化数据，以及基于这些数据生成的报表和分析结果。随着 Agent 开始更多地使用数据，数据平台需要支撑的任务也发生了变化：Agent 需要理解多模态业务上下文和所处环境，获取最新的上下文数据，并据此作出业务决策。

围绕多模态接入与实时上下文这两项需求，阿里云实时计算 Flink 版发布 Streaming Agent，将持续到达的数据、流式 AI 处理、Agent 编排和业务输出连接起来。它所面向的是持续运行的业务过程：新画面、新文档或新事件到来后，系统及时理解变化、更新上下文，并据此触发后续任务。

入口侧接入视频、图片、音频、OSS 对象变化与 CDC 数据；处理侧提供 60 多种算子，结合异步推理和大小模型协同，并支持 SQL、Python DataFrame、YAML 等开发方式；Flink Agents 支持面向记录的灵活编排，以及长、中、短期三层记忆；输出侧连接 Paimon、Fluss，并通过 Skill、MCP 与外部工具协同。

这种组织方式使数据处理与业务行动能够在同一条持续运行的链路中衔接。例如，赛事事件可以驱动解说生成，摄像头画面可以转化为巡店事件，短剧素材可以在上传后完成分镜、打标与语义检索，多语种内容生产则可以将翻译、语音合成和字幕组织为连续流程。文档处理也可以结合跨页流式解析，让持续更新的内容进入后续理解与检索环节。

Streaming Agent 是这些能力面向业务的整体组织方式，Agentic Streaming 则进一步展开其数据接入、理解、加工与入湖链路。实时计算负责持续推进处理过程，模型提供语义理解与生成能力，湖上资产和上下文则为后续任务提供可复用的数据基础。

Flink CDC 是这条链路中重要的组成部分。它原本是用于实时数据同步的工具，主要捕获数据库变更日志。面向多模态场景，变化捕获的范围进一步扩展为三个新的品类：OSS CDC、Doc CDC 和 Video Stream。

首先是 OSS CDC。对象存储已经成为许多用户存放多模态数据的第一站，因此需要解决如何将 OSS 上的数据更实时地同步到数据湖的问题。OSS CDC 组件能够实时捕获对象的创建、更新、删除和版本变化事件，并将对象引用地址、元信息、时间等信息传递给下游。下游据此读取相应对象，进行理解与加工，再将结果写入数据湖。图片、视频、音频、PDF、DOCX、JSON 等不同文件类型，都可以通过对象变化进入这条处理链路。

其次是文档 CDC，许多知识库建立在钉钉文档、语雀文档、飞书文档等协作平台之上。这里不仅需要捕获新增文档，还需要捕获文档内容的变化。例如，某份文档新增了一段内容，或更新了其中一个段落，可以将发生变化的片段同步给下游。

这样，下游更新知识库时，只需针对变化的内容重新计算 Embedding，而不必对整份文档重新进行向量计算。将更新范围收敛到变化片段，既可以提高知识库更新的实时性，也有助于降低构建和维护成本。

最后是 Video Stream。直播数据流、摄像头数据流以及音频流，都可以通过标准的视频流协议实时接入，包括 HLS、RTMP、RTSP 等视频流协议。在接入过程中，可以完成切片、关键帧抽取、音频抽取等操作，按时间窗口、关键帧或分镜形成后续可处理的事件，再将这些内容沉淀到数据湖。

因此，Flink CDC 的作用不再局限于捕获数据库记录变化，而是对多模态内容变化进行持续感知和实时摄入。数据入湖的过程也可以同时成为数据被理解的过程，后者由 Flink AI 的多模态理解能力进一步完成。

Flink AI 在传统结构化算子之上，提供了三类新的算子能力：多模态算子、AI 算子和 Agent 算子。它们分别对应数据预处理、模型理解，以及更复杂的场景化工作流。

多模态算子主要完成多模态数据的预处理，包括文档解析、编解码、图片尺寸调整（Resize）、格式转换，以及音视频切片、关键帧抽取等操作。这些步骤将不同形态的原始内容转换为适合后续模型处理的输入。

AI 算子将模型能力封装为可编排的算子，通过调用大模型，对数据执行分类、信息抽取、Embedding、摘要等任务。图中还展示了翻译和打标等能力。开发者可以通过 SQL、Python、YAML 等接口组织这些处理步骤，使模型调用成为流式处理链路中的一部分。

Agent 算子则面向更加复杂的业务场景，提供偏场景化的封装。一个算子内部可能涉及多轮大模型调用、上下文获取，以及工具调用，而不只是一次独立推理。当前分享展示的场景化算子包括赛事解说、门店监控，也包括高光新闻、AI 直播等应用。

经过这些算子的处理，多模态数据可以在接入过程中被转化为能够理解的业务数据，形成结构化记录、语义标签、摘要和向量表示，并沉淀到数据湖，供后续检索和探索。数据湖中保存的不只是原始文件，还包括对这些内容理解之后形成的资产。

赛事直播对实时 AI 提出了较高要求：画面不断变化，成绩和名次需要准确对应，解说还必须跟上比赛节奏。在 2026 年名古屋大型赛事中，央视体育与阿里云 Flink 合作打造实时 AI 解说 Agent，围绕游泳、射击等项目，将持续看懂画面、记住比赛前情、及时生成解说组织成一条事件驱动的生产流水线。

这条流水线首先接入直播视频、赛程、参赛名单与官方实时赛事事件。视频经过解析、格式标准化、关键帧采样和时间轴归一后，形成带有时间信息的画面；结构化赛事数据与这些画面进行关联，明确当前比赛、运动员和轮次。观察插件再提取动作变化、比分字幕、成绩图卡等信息，为理解比赛状态提供依据。

仅识别出画面中的数字，还不足以直接播报。理解环节需要结合官方数据、比赛阶段和项目规则，区分历史回放与当前成绩、阶段领先与最终赛果。名次、成绩和奖牌归属以官方确认信息为依据，证据不足时暂不输出确定结论。平均成绩、分差等数值由结构化计算得出，再由模型组织表达，使解说中的判断能够对应具体事实。

Flink 的状态管理用于维护随事件不断更新的比赛上下文，包括当前阶段、逐枪成绩、领先关系和已确认事实。例如，射击比赛可以比较最近五枪与此前五枪的平均成绩，结合排名变化说明选手的追赶过程；游泳比赛则可以持续跟踪出发、转身、交接和触壁，连接分段表现与最终结果。这样的持续记忆，有助于减少重复报分和前后表述不一致。

在输出环节，Agent 根据事件重要性、事实可靠性和可用播出时间安排内容：关键成绩优先，比赛间隙补充规则与选手背景。文稿经过事实与数字校验、内容审核后，再进入语音合成和播出编排，待播内容也需要根据比赛进展撤回或更新。案例中提供了“低音沉稳”“高能爆发”“清亮温和”三种解说风格，并利用直播安全审核的时间窗口组织处理，使 AI 解说与直播画面基本同步。

同一套已确认的赛事事实还可以驱动高光生产。关键得分、反超、淘汰或夺冠事件确认后，高光 Agent 确定视频边界，完成裁剪拼接、封面选择、标题生成和上传。案例中，高光链路可在精彩事件发生后一分钟内完成片段合成与上传，形成供编辑审核发布的成品；这一时效对应高光合成与上传，不包含后续人工审核发布。

连续直播的另一项要求是稳定运行。模型与语音服务调用通过异步处理、并发控制和超时策略减少积压；Flink 检查点为受管理的计算状态提供一致性快照，并配合可恢复的数据源恢复上下文。已经播出的解说和已经上传的高光，还需由执行链路记录动作状态，通过幂等或去重控制重复输出。主备切换、监控告警和人工值班共同保障直播持续运行，也体现了流计算、模型与媒体组件协同进入生产环境的方式。

一个典型客户案例来自短剧营销公司。分享中描述了短剧行业激烈的竞争环境：国内每天有上千部 AI 短剧生产、上传，部分短剧演员也面临失业。在这样的环境中，短剧公司需要通过系统化运营和投流，让自己的内容尽早获得更大曝光。

这一业务有两个关键问题：如何更快地投流，以及如何更准确地投流。短视频流量具有明显的虹吸效应，谁能够更快、更准确地投入内容，就更有机会率先起量。因此，围绕短剧投流，产生了对专门产品和解决方案的需求。

困难在于，一部短剧往往包含上千个切片素材。运营人员需要从这些素材中准确找到高光片段，再将其拼接成适合投流的视频。如何快速、准确地完成筛选、理解与制作，是整条链路的核心挑战。

客户最终采用了 Flink 与 Agentic Lake 结合的解决方案。视频上传到 OSS 后，OSS CDC 立即捕获相应事件，并触发 Flink 对视频进行切片和关键帧抽取。随后，Flink AI 调用 Qwen、ASR 等模型，分别理解视频画面和音轨内容，围绕人物、冲突、剧情等信息提取摘要和标签，再对内容进行 Embedding。

这些信息连同原始视频、分镜片段、结构化语义以及 Embedding 向量，一起保存到 Agentic Lake 的多模态宽表中，由 DLF Paimon 统一存储和管理。运营人员不必逐个回看全部素材，而可以通过 StarRocks，按照所需要的镜头、高光片段或具有冲突性的剧情进行检索。例如，图中以“主角受辱后反转的高光片段”为检索意图，召回“出示证据”“局势反转”等相关镜头。

检索得到的片段再经过后处理与二创，形成可用于投放的视频。图中列出了混剪、解说、剧情压缩等处理方式，可将同一部剧制作成多个版本。投放后的曝光、点击等反馈还可以回流，用于优化后续策略。

按照案例材料给出的可核对口径，采用这套方案后，视频从上传到可被检索可以缩短到 30 分钟以内，为后续二创和投放争取时间。这有助于抢占投流窗口，也降低了运营人员的上手难度。图中将业务价值归纳为更快产出、更低门槛、更高人效，以及通过一剧多投扩大收益机会。

门店摄像头能够记录货架缺货、排队拥堵或现场争端，但录像本身并不能保证问题被及时发现。门店经营需要的是可以处置的事件：哪家店、什么时间、发生了什么、是否仍在持续，以及哪些画面能够支持判断。Flink 视频流处理将持续到达的监控画面转为带时间、状态和证据的事件数据，让监控从事后回放进一步进入日常经营。

空货架与店内争端代表了两类不同的处理模式。对于变化较慢的货架，可以按设定周期低频取帧，检查明显、连续的空位，再结合后续巡检结果确认是否持续缺货。事件处理逻辑可以记录发现、提醒补货和恢复有货的过程，并通过去重减少重复通知。

对于争执、推搡等动态场景，单张图片容易丢失前后过程。Flink 视频算子先识别画面活动，再从开始、持续和结束阶段选取少量具有代表性的关键帧，组成按时间排列的证据交给多模态模型。模型输出“疑似”“需要关注”或“未发现异常”等结构化结果，供现场人员确认与处置；它承担的是风险线索识别，而不是仅凭视频判断责任。

两种模式可以共用同一个视频 Source，在一个 Flink 作业中分成两条处理分支，再汇入统一的大模型调用和事件结果表。摄像头通过 RTSP、RTMP、HTTP/HLS 等协议接入 video-stream connector，开发者使用 Python DataFrame 串联抽帧、活动检测、证据筛选和模型调用，无需为每一项门店分析任务重复拉流。

成本控制的关键在于先筛选证据，再调用模型。一路 25 fps 的视频每天约产生 216 万帧，其中大量画面静止或重复。周期抽帧与动态关键帧筛选可以减少无效输入，Flink AI Function 再通过 llm.predict 将业务要求与多张证据图一同交给模型，并利用异步调用、重试和批量推理组织处理。参考案例在经过优化的端到端测试中，将单路视频的整体运行成本降至每天“1 元级”；这一结果依赖采样频率、活动密度、模型选择及资源配置，不能直接理解为所有场景的固定服务价格。

识别结果最终写入 DLF Paimon 等多模态存储，将事件类型、发生时间、处理状态、证据清单和代表画面关联保存。下游可以围绕同一份事件数据开展告警、时间线查询和历史复盘，并把人工确认与处置结果接回业务流程。例如，经营团队可以关注空位持续时间、补货响应时间，值班人员则可以关注有效提示率和人工确认时间。

随着门店与摄像头数量增加，同一条处理链路可以通过并行度扩展承载更多输入。其价值不仅是降低人工查看录像的负担，还在于把视频中的经营现象沉淀为可查询、可复盘的数据资产，为补货、排班、服务检查和风险处置提供持续的信息依据。

类似能力并不局限于短剧，也可以复制到其他行业场景。前述央视体育案例通过持续接入赛事画面与官方数据，在 2026 年名古屋大型赛事中支持游泳、射击等项目的 AI 解说，体现了持续感知、上下文更新与实时输出之间的协同。

在门店监控场景中，团队与连锁门店品牌合作，实时接入监控视频流，捕获货架缺货等情况，并提醒店员及时补货。这里的价值在于，把原本需要人工持续查看的监控内容，转化为可以及时触发业务处置的事件。

此外，具身智能、保险理赔、直播运营等场景也有相应需求。图中进一步列出了具身与智驾视频自动标注、短剧资产化、门店监控、体育赛事、保险理赔、IT 运维、电商商品审核和直播运营八类应用。其共同方式是，将持续产生的数据、流式处理能力，以及模型、Skill、工具连接起来，完成内容加工、问题识别或后续业务动作。

当多模态处理和 Agent 应用持续运行在 Flink 上，作业开发、故障诊断与日常运维也需要同步升级。作业延迟、反压、Checkpoint 超时和资源利用率往往相互关联，单独查看某一条告警，很难还原完整原因。Flink AI Ops 将智能助手、智能巡检与开放集成连接起来，围绕同一套运行时数据和权限体系，支持从即时排障到持续巡检的运维过程。

智能助手面向用户主动发起的开发与运维需求。它可以关联 Metrics、Logs、Events、Traces 等运行时信息，覆盖集群、实例、作业和算子等层次，并结合专家知识库与模型推理回答问题。用户既可以咨询 Watermark、State、Connector 等概念，也可以围绕具体作业生成或解释 SQL、诊断异常、分析性能并获取资源配置建议。

例如，当作业延迟持续升高、Checkpoint 频繁失败时，助手可以联查反压拓扑、Checkpoint 历史以及 TaskManager 的内存和 CPU 水位，判断是否存在热点 Key 导致的算子负载不均。随后再结合实际瓶颈，提出聚合优化或并行度调整等建议。用户确认执行后，运维链路继续完成配置调整、带状态重启与运行状态检查，使诊断结论能够连接到具体处理动作。

智能巡检则负责持续发现尚未被用户主动提出的问题。系统定期扫描工作空间中的作业，将资源利用率、作业健康、Checkpoint 稳定性、反压与延迟、Connector 和状态管理等检查结果汇总为健康视图，并按风险等级组织待处理项。每个异常项关联原因分析与修复建议，资源分析还可识别过度配置或容量不足，为扩缩容和成本优化提供依据。

智能助手处理临时咨询与应急任务，智能巡检持续观察风险变化，并在设定的目标和授权范围内衔接分析、执行与验证。实际运用中，需要区分自动巡检、诊断建议和自动修复的能力边界；不能将发现风险等同于默认获得修改生产作业的权限。

开放集成让这些能力能够进入企业已有工作流。参考文章介绍了实例生命周期管理、工作空间运维和知识问答三类标准 Skill，分别覆盖资源开通与查询，草稿、部署、作业和诊断管理，以及 SQL 生成、参数推荐和文档检索。通过 OpenAPI 与 Skill 封装，企业 Agent 可以复用这些运维能力，减少重复对接接口和重新组织诊断流程的工作。

这类运维执行还需要参数校验、状态检查、凭证保护和幂等控制。停止作业、删除资源等高影响操作应明确影响并经过确认，重试也不能造成重复变更。由此，AI Ops 不仅帮助用户理解异常，还把运行数据、领域知识与受控操作连接起来，为 Streaming Agent 和实时数据链路的持续运行提供支撑。

多模态解决了 Agent 能够理解哪些信息的问题，实时性则决定了这些信息能否支撑当前行动。Agent 通常需要在多轮“观察—推理—行动”的迭代中完成工作，这一过程对数据提出了三方面要求。

首先是新鲜度。Agent 需要看到数据的最新状态，包括最新订单、用户行为和设备状态，才能基于正在发生的事实作出正确、及时的决策。仅有上一批离线快照，并不足以支撑所有实时业务。

其次是完整度。Agent 不能只看到当前的一个异常点，还需要了解设备在过去一段时间内是否出现过故障、是否存在维修记录。只有把实时状态与历史数据结合起来，才能获得更完整的判断依据，进而推导出合理的决策。

最后是访问速度。在多轮处理过程中，Agent 会频繁点查和检索数据。每一次数据访问都会占用整体任务耗时，因此不能只要求数据足够新、足够全，还必须让这些数据能够快速返回。

这三项要求共同构成 Agent 对数据的“实时上下文”需求。图中用“实时上下文 = 新鲜度 × 完整度 × 访问速度”表达三者缺一不可：任何一项不足，都可能影响 Agent 的行动质量。这里是能力关系的概念表达，而非用于量化计算的性能公式。

阿里云流存储 Fluss 用于解决数据湖实时上下文的问题。它基于 Apache Fluss 构建，提供云上全托管流存储服务，并连接实时计算 Flink、EMR Spark、StarRocks 等主流计算引擎，与阿里云数据湖服务共同形成计算、存储协同的湖流一体解决方案。

所谓湖流一体，是把数据湖和数据流作为一个整体来组织，而不是让两套彼此独立的存储长期各自维护一份完整数据。整体架构分为两层：数据湖作为历史数据层，承载长周期、分钟级及以上时效的数据；Fluss 作为实时数据层，承载短周期、毫秒级延迟的数据需求。

两层数据相互协调，历史数据主要保存在湖中，实时层只保留较短周期的数据，并通过自动分层持续沉淀到历史层。图中展示了远端存储、自动分层，以及湖表格式和 Catalog 生态的连接关系。

这种组织方式的重点，是不必在两套独立系统中长期重复维护全量数据。它有助于减少冗余存储、降低存储成本，也减少两份数据分别维护所带来的管理成本和不一致问题。

其中最关键的读取能力是 Union Read。它自动合并实时层与历史层的数据，协调两层的读取边界，保证逻辑结果不重不漏。对用户而言，外部仍然是一张统一的逻辑表，使用方式与访问一张表没有区别，无须自行理解底层冷热数据的拼接细节。

为了降低湖流一体的使用门槛，阿里云 DLF 数据湖提供了一键“实时加速”的入口。用户找到希望进行实时加速的 DLF 表，打开相应的“湖流一体”开关，即可由 DLF 为这张表关联和管理 Fluss 实时层。

启用之后，用户访问的表及其 Schema 保持不变，既有 SQL 也可以保留。上层查询引擎通过 Union Read，自动合并实时层与历史层数据，从而在保留完整历史的同时，获得秒级新鲜度的数据。

DLF 统一管理 Catalog、Schema、冷热边界与数据分层，因此不需要迁移已有历史数据，也不需要让业务维护两张表、手写 UNION，或改写上层业务 SQL。原有数据湖表在保持查询方式兼容的前提下，增加了面向最新变化的实时访问能力。

在湖流一体升级中，我们特别强调格式兼容、权限同步、批流共用与可回滚，并通过全托管服务提供权限管控、弹性伸缩及多可用区容灾等企业级能力。我们希望在复用存量湖表资产的同时，让实时加速能够纳入既有的数据管理和运维体系。

从多引擎视角看，Fluss 只保存最近一段时间的数据，因此实时层成本可控；完整历史仍保存在 Paimon 中。DLF Catalog 将两层作为统一的存储整体，对外提供同一张逻辑表，并管理读取边界。

Flink 可以从历史数据开始处理，再持续消费最新变化，用于 Agent 上下文的持续更新。图中将这一模式表示为“完整快照 → 后续 Changelog”，使已有背景和不断发生的新事件能够进入同一条流式处理链路。

StarRocks 可以通过交互式 OLAP SQL 查询，将历史与当前数据结合起来，支撑秒级新鲜度的报表和按需分析。Spark 则可以执行批式分析，让批量加工和聚合计算同样包含最新数据，而不必只使用已经完成上一批沉淀的历史快照。

因此，不同引擎可以按照各自的计算方式，读取同一张表中的完整历史与最新变化。对于 Agent 而言，例如用户最近行为与历史偏好，也可以通过统一 SQL 入口共同获得。

除了数据新鲜度，Agent 对上下文点查的时效性也有较高要求。频繁的按 Key 查询如果每次都需要等待较慢的底层读取，会直接拉长多轮任务的完成时间。Fluss 通过湖流一体的点查加速来处理这一问题。

对于热分区，数据全量缓存在 Fluss 的热层中，可从内存或 SSD 返回。对于冷分区，完整数据保存在 Paimon 中，而 Fluss 侧保留部分元数据缓存和数据块缓存，也就是图中的 Chunk-Level Caching。

当请求到来时，如果命中缓存，就直接从 Fluss 的内存或 SSD 低延迟返回；如果没有命中，则从 Paimon 加载相应数据，再回填缓存，为后续访问提供加速。

这样，长周期历史数据仍然保存在存储成本较低的数据湖中，而面向 Agent 提供上下文服务时，又可以通过热数据和数据块缓存获得较低的访问延迟。湖流一体不仅让 Agent 读到新鲜、完整的数据，也增强了数据湖面向在线上下文查询的服务能力。

Fluss 是流存储服务，具有自身的 API 和协议；与此同时，许多企业已经拥有成熟的 Kafka 生产端和日志采集工具。为了复用这些既有链路，分享中介绍了即将提供的 Kafka Producer 兼容能力。

按照这一兼容目标，已有 Kafka 业务应用不必改写业务代码，就可以沿用熟悉的 Producer 接口，将数据投递到 Fluss 服务。图中展示了 Web App、Log Proxy、Logstash、Fluent Bit 等生产端或采集工具。Fluss 对写入的数据进行解析和结构化，将 JSON 消息转换为带 Schema 的 Arrow 实时表，并支持实时消费和在线查询。

随后，同一份数据自动、周期性地分层到 DLF Paimon，供历史分析和长期存储使用。这样，用户可以通过 Kafka 兼容入口，将数据送入 Agentic Lake，而不必额外维护一条从 Kafka 出发、负责 Schema 解析、Schema 演进、Compaction 等复杂入湖处理的独立 Pipeline。

这项能力的价值不只是替换生产端接口，更在于缩短从消息产生到可查询湖表的路径，让熟悉的 Kafka 接入方式与实时表、历史湖表连接起来。需要注意，录音采用的是“即将提供”的表述，本文保留这一分享时点的能力状态，不据此认定其在其他时间点已全面可用。

最后分享一个淘宝闪购的案例，看看湖流一体如何提升业务上下文的时效性。

淘宝闪购的运营看板、订单预估和灰度监控，既要快速感知当前变化，也要参考历史基线。随着业务对实时性的要求提高，原有数据湖链路的延迟逐渐成为瓶颈，因此他们升级到了湖流一体架构。

在新架构中，订单、访问等数据经过 Flink 处理和加工，形成 Fluss 中的实时宽表，再自动分层到 Paimon。通过 Union Read，最新状态和历史数据可以统一读取，为看板、预估和分析提供实时上下文。

这次升级带来了几组具体收益。实时决策所需数据的延迟，从分钟级降到秒级，让决策和活动运营能根据最新业务变化来做出判断。点查 Lookup 的 P99 延迟，从800毫秒降到5毫秒以内。监控场景的 IO 成本降低了约67%。整体的存储规模达到了1.4 PB。

阿里云 Flink + Fluss 两者结合，让 Agentic Lake 不仅能够汇聚和理解多模态数据，还能持续更新与业务现场同步的上下文。从数据接入、感知与理解，到历史沉淀、实时读取与业务行动，形成面向 Agent 的完整数据链路。其价值不止于让 Agent 获取更多数据，更在于让每一次判断都有历史可循、每一次行动都有当下可依，推动智能从“理解数据”走向“持续理解业务”，为 Agent 深入业务流程、创造实际价值奠定基础。

阿里云Flink免费试用：https://www.aliyun.com/product/flink

阿里云Fluss开通试用：https://www.aliyun.com/product/flink/fluss