[s08_context_compact] Current user request may be lost after snip_compact
Title
[s08_context_compact] Current user request may be lost after snip_compact
English
Problem
I found a possible issue while testing s08_context_compact with the example prompts from the README.
I entered all three example prompts sequentially in the same CLI conversation:
Prompt 1
请读取 s01_agent_loop 到 s05_todo_write 五节课程的 README.md,
比较它们的一级标题,并总结这些标题的命名规律。
Prompt 2
请分析 web/src/data/generated/docs.json 的数据结构,
并说明一条课程记录包含哪些主要字段。
Prompt 3
请比较 s08_context_compact/code.py 和 s09_memory/code.py,
并说明它们分别怎样管理当前上下文和持久记忆。
While processing Prompt 3, the agent initially read and analyzed s08 and s09 correctly. However, after many tool calls, it unexpectedly returned to Prompt 1 and finally answered the old task instead of the current one.
The screenshot below shows this transition directly: the agent is still inspecting s08 / s09, then immediately switches back to s01–s05.
Possible Cause
snip_compact() keeps the first few messages and the most recent messages:
head_end = 3
tail_start = len(messages) - (max_messages - head_end - 1)
During a long tool-use loop, the current user request may move into the archived middle section.
Although active_request is available in prepare(), it is only explicitly reinserted when compact_history() or reactive_compact() runs.
So this sequence seems possible:
many tool calls
→ snip_compact()
→ current request is archived
→ context is now below the limit
→ compact_history() is not triggered
→ active_request is no longer visible to the model
Possible Fix
Ensure that the current active_request is still present in the model-visible context after snip_compact().
For example, snip_compact() could preserve the current request explicitly, or the harness could reinsert a dedicated Current user request message after structural compaction.
Context compaction may archive history, but it should not remove the currently active user request from the model-visible context.
中文
问题描述
我在按照 README 中提供的测试用例测试 s08_context_compact 时发现了一个可能的问题。
我将 README 中的三条测试 Prompt 连续输入在同一个 CLI 对话窗口中:
Prompt 1
请读取 s01_agent_loop 到 s05_todo_write 五节课程的 README.md,
比较它们的一级标题,并总结这些标题的命名规律。
Prompt 2
请分析 web/src/data/generated/docs.json 的数据结构,
并说明一条课程记录包含哪些主要字段。
Prompt 3
请比较 s08_context_compact/code.py 和 s09_memory/code.py,
并说明它们分别怎样管理当前上下文和持久记忆。
在处理 Prompt 3 时,Agent 前期能够正常读取并分析 s08 和 s09,但在执行了大量工具调用之后,突然重新回到了 Prompt 1,最终回答的也是旧任务,而不是当前任务。
下方截图可以直接看到这个过程:前面还在检查 s08 / s09,随后就切换回了 s01~s05。(图片见英文版)
可能原因
snip_compact() 会保留最前面的几条消息和最近的消息:
head_end = 3
tail_start = len(messages) - (max_messages - head_end - 1)
当一次任务产生大量工具调用时,当前用户请求可能进入中间区域并被归档。
虽然 prepare() 中保存了 active_request,但只有触发 compact_history() 或 reactive_compact() 时,它才会被显式重新加入模型上下文。
因此可能出现:
大量工具调用
→ snip_compact()
→ 当前请求被归档
→ 上下文已经低于限制
→ 不触发 compact_history()
→ 模型看不到 active_request
可能的修复方式
在 snip_compact() 之后,确保当前 active_request 仍然存在于模型可见的上下文中。
例如,可以让 snip_compact() 显式保留当前请求,或者在结构压缩后重新加入一条独立的 Current user request 消息。
上下文压缩可以归档历史消息,但不应该把当前正在执行的用户请求从模型可见上下文中删除。
Source: shareAI-lab/learn-claude-code