长任务前何时压缩上下文：Claude Code实战经验

在让 Claude Code 花大量时间阅读代码、进行修改和运行测试之前，不要急着清除上下文。也不需要为了"充分利用 100 万 token"而保留每一条旧的讨论。

先问更有用的问题：下一步仍然需要哪些原始细节？你计划委托的工作能否独立完成？任务完成后，你如何判断这个改动是否真的有帮助，而不仅仅是减少了用量数字？

9 月 19 日，ZryMiller 描述了他方法上的一个变化。他之前经常进行压缩，后来又回到了他所说的默认 100 万 token 窗口。他感觉体验明显改善了，并表示正准备发布他的第一个应用。但帖子中没有可比较的任务、没有前后的用量数据、也没有表明应用最终已发布的成果。这是实用的个人反馈，但不能作为"从不压缩能让所有长任务都更顺利"的证据。

与其在"经常压缩"和"从不压缩"之间选择，不如在工作的特定边界处做出决定。

首先，确认你正在使用的版本

在终端运行 claude --version 并记录客户端版本。进入会话后，用 /status 检查账户和当前模型，用 /model 查看可用模型及相关设置，用 /context 检查上下文使用情况。需要用量信息时运行 /usage。这些命令显示的内容不同，不是可互换的测量方式。官方命令参考 · 用量文档

本文讨论的官方模型名称是 Claude Fable 5.1，其 Claude API 模型 ID 为 claude-fable-5-1，官方规格列出的是 100 万 token 上下文窗口。模型、Claude Code 版本和 effort 设置是不同的细节。不要简单地把它们记录为"用了 Fable"或"用了 Ultra"。官方模型规格

支持 100 万 token 的模型并不意味着每个账户、每个模型和每条访问路径都自动具有相同的使用条件。例如，官方文档区分了 Opus 100 万包含在 Max、Team 和 Enterprise 计划中，而 Pro 计划需要使用量额度。Sonnet 4.6 的 100 万窗口在订阅计划中也需要使用量额度。不要把这些规则直接应用到其他模型上。客户端配置、模型映射和网关支持也需要检查；在选择器中添加 [1m] 本身不能扩展服务器端模型的能力。100 万资格与模型配置

还要区分三个容易混淆的数字：上下文用量告诉你当前请求需要容纳多少内容；累计 token 用量记录请求已处理的输入、输出和缓存内容的总量；订阅额度是账户在适用使用窗口内的限制。五小时或一周描述的是一个额度窗口，而不是保证任务能连续运行五小时或一周。缓存内容仍然占用上下文，尽管 API 计费可以适用不同的缓存费率。因此，"已用 30% 上下文"不能换算为"已用五小时额度的 30%"，而 100 万也不是你可以重复免费处理的 token 额度。上下文与缓存 · API 定价结构

压缩前，考虑下一步仍然依赖什么

假设你正在调查一个跨越前端、API 和数据库的 bug。你刚读完几段代码、检查了一个失败的请求、注意到了一个边缘情况，但还没有得出可以验证的结论。如果仅仅因为"对话变长了"就压缩，可能会丢失你接下来最需要比较的细节。

相反，如果根本原因已经清楚，相关文件和证据位置已记录在案，下一步是基于商定计划的小规模实现改动，那么早期的搜索过程大部分可能不再需要保留在当前窗口中。

压缩的好时机不是通用的百分比。它是一个已完成阶段的结束，此时可靠的记录足以继续工作。这是一条工作流程建议，不是固定的模型阈值。

首先，让 Claude 把必要状态写入你指定的任务记录中：已确认的事实和证据位置、实际改动的文件、实际运行的检查及其真实结果、未解决的问题，以及下一步。不需要复制整个对话，未经证实的猜测不应变成结论。

然后使用原生的 /compact 命令，指定应保留的内容：

/compact Keep the current goal, confirmed conclusions and evidence locations, changed files, checks actually run and their real results, unresolved issues, and the next step. Remove repeated searches and discussions that have already been ruled out.

