[s08_context_compact] Current user request may be lost after snip_compact

Author: ship-onwardCreated Sep 15, 2026Updated Sep 15, 2026

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 s01s05.

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 前期能够正常读取并分析 s08s09,但在执行了大量工具调用之后,突然重新回到了 Prompt 1,最终回答的也是旧任务,而不是当前任务。

下方截图可以直接看到这个过程:前面还在检查 s08 / s09,随后就切换回了 s01s05。(图片见英文版)

可能原因

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