Python只是前戏，JVM才是正餐！Eclipse开源新方案，在K8s上不换栈搞定Agent

　　编辑 | Tina

　　近期，Eclipse 基金会宣布在其开源平台 Eclipse LMOS 中推出“代理定义语言”（ADL）。这是一种结构化、与模型无关的描述方式，允许用户无需编写代码即可定义 AI 行为。

　　据 Eclipse 表示，ADL 将成为智能体计算平台 LMOS 的核心组件。LMOS 这个项目从一开始就瞄准在 Kubernetes / Istio 上原生运行，服务 JVM 生态，旨在用统一、开放的方式重构企业级 AI 代理的开发与运维链路。同时也对标专有平台与以 Python 为主的企业 AI 技术栈；这也意味着对长期主导企业 AI 的闭源替代方案发起正面挑战。

　　值得注意的是，LMOS 这个项目采取“先落地、后开源”的路径：其前身是德国电信在传统云原生架构中的生产级实践，之后才在 Eclipse 基金会中完成孵化。

完整项目开源地址：

https://github.com/eclipse-lmos

　　1 技术收敛：在熟悉的技能栈上做 AI

　　过去十年，企业在云端应用上已形成一套行之有效的工程范式：不再编写单体应用，而是尽量拆分为微服务，让不同团队负责不同部分，并且便于装配组合。同时，将一切打包进容器，方便跨环境迁移和部署；当流量上升时，也能通过复制实例来横向扩展，让多副本共同承载请求与计算。这大致就是当下大家在云上构建应用的常态实践，运行得相当不错。

　　然后，生成式 AI 来了。过去两年，大家似乎总被迫“学习一堆新技能”才能用上新技术。回溯到 2023 年， GitHub 上新框架不断涌现，很多人都在犹豫是否要跟进（当时 Spring AI 尚未出现、LangChain4j 也刚冒头）。但实际上大家的头号挑战始终是：如何提高开发速度，以及如何高效利用现有资源。

　　面对既有的技术生态，特别是对于深耕 JVM 体系的企业来说，实际上没有必要“推倒重来”再组建一支昂贵的新队伍。因此，LMOS 项目的初衷，就是探索如何将 AI 能力尽量贴近我们已经熟悉的技能栈，而不是迫使企业抛弃既有成果，写 Python 脚本、从零再来一套。

　　我们不能丢掉过去十年的经验，再去“组一支新队伍、换一整套新堆栈”

　　LMOS 项目与这些背景相关。该项目由负责人 Arun Joseph 在 2023 年主导设计，当时他负责了德国电信的一个 AI 项目，需要在 10 个欧洲国家上线面向销售与客服的 AI 能力。

　　“我们刚起步的时候，虽然涌现出了一些框架，比如 LangChain，但它们都是用 Python 编写的，”Joseph 解释道，“但和大多数电信公司和企业一样，德国电信的整个企业级技术栈都是基于 JVM 构建的。”

　　另外，抛开语言差异，德电一线业务的复杂度本身就很高：同一套系统要跨多国部署，还需可插拔地接入不同渠道（Web、App、热线等）；同时 API 体系庞杂，客户端库包含数百个属性与多年沉淀的领域知识。若改以 Python 重新起步，等于放弃既有资产，逼迫团队重建系统。

　　而且，要在 10 个国家运营，技术架构必须支持“平台化、集中式”的统一部署与管理。基于这些考量，团队决定在熟悉的生态内演进：采用 Kotlin，复用既有基础设施、API 与 DevOps 能力，搭建多智能体平台。

　　平台以 Kubernetes 为底座，配合 Istio 等组件提供的能力，将“代理 / 工具”以微服务形态部署到 K8s 环境，并通过自定义资源（CRD）提升为一等公民，支持声明式管理与可观测性。

　　通过这种方式，开发者能沿用既有工作流：只需推一个智能体镜像，接下来的操作就能在一个新环境里把它跑起来，独立测试；运维团队可以直接用 kubectl get agents、kubectl apply 去监控与发布。

