【论文阅读】Agent 记忆机制（40）：HiAgent——通过子目标级记忆提升长程任务执行能力

文章目录

• 前言
• 零、论文基本信息
• 一、背景与问题
• • 1. LLM Agent 是一个持续循环的系统
  • 2. Standard Agent 为什么会出现上下文膨胀？
  • 3. 长 Horizon 会进一步放大问题
  • • 问题一：上下文冗余
    • 问题二：推理负担增加
    • 问题三：长期策略容易被干扰
    • 问题四：Action 可执行性下降
• 二、HiAgent 的核心洞察
• • 1. 人类并不会记住每一步操作
  • 2. Subgoal 是 HiAgent 的 Memory Chunk
• 三、HiAgent 方法总览
• 四、Subgoal-based Hierarchical Working Memory
• • 1. 当前子目标保留完整信息
  • 2. 已完成子目标只保留摘要
  • 3. 工作记忆形成层次结构
• 五、Observation Summarization
• • 1. 为什么需要 Summary？
  • 2. Summary 不是简单截断
  • 3. Summary 本质上是状态压缩
• 六、Trajectory Retrieval
• • 1. Summary 并不能解决所有问题
  • 2. 按需恢复历史轨迹
  • 3. 这与传统 RAG 有什么区别？
• 七、HiAgent 的完整记忆机制
• 八、为什么这种方法有效？
• • 1. 减少无关上下文
  • 2. 降低 LLM 的注意力负担
  • 3. 保留当前任务所需的局部细节
• 九、实验设置
• • 1. 实验任务
  • • Blocksworld
    • Gripper
    • Tyreworld
    • Barman
    • Jericho
  • 2. 为什么选择这些任务？
• 十、评价指标
• • 1. Success Rate
  • 2. Progress Rate
  • 3. Average Steps
  • 4. Context Efficiency
  • 5. Run Time
• 十一、主要实验结果
• • 1. Success Rate 几乎翻倍
  • 2. Progress Rate 提升 23.94%
  • 3. Average Steps 减少 3.8
  • 4. Context 减少 35.02%
  • 5. Run Time 减少 19.42%
• 十二、一个值得注意的实验现象
• 十三、消融实验：到底是谁带来了提升？
• • 1. 去掉 Observation Summarization
  • 2. 去掉 Trajectory Retrieval
  • 3. 两个模块同时去掉
• 十四、HiAgent 到底是不是“Task Decomposition”？
• 十五、Task Decomposition 实验
• • • Task Decomposition 确实有效
    • HiAgent 进一步提升
• 十六、Long-Horizon 下为什么 HiAgent 更稳定？
• 十七、为什么长任务中 Standard 会崩？
• • 1. Standard 的问题
  • 2. HiAgent 更稳定
• 十八、统计显著性实验
• 十九、HiAgent 与前面几类 Memory 方法的区别
• 二十、从“Memory”走向“Context Management”
• 二十一、我的理解和启发
• • 1. Agent Memory 不应该只有“存”和“取”
  • 2. “什么时候压缩”本身就是一个决策问题
  • 3. Summary 不应该只是文本摘要
• 二十二、对自己的 Agent 项目的启发
• 二十三、HiAgent 的局限性
• • 1. Subgoal 生成本身可能出错
  • 2. Summary 可能丢失关键细节
  • 3. Retrieval 触发也可能出错
  • 4. 当前实验任务相对受控
• 二十四、一个更完整的 Agent Memory 架构
• 二十五、总结
• 参考资料

前言

前面已经阅读了 A-MEM、Mem0、MemoryOS、Nemori 等不同类型的 Agent 记忆方法。

这些方法主要关注的是 Agent 如何保存、组织和召回长期历史信息。

但在继续阅读这些工作之后，我发现一个容易被忽略的问题：

Agent 的“记忆”并不只有长期记忆。

一个正在执行任务的 Agent，本身也需要不断维护一块非常重要的工作空间。

例如，一个 Agent 正在执行“更换汽车轮胎”的任务：

打开后备箱
↓
找到千斤顶
↓
找到扳手
↓
抬起车辆
↓
拆下螺母
↓
取下旧轮胎
↓
安装新轮胎
↓
拧紧螺母

如果每执行一步，Agent 都把过去所有的：

Action + Observation

完整保留在上下文中，那么随着任务越来越长，Prompt 会迅速膨胀。

更重要的是，这些历史信息并不是同等重要的。

例如，当 Agent 已经完成：

打开后备箱
找到千斤顶
找到扳手

进入“安装新轮胎”阶段之后，它真正需要知道的可能只是：

千斤顶和扳手已经从后备箱取出。

而不是重新阅读之前所有动作和环境反馈。

这其实就是一个典型的工作记忆管理问题。

HiAgent 关注的正是这个问题。

它没有把重点放在：

怎样从很久以前的历史中检索记忆？

而是关注：

在一个正在进行的长程任务中，哪些历史信息应该继续留在当前上下文？

HiAgent 的核心做法非常直接：

让 Agent 先把长期任务拆成多个子目标（Subgoal），再把每个子目标对应的完整 Action-Observation 轨迹作为一个记忆块。

