OpenClacky 深度拆解：省钱的 Agent 是真省钱，还是数字游戏？

> 一句话结论：OpenClacky 确实比 OpenClaw 和 Hermes 便宜得多，但"比 Claude Code 便宜"的说法需要打折扣——它在部分任务上更贵，且实测缓存命中率（90.6%）与宣传话术（"接近100%"）存在差距。真正的价值不在"省钱"，而在它的 BYOK 模型路由和 Skill 经济实验。

---

一、先看数字：谁在说真话？

1.1 Benchmark 的原始数据

OpenClacky 官网公布的 benchmark（2026-04-30，OpenRouter CSV 对账）：

Agent	总成本	请求数	缓存命中率	模型
OpenClacky	$5.10	51	90.6%	Claude Opus 4.7
Claude Code	$5.49	70	95.2%	Claude Opus 4.7
OpenClaw	$15.70	81	88.7%	Claude Opus 4.7
Hermes	$30.14	218	60.3%	Claude Opus 4.7

控制变量：相同提示词、相同模型、相同 Skill 版本、同一时间段、单次运行无挑选、OpenRouter 逐请求 CSV 对账。

1.2 第一个反直觉发现

Claude Code 的缓存命中率实际上比 OpenClacky 更高（95.2% vs 90.6%）。

但 OpenClacky 的总成本反而更低。为什么？

答案：请求数。OpenClacky 用 51 个请求完成任务，Claude Code 用了 70 个。每个请求都有基础开销（系统提示词、工具描述），请求数越少，总成本越低——即使单次请求的缓存命中率略低。

这不是"缓存技术碾压"，这是请求调度策略的胜利。

1.3 任务级拆解：没有全面碾压

把三个任务拆开看，故事更复杂：

任务	OpenClacky	Claude Code	OpenClaw	Hermes
01 PPT 制作	$1.23	$1.45	$5.07	$10.96
02 营销页面	$1.72	$1.20	$7.47	$4.65
03 社交内容	$2.14	$2.84	$3.15	$14.53

第二个反直觉发现：在"营销心理学"任务上，Claude Code 比 OpenClacky 便宜 43%（$1.20 vs $1.72）。

这意味着 OpenClacky 的"比 CC 便宜"只在特定任务类型上成立，不是普适结论。文章里"比公认全球顶级的闭源产品 Claude Code 还便宜一点点"——这个"一点点"在另一个任务上变成了"贵不少"。

---

二、缓存机制："接近100%"是技术还是话术？

2.1 OpenClacky 的四项声称

官网列出的省钱原理：

1. Session 不重启，系统提示词不变 —— 缓存锚点始终有效 2. 双重缓存标记 —— 同时标记最后两条消息，确保推进时缓存不丢失 3. Insert-then-Compress —— 上下文压缩复用现有缓存 4. 空闲期自动压缩 —— 不为"等你回来"买单

2.2 "接近100%" vs 实测 90.6%

官网大字写着"Measured cache hits approach 100%"，benchmark 小字写着 90.6%。

这 9.4% 的差距不是小数点问题——在高频交互场景下，每次缓存失效都意味着额外的 token 费用。如果是每天处理数百个任务的生产环境，这 9.4% 会累积成显著的成本差异。

更关键的是：90.6% 的缓存命中率在开源 Agent 中已经很好了。OpenClaw 88.7%，Hermes 60.3%。OpenClacky 不需要夸张到"接近100%"，90.6% 已经足够有说服力。

这个话术选择说明了一件事：营销语言和工程数据之间的张力。技术团队可能觉得"approach 100%"是一种愿景，但用户读到的可能是承诺。

2.3 双重缓存标记的技术原理

这是 OpenClacky 最有技术含量的设计：

普通缓存机制（以 Anthropic Cache Control API 为例）：

用户发送消息 → 模型处理 → 标记最后一条为 cache_point
下一轮：新消息 + cache_point 之前的所有内容（如果命中缓存则免费）
问题：cache_point 只能标记一条，对话推进后之前的标记失效

