你有没有遇到过：刚开始聊天时，Agent 能准确复述要求；讨论了几十轮之后，它却把已经纠正的方案重新拿出来，甚至忘记“不要覆盖原文件”？问题可能出在信息没有进入本轮上下文，也可能出在摘要、检索或版本更新。本文用一个 PPT 项目案例，拆开 Agent 的短期记忆、长期记忆与上下文管理，附流程图、对照表和可本地运行的 Python 示例。

一、明明已经说过了，为什么 Agent 还是会忘？

先看一段虚构的项目对话。

第一轮，用户说：“帮我做一份演示文稿，最后导出 PDF。”第五轮，用户修改了要求：“改成 PPTX，后面还要编辑。”第十二轮，又补充：“只处理我确认的 v3，别覆盖原文件，也先不要发布。”

中间，Agent 查询了很多资料，读取了一批日志，修了几个版式问题。到了第三十轮，用户问：“现在可以导出了吗？”

结果，Agent 开始准备 PDF，还打算沿用旧版本。

这时候，用户很容易得出结论：模型记性不好。可从开发者角度看，真正的问题有好几种可能：

• “改成 PPTX”还在数据库里，但没有进入这一次模型请求。
• 历史被摘要后，只留下了最初的“导出 PDF”。
• 新旧要求都被检索出来，却没有标明哪一条已失效。
• 当前上下文被大量日志占满，关键约束被裁掉了。
• 信息确实进来了，但模型仍然没有正确遵循。

这些问题的表现相似，修法却不一样。没有把链路分清，往往会一边增加上下文长度，一边把同样的错误继续带下去。

本文的目标，是让“它怎么又忘了”变成几个能检查的问题：信息存在哪里、这一轮取到了什么、取到的是否仍然有效，以及模型最后有没有正确使用。

文中的项目、对话与代码数据均为教学设计，不是任何用户的真实聊天记录。

二、先分清：聊天记录、上下文、记忆和训练

日常交流中，我们会把“模型知道以前说过什么”统称为记忆。但开发时，这几个概念最好分开。

概念	它是什么	不能直接推出什么
聊天记录	应用保存的历史消息、工具交互等	保存了，不代表每次都传给模型
当前上下文	这次推理实际提供给模型的信息及相关状态	内容进入了，不代表一定被正确采用
短期记忆	支撑同一任务连续工作的近期交互和阶段信息	不代表跨任务永久保留
长期记忆	应用选择持久保存、以后按需调用的信息	不代表每次都会被召回，也不保证永远有效
模型训练	通过训练过程调整模型参数	把一条偏好写入数据库，不等于训练了模型

用一个不太严格但容易理解的比喻：聊天记录像档案柜，当前上下文像这次打开在桌上的材料，长期记忆像整理好的可复用卡片。档案柜很大，不代表桌上正在使用的材料齐全。

上下文窗口有容量限制，需要考虑输入、输出以及具体模型对推理 Token 的处理方式。容量、计费与接口细节应查看所用模型和 API 的说明，而不能简单按“多少个汉字”换算。官方会话与上下文说明

因此，“我们把所有记录保存到了数据库”和“Agent 能持续使用正确的信息”是两项不同的能力。前者解决存储，后者还需要筛选、更新、组装与验证。

更长的窗口，能解决一部分问题

更大的可用上下文，可以让应用在单次调用中携带更多材料。不过，如果旧要求没有作废、资料互相冲突，扩大窗口只是让更多矛盾一起进入请求。

反过来，窗口没有用满，也可能发生“忘事”：某条要求根本没有被召回，摘要写错了，或者组装请求时遗漏了它。排查时应该先确认实际输入，再讨论是否需要更长窗口或更强模型。

三、短期记忆：保留当前工作需要的连续性

短期记忆最重要的用途，是让系统知道“刚才做到了哪一步，以及这一轮还欠什么”。

放在 PPT 案例中，近期工作可能包括：用户刚确认了 v3，Agent 正在检查第 7 页的字体，工具已经返回“发生字体回退”，接下来要比较预览与导出结果。

如果只保留一句“正在处理 PPT”，系统虽然知道主题，却不知道具体目标、已验证事实和未完成动作。下一轮很可能重复检查，或者跳过必要步骤。

最近 N 条消息，并不等于最近 N 轮工作