当某个子目标完成后，就把这个子目标的详细轨迹压缩成一个摘要，只在工作记忆中保留：

Subgoal + Summary

而当前正在执行的子目标则继续保留完整轨迹。

于是，Agent 的工作记忆从：

所有历史 Action-Observation

变成：

过去子目标：摘要
过去子目标：摘要
过去子目标：摘要
当前子目标：完整 Action-Observation

如果之后又需要查看某个过去子目标的具体执行过程，还可以通过 Trajectory Retrieval 将它重新召回。

因此，HiAgent 的核心思想可以概括成一句话：

用“子目标”作为工作记忆的 Chunk，以“摘要”替代已经完成子目标的详细轨迹，同时保留按需恢复历史轨迹的能力。

这篇论文对我理解 Agent Memory 的一个重要启发是：

记忆管理不一定发生在“任务完成以后”。

在 Agent 执行任务的过程中，就应该不断判断：

哪些信息还需要保留？
哪些信息可以压缩？
哪些信息以后可能需要重新查看？

这实际上已经从传统的“长期记忆检索”进一步走向了：

Context / Working Memory Management。

零、论文基本信息

• 论文名称：HiAgent: Hierarchical Working Memory Management for Solving Long-Horizon Agent Tasks with Large Language Model
• 发表平台：ACL 2025 Main Conference，Long Papers
• 代码仓库：HiAgent
• 作者信息：Mengkang Hu、Tianxing Chen、Qiguang Chen、Yao Mu、Wenqi Shao、Ping Luo

一、背景与问题

1. LLM Agent 是一个持续循环的系统

论文将 LLM Agent 看作一个不断与环境交互的系统。

在每个时间步

t

t

t，Agent 根据任务指令以及历史信息生成一个动作：

a

t

∼

π

(

a

t

∣

I

,

o

t

,

a

t

−

1

,

o

t

−

1

,

…

,

a

0

,

o

0

)

a_t\\sim\\pi(a_t\\mid I,o_t,a_{t-1},o_{t-1},\\dots,a_0,o_0)

at​∼π(at​∣I,ot​,at−1​,ot−1​,…,a0​,o0​)

其中：

• $I$
• $o_t$
• $a_t$
• $\pi$

执行动作之后，环境发生变化，并产生新的观察：

s

t

+

1

=

T

(

s

t

,

a

t

)

s_{t+1}=T(s_t,a_t)

st+1​=T(st​,at​)

o

t

+

1

∼

O

(

s

t

+

1

)

o_{t+1}\\sim O(s_{t+1})

ot+1​∼O(st+1​)

然后 Agent 再根据新的 Observation 生成下一步 Action。

因此，一个 Agent 的执行过程可以表示成：

Instruction
↓
Observation
↓
LLM
↓
Action
↓
Environment
↓
Observation
↓
LLM
↓
Action
↓
…

在短任务中，这种方式没有太大问题。

但如果一个任务需要几十甚至上百个动作，就会出现一个非常明显的问题：

工作记忆会越来越长。

2. Standard Agent 为什么会出现上下文膨胀？

传统 Agent 通常直接把历史 Action-Observation 全部保存在上下文中。

例如：

Observation 0
Action 0

Observation 1
Action 1

Observation 2
Action 2

…

Observation 29
Action 29

于是，在第

t

t

t 步时，工作记忆可以表示为：

m

t

s

t

d

=

(

o

t

,

a

t

−

1

,

o

t

−

1

,

…

,

a

0

,

o

0

)

m_t^{std}= (o_t,a_{t-1},o_{t-1},\\dots,a_0,o_0)

mtstd​=(ot​,at−1​,ot−1​,…,a0​,o0​)

这种方式最大的优点是：

信息完整。

Agent 可以看到过去发生过的所有事情。

但是，信息完整并不意味着信息利用效率高。

随着任务变长，历史中会出现大量已经完成、当前阶段不再需要的内容。

例如：

任务：
把红色积木放到蓝色积木上。

历史轨迹：

Step 1：
移动黄色积木

Step 2：
把黄色积木放到桌面

Step 3：
移动绿色积木

Step 4：
把绿色积木放到红色积木上

Step 5：
清理红色积木

…

Step 25：
现在需要把红色积木放到蓝色积木上。

此时 Agent 真正需要关注的是：

红色积木已经清空
蓝色积木已经准备好

而不是重新阅读前面 20 多步具体做了什么。

因此，历史轨迹中存在大量：

与当前决策无关，但仍然占据上下文空间的信息。

3. 长 Horizon 会进一步放大问题

Long-Horizon Agent Task 与普通问答最大的不同，就是：

任务目标
↓
很多中间状态
↓
很多 Action
↓
很多 Observation
↓
最终目标

随着步骤增加：

∣

m

t

∣

↑

|m_t|\\uparrow

∣mt​∣↑

其中

∣

m

t

∣

|m_t|

∣mt​∣ 表示工作记忆长度。

工作记忆变长会带来几个问题。

问题一：上下文冗余

很多已经完成的操作仍然出现在 Prompt 中。

问题二：推理负担增加

LLM 需要从大量历史信息中判断哪些内容真正重要。

问题三：长期策略容易被干扰

