我对大模型 API 的认知，其实停在两年前

坦白说，直到不久前，我对大模型 API 的认知还停在这样一个图景：

传进去一个 system prompt（告诉模型你是谁）、一个 user prompt（用户问了什么），模型返回一段文本。输入两个字符串，输出一个字符串。

最近因为个人兴趣，我花了些时间研究这些大模型公司的开放平台到底在做什么——把 Anthropic、OpenAI 和几家国产平台的文档挨个翻了一遍。翻完才发现，我那个图景没有错，只是停在了 2023 年：那是 Completions API 的时代，形状确实就这么简单。而今天真实的 API 复杂得多，也有意思得多——它不是一个“文本进文本出”的函数，而是一台无状态的对话回放机，外挂一套内置的工具调用协议。

我习惯从传统 API 设计的角度看接口——endpoint 粒度怎么切、错误码怎么设计、API 怎么优雅下线。用这双“传统 API 设计”的眼睛去逐项看大模型 API，会得到一个挺反直觉的结论：

它的外围全是我熟悉的老套路，唯独最核心的那一小块，是我从没见过的新物种。

这篇文章就是这次逐项对照。我会顺着几个关键的设计决策往下走，每一处都摆出十家平台（美国四家 + 国内主流）的做法分化，再和传统 API 设计对一次账。读完你会对“大模型 API 到底是什么”有一个结构化的认识——也会明白为什么这件事对做平台的人不只是技术细节。

一、无状态回放：为什么每次调用都要重发全部历史

先看最基础的形状。以 Anthropic 的 Messages API 为标准样本（这是目前 API 设计的事实标杆，OpenAI 和国内各家的形状高度趋同）：

一个核心端点 POST /v1/messages。入参里最关键的是 messages 数组——它不是“这一句话”，而是整段对话历史，user 和 assistant 一轮轮交替排下来。

这里藏着一个决定了后面一切的设计决策：服务端不保存任何会话状态。每次调用，客户端都要把从头到尾的完整对话重新发一遍。

这和传统 REST 是反着来的。传统 API 里，状态在服务端（你的订单、你的会话就存在平台数据库里），每个请求是一次增量操作（“把这个订单状态改成已发货”）。大模型 API 反过来：服务端什么都不记，你要模型“接着上文说”，就得把上文完整背给它听。

为什么这么设计？因为大模型推理的本质是“读入一段上下文、预测下一段”，它天然没有“会话”这个概念，会话是我们在无状态的推理之上模拟出来的。把状态放在客户端，平台侧的推理服务就能做到完全无状态、水平扩展、任意一台机器都能接任意一个请求。这是工程上的正确选择，但它立刻带来一个副作用——

连锁反应：缓存成了平台经济学

每轮对话都重发全部历史，意味着一段长长的 system prompt、一大堆工具定义，会在每一轮里被重复发送、重复计费。对话越长，浪费越大。

于是 **prompt caching（提示缓存）**几乎是被这个设计逼出来的：平台把你请求开头那段没变的内容缓存住，下次匹配到相同前缀就不再重新计算，按一个便宜得多的价格收费。

有意思的是，“缓存怎么做”这件事本身，成了各家平台第一个真正拉开设计差异的地方。我数了一下，市面上已经分化出四种缓存哲学：

① 手动断点型（Anthropic）。 你自己在请求里用 cache_control 标记“缓存到这里”，最多打 4 个断点，缓存有 5 分钟或 1 小时两种存活时间。写入缓存要付 1.25 倍（或 2 倍）价钱，读取只要 0.1 倍。好处是可控、可优化；代价是有心智负担——你得自己想清楚断点打在哪，还得警惕“缓存悄悄失效”（system prompt 里插一个时间戳，一个字节的变化就让整段缓存作废）。

② 全自动型（DeepSeek、OpenAI）。 你什么都不用管，平台自动做前缀匹配。DeepSeek 做得最干脆：命中的部分按未命中价的约 2% 计费（V4 Flash 输入价从每百万 token 的 $0.14 直接降到 $0.0028），没有 cache_control 参数、没有写入费、没有存储费、零配置。