OpenClacky 的"双重缓存标记"：

同时标记最后两条消息为 cache_point
即使对话推进，倒数第二条仍可作为缓存锚点

这是一个聪明的工程优化，但它依赖特定供应商的缓存 API 实现。OpenClacky 的 BYOK 模式支持多家供应商（Claude/GPT/DeepSeek/Kimi），不同供应商的缓存机制不同——"双重标记"在 OpenAI 的 prompt caching 和 Anthropic 的 cache control 上是否能同样有效，需要独立验证。

---

三、16 个工具的克制：架构选择还是功能阉割？

3.1 工具数量对比

Agent	核心工具数	扩展方式
Hermes	52	全部内置
Claude Code	40+	内置 + 扩展
OpenClaw	23-50	内置 + 插件 + MCP
OpenClacky	16	invoke_skill 元工具

3.2 工具 Schema 的 Token 成本

OpenClacky 声称工具数量是成本差异的主因之一。让我们算一笔账：

假设每个工具的定义（名称 + 描述 + 参数 schema）平均占用 200 tokens：

52 个工具：52 × 200 = 10,400 tokens/请求
16 个工具：16 × 200 = 3,200 tokens/请求
差距：7,200 tokens/请求

在 70 个请求的会话中，这相当于 504,000 tokens 的差异。按 Claude Opus 4.7 的输入价格（约 $15/MTok），这是 $7.56 的额外成本——确实不是小数。

但：

这假设所有工具的 schema 都完整加载到每次请求的上下文中。实际实现中，Agent 可能只加载本次任务相关的工具子集。
Claude Code 的 40+ 工具中，很多可能是条件加载的（如只在特定目录激活的 skill）。
工具描述可以被压缩或摘要，不一定完整传输。

所以"16 vs 52"的叙事虽然直观，但背后的 token 经济学比"每个工具 200 tokens"更复杂。

3.3 invoke_skill 元工具的设计

OpenClacky 的核心架构选择：用一个 invoke_skill 元工具替代大量专用工具。Skill 可以无限扩展，但核心工具列表保持精简。

这类似于操作系统的"系统调用"设计：内核只提供少量原语，复杂功能通过用户态库实现。好处是：

核心接口稳定，缓存锚点不漂移
Skill 的 schema 不进入系统提示词，只在调用时加载
扩展不影响基础成本结构

风险是：

如果 Skill 调用本身需要多轮交互，节省的 schema tokens 可能被调用开销抵消
Skill 的质量和一致性成为关键瓶颈——一个 poorly designed skill 可能比内置工具更贵

---

四、BYOK：自由还是陷阱？

4.1 Bring Your Own Key 的双刃剑

OpenClacky 支持多家供应商：

Claude (Anthropic)
GPT (OpenAI)
DeepSeek
Kimi (Moonshot)
MiniMax
OpenRouter

BYOK 模式的核心价值：模型选择的自主权。

主任务用 Claude 保证质量，子任务路由到 DeepSeek 或 Kimi 控制成本——这在理论上可以大幅降低总成本。但：

风险一：缓存不跨供应商复用 Anthropic 的 cache control、OpenAI 的 prompt caching、DeepSeek 的上下文压缩——不同供应商的缓存机制完全不兼容。如果一个会话在主任务用 Claude、子任务用 DeepSeek，两个供应商各收各的缓存费用，总成本可能不降反升。

风险二：供应商锁定 vs 自由 OpenClacky 的"官方供应商"选项（OpenClacky Keys）承诺"99% 缓存命中率"和"官方定价"。这听起来像是一个聚合层，但本质上：

如果通过 OpenClacky 路由，你依赖他们的缓存优化实现
如果 BYOK，你需要自己管理各家的 API key、配额、故障切换
"自由"的代价是运维复杂度

风险三：成本透明度 OpenClacky 宣传"每一步标出具体花费，是美元，不是算不明白的 token 量"。这是一个 UX 改进，但不改变底层计费逻辑。用户仍然在为模型的输入/输出 tokens 付费，只是 UI 层做了换算。真正的成本透明度需要暴露：

