6 月 15 日，Anthropic 推送了一封隐私政策更新邮件：7 月 8 日起，Claude Free、Pro、Max 个人用户可能被要求上传政府签发的身份证件，外加实时人脸比对。触发场景涵盖 Agent 任务执行、系统风控标记、平台随机抽查，验证方为第三方服务商 Persona。
这则消息在技术社区引发了两层讨论。第一层关于账号安全和区域限制——Claude 不在中国大陆官方支持范围内，提交身份证意味着主动告知"我来自不支持区域"，账号直接面临封禁。但第二层更值得注意：Anthropic 为什么要推实名？
把政策原文读两遍，会发现 Anthropic 焦虑的不是"用户身份"本身。它焦虑的是 Agent 能力越来越强、多步骤任务越来越复杂，但平台不知道每次操作背后是谁。出问题之后怎么追溯？怎么阻断？翻译成技术语言，就是三个词：可追溯、可问责、可阻断。
三层治理模型：从人到调用再到行为
这三个词放在企业内部 AI 调用的场景里，同样适用——而且大多数企业在这三件事上的现状，比 Anthropic 焦虑的个人用户实名要棘手得多。
过去一年和不少技术团队交流下来，一个共同画面是：API Key 散落在项目配置文件、CI/CD Secret 变量、甚至飞书聊天记录里。有人离职几个月了，Key 还在后台跑。问到"这个月 API 花了多少"，财务只能给一个总数，分不清是哪个项目、哪个人、调的哪个模型。
Anthropic 花大力气解决个人用户的身份问题，但企业内部，AI 调用几乎处于匿名使用状态。这个差距值得拆开看。
第一层：身份实名。 谁在操作？Anthropic 做的是上传身份证、确认屏幕后面是个有身份的人。出事了找得到人。
第二层：调用实名。 这次 API 请求是谁发的？哪个项目？哪个环境？走的是哪个 Provider？一个 30 人团队同时用着多个大模型，技术负责人需要的不是每个人的身份证号，而是每次调用的归属——请求落在哪个项目上、是谁的 Key 发出的。这才是企业场景下真正有意义的"实名"。
第三层：行为实名。 调完之后呢？该不该拦？花了多少？某个项目本月预算是 200 美元，已经跑到 180 了，要不要提前告警？凌晨三点某个 Key 突然刷了 500 次调用——是正常的夜间任务还是泄露了？这些是 Anthropic 的身份证模式覆盖不了的问题。
Anthropic 的实名卡在第一层。但企业内部真正需要的是后两层：调用归属 + 行为审计。这是 API 调用层面的"实名制"，跟身份证无关，跟 Key 的治理有关。
技术方案：给每次调用打上"身份证"
这个问题的工程解法并不复杂，本质上是在请求链路上加一个透明代理层。核心设计有三块：
虚拟 Key 映射。 开发者的代码里不直接写云厂商的原始 Key，而是用一个没有实际权限的虚拟 Key。虚拟 Key 绑定了人和项目——谁生成的、属于哪个环境、能调哪些模型、月度额度多少。真正的云厂商 Key 存在本地加密存储中，不进代码仓库，也不进 CI/CD 变量表。虚拟 Key 泄露了可以随时吊销、重新签发，不影响生产环境的原始凭证。
本地代理拦截。 所有 API 请求经过一个本地 HTTP/HTTPS 代理。代理在转发前完成三件事：校验虚拟 Key 是否有效、检查调用额度是否充足、检查请求的模型是否在白名单内。正常请求零感知透传，只有规则被触发时才介入——告警或阻断。
// 代理层核心逻辑伪代码
func (p *Proxy) Handle(req *http.Request) (*http.Response, error) {
// 1. 从 Header 中解析虚拟 Key
vKey := req.Header.Get("X-Virtual-Key")
// 2. 校验身份 + 归属
identity, err := p.lookupIdentity(vKey)
if err != nil || identity.Status == Revoked {
return p.deny(403, "invalid credential")
}
// 3. 检查额度 + 白名单
if err := p.policyEngine.Check(identity); err != nil {
return p.deny(429, err.Error())
}
// 4. 替换为真实 Key 并透传
req.Header.Set("Authorization", "Bearer "+identity.RealKey)
return p.upstream.RoundTrip(req)
}
数据不出域。 代理跑在本地，调用日志、Token 消耗、账单数据全部留在执行机器或内网的存储里。与 Anthropic 把验证数据交给 Persona 的逻辑类似——谁处理敏感数据，谁就对数据负责。对于企业来说，这意味着 API 调用记录不需要推给任何第三方平台。
和阿里云生态的结合点
如果团队已经在使用阿里云 API Gateway 或函数计算，可以在现有架构上叠加类似的调用治理层。阿里云 API Gateway 的插件机制支持自定义认证逻辑，结合 RAM 角色授权，能为每个 API Key 分配最小权限。再配合云监控（CloudMonitor）和日志服务（SLS），就能构建一套"调用前鉴权、调用中记录、调用后可审计"的闭环。
关键是把"谁在调什么"这个信息维度补进现有的监控体系里。API 流量的总量曲线告诉你花了多少，但不会告诉你花在哪个项目上。补上这层归属，才算把从计量到治理的链条走通了。
总结
Anthropic 这次实名制，本质上是在给 AI 调用装一块"水表"：知道流量从哪来、到了哪去、谁来买单。这个方向没有错，只是对企业来说，需要装的不只是一块总表——而是每个房间、每个水龙头的分表。
从技术角度看，这整套体系不过是一个带策略引擎的本地代理层。但它的价值不在于代码复杂度，在于把"调用归属"从一个手动管理的流程问题，变成一个自动生效的基础设施能力。常态无感，异常介入。和 Anthropic 实名制的设计哲学，本质上是同一件事。
