版本基准 :本文档基于 AgentScope 2.0 GA(
v2.0.0)编写。具体版本号以 Release Notes 为准。
一句话概括
HarnessAgent 2.0 围绕 Middleware 洋葱模型、AgentState 状态管理、声明式配置三根支柱，把一个"只有金鱼记忆"的裸 ReActAgent 改造成能长期记忆、会话恢复、沙箱隔离、委派协作、自我学习的工程级 Agent------这 9 篇文档的所有概念，其实都在回答同一个问题：怎么让 AI Agent 像一个靠谱的正式员工一样稳定工作。
你能学到什么
- 串联 01-09 所有模块，建立 2.0 全局认知地图
- 用一张全景图理解 9 个模块之间的数据流和依赖关系
- 用一句话记住每个模块的核心职责
- 了解 1.x 到 2.0 的关键术语变更
- 通过一个生产级完整示例，体验所有能力如何协同工作
- 掌握 call() 完整生命周期的每个阶段
- 获得学习路线建议和下一步行动指引
前置知识
建议你先按顺序读完 01-09 全部文档，再来看这篇总结。本篇不再解释基础概念，只做串联和升华。
如果你已经读完了，恭喜------这篇文档会帮你把所有碎片拼成一幅完整的拼图。
核心概念
三根支柱回顾
HarnessAgent 2.0 的所有能力可以归纳为三根支柱：
第一根支柱：能力叠加（Middleware 驱动）
所有工程能力（工作区注入、压缩、记忆、计划模式、子代理、技能......）都是 Middleware，挂在 ReAct 循环的关键时机。core 的推理算法本身没有改动。你加一个能力，就是往洋葱上加一层。
第二根支柱：共享对象通信
Middleware 之间互不持有引用，靠三个共享对象协作：
| 共享对象 | 生命周期 | 谁读写 | 存什么 |
|---|---|---|---|
RuntimeContext |
一次 call() |
框架写入，Middleware 读取 | sessionId、userId、沙箱句柄 |
AgentState |
一次 call() |
框架和 Middleware 共同读写 | 对话上下文、摘要、权限、计划状态 |
AgentStateStore |
跨 call() |
框架读写 | AgentState 的持久化快照 |
第三根支柱：声明式配置
2.0 用声明式 Spec 替代了大量编程式配置。文件系统用 FilesystemSpec 声明、沙箱用 DockerFilesystemSpec 等 SandboxFilesystemSpec 声明、子代理用 .md 文件声明、技能用 SKILL.md 声明。好处是配置和代码分离，运维能改、Git 能追踪。
模块关系全景图
下面这张 ASCII 大图展示了 9 个模块之间的关系和数据流向：
用户请求
│
▼
┌────────────────────────┐
│ 01-总览（Overview） │
│ HarnessAgent.call() │
│ Middleware 洋葱模型 │
└─────────┬──────────────┘
│
┌────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌──────────┐ ┌───────────────┐
│ 02-工作区 │ │ 03-上下文 │ │ 06-计划模式 │
│ (Workspace) │ │ (Context) │ │ (Plan Mode) │
│ │ │ │ │ │
│ AGENTS.md ──┼─┤ AgentState│ │ 只读思考阶段 │
│ MEMORY.md │ │ AgentStateStore │ │ HITL 确认门控 │
│ knowledge/ │ │ 压缩策略 │ │ │
│ tools.json │ │ │ └───────────────┘
└──────┬──────┘ └─────┬─────┘
│ │
│ │ 后台维护触发
▼ ▼
┌─────────────┐ ┌──────────┐
│ 04-记忆 │ │ │
│ (Memory) │ │ │
│ │ │ │
│ 流水账(追加) │ │ │
│ MEMORY.md(重写)│ │
│ 压缩+卸载 │ │ │
└──────┬──────┘ └──────────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌───────────┐ ┌───────────────┐
│ 05-文件系统 │ │ 07-沙箱 │
│(Filesystem)│ │ (Sandbox) │
│ │ │ │
│ Remote ────┼────┤ Docker/K8s │
│ Docker ────┤ │ 快照+恢复 │
│ Local ─────┘ │ 并发控制 │
│ IsolationScope │ 工作区投影 │
└───────────┘ └───────────────┘
┌─────────────┐ ┌────────────────┐
│ 08-技能 │ │ 09-子代理 │
│ (Skill) │ │ (SubAgent) │
│ │ │ │
│ SKILL.md │ │ 三种声明方式 │
│ 四层优先级 │ │ ISOLATED/SHARED│
│ 四种市场后端 │ │ 同步/异步调用 │
│ 自学习闭环 │ │ 流式输出 │
└──────────────┘ └────────────────┘
数据流方向：
工作区 ──注入──▶ System Prompt ──喂给──▶ 推理循环
AgentState ──序列化──▶ AgentStateStore ──下次还原──▶ AgentState
流水账 ──合并──▶ MEMORY.md ──注入──▶ System Prompt
文件系统 ──声明──▶ 沙箱 ──隔离──▶ 工具执行环境
技能 ──加载──▶ System Prompt ──指导──▶ Agent 行为
子代理 ──委派──▶ 独立 Agent ──回报──▶ 主 Agent一句话记住每个模块
| 序号 | 模块 | 一句话总结 | 生活类比 |
|---|---|---|---|
| 01 | 总览（Overview） | ReActAgent 的薄封装，通过 Middleware 洋葱模型叠加所有工程能力 | 给裸车加装导航、记录仪、对讲机 |
| 02 | 工作区（Workspace） | Agent 的办公桌，人格、记忆、知识、技能都以文件形式摆在这里 | 员工的固定工位，工牌+笔记本+书架 |
| 03 | 上下文（Context） | AgentState 游戏存档 + AgentStateStore 档案柜 + 压缩行李箱整理术 | 存档/读档 + 行李箱打包 |
| 04 | 记忆（Memory） | 日记本（追加）+ 整理好的笔记（重写），双层记忆让 Agent 记住跨会话事实 | 学生速记 + 编辑整理后的文章 |
| 05 | 文件系统（Filesystem） | Agent 的住处选择器：快捷酒店 / 租公寓 / 自己家，声明式切换 | 住酒店 vs 租公寓 vs 自己家 |
| 06 | 计划模式（Plan Mode） | 先写施工图纸再干活，只读阶段强制思考 + HITL 审批门控 | 建筑工地图纸审核 |
| 07 | 沙箱（Sandbox） | 把 Agent 关在安全笼子里干活，随便折腾不影响主机 | 独立实验操作间 |
| 08 | 技能（Skill） | 给 Agent 发工作手册，放上去就生效，还能自学习晋升 | 工具箱 + SOP 手册 |
| 09 | 子代理（SubAgent） | 主 Agent 像项目经理一样分活给下属，支持同步/后台调用、反向通知、wait_async_results 护栏、streamEvents() 父子事件转发 |
项目经理委派子任务 |
关键术语变更速查（1.x → 2.0）
如果你是从 1.x 过来的，这张表帮你快速对照：
| 1.x 术语 | 2.0 术语 | 变化说明 |
|---|---|---|
| Hook | Middleware | 从优先级数字排序改为洋葱模型，5 种挂载点 |
| Priority | 挂载点（onAgent / onReasoning / onActing / onModelCall / onSystemPrompt） | 不再用数字排序，改为语义化的挂载点 |
| PreCallEvent / PostCallEvent | onAgent 挂载点 |
统一进洋葱模型 |
| PreReasoningEvent / PostReasoningEvent | onReasoning 挂载点 |
同上 |
| PreActingEvent / PostActingEvent | onActing 挂载点 |
同上 |
| WorkspaceContextHook | WorkspaceContextMiddleware | 改名，功能不变 |
| CompactionHook | CompactionMiddleware | 改名，功能增强 |
| SessionPersistenceHook | （已移除） | 持久化由 core 的 ReActAgent + AgentStateStore 接管，不再是 Middleware |
| SubagentsHook | SubagentsMiddleware | 改名，新增流式支持 |
| MemoryFlushHook | MemoryFlushMiddleware | 改名，新增禁用开关 |
| Hook.chain() | Middleware.aroundXxx(... next) | 洋葱链式调用替代事件链 |
| RuntimeContext | RuntimeContext（不变） | 概念保持一致 |
| WorkspaceManager | Workspace（简化） | 不再需要 Manager 后缀 |
| AbstractFilesystem | FilesystemSpec（声明式） | 从编程式改为声明式配置 |
| IsolationScope | IsolationScope（不变） | 概念保持一致，新增 GLOBAL |
| Toolkit | tools.json（声明式） | 工具清单从代码配置改为文件配置 |
| SkillBox | Skill + SkillRepository | 拆分为技能定义 + 技能市场两部分 |
| agent_spawn / agent_generate | 子代理声明 + SubagentsMiddleware | 支持文件声明和远程 Agent Protocol |
关键代码解读
一个完整的生产级 HarnessAgent 构建示例
这个示例整合了 9 个模块的所有核心能力，展示它们如何协同工作：
java
// =============================================
// 生产级 HarnessAgent 2.0 完整构建
// 整合：工作区 + 会话持久化 + 记忆 + 压缩 + 文件系统
// + 计划模式 + 沙箱 + 技能 + 子代理
// =============================================
HarnessAgent agent = HarnessAgent.builder()
// [01-总览] 模型 ID，通过 ModelRegistry 解析
.model("my-model-id")
// [02-工作区] 所有文件的根目录
// AGENTS.md、MEMORY.md、knowledge/、skills/、tools.json 都在这里
.workspace(Paths.get(".agentscope/workspace"))
// [03-上下文] 状态持久化------用 Redis 分布式存储支持多副本共享
// 不配的话默认用 JsonFileAgentStateStore（单机落盘即可恢复）
.distributedStore(RedisDistributedStore.fromJedis(jedis)) // 自动配齐 stateStore + 快照 + 执行守卫
// [03-上下文 + 04-记忆] 压缩策略------40 条消息或 80K tokens 后触发
// 压缩时：LLM 做摘要 → 保留最近 10 条 → 旧消息归档到 .log.jsonl
.compaction(CompactionConfig.builder()
.triggerMessages(40) // 消息条数触发阈值
.triggerTokens(80000) // token 数触发阈值（两个条件满足任一即可）
.keepMessages(10) // 压缩后保留最近 10 条原文
.build())
// [04-记忆] 大工具结果卸载------超 80K 字符自动落盘
// 避免"查询数据库返回 100 万行"把上下文撑爆
.toolResultEviction(ToolResultEvictionConfig.builder()
.threshold(80000) // 80K 字符阈值
.build())
// [05-文件系统 + 07-沙箱] 声明式沙箱配置
// DockerFilesystemSpec = 租公寓模式（独立空间 + 随意折腾）
// IsolationScope.SESSION = 每个会话一个独立容器
.filesystem(new DockerFilesystemSpec()
.image("my-agent-runtime:latest")
.isolationScope(IsolationScope.SESSION))
// [06-计划模式] 开启"先规划再执行"
// Agent 进入只读阶段 → 写计划文件 → HITL 确认后才能动手
.enablePlanMode()
// [08-技能] 从 Git 仓库加载技能包
// 技能 = SKILL.md（Markdown 格式的工作手册）
// 自动缓存到 .skills-cache/，SHA-256 去重
.skillRepository(new GitSkillRepository(
"https://github.com/my-org/agent-skills.git"))
// [09-子代理] 子代理在工作区 subagents/ 目录声明
// 例如 subagents/data-analyst.md 定义了"数据分析师"子代理
// 不需要在这里额外配置，只要文件存在就会被自动发现
// [01-总览] 自定义 Middleware------跑在所有内置之前
.middleware(new TimingMiddleware()) // 计时
.middleware(new RateLimitMiddleware()) // 限流
.build(); // 构建完成，所有 Middleware 按固定顺序注册
// =============================================
// 运行------一次完整的生产级调用
// =============================================
// 第一次调用
RuntimeContext ctx = RuntimeContext.builder()
.sessionId("user-123-session-1") // 决定 AgentState 快照存哪
.userId("user-123") // 决定文件命名空间
.build();
String reply = agent.call("帮我分析一下最近三天的销售数据", ctx);
// 这个 call() 背后发生了什么（按顺序）：
// 1. 用户 Middleware 先执行（TimingMiddleware 开始计时）
// 2. WorkspaceContextMiddleware 加载 AGENTS.md + MEMORY.md + knowledge/
// 3. CompactionMiddleware 检查是否需要压缩（第一次不需要）
// 4. HarnessSkillMiddleware 加载匹配的技能到 System Prompt
// 5. SubagentsMiddleware 注入可用子代理列表
// 6. ReAct 循环开始：reason → act → observe
// - Agent 可能委派给 data-analyst 子代理
// - 工具在 Docker 沙箱里执行
// - 子代理结果自动回报给主 Agent
// 7. Plan Mode 检查：如果 Agent 想改文件，先写计划等你确认
// 8. 推理循环结束
// 9. MemoryFlushMiddleware 提取新事实写入流水账
// 10. core 的 ReActAgent + AgentStateStore 把 AgentState 存进 Redis（call()/shutdown 时落盘）
// 11. 用户 Middleware 后执行（TimingMiddleware 记录耗时）
// 12. 返回最终回复整体流程图
下面这张图展示了一次完整 call() 的生命周期，标注了每个模块在哪个阶段介入：
用户消息 ────────────────────────────────────────────────────────┐
│ │
▼ │
┌──────────────────────────────────────────────────────────────┐ │
│ 阶段 1：准备阶段 │ │
│ │ │
│ ┌────────────────────────┐ │ │
│ │ RuntimeContext 构建 │ 01-总览 │ │
│ │ sessionId + userId │ │ │
│ └───────────┬────────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌────────────────────────┐ │ │
│ │ AgentStateStore 恢复 │ 03-上下文 │ │
│ │ 有存档就还原，没有就新建 │ │ │
│ └───────────┬────────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌────────────────────────┐ │ │
│ │ 沙箱环境准备 │ 07-沙箱 │ │
│ │ Docker/K8s 启动容器 │ 05-文件系统 │ │
│ │ 快照恢复（如果有） │ │ │
│ └───────────┬────────────┘ │ │
│ │ │ │
└──────────────┼────────────────────────────────────────────────┘ │
│ │
▼ │
┌──────────────────────────────────────────────────────────────┐ │
│ 阶段 2：System Prompt 组装（onSystemPrompt 挂载点） │ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │ │
│ │ WorkspaceContextMiddleware 加载工作区文件 │ │ │
│ │ │ │ │
│ │ <agents_context> ← AGENTS.md [02-工作区] │ │ │
│ │ <memory_context> ← MEMORY.md [04-记忆] │ │ │
│ │ <domain_knowledge> ← knowledge/ [02-工作区] │ │ │
│ │ <skill_context> ← 匹配的 SKILL.md [08-技能] │ │ │
│ │ <subagent_context> ← 可用子代理列表 [09-子代理] │ │ │
│ │ <tool_context> ← tools.json 白名单 [02-工作区] │ │ │
│ └─────────────────────────────────────────────────────┘ │ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │ │
│ │ CompactionMiddleware 检查是否需要压缩 │ │ │
│ │ │ │ │
│ │ 消息数 ≥ 40 或 tokens ≥ 80K？ │ │ │
│ │ ├── 是 → LLM 做摘要 + 保留尾部 + 归档旧消息 │ │ │
│ │ └── 否 → 跳过 │ │ │
│ └─────────────────────────────────────────────────────┘ │ │
│ [03-压缩+04-记忆]│ │
│ │ │
└──────────────┬───────────────────────────────────────────────┘ │
│ │
▼ │
┌──────────────────────────────────────────────────────────────┐ │
│ 阶段 3：ReAct 推理循环 │ │
│ │ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ ┌──▶ │ Reason │────▶│ Act │────▶│ Observe │──┐ │ │
│ │ │ 推理思考 │ │ 执行工具 │ │ 观察结果 │ │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │ │
│ │ │ │ │
│ │ Act 阶段可能触发： │ │ │
│ │ ├── 调用 MCP 工具 [02-工作区] │ │ │
│ │ ├── 委派子 Agent [09-子代理] │ │ │
│ │ ├── 在沙箱里执行命令 [07-沙箱] │ │ │
│ │ ├── 大结果自动卸载到文件 [04-记忆] │ │ │
│ │ └── Plan Mode 拦截写操作 [06-计划模式] │ │ │
│ │ │ │ │
│ └──────────────────────────────────────────────────────┘ │ │
│ │ │
└──────────────┬───────────────────────────────────────────────┘ │
│ │
▼ │
┌──────────────────────────────────────────────────────────────┐ │
│ 阶段 4：收尾阶段 │ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │ │
│ │ MemoryFlushMiddleware 提取新事实 │ │ │
│ │ ├── 对话中有价值的信息 → memory/YYYY-MM-DD.md（追加） │ │ │
│ │ └── 通知后台调度器：可以合并记忆了 │ │ │
│ └─────────────────────────────────────────────────────┘ │ │
│ [04-记忆] │ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │ │
│ │ 后台维护（异步，不影响返回速度） │ │ │
│ │ ├── 合并流水账 → 重写 MEMORY.md │ │ │
│ │ ├── 清理 90 天前的旧流水账 │ │ │
│ │ └── 清理 180 天前的旧记忆索引 │ │ │
│ └─────────────────────────────────────────────────────┘ │ │
│ [04-记忆] │ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │ │
│ │ core ReActAgent + AgentStateStore 持久化 │ │ │
│ │ └── AgentState 序列化 → Redis / 文件系统 │ │ │
│ └─────────────────────────────────────────────────────┘ │ │
│ [03-上下文] │ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │ │
│ │ 沙箱快照（可选） │ │ │
│ │ └── 容器状态打包 → S3 / 本地存储 │ │ │
│ └─────────────────────────────────────────────────────┘ │ │
│ [07-沙箱] │ │
│ │ │
└──────────────┬───────────────────────────────────────────────┘ │
│ │
▼ │
返回最终回复 ◀──────────────────────────────────────────┘溢出恢复路径
上面的主流程图中还有一条"应急通道"------当 LLM 返回 ContextOverflow 错误时：
正常流程中 LLM 报 ContextOverflow
│
▼
HarnessAgent.forceCompactAndRetry()
│
├── 构造 triggerMessages=1 的紧急压缩配置
├── 强制压缩（不管原来阈值是多少）
├── 清空 AgentState 中的对话历史，只留摘要
│
▼
重新调用 ReAct 推理循环
│
▼
成功返回 or 再次溢出则抛异常模块关系与学习顺序
本篇是第 10 篇（最后一篇），串联了前面 9 篇的所有概念。
| 模块 | 本篇怎么用到它 |
|---|---|
| 01 总览 | 全景图的骨架------Middleware 洋葱模型是整个架构的核心 |
| 02 工作区 | System Prompt 的原材料来源------AGENTS.md、MEMORY.md、knowledge/ |
| 03 上下文 | 状态流转的中枢------AgentState 的存档和读档贯穿整个生命周期 |
| 04 记忆 | 长期记忆的沉淀------流水账追加 + MEMORY.md 重写的双层机制 |
| 05 文件系统 | 存储后端的选择------决定文件存在哪里、命令在哪里运行 |
| 06 计划模式 | 安全执行的保障------只读思考 + HITL 确认门控 |
| 07 沙箱 | 隔离执行的容器------Docker/K8s 沙箱 + 快照恢复 |
| 08 技能 | 能力的热插拔------SKILL.md 加载到 System Prompt 指导行为 |
| 09 子代理 | 任务委派的通道------主 Agent 分配任务，子代理执行并回报结果 |
学习要点
必须记住
- Middleware 是 2.0 的灵魂：所有能力都是 Middleware，挂在 ReAct 循环的关键时机。core 推理算法没动。
- 三个共享对象是协作的底座 ：
RuntimeContext（调用级）、AgentState（状态级）、AgentStateStore（持久化级）。Middleware 之间通过它们通信，互不直接引用。 - 三层状态流转是理解整个系统的钥匙：调用内状态（AgentState）→ 跨调用状态（AgentStateStore 持久化）→ 长期记忆（MEMORY.md）。每一层解决不同的问题。
- 声明式配置优于编程式：文件系统、沙箱、子代理、技能都可以用声明式配置。改配置不改代码，运维友好。
- System Prompt 每轮重新拼：所以你改工作区的任何文件（AGENTS.md、MEMORY.md、SKILL.md），下一轮立即生效，不需要重启。
容易混淆
-
Middleware vs Hook：
Hook（1.x）：按 priority 数字排序，概念分散Middleware（2.0）：洋葱模型，5 种语义化挂载点，顺序固定
-
AgentStateStore vs Memory：
AgentStateStore：存储AgentState的完整快照，用于跨调用恢复运行时状态。换个sessionId就是全新的。Memory（MEMORY.md）：跨会话累积的长期事实。换sessionId不影响，因为它是按userId隔离的。
-
FilesystemSpec vs 沙箱：
FilesystemSpec（05-文件系统）：声明"文件存在哪里"的抽象。有 Remote、Docker、Local 三种。- 沙箱（07-沙箱）：Docker 模式文件系统的深层展开，包含容器管理、快照、并发控制等完整能力。
-
IsolationScope 的四层：
SESSION：每个会话独立容器/目录USER：每个用户独立AGENT：每个 Agent 独立GLOBAL：全局共享（不隔离）
实践建议
- 从最小配置开始：先用默认的 Local 文件系统 + JsonFileAgentStateStore 跑通，再逐步加压缩、记忆、沙箱等能力。不要一上来就全开。
- 先读懂 AGENTS.md 的注入效果：写一个简单的 AGENTS.md，用日志观察 System Prompt 的变化。这是理解整个工作区机制的入口。
- 用
memory_search验证记忆效果 ：让 Agent 记住一些事实，过几轮对话后用memory_search搜索，确认双层记忆在正常工作。 - 沙箱先在本地 Docker 验证：生产部署前，先在本地用 Docker Desktop 跑通沙箱模式，确认容器镜像和工具路径都正确，再上 Kubernetes。
常见问题
Q：我该按什么顺序读这 9 篇文档？
A：推荐按编号顺序 01 → 09 依次阅读。每篇都有前置知识要求，按顺序读能保证你不跳过依赖。如果你已经有 1.x 经验，可以直接看 01-总览的术语变更表，然后跳到你感兴趣的模块。
Q：2.0 可以和 1.x 的 Hook 共存吗？
A：不可以。2.0 完全用 Middleware 替代了 Hook。如果你有自定义 Hook，需要迁移为 Middleware。好消息是迁移很简单------把 onXxx 方法改为对应挂载点的 aroundXxx 方法就行。
Q：所有能力都必须开启吗？
A：不需要。除了状态持久化（默认 JsonFileAgentStateStore 自动开启）外，其他所有能力都是按需启用的。最小配置只需要 model + workspace，其他通过 Builder 方法按需添加。
学习路线建议
根据你的使用场景，推荐不同的学习重点：
路线 A：快速上手（1-2 天）
适合想先跑起来看看效果的开发者。
- 读 01-总览------建立全局认知
- 读 02-工作区------写一个 AGENTS.md
- 用最小配置跑通一次完整的 call()
- 读 03-上下文------理解 AgentStateStore 恢复
- 尝试跨两次 call() 保持对话上下文
路线 B：核心能力掌握（3-5 天）
适合要把 Agent 用于实际项目的开发者。
- 路线 A 的全部内容
- 读 04-记忆------配置压缩和记忆
- 读 08-技能------写一个自定义技能
- 读 09-子代理------实现一个多 Agent 协作
- 读 06-计划模式------给关键操作加安全门控
路线 C：生产部署（5-7 天）
适合要上线生产环境的团队。
- 路线 B 的全部内容
- 读 05-文件系统------理解三种模式的选择
- 读 07-沙箱------配置 Docker 沙箱 + 快照
- 配置 RedisDistributedStore 实现多副本共享
- 配置 IsolationScope 实现多用户隔离
- 压测验证并发场景
下一步行动
学完这 9 篇文档后，你可以往这些方向深入：
动手实践
- 从 01-总览的最小示例开始，自己跑一遍完整代码
- 尝试配置不同的 CompactionConfig 参数，观察压缩行为的变化
- 在工作区里添加自定义 Skill，体验技能的加载和使用
- 编写一个子代理声明文件，实现一个简单的多 Agent 协作场景
深入原理
- 阅读
agentscope-harness的源码，特别是HarnessAgent.Builder.build()方法，看它是如何一步步组装各个 Middleware 的 - 跟踪一次完整的
call()调用链路，在关键 Middleware 处打断点观察 - 研究
FilesystemSpec的类层次结构，理解不同后端的实现差异
生产落地
- 学习沙箱模式的配置，尝试用 Docker 后端实现隔离执行
- 研究分布式场景下的 AgentStateStore 和快照管理
- 了解
SandboxExecutionGuard在多副本部署下的并发控制策略
拓展视野
- 对比其他 Agent 框架（如 LangGraph、CrewAI）的设计思路，思考 HarnessAgent 2.0 的取舍
- 关注 Agent 评估（Evaluation）和可观测性（Observability）方向，这些是生产环境的关键能力
- 探索多 Agent 编排的更多模式（层级式、对等式、市场式），思考 HarnessAgent 的子代理模型适合哪些场景
