Mercor如何用一个平台撑起数千内部应用与630亿Token

AI数据公司Mercor连接着数十万领域专家与前沿AI实验室，为模型训练和评估提供高质量的人工数据。当业务需求脉冲式涌来、单个评估任务却只有24小时交付窗口时，模型容量和访问管理就成了决定客户体验的关键瓶颈。Mercor的解法是把模型调用和身份认证都收拢到同一套平台上，让安全团队从审批者变成赋能者。

从12小时到2小时：容量瓶颈怎么破

Mercor此前混合使用直连集成和第三方网关，在需求高峰时无法为开源模型工作负载提供足够的每分钟Token容量。请求撞上供应商限流后进入重试队列，原本时间敏感的批处理任务被拉长到12小时以上，吃掉客户24小时截止时间的一大半。

Vercel AI Gateway带来的改变有两点：更多推理容量，以及请求触达限流时的多供应商故障转移路由。批处理任务不再卡在重试队列里，而是可以在供应商之间切换继续执行。据Mercor披露，这类任务现在2到3小时即可完成。上线头10天，团队通过Gateway路由了1800万次请求和630亿Token，期间没有触达限流。

Mercor并没有把所有鸡蛋放进一个篮子——它仍然使用多个网关和供应商，看重的是Vercel将模型访问、控制能力和实操支持打包在一起。对工程师而言，一个API就能对接主流基础模型供应商和不断扩充的开源模型目录，试新模型不必再写一套供应商适配代码。

AI Gateway 是介于应用与模型供应商之间的中间层，统一封装各家 API 的差异，并提供路由、限流、重试、可观测性等能力。其核心价值在于把"选哪家供应商"从代码中抽离为运行时决策：当某供应商返回 429（限流）或 5xx 时，网关可自动切换到备用供应商继续执行，而非让请求阻塞在重试队列中。对于 24 小时交付窗口的评估任务，这种多供应商故障转移直接决定了任务能否按时完成。此外，网关通常提供统一计费和用量记录，使按团队、按项目的 Token 归因成为可能。

Token花在哪：给实验装上预算和期限

模型用得越多，账单越难解释。Mercor过去的配置几乎看不到按团队和项目拆分的用量，脚本里一个循环错误就可能烧光预算。

现在数百名工程师通过AI Gateway使用开源模型，每人持有带过期时间、Token限额和消费上限的独立密钥。安全团队可以给实验批一笔预算和一个截止日期，再用用量记录回溯哪个用户、哪个项目、哪类工作负载在消耗资源。工程师在同一网关下换模型试效果，不用每次重新管理一套供应商凭证。这种模式把"先管住再放开"落到了具体机制上：限制不是阻碍实验，而是让实验可持续。

Token 限额与消费上限 是两种不同粒度的配额控制。Token 限额通常指单次或累计可消耗的 Token 总量，适合按任务或实验批次设定；消费上限则是以货币计价的硬性阈值，触及即拒绝请求。两者结合过期时间，就构成"临时凭证"模型：安全团队为一次实验签发有效期为数天、额度有限的密钥，实验结束凭证自然失效，无需人工回收。相比长期共享的供应商 API Key，这种模式把授权范围、时效和成本三者绑定在同一凭证上，既能防止脚本循环错误烧光预算，也能在事后按密钥维度精确追溯消耗来源。

业务团队自己建应用：项目数从十几个到约2000个

Mercor业务团队中有几百人在Vercel上构建应用，公司项目数量从不到十几个增长到约2000个。其中许多是为特定客户合作搭建的临时环境。

一个典型的生产场景是让专家查看自己的任务和进度。过去这需要工程团队把每个合作方的界面加进核心平台，现在业务团队自己构建界面并分享给执行任务的专家。

分享的前提是控制谁能登录，而又不能为每个项目单独搭一套认证。Vercel Passport提供统一的认证层，通过既有身份提供商处理对Vercel部署的登录。Mercor身份团队在此基础上做了名为Audiences的产品，把Passport作为一等原语集成，实现访问开通自动化：选定需要访问的专家后，Audiences自动创建IdP组、Vercel连接和Passport配置。据Mercor介绍，无论受众规模是几十名专家还是数万名，开通都在秒级完成。下线流程反向执行同样自动化——由于访问权限派生自IdP组，合作结束时删除该组，项目访问权限随之消失，不会留下陈旧权限。

IdP 组（身份提供商组）是身份治理中的基础原语：用户在 IdP（如 Okta、Azure AD）中被划分到某个组，下游应用依据组成员关系授予或撤销访问。将访问权限"派生自 IdP 组"而非在应用侧单独维护白名单，好处是权限生命周期与组织身份生命周期保持一致——人员加入、调岗或离开时，只需在 IdP 中调整组，所有下游系统的权限同步变化。这也解释了为何删除 IdP 组能让项目访问权限随之消失：应用侧不持有独立的授权记录，因此不会产生"人已离开但权限仍在"的陈旧残留。

给每个Agent划清能力边界

除了应用，Mercor还用Agent回答市场专家的提问、自动化HR流程、帮员工在内部系统中导航。其做法是给每个Agent配置与其职责匹配的窄权限，而不是继承调用者本人的全部权限。

对于通过AI Gateway使用开源模型的Agent，Mercor还能限定模型范围、设置过期时间、限制消费。模型使用与系统操作权限分开治理，两条线各自收口。

窄权限（least privilege） 指主体只被授予完成其职责所必需的最小权限集合，而非继承调用者的全部权限。对 Agent 而言这尤为关键：Agent 通常以服务身份运行，若直接继承触发者的用户权限，一旦被提示注入或行为偏差利用，影响面等于该用户的全部能力。Mercor 的做法是为每个 Agent 单独定义职责对应的权限边界，并把"能调用哪些模型"与"能操作哪些内部系统"拆成两条独立的治理线——前者通过 AI Gateway 限定模型范围和消费，后者通过系统权限控制操作范围，任一维度收紧都不影响另一维度的正常使用。

安全路径要成为最快路径

Mercor的后续方向是让更多开源模型驱动内部Agent和系统，让更多非工程团队为专家构建工具。随着规模扩大，公司希望团队把时间少花在配置模型集成和应用认证上，以便对截止时间紧张的客户需求快速响应。

Aaron Brown作为Mercor的安全负责人，其思路贯穿始终：让更多人能构建，意味着更简单地给他们所需访问权限，并持续跟踪使用方式。目标是把安全路径做成最快路径——共享的模型访问和可重复的认证流程让专家及时拿到工具、实验室按时拿回结果，而安全工作量的增长不必与业务增长同速。

从Mercor的实践看，AI应用规模化的真正门槛往往不在模型本身，而在容量弹性、成本可见性和身份治理这三件"配套工程"上。把这三件事平台化之后，业务团队才敢放手构建，安全团队也不必为每个新项目重复审批。