任务越长，早期无关信息越多，当前目标更容易被淹没。

问题四：Action 可执行性下降

论文观察到，随着工作记忆变长，Standard Agent 生成不可执行动作的概率明显增加。

例如：

尝试从已经关闭的容器中取出物品

或者：

重复执行已经完成的操作

这意味着：

工作记忆不是越完整越好。

二、HiAgent 的核心洞察

1. 人类并不会记住每一步操作

论文的设计受到认知科学中的 Chunking 思想启发。

人类完成复杂任务时，通常不会把所有细节都以同样的粒度保留。

例如学习做一道菜：

准备食材
→
切菜
→
炒菜
→
调味
→
装盘

完成“切菜”之后，人通常不会一直记住：

拿刀
放下刀
拿西红柿
切第一刀
切第二刀
切第三刀
…

而会把这一阶段压缩成：

食材已经切好。

这就是一种典型的：

Chunking + Abstraction

HiAgent 将这个思想迁移到了 LLM Agent。

2. Subgoal 是 HiAgent 的 Memory Chunk

HiAgent 首先让 LLM 将整个任务拆成多个子目标。

例如：

最终目标：
更换汽车轮胎

Subgoal 1：
打开后备箱并获得工具

Subgoal 2：
拆卸旧轮胎

Subgoal 3：
安装新轮胎

Subgoal 4：
拧紧并检查轮胎

每一个 Subgoal 对应一个 Memory Chunk。

于是原本连续的：

Action 1
Observation 1
Action 2
Observation 2
Action 3
Observation 3
…
Action 20
Observation 20

被重新组织成：

Subgoal 1
Summary 1

Subgoal 2
Summary 2

Subgoal 3
当前详细轨迹

这样，工作记忆就获得了层次结构。

三、HiAgent 方法总览

为了理解 HiAgent 的整体工作流程，可以看论文 Figure 2。

图源：论文 Figure 2。HiAgent 首先生成子目标，再围绕当前子目标执行动作；子目标完成后，将对应的 Action-Observation 轨迹总结为 Summary，并从当前工作记忆中隐藏详细轨迹。对于过去的重要子目标，还可以通过 Trajectory Retrieval 恢复完整轨迹。

整个过程可以整理成：

任务 Instruction
↓
生成 Subgoal
↓
围绕当前 Subgoal 执行 Action
↓
获得 Observation
↓
判断 Subgoal 是否完成
↓
┌───────────────┐
│ │
否 是
│ │
↓ ↓
继续执行 总结该 Subgoal
↓
Summary 替代详细轨迹
↓
生成下一个 Subgoal
↓
…

HiAgent 的工作记忆可以表示为：

m

t

=

(

g

0

,

s

0

,

…

,

g

n

−

1

,

s

n

−

1

,

g

n

,

a

0

n

,

o

0

n

,

…
 

)

m_t= (g_0,s_0,\\dots,g_{n-1},s_{n-1}, g_n,a_0^n,o_0^n,\\dots)

mt​=(g0​,s0​,…,gn−1​,sn−1​,gn​,a0n​,o0n​,…)

其中：

• $g_i$
• $s_i$
• $a_j^n,o_j^n$

也就是说：

过去的 Subgoal → Summary；当前的 Subgoal → Detailed Trajectory。

四、Subgoal-based Hierarchical Working Memory

1. 当前子目标保留完整信息

这是 HiAgent 最重要的设计之一。

假设当前任务是：

更换汽车轮胎

当前 Subgoal：

拆卸旧轮胎

那么此时 Agent 需要看到：

Subgoal：
拆卸旧轮胎

Action 1：
打开工具箱

Observation 1：
工具箱已打开

Action 2：
拿出扳手

Observation 2：
扳手已经拿到

Action 3：
松开第一个螺母

Observation 3：
第一个螺母已经松开

…

因为当前阶段的详细轨迹对下一步决策非常重要。

所以：

当前 Subgoal 不压缩。

2. 已完成子目标只保留摘要

当：

Subgoal：
拆卸旧轮胎

已经完成以后，HiAgent 会将这一阶段的详细轨迹进行总结。

例如：

原始轨迹：

打开工具箱
→ 拿出扳手
→ 松开螺母
→ 拆下轮胎
→ …

Summary：

旧轮胎已经成功拆下，扳手仍在手中。

然后把原来的：

几十个 Action-Observation

替换为：

Subgoal：
拆卸旧轮胎

Observation：
旧轮胎已经成功拆下，扳手仍在手中。

因此，历史轨迹的长度可以大幅下降。

3. 工作记忆形成层次结构

标准 Agent：

Action
Observation
Action
Observation
Action
Observation
Action
Observation
…

HiAgent：

Subgoal 1
Summary 1

Subgoal 2
Summary 2

Subgoal 3
Summary 3

Current Subgoal
Action
Observation
Action
Observation
…

这种结构的最大变化是：

Agent 不再直接维护“步骤序列”，而是维护“子目标层级 + 当前详细轨迹”。

五、Observation Summarization

1. 为什么需要 Summary？

如果一个 Subgoal 完成以后仍然保留所有 Action-Observation，那么 Subgoal 只是被“分类”了，并没有真正减少上下文。