③ 资源化型（Google Gemini）。 这是最“传统 API”的一种：你可以显式创建一个 cachedContent 缓存对象，给它设定存活时间（TTL），然后按存储时长付费——缓存从一个隐形优化变成了一个你要管理、要为之持续付费的资源。同时 Gemini 也提供隐式的自动缓存。两种都做，它是唯一一个。

④ 计费型（Kimi 等）。 缓存的创建、存储、调用分项计价，介于手动和资源化之间。

这四种设计背后是同一个权衡：缓存的配置权，到底给不给开发者？ 给了（Anthropic），开发者能精细优化，但要承担复杂度；不给（DeepSeek），零负担，但你失去了控制。这是大模型时代冒出来的第一个纯新的 API 设计权衡——传统 API 里根本没有“缓存计费”这个维度，因为传统 API 是幂等的、可重试的、状态在服务端的，压根不存在“重发全部历史”这回事。

二、出参不是一段文本：内容块 + 停机原因 + 账单

反过来看响应。你以为返回的是一个字符串，实际上返回的是一个内容块数组——里面可能混着 thinking（思考过程块）、text（文本块）、tool_use（工具调用块）、甚至服务端搜索结果块。多模态和多阶段推理，在数据结构层面就被表达出来了。

但比内容块更值得注意的，是响应里两个传统 API 完全没有的字段：

stop_reason（停机原因）。 模型为什么停下来？可能是 end_turn（正常说完了）、tool_use（我要调工具，你去执行）、max_tokens（说到上限被截断了）、refusal（我拒绝回答）。这个字段是整个 agent 循环的控制信号——你的代码要靠读它来决定下一步干什么：继续等用户？去执行工具再回来？处理一次拒答？没有它，agent 就转不起来。

顺带说一个耐人寻味的细节：refusal（拒答）是作为一种正常的停机原因返回的，HTTP 状态码还是 200。也就是说，内容治理被做进了“成功响应”的语义里。传统 API 里，“我不让你做这件事”是一个 4xx 错误；大模型 API 里，“我拒绝生成这个内容”是一次成功的、正常计费的调用。治理的位置变了。

usage（用量）。 这次调用花了多少 input token、多少 output token、缓存读了写了多少——计费凭证直接长在每一个响应体里。传统平台的计费在网关层，按调用次数记账，业务代码根本看不见；大模型 API 把计费颗粒度直接暴露进了 API 语义内部，每次调用都自带一张明细账单。

这对做平台的人是个信号：计量（metering）从一个后台的、事后的动作，变成了 API 契约的一部分。 你自己的每一次调用都能实时看到成本，这在传统开放平台里是要专门建一套用量系统才能做到的事。

三、最核心的设计：工具调用循环，一套内置在 API 里的双向协议

前面两节其实还在“请求-响应”的框架里。真正让大模型 API 成为新物种的，是工具调用（tool use / function calling）。

机制是这样的：你在请求里带一个 tools 数组，每个工具是一份“说明书”——名字、描述、一个 JSON Schema 定义的参数结构。模型如果决定要用某个工具，就返回 stop_reason: "tool_use" 加一个 tool_use 块（工具名 + 它填好的参数）。然后模型停下来，等你的代码去实际执行这个工具，把结果作为一条新的消息回填进对话，循环继续，直到模型说 end_turn。

这个循环有三个含义，每一个都值得单独咂摸：

第一，一次对话内，调用方和被调用方在持续互换。 一开始你调用模型；模型转头“调用”你的工具；你执行完把结果喂回去，它接着往下想。

有人会立刻反驳：传统 API 也有回调啊，Webhook 不就是平台反过来调你的代码吗？没错，所以这里要说得更准一点，差异不在“有没有回调”，而在回调的性质。Webhook 是异步、解耦、事件触发的：某个预定义事件发生了（支付成功、订单发货），平台往你事先注册的一个 URL 发一条通知，发完就不管了；你什么时候处理、处理不处理，和触发它的那次原始请求早就脱钩了。

