Claude API 的演进：从「Messages 原语」到「托管 Agent 平台」

如果说 OpenAI 的 API 演进主线是「从 Chat Completions 走向 Responses 运行时」，那么 Anthropic 的路径则有所不同，但目标一致：

Claude API 正在从「Messages 消息原语 + 开发者自编排」，演进为「Messages 原语 + 多层 Agent 运行时 + 托管平台能力」。

Anthropic 没有废弃 Messages API，也没有像 OpenAI 那样推出一个替代性的新接口。它的策略是：守住 /v1/messages 这个稳定核心，在上面叠加 Agent SDK、Claude Managed Agents、Compaction、Memory 等一层层运行时能力，让开发者按控制粒度选择接入深度。

理解这条路径，对选型 Claude 的开发者同样关键。

一、两条接入线：Messages API 与 Agent 运行时

1. Messages API：稳定的核心原语

/v1/messages 是 Claude API 的根基，设计哲学与 OpenAI 早期的 Chat Completions 类似：你发一组消息，模型返回结构化的 content blocks（text、tool_use、thinking 等）。

但 Anthropic 在 Messages API 上持续深耕，使其本身就能承载相当复杂的 Agent 工作流：

• • Tool use：模型决定何时调用工具，返回 tool_use block，开发者执行后回传 tool_result
• • Extended thinking：推理过程以 thinking block 返回，可跨轮次传递
• • Prompt caching：块级或自动缓存，最高 90% 成本折扣
• • Structured outputs：JSON Schema 约束输出格式
• • Server-side tools：web search、web fetch、code execution 由 Anthropic 托管执行

Messages API 的优势是控制粒度最细——你拥有完整的 agent loop、上下文管理、工具执行逻辑。劣势也明显：多步工具调用、子 Agent、会话状态、Compaction 都要自己实现。

2. Agent SDK：把 Claude Code 变成库

2025 年 9 月，Anthropic 将 Claude Code SDK 重命名为 Claude Agent SDK。这不是改名而已，而是明确了一个产品定位：

把驱动 Claude Code 的同一套 Agent 运行时，开放给开发者嵌入自己的产品。

Agent SDK 提供两种接入方式：

无状态、单次任务，20 行代码启动 Agent

开箱即用的内置工具：Read、Write、Edit、Bash、Glob、Grep、WebSearch、WebFetch、Skill。加上 18 个生命周期 Hook（PreToolUse、PostToolUse、SubagentStart、PreCompact 等），让开发者能在不重写 Agent loop 的前提下，实现审计、拦截、改造行为。

与 Messages API 的对比很清晰：

• • Messages API：你写 while loop，你执行工具，你管理上下文
• • Agent SDK：你描述任务和工具白名单，SDK 跑 loop，你消费消息流

3. Claude Managed Agents：全托管的 Agent 平台

2026 年 4 月，Anthropic 推出 Claude Managed Agents——这是 Claude API 演进中最大的一次「接口之上」的产品化跃迁。

如果说 Agent SDK 是「Claude Code 作为库」，Managed Agents 就是「Agent 作为服务」：

• • 创建 Agent 配置（模型、system prompt、工具、MCP servers、Skills）
• • 通过 API 启动 Session，Anthropic 托管沙箱执行
• • SSE 流式返回事件（agent.message、tool_use、event_delta 等）
• • 内置 Memory Store、Vault（密钥注入）、Scheduled Deployments
• • Multi-agent Sessions 和 Outcomes（5 月公测）
• • Dreams：读取 memory store 和 session 历史，自动重组、去重、提炼洞察

Managed Agents 的所有端点需要 managed-agents-2026-04-01 beta header。它面向的是「我不想自己管沙箱、编排、密钥、调度，但要一个能跑起来的 Agent」的开发者。

三条线的关系：

Messages API          →  你控制一切，最灵活
Agent SDK             →  你控制策略，SDK 跑 loop
Claude Managed Agents →  你定义 Agent，平台跑一切

二、模型迭代：从 Extended Thinking 到 Adaptive Thinking

Claude 的模型演进有一个贯穿始终的主题：推理能力的产品化——从「可选的 thinking budget」到「默认开启的 adaptive thinking」，再到「effort 参数统一调控」。

Claude 4 系列（2025 年 5 月）：推理与工具的原生融合

Claude Opus 4 和 Sonnet 4 标志着几个重要转折：

