[Bug]: ReActAgent 实现 AutoCloseable 属于过度设计——与无状态可复用单例架构目标矛盾

## 环境

- 框架：AgentScope Java SDK（`io.agentscope.core`）
- 类：`io.agentscope.core.ReActAgent`
- 类声明：`public class ReActAgent extends AgentBase implements AutoCloseable`

## 问题陈述

`ReActAgent` 实现了 `AutoCloseable` 接口，意味着它被标记为"**可能持有资源、使用完毕后需要关闭释放**"的对象。然而按照 AgentScope 官方对 Agent 的架构定义，Agent 是**无状态、可安全并发复用的单例**。一个被设计为无限次复用的共享实例，不应背负"用完即关"的生命周期契约——两者在语义上存在根本矛盾。

## 官方架构定位

官方文档 [Multi-User / Multi-Session Concurrency](https://java.agentscope.io/v2/zh/docs/building-blocks/agent.html#multi-user-multi-session-concurrency) 明确说明：

> Agent **在调用之间是无状态的**（stateless between calls），可被多用户 / 多会话安全并发复用。

AgentScope 自身的 API 设计也印证了这一点。`AguiAgentRegistry.register(String id, Agent agent)` 接受并缓存一个 Agent 实例，供所有请求复用：

```java
AguiAgentRegistry registry = new AguiAgentRegistry();
registry.register("chat", agent); // 单例注册，所有 threadId 共用同一实例
```

多会话隔离通过 `RuntimeContext.sessionId` 在调用时传入，而非为每个会话创建独立 Agent：

```java
RuntimeContext ctx = RuntimeContext.builder().sessionId(sessionId).build();
agent.call(messages, ctx).block(); // 同一 agent 实例，不同 sessionId 隔离状态
```

这意味着 Agent 的设计目标是**单例注册、长期复用**，而非每次调用创建独立实例后销毁。

## close() 当前是空实现

Agent 实例本身不持有需要释放的资源：

- **状态存储**（`AgentStateStore`）：多 Agent 共享，由外部注入，Agent 不拥有其生命周期。
- **模型客户端**：由模型提供方管理连接池 / 客户端缓存，Agent 只持有引用。
- **工具集**（`Toolkit`）：共享引用，不由 Agent 创建或独占。

`close()` 方法目前没有任何实质性的资源释放逻辑，`AutoCloseable` 纯粹是空壳。

## Git 历史追溯

经 git blame 追溯，`implements AutoCloseable` 是在以下提交中被加入 `ReActAgent` 类声明的：

- **提交信息**：`refactor: rename multiple Java files for improved clarity and organization`
- **作者**：Chickenlj
- **日期**：2026-05-27

该提交的主旨是**文件重命名与代码组织调整**（rename / refactor）。但 `AutoCloseable` 接口在此提交中被一并添加，而提交中**没有任何与之配套的代码变更**——既未引入需要释放的新资源（连接、句柄、线程池等），也未为 `close()` 方法添加任何实现。

这表明 `AutoCloseable` 的添加是**附带性的、非设计驱动的**：它并非源于某个具体的资源管理需求，而是随一个不相关的重命名提交"捎带"加入。与上文 `close()` 空实现的事实相互印证——该接口从引入之初就没有明确的资源释放语义，没有经过"Agent 是否应该可关闭"的架构评审。

## AutoCloseable 的正确语义

JDK 对 `AutoCloseable` 的定义：

> An object that **may hold resources** (such as file or socket handles) **until it is closed**. The `close()` method is called automatically when exiting a try-with-resources block.

该接口建立的是一条 **获取 → 使用 → 关闭 → 丢弃** 的生命周期契约，适用于：

| 适用场景 | 不适用场景 |
|---|---|
| 一次性独立实例（如 `FileInputStream`、`Connection`） | 共享 / 单例 / 长期复用的实例 |
| 实例确实持有需要释放的资源（文件句柄、网络连接、线程池） | 实例不持有任何独占资源 |
| 调用方拥有完整的创建—销毁所有权 | 调用方只"借用"，不拥有生命周期 |

`ReActAgent` 完全落在"不适用"列：共享、长期复用、不持有独占资源。

## 矛盾分析

```
AutoCloseable 契约 ReActAgent 实际用法
───────────────── ──────────────────────
获取 → 使用 → 关闭 → 丢弃 注册一次 → 无限次复用 → 永不关闭
调用方拥有生命周期 注册表 / 容器拥有生命周期
close() 后对象不可再用 close() 后仍需服务其他会话
```

如果一个被 `registry.register(id, agent)` 注册的单例 Agent 被某个调用方通过 try-with-resources 关闭：

- **当前**（close() 空实现）：无实际影响，但语义错误。
- **未来**（若 close() 补充了资源释放逻辑）：**直接摧毁所有正在使用该 Agent 的并发会话**——共享的状态存储连接、模型客户端被关闭，其他线程的 `call()` 立即失败。

## 影响

### 1. IDE 警告噪音

每个持有共享 Agent 实例引用的调用点都会触发 `'ReActAgent' used without 'try'-with-resources statement` 警告。由于 Agent 本应作为单例长期复用、不应被关闭，消费方被迫逐个添加抑制注释或 `@SuppressWarnings`：

```java
// agent 是注册表缓存的共享实例，不应在此关闭
@SuppressWarnings("resource")
Agent agent = registry.getAgent(id).orElseThrow();
```

一个本不该存在的接口，导致下游每个消费点都要付出额外的防御性注释成本。

### 2. 语义误导

`AutoCloseable` 向使用者传递"我持有资源，用完要关我"的信号。实际使用中，调用方恰恰**不应该**关闭 Agent。这会诱导开发者写出语义错误的代码：

```java
// 受 AutoCloseable 误导，以为需要"清理资源"——实际 close() 是空操作
try {
agent.close();
} catch (Exception e) {
log.warn("关闭 Agent 时出错: {}", e.getMessage());
}
```

如果未来 close() 被补充实现，这段"清理"代码反而会变成共享实例的定时炸弹。

### 3. 潜在误用风险

一旦官方在未来版本为 `close()` 补充资源释放逻辑（这完全符合 `AutoCloseable` 的设计暗示），所有对单例 Agent 调用 `close()` 的消费方代码——无论是有意调用还是 try-with-resources 自动触发——都会**静默地破坏共享实例**，且极难排查。

## 结论与建议

`ReActAgent` 实现 `AutoCloseable` 属于**过度设计**：

- 当前 `close()` 无实现，接口形同虚设——纯仪式代码。
- 与官方"无状态可复用单例"的架构目标直接矛盾。
- 对下游消费方制造了持续的 IDE 警告噪音和语义误导。
- 若未来 close() 被实质化，单例 + AutoCloseable 的组合将成为并发灾难的温床。

**建议方案**：

1. **移除 `implements AutoCloseable`**——Agent 作为无状态共享单例，不应承担资源释放契约。
2. 若未来确有"持有资源的 Agent"场景（如独占模型连接的临时实例），应通过**独立的类型**承载（如 `CloseableAgent` / `DisposableAgent`），而非将 `AutoCloseable` 强加到所有 Agent 基类上。
3. 资源清理（状态存储、模型客户端等）的职责应归属于**容器 / 注册表**（如 `AguiAgentRegistry.unregister` 时统一释放），而非 Agent 实例自身。