因此，HiAgent 的第二个核心模块就是：

Observation Summarization。

对于一个子目标

g

i

g_i

gi​，系统将其执行过程中产生的轨迹：

(

g

i

,

o

0

,

a

0

,

…

,

a

t

,

o

t

)

(g_i,o_0,a_0,\\dots,a_t,o_t)

(gi​,o0​,a0​,…,at​,ot​)

压缩成一个摘要：

s

i

=

S

(

g

i

,

o

0

,

a

0

,

…

,

a

t

,

o

t

)

s_i=S(g_i,o_0,a_0,\\dots,a_t,o_t)

si​=S(gi​,o0​,a0​,…,at​,ot​)

其中：

• $g_i$
• $a_j$
• $o_j$
• $S$
• $s_i$

论文中使用 LLM 完成这个总结过程。

2. Summary 不是简单截断

这一点非常重要。

HiAgent 并不是简单地：

删除前面 10 步

也不是：

只保留最后一个 Observation

而是让 LLM 根据：

Subgoal
+
完整执行轨迹

生成一个新的状态描述。

例如：

Subgoal：
清空蓝色积木上方的物体

完整轨迹：

Action 1：
拿起黄色积木

Observation 1：
黄色积木已拿起

Action 2：
将黄色积木放到桌面

Observation 2：
蓝色积木已经清空

Summary：

蓝色积木上方已经没有其他积木，黄色积木已被移至桌面。

这里真正重要的是：

最终状态。

而不是：

Agent 是通过哪两步动作达到这个状态的。

3. Summary 本质上是状态压缩

从 Agent 的角度看，一个长轨迹：

τ

i

=

(

a

1

,

o

1

,

a

2

,

o

2

,

…

,

a

k

,

o

k

)

\\tau_i= (a_1,o_1,a_2,o_2,\\dots,a_k,o_k)

τi​=(a1​,o1​,a2​,o2​,…,ak​,ok​)

可以被压缩成：

s

i

=

f

(

τ

i

,

g

i

)

s_i=f(\\tau_i,g_i)

si​=f(τi​,gi​)

因此：

长轨迹
↓
Subgoal-aware Summarization
↓
状态摘要

这其实和传统对话摘要存在明显区别。

普通摘要关注：

这段文本讲了什么？

HiAgent 的摘要更关注：

这个子任务完成之后，Agent 现在处于什么状态？

所以我更倾向于把它理解为：

State-aware Memory Compression。

六、Trajectory Retrieval

1. Summary 并不能解决所有问题

如果所有历史 Subgoal 都只剩 Summary，那么确实可以大幅减少上下文。

但新的问题也出现了：

如果过去某个子目标执行失败了，我想知道当时到底发生了什么怎么办？

例如：

Subgoal 2：
拆卸旧轮胎

Summary：
旧轮胎已经拆下。

但是 Agent 后来发现：

新轮胎无法安装。

此时仅仅知道：

旧轮胎已经拆下

是不够的。

Agent 可能需要进一步查看：

拆卸旧轮胎时具体执行了哪些动作？
哪个步骤可能出现异常？
之前是否已经移动过某个工具？

因此，HiAgent 引入了：

Trajectory Retrieval。

2. 按需恢复历史轨迹

默认情况下：

Subgoal 1 → Summary
Subgoal 2 → Summary
Subgoal 3 → Summary
Current Subgoal → Detailed Trajectory

如果当前任务需要重新查看 Subgoal 2：

Retrieval(Subgoal 2)
↓
找到 Subgoal 2
↓
恢复完整 Action-Observation
↓
加入当前上下文

于是工作记忆变成：

Subgoal 1
Summary 1

Subgoal 2
Detailed Trajectory ← 被召回

Subgoal 3
Summary 3

Current Subgoal
Detailed Trajectory

这使得 HiAgent 的工作记忆具有两个层级：

默认状态：
压缩记忆

需要时：
恢复详细记忆

3. 这与传统 RAG 有什么区别？

传统 RAG：

Query
↓
Vector Retrieval
↓
Relevant Documents

HiAgent：

Current Subgoal / Agent State
↓
判断历史子目标是否需要详细信息
↓
Retrieval
↓
恢复对应完整轨迹

所以它不是典型的：

“从所有历史中找最相似文本”。

而更像：

“当当前任务状态需要时，恢复某个历史执行阶段。”

这是一种面向任务过程的检索。

七、HiAgent 的完整记忆机制

把前面的模块结合起来，可以得到：

Overall Task
│
↓
Generate Subgoal
│
↓
┌────────────────────┐
│ Current Subgoal │
└────────────────────┘
│
Action / Observation
│
↓
Subgoal Completed?
/ \\
No Yes
│ │
↓ ↓
Continue Summarization
│
↓
Subgoal + Summary
│
↓
Hidden Trajectory
│
↓
Generate Next Subgoal

同时增加一条历史召回路径：

Past Subgoal
│
↓
Stored Detailed Trajectory
│
↓
Trajectory Retrieval
│
↓
Restore into Context

因此，HiAgent 实际上形成了：

