[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 消息。

上下文压缩可以归档历史消息，但不应该把当前正在执行的用户请求从模型可见上下文中删除。

Start with s08_context_compact/code.py and inspect snip_compact(), prepare(), compact_history(), and reactive_compact(). Reproduce the three sequential README prompts in one CLI conversation, then verify that after structural compaction the active request remains model-visible and Prompt 3 is answered rather than an archived request.