Lago：把 AI 用量计费从仪表盘里解放出来的开源引擎
开源计量和基于使用情况的计费 API 消费跟踪、订阅管理、定价迭代、支付编排和收入分析。
秒懂
- 它是什么？
- Lago 是一套以 API 为先的开源计量与计费系统，面向 AI 产品处理 token、算力、API 调用等用量计费。它把计量和定价从支付处理中分离出来，并提供 MCP 服务器让代理直接操作账单数据。
- 适合谁用？
- 如果你的产品是 AI 服务、开发者工具或平台型业务，需要按 token、算力或 API 调用计费，并且希望计费逻辑不被锁死在某个支付提供商的目录里，Lago 值得一试。它适合已经有工程能力、愿意维护一套自托管服务的团队。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是哪一类计费问题
很多产品的收费方式不是简单的按月订阅。AI 产品按 token 计费，按输入和输出分开计价，还要区分缓存、推理和工具调用。传统支付提供商的订阅目录根本表达不了这种粒度。Lago 把这件事拆成一条管道：用量事件、计量、定价和额度、权益、发票、支付、收入。它位于产品与支付之间，你不需要把 Stripe 或 Adyen 的产品目录当作计费的唯一真相。
事件如何变成账单
Lago 的核心是事件驱动的计量。应用发送用量事件，Lago 把它们转成可计费的指标，套用定价和额度规则，然后生成发票并触发支付。README 里给了一张数据流图：Usage events -> Metering -> Pricing and credits -> Entitlements -> Invoices -> Payments -> Revenue。这个顺序说明计量和定价是独立于支付处理的。你可以换支付提供商，而不需要重写计费逻辑。事件是原始输入，指标是业务定义，定价是另一层。这种分层让产品团队可以频繁调整价格，而不触碰账单生成代码。
本地演示：一条命令看到完整链路
仓库自带一个可维护的演示脚本，用来给 AI 工作负载定价。运行 ./examples/agentic-ai-demo/run.sh，它会启动与当前 checkout 匹配的 Lago 版本，创建一个一次性的本地组织，然后模拟三个 AI 请求。每个请求发送一个输入 token 事件和一个输出 token 事件。示例输出显示：5000 个输入 token 乘以 0.000002 美元等于 0.01 美元，1250 个输出 token 乘以 0.000008 美元等于 0.01 美元，总计 0.02 美元。脚本会检索当前用量，独立核对结果，并重试一次事务以确认用量不会增加。这演示了幂等性，即重复发送同一事件不会重复计费。演示完全在本地运行，不访问 Lago Cloud。登录地址是 localhost:8080，账号是 agentic-ai-demo@example.local，密码是 agentic-ai-demo-local-password。你可以打开 Customers -> Agentic AI Demo Customer -> Agentic AI Demo subscription -> Usage 查看详细数据。需要 Docker、curl 和 jq。如果端口 8080 或 3001 被占用，可以设置 LAGO_DEMO_UI_PORT 和 LAGO_DEMO_API_PORT。清理用 ./examples/agentic-ai-demo/run.sh --cleanup。
两种使用模式：Direct 与 Embedded
Lago 把同一个引擎包装成两种运营模型。Lago Direct 是你为自己的产品计费，你的应用和团队通过 API、代理界面和 Lago UI 使用它。Lago Embedded 则是你的客户通过你的平台对外计费，Lago 以白标界面藏在你的品牌后面。两种模型共用同一套计量和定价原语。区别在于谁面对最终用户。Direct 适合独立产品，Embedded 适合市场、平台、金融科技和开发者工具。README 给的公开例子分别是 Mistral AI 用 Direct，PayPal 用 Embedded。这个区分对平台型团队很关键，因为 Embedded 意味着你要把计费能力作为产品特性交付给客户，而不只是内部工具。
Agentic-first 的接口设计
Lago 强调 agentic-first，意思是计费模型以结构化、可检查的接口暴露，而不是锁在仪表盘里。它提供 REST API 和 OpenAPI 规范，可以生成类型化客户端或工具。另外有一个 MIT 许可的 MCP 服务器，让兼容 MCP 的代理能够读写发票、用量、客户、支付、信用票据、优惠券等原语。还有 Python 和 JavaScript/TypeScript 的 Agent SDK。JS SDK 声称包装 OpenAI、Anthropic、Mistral、Gemini 和 AWS Bedrock 客户端，p99 包装开销低于 5 毫秒。Python SDK 包装 LLM 客户端、规范化用量并发送 token 或模型成本事件，而不阻塞 LLM 调用。这些接口的存在意味着你可以把计费操作交给编码代理，而不需要人工打开 UI。对工程团队来说，这比依赖手动点击仪表盘更可审计，因为每个操作都是可编程的。
许可证与维护成本
Lago 采用 AGPL-3.0 许可证。这意味着如果你修改了代码并以网络服务形式提供给用户，你有义务公开修改后的源码。对于自托管内部使用，通常影响不大，但如果你的产品以 SaaS 形式分发修改版 Lago，需要认真评估合规义务。这不是法律建议，只是许可证本身的约束。维护方面，仓库最近更新频繁，v1.52.1 在 2026 年 8 月发布，说明项目活跃。但自托管意味着你要自己处理升级、数据库迁移和事件管道的运维。演示脚本依赖 Docker Compose，生产部署需要更全面的基础设施。如果你不想承担这些，Lago Cloud 是商业选项，但那是另一套成本。
局限性与替代方案
Lago 不是万能的。它要求你定义清晰的计量模型，即把事件映射到指标。如果产品用量本身很模糊，比如复杂的折扣层级或跨组织分摊，Lago 的定价模型可能不够灵活。另外，AGPL 许可证对某些商业分发场景是硬约束。支付处理依赖第三方提供商，Lago 只是编排，如果 Stripe 或 Adyen 不支持你所在地区的支付方式，问题依然存在。一个真实的替代方案是 Stripe Billing 本身。Stripe 提供订阅和按量计费，但它的计量能力较弱，通常需要你预先定义价格计划，并且它的产品目录会成为计费真相。Lago 的差异在于把计量和支付解耦，你可以用 Lago 处理事件和定价，再连接到 Stripe 只做收款。另一个方向是自建计量系统，用 ClickHouse 或 TimescaleDB 存事件，自己写定价引擎，但这需要大量工程投入。Lago 的价值在于它把这条管道封装成现成的 API，但你仍然要理解事件流和计费语义。
编辑结论
如果你的产品是 AI 服务、开发者工具或平台型业务，需要按 token、算力或 API 调用计费，并且希望计费逻辑不被锁死在某个支付提供商的目录里，Lago 值得一试。它适合已经有工程能力、愿意维护一套自托管服务的团队。不适合只想快速接入 Stripe 订阅、不想处理事件管道和计量模型的团队。采用前先验证三件事：确认 AGPL-3.0 许可证与你的分发方式兼容；用仓库里的 agentic-ai-demo 跑通本地事件、定价、出账的完整链路；检查 Lago 的订阅和预付额度模型是否覆盖你的计费场景，尤其是最低承诺和超额部分。
社区笔记