德国电信的LMOS：企业AI团队对平台的真实需求

Arun Joseph 在 InfoQ 描述了一个真实的、已投入生产的代理计算层：短暂代理、ADL 以及一个中央功能目录。

简单来说。Arun Joseph在InfoQ的演讲中描述了德国电信的企业AI平台（LMOS）：一个通过一组核心抽象取代“工具泛滥”的层，并引入了带有临时代理的代理定义语言（ADL）。其框架是：代理计算是云提供商未随盒外送的缺失层。

事实

InfoQ于2026年8月3日发布了Arun Joseph关于德国电信LMOS的演讲。三个论点：（1）企业面临LLM/代理工具的失控式泛滥（“工具泛滥”）；（2）它们真正需要的是带有通用抽象的“代理计算”层；（3）LMOS提供了代理定义语言（ADL）和临时代理，而非持久化服务。

我们的解读

Joseph的论点并不新颖——QCon AI波士顿（发布#1211）和Cloudflare Agents Week（发布#1766）都讲述了同一故事的不同版本——但其意义在于它来自一家必须维护数十年业务代码的电信运营商。LMOS是生产环境的实战经验，而非供应商的主题演讲。

该模式对您架构的意义

• 临时而非持久。代理在会话间无状态；状态存在于数据平面（向量数据库、业务数据库、事件日志）。这避免了“长时间运行对话泄露上下文”的陷阱，并便于水平扩展。认知成本：将每次代理调用视为纯函数调用，而非活跃对象。
• ADL作为契约。通过代理消费和生产的内容描述代理，而非传递给它的提示词。两个不同团队可编写可互操作的代理。这正是MCP在内部的真正承诺，且类型更强。
• 核心平台而非工具泛滥。与其让各团队分别接入LangChain或LlamaIndex，不如建立一个共享能力目录，配以可观测性和策略。这是平台工作，而非应用工作。

内部机制

LMOS尚未公开。最接近的开源类比是围绕MCP + 注册中心（Anthropic MCP中心、Cloudflare AI网关、Portkey）涌现的生态。结构性差异：德国电信控制数据平面（电话、计费、内部CRM）——这是美国云无法外包的用例，因此平台内部化是结构性的。

那么呢

对于在“本月代理框架”与“真正平台”之间做抉择的架构师：测试标准如下。若您的代理层无法让您在无需编写Python代码的情况下定义代理，且无需重新部署服务即可部署，那它不是平台，而是SDK。LMOS表明，真正的生产平台更像Airflow而非LangChain。

关注点

LMOS或其组件（ADL）可能开源；发布运营指标（生产中代理数量、延迟、任务成本）；在其他受DMA/数据主权约束的欧洲运营商中采用。