stripe/ai：把 Stripe 计费接进 LLM 调用的两条路径

这个仓库真正交付的东西只有两件

README 的措辞是 one-stop shop，但拆开看，SDK 部分只有两个包。@stripe/ai-sdk 面向 Vercel 的 ai 与 @ai-sdk 库，@stripe/token-meter 面向 OpenAI、Anthropic、Google Gemini 的原生 SDK。两者的共同目标写在各自的一句话说明里：把 Stripe 的计费基础设施接进 LLM 调用。除此之外，仓库还承载了一个远程 MCP 服务的入口说明和一批 agent skill，后者是给编码 agent 用的指令集，不是运行时依赖。

这个划分决定了它的读者。它不是给你一个统一的 LLM 调用层，也不是做模型路由或提示词管理。它假设你已经有一个能跑通的 LLM 调用，只是缺少把 token 消耗映射到 Stripe 计费对象的环节。如果你的产品按订阅收费、与 token 用量无关，这个仓库里没有你需要的东西。

两条集成路径的分界线是框架依赖

两个 SDK 的差别不是功能多少，而是依赖方向。@stripe/ai-sdk 建立在 Vercel 的 ai 包和 @ai-sdk 生态之上，用它的前提是你的调用链已经在这个抽象层里。@stripe/token-meter 的说明明确写了 without any framework dependencies，直接对接三家厂商的原生 SDK。

这条分界线很实际。已经用 ai 包写完全部调用逻辑的项目，换成 token-meter 意味着要么重写调用层，要么在原生 SDK 和 ai 包之间维护两套代码。反过来，一个只用 openai 包、调用点不多的服务，为了计费引入整个 @ai-sdk 体系，代价和收益不成比例。README 没有给出两个包在计费粒度、上报时机上的差异说明，所以选型时不能靠推测，得分别去看 llm/ai-sdk 和 llm/token-meter 两个子目录里的文档。

MCP 走的是远程托管加 OAuth

仓库没有让你自己部署一个 MCP server。README 写的是 Stripe hosts a remote MCP server at https://mcp.stripe.com，客户端通过 OAuth 接入，文档入口在 docs.stripe.com/mcp#connect。同一份文档还指向 docs.stripe.com/mcp#agents，说明它同样可以用于构建自主 agent。

托管模式省掉了自建服务的运维，代价是控制权在对方手里：端点固定、鉴权流程由 Stripe 定义、可用性取决于这个远程服务的状态。对需要在内网隔离环境里跑 agent 的团队，这个设计直接排除了一种部署形态。README 没有说明这个远程服务是否有自托管替代方案，也没有给出限流或配额信息，这些需要去 docs.stripe.com/mcp 确认。

agent skill 的安装方式按客户端分裂

README 列了四个 harness 的安装命令，每个都不一样。Claude Code 用 claude plugin install stripe@claude-plugins-official，Codex 用 codex plugin add stripe@openai-curated，Cursor 用 /add-plugin stripe，Grok Build 用 grok plugin install stripe --trust。注意包名不同：Claude 侧是 claude-plugins-official，Codex 侧是 openai-curated，说明这些插件由各自的插件市场分别维护，不是同一个制品的四种装法。

对于新的 Agent Plugins 标准，README 承认 Installation methods currently vary by client，只能把客户端指向仓库本身：Git URL 是 https://github.com/stripe/ai，子目录是 providers/agent-plugins/plugin/。这是一个尚未收敛的接入面。

手动安装路径是 npx skills add https://docs.stripe.com。README 在引用块里给了一句明确警告：Manually installed skills don't auto-update，需要跑 npx skills update -y 才能拿到最新版本。这是这个仓库里少数几个有具体后果的操作细节，值得单独记下来。

没有发布记录意味着升级要靠自己盯

