问题描述
在长对话的探索性场景中（方案设计、架构讨论、问题诊断），GA 有时会在多轮之后重新回到已经被用户明确否决或放弃的早期方向，表现为：
- Turn 1-5 探讨方案 A；Turn 6 用户否决 A 并转向方案 B；
- Turn 15+ 之后，GA 又提出方案 A 的变体，仿佛忘记了它已被否决；
- 用户需要反复纠正，影响长程探索效率。
这类问题的关键不是上下文长度本身，而是长对话中的「当前认知状态」缺少稳定、结构化的锚点：
- 当前采用的结论 / 方案是什么；
- 哪些方向已经被明确否决；
- 否决原因是什么；
- 哪些约束已经稳定成立；
- 哪些问题仍然开放；
- 已否决方向在什么条件下才允许重新讨论。
如果这些信息只散落在普通摘要或原始历史里，当历史被压缩、折叠或修剪后，模型就可能重新激活早期探索路径。
现有机制观察
GA 已经有 Stage 4 风格的工作记忆 / 锚点能力，可以作为解决这个问题的自然位置：
update_working_checkpoint 会写入 working['key_info'] / working['related_sop']，并返回 anchor，供后续轮次使用。- anchor 构造逻辑会把 earlier context、current turn、
key_info、related SOP 等内容注入后续上下文。
turn_end_callback 会解析 <summary> 并追加到 history_info，也会在一定轮数提醒 checkpoint / ask_user。agent_loop.py 会把 next_prompt 作为下一轮 user message 续写，因此 checkpoint / anchor 的内容确实会影响后续推理。llmcore.py 会压缩旧 anchor / tags，并在上下文过长时修剪历史；因此长对话中真正能稳定保留方向的，是 Stage 4 anchor / checkpoint，而不是完整原始历史。
因此，这个问题可以优先在现有 Stage 4 checkpoint 内解决：让 checkpoint 不只是记录「发生了什么」，而是明确记录「当前应该相信什么、什么已经排除」。
核心缺口
现有 checkpoint 更偏向任务进展摘要，缺少面向探索性对话的语义收敛结构。
一个普通 summary 往往回答的是：
这一轮发生了什么？
但长探索对话更需要 checkpoint 稳定回答：
经过这些讨论后，当前认知状态是什么？
尤其需要把「已否决方向」从普通历史信息提升为高优先级约束，避免模型后续把它当作仍可继续推进的候选方案。
建议方案：Stage 4 semantic convergence protocol
建议在现有 update_working_checkpoint / Stage 4 anchor 内引入一个结构化语义收敛块，例如：
### [SEMANTIC CONVERGENCE]
Current decision:
- 当前采用方案 B。
- 理由：...
Rejected alternatives:
- 方案 A
- Rejected at: Turn 6
- Reason: 用户明确否决，因为 ...
- Revisit only if: 用户重新提出，或出现新的约束/证据。
Stable constraints:
- ...
Open questions:
- ...
Next action:
- ...
也可以先用更轻量的中文结构合并到现有 key_info：
当前结论：...
已否决：
- 方案 A：Turn N 用户否决，原因是 ...；除非用户重新提出，否则不再回溯。
稳定约束：...
仍待决策：...
下一步：...
重点是让 Stage 4 checkpoint 从「进展摘要」升级为「当前认知状态」。
触发条件建议
可以先保持实现克制，只在 prompt / checkpoint 协议层增强：
-
用户明确否决或 pivot 时触发
- 例如：「这个方向不对」「不要这个方案」「改成另一个思路」「上个方案作废」等。
-
长探索对话达到一定轮数时提醒
- 现有代码中已经有轮数相关提醒，可以在类似位置提示更新 semantic convergence checkpoint。
-
用户手动调用 checkpoint 时增强模板
- 当调用
update_working_checkpoint 时，提示模型不仅写 key info，还要写清：当前结论 / 已否决 / 开放问题 / 下一步。
可选实现路径
Phase 1：增强 update_working_checkpoint 的提示协议
最小改动：不新增字段，只规范 key_info 的内容结构。
当任务包含方案探索、架构讨论、诊断路径切换时，key_info 应优先记录：
- current decision；
- rejected alternatives with reasons；
- stable constraints；
- open questions；
- next action；
- revisit conditions。
优点：
- 改动最小；
- 与现有 Stage 4 机制兼容；
- 能直接强化后续轮次的方向一致性。
Phase 2：增加显式 /solidify 或 /converge 命令
用户在感觉对话发散或方向切换后，可以手动触发：
系统要求模型输出并保存类似：
### [SOLIDIFIED]
当前结论：...
已否决：...
仍待决策：...
稳定约束：...
下一步：...
该块后续作为 Stage 4 anchor 的高优先级内容注入。
Phase 3：可选地拆分 checkpoint 字段
如果后续需要更强结构，可以把单一 key_info 拆成两类：
facts：稳定事实 / 环境信息；trajectory：当前探索路径、已否决方向、pivot 记录。
这能更清晰地区分「长期事实」和「探索轨迹」。
验证方式 / Acceptance Test
建议增加一个长对话回归测试，而不是只看普通摘要是否存在。
测试场景：
- Turn 1-5：讨论方案 A；
- Turn 6：用户明确否决 A，并转向方案 B；
- 触发 Stage 4 checkpoint，写入：
- B 是当前方向；
- A 已否决；
- A 的否决原因；
- 除非用户重新提出，否则不再回溯；
- 模拟后续长对话或历史压缩；
- 再询问「下一步怎么做」。
期望行为：
- Agent 沿方案 B 推进；
- 不重新主张方案 A 或 A 的轻微变体；
- 如果提到 A，只能作为「已否决项」或「除非用户重新打开」的历史说明，而不是作为建议方向。
注意：验证指标需要区分：
- 正确行为：在「已否决」字段中提到 A；
- 错误行为：重新建议采用 A。
不能用简单关键词命中判断是否回归，否则会把正确的 rejected list 误判为失败。
非目标
本 issue 不建议优先做以下事情：
- 新增独立于 Stage 4 的上下文层；
- 在
llmcore.py 中复杂改造压缩/裁剪逻辑；
- 简单删除早期讨论历史；
- 仅靠关键词过滤已否决方案。
原因是：问题核心不是「保存更多历史」，而是把关键决策状态写成后续轮次能稳定遵守的约束。
总结
建议增强 Stage 4 checkpoint 的语义收敛协议，让长探索对话在发生 pivot 后能稳定保留：
- 当前方向；
- 已否决方向；
- 否决原因；
- 开放问题；
- 后续行动；
- 回溯条件。
这样可以减少已否决方案在后续长对话中重新回流的问题。
问题描述
在长对话的探索性场景中（方案设计、架构讨论、问题诊断），GA 有时会在多轮之后重新回到已经被用户明确否决或放弃的早期方向，表现为：
这类问题的关键不是上下文长度本身，而是长对话中的「当前认知状态」缺少稳定、结构化的锚点：
如果这些信息只散落在普通摘要或原始历史里，当历史被压缩、折叠或修剪后，模型就可能重新激活早期探索路径。
现有机制观察
GA 已经有 Stage 4 风格的工作记忆 / 锚点能力，可以作为解决这个问题的自然位置：
update_working_checkpoint会写入working['key_info']/working['related_sop']，并返回 anchor，供后续轮次使用。key_info、related SOP 等内容注入后续上下文。turn_end_callback会解析<summary>并追加到history_info，也会在一定轮数提醒 checkpoint / ask_user。agent_loop.py会把next_prompt作为下一轮 user message 续写，因此 checkpoint / anchor 的内容确实会影响后续推理。llmcore.py会压缩旧 anchor / tags，并在上下文过长时修剪历史；因此长对话中真正能稳定保留方向的，是 Stage 4 anchor / checkpoint，而不是完整原始历史。因此，这个问题可以优先在现有 Stage 4 checkpoint 内解决：让 checkpoint 不只是记录「发生了什么」，而是明确记录「当前应该相信什么、什么已经排除」。
核心缺口
现有 checkpoint 更偏向任务进展摘要，缺少面向探索性对话的语义收敛结构。
一个普通 summary 往往回答的是：
但长探索对话更需要 checkpoint 稳定回答：
尤其需要把「已否决方向」从普通历史信息提升为高优先级约束，避免模型后续把它当作仍可继续推进的候选方案。
建议方案：Stage 4 semantic convergence protocol
建议在现有
update_working_checkpoint/ Stage 4 anchor 内引入一个结构化语义收敛块，例如：也可以先用更轻量的中文结构合并到现有
key_info：重点是让 Stage 4 checkpoint 从「进展摘要」升级为「当前认知状态」。
触发条件建议
可以先保持实现克制，只在 prompt / checkpoint 协议层增强：
用户明确否决或 pivot 时触发
长探索对话达到一定轮数时提醒
用户手动调用 checkpoint 时增强模板
update_working_checkpoint时，提示模型不仅写 key info，还要写清：当前结论 / 已否决 / 开放问题 / 下一步。可选实现路径
Phase 1：增强
update_working_checkpoint的提示协议最小改动：不新增字段，只规范
key_info的内容结构。当任务包含方案探索、架构讨论、诊断路径切换时，
key_info应优先记录：优点：
Phase 2：增加显式
/solidify或/converge命令用户在感觉对话发散或方向切换后，可以手动触发：
系统要求模型输出并保存类似：
该块后续作为 Stage 4 anchor 的高优先级内容注入。
Phase 3：可选地拆分 checkpoint 字段
如果后续需要更强结构，可以把单一
key_info拆成两类：facts：稳定事实 / 环境信息；trajectory：当前探索路径、已否决方向、pivot 记录。这能更清晰地区分「长期事实」和「探索轨迹」。
验证方式 / Acceptance Test
建议增加一个长对话回归测试，而不是只看普通摘要是否存在。
测试场景：
期望行为：
注意：验证指标需要区分：
不能用简单关键词命中判断是否回归，否则会把正确的 rejected list 误判为失败。
非目标
本 issue 不建议优先做以下事情：
llmcore.py中复杂改造压缩/裁剪逻辑；原因是：问题核心不是「保存更多历史」，而是把关键决策状态写成后续轮次能稳定遵守的约束。
总结
建议增强 Stage 4 checkpoint 的语义收敛协议，让长探索对话在发生 pivot 后能稳定保留：
这样可以减少已否决方案在后续长对话中重新回流的问题。