Caveman Proxy请求路径详解从Agent到Provider的完整数据流图【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/cavemanCaveman Proxy 是 Caveman 项目的本地代理网关通过「base-URL 一键切换」让 Agent 的 LLM 请求在到达 Provider 之前先经过 Token 压缩据称可削减约 65% 的 Token 消耗。本文带你从一张数据流图出发完整看懂一个请求从 Agent 出发、穿越本地代理、最终抵达 Provider 的全过程。一、先搞懂Caveman Proxy 是什么一句话它是跑在本地的反向代理默认监听127.0.0.1:8787。你把 Agent 的 API 地址指向它Agent 完全无感——代码不改一行但流量会先经过 Caveman 的「Token 压缩引擎」。核心特征零代码改动只需替换 base URLProvider 请求格式原样保留BYOK 单用户模式API Key 留在环境变量配置文件里不存密钥️字节安全byte-safe任何转换失败原始字节原样转发绝不让优化拖垮业务本地记账每笔请求的真实开销写入本地 SQLite~/.caveman/caveman.db源码入口proxy/网关主逻辑在proxy/internal/gateway/proxy.go各 Provider 适配器在proxy/providers/。二、完整数据流图从 Agent 到 Provider这是本文的核心——一个请求在 Caveman 体系中的完整旅程下面按数据流顺序逐步拆解 9 个环节。三、请求生命周期九步拆解① 路由匹配找到对应的 Provider 适配器请求到达后代理先做路由匹配matchAdapter见proxy/internal/gateway/proxy.go。不同 Provider 挂在不同路径前缀下Provider典型路由Anthropic/anthropic/v1/messages、/v1/messagesOpenAI/openai/v1/chat/completions、/v1/responsesGoogle Gemini/gemini/v1beta/models/{model}:generateContentAmazon Bedrock/bedrock/model/{model}/invoke、converseAzure / Vertex/azure/...、/vertex/v1/projects/...可选挂载兼容型 Provider/compat/{name}/...自定义 base_url 环境变量凭据⚠️ 注意它是fail-closed 路由不认识的路径直接返回 404绝不盲目透传——这是排错时最常见的坑404 通常意味着 Agent 用错了挂载前缀。② 认证与凭据解析本地鉴权auth.Authenticate通过后解析出上游凭据creds.Resolve凭据优先级请求头携带的凭据 环境变量兜底如ANTHROPIC_API_KEY、AWS_BEARER_TOKEN_BEDROCK同时分类计费模式auth modePAYG按量付费、订阅Subscription、OAuth——不同模式走不同的压缩策略③ 引擎检测判断「这段内容值不值得压」请求体交给 Caveman Engine源码在 engine/。Engine 会先检测内容类型——JSON、日志、代码、表格、终端输出等每种类型有专属压缩器。检测是纯字节变换不碰网络、不碰存储。④ 原文备份进 CCR 恢复库压缩前原始字节先存进CCR 恢复库~/.caveman/ccr.db实现在engine/ccr/并生成一个handle如ccr:handle。这样 Agent 之后随时能通过caveman-mcp源码在mcp/凭 handle 精确取回原文——压缩永远可逆。⑤ 字节安全转换失败就回退原文这是整个数据流的灵魂设计——fail-open失败场景行为模式无法识别按record纯透传处理转换输入畸形转发原始字节压缩后没有变小转发原始字节CCR 不可用/写满转发原始字节不发布 handle上游拒绝压缩后的请求4xx用原始字节自动重发一次也就是说优化失败永远只影响「省不省钱」绝不影响「请求成不成功」。⑥ 携带凭据转发上游适配器接口定义在proxy/providers/adapter.go完成最后一棒把清洗映射后的请求头、解析好的上游 URL、Provider 凭据组装起来发出。传输层还有短退避重试专门兜底大请求的瞬时网络抖动。⑦⑧ 响应回流流式保持流式Provider 的响应包括 usage 用量计数原格式回传给 Agent。流式协议完整保留请求侧的转换在上游派发前就已完成不影响首字节时间。响应头还会附带披露信息比如x-caveman-compression-ratio压缩率、x-caveman-recovery-handle恢复句柄。⑨ 本地记账每笔请求落一行记录状态码、TTFB、原始/转换后字节哈希、Provider 上报的 Token 用量、生效的优化器列表。价格按目录价核算未知价格标unpriced而不是瞎猜standalone 模式下节省额只标inferred从不标verified——非常诚实。四、7 种运行模式数据流的「变速挡」同一个数据流模式决定第⑤步做什么配置在~/.caveman/caveman.yaml模式行为适合场景record纯透传只记账 估算「能省多少」基线对比、排错compress对合格内容执行压缩可恢复 日常主力模式pixel允许「文本转图片」上下文传输特定视觉模型recommend只给建议不动字节观察期shadow影子评估不生效灰度验证canary对部分流量试实验行为渐进上线active应用已启用的优化器生产五、快速上手三步接入第 1 步获取项目git clone https://gitcode.com/GitHub_Trending/caveman1/caveman第 2 步启动本地代理caveman start默认监听127.0.0.1:8787可用caveman-proxy stats查看本地 JSON 花费摘要。第 3 步把 Agent 指向它caveman wrap agentwrap命令会自动把指定 Agent 的 Provider base URL 改写到本地代理Agent 配置模板见agents/profiles/完成后即可享受全链路压缩。六、安全边界数据流里藏着哪些护栏 只监听 loopback拒绝非本地监听地址 出站 SSRF 防护私有/链路本地/回环上游默认拦截自托管需显式加入CAVE_SSRF_ALLOWLIST 凭据永不落 YAML、Authorization 头永不出日志 请求体上限 32MBCAVE_MAX_REQUEST_BYTES可调七、延伸阅读顺着源码走一遍想深入这条数据流的实现推荐按此顺序网关主流程本文①~⑨的完整实现proxy/internal/gateway/proxy.goProvider 适配器接口与请求元数据proxy/providers/adapter.go独立网关装配与适配器注册proxy/internal/standalone/架构总览与故障行为表docs/technical/architecture.md本地代理与 Provider 官方说明docs/technical/proxy-and-providers.md压缩引擎四大操作Compress/Retrieve/Detect/Statsengine/MCP 恢复通道mcp/一句话总结Caveman Proxy 的请求路径 「路由匹配 → 凭据解析 → 引擎压缩CCR 可恢复→ 字节安全转发 → 本地记账」9 个环节环环有兜底——最坏的情况它就是一台透明的本地代理。【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考