工具调用的回调是同步、在带内（in-band）、由模型临场决定的：模型生成到一半，基于推理判断“我现在需要这个信息”，于是把当前这次请求挂起，等你的结果回来，再从挂起的地方接着想下去。不是两个解耦的事件，是同一个思考过程的暂停与恢复。而且触发它的不是预定义规则，是模型的临场判断——你事先并不知道它会不会调、调哪个、调几次。

所以准确的说法不是“传统 API 单向、大模型 API 双向”，而是：传统 API 的回调是事件驱动的异步通知，大模型 API 的回调是推理驱动的同步挂起。 后者这种“一次调用把自己挂起、等外部输入再恢复、如此循环往复”的形状，才是传统 API 里真正没有的东西。

第二，工具的 description 是写给模型看的，它决定模型选不选你。 模型面对一堆工具，靠什么决定调哪个？靠每个工具的自然语言描述。描述写得清楚、边界划得准，模型就用得对；写得含糊，模型要么不调要么乱调。这催生了一个全新的东西——我把它叫**“面向模型的 SEO”**：过去开发者做 ASO 是为了让人在应用商店里搜到你、点你；现在你写工具描述，是为了让模型在一堆工具里“想得起你、选得中你、调得对你”。流量分配权，从运营团队和搜索算法，转移到了模型的判断里。

这不是我的推演，平台已经在为它立法了。OpenAI 的 ChatGPT 应用审核指南里有一条“公平竞争”条款，明文禁止开发者在描述、标题、工具注释等**“模型可读字段”**里操纵模型的选择——指南举的例子就是“指示模型’优先选我这个应用’”；同时要求描述不得贬低竞品、不得诱导“超出用户明确意图的过宽触发”。有 SEO 的地方就有黑帽 SEO：当平台开始为一种作弊行为写反作弊条款，恰恰证明这种流量已经真实存在、值得去抢了。

第三，MCP 只是把“工具供给”这件事标准化了。 每个开发者手写 tools 数组太重复，于是 Model Context Protocol（MCP）出现，把工具的定义和供给变成一套可复用的协议件——你不再为每个应用重写工具，而是接一个 MCP server 进来。它没有改变工具调用的本质，只是给“供给侧”做了标准化。这个标准化走到了多远，两个事实可以标定：2025 年 12 月，Anthropic 把 MCP 捐给了 Linux Foundation 旗下新成立的 Agentic AI Foundation（同批创始项目还有 OpenAI 捐的 AGENTS.md）——从一家公司的接口变成中立标准；彼时它的 SDK 月下载量已近亿次、活跃 server 上万。工具协议这一层，已经不是任何一家的私产了。

（工具还有更细的层次：除了你自定义的工具，还有平台定义、由你在自己环境里执行的工具（bash、文本编辑器、computer use），以及平台自己执行的 server tools（网页搜索、代码执行）。其中 computer use 尤其值得单独拆——它到底是靠截图还是靠结构在“看”屏幕、被它操作的又是不是你自己那台电脑，都藏着反直觉的东西。展开太长会盖过主线，我把它放到了文末附录。）

四、采样参数正在被平台收回

大模型 API 有一类传统 API 完全没有的参数：temperature、top_p 这些采样参数，控制模型输出的随机性。它们的存在本身就说明了大模型 API 的一个特质——它不是确定性的。同样的输入，调两次可能得到不同的输出。非确定性在这里是特性，不是 bug。传统 API 的幂等、可重试、可 mock，在这里统统不成立。

但 2026 年正在发生一件很值得盯的事：平台开始把这些旋钮收回去。

Anthropic 在最新一代模型上，直接移除了 temperature、top_p、top_k——你要是还传，接口报 400 错误。取而代之的是两个更高层的东西：thinking（自适应思考，模型自己决定要不要深想、想多久）和 effort（认知努力档位，从 low 到 max）。DeepSeek 也跟进了类似方向，思考模式带一个 reasoning_effort 参数。

我的解读是：这是一次平台治理动作。 平台把“你到底怎么采样、怎么思考”这个底层的、开发者其实也调不明白的控制权收回去，只对外暴露一个“你想让我想多深”的高层旋钮。把一个不可解释的连续参数（temperature 到底调到 0.7 还是 0.8 意味着什么，没人真说得清），换成一个可解释的离散档位（low / medium / high / max，语义清楚）。

