企业官网建设流程全解析

当 Python 生态的 Agent 框架百花齐放时，Java 开发者手里握着全世界最成熟的企业级技术栈，却找不到一个生产级 Agent 框架。AgentScope Java 2.0 改变了这个局面——它不是又一个 LLM 调用封装，而是把 Agent 当成一个需要工程化治理的生产系统来设计。

一、为什么 Java 生态需要 AgentScope

2026 年 Agent 工程领域最大的范式变化，不是某个新框架发布，而是Harness Engineering（驾驭工程）概念的崛起。

行业标准公式正在变成：

Agent = 大模型 Model + Harness 驾驭系统

• Model：GPT-6 Astra、Claude、DeepSeek 等大模型，只负责推理、生成、思考
• Harness：包裹模型的整套运行控制系统、约束环境、反馈闭环

9 月 11 日 OpenAI 发布 Agents API，本质就是把 Codex 的 Harness 做成了托管服务。但问题是：OpenAI 托管意味着你的会话状态、上下文、执行环境全部交给 OpenAI，数据仅限美国、不支持零数据保留（ZDR）。对于有数据合规要求的中国企业，这不可接受。

AgentScope Java 2.0 给出了另一条路：用 Java 类型系统从头设计 Agent Harness，你自己掌控一切。

与 Spring AI Alibaba 的边界

同一个阿里，出了两个 Java AI 框架，区别不在"谁更好"，而在"范式不同"：

选型建议：想让 Agent 自主规划、调用工具、多 Agent 协同解决开放式问题，选 AgentScope Java；想在现有 Spring 业务流里快速加一段 AI 能力，选 Spring AI Alibaba。两者不是竞争关系，官方规划 AgentScope 的编排能力会下沉到 Spring AI Alibaba，形成互补。

二、核心架构源码分析

2.1 项目分层与包结构

AgentScope Java 2.0 采用核心 + 扩展的分层架构：

agentscope-java/ ├── agentscope-core/ # 核心框架（ReActAgent、Middleware、AgentState） ├── agentscope-harness/ # HarnessAgent、工作区、压缩、子Agent、沙箱、技能 ├── agentscope-extensions/ # 扩展模块（Redis、OSS、MySQL、PostgreSQL） ├── agentscope-admin/ # 开箱即用的 Web 管理平台 ├── agentscope-spring-boot-starter/ # Spring Boot Starter └── agentscope-dependencies-bom/ # 依赖管理 BOM

技术栈选型：Java 17+、Maven 3.9+、Project Reactor 响应式内核、Reactor Context 状态透传、OpenTelemetry 可观测性、GraalVM Native 原生镜像（约 200ms 冷启动）、Apache 2.0 许可证。

2.2 Agent 接口——推理-行动循环的统一抽象

核心入口io.agentscope.core.agent.Agent接口组合了三个能力接口：

// Agent 接口组合了三个能力 public interface Agent extends CallableAgent, StreamableAgent, ObservableAgent { } public interface CallableAgent { Mono<AgentResult> call(List<Message> messages); } public interface StreamableAgent { Flux<AgentEvent> streamEvents(List<Message> messages); } public interface ObservableAgent { Mono<Void> observe(Message message); // 仅添加到上下文，不触发推理 }

最常用的两种调用方式：

// 同步调用，返回最终结果 Mono<AgentResult> result = agent.call(messages); // 流式调用，逐事件产出 Flux<AgentEvent> events = agent.streamEvents(messages);

2.3 ReActAgent——裸引擎的推理循环

ReActAgent是Agent接口的默认实现，是一个推理-行动循环引擎。它的核心流程是经典的 ReAct（Reasoning + Acting）循环：

用户消息 → reasoning（推理） → acting（行动/工具调用） → 结果反馈 → 再 reasoning → ... → 最终回复

源码中关键的中间件拦截点在 reasoning 阶段：

// ReActAgent.java - 模型调用拦截点 Function<Mono<ModelCallInput>, Mono<ModelCallOutput>> modelCallCore = mci -> modelCallStream(context, mci, true); return MiddlewareChain.build( middlewares, // 中间件列表 ReActAgent.this, // Agent 实例 rc, // RuntimeContext MiddlewareBase::onModelCall, // 拦截点：onModelCall modelCallCore // 核心执行函数 ).apply(new ModelCallInput(messages, tools, options, modelForCall()));

ModelCallInput是一个 Java record（不可变但可重建）：

