Claude API 的工作区校验是一个很小的检查，但它补上了一个让人不太舒服的可观测性缺口。一个多工作区凭证可以把请求发往某个工作区，而过期的部署设置、复制来的 ID 或者路由错误，却可能让请求实际落到另一个地方。如果只记录配置里的工作区，后面每一次成本和资源查询，都建立在一个未经证实的假设上。

响应头里多了一个字段

打开网易新闻 查看精彩图片

Anthropic 现在会在已完成工作区解析的 Claude API 响应中返回 anthropic-workspace-id。作者的做法是：先把路由配置和一个独立维护的授权映射做比较，再拿响应里的权威值和已授权工作区比对，之后才让应用去解析、持久化或归因结果。

Anthropic 的工作区文档把两个容易混淆的概念分开了。请求可以携带 anthropic-workspace-id，前提是多工作区密钥选择了目标工作区。而成功响应里携带的，是凭证实际解析到的工作区。配置说明应用本来想做什么，响应才说明服务商实际在哪里处理了请求。

为什么要在响应上做校验

这件事的影响不止于成本看板。文件、消息批次、Skills、提示缓存以及其他资源，都可能按工作区划分范围。如果把资源 ID 存到错误的内部租户或环境下，故障往往要到后面才暴露出来：资源找不到、配额异常，或者用量看起来凭空消失。

解决办法不是记录更多配置。作者使用两个独立管理的输入：一个路由目标，一个授权租户到工作区的映射。在 HTTP 边界同时断言两个不变量：

  • 路由目标等于授权工作区
  • 授权工作区等于响应中解析出的工作区

如果两个预期值只是同一个未检查设置的别名，第一次比较就没有保护作用。在作者的示例里，授权映射是一个独立参数，这样过期的部署目标会在任何请求离开进程之前就失败。作者还会把服务商返回的 request-id 和已验证的工作区放在一起保存，这对后续支持和归因工作比单独保存配置值有用得多。

在 HTTP 边界比较意图与实际工作区

这个检查应该在 HTTP 状态成功之后、响应体进入应用代码之前执行。Anthropic 在 API 概览中记录了响应头，官方 SDK 也暴露了读取原始响应的访问器。

下面是 .NET 示例的核心逻辑：先调用 EnsureSuccessStatusCode，再尝试从响应头读取 anthropic-workspace-id。如果成功响应里没有这个头，就抛出 InvalidDataException；如果实际值和预期值不一致，也抛出异常并带上“Resolved 实际值；expected 预期值”的信息。校验通过后才返回响应内容字符串。

作者对路由值、授权值和返回值都做了格式校验，要求它们以 wrkspc_ 开头，后面跟着字母数字标识符。这样可以在边界处尽早拦截不符合预期的值，而不是让错误数据流入后续的持久化和归因流程。