这段文字是对摘要的请求，而不是保证不会丢失信息。在进行进一步改动之前，让 Claude 用压缩后的上下文解释下一步操作，并与实际文件和任务记录核对关键约束。先恢复任何缺失的边缘情况，而不是等实现漂移后需要返工。

如果下一个任务无关，通常更直接的做法是保存当前结果和交接信息，然后用 /clear 开始新会话。如果需要返回原始对话，使用 /resume。清除会话不会退还已产生的用量，也不会重置订阅额度。会话命令 · 用量显示中重置什么

Claude Code 已经有自动压缩功能，所以你不需要安装插件来遵循这个方法。v2.1.221 及更高版本也提供 /autocompact：不带参数时显示当前自动压缩窗口；/autocompact auto 恢复模型调优的窗口设置。后者保存的是一个设置，而不仅仅是对模型的偏好。模型的最大上下文窗口和其自动压缩窗口不是同一回事。自动压缩命令

HKTECH_AI 估计，单次压缩可能消耗约五小时额度的 15%。帖子没有提供账单或计算方法，所以这个百分比不应成为操作规则。重要的是压缩是否减少了后续请求中重复携带的内容，以及是否也导致了重读、重新解释或纠正。

子智能体可以分担工作，但"一次一个"取决于你如何执行

SHCH 分享了一种角色划分：Fable 负责规划和判断，Sonnet Scout 负责搜索，Opus Builder 负责执行明确定义的任务。他特别建议一次只调用一个子智能体。

他发布的 Builder 截图强调遵循现有计划、在计划有问题时停下来报告、不启动更多子智能体，以及报告检查结果。这些指令的价值在于明确了职责。但截图中的"不要启动更多子智能体"仍然是提示级别的约束，而不是软件层面的限制。作者还提到运行多个主会话，但没有发布可验证的前后用量。因此这个设置不能被解读为"整个账户只有一个智能体"，更不是固定百分比节省的承诺。

一个普通的子智能体从自己的上下文开始，接收委托的任务和相关配置。它不会自动获取主会话的整个聊天历史；fork 子智能体继承现有对话。把嘈杂的调查移到子智能体中可以减少直接保存在主会话中的过程细节，但子智能体的请求仍然处理 token，其返回的结果也会进入主会话。子智能体上下文边界

所以先问"这个任务值得委托吗"，再问"应该同时运行多少个"。简单的查找不需要完整的规划器、研究员和执行器。两个会重复编辑同一文件的任务也不是并行工作的好候选。真正独立的、有明确交付物的调查才是并行比较的好候选。

你可以把工作指令写得更具体，例如：

Goal: Complete the agreed changes and pass the directly relevant checks.
Allowed scope: The implementation and corresponding tests involved in this request.
Execution: Perform simple lookups directly. When delegation is necessary, provide only the context and deliverable requirements the subtask needs, and assign one subagent at a time. Do not repeatedly query the same status while waiting.
Completion criteria: Deliver against the acceptance requirements and stop once the relevant checks pass. If blocked, report what is complete and why progress is blocked; do not restart the same task.

这些仍然是行为指令。若要真正限制原生子代理的创建，需要使用客户端控制。Claude Code v2.1.217 及更高版本支持并发和委托深度限制。以下是适用于 macOS 和 Linux 的 Bash/Zsh 启动示例，是一个保守的起点，用于调查不必要的并行工作：

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

第一个变量在通过 Agent 工具创建新子代理时对该会话应用并发检查。第二个变量将子代理限制为一级，防止进一步的嵌套委托。它们不是提示词，也不会 retroactive 地更改其他已在运行的会话。

但这并非一个全局锁，并非保证"任意时刻最多只有一个代理"。官方文档明确列出了例外情况：ultracode 会话不强制执行此并发限制；手动 /subtask 调用和恢复已完成的子代理不受相同的新建检查阻塞；workflows 和 agent teams 有各自的限制；此单一设置也不会联合控制多个主会话或外部启动的进程。

