现状
宣布了什么
2026 年 3 月,Mintlify 宣布收购 Helicone,并表示 Helicone 将继续处于维护模式,同时称将“与每位客户密切合作,支持其顺利迁移到其他平台”。2026 年 10 月,Helicone 的首页改为“Helicone 不再属于 Mintlify。详情将很快公布。”其云端注册页面仍显示“注册已关闭”。
没有宣布什么
没有关停日期,没有数据保留承诺,对于 10 月的变化也至今没有任何说明:现在由谁运营 Helicone,这对其路线图意味着什么。请按字面理解:这里没有任何事需要本周处理。这是一个让你审慎决定而不必匆忙的理由,并建议在决定之前重新阅读 Helicone 自己的页面。
这个页面为什么存在
因为诚实的答案取决于你用 Helicone 做什么,而你在这次搜索中找到的大多数页面都不会告诉你这一点。如果你是为了追踪、评估和提示词管理而用它,下一节会给出比我们更合适的去向。
这一节是有意放在差异之前的。读到这里的人中,有很大一部分是把 Helicone 当作可观测性和评估平台来使用的,而针对这项工作,有一款完全围绕它打造的产品。
Langfuse 自称是面向智能体评估和可观测性的开源 AI 工程平台:贯穿 LLM 调用、工具调用和检索步骤的分层追踪,LLM-as-a-judge 和启发式评估器,带部署和回滚的提示词管理,数据集和实验,人工标注,以及 Playground。它采用 MIT 许可,可通过 Docker Compose、Kubernetes 和 Terraform 自托管,并于 2026 年 1 月被 ClickHouse 收购——据 ClickHouse 自己的说法,这使它依然开源、可自托管,云服务也照常运行。
值得看 INFRO 的理由,是另一个换了外衣的问题。如果你实际面对的是:多个团队有多个提供商账号,发票到手之前没人能归因的支出,每个代码库各写一套的重试和回退,以及对服务可以调用哪个模型没有审批环节——那是控制平面的问题,而不是可观测性的问题,而这正是本产品所围绕的问题。很多团队两者都需要,让 INFRO 作为网关,同时把追踪导出到你选择的收集器,是一种合理的形态。
以下情况请选择 Langfuse
- 你主要是为了可观测性才用 Helicone。Langfuse 就是这样的产品,经过精心且深入的构建,也是最接近同类对等的去向。
- 你需要提示词管理或评估器。INFRO 两者都没有,也没有任何一项的日期。Langfuse 两者都有,评估是它主打的两件事之一。
- 你追踪的是智能体,而不仅仅是模型调用。Langfuse 为横跨工具调用和检索步骤的追踪树建模。INFRO 一次记录一个请求;span 树需要你在自己的收集器中拼装。
- 你想自托管,且不想与销售沟通,或想保留这个选项。Langfuse 采用 MIT 许可,任何人都可以运行。INFRO 的套餐是托管的;只有在企业协议下才会运行在你自己的基础设施中。
Langfuse 不是 INFRO 的合作伙伴、转售商或关联方。我们给出它的链接,是因为它是一个本页如果不提就只能不诚实回答的问题的诚实答案。
我们的对象与 Helicone 的对象对照,依据其公开文档(于 2026年10月24日 复核)并对照网关的实际实现核对。4 行表示我们没有对应功能;这些最值得先看。
| Helicone | 它在那里的作用 | 在 INFRO 中 |
|---|---|---|
| 网关集成形式相同 | 将兼容 OpenAI 的客户端指向 Helicone 的 AI 网关基础 URL,并传入你的 Helicone 密钥。 | 形态相同:基础 URL 为 https://api.infro.io/v1,密钥放在 Authorization: Bearer 中。两行,每个服务一行。 |
| 异步日志,不在请求路径上无对应 | 基于 OpenLLMetry 的日志记录器包装了你的提供商 SDK,因此 Helicone 不在你应用的关键路径上。 | 没有对应项。INFRO 是网关,所以它始终在路径上——这使它能够路由、故障转移,并依据预算拒绝请求,这也是你要做出的真实取舍。 |
| 由谁的提供商账号处理请求不同 | 网关可以提供模型访问,Helicone 也支持自带提供商密钥。 | 只有你自己的。你连接已持有的提供商账号,你的提供商按你自己的费率直接向你开具发票,INFRO 对模型支出收取 0%。 |
| 自定义属性不同 | 以 Helicone-Property-<Name> 请求头发送的任意标签,用于过滤和成本分析。 | 请求正文中的 metadata 对象,可在请求日志中按 tag.<key> 过滤。思路相同,位置不同——请求头变成正文字段,这是整个迁移中最大的单项修改。 |
| 终端用户追踪不同 | Helicone-User-Id 标识终端用户,并在其基础上提供按用户的参与度、留存和满意度分析。 | metadata.user_id 会记录在每个请求上,并可用于过滤请求日志和用量分组,因此可以回答每个终端用户的成本。没有按用户的行为分析界面——没有会话时长、回访率或满意度评分。 |
| 会话和追踪树不同 | Helicone-Session-Id、-Path 和 -Name 把相关的调用归入同一个视图,包括向量查询和工具调用等非 LLM 步骤,并根据路径得到父子结构。 | metadata.session_id 在日志中为请求分组,span 也可以从请求路径推送到你自己的 OpenTelemetry 收集器。INFRO 没有的是带追踪树的会话视图:它记录的是模型调用,而不是调用之间的步骤。 |
| 响应缓存不同 | Helicone-Cache-Enabled 在边缘缓存完整的响应,带有桶大小和缓存种子。 | 针对聊天补全的精确匹配响应缓存,默认关闭,按组织或项目开启。在存活时间内的相同请求会直接由缓存作答,不会到达你的提供商,因此你的提供商不会为它计费。控制方式为 cache 正文字段或 X-INFRO-Cache 请求头;缓存种子变为 X-INFRO-Cache-Namespace。没有多个已存储答案的桶,也没有语义(相似提示词)匹配。文档页面为 /docs/features/caching。 |
| 自定义速率限制不同 | Helicone-RateLimit-Policy 按窗口设置配额,以请求数或成本计,可按全局、按用户或按自定义属性分段。 | 按密钥划分的请求速率档位,以 X-RateLimit-Limit 报告,外加组织、项目、成员和密钥层级的预算,到达上限时以 402 budget_exceeded 拒绝流量。成本上限可以很好地对应;按终端用户或任意属性划分的限制则不行。 |
| 提示词管理无对应 | 在代码库之外管理的提示词,其版本可对照生产流量比较。 | 没有,我们也没有可以明说的计划。提示词留在你的代码仓库里,或留在能把这件事做好的工具里——Langfuse 就可以。 |
| 评估器和实验无对应 | LLM-as-a-judge 和自定义评估器对输出质量打分,并支持提示词并排比较。Helicone 的文档在 Experiments 功能上带有弃用通知。 | 没有。INFRO 不对模型输出打分,也不对回答好不好发表意见。 |
| Webhooks不同 | 请求完成时触发带签名的 webhook,携带请求和响应正文、成本、token 和延迟。 | 带签名的 webhook,但仅用于异步媒体任务——job.succeeded、job.failed、job.canceled。没有按请求的完成钩子;请求日志和 GET /v1/requests 是你读取已完成流量的方式。 |
| 每请求成本不同 | 按请求计算成本,并按属性、用户和模型汇总。 | 对提供商将向你收取费用的估算,以 usage.cost 出现在响应中,usage.price_source 说明它来自你的协商价、你对该模型的费率,还是厂商的公开价——在没有已知费率时则不给出,而不是猜测。 |
| 回退和多提供商路由形式相同 | 通过网关实现的提供商回退。 | 命名路由,带有基于你自己连接的优先级或加权目标。在响应开始之前超时或返回 5xx 的目标会在别处重试;一旦字节开始流动,错误会直接暴露,而不会被重新路由。 |
| 模型策略不同 | 在我们阅读的页面中,这不是 Helicone 有文档记载的概念;最接近的控制是速率限制。 | 组织、项目或密钥层级的允许列表。最窄的范围优先,范围之外的一切都会在产生任何费用之前被拒绝。 |
| 历史数据无对应 | 已在 Helicone 中的请求、属性、会话和分数。 | 没有导入工具,也没有计划提供。你在那里记录的任何内容都不会出现在这里。在停止发送之前,请先从 Helicone 导出并保存在你可控的地方。 |
| 开源和自托管不同 | Helicone 的平台是开源的,可以自己运行。 | 网关不是开源的。它的套餐是托管的;自托管或混合部署仅随企业协议提供。如果你需要在没有协议的情况下自己运行,请到此为止。Enterprise — 通过企业协议提供,而非自助开通。 |
这是我们对 Helicone 已发布文档的理解,而非试用或基准测试。在过渡期间他们的文档有所变动,一些功能页面已不在原来的地址;凡是我们无法确认的地方,该行都会如实说明,而不是猜测。所有来源及我们打开它们的日期都列在本页底部。
连接只需改两行。工作量在注解上:Helicone 把它们放在请求头中,INFRO 把它们放在请求体中,所以凡是你设置了请求头的地方都需要修改。
之前 · Helicone 网关
import OpenAI from "openai";
// Before: the OpenAI SDK through Helicone's gateway, attribution in headers.
const sessionId = "sess_42";
const client = new OpenAI({
baseURL: process.env.HELICONE_BASE_URL ?? "https://ai-gateway.helicone.ai",
apiKey: process.env.HELICONE_API_KEY,
defaultHeaders: {
"Helicone-User-Id": "user_8f21",
"Helicone-Session-Id": sessionId,
"Helicone-Property-Feature": "summarizer",
},
});
const completion = await client.chat.completions.create({
model: "gpt-5.4-mini",
messages: [{ role: "user", content: "Summarize this ticket in one line." }],
});
console.log(completion.choices[0]?.message.content);之后 · INFRO
import OpenAI from "openai";
// After: the same SDK through INFRO, on your own OpenAI account.
const sessionId = "sess_42";
const client = new OpenAI({
baseURL: process.env.INFRO_BASE_URL ?? "https://api.infro.io/v1",
apiKey: process.env.INFRO_API_KEY,
});
const completion = await client.chat.completions.create({
model: "openai/gpt-5.4-mini",
messages: [{ role: "user", content: "Summarize this ticket in one line." }],
// Attribution moves from headers into the body. Recorded on the request,
// never forwarded to the provider.
metadata: {
user_id: "user_8f21",
session_id: sessionId,
feature: "summarizer",
},
});
console.log(completion.choices[0]?.message.content);基础 URL 和密钥
https://api.infro.io/v1,密钥放在标准的 Authorization: Bearer 请求头中——也就是你的客户端已有的 baseURL 和 apiKey 参数。如果你的代码仍指向 Helicone 较早的按提供商划分的代理主机,并带有单独的 Helicone-Auth 请求头,请把这个请求头完全去掉;INFRO 不使用它。
模型 ID
模型以 vendor/model 的形式指定,例如 anthropic/claude-opus-5。GET /v1/models 会列出你的密钥实际可以调用的模型,也就是你自己连接的提供商账号所提供的模型——没有任何连接覆盖的模型会返回 503 no_provider_connected,并指明需要连接的提供商。
注解
Helicone-User-Id 变为 metadata.user_id,Helicone-Session-Id 变为 metadata.session_id,每个 Helicone-Property-X 都变为 metadata.tags 下的一个键,在请求日志中以 tag.x 进行筛选。在 TypeScript 中,OpenAI 自带的 metadata 类型是扁平的字符串映射,因此嵌套的 tags 对象需要类型转换;Python 的 extra_body 则可以原样接受。
在做出决定前值得一试的一件事:Helicone 的异步集成是包装你的提供商客户端,而不是位于网络路径上,所以原则上当基础 URL 指向这里时它仍能继续记录日志。我们没有测试过这种组合,无法作出保证——请先在一个服务上运行,并在这一侧查看 GET /v1/requests,确认两边对发生的事情记录一致。
四件事,全都源于它是一个运行在你自己提供商账号上的网关,而不是一个在旁观察它们的日志工具。
- 处理请求的账号是你的,并且会注明
- 每个响应都带有
provider——运行该请求的账号所属的提供商类型——和connection(它使用的连接的 id),当由路由解析时还带有route和route_name。网关背后没有资源池,流量上也没有加价:你的提供商按你自己的费率向你开具发票,INFRO 为这一层收取订阅费。 - 成本是一个会说明来源的估算
usage.cost是对你的提供商针对该请求的账单的估算,usage.price_source说明它是如何得出的——custom_provider表示处理该请求的提供商上的协商价,custom表示你对该模型的费率,list表示厂商公布的费率。没有已知费率时,请求会被记录为未定价而不是零,因为成本列中的零是一种声明,而空缺是一个事实。- 预算可以拒绝请求
- 组织、项目、成员和密钥层级的上限,带你设定的告警阈值。到达上限时,网关返回
402 budget_exceeded,而不是事后用邮件通知你超支——这就是预算与报告的区别。 - 估算会与提供商自己的账单核对
- 每日一次的处理会使用单独的管理员凭据读取 OpenAI 和 Anthropic 的成本 API,把报告的数字与 INFRO 的估算并排存储,因此你看到的是差异,而不是需要盲目相信的数字。只有这两家提供商有适配器;没有适配器的提供商不显示差异,而不是显示差异为零;Bedrock、Vertex 和 Azure 的成本保留在其所属云的计费系统中。
哪些无法迁移过来
没有导入工具。你在 Helicone 中记录的任何内容都不会出现在 INFRO 中,这边也不会回头去获取它。趁他们的服务还在运行,导出你需要的数据。
- 你的请求历史。没有导入工具,也没有计划提供。请先从 Helicone 导出你需要的内容;INFRO 里没有任何东西会回头去取。
- 已记录的自定义属性、会话和用户 id。标注从你向这里发送的第一个请求开始。
- 已缓存的响应。其他产品缓存中的条目不会迁移;INFRO 的缓存从空白开始,由你自己的流量填充,只匹配完全相同的请求,绝不匹配相似的请求。
- 提示词和评估器分数。它们没有可以落脚的地方。
- 你自己运行的 Helicone 部署。INFRO 的套餐是托管的;在你自己的基础设施中运行 INFRO 属于企业协议,而不是迁移步骤。
来源
本页关于 Helicone 或 Langfuse 的每一项陈述都来自以下来源之一,并注明了我们的阅读日期。没有任何内容是从试用、基准测试或交谈中推断的。
- Helicone — homepage (“Helicone is no longer part of Mintlify”)阅读于 2026年10月24日
- Helicone — sign-up page (“Sign ups are disabled”)阅读于 2026年10月24日
- Helicone — “Helicone is joining Mintlify”阅读于 2026年9月20日
- Mintlify — “Mintlify acquires Helicone”阅读于 2026年10月24日
- Helicone docs — Quickstart阅读于 2026年10月24日
- Helicone docs — Async logging (OpenLLMetry)阅读于 2026年9月20日
- Helicone docs — Custom properties阅读于 2026年10月24日
- Helicone docs — Sessions阅读于 2026年10月24日
- Helicone docs — User metrics阅读于 2026年10月24日
- Helicone docs — Caching阅读于 2026年10月24日
- Helicone docs — Custom rate limits阅读于 2026年10月24日
- Helicone docs — Webhooks阅读于 2026年9月20日
- Helicone docs — Experiments (deprecation notice)阅读于 2026年9月20日
- Langfuse — product overview阅读于 2026年9月20日
- ClickHouse — “ClickHouse welcomes Langfuse”阅读于 2026年9月20日