问 Claude Opus 5.5 支持哪套「电脑操作」工具，Anthropic 的文档会按你在哪里跑它给出两个答案——而这两套工具的截图上限并不相同，于是同一个模型字符串买到的是两个智能体：定位精度不同，每步成本也不同。对一个 GUI 智能体来说，可移植性的单位不是模型名，而是（模型，工具版本）这一对；而你的配置里没有任何东西让这一对显形。
一眼概览
两代工具同时在线，而分界线是沿着平台、而不是沿着模型划的。下表每一行都出自电脑操作工具参考文档。
| 属性 | computer_toolset_20260801 | computer_20251124 |
|---|---|---|
| 在请求里的形状 | 一个 toolset 条目，展开成 17 个具名成员 | 一个单独的工具版本 |
| beta 请求头 | 不需要 | 必需 |
| 截图上限 | 长边 2,576px，共 4,784 个视觉 token（约 375 万像素） | 长边 1,568px，约 115 万像素 |
| 状态：Claude API、Google 托管的 Google Cloud 版 Claude | GA，且是 Claude 5.5 及更新模型上唯一的选项 | 在 Claude 5.5 及更新模型上报错 |
| 状态：Bedrock、Claude Platform on AWS、Microsoft Foundry | 不可用 | beta，且是唯一的选项 |
| 只支持这一套的模型 | — | Claude Opus 4.7、Opus 4.6、Sonnet 4.6、Opus 4.5 |
真正造成伤害的那句话
那份参考文档里有两句话，单看都不起眼，合起来就是一个可移植性问题。第一句：「在 Claude API 与 Claude Models on Google Cloud（Google 托管）上，Claude 5.5 及更新的模型只通过 computer_toolset_20260801 toolset 支持电脑操作，对更早的 computer_20251124 与 computer_20250124 工具版本返回错误。」第二句：「在 Amazon Bedrock 上，Claude Opus 5.5、Claude Sonnet 5.5 与 Claude Haiku 5.5 接受更早的 computer_20251124 工具版本，正如 Claude Opus 5 与 Claude Sonnet 5 一样。」
把两句放在一起，「Claude Opus 5.5 用哪套电脑操作工具」这个问题就没有答案了。它有两个答案，由托管平台挑选；而在一边能跑通的那个请求，在另一边是一个 400。这不是新旧并存、你自己掌握节奏去迁移的那种弃用窗口。这是一次分叉：Claude API 已经整体搬到了 toolset 上并拒收旧版本，而三个合作平台只带着旧版本、接不了新的。
更早的那批模型则是朝反方向分叉的，而这就把后路也堵上了。Claude Opus 4.7、Opus 4.6、Sonnet 4.6 与 Opus 4.5「只通过更早的 computer_20251124 工具版本支持电脑操作，而该版本需要一个 beta 请求头」。所以在 Claude API 上，没有任何一个模型同时接受两个工具版本。没有可供你做 A/B 的交集。
两套工具真正的差别在哪里
如果差别只是一串版本号，这就只是文书工作。它不是；而最要紧的那道缺口，恰恰是一次基准测试会捕捉到的。toolset「接受长边最多 2,576 像素、合计最多 4,784 个视觉 token（⌈宽 / 28⌉ × ⌈高 / 28⌉，约 375 万像素）」；而更早的工具版本接受「长边最多 1,568 像素、合计约 115 万像素」。空间定位——给出那个按钮的像素坐标、而不是叫出它的名字——是 GUI 智能体里占主导的错误类别，而它对「模型得以看到多少像素」直接敏感。可用细节上 3.3 倍的差距不是配置层面的细微之处，而是在小目标上两种不同的准确率体制。
新 toolset 还加进了一个读起来就像是针对这类错误的成员。zoom 接受一个 [x0, y0, x1, y1] 形式的 region，并以全分辨率重新捕捉这块区域——这是 API 层面上的一次承认：卡住它的那条约束从来不是屏幕尺寸，而是「将要点下去的那一点上的分辨率」。文档也从另一头说了同样的话，就在它的排障建议里：如果点击打偏了，就启用 zoom、用带位置的提示词、或者把任务切成更小的步骤。而一套写在 computer_20251124 上的外壳，没有这样一次调用可打。
还有两处较小的差别，会在直接移植时咬人。toolset 以单个 {"type": "computer_toolset_20260801"} 条目抵达，它的 tool_use 块携带 "toolset_name": "computer" 加一个成员名；于是按扁平工具名分发结果的代码需要重写，而不是改个名。而旧版本需要一个新版本不需要的 beta 请求头——这意味着一份只是把版本号换掉的配置，会产出一个在两处同时出错的请求。
为什么这先是评测问题、后才是迁移问题
这次分叉的实际代价，是它拿走了你本来唯一拥有的受控对比。升级一个 GUI 智能体通常意味着只改一件事、再跑一遍你的套件：新模型、同样的工具、同样的截图、同样的步数预算。而在这里，模型与工具是一起动的，而工具还带来了一个不同的观测空间。升级之后分数提高了，你也归因不了，因为模型变了、可用分辨率变了、动作集也变了，都在同一个提交里。
这对电脑操作比对文本智能体更要紧，因为 GUI 基准数字本来就在恰好这个维度上脆弱。OSWorld 一类的结果是在不同步数上限、不同屏幕分辨率、不同工具权限下报出来的——这正是第三方榜单会对同一天的同一个系统各说各话的原因。一个没有附上步数上限与截图分辨率的数字，不是对模型的一次度量。而现在，截图分辨率还部分地取决于你是从哪个云买的这个模型。
所以，一份诚实的多平台部署对应的是两次评测运行、而不是一次。如果你在一个区域提供 Claude API、在另一个区域提供 Bedrock，那你运维的是两个共用一个名字的智能体——而跑在旧工具上的那一个，正是你没有量过点击准确率的那一个，因为你的套件是对着另一个拿到的帧尺寸跑的。
在每一条 trace 里，把工具版本记在模型字符串旁边，并让评测结果以这一对为键。一条只写着 claude-opus-5-5 而别无其他的 trace，六周之后没法告诉你点击准确率的回退来自模型、帧尺寸还是宿主——而在这个接口上，这是三件不同的事，你的配置却把它们叫成一件。
这周该做什么
四步，按代价从低到高排列。
- 查清你实际发出去的是哪套工具。在你的外壳里 grep
computer_，再跟你打的那个平台对一遍。搬到 Claude API 之后 beta 请求头还留在那儿，是这个 bug 最常见的形状，而它会大声失败；更安静的那一种，是一套你以为已经跟着别的东西一起升级过的 Bedrock 部署。 - 把截图分辨率显式钉住，而不要去继承显示器的。文档对桌面任务推荐 1024×768 或 1280×720，对网页应用推荐 1280×800 或 1366×768，并警告不要超过 1920×1080。这些推荐值都明显低于 toolset 自己的上限——这就是那条线索：那个上限是留给
zoom的余量，不是一个新的默认帧。 - 按平台、而不是按模型重跑你的定位评测。每个（模型，工具版本）对一次运行。如果只够跑一次，就跑旧工具那套，因为它正是你现有数字没有描述的那个配置。
- 把平台迁移当成一次外壳改造。结果分发、动作词汇表、你在缩放截图时所做的坐标换算，以及每个动作之后的那次核验，全都触到工具契约。文档对最后这一条为何要紧说得很直白：「Claude 有时会表现得仿佛自己的动作已经成功，而没有显式去检查结果。」
这里的普适教训比电脑操作走得更远。模型名对「你到底部署了什么」的描述正在变得越来越不完整：effort 设置、思考模式、工具版本，现在又加上观测上限，全都在它底下变动，而其中好几样还按宿主变动。解法不是更警惕，而是身份——把那个决定行为的完整元组记下来，并让评测结果与运行时以同一件东西为键。文本接口上的同一种失效见提示词可移植性；一个你从未设置过的值在你底下改变时会发生什么，见未钉住的厂商默认值。
常见问题
同一份电脑操作代码能同时跑在 Claude API 和 Amazon Bedrock 上吗？
不分支的话不能。Claude API 带的是 computer_toolset_20260801，并在 Claude 5.5 及更新的模型上对 computer_20251124 返回错误；而 Bedrock、Claude Platform on AWS 与 Microsoft Foundry 只带更早的 beta 工具版本。请求形状、beta 请求头与截图上限三者都不同。
新 toolset 更高的分辨率上限，是不是该用来发更大的截图？
默认不是。文档里的推荐值仍停在桌面任务 1024×768 或 1280×720；而那个上限是以视觉 token 计价的（⌈宽 / 28⌉ × ⌈高 / 28⌉，最多 4,784），所以更大的帧就是循环里每一步更贵的账。把这截余量花出去的精准方式是 zoom——只对你即将点下去的那块区域。
要点击准确率的话该用哪个模型？
那份参考文档对旧工具的模型做了直接比较：Claude Sonnet 4.6「在机械式点击上比 Claude Opus 4.6 更精准」，而 Claude Opus 4.7「与 Sonnet 4.6 大致相当」。这提醒我们：在这个接口上，推理最强的模型不会自动是最好的执行器；而这也是「按配置去测量、而不要继承一份排名」的又一个理由。
这对驱动浏览器而不是桌面的智能体有影响吗？
它影响任何以截图作为观测的智能体，因为上限与动作集是工具的属性、而不是目标的属性。一个通过 DOM 或无障碍树工作的智能体对帧尺寸差异是绝缘的——这本来就是混合定位的论据之一。
这些平台会收敛吗？
文档说更早的工具版本「对不支持 toolset 的模型与平台仍以 beta 形式可用」，这描述的是现状、不是时间表。请按「这次分叉会持续存在」来构建，并把工具版本当成配置里的一等值、而不是一个常量。
延伸阅读
本站相关：
- 计算机操作与 GUI 智能体——定位、截图循环，以及可靠性税。
- 「看一眼」的每步成本——一张截图在被循环反复重发之后到底值多少钱。
- GUI 定位——知道该点什么与知道它在哪里，是两种不同的本领。
- 提示词可移植性——文本接口上同一种隐藏变量问题。
- 未钉住的厂商默认值——不经你部署就改变的行为。
- 评测编程智能体——让结果以配置为键，而不是以名字为键。