一个新选手进入了 Java Agent 竞技场

2026 年 7 月，阿里巴巴正式发布了 AgentScope Java 2.0 GA。经过 5 个 RC 版本迭代，这个框架从实验性项目升级为生产级 Agent 框架。

但它不是 Spring AI Alibaba Graph 的替代品——它是同一个公司开源的另一条路径。

这让我重新思考一个问题：当阿里同时维护两个 Java Agent 框架时，它们到底在解决什么不同的问题？

AgentScope Java 2.0 的核心设计：Harness 优先

AgentScope 2.0 的核心思路可以用一句话概括：

在 ReActAgent 推理内核基础上，增加 Harness 工程化层。

“Harness”这个词很关键。它来自 Claude Code 的设计理念——Agent 不只是”推理 + 工具调用”，还需要一套工程基础设施来支撑它在企业环境里运行。

AgentScope 2.0 内置了 6 个 Harness 组件：

组件 解决什么问题
Workspace Agent 的文件工作空间，隔离不同 Agent 的文件操作
Persistent Memory 跨 Session 的长期记忆，不只是对话上下文
Session 会话管理，支持暂停、恢复、重试
Sandbox 代码执行沙箱，限制 Agent 的 blast radius
Skill 可复用的技能模块，按需加载而非全部注入
Subagent 子 Agent 管理，支持层级编排

关键判断：这些组件不是”功能”，而是”工程约束”。它们解决的不是”Agent 能不能做”，而是”Agent 放进生产环境后能不能活”。

Spring AI Alibaba Graph 的设计：编排优先

Spring AI Alibaba Graph 走的是另一条路。它的核心不是 Harness，而是编排模式：

  • SequentialAgent — 顺序执行
  • ParallelAgent — 并行执行
  • RoutingAgent — 条件路由
  • LoopAgent — 循环迭代
  • Supervisor — 主 Agent 协调子 Agent

Graph 解决的问题是：多个 Agent 怎么协作完成任务。

它假设每个 Agent 已经是一个可运行的单元，关注的是 Agent 之间的流程编排，而不是单个 Agent 在生产环境的工程支撑。

两条路的根本差异

维度 AgentScope Java 2.0 Spring AI Alibaba Graph
核心抽象 Harness（工程基础设施） Graph（编排模式）
解决的问题 单个 Agent 如何在生产环境运行 多个 Agent 如何协作
Agent 内核 ReActAgent 继承 Spring AI ChatClient
记忆模型 内置持久化记忆 + Session 依赖 Spring AI MemoryAdvisor
沙箱 内置 Sandbox 需自行实现
技能系统 内置 Skill 机制 依赖 Spring AI ToolCalling
生态绑定 独立框架，支持多语言 深度绑定 Spring 生态
学习曲线 中等（需要理解 Harness 概念） 低（Spring 开发者上手快）

这不意味着谁更好——它们解决的是不同层次的问题。

一个真实场景的对比

假设你要构建一个”代码审查 Agent”——读取 PR diff、分析代码、调用 SonarQube、给出审查意见。

用 AgentScope Java 2.0

1
2
3
4
5
6
Workspace → 隔离 PR 文件，防止 Agent 误操作系统文件
Sandbox → Agent 执行代码分析命令在沙箱内
Persistent Memory → 记住这个仓库的历史审查模式
Session → 支持审查到一半暂停，开发者回复后继续
Skill → 加载"Java 代码审查规则"技能模块
Subagent → 主 Agent 把测试覆盖分析交给子 Agent

用 Spring AI Alibaba Graph

1
2
3
4
5
6
7
8
9
10
11
SequentialAgent:
  1. FetchPRDiffAgent → 获取 diff
  2. AnalyzeCodeAgent → 分析代码
  3. CallSonarQubeAgent → 调用 SonarQube
  4. GenerateReviewAgent → 生成审查意见

如果需要并行：
ParallelAgent:
  - AnalyzeCodeAgent
  - CallSonarQubeAgent
→ 聚合结果 → GenerateReviewAgent

区别很清楚：AgentScope 解决的是”这个 Agent 在生产环境怎么安全地跑起来”，Graph 解决的是”这几个 Agent 怎么协作完成任务”。

为什么阿里同时维护两个框架？

我认为有三个原因：

1. 场景不同

  • AgentScope：面向”重 Agent”场景——Agent 需要长时间运行、操作文件系统、执行代码、管理状态。典型场景：编码助手、运维 Agent、数据分析 Agent。
  • Graph：面向”轻 Agent + 重编排”场景——多个 Agent 各做各的事，重点是流程怎么走。典型场景：客服分发、文档处理流水线、多模型投票。

2. 语言策略不同

  • AgentScope：多语言实现（Python / Java / TypeScript / Go 开发中），不绑定 Spring。
  • Graph：Spring 生态专属，深度集成 Spring Cloud Alibaba 微服务治理。

3. 工程哲学不同

  • AgentScope 的 Harness 哲学来自 Claude Code：Agent 是一个需要工程约束的系统进程，必须有沙箱、权限、隔离、审计。
  • Graph 的编排哲学来自 Spring：Agent 是 Spring Bean 的一种，通过依赖注入和配置就能组合。

对你的选型建议

你当前在学习 Spring AI + Spring AI Alibaba。我的建议：

1. 优先学 Graph

因为你的技术栈是 Spring 全家桶，Graph 的学习成本最低，且已经能解决 80% 的多 Agent 编排需求。

2. 用 AgentScope 的概念来检验你的设计

即使你不用 AgentScope 写代码，它的 6 个 Harness 组件是一个很好的检查清单：

  • 你的 Agent 有 Workspace 隔离吗？
  • 你的 Agent 记忆是持久化的还是每次重启丢失？
  • 你的 Agent 执行代码在沙箱里吗？
  • 你的 Agent 技能是按需加载还是全部塞进 system prompt？

如果这 4 个问题的答案都是”没有”，那你的 Agent 还是 demo 阶段。

3. 关注 AgentScope 的 Skill 机制

AgentScope 2.0 的 Skill 机制和 Spring AI Agent Utils（2026-07-18 发布的 incubating 库）使用了相似的”渐进式披露”设计：

  • system prompt 里只放技能名称和描述
  • 模型需要时再 read_skill 加载完整内容
  • 这直接解决了”100 个工具塞进 prompt 导致 token 爆掉”的问题

这和我在 Spring AI 2.0 ToolSearch 实战 里讨论的问题是同一个。

更新已有判断

在之前的文章里，我写过：

“Spring AI Alibaba Graph 是 Java 生态解决多 Agent 编排的答案。”

这个判断需要补充：

Spring AI Alibaba Graph 解决的是”编排”问题，AgentScope Java 2.0 解决的是”工程化”问题。生产级 Agent 需要两者结合——Graph 管 Agent 之间怎么协作，Harness 管单个 Agent 怎么在生产环境安全运行。

未来会怎样

  1. Harness 概念会标准化。AgentScope 不是第一个提出 Harness 的（Claude Code 早就在用），但它是第一个把 Harness 作为框架级抽象的 Java 实现。预计 Spring AI 生态会在 2.1 或 2.2 中引入类似的工程化抽象。

  2. 两个框架会逐渐融合。AgentScope 已经支持 Spring 集成，Graph 也需要 Harness 能力。长期来看，它们可能合并或形成互补生态。

  3. **选型标准会从”功能对比”转向”工程成熟度对比”**。当所有框架都能做 ReAct、ToolCalling、Multi-Agent 时，真正的差异化在于：你的 Agent 在生产环境跑了 7 天后，还能不能安全地继续跑。

参考链接