Working Memory
│
┌───────────┴───────────┐
↓ ↓
Current Subgoal Past Subgoals
│ │
↓ ↓
Detailed Trajectory Summary
│
↓
Need more detail?
/ \\
No Yes
│ │
↓ ↓
Keep Retrieve
Full Trajectory

八、为什么这种方法有效？

1. 减少无关上下文

假设一个任务需要：

30 steps

标准方法会保留：

30 × Action-Observation

而 HiAgent 如果形成：

5 个 Subgoal

那么可能变成：

4 个 Summary
+
当前 Subgoal 的若干详细步骤

因此：

∣

m

t

H

i

A

g

e

n

t

∣

<

∣

m

t

S

t

a

n

d

a

r

d

∣

|m_t^{HiAgent}| < |m_t^{Standard}|

∣mtHiAgent​∣<∣mtStandard​∣

尤其当已经完成的子任务包含大量操作时，压缩效果会更加明显。

2. 降低 LLM 的注意力负担

标准 Agent：

过去 30 步
↓
全部进入 Context
↓
LLM 自己判断哪些重要

HiAgent：

过去子目标
↓
Summary
↓
当前子目标
↓
Detailed Trajectory

等于在进入 LLM 之前，已经完成了一次：

信息筛选。

3. 保留当前任务所需的局部细节

HiAgent 并不是简单地：

全部摘要

它采用：

过去：
压缩

现在：
保留详细信息

因此，它实际上是一种：

时间局部性（Temporal Locality）驱动的上下文管理。

最近正在执行的任务通常最需要细节，而已经完成的任务通常只需要状态结果。

九、实验设置

1. 实验任务

论文使用 AgentBoard 中的五个 Long-Horizon Agent Task：

Blocksworld

要求 Agent 将多个积木排列成指定目标状态。

例如：

Goal：

Blue block is on the table.
Red block is on blue block.
…

Agent 需要通过：

pick up
put down
stack
unstack

等动作逐步完成目标。

Gripper

要求机器人在不同房间之间移动多个物体。

任务需要 Agent 同时考虑：

• 物体位置；
• 机械臂状态；
• 房间位置；
• 搬运顺序。

Tyreworld

模拟更换汽车轮胎：

打开后备箱
→
获取工具
→
拆下旧轮胎
→
获取新轮胎
→
安装新轮胎
→
充气
→
拧紧螺母

这是论文中非常典型的 Long-Horizon Task。

Barman

模拟酒保调制鸡尾酒。

Agent 需要：

获取原料
→
使用容器
→
混合
→
摇匀
→
装杯
→
添加装饰

Jericho

文本冒险游戏环境。

Agent 需要在复杂的环境描述和连续操作中完成任务。

2. 为什么选择这些任务？

这些任务都有一个共同特征：

完成最终目标需要多个连续动作，而且中间状态会不断积累。

因此非常适合测试：

工作记忆长度
+
长程任务执行
+
上下文压缩

而不是简单的单轮问答。

十、评价指标

论文主要使用五个指标。

1. Success Rate

成功完成任务的比例：

S

R

=

S

u

c

c

e

s

s

T

a

s

k

s

SR=\\frac{Success}{Tasks}

SR=TasksSuccess​

只有完整完成任务时才算成功。

2. Progress Rate

衡量 Agent 已经完成了多少目标条件。

如果一个任务有：

10 个 Goal Conditions

Agent 完成其中：

7 个

那么：

P

R

=

7

10

=

70

%

PR=\\frac{7}{10}=70\\%

PR=107​=70%

这个指标能够反映：

即使 Agent 最终没有完成任务，它究竟走到了哪一步。

因此比单纯的 Success Rate 更细粒度。

3. Average Steps

完成任务所需要的平均步骤数。

这个指标越低越好。

如果两个 Agent 都能够完成任务：

Agent A：25 steps
Agent B：19 steps

那么 Agent B 更高效。

4. Context Efficiency

衡量整个执行过程中平均使用了多少上下文 Token。

论文以 Standard 的上下文长度为：

100

%

100\\%

100%

然后比较 HiAgent 的相对比例。

例如：

64.98%

意味着：

HiAgent 使用的上下文 Token 约为 Standard 的 64.98%。

5. Run Time

衡量整个任务执行所需要的时间。

它可以体现：

• Prompt 是否过长；
• LLM 调用次数；
• 上下文长度；
• 摘要和检索带来的额外成本。

十一、主要实验结果

论文 Table 1 对 Standard 和 HiAgent 在五个任务上的表现进行了比较。

1. Success Rate 几乎翻倍

总体结果：

STANDARD：21.00%
HIAGENT：42.00%

即：

42

/

21

=

2

42/21=2

42/21=2

因此论文称：

HiAgent 将整体 Success Rate 提高到了 Standard 的约两倍。

这个结果是论文最核心的实验结论。

2. Progress Rate 提升 23.94%

总体：

STANDARD：38.61%
HIAGENT：62.55%

提升：

62.55

−

38.61

=

23.94

62.55-38.61=23.94

62.55−38.61=23.94

也就是说，即使没有完全完成任务，HiAgent 平均也能够推进到更深入的位置。

3. Average Steps 减少 3.8

总体：

STANDARD：26.41
HIAGENT：22.61

减少：

26.41

−

22.61

=