这件事在开放平台设计里是有先例的——能力的抽象层级在往上走。就像早年的 API 会暴露一堆底层参数，成熟之后往往收敛成几个语义清晰的模式。只不过在大模型这里，这个收敛发生得特别快，而且带着明确的“我比你更懂怎么调”的平台自信。国内各家目前还大多保留着采样参数，是否跟进，是一个值得持续观察的信号。

五、一个 API，还是很多个？——归拢的四种哲学

到这里你可能以为大模型 API 就是那一个 /messages 端点。其实不是。每家平台在“要不要把所有能力归拢成一个统一 API”这件事上，走了四条不同的路。这四条路特别能看出各家的平台战略。

① OpenAI / xAI：统一交互 API + 分立生成 API。 OpenAI 推了 Responses API，把对话、工具、内置工具、状态管理归拢成一个端点，并且明确宣布它要取代老的 Chat Completions 和 Assistants API。但图像、音频、Realtime（实时语音）仍然是各自独立的端点。xAI 直接把 Responses 这个形状抄了过去。OpenAI 是第一个把“归拢”当成一个公开的 API 战略叙事来做的——配着弃用公告、迁移指南、统一底座一起推。

② Google Gemini：单一巨型端点。 Gemini 其实归拢得更狠——一个 generateContent 端点，吃下文本、图像、视频、音频的理解，甚至顺手把一部分生成也塞了进去（图像生成、TTS 都走这个端点），只有重异步的视频生成等少数拆出去。它没有 “Responses API” 这样的叙事，但实际统一度比 OpenAI 还高。

③ Anthropic：做减法式的统一。 Anthropic 只有 Messages 一族 API。它的“统一”不是把很多能力归拢进来，而是根本不做那些能力——没有 embedding、没有自助微调、没有图像/视频生成、没有实时语音。六个 API 家族它砍掉一半，把全部注意力压在 agent 循环和托管 runtime 上。这是一种战略性的克制。

④ 国内各家：不归拢。 智谱、MiniMax、百炼这些平台，普遍沿用 chat/completions 的形状，再给每个模态配一套独立的异步任务 API。MiniMax 最典型：语言、语音、视频、音乐各开各的门户。它们的定位是“多模态能力供应商”，能力越全越好，归不归拢不是重点。

顺着这个话题，把大模型平台的 API 家族做一次全景收束——它其实远不止对话一个。我把它们按设计形状分成六族，而形状由两个第一性变量决定：计算要花多久，以及状态放在哪一侧：

  1. 同步推理族（秒级、无状态、按 token 计费）：对话、Embeddings（文本转向量，RAG 的地基）、Rerank、Moderation（内容分类，把治理做成 API）、Token Counting（计量预检，“先问多少钱再下单”）。
  2. 异步任务族（分钟级以上，创建任务→轮询或回调→取结果）：Batch API（请求打包、延迟换五折）、图像/视频生成、微调（产出的不是数据，是一个新的 model ID——调用方从消费者变成了平台能力的共同生产者）。这一族的形状是传统开放平台最熟悉的“异步任务 + 回调”。
  3. 实时流族（双向、有状态、连传输层都换了）：Realtime API 用 WebSocket 甚至 WebRTC，语音进语音出，会话状态在服务端。
  4. 资源管理族（经典 REST CRUD 原样回归）：Files API、Models API（机器可读的能力发现——每个模型返回自己的上下文窗口、支持哪些特性）、向量存储。
  5. 托管 runtime 族：Agent 作为平台资源（下一节展开）。
  6. 治理配套族：用量 API、评估 API、限流。

这里有一个对做平台的人特别重要的观察：越往外围，越是传统 REST。 真正的新物种只有同步推理和实时流那两小块（无状态、stop_reason 循环、内容块、缓存经济学）；异步任务、资源管理、治理配套这些，几乎就是传统开放平台 API 设计的换皮。也就是说——传统开放平台的 API 设计经验，在大模型平台的外围 API 上几乎全部适用，真正需要重新学的，只有推理端点那一小块的语义。

