BUZZ AI Gateway
文档 · 核心概念 · 零数据留存

零数据留存

"零留存" 是一个针对具体对象的精确承诺,这个对象就是请求体和响应体。BUZZ 不存储你发送的 prompt,也不存储 Claude 返回的补全。出于计费、故障排查、滥用应对的需要,我们会持久化少量元数据,但消息内容本身不会落盘。

为什么 "零" 必须有定义

"我们不记录请求" 是一个常见说法,但模糊到几乎没有意义。一个有用的零留存声明必须回答四个问题:丢什么、留什么、边界画在哪、留下的东西活多久。

BUZZ 把边界画在消息体上。POST /v1/messages 请求体里的任何内容,以及响应体里的任何内容,都被视为客户数据,在我们的基础设施里不会落到任何磁盘上。计数、标识符、状态码、路由决策会被持久化,因为我们必须给你计费,必须能够调查故障。

数据流向图

你的应用 | | TLS(你的 prompt) v BUZZ 边缘 -- 读 auth header,选择上游通道 | -- 建立上游连接 | -- 字节直通(请求体不落盘) v ANTHROPIC / 上游 | | TLS(模型输出) v BUZZ 边缘 -- 字节回灌(响应体不落盘) | -- 从最后一个 SSE 事件读出 usage | -- 写入计费记录 { user_id, model, tokens, status, ms } v 你的应用 落盘: 仅计费记录(无 prompt、无补全) 不落盘: 请求体、响应体、tool 输入、tool 结果

字节通过流式管道穿过 BUZZ。出口前唯一被提取的东西,是最后一个 SSE message_delta(或非流式响应的 JSON)里携带的 usage 对象。这个对象变成一条计费记录。消息体的字节本身不会写盘,也不会复制到任何队列。

存什么

每一次请求,无论成功还是失败,BUZZ 都只保留一条小记录,大致长这样:

{
  "request_id":   "202605260713594...",
  "user_id":      "usr_...",
  "key_id":       "key_...",
  "endpoint":     "/v1/messages",
  "model":        "claude-haiku-4-5-20251001",
  "channel":      "anthropic-direct-1",
  "status":       200,
  "input_tokens": 1240,
  "output_tokens": 380,
  "cache_read_tokens": 800,
  "latency_ms":   2410,
  "ts":           "2026-05-26T07:13:59Z"
}

这就是我们对你流量保留的全部内容。它足够支撑账单计算、控制台用量展示、按 request id 排查 5xx、以及不读消息内容前提下的滥用模式识别。

不存什么

需要诚实交代的例外

三个狭窄的场景下,内容会短暂离开流式管道,你应该知道:

错误响应包络。当上游返回非 2xx,小型错误 JSON 包络(几百字节、描述错误类型)会被采集到结构化日志,方便支持团队复现失败。原始请求体不会。

滥用排查。如果你的账户被风控标记(比如 key 泄露后流量暴涨),运维可临时为该 key 开启采样,采集请求哈希(不是请求体)用于审查。这需要明确的运维操作,本身也会被记录。

系统层内存。请求过程中字节会经过进程内存,不会落盘但会在 RAM 中存在。这是任何 TLS 终结代理的固有性质,Anthropic、Cloudflare 以及任何中间节点都一样。

合规与企业意义

零留存把一批棘手的采购问题变得简单。如果你的安全评审问 "客户 prompt 内容到了哪",答案就是 "进了 Anthropic 的 TLS 连接,然后没去任何别的地方",而且这个答案能被 BUZZ 自身的日志面验证(因为日志里根本就没有 prompt 字段)。

对受监管的工作负载(医疗、法律、金融),这是 "需不需要一份覆盖消息内容的数据处理协议" 的差别——没有消息内容,也就没有要覆盖的对象。它也大幅压缩了 BUZZ 假想被攻破时的爆炸半径:即便攻击者拿下整套数据库,他得到的是计费计数和路由日志,不是你的对话。

架构基石是透明转发。不留存最简单的办法,是从一开始就不持有。BUZZ 把最自然的代码路径设计成了最隐私的那条。

相关链接