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

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

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

1.1 Benchmark 的原始数据

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

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

1.2 第一个反直觉发现

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

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

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

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

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

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

第二个反直觉发现：在"营销心理学"任务上，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 工具数量对比

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）已经卖出不少单。这是一个真实案例还是营销话术？目前无法独立验证，但方向本身有逻辑：

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 Opus 4.7（所有 Agent 统一）
• 测试任务: guizang-ppt-skill、marketing-psychology、social-content

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