一次用户请求之后，可能紧跟着工具调用、工具结果、多次追加检查，最后才是助手答复。如果按消息条数直接截断，恰好可能把调用留下、结果删掉，或者只保留一句没有来源的“已经完成”。

更合理的做法，是先定义应用里的完整单元：一轮用户交互、一个已完成的调用与结果组合，或 API 要求保留的会话项。再在不破坏协议关系的前提下做筛选。

例如，call-17 发出了字体检查请求，结果对应 call-17。只把结果改写成“第 7 页有问题”，会丢失它和具体动作、版本、页码的关联；原始记录仍应能够查回。

任务状态还要单独维护

“当前版本 v3”“导出格式 PPTX”“允许覆盖 false”这类字段，适合进入明确的任务状态。不能因为刚好保留在某段对话中，就完全依赖模型从长文本里重新推断。

任务状态更接近程序用来推进流程的依据；短期记忆则帮助模型理解连续交互。二者可以互相引用，但业务程序仍应根据受控状态决定能否执行写操作。

四、摘要：压缩的是历史，不能把关键约束压没

当历史不断增长，把较早内容整理成摘要，可以为后续工作保留线索。但摘要是一份派生内容，需要检查它保留了什么、遗漏了什么。

看两个例子。

不够用的摘要：

用户想做一份 PPT，已经讨论了样式和导出问题，继续完善即可。

更便于接手的摘要：

目标：定位并修复演示文稿的导出字体问题。
当前版本：用户确认的 v3；先不处理其他版本。
有效要求：输出 PPTX；不覆盖原文件；暂不发布。
已替代要求：第一轮的 PDF 导出要求已被第五轮纠正。
已观察事实：第7页存在字体回退，来源为 call-17 的检查结果。
待验证：修复后，预览与导出文件是否一致。
下一步：检查字体映射，完成后复核第7页。

第二份摘要更长，却保留了继续执行所需的信息。这里评价摘要的标准，应该是能否支持下一步正确行动，而不仅是压缩率有多高。

一份摘要，至少分清四种内容

用户要求、工具观察到的事实、助手提出但未确认的方案、仍然未知的问题，最好分别记录。

例如，“可能是字体回退”和“检查结果确认字体回退”不能混写。把推测压缩成事实，会让后面的决策建立在错误前提上；把“尚未确认发布”压缩成“准备发布”，也会改变实际边界。

生成摘要时，可以使用下面这份模板。它是任务交接结构，不是自动保证正确的咒语：

请依据原始记录，整理后续工作需要的摘要：
1. 当前目标及范围。
2. 已确认的有效约束，保留必要标识与版本。
3. 已完成动作及结果来源。
4. 已被纠正或作废的旧要求。
5. 未解决问题、失败与等待中的调用。
6. 下一步及其前置条件。

区分事实、推测、提案与授权；无法确认时写明未知。
不要把旧摘要中的结论直接当作新的证据。

OpenAI 的会话记忆示例对裁剪和摘要的取舍作了说明：裁剪可能丢掉较早信息，摘要则可能产生信息损失和偏差。具体策略需要结合自己的任务验证。会话记忆示例

不断“摘要的摘要”，需要格外留意

如果每次都只压缩上一份摘要，较早的错误可能被反复保留，来源却越来越难追。建议让摘要保留可回查的消息或事件标识，并在关键里程碑回到原始证据核对。

对于长代码、完整日志和大文档，通常可以保留结果摘要与定位信息，按需回读对应片段。真正需要逐字验证的内容，应以可核对的原文或产物为准。

五、长期记忆：值得复用，才值得留下

并不是所有对话都应该变成长期记忆。“这次先用蓝色”可能只针对当前封面；“以后技术文章优先用中文解释术语”才可能是一项跨任务偏好。

如果把偶然要求、临时状态和未经确认的建议全部长期保存，下次任务很容易被过期信息带偏。

我更倾向于先区分下面几类，再决定保存范围：

信息类别	示例	建议的使用范围
稳定偏好	技术说明优先中文，保留必要英文术语	经确认后可跨相关任务复用
项目约定	这个项目只交付 PPTX，不覆盖源文件	限定到对应项目与有效版本
工作方法	修字体后同时检查预览和导出文件	作为方法提示，使用前确认适用条件
阶段事实	v3 第 7 页尚未通过检查	放入任务状态，完成或变更后更新
临时材料	一次工具返回的大段调试日志	原始记录保留，按需定位读取