仓库信息显示 recent releases 为空，也就是说从给定的材料里看不到任何版本发布记录。这对一个要接进生产计费链路的 SDK 来说是个需要正视的信号：没有 release note，就没有官方的变更说明可供比对，升级时你只能靠 diff 或子目录文档判断影响面。

这不是说项目不活跃，仓库的 last push 时间是 2026-09-10，未归档，默认分支 main。但活跃度和发布纪律是两件事。如果你的团队有依赖升级流程，需要人工为这两个包补上版本观察动作，而不是指望 release feed。这一点在选型评审时应该被明确提出来。

它不该被用在什么地方

最典型的误用是把它当成用量统计工具。两个 SDK 的目标都是把消耗接到 Stripe 的计费基础设施上，不是给你一个本地 token 计数器。如果你只是想知道每次调用花了多少 token、想在日志里看一眼，引入 Stripe 的计费链路属于绕远路。

第二种误用出现在计费模型不匹配的场景。README 通篇讲的是 LLM 与 agent 的计费集成，没有提到按席位、按调用次数或一次性收费的模式该怎么处理。如果你的商业模式不是按 token 用量计费，这个仓库提供的抽象很可能对不上你的账目结构。

第三种是环境限制。MCP 部分只有远程托管这一种形态，内网隔离部署的团队在这里会直接卡住，且 README 未提供替代方案。

和自己写一层计量中间件的区别

一个自然的替代方案是在自己的调用层里加钩子：在每次请求返回后读取 usage 字段，累加到自己维护的计量表里，再定期同步到 Stripe。这个做法的好处是零新增依赖、完全可控、能按自己的口径定义什么叫一次计费单位。代价是你要自己处理重试导致的重复计数、流式响应下 usage 何时到达、以及多厂商 usage 字段结构不一致的问题。

stripe/ai 的两个 SDK 本质上是把这层中间件产品化了，代价是你接受它的抽象和它的依赖。分界线可以这样划：如果你的计量口径就是标准的 token 用量，用现成的 SDK 更省事；如果你的计费单位经过了业务加工（比如按对话轮次、按生成的文档数折算），自己写中间件反而更直接，因为 SDK 的抽象未必留出了这个加工层。README 没有说明两个包是否支持自定义计量单位，这一点需要看子目录文档。

MIT 许可与维护成本的实际情况

仓库采用 MIT 许可。这意味着你可以修改、分发、商用，义务主要落在保留版权与许可声明上。这里不做法律判断，涉及具体合规场景请让法务看 LICENSE 原文。需要提醒的是，MIT 覆盖的是这个仓库里的代码，通过 OAuth 接入的 mcp.stripe.com 是一个托管的远程服务，它的使用条款由 Stripe 的服务协议约束，和代码许可不是一回事。这个区别在内部评审时经常被混为一谈。

维护成本主要来自三处：手动安装的 skill 需要主动跑 npx skills update -y，否则会停留在旧版本；没有 release 记录，升级前要自己判断影响；MCP 端点的可用性由 Stripe 侧决定，你只能监控不能修复。这三项都不大，但都需要有人明确负责，否则会在某次故障或某次行为变更时才发现没人跟。

编辑结论

如果你的 LLM 调用已经跑在 Vercel 的 ai 与 @ai-sdk 之上，@stripe/ai-sdk 是嵌入成本最低的选项；如果用的是 OpenAI、Anthropic 或 Gemini 的原生 SDK，并且不想为一个计费功能引入框架依赖，@stripe/token-meter 才是对的那一个。反过来，如果只是想在本地脚本里统计 token 数、并不打算把这些消耗变成 Stripe 的账单条目，这个仓库里的两个 SDK 都不解决问题。动手前先确认两件事：你的调用栈落在哪一侧，以及你是否接受手动安装的 skill 不会自动更新（官方给出的做法是跑 npx skills update -y）。至于计费口径本身，去 docs.stripe.com/agents 核对，别从 README 推断。

官方来源

1. Issues
2. License: MIT
3. Project website
4. README
5. stripe/ai on GitHub