上下文管理

你发送给 Claude 的每个请求都有一个 上下文窗口。一百万个 token 听起来很多，但一旦你发布真正的 agent，它会比你想象的更快耗尽。这就是 上下文管理 的用武之地：它是你在不丢失重要内容的情况下保持在窗口内的方法。

什么算作上下文

上下文是 Claude 在给定轮次中看到的所有内容：

• 系统提示
• 消息历史
• 工具定义和工具结果
• 附加文件和 skills
• 思考块

它是每个 API 调用的输入。你为它支付入场费，也为它支付出场费。一旦窗口满了，请求就会失败。

所以目标不是把所有东西都放进去。目标是 放入正确的东西。

Anthropic 发布了 四种模式 用于在长时间运行的 agents 中管理上下文。三种是一流的 API 功能，一种是设计模式。

模式 1：即时上下文

不要预先加载所有内容。加载 agent 现在 需要的内容，让它在需要时通过工具拉取更多。

以合规审查 agent 为例。它不会将整本建筑规范书塞入系统提示——当它需要特定部分时，它调用 lookup_building_code 工具。这是四种中的设计模式：API 中没有特殊内容，只是关于你加载什么和何时加载的深思熟虑的选择。

模式 2：服务器端压缩

当对话运行时间较长时，Anthropic 的 服务器端压缩 将旧轮次总结为单个块。你通过在请求中添加 context_management 键并包含一个类型来选择加入：

response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    max_tokens=1024,
    context_management={
        "edits": [
            {"type": "compact_20260112"}
        ]
    },
    messages=messages,
)

当输入超过触发阈值时，API 自动总结。你不必自己跟踪对话长度。

模式 3：提示缓存

提示缓存 让你标记请求的稳定部分——系统提示、工具定义、长文档——并在调用间以极低的成本重用它们。

数学比看起来更重要。如果你的系统提示是 4,000 个 token，你每小时调用 100 次，缓存是可用账单和财务部门打电话之间的区别。

模式 4：记忆工具

有些上下文需要 跨会话 生存：用户偏好、agent 的运行笔记、上周决定了什么。推荐用于此的原语是 记忆工具。

它是这样工作的：

• Claude 通过工具调用读写记忆目录。
• 你在客户端实现存储后端——文件系统、数据库、加密存储，无论你想要什么。
• Anthropic 自动注入系统指令，告诉 Claude 在开始工作前检查记忆目录。

组合模式

在生产应用中，你通常会同时使用所有四种。合规审查 agent 缓存其系统提示和工具定义，并通过 lookup_building_code 即时拉取建筑规范部分。

每种模式处理不同的失败模式：成本、窗口大小、无状态性。选择与你遇到的问题匹配的模式。