# [Bug] /compress 命令在对话历史接近上下文限制时失败，但自动压缩正常

[zhan5544]

Bug 描述

当对话历史接近模型的上下文窗口限制时，手动执行 /compress 命令会失败，但系统的自动压缩机制可以正常工作。

复现步骤

1. 进行长时间对话，使对话历史接近上下文窗口限制（如 glm-5 的 202,752 tokens）
2. 手动执行 /compress 命令
3. 观察压缩结果

实际行为

手动压缩失败，显示"聊天历史压缩未能减小大小"。

日志分析显示：

• 压缩 API 只收到了 29 tokens（压缩提示词本身）
• 模型"猜测"生成了 400+ tokens 的摘要
• 结果：压缩后 token 反而增加（200,060 → 201,515）

时间: 07:23:21 | /compress | 状态:2 | 原始:200,060 → 压缩后:201,515
时间: 07:23:54 | /compress | 状态:2 | 原始:200,060 → 压缩后:201,424

预期行为

压缩应该成功，或者给出明确的错误提示说明原因。

成功案例对比

在 07:26:07，系统的自动压缩机制触发，成功压缩：

时间: 07:26:07 | 自动压缩 | 状态:1 | 原始:202,738 → 压缩后:108,494

这次压缩 API 正确收到了 96,699 tokens 的对话历史，生成了 1,455 tokens 的摘要。

根本原因分析

1. 当对话历史接近/超过上下文窗口限制时，手动 /compress 的输入被截断
2. 系统只发送了压缩提示词（29 tokens），没有发送对话历史
3. 模型无法基于实际对话生成摘要，只能"猜测"
4. 自动压缩机制有不同的处理逻辑，可以正确处理这种情况

建议修复

1. 当检测到对话历史接近限制时，手动 /compress 应该使用与自动压缩相同的逻辑
2. 或者在输入被截断时，给出更明确的错误提示（如"对话历史过长，请等待自动压缩"）
3. 考虑在对话历史达到阈值时自动触发压缩，而不是等到用户手动执行

环境信息

• Qwen Code 版本: 0.12.6
• 模型: glm-5 (上下文窗口: 202,752 tokens)
• 操作系统: macOS (darwin)

相关日志

// 失败的压缩 API 调用
{
  "input_token_count": 29,
  "output_token_count": 393,
  "prompt_id": "compress-1774337022498"
}

// 成功的压缩 API 调用
{
  "input_token_count": 96699,
  "output_token_count": 1455,
  "prompt_id": "compress-1774337113019"
}

相关 Issue

• [Bug] web_fetch tool returns AI greeting instead of actual web content #2609 (web_fetch tool returns AI greeting instead of actual web content)