子代理也能提前自动压缩：autoCompactWindow
子代理常常比主会话更「吵」：要读一堆文件、跑一串测试、来回改代码。上下文涨得快，却一直跟主会话共用同一套自动压缩节奏——主会话还宽裕，子代理可能已经顶满，开始漏步骤或反复重读。
CLI 2.1.296 给子代理 frontmatter 和 --agents 定义加了 autoCompactWindow，让某个子代理可以比主会话更早触发自动压缩。
自动压缩窗口是什么
自动压缩（auto-compact）会在上下文接近上限时，把较早的对话整理成摘要，腾出空间继续干。窗口设得越大，越晚压缩；设得越小，越早压缩。
以前子代理大体跟着主会话的窗口走。长跑型子代理（全仓检索、大范围重构）容易先撑爆；主会话还在「没事」，子代理那边已经开始丢细节。
autoCompactWindow 怎么用
在自定义子代理的 frontmatter（或 --agents 里对应定义）增加 autoCompactWindow，把它设成小于主会话的值，子代理就会更早压缩。
示意（具体单位与合法取值以当前 CLI 文档为准）：
---
name: deep-reviewer
description: 长跑代码审查，上下文涨得快
autoCompactWindow: <比主会话更小的窗口>
---要点：
- 只影响这个子代理，主会话和其他子代理可以保持原样；
- 设得太小会频繁压缩，摘要变多、细节变少，审查类任务要权衡；
- 短任务、几步就结束的子代理，通常不用改，默认即可。
主会话侧若要按模型分别保存自动压缩窗口，可以结合站内关于 /autocompact 的说明一起看；本次新增的是子代理级覆盖。
什么时候值得开
- 长跑子代理：要扫大量文件、多次工具往返；
- 和工作流绑定的审查 / 测试代理：一轮任务很长，中间不能轻易失败；
- 主会话要保留完整思路：主会话窗口开大，子代理窗口开小，互不拖累。
不值得的情况：一两步就返回的轻量子代理——提前压缩收益很小，还可能多花摘要成本。
同版本：workflow 子代理统一模型
2.1.296 还加了环境变量 CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL：可以让所有 workflow 代理跑在同一个模型上，其他普通子代理仍用各自配置。适合「工作流里要稳定、可预期的模型，探索性子代理继续用别的档」这类分工。
另外，同版本给 529 过载重试补了 CLAUDE_CODE_OVERLOADED_RETRY_MAX_DELAY_MS（最大延迟上限）。之前讲过的基础延迟是 CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS；现在基础延迟和最大延迟都能调，无人值守长任务更稳。
小结
- 2.1.296 起，子代理 frontmatter /
--agents支持autoCompactWindow。 - 可让长跑子代理比主会话更早自动压缩，避免先顶满。
- 短任务保持默认；过小窗口会频繁摘要，按任务类型权衡。
- 可选：
CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL统一 workflow 代理模型；529 重试可用CLAUDE_CODE_OVERLOADED_RETRY_MAX_DELAY_MS拉长最大等待。
升级到 ≥ 2.1.296 后，给团队里最「吃上下文」的自定义子代理先试一个更小的 autoCompactWindow，观察是否还出现中途丢步骤或反复重读文件。