Claude API：按需 Compaction 与 `auto` 权限模式，重写你的 Agent 循环设计

Anthropic 在 9 月 10 日至 14 日这周向 Claude API 推送了两个面向 Operator 的新功能。两者都不是模型升级，但都改变了你的代码与 API 之间的契约。

第一个是按需 Compaction —— 通过新的 compact-2026-09-04 Beta Header，你可以把对话摘要作为一个独立的后台调用发出，完全与用户正在等待的那个 Turn 解耦。第二个是 Managed Agents 的 auto 权限模式，它让服务器逐次决定某个工具是执行、拒绝还是暂停等待你的审批。如果你已经在用阈值 Compaction（compact-2026-01-12）或 Managed Agents（managed-agents-2026-04-01），这两个增量变化会最直接地影响你的运营姿态。

按需 Compaction：compact-2026-09-04 Header 的机制

基于阈值的 Compaction 在输入 Token 触及上限时自动生成摘要。问题在于时机：摘要生成发生在用户正在等待的那个请求里，在上下文窗口最拥挤的时刻额外增加了延迟。

按需 Compaction 通过把摘要拆成独立 API 调用来解决这个问题。这个调用只返回一个 compaction Block，没有 Assistant Turn，没有工具结果，只有摘要本身。你可以在会话空闲时从后台 Worker 触发它。摘要块返回后，你把它拼入消息数组，丢弃它之前的所有内容。用户的下一个请求发出时，压缩好的上下文已经就位。

新 Header 是 compact-2026-09-04。你发出一个带 compaction 参数（而不是 context_management.edits）的独立请求，得到摘要块。在后续 Turn 里，该块放在消息数组顶部，API 自动丢弃之前的所有内容。

截至 9 月 17 日支持的模型：claude-fable-5-1、claude-mythos-5-1、claude-fable-5、claude-mythos-5、claude-mythos-preview、claude-opus-5、claude-opus-4-8、claude-opus-4-7、claude-opus-4-6、claude-sonnet-5、claude-sonnet-4-6。ZDR 合规（Covered Models 除外）。在 Claude API、Claude Platform on AWS、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 上均为 Beta 状态。

消息循环的前后对比

只用阈值 Compaction 时，你的循环是这样的：

# 每个 Turn：
response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    messages=messages,
    context_management={"edits": [{"type": "compact_20260112"}]},
    max_tokens=4096,
)
messages.append({"role": "assistant", "content": response.content})
# 如果触发了 Compaction，response.content 包含 compaction block。
# API 在下一次请求时自动丢弃旧消息。

Compaction 在请求里同步发生。如果上下文很大，这个 Turn 就慢。用户在等。

使用按需 Compaction（compact-2026-09-04）后，摘要可以在带外运行：

# 后台 Worker 在会话空闲或 Token 检查点触发：
summary_response = client.beta.messages.create(
    betas=["compact-2026-09-04"],
    model="claude-opus-5",
    messages=messages,           # 当前为止的对话
    compaction={"type": "compact_20260904"},
    max_tokens=4096,
)
compaction_block = summary_response.content[0]  # 只有 compaction block

# 写回消息存储：
messages = [{"role": "assistant", "content": [compaction_block]}]
# 所有旧消息已丢弃；下一个用户 Turn 带着压缩好的上下文发出。

用户的下一个请求不再有额外延迟。如果你的会话是长期的 —— 客服对话、编程 Agent、文档审阅 —— 这正是最重要的结构变化。你来决定摘要触发时机，而不是 API。

一个运营注意点：你现在要自己负责在合适时机触发 Compaction。阈值 Compaction 是自管理的，按需 Compaction 不是。你需要 Token 计数（或启发式规则）来判断何时触发后台任务。如果错过窗口导致上下文溢出，你不会得到回退摘要，而是得到一个 400 错误。

auto 权限模式：Managed Agents 的服务器端信任评估

Managed Agents Beta（managed-agents-2026-04-01）最初只有两种权限模式：always_allow（自动执行）和 always_ask（暂停等待你的审批）。默认值是不对称的：agent_toolset_20260401 默认 always_allow，MCP Toolset 默认 always_ask。

新的 auto 模式增加了第三条路径。当你在 Toolset 上设置 permission_policy: {type: "auto"} 时，服务器逐次评估每个调用，决定以下三个结果之一：执行、拒绝或暂停等待你的审批。你无法提前知道某次调用会走哪条分支 —— 这正是它的设计意图。Anthropic 服务端的评估会用到你的代码所没有的上下文：这次调用是否看起来异常、目标是否在范围内、会话是否已积累了风险信号。

配置方式与其他模式相同：

{
  "type": "agent_toolset_20260401",
  "default_config": {
    "permission_policy": {"type": "auto"}
  }
}

也可以在单个工具粒度上设置，比 Toolset 级别的默认值更细。

重要的运营约束：正在运行的会话保持创建时的 Toolset 配置。如果你更改了现有 Agent 的策略，只有新会话会生效。进行中的会话在结束前仍使用旧策略。

auto 模式带来的审计缺口，以及如何弥补

always_allow 模式下，你的日志记录了每次工具调用和结果 —— 你的代码决定了允许，所以你拥有这个决策。always_ask 模式下，会话流中有明确的审批事件 —— 同样是清晰的归属。auto 模式下，是服务器做了决定。审批或拒绝事件会出现在会话事件流里，但原因 —— 服务器为什么允许或拒绝 —— 在当前 Beta 中没有暴露。

这对合规团队和调试都有影响。如果 Agent 在任务中途遭到拒绝，你的用户看到任务失败，但 Operator 侧看不到原因。你拿到的是一个事件类型，而不是解释。

目前实际的缓解措施：不要把 auto 当作唯一的门控。把它用作在窄范围 Toolset 之上的第二层。如果你在跑 agent_toolset_20260401，先把工具集限制在 Agent 真正需要的范围内，再设置 auto —— 当动作空间很小时，服务端的评估会更可预测。把意外的拒绝当作信号，说明这个请求从服务器视角看起来异常，然后回查它之前的会话上下文。

对于 MCP Toolset：默认的 always_ask 本身就比较保守。切换到 auto 意味着你把明确的审批事件换成了服务端评估的流程 —— 只有当审批轮次的会话延迟确实是瓶颈时才值得这样做。

需要更新的 Operator 配置

关于 Compaction：

• 如果要用按需 Compaction，在 Beta Header 列表里加上 compact-2026-09-04，可以与现有的 compact-2026-01-12 并存。两种模式独立 Opt-in。
• 在你的会话管理器里加入 Token 检查点。Anthropic SDK 的 Token 计数接口是触发后台 Compaction 的干净方式。
• 按需 Compaction 与阈值 Compaction 共用同一份支持模型列表。如果你路由的目标模型不在列表上，调用会报错 —— 建议在启用前先验证。

关于权限策略：

• 策略变更不影响进行中的会话。如果你需要对活跃的长期运行 Agent 变更行为，需要创建新 Agent 并把会话迁移过去。
• auto 模式不是高风险 Toolset 上 always_ask 的替代品。它适合低风险工具，那些审批轮次的开销高于逐次显式控制需求的场景。
• Managed Agents 环境中的 MCP Server Operator 需要注意：你们的默认姿态是 always_ask。如果一个使用 auto 权限的 Managed Agent 调用你的 MCP Server，调用可能被服务端静默拒绝。在 Staging 环境里显式测试这一点。

两个功能均在 Beta 阶段，API 结构在 GA 前可能变化。compact-2026-09-04 和 managed-agents-2026-04-01 是独立的 Beta Flag，有各自的弃用时间线，需要分开追踪。