3.80

26.41-22.61=3.80

26.41−22.61=3.80

这说明 HiAgent 不仅更容易完成任务，而且：

完成任务所需要的动作更少。

在 Tyreworld 上尤其明显：

STANDARD：28.40
HIAGENT：19.00

减少：

28.40

−

19.00

=

9.40

28.40-19.00=9.40

28.40−19.00=9.40

4. Context 减少 35.02%

总体上下文使用：

STANDARD：100%
HIAGENT：64.98%

因此：

100

%

−

64.98

%

=

35.02

%

100\\%-64.98\\%=35.02\\%

100%−64.98%=35.02%

也就是说：

HiAgent 在平均上下文长度上减少了约 35%。

这正是论文所要解决的问题。

5. Run Time 减少 19.42%

总体：

STANDARD：100%
HIAGENT：80.58%

因此：

100

%

−

80.58

%

=

19.42

%

100\\%-80.58\\%=19.42\\%

100%−80.58%=19.42%

虽然 HiAgent 增加了：

• Subgoal 生成；
• Summary；
• Retrieval；

这些操作本身都需要额外 LLM 调用，但由于上下文明显缩短，整体运行时间反而下降。

十二、一个值得注意的实验现象

并不是所有任务的每个指标都提升。

例如 Gripper：

STANDARD PR：87.75
HIAGENT PR：86.25

HiAgent 反而下降：

87.75

−

86.25

=

1.50

87.75-86.25=1.50

87.75−86.25=1.50

但是：

Context：
100% → 49.99%

Time：
100% → 70.46%

上下文和时间成本都明显下降。

这说明：

HiAgent 的核心优势不是“每一个指标、每一个任务都严格单调提升”，而是整体上改善了长程任务中的成功率、上下文效率和执行效率。

十三、消融实验：到底是谁带来了提升？

HiAgent 有两个关键模块：

Observation Summarization
Trajectory Retrieval

论文在 Tyreworld 上进行了消融。

1. 去掉 Observation Summarization

结果：

SR：
60% → 30%

Steps：
19.0 → 24.2

Context：
100% → 110.8%

Time：
100% → 122.5%

也就是说：

Observation Summarization 是整个框架最关键的模块之一。

原因很好理解。

如果不总结：

过去 Subgoal
↓
仍然保留完整轨迹

那么所谓的层次化工作记忆就失去了最重要的压缩能力。

2. 去掉 Trajectory Retrieval

结果：

SR：
60% → 50%

Steps：
19.0 → 21.2

影响比 Observation Summarization 小，但仍然明显。

这说明：

摘要能够减少上下文，但 Retrieval 保证了 Agent 不会因为摘要而永久丢失细节。

两者实际上形成了互补：

Summary：
负责压缩

Retrieval：
负责恢复

3. 两个模块同时去掉

结果：

SR：
60% → 30%

PR：
75.8% → 62.4%

Steps：
19.0 → 26.2

这进一步说明：

HiAgent 的提升不是来自单纯的 Subgoal，而是来自完整的“子目标划分 + 摘要压缩 + 按需恢复”机制。

十四、HiAgent 到底是不是“Task Decomposition”？

这是论文里我认为非常重要的一组实验。

因为一个自然的质疑是：

HiAgent 的效果是不是仅仅因为让 LLM 先生成 Subgoal？

也就是说：

Standard：
直接生成 Action

HiAgent：
先生成 Subgoal
再生成 Action

如果只是增加一个 Subgoal，性能可能自然会提高。

因此论文额外构造了：

Task Decomposition（TD）Baseline。

它同样先生成 Subgoal，但：

不会隐藏过去子目标的详细轨迹。

也就是：

Task Decomposition：

Subgoal 1
Action
Observation
Action
Observation
…

Subgoal 2
Action
Observation
…

而 HiAgent：

Subgoal 1
Summary

Subgoal 2
Summary

Current Subgoal
Action
Observation
…

十五、Task Decomposition 实验

在 Tyreworld 上：

这里可以看到：

Task Decomposition 确实有效

10% → 40%

Success Rate 提升了 30 个百分点。

所以：

Subgoal 本身确实可以帮助 Agent 规划。

但是：

HiAgent 进一步提升

40% → 60%

并且同时：

Context：
112.8% → 73.6%

Time：
105.7% → 77.6%

因此论文证明：

HiAgent 的优势不能简单归因于 Task Decomposition。

真正的核心增量是：

Subgoal
+
Working Memory Compression
+
Trajectory Retrieval

十六、Long-Horizon 下为什么 HiAgent 更稳定？

论文进一步分析了不同 Step 数下的 Progress Rate。

结果显示：

随着任务步骤增加，HiAgent 与 Standard 的差距越来越明显。

例如 Blocksworld 和 Barman：

Step 15
↓
Step 20
↓
Step 25

Standard 的 Progress Rate 在较长任务中出现明显停滞。

而 HiAgent 仍然能够持续提高。

这说明：

HiAgent 的优势并不是短任务上的偶然优势，而是在任务越来越长的时候更加明显。

十七、为什么长任务中 Standard 会崩？

论文进一步分析了 Action 的 Executability。

所谓 Executability，可以理解为：