如果你自己的调度器需要一个真正的全局限制，需要用队列或并发锁来协调启动、恢复和重试，而不是在提示词中依赖"一次一个"。这是你自己的调度实现的一部分，而不是另一个未文档化的 Claude Code 设置。

等待结果并不意味着让模型不断检查进度

LeeLeepenkman 描述的不仅仅是"使用子代理"。他描述的是 Fable 5.1 向 muse 发送一个大提示词，然后大约每五秒轮询一次，导致上下文快速增长。原文没有解释 muse 的实现、没有提供请求记录，也没有报告解决后的结果。因此不能将五秒描述为 Claude Code 固定的轮询间隔。

原生后台子代理目前提供完成通知，结果在后续轮次中传回主会话。你可以使用 /tasks 检查运行中的工作。这与反复让模型发出新的"它完成了吗？"请求不同。

在调查时，展开会话的工具记录并追踪同一任务：重复检查是否产生了新信息？已完成的任务是否被重新启动？状态检查是否实际上触发了一次新的模型调用？Ctrl+O 打开更详细的对话视图，但界面刷新次数不能被视为模型请求次数。对于请求级别的使用，也要检查你实际使用的服务商记录。

使用原生通知时，由模型驱动的高频检查循环通常是不必要的。如果外部工具只支持轮询，让程序以合理的间隔等待状态变化，设置超时，仅当有新结果或异常时才将信息传递给模型。目的是减少不增加信息的模型调用，而不是禁止必要的进度监控。

配额重置后，首先检查还有什么需要做的

intwerpret 报告了一次更剧烈的体验。在达到用量限制后，他选择等待并自动继续，然后声称出现了 39 个代理并再次耗尽了配额。他最终切换回了 Codex。这些材料没有包含客户端版本、任务详情、完整配置或恢复机制的识别。任务最终是否完成也不得而知。

这份报告是检查恢复工作流的原因，而非"Claude Code 自动恢复总是启动 39 个代理"的证据。他使用"Ultra"一词也不足以确定他运行的是上述讨论的 ultracode 模式。

同时，自动继续已不能再完全归因于第三方脚本。官方交互文档描述了配额限制重置后的原生继续行为：从 v2.1.234 开始，符合条件的交互式订阅会话可以等待配额重置然后继续工作。这不应与 API key 会话、-p 或每种后台模式的行为混为一谈。恢复也不是简单地重发用户最后的原始任务。

如果你不希望任务无人值守地恢复，请在 /config 中关闭"Continue automatically at usage limit"。在支持该设置的版本上，你也可以运行：

/config autoContinueAtUsageLimit=false

如果会话已经在等待，也请取消那个特定的等待：在空输入框中按 Esc，或在 /rate-limit-options 中使用"Don't continue automatically"。更改默认值和取消你已经选择的等待不是同一个操作。

接下来，检查 /tasks 和文件的实际状态。哪些任务仍在运行，哪些已完成，哪些只需要一次验证即可？重用现有结果并指定未完成的工作应如何继续，而不是重新发送整个请求并让它再次分解工作。

对于提交、部署、消息或其他具有外部影响的操作，首先确定前一次尝试是否成功。配额重置只回答"请求能否继续？"不保证"下一个操作不会是重复的"。

在确定用量已改善之前先检查结果

chasemdev 解释说，他并不是让 Fable 自己编写所有代码；而是用它来编排 Opus 子代理。他仍然预计很快就会达到周限额。"很快"是作者当时的预测，而非经验证的最终用量结果。但这凸显了一个容易从记录中遗漏的事项：包含子代理的模型和工作，而不仅仅是主模型。

/usage 的 Session 部分目前显示会话令牌用量和本地计算的成本估算。订阅用户也在同一界面中看到计划用量。Session 中的美元数字不是订阅账单，也不一定等于 API 服务商的最终收费。按量付费用户应参考其实际服务商的账单。

