goal 模式上下文压缩后，已完成进度和已确认决策被遗忘，导致任务从头重做、确认事项丢失
问题现象
在 trae IDE 的 goal 模式下，当会话发生上下文压缩（compaction）后，经常出现以下情况：
-
goal 中提到的任务被从头开始重新执行一遍，即使这些任务在压缩前已经完成。
-
上下文压缩前已经完成的进度被遗忘，agent 重复劳动。
-
通过 AskUserQuestion 向用户确认过、用户已明确指示要继续执行的问题或决策，在压缩后被遗忘，导致该做的没有做。
-
最终结果是：已经做完的事情反复做，确认过要继续做的东西却又没做。用户等待很长时间、消耗大量积分之后，得不到满意的结果。
复现步骤 -
在 goal 模式下启动一个多步骤、长时间的任务（goal 中包含多个子任务）。
-
在执行过程中，通过 AskUserQuestion 与用户确认若干关键决策，用户给出明确指示。
-
完成其中部分子任务。
-
触发上下文压缩（会话变长后自动触发）。
-
观察压缩后的行为：agent 是否记得已完成的工作、是否记得用户确认过的决策、是否从断点继续。
期望行为
上下文压缩后，agent 应当至少保留并知晓以下信息，并从断点处继续：
-
goal 中各子任务的完成状态（哪些已完成、哪些未完成）。
-
用户通过 AskUserQuestion 确认过的所有决策与指示。
-
当前进度位置，从断点处继续，而非从头重做。
实际行为 -
已完成的子任务被重新执行。
-
用户确认过的决策被遗忘，应当执行的未执行。
-
agent 从 goal 起点重新开始，而非从断点继续。
影响 -
严重浪费用户时间与积分：长时间运行后得到的是重复劳动和遗漏成果，而非有效产出。
-
破坏用户对 goal 模式的信任：用户无法依赖 agent 记住关键决策，被迫在每次压缩后重新交代背景、重新确认已确认过的问题。
-
goal 模式作为"长任务托管"的核心价值被削弱——本应让用户放心托付，实际却需要用户全程盯防压缩后的失忆，用户不敢发起长任务。
-
形成"越长的任务越容易失忆、越长的任务越需要重做"的负反馈，与 goal 模式鼓励长任务托管的初衷相悖。
环境信息 -
问题平台：trae IDE goal 模式
建议 -
上下文压缩时，应强制保留一份"进度快照"，至少包含：① goal 的任务清单及各项完成状态；② 所有用 AskUserQuestion 确认过的决策原文；③ 当前断点位置。
-
压缩后的 prompt 应明确指示 agent"从断点继续，不要重做已完成项"，而非让 agent 自行从 goal 文本推断进度。
-
可考虑在 goal 模式维护一个持久化的进度文件（由 agent 实时更新），作为压缩后的恢复依据，从根本上解决"压缩即失忆"的问题。