Cursor Subagent 上下文窗口中途从 1M 缩到 300K 长任务会被截断
Cursor 3.19 中 subagent 在后台命令完成后自动恢复时，上下文窗口会从 1M 缩到 300K，触发压缩导致长任务上下文丢失。临时方案是禁止后台命令。
Cursor 3.19.13 有一个影响长任务的 bug：当你启动一个配置了 1M 上下文窗口的 subagent，它在运行过程中上下文窗口会被重置为 300K。如果现有上下文已经超过 300K，这会触发压缩，导致之前积累的上下文信息丢失。Cursor 工程师已确认在追踪中。
Bug 的表现
论坛用户 Mujahid Maqsood 在 9 月 10 日报告了这个问题，复现步骤如下：
- 创建一个
.cursor/agentsubagent，固定使用 Sonnet 5 模型和 1M 上下文窗口 - 在一个非 Sonnet 5 的主 Agent 会话（比如 Opus）里启动这个 subagent
- Subagent 启动时上下文窗口正确（1M）
- 运行过程中，上下文窗口降到 300K
用户原话："This is extremely catastrophic for long running tasks, as a healthy session can immediately turn into one that should be cancelled because of how much context is filled."
触发条件
Cursor 工程师 Mohit 确认了触发路径：当 subagent 在后台运行 terminal 命令，命令完成后 subagent 被自动恢复（auto-resume）时，恢复的那一轮使用的是 300K 窗口而不是 subagent 配置的 1M 窗口。如果现有上下文已经超过 300K，压缩会被触发。
正常轮次（非后台命令恢复）使用完整的 1M 窗口。问题只出在后台命令完成后的恢复轮次。
临时解决方案
Cursor 工程师建议在 subagent 定义里加一条指令：
Always run terminal commands in the foreground and wait for them to finish. Do not run terminal commands in the background.
这会降低 subagent 在后台运行长时间命令的能力（比如 npm test 或 docker build），但能避免触发 300K 窗口重置。
另一个相关 bug 是 subagent 冻结问题（9 月 10 日报告）：subagent 显示 "Stopped" 但主 Agent 显示 "Waiting for subagent"，需要手动发 "Continue" 才能恢复。Mohit 说 subagent 实际上还在后台运行，"Stopped" 是显示问题。
为什么这很重要
Subagent 的设计目标就是让主 Agent 委派子任务给专门的 Agent 处理。如果 subagent 的上下文窗口在长任务中不可预测地缩小，委派机制在长任务场景下就不可靠了。
这和 Auto 模式无限循环读文件 是同一类问题：上下文管理出问题时，Agent 行为会严重退化。Auto 模式是压缩后重复操作；subagent 是压缩后丢失上下文。
如果你在用 Cursor Projects 的协调 Agent + subagent 架构处理跨月的大型任务，这个 bug 的影响会被放大。建议长任务的 subagent 暂时避免后台命令，等 Cursor 修复后再恢复。