流式响应、并发性能、统计边界caveman proxy 实测中容易忽略的三个隐患【免费下载链接】caveman why use many token when few token do trick. Viral skill proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman把 AI 编码代理的请求从本地转发到云端模型时proxy 层的价值常常被一句话概括改请求、省 token、看账单。但从社区实测反馈看真正让开发者踩坑的地方恰恰藏在三个角落流式响应下的 token 统计是否失真、并发场景下前缀缓存与计量是否稳定、统计边界到底把什么算进去、什么不算。这三个问题如果没想清楚proxy 省下来的 token 数字就会变成一份看似精确、实则无法对账的报表。caveman proxyproxy/ 目录网关核心在 proxy/internal/gateway/在这三个维度上给出了相当硬核的工程答案。本文结合其源码逐一拆解这三处隐患及其在实现层面的对策——这不是教程而是把 proxy 当作计量仪器的边界条件测试。隐患一流式响应下的 token 统计失真流式请求为什么默认被排除在压缩路径之外先看一个容易忽略的事实流式请求根本不参与压缩改造。proxy/internal/gateway/proxy.go 的compress分支里有这样一行判断serverRetrieveAllowed : authMode AuthModePAYG !s.recoveryViaMCP !meta.Stream !hasRetrieveTool(body) serverRetrieveSupported(meta.Provider, meta.Endpoint)!meta.Stream意味着一旦请求声明了流式服务端注入 retrieve 工具、走 CCR 恢复路径的资格立即被取消。为什么因为压缩请求的原始内容存放在本地 CCR缓存恢复存储里压缩后的请求通过ccr:handle标记携带句柄恢复路径要么靠服务端注入 retrieve 工具在一次流式会话中多轮调用要么靠 MCP 工具由代理侧自行取回。流式请求让这两种恢复方式都变得不可靠——你无法在一条不断吐字的事件流里优雅地插入一次先取回原始内容再继续的往返。caveman 的取舍很干脆恢复不可达的改造一律不做。这引出了第一个实测教训如果你在 compress 模式下对 SDK 默认开启stream: true的调用做压测会发现压缩率数字远低于文档宣称的 65%。那不是 bug而是流式请求被有意挡在压缩门外属于安全优先于省钱的策略。响应流的计量tee 扫描与 TTFB 的真实测量流式响应的计量则是另一套机制。代理把上游响应体通过io.TeeReader同时喂给客户端拷贝和UsageScannerproxy/internal/gateway/proxy.go 的streamResponse边转发边解析 SSE 事件流里的 usage 字段不缓冲客户端拷贝。这里有两个值得注意的边界扫描缓冲上限UsageScanner默认只缓冲 2 MiBCAVE_USAGE_SCAN_MAX_BYTES见 proxy/providers/adapter.go。一旦响应超过上限它放弃全量缓冲只保留一个有限尾部且仅在编码为 identity 时才尝试从尾部恢复完整的 usage 事件——否则直接标记response_scan_limit_exceeded整行计费信息降级为 unknown。换句话说超大流式响应可能丢统计。usage 事件的合并语义流式场景下 provider 会把 usage 拆在多个事件里如 Anthropic 的message_start带 input/cache 字段message_delta只带 output。proxy/providers/adapter.go 的UsageObservation注释明确指出这是merge 而非取最后一个 chunk且同一字段取较大值、空值不覆盖非空值——否则 Anthropic 的缓存增量数据会从账单里无声消失。TTFB 的测量同样只在流式路径上成立countingWriter记录首个字节写入时刻proxy/internal/gateway/proxy.go 的firstByteAt配合streamResponse在首读前强制Flush()让客户端尽早看到 SSE 头部。proxy/internal/gateway/server_test.go 的TestRoundTripStreamTTFB专门断言TTFB 为真实正值且低于总延迟。这个测试的存在说明非流式路径的 TTFB 没有意义——整段响应被缓冲完才提交头所谓首字节延迟就是总延迟。流式中断的记账规则最后一个容易被忽视的点流式中断时usage 已部分入账怎么办caveman 的规则是流式中断不再重放never replay a partial response因为 provider 可能已经完成了推理并计费同时已解析的完整 usage 仍可保留在行内用于支出统计但失败的流绝不产生反事实节省——record()里压缩节省的归属条件是status 2xx errorCode !usage.ProviderError !retrieved。一个中途断掉的流无论压缩器产出了多少都不会被计入省了多少钱。隐患二并发场景的性能与计量偏差并发前缀稳定一个真实的回归与修复代理对每个请求做字节级改造压缩、工具 schema 裁剪、缓存断点注入这要求同一会话的同一前缀块在每轮请求中输出完全相同的字节——否则 provider 侧的 prompt cache 前缀每次都在变缓存永远打不中。并发正是打破这个不变量的头号杀手。proxy/internal/gateway/prefix_stability_test.go 的TestPrefixStableUnderConcurrency记录了一个真实回归代理并发服务多个回合并行 agent、subagent而支撑前缀缓存的存储同时又是遥测 sink查找总是与写入竞争。一旦竞争把命中降级为 miss相同请求就会产生不同字节发往上游provider 的 prompt cache 便不确定性地失配。该测试用 8 个并发 goroutine 发送完全相同的请求体断言上游收到的 n 个 body 的 SHA-256 必须全部一致len(seen) ! 1即失败。修复后的约束是任何并发路径都不允许把本该命中的替换降级成 miss。这个测试本身就是给使用者的警示并发压测代理时不要只看吞吐还要抓上游原始请求的字节指纹确认前缀稳定。并发下的计量行为买单 goroutine 与有损捕获计量侧的并发防护同样明确body capture 是有损的。proxy/internal/gateway/capture.go 实现的本地请求体捕获CAVE_CAPTURE_DIR开启通过有界队列 单 writer goroutine落盘队列满时直接丢弃记录并计数。设计注释写得很直白诊断仪器绝不能拖慢或打断流量哈希、编码、写盘全部挪到 writer 侧请求路径上最多付出一次 nil 检查和一个 channel 发送。所以高并发下如果你发现捕获文件出现 seq 空洞那不是文件损坏而是仪器主动丢弃——捕获用于诊断不用于计费。观测式估计与上游往返并行。record 模式下若开启observe-estimatetokenizer 加 Simulate 的估算成本被放到 goroutine 里与上游往返重叠执行proxy/internal/gateway/proxy.go 的estimateWG避免估算落在 time-to-first-byte 上主路径在record()前统一estimateWG.Wait()保证 happens-before。并发计量的前提是估算永远跑在拷贝上绝不碰转发字节。性能数字的可信度并发压测时你还会发现一个指标分层LatencyMS是总耗时TTFBMS只对流式有意义ResponseBytes来自countingWriter只统计成功写到客户端的字节数。被客户端中断、被截断的响应其字节数与 usage 都不会伪装成成功——streamResponse返回错误码后主路径会panic(http.ErrAbortHandler)主动打断 HTTP 帧避免残缺 SSE 被客户端当成干净 EOF。所以读并发报告时凡是cave_client_canceled/cave_upstream_body_read_failed的行都不能计入成功流量的均值里。隐患三统计边界什么该算、什么不算这是三个隐患里最容易被忽略、也最影响对账可信度的部分。caveman 的统计边界哲学可以浓缩成一句每笔数字必须能说清怎么来的。docs/technical/accounting-and-evidence.md 把证据基底evidence basis分成七类——measured、inferred、provider_reported、benchmark_counterfactual、observed、verified、unpriced并规定一个值不能在被聚合时悄悄更换基底。边界一4 MiB 与多模态请求侧估计的禁区proxy/internal/gateway/stats_accounting.go 的requestAccounting是整条统计链上最严格的守门员if len(original) requestAccountingMaxBytes || len(accepted) requestAccountingMaxBytes { row.RequestMeasurementStatus request_payload_too_large return }超过 4 MiB 的请求不做本地 token 估计requestAccountingMaxBytes 4 20只保留 provider 侧真实 usage 和定价——大请求照常流转但压缩省了多少 token这一项直接 unavailable。为什么因为本地 o200k tokenizer 的估算对超大 payload 既不经济也不可信。多模态 payload 整个被排除。containsNonTextInput递归扫描 OpenAI 的image_url、Anthropic 的input_image、Bedrock 的bytes/s3Location、Gemini 的inlineData等形状只要出现图片/音频/文件就把 base64 字节当作文本 token 去估计是荒谬的模型看到的是像素不是 base64 字符所以该请求直接标记unsupported_payload。归一化防止作弊式节省。两侧 JSON 都经compactTextRequest规范化——键序、转义\u0061vsa、HTML 转义差异全部抹平后再计数避免重组器通过序列化差异造出 token 节省。这三条合起来说明本地估计只对纯文本、大小适中、单次调用的请求可信。凡是多模态、超大、多调用恢复recovery_multiple_calls的请求你在caveman stats里看到的将是unavailable这不是缺陷而是统计诚实性的体现。边界二反事实定价的保守规则即使估计通过折算美元时还有更多禁区自定义上游源不定价statsPricingOriginKnown只认官方域名api.openai.com、api.anthropic.com、generativelanguage.googleapis.com、bedrock/vertex 正规主机运营商自建 base URL 即便用同样协议和模型名也可能按完全不同的费率计费因此这类请求一律标custom_provider_origin不套官方刊例价。未知模型绝不借兄弟模型的价格docs/technical/stats-accounting.mdunpriced意味着零加显式标记零防止虚构成本进入合计标记防止零被误读为免费。反事实阈值不可证明时拒绝定价本地 BPE 差值无法证明 provider 的反事实计费档位比如压缩可能把请求拉低到更低的价格档requestAccounting里cost.ForInputTokens(price, int(baselineInput)) ! effective时直接标counterfactual_tier_unknown——宁可不算也不乱算。边界三什么不算节省统计边界还要回答哪些东西明确不该进节省账本失败的请求不算压缩器产出了输出 ≠ 省了钱requestAccounting在status 200 || status 300 || errorCode ! || usage.ProviderError时直接返回失败状态。重放原始字节的请求不算上游 4xx 拒绝改造后的请求时proxy 用原始字节 fail-open 重试一次proxy/internal/gateway/proxy.go 的字节安全回退该重试不认领任何优化、不记账任何节省The retry claims no optimization and books no savings。恢复请求不算retrieved为真时压缩节省被整体拒绝因为代理无法证明压缩请求与检索到的原始内容在模型侧等价。按次计费场景无效社区情报里多次提到的对按请求计费平台无效也是统计边界的一部分——token 压缩只对按 token 计费的模型有意义这是工具的边界不是缺陷。订阅/OAuth 场景只展示等价价值subscription_passthrough流量走 S0 直通统计上记为 token-only、绝不折算成美元节省订阅账单不会因为 proxy 压缩而减少等价 API 价值与真金白银的节省被严格区分。三个隐患的排查清单把源码里的防护机制翻译成实测时的操作建议隐患现象排查入口流式统计失真压缩率偏低、大流式响应缺 usage检查meta.Stream是否导致请求被排除压缩检查CAVE_USAGE_SCAN_MAX_BYTES与response_scan_limit_exceeded标记区分 TTFB 与非流式缓冲并发偏差相同请求上游字节不同、捕获文件 seq 空洞参照TestPrefixStableUnderConcurrency抓上游字节指纹CAVE_CAPTURE_DIR下空洞是丢弃而非损坏勿把cave_client_canceled行计入成功均值统计边界报表出现大量unavailable/unpriced对照 docs/technical/accounting-and-evidence.md 的基底表4 MiB 与多模态请求本就该 unavailable自定义 base URL 不套官方价caveman proxy 最值得借鉴的不是压缩算法本身而是它对不可验证的数字宁可不给的态度流式路径为了恢复可靠性放弃压缩资格并发路径用有损捕获换取流量零阻塞统计边界则用unpriced、counterfactual_tier_unknown、response_scan_limit_exceeded一类显式状态把不知道如实说出来。对于任何把 proxy 当计量仪器用的团队这三个隐患对应的不是三个 bug而是三份边界说明书——读懂它们你才能知道报表上每个数字到底证明了什么。【免费下载链接】caveman why use many token when few token do trick. Viral skill proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 13:59:16 · 阅读 1.2k 流式响应、并发性能、统计边界：caveman proxy 实测中容易忽略的三个隐患
流式响应、并发性能、统计边界caveman proxy 实测中容易忽略的三个隐患【免费下载链接】caveman why use many token when few token do trick. Viral skill proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman把 AI 编码代理的请求从本地转发到云端模型时proxy 层的价值常常被一句话概括改请求、省 token、看账单。但从社区实测反馈看真正让开发者踩坑的地方恰恰藏在三个角落流式响应下的 token 统计是否失真、并发场景下前缀缓存与计量是否稳定、统计边界到底把什么算进去、什么不算。这三个问题如果没想清楚proxy 省下来的 token 数字就会变成一份看似精确、实则无法对账的报表。caveman proxyproxy/ 目录网关核心在 proxy/internal/gateway/在这三个维度上给出了相当硬核的工程答案。本文结合其源码逐一拆解这三处隐患及其在实现层面的对策——这不是教程而是把 proxy 当作计量仪器的边界条件测试。隐患一流式响应下的 token 统计失真流式请求为什么默认被排除在压缩路径之外先看一个容易忽略的事实流式请求根本不参与压缩改造。proxy/internal/gateway/proxy.go 的compress分支里有这样一行判断serverRetrieveAllowed : authMode AuthModePAYG !s.recoveryViaMCP !meta.Stream !hasRetrieveTool(body) serverRetrieveSupported(meta.Provider, meta.Endpoint)!meta.Stream意味着一旦请求声明了流式服务端注入 retrieve 工具、走 CCR 恢复路径的资格立即被取消。为什么因为压缩请求的原始内容存放在本地 CCR缓存恢复存储里压缩后的请求通过ccr:handle标记携带句柄恢复路径要么靠服务端注入 retrieve 工具在一次流式会话中多轮调用要么靠 MCP 工具由代理侧自行取回。流式请求让这两种恢复方式都变得不可靠——你无法在一条不断吐字的事件流里优雅地插入一次先取回原始内容再继续的往返。caveman 的取舍很干脆恢复不可达的改造一律不做。这引出了第一个实测教训如果你在 compress 模式下对 SDK 默认开启stream: true的调用做压测会发现压缩率数字远低于文档宣称的 65%。那不是 bug而是流式请求被有意挡在压缩门外属于安全优先于省钱的策略。响应流的计量tee 扫描与 TTFB 的真实测量流式响应的计量则是另一套机制。代理把上游响应体通过io.TeeReader同时喂给客户端拷贝和UsageScannerproxy/internal/gateway/proxy.go 的streamResponse边转发边解析 SSE 事件流里的 usage 字段不缓冲客户端拷贝。这里有两个值得注意的边界扫描缓冲上限UsageScanner默认只缓冲 2 MiBCAVE_USAGE_SCAN_MAX_BYTES见 proxy/providers/adapter.go。一旦响应超过上限它放弃全量缓冲只保留一个有限尾部且仅在编码为 identity 时才尝试从尾部恢复完整的 usage 事件——否则直接标记response_scan_limit_exceeded整行计费信息降级为 unknown。换句话说超大流式响应可能丢统计。usage 事件的合并语义流式场景下 provider 会把 usage 拆在多个事件里如 Anthropic 的message_start带 input/cache 字段message_delta只带 output。proxy/providers/adapter.go 的UsageObservation注释明确指出这是merge 而非取最后一个 chunk且同一字段取较大值、空值不覆盖非空值——否则 Anthropic 的缓存增量数据会从账单里无声消失。TTFB 的测量同样只在流式路径上成立countingWriter记录首个字节写入时刻proxy/internal/gateway/proxy.go 的firstByteAt配合streamResponse在首读前强制Flush()让客户端尽早看到 SSE 头部。proxy/internal/gateway/server_test.go 的TestRoundTripStreamTTFB专门断言TTFB 为真实正值且低于总延迟。这个测试的存在说明非流式路径的 TTFB 没有意义——整段响应被缓冲完才提交头所谓首字节延迟就是总延迟。流式中断的记账规则最后一个容易被忽视的点流式中断时usage 已部分入账怎么办caveman 的规则是流式中断不再重放never replay a partial response因为 provider 可能已经完成了推理并计费同时已解析的完整 usage 仍可保留在行内用于支出统计但失败的流绝不产生反事实节省——record()里压缩节省的归属条件是status 2xx errorCode !usage.ProviderError !retrieved。一个中途断掉的流无论压缩器产出了多少都不会被计入省了多少钱。隐患二并发场景的性能与计量偏差并发前缀稳定一个真实的回归与修复代理对每个请求做字节级改造压缩、工具 schema 裁剪、缓存断点注入这要求同一会话的同一前缀块在每轮请求中输出完全相同的字节——否则 provider 侧的 prompt cache 前缀每次都在变缓存永远打不中。并发正是打破这个不变量的头号杀手。proxy/internal/gateway/prefix_stability_test.go 的TestPrefixStableUnderConcurrency记录了一个真实回归代理并发服务多个回合并行 agent、subagent而支撑前缀缓存的存储同时又是遥测 sink查找总是与写入竞争。一旦竞争把命中降级为 miss相同请求就会产生不同字节发往上游provider 的 prompt cache 便不确定性地失配。该测试用 8 个并发 goroutine 发送完全相同的请求体断言上游收到的 n 个 body 的 SHA-256 必须全部一致len(seen) ! 1即失败。修复后的约束是任何并发路径都不允许把本该命中的替换降级成 miss。这个测试本身就是给使用者的警示并发压测代理时不要只看吞吐还要抓上游原始请求的字节指纹确认前缀稳定。并发下的计量行为买单 goroutine 与有损捕获计量侧的并发防护同样明确body capture 是有损的。proxy/internal/gateway/capture.go 实现的本地请求体捕获CAVE_CAPTURE_DIR开启通过有界队列 单 writer goroutine落盘队列满时直接丢弃记录并计数。设计注释写得很直白诊断仪器绝不能拖慢或打断流量哈希、编码、写盘全部挪到 writer 侧请求路径上最多付出一次 nil 检查和一个 channel 发送。所以高并发下如果你发现捕获文件出现 seq 空洞那不是文件损坏而是仪器主动丢弃——捕获用于诊断不用于计费。观测式估计与上游往返并行。record 模式下若开启observe-estimatetokenizer 加 Simulate 的估算成本被放到 goroutine 里与上游往返重叠执行proxy/internal/gateway/proxy.go 的estimateWG避免估算落在 time-to-first-byte 上主路径在record()前统一estimateWG.Wait()保证 happens-before。并发计量的前提是估算永远跑在拷贝上绝不碰转发字节。性能数字的可信度并发压测时你还会发现一个指标分层LatencyMS是总耗时TTFBMS只对流式有意义ResponseBytes来自countingWriter只统计成功写到客户端的字节数。被客户端中断、被截断的响应其字节数与 usage 都不会伪装成成功——streamResponse返回错误码后主路径会panic(http.ErrAbortHandler)主动打断 HTTP 帧避免残缺 SSE 被客户端当成干净 EOF。所以读并发报告时凡是cave_client_canceled/cave_upstream_body_read_failed的行都不能计入成功流量的均值里。隐患三统计边界什么该算、什么不算这是三个隐患里最容易被忽略、也最影响对账可信度的部分。caveman 的统计边界哲学可以浓缩成一句每笔数字必须能说清怎么来的。docs/technical/accounting-and-evidence.md 把证据基底evidence basis分成七类——measured、inferred、provider_reported、benchmark_counterfactual、observed、verified、unpriced并规定一个值不能在被聚合时悄悄更换基底。边界一4 MiB 与多模态请求侧估计的禁区proxy/internal/gateway/stats_accounting.go 的requestAccounting是整条统计链上最严格的守门员if len(original) requestAccountingMaxBytes || len(accepted) requestAccountingMaxBytes { row.RequestMeasurementStatus request_payload_too_large return }超过 4 MiB 的请求不做本地 token 估计requestAccountingMaxBytes 4 20只保留 provider 侧真实 usage 和定价——大请求照常流转但压缩省了多少 token这一项直接 unavailable。为什么因为本地 o200k tokenizer 的估算对超大 payload 既不经济也不可信。多模态 payload 整个被排除。containsNonTextInput递归扫描 OpenAI 的image_url、Anthropic 的input_image、Bedrock 的bytes/s3Location、Gemini 的inlineData等形状只要出现图片/音频/文件就把 base64 字节当作文本 token 去估计是荒谬的模型看到的是像素不是 base64 字符所以该请求直接标记unsupported_payload。归一化防止作弊式节省。两侧 JSON 都经compactTextRequest规范化——键序、转义\u0061vsa、HTML 转义差异全部抹平后再计数避免重组器通过序列化差异造出 token 节省。这三条合起来说明本地估计只对纯文本、大小适中、单次调用的请求可信。凡是多模态、超大、多调用恢复recovery_multiple_calls的请求你在caveman stats里看到的将是unavailable这不是缺陷而是统计诚实性的体现。边界二反事实定价的保守规则即使估计通过折算美元时还有更多禁区自定义上游源不定价statsPricingOriginKnown只认官方域名api.openai.com、api.anthropic.com、generativelanguage.googleapis.com、bedrock/vertex 正规主机运营商自建 base URL 即便用同样协议和模型名也可能按完全不同的费率计费因此这类请求一律标custom_provider_origin不套官方刊例价。未知模型绝不借兄弟模型的价格docs/technical/stats-accounting.mdunpriced意味着零加显式标记零防止虚构成本进入合计标记防止零被误读为免费。反事实阈值不可证明时拒绝定价本地 BPE 差值无法证明 provider 的反事实计费档位比如压缩可能把请求拉低到更低的价格档requestAccounting里cost.ForInputTokens(price, int(baselineInput)) ! effective时直接标counterfactual_tier_unknown——宁可不算也不乱算。边界三什么不算节省统计边界还要回答哪些东西明确不该进节省账本失败的请求不算压缩器产出了输出 ≠ 省了钱requestAccounting在status 200 || status 300 || errorCode ! || usage.ProviderError时直接返回失败状态。重放原始字节的请求不算上游 4xx 拒绝改造后的请求时proxy 用原始字节 fail-open 重试一次proxy/internal/gateway/proxy.go 的字节安全回退该重试不认领任何优化、不记账任何节省The retry claims no optimization and books no savings。恢复请求不算retrieved为真时压缩节省被整体拒绝因为代理无法证明压缩请求与检索到的原始内容在模型侧等价。按次计费场景无效社区情报里多次提到的对按请求计费平台无效也是统计边界的一部分——token 压缩只对按 token 计费的模型有意义这是工具的边界不是缺陷。订阅/OAuth 场景只展示等价价值subscription_passthrough流量走 S0 直通统计上记为 token-only、绝不折算成美元节省订阅账单不会因为 proxy 压缩而减少等价 API 价值与真金白银的节省被严格区分。三个隐患的排查清单把源码里的防护机制翻译成实测时的操作建议隐患现象排查入口流式统计失真压缩率偏低、大流式响应缺 usage检查meta.Stream是否导致请求被排除压缩检查CAVE_USAGE_SCAN_MAX_BYTES与response_scan_limit_exceeded标记区分 TTFB 与非流式缓冲并发偏差相同请求上游字节不同、捕获文件 seq 空洞参照TestPrefixStableUnderConcurrency抓上游字节指纹CAVE_CAPTURE_DIR下空洞是丢弃而非损坏勿把cave_client_canceled行计入成功均值统计边界报表出现大量unavailable/unpriced对照 docs/technical/accounting-and-evidence.md 的基底表4 MiB 与多模态请求本就该 unavailable自定义 base URL 不套官方价caveman proxy 最值得借鉴的不是压缩算法本身而是它对不可验证的数字宁可不给的态度流式路径为了恢复可靠性放弃压缩资格并发路径用有损捕获换取流量零阻塞统计边界则用unpriced、counterfactual_tier_unknown、response_scan_limit_exceeded一类显式状态把不知道如实说出来。对于任何把 proxy 当计量仪器用的团队这三个隐患对应的不是三个 bug而是三份边界说明书——读懂它们你才能知道报表上每个数字到底证明了什么。【免费下载链接】caveman why use many token when few token do trick. Viral skill proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考