Helicone — AI 网关与 LLM 可观测性平台:架构与原理
30 秒导读: Helicone 让你把 LLM 请求的
baseURL换成它的域名(一行代码),它就站在你和 OpenAI/Anthropic/... 之间当"透明中转站":照常把请求转发给模型、把回答原样还给你,同时在旁路异步地把这次调用截下来——算钱、脱敏、拆结构,最后落到三个库里,变成你能查询、能按会话追踪、能打分评估的可观测数据。它既是可观测平台(看每一次调用花了多少、多慢、说了什么),也是AI 网关(一个 API key 通 100+ 模型,带路由和自动故障切换)。
1. 这是什么(零基础也能懂)
一句话定义: Helicone 是一个开源的 LLM 可观测性平台 + AI 网关——把它插在"你的应用"和"模型厂商"之间,零改动地记录并分析每一次 LLM 调用。
解决什么问题 / 给谁用。 假设你在做一个 AI 产品,调了 OpenAI、Anthropic、Gemini 十几个模型,散在几十个代码文件里。你想知道:这个月花了多少钱?哪个 prompt 最慢?某个用户昨天那条对话到底问了什么、模型怎么答的?一个 agent 跑了 20 步,是在哪一步跑偏的?自己搭一套日志+成本核算+存储+看板,是个大工程。Helicone 把这件事变成改一行 baseURL。
它能做什么(功能):
| 能力 | 白话 |
|---|---|
| 可观测(Observe) | 记录每次调用的请求正文、回答、延迟、token、成本 |
| AI 网关(Gateway) | 一个 key 通 100+ 模型,统一 OpenAI 格式,带路由与自动故障切换 |
| 会话追踪(Sessions) | 把一个 agent / 多轮对话的多次调用串成一条 trace |
| 打分与评估(Scores / Eval) | 给每条请求打分(人工或在线自动 eval),沉淀质量指标 |
| 成本核算 | 内置 300+ 模型的价目表,按 token 反算美元成本 |
| Prompt 管理、缓存、限流、告警 | 生产数据驱动的 prompt 版本;命中缓存省钱;按 key 限速 |
用起来什么样。 只改 baseURL 和 key,其余照旧:
// 示意,来自 README 的最小用法
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://ai-gateway.helicone.ai", // 原本是 api.openai.com
apiKey: process.env.HELICONE_API_KEY,
});
const res = await client.chat.completions.create({
model: "gpt-4o-mini",
messages: [{ role: "user", content: "Hello!" }],
});
// 请求照常返回;这次调用已被记录,去 dashboard 就能看到
一句话直觉/类比: 把 Helicone 当成 LLM 流量的**"带记账功能的收费站"——车(请求)必须过站,过站时它抄下车牌、算过路费、拍张照存档,然后立刻放行**(记账在旁边异步做,不拦车)。这个"必经+旁路异步"就是整套系统的灵魂。
本节不谈实现。记住一件事:Helicone 的价值来自"你的请求本来就要经过它"这个位置——有了这个位置,才谈得上零改动地观测。
2. 顶层全景(它大概怎么转)
2.1 六个服务,各司其职
Helicone 由六个服务拼成。README 的原话是"五个服务"(README.md:88),但下面那张清单其实列了六项(Worker、Jawn、Web、ClickHouse、S3/MinIO、Postgres),docker/docker-compose.yml 与 supervisord.conf 里也能逐个对上。用一张表看清谁干什么:
| 服务 | 干什么 | 在哪 |
|---|---|---|
| Worker(边缘代理 / AI 网关) | 站在必经之路上,转发请求、旁路截获、投递队列 | worker/(Cloudflare Workers) |
| Jawn(消费/API 后端) | 从队列取消息,经责任链加工,落三处库;并对外提供查询 API | valhalla/jawn/(Express + Tsoa) |
| Web(前端) | 看板:查请求、看会话、成本分析 | web/(Next.js) |
| ClickHouse | 分析库:海量请求行,支撑聚合/筛选/看板 | clickhouse/ |
| S3 / MinIO | 大对象库:超限的请求-响应正文 | 由 S3Client 访问 |
| Postgres(Supabase) | 元数据与 Auth:组织、API key、配置 | supabase/ |
注:CLAUDE 里还提到一个 Rust 版
aigateway;本 clone 内没有该目录,worker 内自带 TypeScript 版 AI 网关(worker/src/lib/ai-gateway/SimpleAIGateway.ts:55)。本套文档只讲 clone 里真实存在的代码。
2.2 一条请求的一生(主线,不进代码)
怎么读这张图: 从左到右是"同步主链路"(用户在等的那条,必须快);从 Worker 往下垂的那条虚线是 ctx.waitUntil 异步旁路——用户拿到回答后才在后台慢慢跑。
┌──────────────────── 同步主链路(用户在等,要快)────────────────────┐
│ │
你的应用 ─────► ① Worker 边缘代理 ─────────────► LLM 厂商 ──────► ① Worker ──► 你的应用
(改了baseURL) · 判 WORKER_TYPE (OpenAI/…) · 组装回答 (拿到回答)
· 缓存/限流/安全检查 · ctx.waitUntil
╎ (异步旁路,不阻塞)
▼
② 算成本 + 投队列
(Kafka / SQS / HTTP)
▼
③ jawn 消费者:一条责任链
认证→读S3→拆请求/回答→
打prompt→在线eval→落库…
▼
┌─────────────────┬─────────────────┐
▼ ▼ ▼
④ ClickHouse ④ S3 ④ Postgres
(分析·可查询) (大正文) (元数据)
主线一句话:必经拦截(①)→ 旁路算钱+投队列(②)→ 消费者责任链加工(③)→ 三处落库(④)。 这四步对应 01–04 章;第 05 章再讲在这行日志之上生长的 agent 可观测性(会话 / 打分 / 评估)。
2.3 两条接入路径:代理式 vs 异步日志
上图画的是代理式接入。其实数据交给 Helicone 有两条路,搞混是新手最大的坑,先分清:
| 维度 | 代理式(Proxy / Gateway) | 异步日志(Async Logging) |
|---|---|---|
| 谁在链路上 | 在关键路径,Worker 同步转发你的请求 | 不在链路,你自己调模型,事后单独上报 |
| 你改什么 | 改 baseURL 指向 Worker | 保留原调用,额外发一份日志给 jawn |
| 典型手段 | AI Gateway、各家 proxy 入口(01 章) | OpenLLMetry(OTEL)、自定义上报(05 章 TraceManager) |
| 好处 | 一处接入即得网关能力(路由 / fallback) | 请求不经过 Helicone,少一跳、少一个故障点 |
| 代价 | 请求多走一跳边缘代理 | 需要在自己代码里埋点上报 |
一句话选型: 想要"换模型 / 自动兜底"这类网关能力 → 走代理式;只想记录分析、不愿把生产流量引到第三方链路 → 走异步日志。两条路最终都汇进同一套 jawn 责任链和同三个库——所以下面各章讲的加工与落库,对两条路一视同仁。