Atmosphere：把 JVM 里的 AI 智能体当成实时服务来跑

一个 @Agent 类，十二种运行时，问题出在哪

AI 智能体框架的碎片化是现实问题。Spring AI、LangChain4j、Anthropic 各自有不同的流式接口、工具调用约定和会话管理方式。团队一旦选定某个框架，后续切换的成本几乎等于重写端点。Atmosphere 的回应是把运行时抽象成一个名为 AgentRuntime 的 SPI，并提供 12 个适配器。文档强调这些适配器带有契约测试的能力标志，意思是每个适配器声明自己支持哪些特性，而不是假装全部一致。这种设计承认了框架间的差异，但代价是适配器质量参差时，你的代码可能跑在能力子集上。对于只想写一个 @Agent 类然后在多个框架间移植的开发者，这个抽象有价值，但前提是你愿意信任那套契约测试的覆盖范围。

数据流：从 LLM 令牌到客户端，中间有一道闸门

Atmosphere 的核心不是模型调用，而是把令牌流从 LLM 运行时送到客户端的那条广播管道。README 说这条管道可以被过滤、门控和观察，传输层默认支持 WebSocket、SSE、长轮询，gRPC 也可用，WebTransport/HTTP3 则是可选。关键机制在于治理点被放在关键路径上：策略准入、@AgentScope、计划验证、PII 改写、成本上限、人工审批，这些都在工具调用发生之前执行。这意味着每个工具调用不是直接触发，而是先经过策略检查。这种设计把治理从应用逻辑中抽离，但引入了额外延迟，对于低延迟敏感的场景需要评估。会话层支持持久化、运行 ID、回放缓冲和检查点，配合可选的 session tape 模块，可以把会话边界事件记录到 SQLite，之后无需模型调用即可重建运行过程。

快速上手：一条命令跑样例，一条命令建项目

安装和启动的路径很直接。macOS 用户可以用 brew install Atmosphere/tap/atmosphere，其他环境用 curl 脚本安装。然后运行 atmosphere run spring-boot-multi-agent-startup-team 就能启动一个样例。创建新应用的命令是 atmosphere new my-agent --template ai-chat，进入目录后用 LLM_API_KEY=your-key ./mvnw spring-boot:run 启动。这里的关键是 CLI 支持 --runtime 参数来切换适配器，比如 --runtime spring-ai 会生成针对 Spring AI 适配器的项目骨架，CLI 通过覆盖层注入对应的 Maven 依赖。对于不想手动配置多个依赖的开发者，这个脚手架省事，但要注意它依赖 Maven Wrapper，如果项目本身用 Gradle 可能需要额外调整。

治理与人工审批：不是事后审计，而是事前拦截

大多数 AI 框架把工具调用当作普通函数执行，治理往往靠外围的日志和监控。Atmosphere 把策略准入放到工具调用之前，意味着每个请求都要经过一道检查。文档提到 durable HITL 审批，它会持久化等待状态，不占用线程，工作流状态可以保存，之后通过 REST 接口恢复。这种设计适合需要人工确认才能执行敏感操作的场景，比如转账或删除数据。但代价是引入了额外的状态管理，你需要理解审批的生命周期。另一个治理特性是成本上限和 PII 改写，这些在流式传输中实现起来比普通请求更复杂，因为令牌是分块到达的，改写必须在流中实时进行。文档没有给出具体的配置键，实际使用时需要查阅 governance 参考文档。

协议出口：MCP、A2A、AG-UI，以及聊天平台适配

同一个 @Agent 可以暴露到多种协议，这是 Atmosphere 的一个卖点。MCP 支持分两个版本：无状态的 RC 基于 2026-07-28 规范，会话版本回溯到 2024-11-05。这意味着如果你的客户端使用旧版 MCP 会话机制，Atmosphere 也能兼容，但你需要明确自己用的是哪个版本。A2A 和 AG-UI 是另外两个协议，分别面向 agent 间通信和用户界面交互。此外还有 Slack、Telegram、Discord、WhatsApp、Messenger 的通道适配器。这个列表覆盖面广，但每个适配器的成熟度可能不同，文档没有详细说明各通道的特性差异。如果你的需求只是内部工具，不一定需要这些外部通道，反而会增加依赖体积。

