相信一直关注 Apache Flink 生态的朋友，最近都注意到了 Flink Agents 引发的热议。这是一个全新的Apache Flink子项目，旨在提供一个开源的Agent框架，用于构建事件驱动的流式 Agent。
最近，Flink Agents 发布了 0.2.1 版本，并展示了一个基于该框架构建的 Flink 作业智能运维 Agent，充分展现了其在事件驱动领域的潜力。但更令人兴奋的是，社区已经启动了 0.3 版本的规划讨论，其中涉及的不少功能让我倍感期待。
为此，我深入研究了 github 上的讨论、issues 和 PRs，整理了 0.3 的Roadmap，希望能帮助感兴趣的开发者了解发展方向并参与其中。
Roadmap
根据社区讨论，Code Freeze日期为2026年5月31日，预期发布时间为6月15日。尽管实际的发布时间可能会有所调整，但目前规划中的关键特性包括：
Agent Skills 集成
基于 Mem0 的长期记忆后端
支持事件日志按类型配置日志级别
支持工具调用的参数注入
支持跨语言 Action & Events
Quickstart 体验增强
优化事件日志显示
支持跨语言资源的异步执行
Durable Excution增强
支持 Python 3.12
部分功能不只是停留在讨论阶段，已经有社区贡献者提交设计方案或者代码实现：
事件日志分级和 Quickstart 体验增强的设计提案已多轮讨论并达成共识。
Agent Skills 集成和Mem0 集成的设计提案已提交，正在讨论中。
跨语言 Action & Events 中的 Event 部分已通过 PR 提交。
Python 3.12 支持已完成。
为何我对这些功能充满期待
列表虽长，我对于其中的几个功能尤为关注。
Agent Skills 集成
Agent Skills 作为一种轻量级开放格式，旨在用专业知识和工作流扩展 AI Agent 能力，正被越来越多的产品采纳。以 OpenClaw 为例，我相信很多人都已经尝试过“养小龙虾”。在我看来，OpenClaw能够取得如此成功的一个重要原因就是对 Agent Skills 的支持。一方面，Skills 让工作流更稳定高效；另一方面，用户可以轻松获取组织内或互联网上提供的Skills，从而扩展自己的Agent的能力。
如果你看过 Flink Agents 最近发布的Flink作业智能运维 Demo，会发现其概念与 Agent Skills 惊人相似：利用 LLM 生成问题描述，从向量库检索 SOP，再按照SOP执行操作。这本质上和LLM 基于上下文识别关联Skill并根据Skill执行是类似的。但相比 RAG，Agent Skills更轻量。在Flink 0.3 发布后，我想感兴趣的开发者可以利用Agent Skills 重构该 Demo。
社区已发布集成提案：https://github.com/apache/flink-agents/discussions/565。目前看来，其渐进式披露机制的实现与其他框架类似。真正的区别在于 Flink Agents 作为基于 Flink 的分布式框架，如何支持在 yarn 或 k8s 集群中提供和分发 Skills，是一个值得深思的工程挑战。
Mem0 长期记忆后端
长期记忆是 Agent 上下文管理的关键，尤其是对于 7 * 24小时连续运行、不断消费事件的 Agent，而这正式Flink Agents的目标场景。在0.2 版本中，Flink Agents已原生支持长期记忆及一个粗糙的自动压缩机制。
实际上，这个功能正是我开发的。在实现过程中我意识到，长期记忆管理（尤其是压缩）极其复杂。在 Flink Agents内从零构建成熟方案挑战巨大。此外，流式Agent 和对话Agent对长期记忆管理的需求差异不大。因此，我调研了其他Agent框架的实现，以及一些专门的记忆管理框架，最终选择了 Mem0。
Mem0是专为 AI Agent 设计的智能记忆层。通过支持 Mem0 作为后端，我们可以基于开源生态，提供更成熟易用的记忆管理能力，避免重复造轮子。
持久执行增强
基于 Flink 构建，Flink Agents 的天然优势就是容错。Flink基于 Chandy-Lamport 算法实现了检查点机制，允许从 Checkpoint 恢复而无需从头重新消费数据。
但问题在于对Agent而言，仅靠Checkpoint恢复不够。从Checkpoint恢复，会导致该Checkpoint后已经处理过的事件被重新消费，由于 Agent 频繁调用外部模型和执行动作，这可能造成重复调用和重复执行动作。LLM 调用成本高，重复执行操作可能有副作用。因此，Flink Agents一直在容错上进行增强：
0.1 引入了 Action 粒度的一致性，利用 Action Store 避免恢复时重放已执行的Action。
0.2 提供了Durable Execution接口。用户可利用该接口提交代码片段，框架会记录代码片段的返回结果。恢复时若片段已执行完毕则无需重跑，进一步缩小了不一致范围。
但是问题仍然是存在的，若代码片段在恢复前已开始执行但尚未完成，恢复后仍会被重新执行。由于代码片段可能涉及和外部系统的交互，如调用LLM服务、读写向量数据库，仅靠 Flink Agents 无法保证端到端精确一次（Exactly-Once）语义。这与 Flink Sink 是类似的：系统内保证精确一次语义，端到端一致性依赖下游外部系统支持幂等或两阶段提交。
Flink Agents 要如何解决这一问题？这仍是开放问题，但一种可能方案是提供 Hook 或回调 API。这将赋予用户根据业务场景自定义逻辑的能力。例如，若外部服务支持幂等，可配置直接重试；或先查询状态再决定。通过这种灵活性，Flink Agents 能更好适应真实世界的可靠性需求。
事件日志增强
可观测性对生产级产品至关重要，排查过线上故障的朋友对此应该深有体会。对 Agent 框架而言，由于 LLM 的不确定性，可观测性尤为重要。
Flink Agents 基于事件进行Agent的编排，并支持生成事件日志和在Flink Web UI中展示。通过日志，用户可深入了解Agent的执行过程。根据我排查 Flink Agents 问题的经验，事件日志确实很有帮助。在最近发布的Flink作业智能运维 Demo 中，你也可以看到日志如何帮助我们确认 Agent 行为。
但要真正生产就绪，我认为需继续提升事件日志的易用性。0.3 计划了几项关键增强：
日志可读性：当前日志格式对人不够友好，0.3 将支持格式配置。
可配置日志级别：对于复杂 Agent，用户可能只关心部分事件。0.3 将支持按事件类型配置日志级别，灵活满足需求。
结构化查询：随着 Agent 持续运行，日志不断累积。支持结构化查询将帮助用户更高效定位信息。
我对Flink Agents的 0.3 版本充满期待。因为这不仅仅是功能的新增，更是意味着通过整合这些能力，我们有机会打造一个真正生产级的事件驱动的流式Agent 框架。
附录
文档网站: https://nightlies.apache.org/flink/flink-agents-docs-latest/docs/get-started/overview/
Github仓库: https://github.com/apache/flink-agents
用户 Slack 频道 #flink-agents-user 和开发者 Slack 频道 #flink-agents-dev
