企业官网建设流程全解析

省钱三件套横评：Caveman Skill、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 编码代理的账单主要花在两个地方：模型说太多（输出 token 里的客套话、复述、总结）和模型读太多（每次调用都要重发的系统提示、对话历史、工具返回的日志与 JSON）。Caveman 生态把这两个方向拆成了三个独立组件——管输出的 Skill、管输入的 proxy、以及面向自建应用的通用压缩中间件。它们不是同一件事的三层包装，而是作用在模型调用链路不同位置的省钱工具。本文基于仓库实测数据（docs/WRAP-BENCHMARK.md、docs/HONEST-NUMBERS.md）逐一拆解：各自能省多少、代价是什么、按什么场景选型。

三个工具在链路中的位置

先把三者按"压什么、在哪压"对齐：

Skill 是一条"规则注入"：它不改任何请求字节，只让模型换个口吻说话。proxy 是一个真正的字节级代理：caveman start在127.0.0.1:8787起一个与 Anthropic/OpenAI/Gemini/Bedrock 协议兼容的监听，把 agent 的 base URL 指过去，流量经本地 Engine 压缩后再转发到真实提供商。中间件则是把 Engine 的压缩能力以适配器形式塞进你自己写的应用代码里，框架（OpenAI SDK、LangChain、LiteLLM、Vercel AI SDK 等）保留自己的推理客户端、重试和流式逻辑。

三者可以独立运行，也可以叠加——proxy 在包裹 Claude Code 时会顺带挂上 Skill，这就是 README 中"整会话基准"的默认形态。

各能省多少：三份实测数据

Skill：输出侧，砍的是"废话"而不是"内容"

Skill 的核心规则写得很克制：回答先行、杀掉寒暄、一句一个意思、代码块/命令/路径/错误信息逐字符保留、否定词永不丢。它明确声明"never perform caveman"——如果口语化并不更短，就用平实写法。也就是说，它压的是仪式感，不是信息。

仓库用 claude-opus-5-5 对十道开发题做过一次输出长度实测（README.md 基准表，harness 见 evals/README.md）：

注意其中两件事：其一，新模型已经"天生会简短"，所以真正的对照基线是 4,334 这一行；其二，/caveman相比"请简洁回答"只再省约 3%（在噪声范围内），/ultracave才是量级选手（中位数再省 35%），/megacave（文言文）靠的是字符数暴降、token 收益有限（中位数 9%，区间从 +12% 到 −39%）。社区流传的"砍 65%"更多来自 Adobe Research 等外部复现（八个模型、五个数据集，成本下降 1.4–2.4×），而仓库自己发布的口径是：输出压缩没有公开的权威基准，只有上面这份单次快照。

Skill 的代价是明码标价的：规则文本大约为每次调用增加约 1,000 个输入 token（README.md）。短任务可能净亏——GitHub 上就有人测出固定提示开销超过输出节省（HONEST-NUMBERS 记录在案）。而且它只对按 token 计费的平台有效，按请求计费（如 Copilot premium requests）时答案变短了价格不变，纯属白忙。

Proxy：输入侧，压缩的是"agent 反复重读的东西"

Agent 会话中真正的 token 大头往往不是对话，而是每轮都会重新发送的工具结果：几十 KB 的 CSV、日志、YAML、测试输出、JSON。proxy 的 Engine（engine/README.md）按内容形状匹配压缩器（默认注册表有 15 个：JSON、日志、代码、diff、表格、配置、TOON 等），每次有损压缩前先把原始字节存进本地 CCR 恢复库，再给模型一个更小的表示和可取回原样的句柄；解析失败、存不下或压缩后不变小，就原样透传且不认领任何节省。

仓库的 Wrap 基准（docs/WRAP-BENCHMARK.md）给出了目前最扎实的一手数字：六个确定的、agent 形态的工具输出工作负载（每个 60–95 KB），每臂三次重复，Claude Code 直连 vs Caveman 包裹，共 54 次运行：

单看文件级压缩更夸张：CSV 28,041→314（−98.9%）、日志 22,810→348（−98.5%）、YAML 20,447→178（−99.1%）、测试输出 −98.9%、JSON −98.5%。但文件缩小不等于会话缩小——整会话还带着系统提示、工具定义、对话历史和 Skill 规则，所以会话级只有 33.2%。最诚实的部分藏在表格尾部：HTML 没有对应压缩器，Caveman 只付了自己的开销没赚回一分钱，该用例−9.9% 反超支，且没有被隐藏或剔出聚合。这正是社区对 Caveman 信任的来源：反例留在表里。

proxy 的代价是运维性的：需要常驻本地进程、CCR 存储（默认上限 512 MiB）和管理恢复句柄；订阅流量（Claude Pro/Max）默认不压缩（subscription_compress: false），避免在订阅计费下引入风险。

中间件：给自建应用的那一份"可恢复压缩"