　　所以，在理念上 Eclipse LMOS 与当下主流 AI 工具生态分道而行了。Joseph 指出，许多“企业级 AI 技术栈”往往是一个 Python 代码库拼接多家风投支持初创的 SDK——各自只解决遥测、记忆、评测等一小块问题——再用一个装饰器（decorator）把整片容器编队塞进基础设施。“我见过某些评测工具，为了一个函数就要 25 个容器，”他说，“也就是说，为了一行代码，让 25 个容器跑一个自定义的 Kubernetes Operator。企业承受不起这样的无序膨胀。”

　　Eclipse LMOS 的方式避免了这些问题：原生融入 Kubernetes、Istio 与基于 JVM 的应用，顺畅对接组织多年建设的 DevOps 流程、可观测性工具与 API 库，让 AI 代理以最低迁移成本进入生产系统。

　　这些平台已支撑德国电信的多项 AI 应用，其中包括多次获奖的客服机器人 Frag Magenta。到 2023 年底，首个代理在德国电信投入生产，并在欧洲加速扩展：覆盖范围从 3–4 个国家增至 10 个国家，上线后月均处理约 450 万次会话；到 2024 年，转人工次数下降 38%。于是这成为欧洲最大规模之一的、真正投入生产的 Agentic 系统。

　　沿用熟悉的技术栈，开发周期也因此得以压缩：“最初做第一个代理（同时还在搭平台）花了一个月；随后在少量工程师参与下把周期降到 15 天；再往后，基本一两天就能把一个代理连同一组用例做出来。”

　　“经过一段时间的度量我们发现，只需一名数据科学家与一名工程师配对，从业务提出想法或问题陈述到将代理部署到生产都能非常快。进入维护阶段后仍可快速迭代，小团队也带来明显的成本优势。我们没有在一开始就纠结于是否提前扩招 AI/ML 工程师或数据科学家——2023、2024 年许多团队都把时间浪费在这类取舍上。”

　　随后，在 2024 年，团队将德国电信内部的专有代码迁移至 Eclipse 基金会开源，项目采用 Apache-2.0 许可证进行发布。

　　2 如何将经典领域的精华融合到一个平台中

　　在将 AI 代理真正推向企业生产环境的过程中，Eclipse 选择了一条“双线策略”。一条线是LMOS 平台（此前已完全开源）。另一条线更具突破性：ADL（Agent Definition Language），“让更多人能真正写出代理”。

　　“我们对当时的框架集体‘不满意’，于是走了‘激进简化’路线：选了 Kotlin 作为主语言，因为它便于我们打造领域专用语言（DSL）——也就是 ADL。”

　　“将业务背景融入人工智能工作流程和应用程序至关重要，这样它们才能大规模地做出高质量的决策，自然语言提示无法进行版本控制或审计——这是企业面临的痛点，也是编程语言存在的原因——所以这种方法可以满足介于两者之间的需求。”

　　这种路线也来自实践中的痛点。在现实的 AI 基础设施里，Agent、提示词（prompts）、工具（tools）层层叠加，复杂度迅速膨胀，同一套模式在不同场景被反复造轮子。更关键的是，系统本质上仍是自然语言驱动——大量的条件、规则与 SOP 需要压在模型之上去执行。有意思的是，市场上已经被这些产品淹没了。单拎出来看，它们都很棒；但拼成一套完整系统就很难彼此“对话”与“粘合”。

　　而且当系统一旦扩大，AI 模型集成会变得极其微妙。模型轻微升级或细节偏差，上层行为就会被牵一发而动全身导致整体脆弱（如下图所示）。

　　所以，这个平台最终凝结为三个彼此独立、又能够协同运作的模块：

　　ADL：结构化、模型无关，支持可视化创作与多角色协作，让业务与工程团队共写代理。。它让业务部门能够像写 SOP 一样定义代理行为，立刻测试、立刻迭代，无需等工程工单排期。与此同时 ADL 仍保持工程严谨性：行为可版本化、可追踪、可维护，这也是它替代传统提示词工程的关键。