• • Extended thinking 成为旗舰模型的标配能力，thinking 摘要以 summary 形式返回，完整推理链加密在 signature 字段
• • Interleaved thinking（Beta）：工具调用之间也能思考，不再只在首轮推理
• • Files API、Code execution、MCP connector 同期发布——工具能力从「客户端执行」扩展到「服务端托管」
• • Computer use 工具独立版本化（computer_20250124），与 text editor、bash 解耦

Claude 4.5 / Sonnet 4.5（2025 年 9–11 月）：Agent 工具链成型

这一阶段是 Claude API 工具能力最密集的一次补齐：

同时，Claude Sonnet 4.5 被定位为「复杂 Agent 和编码的最佳模型」，Claude Opus 4.5 则在视觉、编码、computer use 上实现阶跃，但价格更亲民。

Claude 4.6（2026 年 2 月）：Adaptive Thinking 与 Compaction

Opus 4.6 和 Sonnet 4.6 带来了推理模式的根本转变：

Adaptive thinking 成为推荐默认

"thinking":{"type":"adaptive"}

模型自行判断何时需要深度推理，不再依赖开发者设置 budget_tokens。手动 thinking（type: "enabled"）被标记为 deprecated。

Effort 参数 GA

effort 替代 budget_tokens 成为调控推理深度的统一接口，支持 low / medium / high 等级。

Compaction API（Beta）

服务端上下文摘要，实现「 effectively infinite conversations」。对长时间运行的 Agent 工作流，这是关键的内存管理方案。

多项工具 GA

Web search、programmatic tool calling、tool search、code execution、web fetch、memory tool 全部转正，不再需要 beta header。

1M token 上下文 GA

Opus 4.6 和 Sonnet 4.6 默认支持 1M token 上下文，超过 200k 的部分按 long context 定价。

Automatic caching

只需在请求体加一个 cache_control 字段，系统自动缓存最后一个可缓存块，随对话增长前移缓存点——不必手动管理 cache breakpoints。

Claude Opus 4.7 / 4.8（2026 年 4–5 月）：旗舰能力的精细打磨

Opus 4.7（4 月）的关键更新：

• • Task budgets（Beta）：给 Agent loop 设置 advisory token 预算，模型看到剩余额度并优雅收尾
• • Advisor tool（Beta）：执行模型 + 顾问模型配对——执行模型负责大量 token 生成，顾问模型在关键节点提供战略指导，接近「顾问 solo」质量但成本更低
• • xhigh effort level：介于 high 和 max 之间，面向 30 分钟以上长任务
• • 高分辨率图像输入：长边从 1568 提升到 2576 像素
• • 新 tokenizer：同样文本产生约 30% 更多 token——这是迁移时必须注意的隐性成本变化

Opus 4.8（5 月）在此基础上：

• • 1M 上下文默认 GA，adaptive thinking 进一步优化（减少无效 thinking token）
• • Mid-conversation system messages：可在 user turn 之后插入 system 消息，且不破坏 prompt cache
• • Fast mode（Research Preview）：speed: "fast" 显著加速输出 token 生成，溢价计费
• • stop_details 公开文档化，refusal 响应返回 category 和 explanation
• • Prompt caching 最低可缓存长度降至 1024 token

Claude Fable 5 / Mythos 5 / Sonnet 5（2026 年 6–7 月）：新代际与规则重置

6 月发布的 Fable 5 和 Mythos 5 代表了 Claude 模型的新天花板：

• • 1M 上下文默认、128k max output、仅支持 adaptive thinking（不能 disable，不能手动 budget）
• • 安全分类器运行中，stop_reason: "refusal" 时若未生成任何输出则不计费
• • fallbacks 参数（Beta）：refusal 后自动在另一模型上重试
• • Fable 5 要求 30 天数据 retention，不支持 ZDR

7 月发布的 Sonnet 5 则是面向主流开发者的新默认：

• • 限时定价 2/2/2/10 per MTok（至 8 月 31 日），之后 3/3/3/15
• • 1M 上下文、128k max output
• • Adaptive thinking 默认开启，移除手动 extended thinking（设 budget_tokens 返回 400）
• • 非默认 sampling 参数（temperature、top_p、top_k）返回 400——与 Opus 4.7+ 一致
• • 新 tokenizer，同样文本约多 30% token

模型迭代的隐含规则越来越清晰：越新的模型，越少给开发者「手动调采样和推理」的空间，越多用 adaptive thinking + effort 统一管理。

三、工具链演进：从 Tool Use 到 Advisor + Skills

Claude 的工具能力演进路径：

Tool Use（2024.05 GA）
    ↓ 客户端定义工具，模型决定调用
Web Search / Web Fetch（2025.05 / 09）
    ↓ 服务端托管的信息获取