如果你不是在包裹现成编码 agent，而是自己写 agent 或服务，中间件把同样的压缩能力以适配器形式开放出来（packages/middleware/typescript/README.md 与 packages/middleware/python/README.md）。它的行为契约比 proxy 更严格：

• 压缩需要恢复工具：只有能注册caveman_retrieve的入口点才会真正压缩（如withCavemanOpenAI的runTools、withCavemanAgent）；普通messages.create只记录、透传，报告recovery_unbound。
• 三种模式：off/record/compress。客户端默认压缩，独立 runtime 默认记录，两边都要显式设置。
• fail-open + 版本门控：适配器检查框架版本，超出测试范围就原样透传并告警一次；任何内部异常都不会改写你的请求。
• 作用域隔离：scope 按命名空间和 session_id 切分，runtime.deleteSession(scope)只删某个用户的原件；多租户一个 client 实例即可。

一个反直觉但重要的设计：最终决策报告里没有 token 计数器。本地分段估计是推断的（inferred），提供商用量和账单节省是另一套证据，"本地示例不验证任何账单节省"。也就是说，中间件给你的是可观测性和可恢复压缩，省钱数字要拿提供商账单自己验证——它宁可少报，也不虚报。

按部署形态与计费模式选型

计费模式是第一道筛子

• 按 token 计费（API key 直连、BYOK）：三件套全部适用，输入侧（proxy/中间件）收益通常大于输出侧。
• 按请求/信用计费（Copilot premium requests 等）：输出压缩完全无效；输入压缩仍有意义吗？部分平台按上下文大小阶梯计价，需要自己 A/B。HONEST-NUMBERS 的规则很简单：同一任务在开/关 Caveman 下对比提供商账单，净增就关掉。
• 订阅制（Claude Pro/Max）：proxy 的订阅压缩默认关闭，因为订阅下输入 token 的边际成本为零——先检查自己的套餐，再决定要不要开subscription_compress。

部署形态决定用哪个"壳"

• 个人开发机、高频使用：Skill 一条命令（npx skills add JuliusBrussee/caveman -g）零成本起步，先砍输出；觉得不够再npm install -g @caveman-ai/cli && caveman setup --install，caveman claude起本地代理。本地 proxy 默认只监听127.0.0.1:8787，无入站认证，单机 BYOK。
• 团队共享/自托管：同一caveman-proxy二进制可部署为一个共享服务（docs/technical/deploy.md）。设置CAVEMAN_AUTH_TOKEN（openssl rand -hex 32生成）后才允许非回环监听，且该 token 在转发前即被消费、绝不会到达提供商；SSRF 防护默认拦截私网/环回上游，除非显式加入CAVE_SSRF_ALLOWLIST。仓库提供 Docker、Compose、K8s（含 HA 版）、ECS Fargate、Cloud Run、Fly.io 全套清单。这里的关键约束：SQLite 状态一份卷只允许一个写入者，K8s 清单用Recreate而非滚动更新；中间件存储可切 Postgres，才能多副本水平扩展。
• 自建应用/Agent 服务：走中间件适配器。部署拓扑上推荐 sidecar 模式——每个应用 Pod 一个 runtime，回环监听，多租户隔离靠 Postgres schema 与身份（共享 token、token map、OIDC、mTLS 四级身份源）；需要加密原件时配CAVEMAN_MIDDLEWARE_ENCRYPTION_KEY（AES-256-GCM）。

组合策略：从最小路径开始

product-model 文档给了一张"最小路径表"，原则是一次只加一层，只有当某层在你自己的负载上实测赚回开销，才继续叠加：

观测是省钱的第一步：caveman learn只读本机会话历史，给配置税、死技能、超窗消息、重复粘贴块逐项打分并给出机械修复建议，且只在你确认后逐个 diff 应用、净亏自动回退。把观测层与执行层分开，是 Caveman 这套工具链区别于"一个魔法开关"的核心。

社区热度与"把反例写进文档"的文化

Caveman 的破圈不需要复述——百万级 star、Hacker News 榜首、被 Adobe Research 论文引用、被 JetBrains 做 A/B（86 个真实编码任务，p=0.82，无可测质量损失）、被 Elasticsearch Labs 改造成 63.6% 响应 token 削减的变体，这些都在 README.md 的 "In the wild" 一节有据可查。

比热度更值得学习的是它的实证纪律：输出压缩不吹"权威基准"、HTML 反例留在图表里、规则开销和按请求计费的失效场景写进 docs/HONEST-NUMBERS.md、本地数字只允许标inferred永不标verified。三件套横评的结论因此很明确——没有"谁最能省钱"的普适答案，只有按链路、按计费、按部署形态各自测量：输出侧的 Skill 门槛最低但天花板有限且要吃 1,000 token 规则税；输入侧的 proxy 收益最大（会话级 33.2%），但要扛起代理运维和恢复存储；中间件给自建应用留了同样的可恢复压缩，代价是严格的版本门控与作用域管理。先跑一次caveman learn看清自己的钱花在哪，再决定让哪块石头扛活。

【免费下载链接】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