这些分类是本文的应用设计建议，并没有一个适用于所有 Agent 的固定目录结构。

让记忆带着来源和有效范围

下面是一条应用自行定义的记忆记录，字段不是任何平台的统一标准：

{
  "key": "export_format",
  "scope": "demo/project-ppt",
  "value": "PPTX",
  "source": "用户第五轮明确修改",
  "revision": 2,
  "status": "confirmed",
  "supersedes": "export_format@1",
  "updated_at": "2026-11-05"
}

这样，当系统再次取到旧的 PDF 要求时，可以知道它已经被替代。记忆应该允许更新、撤销和失效，而不是只有不断追加。

还要注意，“更新时间更近”并不意味着任何内容都能覆盖既有要求。另一项目的新日志不能覆盖本项目的约束，网页中的一句话也不能获得用户授权。比较新旧之前，先确认来源、范围与权限。

长期保存，不等于自动进入每一次上下文

记忆可以存成结构化表、文件或检索索引。向量检索有助于按语义找材料，但不是长期记忆成立的唯一方式。

如果只想保存一个明确的导出格式，按项目和键查询可能更直接；如果要在大量经验中寻找相似问题，语义检索才更有价值。应根据查询需求选择存储与检索方式，而不是先选数据库，再把所有东西都塞进去。

六、上下文工程：这一轮到底该让模型看到什么？

把历史存好以后，还需要一次“装配”：从可用资料中取出当前任务真正需要的部分，形成这一轮的输入。

在 PPT 案例里，用户此刻问的是“v3 的导出字体修好了吗”，这一轮优先需要的通常是：

1. 当前任务与有效约束。
2. 最近相关交互，以及不能断开的调用与结果。
3. 阶段摘要中的关键事实和待办。
4. 与字体问题相关、仍有效的项目记忆。
5. 用于核验结论的具体工具结果或产物信息。

早先讨论封面颜色的十几轮消息，未必需要全部展开。它们可以继续保存在历史中，等用户重新讨论封面时再取出。

先判断能不能用，再判断有没有用

检索命中一条记录后，至少还要看：是否属于当前用户和项目，是否已经作废，来源能否核对，和这次任务是否相关。

如果检索到了另一个项目的“导出 PDF”，即使相似度很高，也不应该进入本项目的有效要求。相似度表示内容相关程度，不代表权限、事实可信度或要求优先级。

因此，实际流程通常需要先限定可访问范围，再做相关性筛选和排序；返回给模型之前，再检查版本与失效状态。不能把检索分数当作唯一的通行证。

给输出和工具返回留出空间

假设应用给本轮工作设定了 12,000 Token 的教学预算，可以先安排一个如下的草案：

组成	示例预算	为什么需要它
固定指令与工具说明	2,000	明确能力和边界
当前目标与关键约束	1,600	保住正在完成的任务
近期交互与未闭合调用	3,200	保持执行连续性
阶段摘要	1,200	保留较早的有效进展
按需取回的记忆和证据	1,800	补充当前问题需要的资料
输出及必要余量	2,200	避免把可用空间全部用作输入
合计	12,000	仅为教学分配，不是固定比例

真实预算还要考虑接口封装、工具定义、图片等输入，以及所用模型的计数规则。不能用上表直接推算某个账号能跑多少轮。

当关键约束本身已经超预算时，应缩小任务、调整预算或明确报错。静默丢掉“不覆盖原文件”，让请求勉强发出去，会把技术上的容量问题变成业务上的行为错误。

七、裁剪、摘要、检索与压缩，怎么选？

这几个方法不是互相排斥的替代品，它们解决的问题有所不同。

裁剪：不再把一部分旧内容放进本轮上下文。实现容易理解，但要保护关键约束和完整交互单元。

摘要：把较长历史转成更短的描述。适合保留阶段进展，不过需要核对来源，处理遗漏、误写与过期结论。

检索：在需要时从外部存储取回相关信息。适合跨任务复用，但必须处理范围、版本和召回遗漏。

平台提供的上下文压缩：按具体 API 的机制，使用更紧凑的状态继续会话。它可能并不是一份能直接阅读、手动编辑的自然语言摘要。