　　ARC Agent Framework：基于 JVM/Kotlin，提供 IDE 级开发体验与可视化调试，让工程师专注业务 API 与集成逻辑，而不是搭底层。

　　LMOS 平台层：开放的云原生编排层，用于代理生命周期管理、发现、语义路由和可观测性。它基于 云原生计算基金会（CNCF） 技术栈构建，目前处于 alpha 版本。

　　围绕上述模块，LMOS 还提供了与运行环境紧密集成的控制平面（control plane）：当一个 agent 或 tool 以微服务形态部署到 Kubernetes 后，LMOS Operator 负责生命周期管理。每当新应用安装，Operator 会接收事件通知，抓取其 Description（描述文档），并写入 Kubernetes Registry（当前用作存储机制）；同时 Operator 还提供了来自 Web of Things 的 Directory API 便于发现当前在 Kubernetes 环境中安装了哪些 agents。

　　其中，还值得一提的是 LMOS 协议。

　　考虑到每个代理都有独立生命周期，系统需要一种机制让代理彼此发现并协商通信协议。LMOS 的设计借鉴了 W3C 成熟标准，并从 Matter/Thread 与 Bluesky 的 AT Protocol 等去中心化技术中汲取灵感。其目标在于像互联网连接计算机、物联网连接设备那样，让平台连接跨组织边界的 AI 智能体，实现可发现、可互操作的代理网络。

　　Eclipse 团队回忆，早期他们在没有 MCP 的前提下就把东西做起来了 ：既然熟悉内部 API，就先压缩出一套“收敛版”接口用于函数调用，而不是再搭一台新服务器、引入一堆新概念。他们还在 MCP 之前就实现了“工具注册表”：只需填入工具名即可自动注册，让模型清楚“该用哪个工具”。此后 MCP 走红、Google 又推出 A2A。

　　但这并不意味着 LMOS 这样的路径没有空间——毕竟在“代理大多运行于云、而云标准已成型”的现实里，要把代理与现有云原生栈真正对上齿轮，反而需要像 LMOS 这样贴近工程现场的协议与平台。当然，面对 MCP 与 A2A 标准更新快、落地也快的节奏，这对 Eclipse 基金会而言将是一场硬仗。

　　3 写在最后

　　在生成式 AI 席卷企业软件的当下，技术世界正在形成一条看不见的断层线：一边是敏捷、开源、快速原型迭代的 Python 阵营，主导着创新型初创公司；另一边是庞大而成熟的 JVM 世界，以稳健与可控为前提，承载着大多数企业的关键系统。

　　Eclipse LMOS 站在这条缝隙之间，试图做一件看似朴素、实则颇具野心的事：把 AI 代理带回企业能理解、能运维、能长期托管的基础设施之上。你不需要“推倒重来”、重新组建一支只会写 Python 的团队，也不必在提示词与外部工具间疲于奔命；你完全可以从 Eclipse LMOS 和 ADL 这样的入口出发，再按需把系统复杂度一点点提升到 Kubernetes 等成熟栈之中。

　　“Agentic AI 正在重新定义企业软件，但迄今仍缺乏可真正替代专有产品的开源软件，”Eclipse 基金会执行董事 Mike Milinkovich 曾在一份声明中表示，“借助 Eclipse LMOS 和 ADL，我们正在提供一个强大的开放平台，任何组织都可以据此构建可扩展、智能且透明的代理系统。”

　　LMOS 和 ADL 所做的，是将智能体在你已经信任的技术之上自然生长——这一点，也许正是“代理时代”最值得期待的转折。

　　https://thenewstack.io/eclipse-opens-up-enterprise-ai-agent-development-with-adl/

　　https://www.youtube.com/watch?v=gcpHYtqTBbA

　　https://www.infoq.com/presentations/ai-agents-platform/

　　https://www.youtube.com/watch?v=gHqP5Hx9gbU

　　声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。