Code Execution（2025.05 Beta → 2026.02 GA）
    ↓ 沙箱内执行代码
MCP Connector（2025.05 Beta）
    ↓ 连接远程 MCP 服务器
Computer Use（2024.10 → 持续迭代）
    ↓ 截图式 UI 交互
Agent Skills（2025.10 Beta）
    ↓ 动态加载专业技能包
Programmatic Tool Calling（2025.11 Beta → 2026.02 GA）
    ↓ 在 code execution 内协调工具
Tool Search（2025.11 Beta → 2026.02 GA）
    ↓ 运行时按需发现工具
Advisor Tool（2026.04 Beta）
    ↓ 执行模型 + 顾问模型配对
Managed Agents Toolset（2026.04+）
    ↓ 平台托管的完整工具运行时

与 OpenAI 的路径对比：

Anthropic 的策略更偏向「在 Messages API 上堆工具，在 Managed Agents 上堆平台」；OpenAI 则更倾向「在 Responses API 内一站式解决」。

四、Claude Managed Agents：平台层的全面铺开

2026 年 4 月以来的 Managed Agents 更新，值得单独梳理——它代表了 Anthropic 对企业 Agent 市场的直接切入。

核心能力时间线

公测发布：Agent 创建、Session 运行、SSE 流式、沙箱执行

几个值得关注的设计

Self-hosted Sandboxes

Managed Agents 不必在 Anthropic 基础设施上执行工具——可以部署自己的沙箱环境，通过 GET /v1/environments/{id}/work 拉取待执行工作。这对有合规要求的企业是关键能力。

Vault 与凭证注入

密钥不再硬编码在 Agent 配置里。Vault 支持 OAuth 凭证和环境变量凭证，并可通过 injection_location 控制注入到请求 header、body 或两者。

Dreams

一个有趣的「离线整理」能力：读取 memory store 和历史 session，自动去重、更新过时条目、提炼新洞察，输出重组后的 memory store。这是 Agent 记忆管理的主动维护，而非被动累积。

大输出 Spill

agent_toolset 和 MCP 工具返回超过 100K token 时，自动写入沙箱文件，模型收到截断预览和文件路径，可按需读取全文。

五、基础设施与治理能力

Prompt Caching 的演进

块级 cache_control，最高 90% 折扣

身份与访问

• • Workload Identity Federation（2026.05 GA）：AWS IAM、GCP、GitHub Actions、K8s、Entra ID、Okta、SPIFFE 等 OIDC 提供商签发短期令牌，替代长期 API Key
• • API Key 过期设置（2026.07）：创建 Key 时可选预设或自定义有效期，7 天以上到期前邮件提醒
• • MCP Tunnels（2026.05 Preview）：连接私有网络内的 MCP 服务器，无需暴露到公网

可观测与成本

• • Usage & Cost API（2025.08）：程序化查询组织用量和成本
• • Rate Limits API（2026.04）：查询组织和工作空间的速率限制配置
• • Refusal 零计费（2026.06）：stop_reason: "refusal" 且未生成任何输出时不计费
• • thinking_tokens 明细（2026.05）：usage.output_tokens_details.thinking_tokens 单独报告推理 token 消耗

多云与多平台

Claude API 的分发策略比 OpenAI 更「多云原生」：

• • Amazon Bedrock：Messages API 兼容端点（2026.04 Research Preview → 全面开放）
• • Claude Platform on AWS（2026.05）：Anthropic 托管基础设施 + AWS 计费和 IAM
• • Microsoft Foundry（2025.11）：Azure 计费 + OAuth，支持 Messages API 全功能
• • Google Vertex AI：持续支持

六、正在消失的东西

迁移时需要特别注意的两个「隐性破坏」：

1. 1. Tokenizer 变化（Opus 4.7 起）：同样文本约多 30% token，直接影响成本和上下文占用
2. 2. Sampling 参数限制（Opus 4.7+ / Sonnet 5）：非默认 temperature、top_p、top_k 返回 400 错误

七、与 OpenAI API 的演进对比

把两家放在同一张图里，能看到有趣的分歧与收敛：

接口策略

OpenAI 选择「用一个新接口统一一切」；Anthropic 选择「守住 Messages API，在上面叠加多层运行时」。两种路径各有优劣：

• • OpenAI 路径：迁移成本高，但长期接口统一
• • Anthropic 路径：Messages API 稳定，但能力分散在 API / SDK / Managed Agents 三层

Agent 能力收敛

尽管接口策略不同，两家在 Agent 能力上高度收敛：