例如，OpenAI 的 Compaction 文档说明了不透明压缩项及相应的输出处理要求。使用时应遵循接口约定，不能把自己生成的一段摘要当成同一种 API 状态。官方 Compaction 说明

在自己的项目里，可以组合使用：最近相关轮次尽量保留原文，较早阶段整理摘要，稳定信息进入受控记忆，长原文在需要时定位回读。

重点是让每一层有职责，而不是同时启用许多机制，却不知道某条要求究竟在哪一层丢失。

八、写一个可本地运行的上下文筛选器

下面用 Python 标准库演示四件事：范围隔离、版本替换、关键内容保护，以及预算不足时完整跳过可选块。

把代码保存为 context_demo.py，然后运行：

python context_demo.py

示例预算使用 UTF-8 字节，不是 Token。 这样不需要安装额外分词器，就能观察筛选逻辑。真实接模型时，必须换成与目标模型、请求结构匹配的计数方式，并计入其他输入和输出余量。

每个 recent 块在本例中已经整理成完整交互单元。程序没有解析真实 API 的消息协议，也没有自动生成摘要、执行向量检索或调用模型。

"""Offline context-selection demo. Byte budgets are NOT token budgets."""
from dataclasses import dataclass
import json


@dataclass(frozen=True)
class Block:
    key: str
    kind: str
    text: str
    scope: str = "demo/ppt"
    revision: int = 1
    active: bool = True


def render(block):
    return f"[{block.kind}:{block.key}@{block.revision}] {block.text}\n"


def build_context(blocks, scope, budget_bytes):
    protected = {"constraint", "current", "pending"}
    priority = {"recent": 0, "summary": 1, "memory": 2, "tool": 3}
    latest = {}
    for block in blocks:
        if block.scope != scope:
            continue
        if block.kind not in protected | priority.keys() or block.revision < 1:
            raise ValueError("无效类型或版本")
        key = (block.kind, block.key)
        old = latest.get(key)
        if old and old.revision == block.revision and old != block:
            raise ValueError("同一版本内容冲突，需要核对来源")
        if old is None or block.revision > old.revision:
            latest[key] = block
    # 先处理版本，再过滤失效项；避免撤销后旧记忆复活。
    active = [b for b in latest.values() if b.active]
    pinned = [b for b in active if b.kind in protected]
    optional = sorted((b for b in active if b.kind not in protected),
                      key=lambda b: priority[b.kind])
    selected = list(pinned)
    used = sum(len(render(b).encode("utf-8")) for b in selected)
    if used > budget_bytes:
        raise ValueError("关键上下文超预算：缩小任务或调整预算，不能静默删除")
    skipped = []
    for block in optional:
        size = len(render(block).encode("utf-8"))
        if used + size <= budget_bytes:
            selected.append(block)
            used += size
        else:
            skipped.append(block.key)
    return {"context": "".join(render(b) for b in selected),
            "included": [b.key for b in selected],
            "skipped_for_budget": skipped, "used_bytes": used}


def demo_blocks():
    return [
        Block("boundary", "constraint", "只处理已确认版本，不覆盖原文件。"),
        Block("goal", "current", "定位 PPT v3 的字体问题，暂不发布。"),
        Block("format", "summary", "导出 PDF。", revision=1),
        Block("format", "summary", "用户已改为导出 PPTX。", revision=2),
        Block("turn-3", "recent", "用户：检查第7页。\n"
              "调用 inspect_page(7)；返回：字体回退。"),
        Block("workflow", "memory", "字体修复后先检查预览，再比较导出结果。"),
        Block("large-log", "tool", "重复的逐页调试日志。" * 500),
        Block("other-project", "memory", "另一项目的独立需求。", scope="demo/other"),
    ]


if __name__ == "__main__":
    result = build_context(demo_blocks(), scope="demo/ppt", budget_bytes=700)
    print(json.dumps(result, ensure_ascii=False, indent=2))

运行后，可以观察到：

• boundary 与 goal 被保留，当前约束不会因为大日志挤入而消失。
• format 使用第 2 版的 PPTX 要求，旧的 PDF 要求被替代。
• 另一个项目的内容没有进入当前上下文。
• 大段重复日志因预算不足被完整跳过，并留下记录。
• 如果关键块本身就超预算，程序明确报错。

这个筛选器的优先顺序是为了方便演示而固定的，不能当成所有 Agent 的最佳策略。实际业务可能更需要某条近期工具证据，也可能需要针对不同任务动态安排预算。