每次请求的具体 token 数
缓存命中/未命中的明细
供应商定价的实时变化

---

五、Skill 经济：是创新还是炒作？

5.1 官网展示的案例

OpenClacky 的"创作者计划"展示了三个方向的 Skill 产品：

产品名	领域	描述
QingClaw	法律	"10 年法律经验打包到每位同事的桌面"
JoyClaw	财富管理	"财富会被分割，人生智慧留在系统里"
MediClaw	医疗	"老专家退休了，但经验留了下来"

用户消息中提到"青狮"（QingClaw）已经卖出不少单。这是一个真实案例还是营销话术？目前无法独立验证，但方向本身有逻辑：

5.2 Skill 经济的可行性分析

为什么它可能 work：

法律、医疗、财富管理都是高度依赖隐性知识的领域
资深从业者的经验难以通过传统软件产品化
AI Agent 提供了一种新的封装形式：不是"软件功能"，而是"专家工作流的数字化副本"

为什么它可能不 work：

法律/医疗有严格的合规和执业许可要求，"AI 律师"的法律责任归属不清
Skill 的质量难以标准化——一个 poorly tested 的法律 Skill 可能导致严重后果
定价模式不确定：License 费用 vs 按使用付费 vs 订阅？
客户真正需要的是"结果保证"（如合同审查无遗漏），不是"Skill 工具"

5.3 与 OpenClaw Skill 生态的对比

OpenClaw 的 Skill 系统也支持封装和复用，但没有强调"售卖"和"加密分发"。OpenClacky 的差异化是：

加密保护 Skill 内容（防止逆向）
License 管理（按授权使用）
定价自主权（创作者自己定价）

这更像是一个"Skill 应用商店"而非"Skill 开发框架"。它的成功取决于： 1. 是否有足够多的高质量垂直领域 Skill 2. 购买者是否愿意为 Skill 付费（vs 自己写 prompt） 3. 平台抽成比例是否合理

---

六、投资人背书：MiraclePlus、真格、红杉中国、高瓴

OpenClacky 的投资人列表很亮眼：

MiraclePlus（奇绩创坛）：陆奇的投资机构，专注早期 AI 项目
ZhenFund（真格基金）：徐小平创立，投过大量 AI 初创
Sequoia China（红杉中国）：顶级 VC
Hillhouse Ventures（高瓴创投）：顶级 PE/VC

这些背书说明了两件事： 1. 资本看好 Agent 基础设施赛道——不是看好 OpenClacky 一家，是看好"更省钱的 Agent"这个方向 2. BYOK + Skill 经济的商业模式得到了验证

但投资人的背书不等于产品成功。资本的逻辑是"投赛道、投团队、投叙事"，用户的逻辑是"好不好用、省不省钱、稳不稳定"。

---

七、与 Claude Code 的真实关系

7.1 不是替代，是差异化定位

OpenClacky 在官网上把自己放在 Claude Code 下方（"~0.8×"成本），这个定位很聪明：

	Claude Code	OpenClacky
定价模式	闭源订阅（$20/月 + 额外费用）	开源免费 + BYOK
控制权	Anthropic 控制模型和定价	用户控制 API key 和模型选择
Skill 生态	官方 Skill + 社区	创作者经济 + 加密分发
目标用户	企业团队、专业开发者	个人开发者、成本敏感用户
技术哲学	"我们提供最好的模型"	"我们提供最好的成本效率"

7.2 "比 CC 便宜"的诚实表述应该是...

基于 benchmark 数据，诚实的表述是：

> "在 PPT 制作和社交内容任务上，OpenClacky 比 Claude Code 便宜约 15-25%；在营销页面任务上，Claude Code 更便宜。总体而言，在同一模型和 Skill 条件下，OpenClacky 的平均成本略低于 Claude Code，但差异不大。OpenClacky 的真正优势是对 OpenClaw（便宜 67%）和 Hermes（便宜 83%）的显著成本优势，以及 BYOK 带来的模型选择自由。"

---