六、协议对象变了：过去是你的代码，现在是模型

这是我认为对做平台的人最重要、也最容易被忽略的一处转变。

传统开放平台 API 的“协议对象”是开发者的代码。文档写给人看，人读懂了去写代码调你。一切设计——端点粒度、错误码、字段命名——最终服务的是“让工程师读懂并写对”。

大模型平台的协议对象，很多时候是模型本身。工具的 JSON Schema 是写给模型解析的；工具的 description 是写给模型判断的；甚至连文档，都在长出一个“写给模型看的版本”。

最典型的载体是 llms.txt——放在网站固定路径下、给大模型/agent 当入口的一份 Markdown 结构化索引，类似 robots.txt 之于爬虫。它告诉一个来访的 agent：这个平台有哪些能力、当前任务该先读哪一小组文档、要全文或 schema 从哪里拿。

哪家做了 llms.txt，是一个耐人寻味的信号。就大模型厂商这一圈，我实测的结果是：Anthropic、智谱、MiniMax 做了；OpenAI、Google 反而没做。 而且这远不是模型公司的专属动作——Stripe、GitHub、AWS、Cloudflare、Shopify 这些传统开放平台早就挂出了自己的 llms.txt，我自己参与建设的电商开放平台，最近也刚把它做了出来。所以规律不是“越大越做”，也不是“AI 公司才做”，而是横跨两个阵营的同一条：越是需要被 agent 主动消费的一方，越先做。 流量弱势方、想让自己更容易被 agent 找到和调用的一方，先把文档改造成“给模型读”的形态。这和传统时代“弱势平台先做开发者友好”的逻辑一模一样，只是“友好”的对象从人变成了模型。

对做开放平台的人，这里的判断可以直接落地：你的文档从此有两类读者——人和 agent——而大多数平台的文档，至今只为前者设计过。 面向 agent 的文档改造（llms.txt、每个页面的 Markdown 版本、可 fetch 的 OpenAPI spec、工具描述的语义清晰度），传统平台阵营里已经有一批先行者动起来了，但离拥挤还早——仍然是一块低成本、高回报的开发者体验投资。

七、兼容端点：一场正在进行、但很少人点破的协议战

最后一个切面，藏在各家文档的“接入指南”里，不注意根本看不见。

先说一个几乎全员标配的事实：除了 OpenAI 自己，几乎所有平台都提供 OpenAI 兼容端点——换一个 base_url、换个 key，你原来调 OpenAI 的代码就能调它。OpenAI 的 API 格式，赢下了对话时代的兼容战，成了事实标准。

但真正有意思的是另一件正在发生的事：国内四家新兴大模型——智谱、DeepSeek、Kimi、MiniMax——全部提供了 Anthropic 兼容端点。 智谱三套协议（OpenAI / Anthropic / 原生）全兼容；DeepSeek 开了 api.deepseek.com/anthropic 这个专门的 base_url；Kimi 甚至开了两个 Anthropic 端点（一个通用、一个专供 coding 工具）；MiniMax 更直接，把 Anthropic SDK 列为推荐接入方式。智谱和 DeepSeek 还把“如何用 Claude Code 接入我们”写成了官方文档的一级章节。

为什么？因为它们兼容的不是 Anthropic 的模型，是 Anthropic 的 harness 生态。 Claude Code、Claude Agent SDK 这套工具链，是 agent/coding 时代开发者聚集的地方。你只要说 Anthropic 的协议，一个开发者就能把整套 Claude Code 的能力，换个 base_url 直接跑在你的 GLM、Kimi、DeepSeek 上。兼容 Anthropic 协议，等于免费接入了这个巨大的开发者习惯池。

于是浮现出一个此前很少被点破的判断（这是我的判断，不是行业共识）：OpenAI 协议赢了 chat 时代的兼容战，Anthropic 协议正在赢 agent/coding 时代的兼容战。 这是一场协议层的竞争，比 MCP 之争更隐蔽，但可能更关键——因为它争夺的是 agent 时代最稀缺的东西：开发者的肌肉记忆。

