Round 2 · 同 skill 同模型同 prompt 的 1v1 实测

OpenClacky vs Generic Agent ——
同一份 PPT 任务，两种调度风格下的真实数据。

同一个 guizang-ppt-skill、同一个 claude-4.7-opus、同一份 prompt，唯一变量是 agent 框架本身。两边都成功交付了 11 页 PPT，本页把过程数据一次性铺开，不下结论谁好谁坏，由你看完后自己判断。

OpenClacky clacky-ai/openclacky Generic Agent lsdefine/GenericAgent

Generic Agent 的设计目标就是 「从 3.3K 行种子自演化出技能树，以 6× 更少的 token 消耗实现全系统控制」（README 原文）。它的轻量上下文不是 bug，是核心设计意图。本页用同一份 PPT 任务，把这套设计哲学放在和 OpenClacky 同一坐标系下做实测对比。

结论先行 · 总成本

$1.18 vs $1.82

同一份 skill、同一个 claude-4.7-opus、同一份 prompt，OpenClacky 比 Generic Agent 省了 35%。两边都交付了 11 页结构同源的 PPT。

缓存命中率

90.7% vs 73.6%

请求轮数

14 vs 22

三句话事实

OpenClacky 缓存命中超高（90.7%）。 14 个请求里，13 个都命中前一轮的 prompt cache，调度器把上下文累积起来重复使用，是省钱的主因。
Generic Agent 单轮 token 更少（−45%）。 平均每次 prompt 只有 30.8k，比 OpenClacky 的 55.6k 轻 0.55×，单轮生成也更快——它的「轻量上下文」设计目标在数据上确实做到了。
代价：中途 3 次缓存被打断（#10 / #15 / #20）。 这三次命中率直接掉到 0%，让 22 轮总成本反而高过 14 轮——「单轮轻」和「跨轮高命中」在 prompt-caching 计费模型下是相互拉扯的两个目标。

实验设定

唯一变量是 agent 框架本身。

Skill

guizang-ppt-skill

两边载入同一份 skill，结构产物完全同源

模型

claude-4.7-opus

两边整轮 100% 使用同一模型，无混用

Prompt

10 页 AI Agent 趋势 PPT

面向企业决策者，深色科技商务风

测试时间

2026-05-09

两次实验间隔 ~2 分钟，同时段同模型实例

查看完整 Prompt 摘要

任务：使用 guizang-ppt-skill 制作《2026 年 AI Agent 行业发展趋势：企业智能化转型的战略新范式》PPT。
受众：企业负责人 / 中高层决策者（关注 ROI、降本增效、组织变革）。
时长：20 分钟。篇幅：≤10 页。风格：高端、简洁、商务、科技感。
内容大纲：封面 / 核心论点（Copilot→Agent）/ 市场驱动 / 多智能体协同 /
行业落地 ROI / 架构演进 / 治理红利 / 风险挑战 / 4 季度路线图 / 结语。

查看原始 prompt.md →

执行过程录像

Process · Evidence

建议带着这两个观察点看：（1）agent 在每一轮做什么粒度的决策；（2）有没有反复读同一文件的瞬间。

OpenClacky

≈ 3min

Generic Agent

≈ 4min

录像由 2026-05-09 实测产生，可与 OpenRouter CSV 中的时间戳逐条对齐。

全部关键指标

全部数据来自 OpenRouter activity CSV 逐请求核算 + session 元数据。无估算、无平均值粉饰。

指标	OpenClacky	Generic Agent	说明
请求数	14	22	调用底层模型的总次数
Agent 迭代轮次	11	22	openclacky 来自 session.stats；generic 即请求数
任务总耗时	168s	220s	从首请求到末请求的真实时间
总花费	$1.18	$1.82	OpenRouter 账单（含 cache 折扣）
Prompt tokens 总量	778,403	677,409	送入模型的所有 input token
Cached tokens 总量	705,787	498,294	命中 prompt cache 的 token
整体缓存命中率	90.7%	73.6%	Σcached / Σprompt
缓存中断次数	1	5	命中率 < 50% 的请求数（不含正常冷启动）
每轮平均 prompt	55,600	30,791	单次请求送入的 token 体量
每轮平均输出	1,054	828	单次响应的输出 token 体量
每轮平均生成耗时	10.6s	8.0s	OpenRouter generation_time_ms
每轮平均首 token 时延	1560ms	1111ms	OpenRouter time_to_first_token_ms
输出截断次数	0	0	finish_reason = length 的请求数
错误次数	0	0	finish_reason = error / content_filter

绿色表示在该指标上数值更优，灰色表示无明确「更优」方向（如 token 体量本身不带好坏）。

逐请求时间线 · 「缓存中断」如何发生

横条长度 = 该轮 prompt token 体量，颜色 = 该轮缓存命中率。一旦颜色变红，意味着 agent 的上下文被重置，前几十 k token 的缓存收益归零。

OpenClacky

14 请求

#1 13 0%

#2 21,363 0%

#3 40,959 52%

#4 55,665 74%

#5 56,470 99%

#6 57,015 99%

#7 57,922 98%

#8 67,509 86%

#9 68,421 99%

#10 69,055 99%

#11 70,068 99%

#12 70,287 100%

#13 71,459 98%

#14 72,197 98%