• • 都有 programmatic tool calling
• • 都有 tool search（按需加载工具）
• • 都有 computer use
• • 都有 MCP 支持 + 私有网络隧道
• • 都有 multi-agent（OpenAI 在 API 层，Anthropic 在 Managed Agents 层）
• • 都有 compaction / 上下文管理
• • 都有 workload identity federation
• • 都在推 prompt caching 和 refusal 零计费

模型策略

八、开发者该怎么理解这些变化

判断一：先选接入层，再选模型

Claude 的三层接入（Messages API / Agent SDK / Managed Agents）不是「越上层越好」，而是控制粒度与运维负担的权衡：

• • Messages API：你需要完全控制 agent loop，或有复杂的自定义编排逻辑
• • Agent SDK：你想要 Claude Code 级别的 Agent 能力，但嵌入自己的产品，且愿意接受 Claude 模型的绑定
• • Managed Agents：你不想管沙箱、调度、密钥、记忆，只要一个能 API 调用的 Agent 服务

新项目建议：先用 Agent SDK 验证 Agent 行为，再决定是否需要下沉到 Messages API 或上浮到 Managed Agents。

判断二：Adaptive thinking 改变了成本模型

随着 manual thinking budget 被移除、adaptive thinking 成为默认，开发者不能再靠「设一个固定 budget」来控制成本。取而代之的是：

• • effort 参数：统一调控推理深度
• • task budgets（Beta）：给整个 Agent loop 设 token 上限
• • advisor tool：用执行模型 + 顾问模型配对降低成本
• • thinking.display: “omitted”：省略 thinking 内容加速流式传输（计费不变）
• • automatic caching：降低长对话的重复 token 成本

设计 Agent 时，应该把 effort 和 caching 当作一等公民，而不是事后调优。

判断三：Tokenizer 变化是真实的迁移成本

Opus 4.7 引入的新 tokenizer 让同样文本产生约 30% 更多 token。这不只是计费变化——它影响：

• • 上下文窗口的实际可用空间
• • Prompt caching 的命中率计算
• • Rate limit 的 token 消耗速度
• • 与旧模型的 A/B 测试对比基准

迁移到新模型时，务必用 Token Counting API 重新测量你的 prompt，不要假设 1:1 映射。

判断四：Managed Agents 是 Anthropic 的企业赌注

Managed Agents 的密集更新（Memory、Vault、Dreams、Scheduled Deployments、Self-hosted Sandboxes、Multi-agent）说明 Anthropic 不满足于「卖 token」，而是要成为企业 Agent 的运行平台。

这与 OpenAI 的 Responses API + Assistants 退场、Salesforce/ServiceNow 的 Agent 平台化，是同一赛道上的竞争。对开发者来说，如果 Agent 需要长期运行、跨 Session 记忆、密钥管理、定时调度，Managed Agents 值得评估——但它也意味着更深的平台绑定。

九、结语：原语不变，运行时叠加

回顾 Claude API 从 2024 到 2026 上半年的演进，最本质的变化可以用一句话概括：

Messages API 没有变，变的是它上面能跑什么。

• • 2024 年，API 的回答是：「我给你一段文本，顺便调了个工具。」
• • 2025 年，API 的回答是：「我想了一会儿，搜了网页，执行了代码，调了 MCP，这是结果。」
• • 2026 年，API 的回答是：「我启动了托管 Agent，在沙箱里跑了三个子任务，整理了记忆，顾问模型审了一遍，这是汇总。」

Anthropic 选择了一条与 OpenAI 不同的路：不替换核心接口，而是在上面逐层叠加运行时能力。Messages API 依然是那个 Messages API，但它已经能承载从单次推理到全托管 Agent 平台的完整光谱。

对于正在构建 AI 应用的团队，现在值得问几个问题：

• • 你的 Agent loop 是自己写的，还是该评估 Agent SDK？
• • 你的长对话是否利用了 Compaction 和 automatic caching？
• • 你的模型迁移是否考虑了 tokenizer 变化带来的 30% token 增量？
• • 你的企业 Agent 是否需要 Managed Agents 的 Memory、Vault 和调度能力？

Claude API 的演进还没有停止。Fable 5 的安全分类和 refusal 机制、Sonnet 5 的限时定价、Managed Agents 的 Dreams 和 Multi-agent——这些都在暗示，下一个半年的主题，可能是从「开发者编排 Agent」走向「平台托管 Agent」的规模化落地。

到那时，选 Messages API 还是 Managed Agents，可能不再是技术偏好问题，而是商业模式问题。

本文基于 Claude Platform Release Notes（截至 2026 年 7 月）整理分析。