[Feature Request] Decouple HarnessAgent-exclusive memory capabilities into a composable module usable by lightweight agents (ReActAgent / BaseAgent)

# [Feature Request] Decouple HarnessAgent-exclusive memory capabilities into a composable module usable by lightweight agents (ReActAgent / BaseAgent)

## Summary / 一句话总结

Some of our business scenarios only need a minimal agent unit (BaseAgent / ReActAgent level) and cannot afford the full HarnessAgent runtime, but they still need HarnessAgent-exclusive memory capabilities (workspace long-term memory, `MEMORY.md` auto-injection, `memory_save/search/get`, `session_search`) — we request these memory capabilities be decoupled from HarnessAgent into an opt-in, composable module that any agent can mount.

> 中文：部分业务场景只需要最小 Agent 单元（BaseAgent / ReActAgent 级别），无法承担完整 HarnessAgent 运行时的开销，但又需要 HarnessAgent 独有的记忆能力（Workspace 跨 Session 长期记忆、`MEMORY.md` 自动注入、`memory_save/search/get`、`session_search`）。希望官方将这部分记忆能力从 HarnessAgent 中解耦为可选、可组合的模块，任意 Agent 都能按需挂载。

## Background / 背景

In production we run a mix of agents:

- **Lightweight business agents** (BaseAgent / ReActAgent): single-purpose, latency-sensitive tasks (classification, extraction, single-domain Q&A). They only need session-level working memory.
- **HarnessAgent**: full orchestration scenarios (planning, subagents, workspace, file tools).

After auditing both, we found the memory gap between them is **not just `MEMORY.md`** — it is a set of capabilities hard-bound to the HarnessAgent runtime:

| Capability | BaseAgent / ReActAgent | HarnessAgent |
|---|---|---|
| Same-session context (AgentState store) | Yes | Yes |
| Compaction (summarize old messages) | Yes | Yes |
| Reopen the same session (state restore) | Yes | Yes |
| New session inherits user-level info | **No** | Yes (workspace long-term memory) |
| `MEMORY.md` auto-injection (up to 8000 tokens) | **No** | Yes |
| `memory_save` / `memory_search` / `memory_get` tools | **No** | Yes |
| `session_search` (retrieve offloaded originals) | **No** | Yes |
| Compaction-offloaded JSONL | Written, but agent has **no tool to read it back** | Written and retrievable |

> 中文：审计后发现两者的记忆差异不只是一个 `MEMORY.md`，而是一整套与 HarnessAgent 运行时硬绑定的能力（见上表）。

## Problem / 问题

Because these capabilities are exclusive to HarnessAgent, lightweight agents suffer from:

1. **No cross-session long-term memory**: a new session forgets user preferences, decisions, and constraints established in earlier sessions.
2. **Irreversible detail loss after compaction**: old messages are summarized, and although the original content is offloaded to JSONL, the agent has no tool (like `session_search`) to retrieve it — the data exists but is unreachable.
3. **All-or-nothing choice**: to gain these memory capabilities we must upgrade the whole business unit to HarnessAgent, paying for workspace management, extra file tools, and per-turn `MEMORY.md` token overhead that these minimal scenarios do not need.

> 中文：由于这些能力仅 HarnessAgent 可用，轻量 Agent 面临三个问题：(1) 新 Session 不认识旧 Session 中的用户偏好/决定/约束；(2) 长会话压缩后细节永久丢失——原文虽已 offload 到 JSONL，但 Agent 没有工具读回；(3) 只能"全有或全无"，为了记忆能力被迫升级为完整 HarnessAgent，承担不需要的 Workspace、文件工具和每轮 `MEMORY.md` 注入的 Token 成本。

## Proposed Solution / 建议方案

Extract the memory capabilities into a standalone, composable module (e.g. `LongTermMemoryModule` / memory toolkit) with independent switches, so that any agent — including ReActAgent / BaseAgent — can opt in:

1. **Memory tools as a pluggable tool group**: `memory_save` / `memory_search` / `memory_get` / `session_search` registrable on any agent, backed by a configurable storage root (not necessarily a full HarnessAgent workspace).
2. **`MEMORY.md` injection as an optional middleware/hook**: configurable token budget, mountable on any agent's system-prompt pipeline.
3. **Offloaded-content retrieval decoupled from HarnessAgent**: since compaction already writes offloaded JSONL for all agents, expose `session_search` (or equivalent read-back API) wherever compaction is enabled.
4. **Keep auto Flush/Consolidation independent and opt-in**: we currently disable auto hooks even on HarnessAgent (they add tens of seconds of tail latency per turn); explicit `memory_save` + injection is the sweet spot, so the decoupled module should support this "manual-save, auto-inject" mode as a first-class configuration.

> 中文：建议将记忆能力抽成独立可组合模块并提供独立开关：(1) 四个记忆工具做成可插拔工具组，存储根目录可配置，不依赖完整 Workspace；(2) `MEMORY.md` 注入做成可选中间件/Hook，Token 预算可配；(3) offload 原文检索与 HarnessAgent 解耦——Compaction 本来就会为所有 Agent 写 JSONL，凡开启 Compaction 的 Agent 都应能用 `session_search` 读回；(4) 自动 Flush/Consolidation 保持独立可选（我们实测其尾部延迟可达数十秒，即使在 HarnessAgent 上也是关闭的），"手动 save + 自动注入"应作为一等公民配置。

## Alternatives Considered / 已考虑的替代方案

- **Upgrade all business agents to HarnessAgent**: rejected — unnecessary runtime overhead (workspace, file tools) and higher per-turn token cost for minimal single-purpose agents.
- **Re-implement memory tools ourselves on BaseAgent**: possible but duplicates framework logic (MEMORY.md format, injection budget, offload index), and will drift from official behavior across versions.

> 中文：(1) 全量升级为 HarnessAgent——被否，最小业务单元不需要 Workspace/文件工具，且 Token 成本上升；(2) 自行在 BaseAgent 上重造记忆工具——会重复框架逻辑且随版本演进产生行为漂移。

achieving "session working memory + cross-session long-term memory + active save/retrieve" without adopting the full HarnessAgent runtime.

> 中文：轻量 Agent 通过配置即可获得"Session 工作记忆 + 跨 Session 长期记忆 + 主动保存/检索"能力，而无需引入完整 HarnessAgent 运行时。