## 使用 Memory 定义 Memory 在 AgentTeam 里的职责边界，并说明什么信息应该进入 Memory。 本章讨论的是产品层 Memory，不讨论底层存储实现细节。 ```text 请判断下面这些信息是否值得写进 Memory： 1. 客户长期偏好的输出格式 2. 某次会议里临时提到的想法 3. 团队已经确认的术语表 4. 这次任务的附件内容 并说明理由。 ``` ### Memory 的职责 Memory 用来保存会跨任务复用的长期信息。 它服务的不是“当前这次任务马上要怎么做”，而是“以后这个 Agent 再遇到类似任务时，需要继续知道什么”。 在 AgentTeam 中，Memory 同时也是一种受管理的长期记忆资源。它可以在 workspace 内被创建、授权、共享、派生，并通过显式绑定关系接入 Agent，作为 Agent 在后续任务中持续使用的长期背景。 在产品层面，Memory 最适合承载 4 类内容： - 长期稳定的团队事实 - 客户或用户的持续偏好 - 会反复复用的工作约束 - 已经验证有效、值得长期保留的协作经验 ### 哪些信息值得进入 Memory 典型的可写入内容包括： - 某个客户长期要求评审结果必须单列 blocker - 团队固定使用的一套术语、命名规则或交付结构 - 某类项目默认使用的工作流、模板或审批边界 - 长期不会频繁变化的项目事实和背景 这些内容的共同特征是： 1. 会跨任务继续使用 2. 对后续判断持续有价值 3. 不是只针对某一次对话 4. 适合作为可维护、可共享的长期知识基线 ### 哪些信息不应该进入 Memory 不要把短期聊天记录整段塞进 Memory。 也不要把一次性任务要求、临时附件内容、尚未验证的想法、或者很快就会过期的状态直接写进 Memory。否则 Memory 会迅速从“长期资产”退化成“历史噪音仓库”。 以下内容通常不值得长期保存： - 本周临时要赶的一个节点 - 某次讨论中的未确认猜测 - 当前任务附件的原文复制 - 只会出现一次的客户临时要求 ### Memory 的共享、授权与绑定 在产品使用上，可以把 Memory 理解为一份可长期维护的记忆资产。 它通常有 4 个关键动作： - **共享**：把一份受管理 Memory 共享给 workspace 内其他成员使用 - **授权**：按权限控制谁可以查看、谁可以维护、谁可以继续用于绑定 - **派生**：从已有 Memory fork 出副本，形成新的记忆分支 - **绑定**：把某一份 Memory 显式绑定到指定 Agent，作为这个 Agent 的长期记忆来源 这套机制适合团队协作场景：团队可以维护一份公共 Memory 基线，也可以在此基础上派生出面向不同角色、不同客户或不同项目的专用版本。 ### Memory 与其他层的关系 Memory 不是 Role。 Role 负责定义职责边界；Memory 负责提供长期背景。 Memory 也不是 Skill。 Skill 负责定义稳定做法；Memory 负责保存长期事实和偏好。 Memory 还不是当前上下文。 当前上下文解决“这次具体要做什么”；Memory 解决“以后类似任务还要继续记住什么”。 ### 什么时候应该更新 Memory 不是每次任务结束都要写 Memory。 更合理的时机是： - 团队确认了一条会长期复用的规则 - 某个客户偏好已经被反复验证，不再是临时例外 - 某个工作流或模板已经稳定，值得在后续任务继续沿用 - 一条背景事实会持续影响后面的判断 如果只是临时例外，直接留在本次任务上下文即可，不要急着固化进 Memory。 ### 写得太多和写得太少都会出问题 Memory 写得太少，Agent 每次都要重新问相同背景，团队无法积累复用收益。 Memory 写得太多，则会出现相反问题： - 过期信息干扰当前判断 - 真正重要的长期事实被埋没 - Agent 在不该带入历史的地方带入了陈旧偏好 因此，Memory 的关键不在于“存得越多越好”，而在于“只保留对后续判断持续有价值的信息”。 对共享 Memory 的写入标准，最好由团队明确：什么算长期事实、什么只是临时上下文。 常见反例： - 把客户所有聊天原样归档进 Memory - 把一周后就失效的状态当成长期事实保存 - 把本来应该写成 Skill 的流程说明塞进 Memory 会影响多个 Agent 判断的共享 Memory 规则，最好经过一次同行确认。 来自外部系统的长期稳定事实可以进入 Memory；一次性抓取结果应优先留在当前任务上下文。 读完本章后，读者应该能判断哪些信息值得长期进入 Memory，哪些信息只应留在当前任务里。