AI Agent 开发正在从"写一个调 API 的脚本"进化到"搭一个可编排、可观测、可扩展的运行时"。2026 年,Java 生态里两套 Harness 框架几乎同时交卷——阿里系的 AgentScope Java 和杭州无耳团队的 Solon AI。它们对"马具引擎"的理解截然不同,选哪一套,直接决定你后续的架构走向。
Harness 到底在解决什么问题
Harness 这个词来自马术——马鞍、缰绳、马蹄铁,让骑手能驾驭马匹而不被甩下来。在 Agent 开发里,马是 LLM 和各种外部工具,骑手是你的业务逻辑。没有 Harness,你就是在裸骑:每次调用都要手写 prompt 拼装、工具注册、异常重试、上下文管理,代码很快变成一团意大利面。
一个合格的 Harness 至少要兜住三件事:
- 工具绑定与调度——让 Agent 能声明自己能用哪些工具,并在运行时安全调用
- 对话上下文管理——多轮对话的记忆、截断、摘要,不能靠开发者手动拼 JSON
- 编排与观测——多 Agent 协作时的流程控制、日志追踪、中间状态持久化
AgentScope 和 Solon 都在这三件事上下了功夫,但切入点完全不同。
AgentScope Java:学术基因,重编排
AgentScope 最早是阿里达摩院的 Python 项目,2026 年推出 Java 版本,核心思路是把 Agent 当作可编排的流水线节点。它的架构有三个关键层:
| 层 | 职责 | 特点 |
|---|---|---|
| Agent 抽象层 | 定义 Agent 的生命周期接口 | 每个 Agent 是一个独立的消息处理单元 |
| Pipeline 编排层 | 串联多 Agent 的执行流 | 支持 Sequential、DAG、Loop 三种拓扑 |
| Message 传输层 | Agent 间通信 | 基于 Message 对象,内置序列化与追踪 |
AgentScope 的强项在多 Agent 协作场景。它的 Pipeline 可以声明式地描述 Agent 之间的依赖关系,类似一个轻量版的工作流引擎。代价是:单 Agent 场景下这套编排显得过重,启动成本偏高。
下面是一个用 AgentScope Java 搭建"研究+写作"双 Agent 协作的骨架代码:
// AgentScope Java — 双 Agent 协作示例
// 前置:引入 agentscope-java-sdk 依赖,配置 LLM endpoint
import com.alibaba.agentscope.*;
import com.alibaba.agentscope.pipeline.*;
import com.alibaba.agentscope.agent.*;
// 1. 定义研究 Agent:负责检索与摘要
Agent researcher = ReActAgent.builder()
.name("researcher")
.model("qwen-max")
.tools(List.of(
new WebSearchTool("serpapi", apiKey),
new FileReadTool()
))
.promptTemplate("你是一个研究助手。根据用户问题检索信息,输出结构化摘要。")
.build();
// 2. 定义写作 Agent:基于摘要生成文章
Agent writer = LLMAgent.builder()
.name("writer")
.model("qwen-max")
.promptTemplate("你是一个技术写作助手。基于以下研究摘要,撰写一篇中文技术博客。")
.build();
// 3. 用 Sequential Pipeline 串联:先研究,再写作
Pipeline researchAndWrite = SequentialPipeline.builder()
.agents(List.of(researcher, writer))
.messageTransformer(msg -> {
// 研究结果注入写作 Agent 的输入
return Message.builder()
.content("研究摘要:\n" + msg.getContent())
.build();
})
.build();
// 4. 执行
Message result = researchAndWrite.run(
Message.builder().content("对比 Java Agent 框架的架构差异").build()
);
System.out.println(result.getContent());
这段代码的关键点:ReActAgent 自带"思考-行动-观察"循环,SequentialPipeline 把两个 Agent 的输入输出串联。你只需要关注 messageTransformer 里的数据转换逻辑,编排本身由框架兜底。
Solon AI:轻量基因,重嵌入
Solon 是杭州无耳团队做的轻量 Java 框架,整个 Solon 生态的哲学是"小即是美"。Solon AI 不是独立框架,而是 Solon 体系里的一个插件集,核心思路是把 AI 能力嵌入现有应用,而不是让应用迁入 AI 框架。
它的架构更扁平:
| 模块 | 职责 | 特点 |
|---|---|---|
solon-ai-chat |
LLM 调用与对话管理 | 直接集成到 Solon 的 Controller 体系 |
solon-ai-agent |
Agent 定义与工具绑定 | 用 @Agent 注解声明式配置 |
solon-ai-flow |
多步骤编排 | 基于 Solon 的 Flow 引擎,轻量 DAG |
Solon AI 的强项在单 Agent 快速嵌入。如果你已经有一个 Solon 应用,加一个 Agent 就像加一个 Controller 一样自然。多 Agent 协作也能做,但编排能力比 AgentScope 的 Pipeline 简单,适合"主 Agent + 几个工具 Agent"的模式而非复杂 DAG。
下面是同样的"研究+写作"场景,用 Solon AI 的写法:
// Solon AI — 注解式 Agent 嵌入示例
// 前置:solon-ai-chat、solon-ai-agent 插件已引入
import org.noear.solon.ai.*;
import org.noear.solon.ai.agent.*;
import org.noear.solon.annotation.*;
import org.noear.solon.core.*;
@Controller
public class ResearchWriteController {
// 1. 声明研究 Agent(注解驱动,零配置类)
@Agent(name = "researcher", model = "qwen-max")
private ReActAgent researcher;
// 2. 声明写作 Agent
@Agent(name = "writer", model = "qwen-max")
private LLMAgent writer;
// 3. 在 Controller 里编排——简单直接
@Mapping("/research-write")
public String doResearchWrite(String question) {
// 研究阶段
Message summary = researcher.call(question);
// 写作阶段:把摘要喂给 writer
Message article = writer.call(
"基于以下研究摘要撰写技术博客:\n" + summary.getContent()
);
return article.getContent();
}
}
对比 AgentScope 的版本,Solon 的写法更"Java 原生"——Agent 是注入的 Bean,编排就是方法调用。没有 Pipeline 对象,没有 MessageTransformer,代码量少了一半。但代价是:编排逻辑散落在业务代码里,复杂场景下维护成本会上升。
三个维度的硬对比
架构设计
| 维度 | AgentScope Java | Solon AI |
|---|---|---|
| 核心抽象 | Agent + Pipeline + Message | @Agent + Controller + Flow |
| 编排模型 | 声明式 Pipeline(独立拓扑层) | 过程式编排(业务代码内) |
| 通信机制 | Message 对象 + 内置序列化 | 直接方法调用 + Solon Event |
| 启动成本 | 需初始化 Pipeline 上下文 | 随 Solon 应用启动,无额外成本 |
AgentScope 的 Pipeline 层是独立存在的,你可以把拓扑定义抽成配置文件或 JSON,运行时动态加载。Solon 的编排更像是"你写什么就跑什么",灵活但不容易外部化。
功能覆盖
| 功能 | AgentScope Java | Solon AI |
|---|---|---|
| ReAct 循环 | ✅ 内置 | ✅ 内置 |
| 工具注册 | 声明式 Tool 接口 | @Tool 注解 |
| 多 Agent DAG | ✅ Pipeline 支持 | ✅ Flow 支持(较简单) |
| 分布式 Agent | ✅ 基于 Message Queue | ❌ 单进程为主 |
| 对话记忆 | 内置 Memory 模块 | 内置 ChatMemory |
| 可观测性 | Pipeline 级 Trace | Solon 日志体系 |
| 流式输出 | ✅ | ✅ |
AgentScope 在分布式和可观测性上领先——它的 Message 传输层天然支持跨进程 Agent 通信,Trace 信息随 Message 流动。Solon 目前更偏向单进程场景,分布式需要自己搭消息层。
开发者体验
| 体验维度 | AgentScope Java | Solon AI |
|---|---|---|
| 学习曲线 | 中等(需理解 Pipeline 概念) | 低(注解驱动,Java 开发者直觉) |
| 代码侵入性 | 高(需继承 Agent 抽象) | 低(注解 + 接口) |
| 调试便利度 | Pipeline Trace 可视化 | 标准 Solon 日志 |
| 生态兼容 | 独立 SDK,可接入任意 Java 框架 | 强绑定 Solon 生态 |
| 文档与示例 | 学术风格,偏概念 | 实战风格,偏代码 |
这里有个关键取舍:AgentScope 可以跑在 Spring Boot、Quarkus 乃至纯 Java 项目里,它是独立的 SDK。Solon AI 则深度绑定 Solon 框架——如果你不用 Solon,就用不了 Solon AI。反过来,如果你已经是 Solon 用户,Solon AI 的接入成本几乎为零。
实战选择清单
根据你的项目情况,选择逻辑可以简化为以下决策树:
你的项目已经是 Solon 应用?
├── 是 → Solon AI(零摩擦接入,注解式开发)
└── 否 → 继续判断
├── 需要多 Agent DAG 编排 + 分布式 Agent?
│ ├── 是 → AgentScope Java(Pipeline + MQ 传输)
│ └── 否 → 继续判断
├── 只需要单 Agent + 工具调用?
│ ├── 是 → 两者皆可,Solon AI 更轻量(如果愿意引入 Solon)
│ └── 否 → AgentScope Java(功能覆盖更全)
几个实操建议:
- 先跑最小原型再选框架。用下面这个最小 Solon AI 单 Agent 示例验证你的核心场景,再决定是否需要 Pipeline 级编排:
# solon-ai 最小启动配置 — application.yml
solon.app:
name: ai-demo
mode: plugin # Solon 插件模式启动
solon.ai:
chat:
default-model: qwen-max
default-endpoint: https://dashscope.aliyuncs.com/api/v1
api-key: ${DASHSCOPE_API_KEY} # 建议用环境变量
agent:
tool-scan: true # 自动扫描 @Tool 注解方法
// 最小可运行 Agent — Solon AI
import org.noear.solon.ai.agent.*;
import org.noear.solon.annotation.*;
import org.noear.solon.core.*;
@Agent(name = "helper", model = "qwen-max")
public class HelperAgent {
@Tool(desc = "获取当前时间")
public String currentTime() {
return java.time.Instant.now().toString();
}
@Tool(desc = "计算两个数的和")
public int add(int a, int b) {
return a + b;
}
}
// 启动入口
public class App {
public static void main(String[] args) {
Solon.start(App.class, args);
// Agent 自动注册,直接调用
HelperAgent agent = Solon.context().getBean(HelperAgent.class);
String answer = agent.call("现在是几点?15 加 27 等于多少?");
System.out.println(answer);
}
}
运行前需要:安装 Solon(mvn 或 gradle 引入 solon-ai-agent 插件),设置 DASHSCOPE_API_KEY 环境变量。这段代码展示了 Solon AI 最核心的价值——@Tool 注解让普通方法变成 Agent 工具,@Agent 让类变成智能体,零继承、零配置类。
-
如果场景复杂到需要 DAG,先画流程图再写 Pipeline。AgentScope 的 SequentialPipeline 和 DAGPipeline 各有适用场景,别用 Sequential 硬套本该是 DAG 的流程。一个判断标准:如果任何 Agent 的输出需要被两个以上下游消费,就该用 DAG。
-
分布式 Agent 是架构决策,不是框架功能。AgentScope 的 Message Queue 传输解决了通信问题,但没解决状态一致性和故障恢复。跨进程 Agent 协作前,先想清楚:哪些状态需要持久化?哪个 Agent 挂了整个流程能不能继续?这些问题的答案不在框架里,在你的设计里。
两套框架都在快速迭代。AgentScope Java 正在补齐开发者体验的短板(文档重构、注解支持),Solon AI 正在加强编排能力(Flow 引擎升级、分布式探索)。2026 年下半年的版本可能又会拉开新的差距——但架构基因不会轻易变:AgentScope 始终偏"编排优先",Solon AI 始终偏"嵌入优先"。选基因,比选版本更重要。