顺着这个视角回头看，Anthropic 对自己两种协议的处置耐人寻味：工具协议（MCP）捐出去，交给中立基金会换普及和标准地位；消息协议（Messages API 格式）攥在手里，靠 harness 生态的引力让别人主动来兼容。一放一收，是同一场标准战的两种打法——放出去的换生态广度，留下来的换生态深度。

尾声：绕了一圈，又回到了 REST

我用传统 API 设计的眼睛看了一圈大模型 API，最后停在一个有点像寓言的观察上。

大模型 API 从一个极简的、无状态的单端点出发（/messages，什么都不记，每次重发全部历史）。但当你需要它做真正复杂的、长时间的、有记忆的工作时，这个无状态原语开始往上长——长出了托管 runtime：OpenAI 的 Responses API 开始在服务端存状态，Anthropic 的 Managed Agents 把“agent”变成了一个持久化、版本化的资源对象，配上运行实例、容器环境、定时调度、凭证托管、审计记录。

这里得公平地说一句：托管 runtime 本身不是什么新发明——AWS Lambda 替开发者跑代码已经跑了十几年。真正新的是 runtime 里跑的东西变了：过去是执行路径被代码预先写定的确定性程序，现在是一个每步都由模型临场决定的概率性循环——同一个目标，这次调这三个工具，下次可能换一条路走。所以平台要管的不再只是“代码能不能跑”，还多了“它为什么这么选、哪一步需要人来确认、跑偏了算谁的”。

你发现没有——API 的形状绕了一大圈，又长回了传统 API 设计里最熟悉的那个东西：REST 资源模型。 版本化、生命周期管理、审计、凭证托管、Webhook 签名与重试……全是传统 API 设计里的老问题。

只是这一次，被管理的资源不再是“数据”，而是“一个正在运行的智能”。

所以大模型 API 对做平台的人，是一件既熟悉又陌生的事。陌生的是核心那一小块——无状态回放、stop_reason 循环、工具调用的挂起-恢复循环、缓存经济学、写给模型看的文档——这些是真正的新物种，得从头学。但一旦越过这层核心，走到外围的异步任务、资源管理、版本治理、runtime 托管，你会一次次撞见早就熟悉的老问题，换了个新宿主，重新变得值钱。

这里有一个不算坏的结论：这套经验没有过时，它只是换了一个需要被重新翻译的场景。而看懂大模型 API 到底新在哪、旧在哪，就是这次翻译的第一步。

附录：computer use 拆解——它看的是截图还是结构？操作的是谁的电脑？

这部分从正文第三节抽出来。它是“工具调用”里一个特别值得挖的特例，展开却会盖过 API 设计的主线，所以挪到这里给愿意深挖的人。

先把“工具”拆成三层，而不是两层：

类型 Schema 谁定义 谁执行 例子
自定义工具 你 你 你自己写的业务工具
平台定义、客户端执行 平台（模型为这套 schema 专门训练过） 你（在你控制的环境里——本地机、容器、或一台云上的虚拟机） bash、文本编辑器、computer use
服务端工具 平台 平台 网页搜索、代码执行

computer use 落在中间那一类：模型输出结构化动作，执行环境由客户端提供。它之所以是“平台定义”，是因为模型针对这套精确的动作 schema 做过专门的后训练——schema 就是契约，训练就是绑定。但它比其它工具更值得挖，因为两个细节都藏着反直觉的东西。

第一个问题：模型到底是怎么“看”屏幕的？

先纠正一个很常见（我一开始也踩过）的直觉：computer use 不是“每一步都截个图、盲猜坐标去点”。它更像一个闭环的 GUI 代理——读取当前界面状态 → 选定要操作的元素 → 执行点击/输入 → 再读一次状态 → 判断这步成没成，如此循环。

关键在“读取界面状态”这一步，它其实有两个信号源：

  • 结构信号（accessibility tree / DOM）：按钮叫什么、输入框里填了什么、有哪些菜单项、可操作元素的索引。桌面程序通过操作系统的无障碍接口暴露它（屏幕阅读器就是靠这个工作的），网页通过 DOM 暴露它。对标准的表单、设置页、菜单，这是主要依据。
  • 像素信号（截图）：补足结构表达不了的东西——canvas 画布、图表、布局有没有错位、自绘控件、悬浮层、颜色状态。