public record ModelCallInput( List<Message> messages, List<ToolSchema> tools, GenerateOptions options, Model model ) {}

核心模型调用使用mci.model().stream(...)：

// ReActAgent.java line 2170 Flux<ModelEvent> modelEvents = mci.model().stream( mci.messages(), mci.tools(), mci.options() )...

关键设计：ModelCallInput是 record（不可变但可重建），MiddlewareBase.onModelCall的默认实现将 input 直接传给 next。如果自定义中间件构造一个新的ModelCallInput、替换其中的Model实例，再传给 next，就能实现per-request 模型切换——这是多模型路由的基础。

2.4 五阶段洋葱中间件

AgentScope Java 2.0 把 1.x 的零散 Hook 重构为五个精准扩展点，形成洋葱模型的中间件链：

public abstract class MiddlewareBase { // 阶段1：Agent 生命周期 public Mono<Void> onAgent(AgentContext ctx, Next next) { return next.proceed(ctx); } // 阶段2：推理阶段（模型调用前） public Mono<ReasoningResult> onReasoning(ReasoningContext ctx, Next next) { return next.proceed(ctx); } // 阶段3：行动阶段（工具执行前） public Mono<ActingResult> onActing(ActingContext ctx, Next next) { return next.proceed(ctx); } // 阶段4：模型调用（最细粒度拦截） public Mono<ModelCallOutput> onModelCall(ModelCallInput input, Next next) { return next.proceed(input); } // 阶段5：工具调用 public Mono<ToolCallResult> onToolCall(ToolCallInput input, Next next) { return next.proceed(input); } }

中间件链构建核心：

public class MiddlewareChain { public static <T, R> Function<T, Mono<R>> build( List<MiddlewareBase> middlewares, Agent agent, RuntimeContext rc, BiFunction<MiddlewareBase, Next, Function<T, Mono<R>>> dispatcher, Function<T, Mono<R>> core ) { // 从后往前构建洋葱：最后注册的中间件最外层 Function<T, Mono<R>> chain = core; for (int i = middlewares.size() - 1; i >= 0; i--) { MiddlewareBase mw = middlewares.get(i); final Function<T, Mono<R>> next = chain; chain = input -> dispatcher.apply(mw, new Next(next, rc)).apply(input); } return chain; } }

2.5 HarnessAgent——组合替代继承的架构决策

HarnessAgent是 2.0 的核心抽象，但看源码你会发现一个反直觉的设计：

// 不是继承！是平级实现 + 内部委托 public class HarnessAgent implements Agent, AutoCloseable { private final ReActAgent delegate; // 内部委托，不是 extends // 不是继承 ReActAgent，而是持有它的实例 // 所有推理逻辑委托给 delegate // 自身只负责装配工程能力 }

Javadoc 说得更直白："HarnessAgent is the user-facing harness API that wraps a ReActAgent with workspace / filesystem / sandbox / subagent / skill / plan-mode / MCP orchestration."

为什么不继承？因为调用方看到的始终是统一的Agent接口——你传一个Agent给上游代码，它不需要关心底下是裸的ReActAgent还是全副武装的HarnessAgent。如果用继承（HarnessAgent extends ReActAgent），就会绑死在ReActAgent的实现细节上——ReActAgent改一个protected方法签名，HarnessAgent就可能断。组合替代继承，在这里不是教科书口号，是架构决策。

2.6 十六个 Harness 中间件

HarnessAgent自身代码很薄——它的核心工作是装配。十六个 harness 中间件各注入一种能力：

2.7 无状态 + Reactor Context 多租户隔离

HarnessAgent是无状态的，Javadoc 明确声明线程安全：

"Thread Safety: HarnessAgent is stateless between calls and safe to use as a singleton serving multiple users and sessions."

两次调用之间不持有可变状态——单例服务多用户，靠RuntimeContext的(userId, sessionId)隔离状态。同 session 串行、异 session 并行（通过serializeOnKey实现）。

这意味着在 Spring 里可以这样用：

@Bean // 单例——服务所有用户 HarnessAgent agent = HarnessAgent.builder() .workspace(Paths.get("./my-agent")) .filesystem(Filesystem.local()) .sandbox(Sandbox.docker()) .build(); // 多用户并发使用——每个调用独立的 (userId, sessionId) agent.call(messages, runtimeContext("userA", "session1")); agent.call(messages, runtimeContext("userB", "session2"));

还实现了AutoCloseable——close()会优雅地关闭任务仓库、工作区索引、沙箱资源。Agent 有完整生命周期：启动、运行、停下、关闭。

三、生产级实战：企业智能客服 Agent

3.1 项目背景

构建一个多租户企业客服 Agent，要求：
- 主客服 Agent 能自主推理、调用工具、派活给子 Agent
- 子 Agent 包括：订单查询 Agent、物流追踪 Agent、退款处理 Agent
- 多租户隔离：不同企业的数据互不可见
- 沙箱执行：危险操作（退款、改单）必须经人工审批
- 会话恢复：Pod 重启后能恢复正在进行的会话

3.2 Maven 依赖

<dependencyManagement> <dependencies> <dependency> <groupId>io.agentscope</groupId> <artifactId>agentscope-dependencies-bom</artifactId> <version>2.0.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- 核心 + Harness --> <dependency> <groupId>io.agentscope</groupId> <artifactId>agentscope-core</artifactId> </dependency> <dependency> <groupId>io.agentscope</groupId> <artifactId>agentscope-harness</artifactId> </dependency> <!-- Redis 会话存储 --> <dependency> <groupId>io.agentscope</groupId> <artifactId>agentscope-extension-redis</artifactId> </dependency> <!-- Spring Boot Starter --> <dependency> <groupId>io.agentscope</groupId> <artifactId>agentscope-spring-boot-starter</artifactId> </dependency> </dependencies>

3.3 工具定义（注解驱动）

@Component public class CustomerServiceTools { private final OrderService orderService; private final LogisticsService logisticsService; private final RefundService refundService; public CustomerServiceTools(OrderService orderService, LogisticsService logisticsService, RefundService refundService) { this.orderService = orderService; this.logisticsService = logisticsService; this.refundService = refundService; } @Tool(description = "根据订单号查询订单状态、金额、商品列表") @Permission(requireApproval = false) // 只读操作无需审批 public OrderInfo queryOrder( @ToolParam("orderId") String orderId, @ToolParam("tenantId") String tenantId // 租户隔离 ) { return orderService.queryByOrderIdAndTenant(orderId, tenantId); } @Tool(description = "根据订单号查询物流追踪信息") @Permission(requireApproval = false) public LogisticsInfo trackLogistics( @ToolParam("orderId") String orderId ) { return logisticsService.trackByOrderId(orderId); } @Tool(description = "发起退款申请，需要人工审批后执行") @Permission( requireApproval = true, // 敏感操作必须 HITL 审批 riskLevel = RiskLevel.HIGH, approver = "customer-service-lead" // 指定审批人 ) public RefundResult initiateRefund( @ToolParam("orderId") String orderId, @ToolParam("reason") String reason, @ToolParam("amount") java.math.BigDecimal amount ) { // 只有审批通过后才会执行到这里 return refundService.processRefund(orderId, reason, amount); } }

Toolkit.registerTool()会反射扫描对象中的@Tool方法，读取注解和参数信息，生成参数 JSON Schema，再把方法包装成ReflectiveFunctionTool，放进工具注册表。

3.4 Agent 构建与配置

@Configuration public class AgentConfig { @Bean public Toolkit customerServiceToolkit(CustomerServiceTools tools) { Toolkit toolkit = new Toolkit(); toolkit.registerTool(tools); return toolkit; } @Bean public AgentStateStore agentStateStore(RedisConnectionFactory factory) { // Redis 后端：支持跨副本会话恢复 return new RedisAgentStateStore(factory.getConnection()); } @Bean public HarnessAgent customerServiceAgent( Toolkit toolkit, AgentStateStore stateStore, Model model, // 通义千问 / DeepSeek / 任意兼容模型 ObjectProvider<SubagentRegistry> subagentRegistry) { return HarnessAgent.builder() .model(model) .toolkit(toolkit) // 工作区：Agent 的人格 + 记忆 + 领域知识 .workspace(Paths.get("./workspace/customer-service")) // 沙箱：Docker 隔离执行 .sandbox(SandboxBuilder.docker() .image("agentscope/agent-runtime:2.0") .memoryLimit("512m") .cpuLimit("1.0") .networkMode(NetworkMode.RESTRICTED) // 限制网络访问 .build()) // 会话状态存储 .stateStore(stateStore) // 子 Agent 注册 .subagents(subagentRegistry.ifAvailable) // 中间件链（顺序敏感！） .middleware(new PermissionMiddleware()) // 最外层：权限守门 .middleware(new SessionRecoveryMiddleware()) // 会话恢复 .middleware(new WorkspaceContextMiddleware()) // 注入 AGENTS.md .middleware(new CompactionMiddleware()) // 上下文溢出应急 .middleware(new ToolResultEvictionMiddleware()) // 清理旧结果 .middleware(new MemoryFlushMiddleware()) // 压缩前持久化 .middleware(new EventForwardingMiddleware()) // 子 Agent 事件转发 .build(); } }

3.5 子 Agent 定义

@Component public class OrderSubagent implements SubagentDefinition { @Override public String getName() { return "order-agent"; } @Override public String getDescription() { return "专门处理订单查询、状态追踪的子 Agent"; } @Override public Agent build(Model sharedModel) { return ReActAgent.builder() // 子 Agent 用裸 ReActAgent，不需要 Harness .model(sharedModel) .toolkit(orderOnlyToolkit()) .maxIterations(5) // 限制迭代次数防失控 .build(); } private Toolkit orderOnlyToolkit() { Toolkit tk = new Toolkit(); tk.registerTool(new OrderQueryTool()); return tk; } }

主 Agent 通过agent_spawn/agent_send原语调用子 Agent，子 Agent 的结果通过EventForwardingMiddleware实时转发事件流。

3.6 Controller 层

@RestController @RequestMapping("/api/agent") public class AgentController { private final HarnessAgent agent; public AgentController(HarnessAgent agent) { this.agent = agent; } @PostMapping("/chat") public Mono<AgentResult> chat( @RequestBody ChatRequest request, @RequestHeader("X-Tenant-Id") String tenantId, @RequestHeader("X-User-Id") String userId) { List<Message> messages = List.of( Message.system("你是企业客服 Agent，当前租户：" + tenantId), Message.user(request.getMessage()) ); RuntimeContext rc = RuntimeContext.builder() .userId(userId) .sessionId(request.getSessionId()) .tenantId(tenantId) .build(); return agent.call(messages, rc) .timeout(Duration.ofSeconds(60)) .onErrorResume(ex -> Mono.just( AgentResult.error("客服 Agent 暂时不可用：" + ex.getMessage()) )); } @PostMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<AgentEvent> stream( @RequestBody ChatRequest request, @RequestHeader("X-Tenant-Id") String tenantId, @RequestHeader("X-User-Id") String userId) { List<Message> messages = List.of(Message.user(request.getMessage())); RuntimeContext rc = RuntimeContext.builder() .userId(userId) .sessionId(request.getSessionId()) .tenantId(tenantId) .build(); return agent.streamEvents(messages, rc) .timeout(Duration.ofSeconds(120)); } }

3.7 审批回调

@RestController @RequestMapping("/api/approval") public class ApprovalController { private final PendingApprovalStore approvalStore; @PostMapping("/pending") public Mono<List<PendingApproval>> listPending( @RequestHeader("X-User-Id") String approverId) { return approvalStore.findByApprover(approverId); } @PostMapping("/{id}/approve") public Mono<Void> approve(@PathVariable String id) { // 审批通过 → PermissionMiddleware 放行 → 工具执行 return approvalStore.approve(id); } @PostMapping("/{id}/reject") public Mono<Void> reject( @PathVariable String id, @RequestParam String reason) { // 审批拒绝 → PermissionMiddleware 中断 → Agent 收到拒绝消息 return approvalStore.reject(id, reason); } }

四、28 种类型化事件流

AgentScope Java 2.0 的核心设计之一是把 Agent 的所有行为抽象为 28 种类型化事件（AgentEvent），给前端和编排器精确、结构化的可见性：

public sealed interface AgentEvent permits AgentStartedEvent, // Agent 启动 ReasoningStartedEvent, // 推理开始 ReasoningCompletedEvent, // 推理完成 ActingStartedEvent, // 行动开始 ToolCallRequestedEvent, // 工具调用请求（审批前） ToolCallApprovedEvent, // 工具调用审批通过 ToolCallRejectedEvent, // 工具调用审批拒绝 ToolCallStartedEvent, // 工具调用开始执行 ToolCallCompletedEvent, // 工具调用完成 ToolCallFailedEvent, // 工具调用失败 SubagentSpawnedEvent, // 子 Agent 创建 SubagentCompletedEvent, // 子 Agent 完成 SubagentFailedEvent, // 子 Agent 失败 ContextCompactedEvent, // 上下文被压缩 MemoryFlushedEvent, // 记忆刷到持久层 SkillLoadedEvent, // 技能加载 SkillCreatedEvent, // 新技能沉淀 PlanEnteredEvent, // 进入计划模式 PlanWrittenEvent, // 计划写入 PlanExitedEvent, // 退出计划模式 SandboxCreatedEvent, // 沙箱创建 SandboxDestroyedEvent, // 沙箱销毁 ApprovalRequestedEvent, // 审批请求发出 SessionRecoveredEvent, // 会话恢复 AgentPausedEvent, // Agent 暂停 AgentResumedEvent, // Agent 恢复 AgentCompletedEvent, // Agent 完成 AgentFailedEvent // Agent 失败 { String sessionId(); Instant timestamp(); }

这不是随意的 JSON 日志——前端可以精确地知道 Agent 在做什么，审计系统可以追踪每一个工具调用的审批链路。

五、生产环境踩坑清单

坑1：中间件顺序写反导致权限检查被绕过

现象：PermissionMiddleware注册在CompactionMiddleware之后，当上下文溢出时CompactionMiddleware先触发压缩，压缩过程中可能触发的工具调用绕过了权限检查。

根因：中间件链是洋葱模型，最外层先执行。PermissionMiddleware必须在最外层（第一个注册），确保任何工具调用都经过权限检查。

解决：

// 正确顺序：权限 → 会话恢复 → 工作区 → 压缩 → ... .middleware(new PermissionMiddleware()) // 第1层：最外层 .middleware(new SessionRecoveryMiddleware()) // 第2层 .middleware(new WorkspaceContextMiddleware()) // 第3层 .middleware(new CompactionMiddleware()) // 第4层

坑2：RuntimeContext 忘记传 tenantId 导致跨租户数据泄漏

现象：Controller 层从 Header 取了tenantId但忘记传进RuntimeContext，工具方法里拿到的tenantId为 null，查到了其他租户的订单。

根因：HarnessAgent无状态，所有状态靠RuntimeContext透传。忘记传就等于没有隔离。

解决：

// 强制校验：自定义 RuntimeContextFactory public class TenantAwareContextFactory { public RuntimeContext create(String userId, String sessionId, String tenantId) { Assert.hasText(tenantId, "tenantId 不能为空"); return RuntimeContext.builder() .userId(userId) .sessionId(sessionId) .tenantId(tenantId) .build(); } }

坑3：子 Agent 无限 spawn 导致资源耗尽

现象：主 Agent 在一个会话中创建了 20+ 个子 Agent，每个子 Agent 又创建自己的子 Agent，Pod 内存溢出。

根因：agent_spawn没有设置并发上限，子 Agent 可以无限递归创建。

解决：

@Bean public HarnessAgent agent(...) { return HarnessAgent.builder() // ... .maxConcurrentSubagents(3) // 全局并发上限 .maxSubagentDepth(2) // 递归深度上限：主→子→孙，不允许更深 .subagentTimeout(Duration.ofMinutes(5)) // 单个子 Agent 超时 .build(); }

坑4：沙箱镜像没做 CPU/内存限制被 Agent 吃光资源

现象：Agent 在沙箱里运行用户提交的 Python 脚本，脚本有死循环，沙箱容器吃光了节点全部 CPU。

根因：Docker 沙箱没设--cpus和--memory限制。

解决：

.sandbox(SandboxBuilder.docker() .image("agentscope/agent-runtime:2.0") .memoryLimit("512m") // 必须设 .cpuLimit("1.0") // 必须设 .pidsLimit(100) // 限制进程数，防 fork bomb .networkMode(NetworkMode.RESTRICTED) .allowedDomains(List.of("api.deepseek.com")) // 白名单 .build())

坑5：Redis 会话恢复后中间件状态丢失

现象：Pod 重启后会话从 Redis 恢复成功，但PermissionMiddleware的待审批队列丢了，用户审批点击后无响应。

根因：PendingApprovalStore用了内存实现，Pod 重启就没了。

解决：审批队列也必须持久化到 Redis：

@Bean public PendingApprovalStore approvalStore(RedisConnectionFactory factory) { return new RedisPendingApprovalStore(factory.getConnection()); // 不要用 new InMemoryPendingApprovalStore() }

坑6：CompactionMiddleware 压缩后丢失关键工具调用上下文

现象：上下文溢出触发压缩后，Agent 忘记了之前调用queryOrder的结果，用户问"刚才查的订单呢"，Agent 答不上来。

根因：CompactionMiddleware默认策略是 LLM 摘要压缩，摘要可能丢失具体工具结果。

解决：配置ToolResultEvictionMiddleware在压缩前先清理旧工具结果，并对关键结果标记不可压缩：

// 自定义工具结果标记 @Tool(description = "查询订单") @PreserveResult(compressible = false) // 标记此工具结果不可被压缩 public OrderInfo queryOrder(...) { ... } // 中间件配置 .middleware(new ToolResultEvictionMiddleware(EvictionPolicy .maxAge(Duration.ofMinutes(10)) .preserveMarked())) // 保留标记为不可压缩的结果 .middleware(new CompactionMiddleware())

坑7：流式响应中 AgentEvent 序列化失败导致 SSE 断连

现象：前端接收 SSE 流正常，但偶尔断连，后端日志报JsonSerializationException: Cannot serialize event of type SubagentSpawnedEvent。

根因：自定义子 Agent 的SubagentSpawnedEvent携带了不可序列化的字段（如Mono<AgentResult>或Flux<AgentEvent>）。

解决：事件只携带可序列化数据，响应式类型不要放进事件：

// 错误：把 Mono 放进事件 public record SubagentSpawnedEvent( String sessionId, Instant timestamp, Mono<AgentResult> result // ← 不可序列化！ ) implements AgentEvent {} // 正确：只放元数据 public record SubagentSpawnedEvent( String sessionId, Instant timestamp, String subagentName, String subagentId ) implements AgentEvent {}

坑8：GraalVM Native Image 编译失败（反射注册缺失）

现象：native-image编译时报ClassNotFoundExceptionforReflectiveFunctionTool，运行时Toolkit.registerTool()找不到工具方法。

根因：ReflectiveFunctionTool用反射扫描@Tool注解，GraalVM Native Image 默认不支持运行时反射。

解决：配置reflect-config.json：

[ { "name": "com.example.tools.CustomerServiceTools", "allDeclaredMethods": true, "allDeclaredConstructors": true }, { "name": "io.agentscope.tools.ReflectiveFunctionTool", "allDeclaredMethods": true, "allDeclaredConstructors": true } ]

或者用 AgentScope 提供的编译期注解处理器替代运行时反射（2.0.1+ 支持）。

六、AgentScope Java vs OpenAI Agents API

OpenAI Agents API 刚发布（9/11），它和 AgentScope Java 解决同一个问题但路径完全不同：

结论很清晰：如果你是中国企业的 Java 团队，AgentScope Java 是比 OpenAI Agents API 更合适的 Agent Harness 底座。你可以用通义千问或 DeepSeek 做模型，用自己的 Redis 做会话存储，在自己的 K8s 集群跑沙箱，全程数据不出域。

七、总结

AgentScope Java 2.0 的出现标志着 Java 生态在 AI 上的一个转向：从"能不能调大模型"（这个问题早已解决），转向"怎么把 Agent 工程化地跑在生产环境里"。

它把 Java 引以为傲的类型系统、并发模型、微服务治理，用在了 Agent 这个新物种上：

• 类型系统：28 种类型化事件、sealed interfaceAgentEvent、ContentBlock 类型系统——结构化、可校验、可追踪，而不是 ad-hoc JSON
• 组合优于继承：HarnessAgent 不继承 ReActAgent 而是委托，接口不受实现细节绑架
• 洋葱中间件：五阶段精准拦截点，工程能力全走中间件注入，"只叠加、不替换"
• 无状态 + Reactor Context：单例服务多租户，靠(userId, sessionId)隔离，天然适配 Spring Bean 生命周期
• 沙箱隔离 + HITL 审批：危险操作先 review 再执行，不是事后审计

当 OpenAI 把 Harness 做成托管服务时，AgentScope Java 给了中国 Java 开发者另一条路：自己掌控 Agent 的每一个环节。

Java 工程师做 AI，工程化能力才是护城河。AgentScope Java 让你可以用熟悉的 Java 类型系统、Spring 编程模型、K8s 部署体系，把 Agent 做成可观测、可降级、可审计的生产基础设施——而不需要把会话状态交给 OpenAI。