这段代码最值得留意的两处

第一处是先确定最新版本，再过滤失效项。如果先把撤销记录删掉，再从剩余内容里找最新值，旧版本反而可能重新出现。

第二处是按整个块保留或跳过。程序不会把一条工具结果截成半句，剩下部分让模型猜。真实协议还要额外保护调用标识、结果对应关系及要求保留的状态项。

另外，示例里的 scope 只是演示命名空间筛选。生产环境需要真正的身份认证、授权和存储层访问控制，不能让外部调用方随意填写一个 scope 就访问别人的记忆。

这份程序输出的是上下文数据包，不是系统指令。来自网页、工具结果或记忆的文本，也不应因为被取回，就自动获得更高的指令权限。

我对教学代码做了九项离线检查，包括项目隔离、新版本替代、撤销不复活、关键内容超预算、块完整性和同版本冲突等，均通过。这些检查只验证确定性的程序分支，没有测量真实模型的长期记忆准确率。

九、记忆更新：纠正、撤销、冲突都要有路径

比起“又记住了一条”，实际项目更难处理的是“之前记住的那条，现在不适用了”。

场景 1：用户纠正了要求

从 PDF 改成 PPTX，应该表现为旧要求被新要求替代。程序可以保留历史以便追溯，但组装有效上下文时，不能把两条都当成仍然生效的指令。

若无法判断用户是在说当前项目，还是另一个交付物，应先确认范围。不要为了自动化，把含糊的表达强行写成全局偏好。

场景 2：助手提出了一个方案，但用户没同意

“建议把所有页面统一成某种字体”属于提案。只有得到相应确认，才能成为当前任务要执行的要求。

如果记忆提取器只识别关键词，把这句话保存成“用户要求统一字体”，下次读取时就可能产生越界修改。记录的 status、source 与范围应能反映这种区别。

场景 3：用户要求忘记某条偏好

这里需要处理的不只有主表中的一行。相关索引、派生摘要、缓存和后续召回入口，也可能残留旧内容。

应用应明确“删除”或“停用”的具体语义，并检查读取路径是否仍会把它重新带回来。如果只能完成部分范围，就应说明边界，不能把“主表已停用”描述成所有副本都已清除。

本文代码中的 active=False 只是逻辑失效标记，没有实现物理删除、索引清理或跨副本传播。

场景 4：摘要与原始证据冲突

假设摘要写“字体已修复”，原始检查却显示“预览正常，导出仍待验证”。这时应回到具体证据纠正摘要，并让依赖它的阶段状态同步更新。

不要把经过多次摘要的结论当作新的独立证据。重复出现十次的错误摘要，仍然只有同一个未经核对的来源。

OpenAI 的记忆与压缩示例也区分了帮助当前运行继续的压缩状态、供以后运行复用的记忆，以及供人核查的产物。本文采用的版本和撤销设计，是针对教学案例提出的应用层做法。记忆与压缩示例

十、怎么评测：记得多，还是用得对？

评估记忆系统，不能只问模型“你还记得我喜欢什么吗”。这种提问可能测到了复述，却没测到它能否在后续任务中正确行动。

围绕 PPT 案例，可以设计下面这组回放任务：

测试情形	要观察什么
很早说过“不覆盖原文件”，中间加入大量无关日志	后续执行仍保留该约束
PDF 要求后来改为 PPTX	使用新要求，旧要求不再生效
另一项目也有相似的导出讨论	不混入其他范围的信息
摘要把推测写成结论	能查回原文，识别并纠正冲突
最近一轮含工具调用与结果	裁剪后对应关系完整
记忆被撤销或到期	不继续从旧索引、摘要中取回
预算小到装不下关键约束	明确失败或调整任务，不静默删约束
长期偏好与用户本轮要求不一致	核对范围，按有效要求处理

至少把三段链路分开测

存储与更新：该保留的是否保留，旧版本是否正确失效。

检索与组装：这次该取的是否取回，错误范围的是否被拦住，关键内容是否完整进入输入。

模型使用：模型拿到正确材料以后，能否正确回答或选择动作。

前两段可以做不少确定性测试。第三段需要真实模型回放、业务规则检查或人工评审。不能拿筛选器的单元测试通过，替代对模型行为的评测。