边界与陷阱：它不是一个托管平台，也不是 serverless

README 明确说 Atmosphere 是实时事件驱动框架，不是智能体托管平台。它不提供计算调度，你需要自己选 Tomcat、Jetty、Netty、Undertow、Quarkus 或 Spring Boot 作为宿主。这意味着部署、扩缩容、故障恢复都由你负责。另一个边界是代码执行，它提供 SandboxProvider SPI，默认实现是 DockerSandboxProvider，但浏览器自动化和 headless Chromium 不在范围内。对于需要沙箱执行代码的场景，你要自己准备 Docker 环境。更重要的适用性边界是：对于无状态、突发性、空闲时应休眠的自主智能体，Atmosphere 不是合适选择，文档直接建议这类场景用 serverless 平台。如果你没有长连接需求，只是偶尔调用一次 LLM，引入 WebSocket 和会话持久化是过度设计。

替代方案与取舍：LangChain4j 或 Spring AI 原生方案

不采用 Atmosphere 的替代路线是直接使用某个 AI 框架的原生能力。比如 Spring AI 本身提供 ChatClient 和流式 API，LangChain4j 也有自己的工具调用和内存管理。区别在于：这些框架不包含实时传输层，你需要自己用 Spring WebSocket 或 Netty 搭建流式端点；它们也没有内置的 MCP、A2A 适配器，需要额外集成。Atmosphere 的价值是把传输、运行时适配和协议出口打包成一个 SPI，省去集成工作。但代价是引入了一层抽象，当你需要调试底层流式行为时，可能要多绕一层。另一个替代是使用托管平台如 Cloudflare Agents 或 AWS Bedrock Agents，它们提供完整的托管体验，但把你锁在特定云生态中，而且不解决 JVM 内嵌的问题。如果你的团队已经深度使用 Spring AI，并且需求简单，原生方案可能更轻。

维护与升级成本：版本节奏快，MCP 兼容性要盯紧

从发布记录看，Atmosphere 的版本更新很频繁，4.0.68 到 4.0.70 在十天内连续发布。这种节奏意味着修复和新特性不断，但也带来升级负担。每次升级需要检查适配器行为是否变化，尤其是 MCP 协议支持跨越两个规范版本，行为差异可能影响客户端。许可方面，项目采用 Apache-2.0，这对商业使用相对宽松，不需要开源你的衍生代码。但注意，它依赖的底层框架（如 Spring AI、LangChain4j）各自有许可，你需要自行确认。维护成本主要来自三方面：一是宿主容器版本与 Atmosphere 的兼容性，二是持久化模块（SQLite 或 Redis）的运维，三是如果使用 Temporal 后端，需要额外的部署组件。对于小团队，这些运维负担可能比想象中重。

编辑结论

适合采用 Atmosphere 的团队是那些已经运行在 JVM 上、需要把 AI 智能体暴露为实时交互服务、并且要求每个工具调用前都有策略检查和人工审批入口的开发者。它把传输层、运行时适配、协议出口和治理集中到一个 SPI 之后，省去自己拼装 WebSocket 与 MCP 的功夫。不适合的团队是那些只需要无状态、突发性、空闲即休眠的自主智能体，这类场景用 serverless 平台更划算。在决定采用前，先验证三件事：第一，你的目标 AI 框架是否在 12 个适配器列表中，并且你需要的特性（如 WebTransport/HTTP3）是否标记为可选且需要额外依赖；第二，治理策略的默认行为是否符合你的合规要求，尤其是 PII 改写和成本上限的配置方式；第三，长期运行的会话是否依赖 SQLite 或 Redis 的持久化模块，以及 Temporal 后端是否在你的运维能力范围内。最后，Atmosphere 的发布节奏很快（4.0.68 到 4.0.70 间隔不到两周），升级前要检查 MCP 协议版本兼容性，因为其 MCP 支持同时覆盖 2026-07-28 的无状态 RC 和 2024-11-05 的会话版本，两者行为不同。

官方来源

1. Atmosphere/atmosphere on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases