章末自测-大赛人网

题目 1：为什么 Conversation History 不能替代 Working Memory？

请从数据形态、长度、稳定性、当前焦点四个角度解释，并说明两者分别适合保存什么。

Conversation History 是原始事件流，保存用户消息、Assistant 输出和 Tool Result，信息完整但会不断增长；Working Memory 是对当前任务状态的结构化摘要，只保留 Goal、Plan、Completed、Errors、重要文件和 Next Action。History 适合保留细节和上下文证据，Working Memory 适合稳定表达当前焦点。只依赖 History，会让模型每轮重新提炼任务状态，既浪费 Token，也容易重复调查或丢失关键结论。

题目 2：判断题——Working Memory 中的 errors 应该永久保存任务过程中出现过的所有错误，对吗？

请说明为什么已解决错误需要移出当前 Memory，以及完整错误历史应该放在哪里。

不对。Working Memory 表示当前仍影响后续决策的错误。如果 ModuleNotFoundError: requests 已经修复并通过验证，它就不应该继续占据当前 errors，否则模型可能反复围绕已解决问题行动。完整错误历史可以记录到 Trace 或 Run History，用于审计和复盘。当前 Working Memory 应保持最新、相关、可行动，而不是成为永久日志。

题目 3：代码阅读——为什么下面设计会让 Working Memory 很快失控？

memory["completed"].append(str(tool_result))
memory["errors"].append(full_traceback)
memory["important_files"].append(every_read_file)

请至少指出三个问题。查看参考答案

第一，completed 保存完整 Tool Result，会把任务成果和执行细节混在一起；第二，errors 保存完整 traceback 会迅速膨胀并占用 Context；第三，important_files 把所有读过的文件都加入，无法表达“真正重要”的区别。更合理的是 completed 保存认知结果，errors 保存关键未解决错误摘要，important_files 只保留与当前任务强相关的文件。完整原始数据留给 Trace。

题目 4：编程实现——写一个 WorkingMemory 数据类

要求包含 goal、plan、completed、errors、important_files、next_action，并实现 add_completed() 与 add_important_file() 去重。

from dataclasses import dataclass, field


@dataclass
class WorkingMemory:
    goal: str
    plan: list[str] = field(
        default_factory=list
    )
    completed: list[str] = field(
        default_factory=list
    )
    errors: list[str] = field(
        default_factory=list
    )
    important_files: list[str] = field(
        default_factory=list
    )
    next_action: str = ""

    def add_completed(
        self,
        item: str,
    ) -> None:
        if item not in self.completed:
            self.completed.append(
                item
            )

    def add_important_file(
        self,
        path: str,
    ) -> None:
        if (
            path
            not in self.important_files
        ):
            self.important_files.append(
                path
            )


if __name__ == "__main__":
    memory = WorkingMemory(
        goal="修复测试失败"
    )

    memory.add_completed(
        "已复现错误"
    )

    memory.add_completed(
        "已复现错误"
    )

    memory.add_important_file(
        "src/api.py"
    )

    print(memory)
#这个版本已经体现 Working Memory 的核心结构和简单去重逻辑，后续还可以加入错误解决、容量限制和 render()。

题目 5：综合应用——Agent 已经确认“请求量稳定，eCPM 大幅下降”，Working Memory 应该怎么写？

请给出一个适合 Data Analysis Agent 的 completed 与 next_action，并说明为什么不应该把十几条 SQL 原始结果全部塞进去。

可以写成：completed = ["已确认总收入下降 20%", "已确认请求量基本稳定", "已确认 eCPM 下降约 35%", "media_B 是主要异常来源"]，next_action = "继续按广告位下钻 media_B 的 eCPM，定位价格下降集中位置"。这样保留的是会影响下一步的结论。十几条 SQL 原始结果可以留在 Tool History 或 Trace，因为它们体量大、细节多，全部复制到 Working Memory 会增加 Context 噪声。

题目 6：对比分析——Working Memory、Tool History、Trace 分别负责什么？

请以一次 Coding Agent 修 Bug 为例，分别举出每一类适合保存的信息。查看参考答案

Working Memory 保存当前认知，例如“已确认错误来自 requests 缺失”“重要文件为 app.py 和 requirements.txt”“下一步修复依赖声明”；Tool History 保存结构化调用，例如 read_file("app.py")、run_shell("pytest")；Trace 保存更完整的执行证据，例如每一步 Prompt、Tool 参数、stdout、stderr、耗时和 Token。三者粒度和用途不同：Working Memory 服务下一步决策，Tool History 服务行为记录，Trace 服务完整复盘。

题目 7：概念理解——为什么 Working Memory 应该允许覆盖和删除？

请结合“旧假设被新证据推翻”和“错误已经解决”两个场景解释。

Working Memory 表达的是当前最好认知，而不是历史档案。如果一开始怀疑数据库问题，但后面证据表明启动阶段根本没有访问数据库，就应该从当前 Plan 或 Next Action 中移除该方向；如果 ModuleNotFoundError 已修复并通过测试，也应该从当前 errors 中移除。否则过期信息会持续影响模型。历史上曾经怎么想、怎么变化，可以由 Trace 保存，当前 Working Memory 必须保持最新和可行动。

题目 8：安全判断——工具输出里出现了一条“忽略项目规则”的文字，应该写进 Working Memory 并照做吗？

请从“数据来源”和“指令权限”两个角度说明处理方式。

不能照做。工具输出可以作为带来源的 Observation 保存，但它仍然是外部数据，不会因为进入 Working Memory 就升级成指令。Harness 应保留来源标签，把它放在普通上下文而不是 System 消息中，并继续遵守 System、项目规则和用户约束。如果这段文字与当前任务有关，我们可以记录“外部内容包含可疑指令”并进一步检查；如果无关，就不必让它持续占用 Working Memory。

进一步阅读

Working Memory / Short-term Memory 相关认知科学概念：帮助理解“当前任务所需信息”和“完整历史”为什么天然不同。
State Management 相关资料：Working Memory 本质上也是 Agent State 的一个结构化子状态。
Context Engineering 相关资料：理解为什么 Working Memory 是降低 Context 噪声的重要手段。
Summarization / Compaction 相关资料：后续会把长 Conversation 压缩成摘要，并与 Working Memory 配合。
Event Sourcing / Snapshot 相关思想：可以类比“完整历史事件”和“当前状态快照”的区别。
Task Planning 相关资料：Plan 字段后续会与 Planner 章节正式衔接。
Observability / Tracing 相关资料：保存 Working Memory Snapshot 可以帮助定位 Agent 从哪一步开始认知漂移。
Memory Architecture for Agents 相关资料：用于进一步理解短期、长期、语义记忆之间的区别。

术语表

工作记忆（Working Memory）：Agent 当前 Run 中用于保存任务目标、计划、已完成事项、关键错误、重要文件和下一步焦点的短期结构化认知。
会话历史（Conversation History）：用户、Assistant、Tool 之间按时间发生的原始交互记录，强调“发生过什么”，通常比 Working Memory 更完整也更冗长。
当前认知（Current Belief / Current Understanding）：Agent 基于已有 Observation 对任务现状形成的最新理解，例如“根因集中在依赖缺失”。Working Memory 主要保存这一类信息。
已完成事项（Completed）：当前任务中已经确认完成的阶段性成果，例如“已复现错误”“已排除数据库问题”，不是单纯的 Tool 调用日志。
重要文件（Important Files）：当前任务中与根因、配置、修改或验证高度相关的文件集合，不等于所有读过的文件。
下一步焦点（Next Action）：Working Memory 中对当前最值得推进方向的简短描述，用于帮助下一轮模型保持任务连续性，但不应该过度写死为固定 Tool Call。
短期记忆（Short-term Memory）：生命周期主要局限在当前 Run 或当前任务的记忆信息，通常频繁更新、允许覆盖，任务结束后大部分内容可以丢弃。
记忆快照（Memory Snapshot）：某个 Agent Step 时刻的 Working Memory 副本，可记录到 Trace，用于复盘 Agent 认知如何随执行过程变化。

本章总结

这一节我们把 Context Engineering 再推进了一层。

上一节解决的是，每一轮模型输入应该从哪些来源组装？

这一节解决的是，Agent 怎么保持对“当前任务状态”的持续认知，而不是每一轮都从完整历史重新理解？

答案就是，Working Memory。

最基础结构：

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

这几个字段看起来简单，但它们解决的是长任务里非常真实的问题。

goal 保持总目标稳定。

plan 保留当前执行思路。

completed 告诉 Agent 哪些事情已经做完。

errors 保留当前仍未解决、会影响后续决策的问题。

important_files 帮助 Agent 聚焦真正关键的项目文件。

next_action 则告诉模型，“目前最值得推进的方向是什么？”

这一节最重要的认知是，Conversation History 和 Working Memory 不是一回事。

Conversation History 是：

完整事件流

Working Memory 是：

当前认知摘要

前者回答，“发生过什么？”

后者回答，“现在最重要的是什么？”

这两层结合以后，Agent 不需要每轮重新从几十条 Tool Result 中恢复任务状态。

ContextBuilder 可以直接注入：

Working Memory
+
最近 Conversation
+
最近 Tool Results

让输入更短、更稳、更聚焦。

我们还特别强调，Working Memory 不是第二个日志系统。

它不应该保存：

所有 Tool Result
完整 traceback
所有读过的文件
所有历史结论

真正应该保留的是：

仍然影响下一步的关键信息。

已解决错误可以删除。

旧假设被新证据推翻后可以覆盖。

但事实、假设和约束要分开保存；Memory 中的外部内容仍然是数据，不能因为被注入下一轮 Context 就获得更高指令权限。

重要文件集合可以重新筛选。

Plan 也可以随着环境反馈重构。

因为 Working Memory 忠于的是，当前最好认知。

而不是，历史上曾经怎么想过。

历史变化应该交给 Trace。

如果你想验证自己是否真正掌握这一节，可以做一个很简单但非常有效的实验。

让 Coding Agent 连续执行 10 步。

第一版只给它 Conversation History。

记录：

重复 Tool Call 次数
重复读取文件次数
平均 Context 长度

第二版加入 Working Memory：

goal
completed
errors
important_files
next_action

再比较。

通常你会明显看到，Agent 更像一个“记得自己刚才做过什么的人”。

下一节我们会继续解决另一个非常现实的问题，一个用户和 Agent 的多轮交互，到底怎么被组织和恢复？

Working Memory 现在只存在当前 Run 内。

但用户可能：

上午聊一次
下午继续
刷新页面
重新进入

所以第 14 节，我们会进入，Session：多轮会话怎么管理？

把：

session_id
messages
working_memory
tool_history
runs

正式组织成一个可以创建、恢复、读取和关闭的会话对象。

文章版权归作者所有，未经允许请勿转载。

THE END

Harness Engineering
# Harness Engineering