LLM 生成的动作是否满足当前环境的执行条件。

例如：

当前箱子是关闭的。

Agent：
从箱子中取出物品。

这个 Action 就不可执行。

1. Standard 的问题

随着工作记忆不断增长：

Context ↑
↓
历史信息越来越多
↓
LLM 处理难度 ↑
↓
状态理解能力下降
↓
不可执行 Action ↑

论文观察到，在 Blocksworld 中：

当步骤超过 20 后，Standard 的 Action Executability 会下降到 10% 以下。

这意味着：

长上下文不仅增加 Token 成本，还会直接影响 Agent 的行动质量。

2. HiAgent 更稳定

HiAgent 在更长步骤下仍然能够维持：

80% 以上的 Executability。

这说明：

Subgoal
+
Memory Compression

实际上帮助 Agent 保持了更清晰的当前状态。

因此，我认为论文的一个重要结论是：

上下文压缩不是单纯的工程优化，而可能直接影响 Agent 的决策能力。

十八、统计显著性实验

为了验证性能提升是否只是随机波动，论文使用：

Wilcoxon Signed-Rank Test

比较 HiAgent 和 Standard。

对于 Progress Rate：

p

=

2.38

×

10

−

5

p=2.38\\times10^{-5}

p=2.38×10−5

对于 Average Steps：

p

=

0.0016

p=0.0016

p=0.0016

两个结果均具有统计显著性。

因此论文认为：

HiAgent 在 Progress Rate 和 Average Steps 上的提升并不是简单的随机波动。

这一点比较重要，因为前面的任务数量并不算特别大，单纯看平均值容易高估偶然因素。

十九、HiAgent 与前面几类 Memory 方法的区别

结合之前阅读的 A-MEM、Mem0、MemoryOS、Nemori，可以发现 HiAgent 的问题定义其实不太一样。

这里存在一个非常重要的区别：

长期记忆：
过去很久以前发生过什么？

工作记忆：
我现在执行这个任务，需要记住什么？

HiAgent 主要研究后者。

二十、从“Memory”走向“Context Management”

我认为 HiAgent 最值得关注的地方，是它实际上把：

Agent Memory

进一步拆成了：

Long-Term Memory
↓
保存长期知识、经历、偏好

以及：

Working Memory
↓
当前任务执行所需的信息

HiAgent 研究的是第二种。

因此可以把 Agent 的整个记忆系统理解成：

Agent Memory
│
┌──────────┴──────────┐
↓ ↓
Long-Term Memory Working Memory
│ │
↓ ↓
长期事实/经历/偏好 当前任务状态
│ │
Retrieval / Recall Context Management
│
┌────────────┴────────────┐
↓ ↓
Compression Retrieval
│ │
↓ ↓
Summary Restore Detail

这也是为什么我认为 HiAgent 与前面那些 Agent Memory 工作具有互补关系。

二十一、我的理解和启发

1. Agent Memory 不应该只有“存”和“取”

之前很多 Agent Memory 方法的核心流程是：

交互
↓
写入记忆
↓
长期存储
↓
未来检索

HiAgent 让我意识到，还存在一个经常被忽视的过程：

交互
↓
进入当前 Working Memory
↓
当前阶段使用详细信息
↓
阶段完成
↓
压缩
↓
继续执行
↓
必要时恢复详细信息

因此，Memory 的生命周期实际上可以进一步扩展：

Raw Experience
↓
Working Memory
↓
Chunk
↓
Summary
↓
Long-Term Memory
↓
Retrieval

2. “什么时候压缩”本身就是一个决策问题

HiAgent 使用 Subgoal Completion 作为一个比较自然的压缩边界：

Subgoal 未完成：
不压缩

Subgoal 完成：
进行 Summary

这比简单地：

每 N 步压缩一次

更加合理。

因为压缩的真正语义应该是：

一个有意义的任务阶段已经完成。

所以未来的 Agent Memory 可以进一步研究：

什么时候应该压缩？
什么时候不能压缩？
压缩到什么程度？

这本身就可以成为一个 Memory Policy。

3. Summary 不应该只是文本摘要

如果把 Summary 仅仅理解成：

把过去几段话总结一下

其实低估了 HiAgent。

在 Agent 场景中，更重要的是：

Current World State
+
Task Progress
+
Important Preconditions
+
Completed Subgoals
+
Unresolved Issues

例如：

{
"subgoal": "拆卸旧轮胎",
"status": "completed",
"state": {
"old_tire": "removed",
"jack": "in_use",
"wrench": "held"
},
"unresolved": [],
"important_constraints": [
"new tire must be inflated"
]
}

这种结构化 Summary 可能比自然语言摘要更加适合 Agent。

二十二、对自己的 Agent 项目的启发

如果将 HiAgent 的思想放到实际 Agent Framework 中，我认为可以进一步设计成：

Agent Runtime
│
↓
Current Task
│
↓
Subgoal Planner
│
┌────────────┴────────────┐
↓ ↓
Current Subgoal Past Subgoals
│ │
↓ ↓
Detailed Context Summary
│ │
↓ ↓
Tool Calls Memory Store
│ │
└────────────┬────────────┘
↓
Context Manager
│
┌────────┴────────┐
↓ ↓
Compress Retrieve
│ │
└────────┬────────┘
↓
LLM

