agentscope-ai/agentscope-java

如果团队用 Java 构建智能体，且需要它在单次请求结束后继续存活，AgentScope Java 2.0 值得认真评估。不在 JVM 生态里的团队，或只想做单轮简单助手的开发者，可以跳过。

解决什么问题

团队想要一个跨会话持续工作的助手：记得此前的决策，在调用有风险的工具前停下来等人工确认，并把进度实时推到已有产品界面。如果直接从裸 ReAct 循环开始，对话持久化、权限校验、事件传递和上下文压缩都要自己写，而且每做一个新 Agent 就要重写一遍。AgentScope 把这些装进一个 harness：启动时配置一次共享 Builder，每个请求用 build() 创建 Agent，同一身份和持久化存储让对话跨实例延续。得到的是一个可恢复、可观察的 Agent，而不是一次性脚本。

有什么不同

框架通过 Middleware 和 Toolkit 通道在 ReAct 推理核心之上叠加工程设施，推理循环本身不变。README 里比较突出的是两处：32 种类型化事件组成的统一事件流，用于前端实时渲染和人机协同；以及把每次工具调用分为允许、需用户批准、拒绝三档的权限系统。持久记忆分成上下文、Agent 维护的 MEMORY.md 和磁盘事实日志，并通过自动压缩控制提示词体积。另有一套自我进化机制，把成功的模式保存为 Markdown 技能，按需加载。

代价是它更像一个平台而非轻量库。采用意味着接受它的抽象、基于文件的状态布局和部署方式，所以要先判断自己 Agent 的复杂度是否撑得起这份重量。模型提供方是独立扩展模块，选哪个提供方就决定了一个额外依赖，也可能带来该提供方特有的行为。

谁值得试

适合：使用 JDK 17+ 服务的后端团队，需要把 Agent 通过端点接入现有应用，工作流里包含后台任务、交互式审批和可复核交付。独立的 AgentScope Service 和控制面正是为此设计：通过 API 发布能力，而应用保留自己的界面与授权。

不适合：想用 Python 写最小对话 Agent 或轻量脚本的开发者，或只需要一轮推理的场景。框架的分布式、长时间运行定位会带来用不上的概念。已押注其他 Agent 技术栈的团队仍可从事件和权限设计中借鉴，但不要指望它能直接替换。

使用条件与边界

需要 JDK 17 或更高版本。模型提供方以独立 Maven 模块发布，快速开始用的是 DashScope 并要求 API key，所以初始配置除了加一个依赖，还要选好并接通提供方。核心依赖是 2.0.3 版的 agentscope-harness，仓库中的示例版本可能落后于发布版。日常维护意味着要在业务数据之外管理持久化的 Agent 状态、技能文件和记忆文件，并持续审查允许哪些工具调用。

README 只是节选，省略了完整模块列表和生产运维说明，也没有交代集群、状态存储后端或持久状态的升级路径，生产团队应在投入前对照文档确认。按发布说明，v2.0.0 是首个生产可用版本，但这只是项目自己的表述。

HotRepo 点评

HotRepo 在 2026-10-27 记录到 6,136 star，当天 +12，仅有一天出现在每日趋势榜。这只是单日快照，既不能说明走势，也不足以判断热度能否持续。建议回到设计与文档本身：先看权限系统和事件模型文档，确认人机协同需求是否匹配；采用前需核实文档中长时间运行 Agent 的状态存储方案。