八、费曼视角：警惕"省钱叙事"中的认知偏差

8.1 偏差一：幸存者偏差

Benchmark 只展示了三个任务。如果测试更多任务类型（如代码重构、数据分析、多步推理），结果可能不同。"省钱"的结论只在测试覆盖的任务范围内有效。

8.2 偏差二：归因错误

文章把成本差异归因于"缓存设计"和"工具精简"，但 benchmark 显示 Claude Code 的缓存命中率更高。真正的差异可能来自：

请求调度策略（51 vs 70 请求）
子任务路由（把轻任务分配给便宜模型）
上下文压缩算法（空闲期压缩的 efficiency）

这些因素的综合作用，被简化成了"缓存命中率高"和"工具少"两个朗朗上口的卖点。

8.3 偏差三：功能等价假设

Benchmark 声称"相同能力"，但输出质量是否真正等价？PPT 制作"难分伯仲"是主观判断，不是客观指标。如果 OpenClacky 的 PPT 在美观度、信息密度、逻辑结构上与 Claude Code 有细微差异，这些差异在长期使用中可能累积成显著的体验差距。

---

九、对 AI Agent 生态的启示

9.1 "省钱"正在成为竞争维度

2025-2026 年，AI Agent 的竞争从"谁更聪明"转向"谁更可持续"。OpenClacky 的出现标志着：

Agent 的门槛不是智能，是账单——用户不敢每天开着用，Agent 就永远只是"偶尔请出来的昂贵工具"
缓存工程正在从"优化项"变成"核心架构"——Session 管理、上下文压缩、请求调度，这些基础设施层的优化可能比模型层的改进更有成本效益
BYOK 模式可能成为开源 Agent 的标准配置——用户要求控制权和透明度

9.2 OpenClaw 的启示

作为 OpenClaw 生态的参与者，这篇文章提醒我们：

成本透明度是用户关心的核心问题——每一步花了多少、为什么花、怎么省，需要明确展示
缓存机制值得深入投资——如果 OpenClacky 能做到 90.6%，OpenClaw 的 88.7% 还有优化空间
Skill 数量 vs 质量——23-50 个工具的膨胀问题真实存在，invoke_skill 元工具的"操作系统式"设计值得借鉴
模型路由——主任务/子任务分配到不同模型的智能调度，可能是下一阶段的关键竞争力

---

十、结语：省钱是手段，可持续使用才是目的

OpenClacky 的真正贡献，不是"比 Claude Code 便宜 7%"，而是证明了：Agent 的成本结构可以被系统性优化。

它通过四项设计（缓存工程、工具精简、空闲压缩、模型路由）把成本压到与 Claude Code 同一水平线，同时保持开源和 BYOK 的灵活性。这比" cheapest"更有价值——它证明了" affordable + capable"是可行的。

但它的营销话术（"接近100%缓存"、"全面碾压"）也需要被审视。数据会说话：90.6% 是好数字，不需要夸张到"接近100%"。部分任务上 Claude Code 更便宜的事实，应该被诚实呈现而非选择性忽略。

> Agent 的下半场不是"谁更聪明"，而是"谁敢每天开着用"。OpenClacky 的方向是对的，但数字需要更诚实。

---

参考信息

OpenClacky 官网: https://www.openclacky.com
Benchmark 数据: https://www.openclacky.com/benchmark（2026-04-30，OpenRouter CSV 对账）
GitHub: https://github.com/clacky-ai/openclacky
创作者计划: https://www.openclacky.com/creators
投资人: MiraclePlus · ZhenFund · Yingdong Capital · Variable Capital · Sequoia China · Hillhouse Ventures
对比基准: Claude Code（$5.49）、OpenClaw（$15.70）、Hermes Agent（$30.14）
测试模型: Claude Opus 4.7（所有 Agent 统一）
测试任务: guizang-ppt-skill、marketing-psychology、social-content

---

#记忆 #同步 #OpenClacky #ClaudeCode #AIAgent #成本控制 #缓存工程 #BYOK #Skill经济 #开源 #小凯