尤其是对于软件开发 Agent：

Task：
修复一个复杂 Bug

可以自动形成：

Subgoal 1：
定位 Bug

Subgoal 2：
分析调用链

Subgoal 3：
修改代码

Subgoal 4：
运行测试

Subgoal 5：
修复回归问题

当 Subgoal 1 完成：

Summary：
Bug 位于 xxx.py 的 xxx 函数，
根因是参数为空时没有进行校验。

之后就没有必要继续把：

grep
find
cat
sed
pytest
…

这些全部留在当前 Context。

但是如果 Subgoal 4 的测试失败：

Trajectory Retrieval
↓
恢复 Subgoal 3
↓
查看具体修改过程

这样就形成了一个非常适合 Coding Agent 的：

Hierarchical Working Memory。

二十三、HiAgent 的局限性

1. Subgoal 生成本身可能出错

HiAgent 的核心依赖：

LLM → Subgoal

如果 Subgoal 本身划分错误：

Subgoal 1：
做 A + B + C + D

Subgoal 2：
做 E

那么：

• Chunk 边界可能不合理；
• Summary 时机可能错误；
• 当前上下文仍然可能过长。

因此：

Subgoal Quality 是整个框架的重要前提。

2. Summary 可能丢失关键细节

压缩本质上意味着信息损失。

例如：

Summary：
已经完成文件修改。

但实际上：

修改了 file_a.py
修改了 file_b.py
修改了 config.yaml
测试 test_x 失败

如果 Summary 没有保留这些关键信息，后续 Agent 就可能无法正确决策。

因此，未来更好的 Summary 应该不是单纯追求：

越短越好。

而应该追求：

在有限 Token 下最大化任务相关信息。

3. Retrieval 触发也可能出错

如果 Agent 没有意识到：

过去某个 Subgoal 的详细轨迹很重要

那么它可能不会调用 Retrieval。

这会产生一种：

Information exists but is not retrieved

的问题。

因此，Trajectory Retrieval 本身也可以进一步变成一个学习型策略。

4. 当前实验任务相对受控

论文使用：

• Blocksworld；
• Gripper；
• Tyreworld；
• Barman；
• Jericho。

这些任务非常适合验证 Long-Horizon Planning 和 Working Memory。

但真实 Agent 通常还会面对：

• Web；
• Coding；
• 多工具调用；
• 多 Agent；
• 动态环境；
• 长时间运行；
• 多用户交互。

这些环境中的 Subgoal 边界可能没有这么清晰。

二十四、一个更完整的 Agent Memory 架构

结合 HiAgent 与前面阅读的其他工作，我认为未来的 Agent Memory 可以分成四层：

Layer 1：Raw Interaction
原始 Action / Observation / Tool Call

Layer 2：Working Memory
当前任务正在使用的详细上下文

Layer 3：Episodic / Long-Term Memory
已经完成任务的 Summary、经验和事实

Layer 4：Structured Memory
实体、时间、因果、任务、技能等关系

然后形成这样的生命周期：

Raw Interaction
↓
Working Memory
↓
Subgoal Completion
↓
Summarization
↓
Episodic Memory
↓
Structure / Index
↓
Future Retrieval
↓
Working Memory

这比单纯的：

Vector DB + Top-K

更加接近一个真正长期运行的 Agent Memory System。

二十五、总结

HiAgent 研究的是一个非常具体但非常重要的问题：

当 LLM Agent 执行 Long-Horizon Task 时，如何管理不断增长的 Working Memory？

它没有简单地删除历史，也没有把所有历史都永久保留。

核心机制可以概括为：

任务
↓
Subgoal
↓
Action / Observation
↓
Subgoal 完成
↓
Summary
↓
隐藏详细轨迹
↓
下一个 Subgoal

同时保留：

Past Subgoal
↓
Trajectory Retrieval
↓
恢复完整历史

因此，HiAgent 最核心的思想可以概括成：

让“子目标”成为工作记忆的基本 Chunk，让已经完成的任务阶段从“详细轨迹”逐渐退化为“状态摘要”，只有在需要时再恢复历史细节。

实验结果也验证了这一点：

• Overall Success Rate：21% → 42%，约提升 2 倍；
• Overall Progress Rate：38.61% → 62.55%；
• Average Steps：26.41 → 22.61，减少 3.8；
• Context：减少 35.02%；
• Runtime：减少 19.42%。

更重要的是，消融实验表明：

真正有效的并不只是 Subgoal Planning，而是 Subgoal + Observation Summarization + Trajectory Retrieval 形成的完整工作记忆管理机制。

如果用一句话概括 HiAgent：

HiAgent 将 Agent 的工作记忆从“保存所有历史轨迹”，转变为“以子目标为 Chunk、以摘要保存已完成阶段、按需恢复详细轨迹”的分层动态上下文。

参考资料

• Hu M, Chen T, Chen Q, Mu Y, Shao W, Luo P. HiAgent: Hierarchical Working Memory Management for Solving Long-Horizon Agent Tasks with Large Language Model. ACL, 2025.
• HiAgent 代码仓库