7 月 14 日，Akka 正式发布了其 Agentic Platform，号称“提供 SDK 与运行时，其中包含创建自主 AI 系统所需要的全部组件：编排、智能体、内存与流式传输”。这标志着 Akka 迈出了从传统分布式计算领域向 AI 驱动型系统转型的关键一步。
作为一款老牌的开源中间件项目，Akka 旨在简化 JVM 上并发与分布式应用程序的构建过程。其软件已经被下载超过十亿次，支撑着全球大约十万个应用程序。并且它在 GitHub 上拥有 13.2k 的星标和超过 3,600 个分支（forks），足见其在开发者社区中的深厚积累和影响力。
然而，Akka 的运营在近年来却面临着不小的挑战。尽管自 2009 年成立以来一直秉持开放友好的 Apache 许可证，但前两年，“公司已经实质上陷入困境”，每年客户流失量接近 30%。因为没有有效的盈利模式，导致该项目运营面临巨大的资金压力。为了维持公司的正常增长和持续发展，Akka 团队在 2022 年还不得不做出一个艰难的决定，将许可证更改为商业源许可证 (BSL)，以此获取必要的资金支持。
尽管 Akka 公司 CEO Tyler Jewell 曾坦言对 AI 和“智能体”的无休止炒作持怀疑态度，但他现在明确表示“我们是时候抛开偏见了”。Akka 正在全力押注代理式 AI，因为他注意到越来越多的客户已经开始使用 Akka 构建代理式系统，并且迫切需要更多相关功能。Jewell 提到，尽管客户长期以来一直呼吁 Akka 提供 AI 功能，但公司官方此前始终保持着谨慎态度。
“如今我们正在扭转乾坤，构建起一套比任何 Langchain 现有技术都更丰富、也更复杂的 AI 功能集。”
简言之，该平台相当于 Langchain 的 Java 应用替代方案；Akka 类似于瑞士军刀，支持高容量代理式 AI 工作流的自动化。Jewell 提到，与其他代理式应用程序构建方案相比，Akka 能够显著降低计算成本。
“这套集成平台可以将 Agentic 系统的开发速度提升 3 倍，计算资源降至三分之一，并满足各类 SLA，无论系统是自主、自适应、实时、事务型还是部署在边缘端。”
其中包含四大核心组件：
Akka Orchestration，用于“引导、调节和控制长期运行的系统”；
Akka Agents，用于“创建智能体、MCP 工具和 HTTP/gRPC API”；
Akka Memory，用于“持久化、内存内及分片数据”；
Akka Streaming，用于流处理等。
这不仅是对 LangChain、Crew.ai、Temporal 和 n8n 等方案的替代，更是对代理式系统架构进行的一次系统性重塑。
<!---->全力押注 Agentic AI 找活路
在2025年QCon的一场演讲中，Akka 团队分享了一个他们最近的发现，“Agentic AI”这个词在 Google 搜索中的热度，在过去四五个月增长了超过 1500%。他们强调，这不仅是一个备受关注的热门词汇，更是一个潜力无限的强大概念。
“我们坚信，Agentic AI 将成为第五次计算浪潮。这是一个你无法忽视的巨大趋势。”Akka 高级总监 Duncan DeVore 如此断言。
<!---->回顾历史，第一次计算浪潮是大型机。随后，我们步入了“小型机”时代，计算机开始联网，最终进入 Web 时代。Duncan 引用了一个著名的例子：微软最初曾将 Web 视为“昙花一现”的风潮，但仅仅六个月后，这家巨头便彻底转型，其变革之迅速和彻底，即便对于微软这样规模的公司而言，也是一次里程碑式的决策。如今，这个历史片段如今正在重演，只不过这一次，是 Agentic AI。
“你可以看到，随着每一波浪潮的推进，用户数量从几千到几百万，再到几亿、几十亿，现在在移动互联网时代已经达到数十亿用户。而我们预测，Agentic AI 时代的用户量级将达到‘万亿’级别。”
这将是一次前所未有的规模挑战，也意味着前所未有的系统复杂度。在这种背景下，传统技术堆栈开始显得力不从心。
“试想一下，在面对万亿用户、每秒百万级事务处理、Agent 分布式并行处理的场景下，你还会用 Python + MySQL 写系统吗？”
他指出，Web 时代的 MySQL 已基本抛弃了关系型理论，采用“扁平化”表结构；而到了移动时代，即使是列式数据库也逐渐力不从心。而在 Agentic 时代，我们将面临十倍乃至百倍于今日的负载与动态复杂度——不只是执行一个操作，而是有五个、十个、十五个 Agent 同时在执行，甚至还会衍生出“子代理”。这一切都需要统一调度与管理。
如今范式转变已至，“Agentic AI 是你无法回避的未来趋势”，所以 Akka 决定将这类技术集成到自己的服务中。
这中间也不可避免的遇到一些挑战。
Agentic 系统，特别是那些偏重推理能力的模型系统，常常伴随着 5-15 秒的显著延迟。这种“代理性循环”要求我们彻底摒弃传统阻塞模式，必须转向非阻塞、能处理高并发的模式。
传统的“分布式应用”多为无状态、单线程的架构，依赖 Kafka 这一类的队列写入数据库，然后通过负载均衡来实现可扩展性。这种架构的弊端明显：一旦某节点负载过高，极易引发级联故障。在面向 Agent 的超大规模系统中，“写入队列 + 写入关系型数据库”的传统方式的旧方法已经走到了尽头，必须从架构层重构整个系统的运行范式。
<!---->Agentic 服务的架构也在发生变化：要么作为独立微服务存在，与 SaaS 系统协同运行；要么两者融合，构成一个统一的联合系统。
另外， Agentic 服务——它是有状态的，能够管理历史上下文，大多数时候会采用事件溯源（event sourcing）机制。这意味着，读取和写入不能走同一通道，因为数据量太大，要避免拥塞。在移动时代，我们还能“勉强凑合”，但在 Agentic 时代，这种方式已经无法满足需求。
值得注意的是，LLM 本身是无状态的，其上下文历史通常由外部基础设施负责保存并传递——一部分在前端界面中，另一部分在与模型交互的后端系统中。随着对话复杂度提升，我们必须每次都上传完整上下文。这就像事件溯源——你记录了 1000 万个事件，每次想得出当前状态时都得重放一遍。为此，系统必须周期性地做状态“快照”（snapshotting）。
Agentic 还必须是双向、异步且支持并发的“流式传输”架构。这类流式能力在大模型时代，要支持文本、音频和视频数据，还必须是开箱即用的，否则就算一开始能“凑合着”跑起来，但很快就会遇到大问题。在实际项目中，一些现成的 LLM 接口（如 Gemini 适配器）因采用阻塞、同步方式，很快就暴露出瓶颈，无法满足实时性需求，最后不得不重写为支持异步双向通信的版本。
随着使用 LLM 的复杂性提高，开发者越来越发现，这其实是一个分布式计算问题。流式双向通信、状态一致性管理、负载动态调度，这些问题不再是数据基础设施团队的专属，而直接进入了应用层的架构范畴。
所以，Agentic 架构需要有五大核心能力：
流式端点（Streaming Endpoints） 架构必须支持双向、异步、并发的数据流。无论是文本、音频还是视频，模型与人之间的交互不再是“请求-响应”，而是“持续交互”。这就要求系统能支持很多复杂的流处理和反压（backpressure）管理。
智能体适配器（Agent Connectivity & Adapters） Agent 需要连接多个异构系统：IoT、数据库、外部 API 等，这些连接必须异步、非阻塞且高可用。开发者不想自己去处理信号量（semaphore）、锁（locks）这些底层复杂逻辑，而是希望用已有的平台自动处理这些。
智能体编排（Agent Orchestration） 能够管理 Agent 流程和执行逻辑，比如 Scatter-Gather（分发-汇总）、路由模式（router pattern）等，平台或工具需要支持这些能力。
内存数据库 + CRDT（冲突自由复制数据结构） 要访问支持冲突解决的数据结构（CRDT）。 平台具备持久性，当某个节点崩溃，可以快速恢复并重新加载数据，在一个节点上读取的数据，换到另一个节点时也要是一致的。
Agent 生命周期管理（Agent Lifecycle Management） 当某个 Agent 崩溃或宕机时，系统应能自动重启它、加载其上下文，或根据情况创建新的子 Agent。这类似于 Actor 模型中的“监督策略（Supervision）”，用于构建真正具备韧性（resilience）的 AI 系统。
因此，这五大能力构成了 Akka 系统的“蓝图”。同时，这也是一种新的架构哲学：从移动应用时代的 N 层架构中解放出来，彻底推倒重建，形成适配 Agentic AI 时代的 A-Tier 架构。
<!---->其 CEO Jewell 对新 Platform 表现得非常开放且自信满满。
“我们的技术栈中有两项让人眼前一亮的功能。”
“一个是内存机制：它是隐式的，就是说内存会自动成为智能体和工作流程中的一部分。我们的所有竞争对手都要求用户单独添加内存，而这会产生很大的编程挑战，特别是难以实现可靠且可扩展。而我们支持自动添加内存。”
“另一大优势在于，我们是唯一一家为代理式框架提供高性能流式传输功能的供应商。就是说如果大家需要接收音频或视频，或者打算获取物联网指标，且希望智能体可以处理这些指标，就必须拥有与智能体并行运作的持续处理引擎……”
那么，难道市面上还没有能够实现这些功能、易于理解且可以轻松应用的开源流式传输引擎吗？
“市面上当然不乏独立的高性能事件流式传输引擎，比如 Flink，它能够支撑起大量消息总线。”
“但 Flink 之类只是独立系统，仅适用于计算。而借助 Akka，我们将智能体编排、内存与流式传输功能集成至同一编程包内。其优势在于，用户能够一站式对所有功能进行编程，且各项功能均使用相同的计算资源。也正因为如此，我们的执行效率才会比 Langchain 高出 70%。”
这是黎明前的最后黑暗……
Akka 近期的发展状态相当不顺。该软件由 Lightbend（即现在的 Akka）作为开源软件项目交付和维护，被广泛用于支持 Java 及 Scala 的弹性消息驱动类应用程序……
Akka 公司由 CTO Jonas Bonér 建立，其产品模型是“在分布式系统的多个核心上进行并发，确保用户服务能够在不同时间及空间的不同位置上成功运行。每天有超过 10 万个系统在生产环境中构建和部署，以 Akka 作为内部运行时的应用程序已经拥有约 20 亿用户。”
但怎样将这款开源软件的高人气转化为商业收入？答案并不简单。
开源应用（包括 Adobe、苹果、亚马逊云科技、Azure、Google Cloud、HPE、特斯拉等）非常广泛，但 Akka 只是整体技术栈中的一枚齿轮，组织往往没有意识到自己正在使用。本质上，Akka 只是企业 IT 栈中功能强大的一环。
他宣称，Akka 的社区参与度很低，而且由于该开源软件本体运行状况良好，所以没办法采取开放核心的盈利模式。
该公司在基础开源元素之外追加销售部分高级附加组件的开放核心模式没能跑通，“到 2021 年，公司已经实质上陷入困境”。他们失去了很多客户，每年客户流失量接近 30%。这一切与竞争对手无关，客户只是单纯降级至免费开源软件，并表示“开源版本已经足够好用”。
客户坦言“这是一款很棒的软件，我们非常喜欢。我们感谢公司的贡献，但如果非得付钱，那我们会另想办法……”
Jewell 补充道，多年来绝大多数上游开源贡献均来自 Lightbend。因此在 2022 年，CTO 兼创始人 Bonér 被迫在 Akka v2.7 中将 Apache 2.0 许可更换成了限制性更强的 BSL v1.1（商业源代码许可证），并开始按核心收费。
Jewell 自豪地宣布，“从那时起，我们迎来了可观的收入增长。去年我们的业绩仍保持盈利，未计利息、税项、折旧及摊销前的利润（EBITDA）与现金流也均为正数。”
“今年早些时候，部分现有客户及潜在客户找到我们，询问我们是否在关注代理式 AI。当时我们的回应是还没太关注，AI 成果更像是玩具、而非基础性工具。”
但客户们强调“不，你们真的应该给予关注。我们试过一些开源代理式框架，比如 Langchain 和 Crew.ai，但它们总出问题……”
“这时候我们才意识到必须行动起来。”
“事实证明，客户至少已经在 Akka 上构建和部署了几十种代理式 AI 系统，其中最大的系统每秒处理近 10 亿个 token——也就是来自印度的线上食品订购与配送平台 Swiggy。”
“代理式 AI 本质上是多个智能体，它们采取某种分布编排形式，且均共享某种状态。我们突然想到，既然代理式 AI 的本质是分布式系统，那不正好跟 Akka 的设计初衷相吻合吗！”Jewell 充满信心地表示，“所以我们做出一个不同寻常的决定，从今年三月开始全力投入代理式 AI 领域，并构建起一整套比 Langchain 现有产品都更加丰富且复杂的 AI 功能集。”
Akka 于 2022 年的许可证变更当然引发了不可避免的结果：开源分叉 Pekko，但后者并未像 Redis 分叉 Valkey 或 Terraform 分叉 OpenTofu 那样获得关注。对于个中原因，Jewell 简单总结称“社区没有投入资金来做功能改进。”
“Akka 发现并解决了一系列关键运行时问题，而 Pekko 没能及时跟上，这影响了其进一步普及。”他还尖锐地指出，“Pekko 过去三年间的提交量比 Akka 少了约 2 万次……”
“三年前，Akka 的大部分（超过 99%）的贡献都来自 Akka（Lightbeng）员工，这是开源社区所无法比拟的。”
“社区正在构建自定义集成与数据存储方案，例如对 MongoDB 的支持，但这些只是他们在自有项目中用过后又免费提供的附加组件。社区本身对 Akka 核心路线图及发展方向的投入不多……”
Jewell 拒绝透露 Akka 目前的运营情况，而且对团队规模三缄其口（只提到「超过 10 人，不到 1000 人」）。此前 Akka 曾在 2023 年进行了一次小规模债务重组，他的公关公司在随后的邮件中补充称 Akka 目前开放 15 个招聘职位，其中包括三个现场 CTO 职位和一个首席 AI 官职位。
参考链接：
https://akka.io/blog/announcing-akkas-agentic-ai-release
https://www.thestack.technology/agentic-ai-convert-akka-looks-to-take-on-langchain/
