公司接入 Claude API：官 key、Bedrock 还是中转怎么选
老板拍板要把 Claude 接进公司工作流，要求数据不经过来路不明的第三方、能对公结算，可国内几乎买不到正规官 key，找上门的又多是低价中转。这篇梳理四条采购路线的门槛、数据路径与风险，并给出三天内可落地的试点方案、内部网关做法和成本控制清单。
老板试用完 Claude，当场决定把它接进公司工作流，采购的事落到技术负责人头上，还附带两个条件：数据不能经过来路不明的第三方，最好能对公结算、开得出票。真正的麻烦在于，国内几乎找不到"官方 key"的企业级零售渠道，主动找上门的供应商大多自称中转，报价低到让人不敢签。三天内要交结果，还要让不懂技术的决策者听懂——这是这类需求最典型的困境。
先把需求翻译成采购语言
老板说的是"买 Claude"，工程上要满足的其实是四件事：
| 老板的说法 | 实际要满足的 |
|---|---|
| 用 Claude | 稳定的模型调用能力，有可用性承诺和故障响应 |
| 数据不能乱传 | 明确的数据处理条款：是否留存 prompt、是否用于训练、是否二次转发 |
| 正规 | 可查的合同主体、发票、付款方式、责任归属 |
| 三天给结果 | 先给出路线对比和试点方案，而不是立刻全公司上线 |
把这四条列清楚，很多"便宜得离谱"的报价会自己出局。
为什么"官 key"在国内这么难买
Anthropic 的官方服务并不向中国大陆提供，注册和付费通常需要海外主体与海外支付方式。于是市面上流通的所谓官 key，绝大多数不是企业级合同，而是个人订阅额度、试用额度、区域价差账号或者共享账号的再分配。
这类 key 的共同问题是：随时可能被停、开不出票、用量与账单无法审计，而且公司数据实际上是交给了一个没有合同关系的个人。价格本身就是信号——企业级 API 是明码标价的，长期大幅低于牌价的供给，要么在补贴获客，要么会在数据、额度池或后续涨价上找补回来。
四条路线怎么选
| 路线 | 合同与发票 | 数据路径 | 主要门槛 |
|---|---|---|---|
| 云厂商托管（Bedrock、Vertex AI） | 标准云采购，可签合同 | 在云厂商侧处理 | 需要相应区域的云账号主体，结算币种与税务要财务确认 |
| 官方 API 直连 | 与官方签约 | 直连官方 | 基本需要海外实体 |
| 聚合平台 | 视平台而定 | 经第三方转发 | 数据经过第三方，票据与 SLA 需核实 |
| 第三方中转 | 差异极大 | 层层转售，不透明 | 需要逐项尽调，不能只看口头保证 |
云厂商托管：目前最接近"正规采购"的一条
Claude 系列模型在 AWS Bedrock 和 Google Vertex AI 上有托管版本，这是企业客户最容易走通合同的路径：合同、发票、账单、IAM 权限、审计日志、私网访问、用量监控都是现成的。
几个容易踩的点：
- Azure 主要提供 OpenAI 系模型，不要想当然认为 Azure 上也有 Claude，选型前按各家官方的模型清单核对。
- 云上托管版本的模型版本、上下文长度、缓存与批处理等能力，与 Anthropic 官方 API 并不总是完全同步，落地前按官方文档逐项确认。
- 国内云账号通常没有这些模型，需要开海外区域账号；外币账单能否入账、怎么税务处理，提前找财务确认，别等报销时才卡住。
- 办公网访问海外云服务不稳定时，在云上起一台小实例做统一出口，或走企业专线，不要让每个员工各自想办法。
官方 API 直连
最"纯"的路径，价格透明、功能最新，但需要有能注册和付费的海外实体。已有海外主体的公司可以优先考虑；没有的话，硬凑主体反而会带来一堆后续问题。
聚合平台
一个 key 调多家模型，支付相对友好，非常适合快速验证和多模型对比。但它本质仍是第三方转发，请求会经过平台。企业正式使用前要看清数据处理政策、日志留存、可用性承诺，以及能否提供合规票据。适合当 PoC 通道，是否作为生产通道取决于公司能否接受这条数据路径。
第三方中转：不是一律不能谈，但要看什么
把"便宜 key"和"企业服务"分开看。真正做企业生意的中转，卖的是支付、开票、额度管理、统一接口和技术支持，这些是可以验证的：
- 公司主体是否可查，能否签合同、开票、走对公；
- 是否书面承诺不留存、不训练，是否提供数据处理协议；
- 上游是谁：能否说清是官方、云厂商还是层层转售；
- 计费口径：按官方价打折还是自建倍率，有无最低消费和退款规则；
- 稳定性：限流策略、SLA、故障赔付；
- 能否导出用量明细用于对账。
"我们客户都是大厂"这类口头保证不算证据，让对方写进合同。
必须说清楚的红线
- 购买、共享、代充个人账号，或使用来源不明的低价额度，风险包括随时封停导致业务中断、公司数据流向不明、无法入账、出事无人负责。
- 用虚假主体、虚开发票的方式走账，是明确的法律风险，不要碰。
- 面向国内公众提供生成式 AI 服务涉及备案等要求，内部自用和对外服务的合规路径不同，具体请法务或合规同事确认，以主管部门最新规定为准。
- 把公司文档、代码发给境外模型服务，可能触发数据出境相关要求。先做数据分类，敏感内容脱敏或不外发。
三天内能交出的东西
第一步，给对比表，别只给一个答案。 把上面四条路线的合同、发票、数据路径、门槛、预估成本列成一页纸，让决策者做选择而不是猜。
第二步，小范围试点。 挑 5 到 10 人和一两个明确场景，按量计费跑两周，拿到真实账单再谈全公司推广。三天内承诺全员上线，风险远大于收益。
第三步，搭内部统一网关。 用 LiteLLM、one-api 这类工具做统一入口：密钥只放服务端，按人或部门发虚拟 key，记录调用量、做限额和审计。这样将来换供应商不用改业务代码，也避免了 key 在员工之间传来传去。
第四步，先把成本控制手段准备好。
- 模型分级：日常任务用便宜的小模型，难题才升级；
- 打开供应商支持的提示缓存、批处理能力；
- 设置月度硬上限和告警，超阈值自动降级；
- 代码补全、文档生成、客服问答分开算账，避免一笔糊涂账；
- 上线前就用真实业务语料跑一遍，估算月消耗量级。
如果团队要长时间在线跑 Claude Code 这类命令行工具，本地机器性能吃紧或公司出口网络不稳，也可以把这类长任务放到一台常驻的远程 Mac 上执行，本地只负责连接——这属于运行环境的选择，和 API 采购渠道是两件独立的事。
第五步，准备退出方案。 万一供应商涨价、停服或合规要求变化，业务能否在一周内切到另一条路线？统一网关加多路由配置，就是为这一天准备的。
小结
有海外主体、能走云采购的，优先 Bedrock 或 Vertex AI；只做验证的，聚合平台够用；第三方中转只在有合同、可审计、能随时替换的前提下作为过渡；个人账号和来源不明的低价额度一律不碰。三天时间不该用来找"最便宜的 key"，而是拿出一份可执行的路线对比、一个试点计划和一份成本与风险说明——这比任何口头保证都更能让老板签字。