订阅用量的本地归属也只是一个线索。子代理、插件、技能及相关组件的明细来自本机的最近历史。它们不涵盖来自其他设备或网页的完整用量，也不是"某个插件造成了多少浪费"的因果证明。如果你看到"Showing last-known usage"，请记录显示数据的时间戳，并在比较前刷新。

你不需要复杂的评估系统。选择一个范围明确且可以安全重现的任务，记下其验收标准，并在开始和结束时记录以下内容：

只改变一种做法，比如等到调查完成后再压缩，或在创建新子代理时限制并发。保持原有的验收标准；不要悄悄缩小任务以获得更低的用量数字。也要注意缓存条件是否不同。如果运行使用了不同的模型、代码版本或任务大小，不要将整个差异归因于压缩。

在遗漏需求或让人员补充验证的情况下使用更少令牌并非改进。相反，如果保留更多上下文让任务一次完成而无需反复调查，仅凭更完整的窗口本身不足以称之为浪费。

将独立的 API 用量和订阅用量保持在不同账户。切换计费来源不会重置原始订阅配额，也不会自动更改客户端的委托、等待和压缩行为。通过比较完成相同任务所需的总用量和返工量来判断变更是否值得，而不仅仅是某个模型的单价。

在插件决定何时压缩之前，检查它发送出去的内容

Kun Chen 提出了一个实际问题："我什么时候应该 /compact 我的会话"？他的 compact-adviser 使用 TypeSafe 的 Jev 来判断工作是否已达到适合压缩的边界。它提供提示模式和需要选择加入的自动模式。

这篇审核已固定到 commit d1655faa16a22b68bff60c3d7deb0123e1e52a53，其中 Claude Code 插件清单列出版本 0.1.4。该项目要求 Node.js 22 或更高版本以及 Claude Code 2.1.274 或更高版本，并说明已在 2.1.275 上验证通过。其 Claude Code 集成依赖实验性函数钩子，需要设置 CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1。这些是项目声明的兼容性条件，而非为本文执行的安装测试。固定版本清单 · 版本与集成要求

更重要的是，hint 模式仅意味着不会自动执行压缩，并不意味着决策在本地进行或上下文保留在本地机器上。项目的安全文档指出，安装后如果启动环境、保存的设置或工作目录中的 .env 文件提供了密钥，且满足请求条件，选定的会话内容就会被发送到 TypeSafe。这包括用户约束条件、近期可见的回复和工具结果、已有摘要以及产物名称。没有单独的共享同意开关。摘录中可能仍包含代码或业务信息；尽力进行的脱敏处理并不能保证敏感内容完全不存在。上下文共享的边界

如果已安装该插件，可通过 /compact-adviser off 禁用它，或通过以下方式启动：

COMPACT_ADVISER_DISABLE=1 claude

根据该项目说明，这会停止插件请求、提示和自动压缩。它禁用插件，而非 Claude Code 自身的自动压缩功能。如果不允许将工作内容作为额外收件人发送给 TypeSafe，应禁用或卸载该插件，而不仅仅是将从自动模式切换到提示模式。如何禁用

作者提到的 40 会话评估是该项目的自身评估，数据集并不公开。它无法保证细节会在你的任务中被保留。即使插件判断某个点"可以安全压缩"，最终重要的是工作之后能否正确继续。评估边界

无需插件，你已经可以做到以下所有事情：在任务边界处保存状态并保留下一步所需的细节；给子代理清晰、独立的工作；在等待或恢复时避免重复启动；通过交付物和使用记录来评判结果。

管理长期任务的目标既不是填满窗口，也不是让每个请求看起来尽可能便宜。它的意义在于减少不推进任务的工作，并可靠地完成你开始的事情。

最初发布于 BetterToken 博客。

BetterToken 通过 OpenAI 兼容和 Anthropic 兼容的端点提供随用随付的 AI 模型 API 访问——如果你将 Claude Code、Codex 或你自己的工具连接到自定义基础 URL，这会很有用。参阅文档开始使用。

如需进一步操作，你可以考虑屏蔽此人或举报滥用行为。