建议记录的指标

关键约束保留率、过期信息误用率、错误范围召回次数、下一步动作正确率、实际输入量、端到端耗时，以及摘要和检索带来的额外成本。

例如，“关键约束保留率”可以定义为：应当进入该轮上下文的有效约束中，实际完整进入的比例。它不等同于模型遵循率；后者还要检查生成结果或实际动作。

比较策略时，使用同一批任务与相同成功标准。可以对比完整历史、仅保留近期、近期加摘要、再加长期记忆，观察质量、耗时与输入量怎样变化。没有跑出的结果，就保留为待测，而不是填写一个看起来漂亮的提升百分比。

OpenAI 的评估指南强调先定义目标和指标，再迭代样例与持续评估。上面的回放用例，是本文针对记忆问题的具体设计。评估方法参考

十一、几个经常混淆的问题

1. 缓存命中率高，为什么还是会忘？

Prompt Caching 与应用层记忆解决的是不同问题。缓存复用可匹配的提示前缀所对应的计算状态；它不会替你判断一条项目要求是否已失效，也不会保证业务事实正确。

如果固定前缀很长，命中率可能很好看，但本轮需要的“输出改成 PPTX”仍可能没有进入正确位置。反过来，摘要改变了前缀，缓存复用可能下降，任务表现却未必变差。

因此要同时看实际上下文、任务效果和总成本，不能用缓存命中率替代记忆质量。官方 Prompt Caching 说明

2. 开一个新对话，就一定解决了吗？

新对话可以减少旧材料的干扰，但也可能丢掉有效约束和已经确认的进展。更稳妥的做法，是带着一份经过核对的交接包继续。

交接包可以包含当前目标、有效版本、已完成事项、原始证据位置、未解决问题和禁止执行的动作。新对话是否能读取项目状态与长期记忆，还取决于具体应用实现，不能默认继承。

3. 做了长期记忆，还需要 RAG 吗？

它们可以共用某些检索组件，但管理对象和生命周期未必相同。知识库可能保存文档、手册和事实资料；记忆还可能保存用户偏好、项目约定或过去任务的方法经验。

在当前任务中，这些内容都可能成为上下文来源，但不能共用一套“命中就全部相信”的逻辑。文档版本、用户身份、项目范围和记忆有效性，仍然需要分别处理。

4. 能不能让另一个模型专门写摘要？

可以，但要测摘要质量、额外延迟与费用。重点是保住哪些内容、何时更新、怎样核对，以及出错后能否回查，并不在于一定要再增加一个模型角色。

本文的本地示例没有调用摘要模型。真正接入时，摘要请求本身也应纳入用量和耗时记录。

十二、落地建议：先做到能解释，再追求“永远记得”

如果正在做第一个带记忆的 Agent，我建议先从一个明确的任务开始，把有效约束和阶段状态拆出来，避免一开始就建设庞大的长期记忆库。

接着，保留完整近期交互，为较早历史设计可核查的摘要，再增加来源与范围明确的长期记录。最后才针对真实数据优化召回、排序、预算和压缩触发时机。

每轮组装上下文时，最好能够回答下面这些问题：

• 这次用了哪些材料，它们来自哪里？
• 哪些记忆被新版本替代，哪些已经失效？
• 哪些内容因为预算被跳过，是否影响关键约束？
• 未完成的调用和待办有没有保留？
• 最终结果出了问题，能否还原这一轮实际使用的上下文？

日志可以记录信息标识、版本、筛选原因和用量；是否保存完整内容，应结合隐私与访问控制要求决定。排错所需的可追溯性，不意味着把所有敏感内容复制到每一份日志中。

真正有用的记忆系统，应当让 Agent 在合适的时候取回合适的信息，并且知道哪些旧信息已经不能再用。保留更多内容只是手段，支持下一步正确行动才是目的。

---

资料与示例边界：文中 API 与压缩机制参考所链接的官方资料，核对日期为 2026 年 11 月 5 日。PPT 对话、记忆结构、预算分配、流程图和筛选代码均为教学设计；离线检查只覆盖程序逻辑，没有进行真实模型记忆效果或生产成本的对比实验。

你遇到过 Agent 忘记已确认要求，或者反复拿出旧方案的情况吗？欢迎在评论区分享具体场景：它忘的是一个事实、一条约束，还是整个任务进度？