所有大模型在发布时，都会标明模型的上下文窗口大小，如上图所示，当上下文窗口超过模型的限制时，模型一般会截取或限制服务。
以下是一些主流LLM模型的上下文窗口大小，一般在官网都可以查询到：
• OpenAI最新的GPT-4.1的上下文窗口已经达到1M，其它主要模型也达到了200K• Anthropic的Claude模型的上下文窗口大小现在都是200K什么是KV缓存(KV-Cache)？
这个问题我问了一下Gemini，它的回答是：
从模型的内部视角(Model's Internal Perspective)，LLM 的核心是 Transformer 架构，其关键是自注意力（Self-Attention）机制。为了计算下一个 token，模型需要“回顾”之前所有的 token。
- • 没有缓存： 每生成一个新 token，都要重新计算所有前面 token 的注意力关系。这是一个非常耗时的操作。
- • 有 KV 缓存： 模型在处理完一个 token 后，会将其关键的计算结果（Key 和 Value 矩阵，简称 KV）存储起来。在生成下一个 token 时，它只需要计算新 token 与所有“已缓存”旧 token 的关系，而无需重新计算那些旧 token 彼此之间的关系。
结论： KV 缓存是一个性能优化工具，它极大地加快了模型的推理速度（即响应速度），尤其是长文本的生成。
但是，为什么文章中，作者一直在强调：
幸运的是，具有相同前缀的上下文可以利用KV缓存[7]，这大大减少了首个token的生成时间(TTFT)和推理成本——无论你是使用自托管模型还是调用推理API。我们说的不是小幅度的节省：例如使用Claude Sonnet时，缓存的输入token成本为0.30美元/百万token，而未缓存的成本为3美元/百万token——相差10倍。
这其中的推理成本可能对现在的使用场景更加关键，像最近Cursor、Claude Code等出现的订阅收费的问题，更加说明了在Agent快速发展的时候，推理成本的问题会变得更加突出。好像现在市面上，原来号称可以无限"续杯"的会员服务都在调整策略，其中最大的原因就是Agent数量庞大的Tokens消耗(在Anthropic: 如何构建多智能体研究系统文章中，Claude的工程师就提出Multi Agent系统的Token耗用量大概是普通聊天的15倍左右，这是一个非常惊人的数字)
现在主流的LLM基本都已经支持"Prompting Cache"这样的技术，在查阅Deepseek官网时，看到它对整个缓存的动作机制有清晰的描述。
下面摘取一段Deepseek官网的说明，它是以API接口中消息的顺序进行讲解的，与AI代理的上下文工程：构建Manus的经验教训一文中的缓存表述非常吻合，可以作为参考。
例一：长文本问答
第一次请求
messages: [
{"role": "system", "content": "你是一位资深的财报分析师..."}
{"role": "user", "content": "<财报内容>\n\n请总结一下这份财报的关键信息。"}
]
第二次请求
messages: [
{"role": "system", "content": "你是一位资深的财报分析师..."}
{"role": "user", "content": "<财报内容>\n\n请分析一下这份财报的盈利情况。"}
]
在上例中，两次请求都有相同的前缀，即 system 消息 + user 消息中的 <财报内容>。在第二次请求时，这部分前缀会计入“缓存命中”。
例二：多轮对话
第一次请求
messages: [
{"role": "system", "content": "你是一位乐于助人的助手"},
{"role": "user", "content": "中国的首都是哪里？"}
]
第二次请求
messages: [
{"role": "system", "content": "你是一位乐于助人的助手"},
{"role": "user", "content": "中国的首都是哪里？"},
{"role": "assistant", "content": "中国的首都是北京。"},
{"role": "user", "content": "美国的首都是哪里？"}
]
在上例中，第二次请求可以复用第一次请求开头的 system 消息和 user 消息，这部分会计入“缓存命中”。
例三：使用 Few-shot 学习
在实际应用中，用户可以通过 Few-shot 学习的方式，来提升模型的输出效果。所谓 Few-shot 学习，是指在请求中提供一些示例，让模型学习到特定的模式。由于 Few-shot 一般提供相同的上下文前缀，在硬盘缓存的加持下，Few-shot 的费用显著降低。
第一次请求
messages: [
{"role": "system", "content": "你是一位历史学专家，用户将提供一系列问题，你的回答应当简明扼要，并以`Answer:`开头"},
{"role": "user", "content": "请问秦始皇统一六国是在哪一年？"},
{"role": "assistant", "content": "Answer:公元前221年"},
{"role": "user", "content": "请问汉朝的建立者是谁？"},
{"role": "assistant", "content": "Answer:刘邦"},
{"role": "user", "content": "请问唐朝最后一任皇帝是谁"},
{"role": "assistant", "content": "Answer:李柷"},
{"role": "user", "content": "请问明朝的开国皇帝是谁？"},
{"role": "assistant", "content": "Answer:朱元璋"},
{"role": "user", "content": "请问清朝的开国皇帝是谁？"}
]
第二次请求
messages: [
{"role": "system", "content": "你是一位历史学专家，用户将提供一系列问题，你的回答应当简明扼要，并以`Answer:`开头"},
{"role": "user", "content": "请问秦始皇统一六国是在哪一年？"},
{"role": "assistant", "content": "Answer:公元前221年"},
{"role": "user", "content": "请问汉朝的建立者是谁？"},
{"role": "assistant", "content": "Answer:刘邦"},
{"role": "user", "content": "请问唐朝最后一任皇帝是谁"},
{"role": "assistant", "content": "Answer:李柷"},
{"role": "user", "content": "请问明朝的开国皇帝是谁？"},
{"role": "assistant", "content": "Answer:朱元璋"},
{"role": "user", "content": "请问商朝是什么时候灭亡的"},
]
在上例中，使用了 4-shots。两次请求只有最后一个问题不一样，第二次请求可以复用第一次请求中前 4 轮对话的内容，这部分会计入“缓存命中”。
综上所述，无论是处理长文档、进行多轮对话，还是利用 Few-shot 提升效果，其背后都遵循着同一个核心原则：通过保持 Prompt 前缀的稳定性来最大化缓存命中率。理解并善用 Prompt Caching 机制，已经不再是一个锦上添花的技术选项，而是未来在开发高效率、低成本 AI 应用，尤其是在构建复杂 Agent 系统时，每一位开发者都必须掌握的关键技能。
如何遮蔽(Mask)？
在Manus的论文中，第二点提到："遮蔽，而非移除(Mask, Don't Remove)"，那什么是遮蔽(Mask)呢？
“遮蔽 (Masking)” 的核心思想是：在任何时候，都将所有可能的工具定义完整地保留在模型的上下文（Context）中，但通过技术手段在模型生成（解码）的瞬间，动态地限制模型只能选择当前可用的工具。
在文章有如下的描述：
函数调用通常有三种模式(Hermes)：
• 自动(Auto)–模型可以选择调用或不调用函数。通过预填充回复前缀实现：<|im_start|>assistant
• 必需(Required)–模型必须调用函数，但选择不受约束。通过预填充到工具调用令牌实现：<|im_start|>assistant<tool_call>• 指定(Specified)–模型必须从特定子集中调用函数。通过预填充到函数名称的开头实现: <|im_start|>assistant<tool_call>{"name": "browser_通过这种方式，我们通过直接掩码token的logits来约束动作选择。Jack，公众号：LiveThinkingAI代理的上下文工程：构建Manus的经验教训
而如果使用API调用模型时，已经有对遮蔽(Mask) 进行支持，以OpenAI的API为例：
当我们调用 chat.completions.create 接口时，可以传递一个 tool_choice 参数来精确控制模型的行为。
tool_choice 参数的作用就是告诉模型：“在这次生成中，你关于工具使用的选择空间被我‘遮蔽’了，你必须遵循以下规则”。
它有几种模式：
- 1. 遮蔽“不使用工具”的选项（强制调用工具）
这对应文章中的“必需 (Must)”模式。response = client.chat.completions.create(
model="gpt-4-turbo",
messages=my_messages,
tools=my_tools,
tool_choice="required" # 强制模型必须选择一个工具调用
)
- 2. 遮蔽“所有工具”的选项（禁止调用工具）
如果你想让模型进行纯文本对话，而忽略它可能看到的工具时，可以使用这个。response = client.chat.completions.create(
model="gpt-4-turbo",
messages=my_messages,
tools=my_tools,
tool_choice="none" # 强制模型不能调用任何工具，只能生成文本
)
- 3. 遮蔽“除某个特定工具外”的所有选项（强制调用特定工具）
这对应文章中的“指定 (Specific)”模式，是最强大的“遮蔽”形式。response = client.chat.completions.create(
model="gpt-4-turbo",
messages=my_messages,
tools=my_tools,
# 强制模型必须调用名为 "get_current_weather" 的函数
tool_choice={"type": "function", "function": {"name": "get_current_weather"}}
)
粤ICP备14082021号
免费POC，
零成本试错