曲线一路稳步累积到 72k，除冷启动外 命中率全部 ≥ 86%，没有任何中途清空。代价是单轮 prompt 体量大、生成耗时偏长。

Generic Agent

22 请求

#1 4,883 0%

#2 5,627 87%

#3 11,553 49%

#4 13,899 83%

#5 16,523 84%

#6 18,190 91%

#7 24,390 75%

#8 30,226 81%

#9 40,607 74%

#10 33,309 0%

#11 40,536 82%

#12 42,591 95%

#13 46,429 92%

#14 48,221 96%

#15 29,459 0%

#16 31,334 94%

#17 33,257 94%

#18 37,223 89%

#19 47,005 79%

#20 38,028 0%

#21 40,945 93%

#22 43,174 95%

请求 #10 / #15 / #20 出现 3 次明显的上下文重置（命中率从 90+% 跌到 0%），其中 #15 的 prompt 体量从 48k 直接降到 29k（−39%）。这是它能维持每轮 prompt 体量较小的代价。

≥ 80% 命中 50–80% 命中 < 50% 命中（含冷启动 / 上下文重置）

技术特点（双方各自的取舍）

两套框架各自做了不同的设计取舍，本节用本次数据可证的事实来对照——不下"哪个更好"的结论。

上下文管理

两边对「上下文累积 vs 主动收敛」的态度是镜像的，结果是两端不同的成本曲线。

OpenClacky

持续累积上下文，14 轮内 prompt 单调增长 13 → 72k，整轮命中率 90.7%。优点：缓存收益最大化；代价：单轮越往后越重。

Generic Agent

运行中出现 3 次明显的上下文重置（#10 / #15 / #20），将 prompt 缩到 ~30k。优点：单轮 token 占用稳定；代价：每次重置都让此前的缓存归零。

工具粒度

OpenClacky 提供较多内聚的专用工具；Generic Agent 几乎只靠 file_read / code_run / file_patch 三件套。

OpenClacky

13 次 tool_use，分布在 file_reader / edit / glob / grep / write 等专用工具上。单次工具调用拿到的信息量更高，因此 14 轮就完成。

Generic Agent

24 次 tool_use 集中在 file_read×11、code_run×8、file_patch×4。11 次 file_read 反映出反复确认中间文件——通用工具在「多次读同一文件」时没有捷径。

单轮负担

「单轮轻、多轮多」 vs 「单轮重、多轮少」是这次最直观的差异。

OpenClacky

单轮平均 prompt 55.6k，平均生成耗时 10.6s，TTFT 1560ms。每轮更慢、更重。

Generic Agent

单轮平均 prompt 30.8k，平均生成耗时 8.0s，TTFT 1111ms。每轮更轻、更快——这是 Generic Agent 的真实优势。

稳定性

两边在本任务都没有触发任何崩溃路径，质量层面无差异。

OpenClacky

0 次输出截断、0 次错误，14 轮全部 finish_reason=stop。

Generic Agent

0 次输出截断、0 次错误，22 轮全部 finish_reason=stop。

如何理解这组数据: Generic Agent 用「轻量上下文 + 通用工具」实现了更小的单轮 token 占用和更短的单轮延迟；OpenClacky 用「累积上下文 + 专用工具」拉满了缓存命中率和单次工具的信息密度。两条路径都做完了 PPT，本任务中 OpenClacky 在请求数（−36%）、总成本（−35%）、缓存命中率（+17pp）三项上数值更优；Generic Agent 在单轮 prompt 体量（−45%）、单轮生成耗时（−25%）两项上数值更优。哪种取舍更合适，取决于你愿意在「单轮快」和「整体省」之间偏向哪一端。

最终产物对比

两边产物结构同源（同一份 skill 模板：11 页、双 canvas 背景、相同字体）。点击任一缩略图打开完整 PPT。

OpenClacky 新标签打开

Generic Agent 新标签打开

缩略图为同步缩放预览。两份产物均含同一 skill 自带的 motion.min.js 与 WebGL 双背景，建议在桌面浏览器中查看。

小结

同一份 skill、同一个 claude-4.7-opus、同一份 prompt，两边都交付了 11 页结构同源的 PPT，质量层面的可见差异极小。

差异主要在过程：OpenClacky 用累积上下文 + 专用工具，14 个请求拿下任务、缓存命中率 90.7%、$1.18 完成；Generic Agent 用轻量上下文 + 通用工具，单轮 prompt 体量更小、单轮更快，最终用 22 个请求、$1.82 完成。

需要尊重的是：Generic Agent 的「轻量上下文」是它明确的设计目标（其 README slogan 即"6× less token consumption"）。本任务中它单轮平均 prompt 是 OpenClacky 的 0.55×（30.8k vs 55.6k），这一点上它确实做到了——只是在与 prompt cache 配合时，"轻量"和"高命中率"是相互冲突的两个目标。

这是一组诚实的「设计取舍」对照：没有谁压倒谁，只有谁更适合什么场景——长任务、需要回到早期上下文的场景，OpenClacky 的累积式调度成本更低；短任务、希望单轮响应紧凑的场景，Generic Agent 的轻量式调度更省单次延迟。

所有原始数据（OpenRouter CSV、session JSON、录屏）都已附在本页，欢迎自己核对，也欢迎访问 Generic Agent 的 GitHub 看作者本人的设计阐述。