所以对截图的依赖不是“有或无”，而是一条随界面有多“视觉化”而滑动的光谱：标准按钮表单，主要靠结构、截图很轻；网页视觉验收、视觉 bug，必须看截图；canvas、远程桌面、设计工具、自绘控件，几乎退回纯视觉操作。每操作一步它都会重新读状态，但正常 UI 下它优先读更新后的结构树、重新取元素索引，只有视觉判断必要、或结构信息不全、或行为异常时，才重点依赖截图和坐标。

这也划出了 computer use 的能力边界：比纯坐标自动化稳（它理解“保存”“继续”“邮箱”这类语义元素，不是死记坐标），又比 API/MCP 脆（GUI 会因弹窗、加载、窗口遮挡、控件重绘而变化）。所以一条实用判断是：能用 API、MCP、CLI 或浏览器 DOM 的场景，优先别用纯 computer use；只有必须操作或验证 GUI 时才走这条路。各家产品在这条光谱上的默认位置也不同——Anthropic 的 computer use 工具明显偏截图/视觉，Codex 的桌面 computer use 偏“结构树优先、截图补足”，Google 的 Gemini computer use 偏 DOM。

理清了这个，就能拆掉另一个更容易混的概念——computer use 和“操作浏览器”是两回事。 区别不在“用不用截图”，在作用域：

  • computer use：作用域是整台电脑——原生桌面软件、系统设置、任意窗口。它既要读桌面无障碍树，也要能截图兜底，因为桌面上什么奇形怪状的画面都可能遇到。
  • 操作浏览器：作用域只圈在网页内，走的通常是 Chrome 插件 / 浏览器扩展（或 Playwright、CDP 这类）那条路。网页不只暴露 DOM，还能给出控制台、网络请求这些额外的结构化信号，比桌面无障碍树更丰富、更可靠。

“Claude Code 到底用不用截图”这个困惑，根子就在这个混用上：Claude Code、Codex 操作网页时，走的是这条结构更富的浏览器路径，不是那个通用的、更偏截图的 computer use 原语——所以它操作网页时主要不靠截图。两者作用域不同、信号源不同，说的压根是两件事。

第二个问题：被操作的，是我自己的电脑吗？

不一定——而这正是“客户端工具 / 服务端工具”这条线的关键。

默认情况下，computer use 是客户端工具。Anthropic 的文档说得很直白：截图、鼠标动作、键盘输入、涉及的文件，全都发生在你的环境里，不经过 Anthropic。模型只负责“想”，执行环境（那台机器、那个浏览器）是你提供的。这台机器是什么是你的自由：可以是你本地的电脑，可以是你起的一个 Docker 容器，也可以是你在云上租的一台虚拟机。

而当它“服务端化”——比如在 Claude Code 网页版、或托管 Agent 里跑——发生的事情正是你会猜到的那样：平台自己开了一台隔离的云端虚拟机，模型操作的是那台云机器，不是你的电脑。 Claude Code 网页版给每个会话配一台 Anthropic 托管的 VM；托管 Agent 按“活跃会话小时”计费（约 $0.08/session-hour），买的就是这台云沙盒的算力、检查点和崩溃恢复。你的本地电脑从头到尾没被碰过——模型操作的是一个用完即弃的云端桌面。

把两个问题连起来看，会浮出一条更大的暗线：感知方式（截图还是结构）是模型侧的设计选择，而执行环境的宿主（你的机器还是平台的云机）是平台侧的收权动作。 后者尤其值得记住——它正是正文尾声那条“无状态原语长回托管 runtime”的暗线，在工具层的一个具体切片：平台在一件一件地，把“原本你得自带的执行环境”变成托管服务。

（附：本文事实以各家 2026 年 7 月官方文档与定价页为准。价格、模型名、退役日期这类数字保鲜期以季度计，读到时请以官方最新为准。）