Working Memory：Agent 当前正在想什么？

上一节我们已经实现了 ContextBuilder，把真实 Agent 的输入从简单的：

System Prompt
+
用户问题

升级成：

System Prompt
+
Agent Rules
+
AGENTS.md
+
Skills
+
Memory
+
Conversation
+
Tool Results
+
Current Task

但只要 Agent 真正跑十几步，你会立刻遇到一个新问题，Conversation 和 Tool Results 越来越多，Agent 每一轮都要重新从头理解“我现在到底做到哪了”。

例如一个 Coding Agent 已经完成：

1. 看过项目目录
2. 读过 README
3. 跑过 pytest
4. 确认失败来自 requests 未安装
5. 已经排除数据库问题
6. 当前只需要确认 requirements.txt 是否缺失 requests

如果下一轮 ContextBuilder 只是把过去几十条消息全部塞给模型，模型就得重新从：

User
Assistant
Tool
Assistant
Tool
...

里自己恢复这些认知。

有时能恢复。

有时会漏。

有时会重复调查。

有时会把已经排除的方向又查一遍。

这就是为什么真实 Agent 还需要一个独立层，Working Memory。

它不是完整历史。

它更像 Agent 当前桌面上的“小白板”：

{
    "goal": "",
    "plan": [],
    "completed": [],
    "errors": [],
    "important_files": [],
    "next_action": ""
}

这里先把标题里的“正在想什么”说准确：它是一种便于理解的说法，不是让我们保存模型隐藏的推理过程。Working Memory 保存的是 Harness 能检查、能更新、能追踪的任务状态，例如目标、证据、假设、约束和下一步；模型内部逐字展开的思考既不需要保存，也不应该拿来充当事实。

这个边界很实用。看到“测试返回码为 1”，我们可以记录一条有来源的事实；模型觉得“可能缺少依赖”，只能先记为假设。前者来自环境，后者等待验证，不能因为都出现在 Memory 里就拥有相同可信度。

这一节我们会把这块“小白板”真正做出来。

开场引入

先看一个很真实的失败路径。

用户说，“帮我修复这个 Flask 项目为什么启动失败。”

Agent 开始：

Step 1
list_files()

Step 2
read README.md

Step 3
read app.py

Step 4
run_shell("python3 app.py")

Step 5
Observation:
ModuleNotFoundError: requests

Step 6
read requirements.txt

到这里，Agent 已经知道很多事实：

Goal：
修复 Flask 项目启动失败

关键错误：
ModuleNotFoundError: requests

重要文件：
app.py
requirements.txt

已完成：
看项目结构
确认启动命令
复现错误
定位到 requests 缺失

当前下一步：
确认 requirements.txt 是否声明 requests

如果我们把这些事实整理成：

working_memory = {
    "goal": "修复 Flask 项目启动失败",
    "plan": [
        "复现错误",
        "定位根因",
        "修复",
        "重新验证"
    ],
    "completed": [
        "已复现启动错误",
        "已确认缺失 requests"
    ],
    "errors": [
        "ModuleNotFoundError: requests"
    ],
    "important_files": [
        "app.py",
        "requirements.txt"
    ],
    "next_action": "检查 requirements.txt 是否缺少 requests"
}

下一轮模型一看就明白，“我们现在已经做到这里了。”

它不需要从十几条 Tool Result 重新推理。

这就是 Working Memory 的核心价值。

很多人会问，“那我不是已经有 messages 吗？”

有。

但 messages 回答的是，“发生过什么？”

Working Memory 回答的是，“基于已经发生的事情，现在最重要的认知是什么？”

这两个非常不一样。

比如历史里可能有：

Tool：
read README

Tool：
read app.py

Tool：
pytest failed

Tool：
search config

Tool：
read config

Working Memory 不需要把这些全部复制一遍。

它只需要提炼：

已排除 config 问题
当前根因集中在依赖缺失

所以 Working Memory 的本质不是“再存一份历史”。

而是，对当前任务状态的结构化压缩。

这也是为什么它会和 Context Compaction、Long-term Memory 不同。

Working Memory 是：

短期
当前 Run
当前任务
持续更新
允许覆盖

Long-term Memory 是：

跨 Session
长期保留
未来复用

这一区别我们后面会专门再展开。

知识地图

也可以把二者关系画得更直观：