长交互的上下文保全（考点 5.1）· CCAF 备考

本页目录5

这个考点是什么

长交互的上下文保全，考的是当一次agentic任务或对话持续几十轮甚至上百次工具调用后，哪些内容必须被记住、哪些可以被舍弃，以及Claude API提供了哪几种官方机制来做这件事。

核心矛盾是：上下文窗口是一次请求的硬上限——system prompt、tool定义、每条message、cache_read_input_tokens与cache_creation_input_tokens产生的token、以及当前轮的thinking输出全都占用它；但长任务里工具结果和历史往返会不断膨胀，放任不管迟早撞墙。

Anthropic在API层给出了三类互不替代的手段：

context editing（clear_tool_uses_20250919）按规则清掉过期的工具调用/结果，腾出空间但不生成摘要；
server-side compaction（compact_20260112）在触及阈值后把更早对话真正总结成一个compaction block，交回调用方原样带回下一轮；
context awareness则是在部分模型上自动注入剩余预算提示，让模型自己有意识地节流或提前收尾。

三者分别对应“清理”“压缩”“感知剩余空间”，常被放在一起互相当干扰项考。

真正的难点不在记住参数名本身，而在分清“占用上下文窗口”与“计入ITPM速率限制”是两套完全独立的计数口径，以及prompt caching只优化成本和延迟、根本不参与“保全”这件事。

为什么考

这一考点最常见的出题手法，是把“占用上下文窗口的token”和“计入ITPM限制的token”混在同一道计算题里，考察能否准确排除cache_read_input_tokens、正确纳入cache_creation_input_tokens与input_tokens。

另一类高频出法，是给出context editing与server-side compaction的参数或行为描述，让考生辨认某个陈述描述的到底是清理（clear_at_least/keep/trigger/exclude_tools）还是压缩（compaction block必须原样带回下一轮请求）——两者用词相似，极易张冠李戴。

还有一类专考context awareness的自动生效范围，专挑“需要自己拼标签”或“所有模型都有”这类似是而非的说法做干扰项。

核心辨析

1
上下文窗口计数与ITPM速率限制是两套口径
system prompt、tool定义、每条message、cache_read_input_tokens及当前轮thinking输出都占用上下文窗口；但ITPM只统计input_tokens加cache_creation_input_tokens,cache_read_input_tokens对多数模型（Claude Haiku 3.5除外）不计入ITPM。省速率额度不等于省上下文空间，prompt caching只优化前者。
2
context editing（clear_tool_uses_20250919）做的是“清旧工具结果腾空间”，不是总结：trigger设定触发的输入token阈值，keep保留最近若干轮tool_use/result,exclude_tools豁免关键结果永不被清，clear_at_least是清理量的下限而非上限——清不到这么多就跳过，避免为省一点点空间打破prompt cache前缀。
3
server-side compaction（compact_20260112）才是真正的“总结压缩”：
- 到阈值后API把更早对话总结进一个compaction block返回；
- 因为Messages API无状态，必须把整段response.content（含该block）原样带回下一轮请求，API据此丢弃该block之前的内容——只回传文本、漏掉block，压缩就白做了。
4
context awareness是“让模型知道还剩多少空间”的信号机制，不是压缩或清理本身
在支持的模型（如Sonnet 5/4.6/4.5、Haiku 4.5）上，API自动在system prompt注入budget:token_budget、每次工具调用后追加<system_warning>报告剩余容量，调用方不需要也不应该自己拼标签；Opus/Fable/Mythos系列走的是另一条beta的task budget路线，不吃这套自动注入。
5
token counting endpoint（/v1/messages/count_tokens）本身不参与任何保全机制，只回答“现在占用多少”：免费但有独立于Messages API的速率限制，只返回input_tokens估算值，不读写prompt cache，也预测不了输出长度。它的作用是让调用方在真正触发清理/压缩阈值之前，提前判断该不该主动收敛上下文。

反模式对照

常见做法

把clear_at_least理解成“最多清理多少token”的上限

正确做法

clear_at_least是“至少清理这么多token才执行”的下限，清不到这个量就跳过整次清理

清理会打破被清内容之后的prompt cache前缀，设下限是为了避免为省一点点空间就牺牲缓存命中

常见做法

compaction发生后只把assistant的文本部分追加回messages数组

正确做法

把response.content整体——包括compaction block——原样追加回messages，再发下一轮请求

Messages API无状态，遗漏block会让API认不出已总结的历史，压缩状态形同虚设，下一轮又得携带全部旧history

常见做法

认为cache_read_input_tokens命中的前缀“服务器端存着、不占用上下文窗口”

正确做法

cache_read_input_tokens依然完整计入上下文窗口，prompt caching只省成本和延迟，不省容量

这是把“计费优化”和“容量占用”混为一谈的典型误解，压缩/清理要解决的才是容量问题，缓存解决不了

常见做法

以为要自己在system prompt里手写budget:token_budget标签，或认为该机制对所有Claude 4+/Opus模型自动生效

正确做法

在支持的模型（Sonnet 5/4.6/4.5、Haiku 4.5）上标签由API自动注入，调用方不发送任何标签；Opus/Fable/Mythos系列不在此列，走的是另一套beta的task budget

干扰项常把“自动生效的范围”和“需要手动配置”调换，或把支持列表夸大成“全体现行模型”

练这个考点

练习模式支持按考点专练（需 Google 登录，不占用正式考机会）。

专练考点 5.1

该考点的公开题（免登录，含完整解析）：