Round 3 · 同模型同 prompt 的 1v1 实测

OpenClacky vs Pi Agent ——
同一份 PPT 任务，账单只要 65%。

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

OpenClacky clacky-ai/openclacky Pi Agent earendil-works/pi

Pi Agent 出自 badlogic（libGDX 作者）之手，是 GitHub 上 46.9k star 的完整 agent harness 单体仓库——含 coding agent CLI、统一多 provider LLM API、TUI / web UI 库、Slack bot、vLLM 部署。它强调 OSS session 公开可分享、self-extensible，定位是平台而非脚本。它「单轮轻量、小步多走」是明确的工程取舍——本页用同一份 PPT 任务，把这套设计哲学放在和 OpenClacky 同一坐标系下做实测对比。

结论先行 · 总成本

$1.18 vs $1.79

同一份 skill、同一个 claude-4.7-opus、同一份 prompt，OpenClacky 比 Pi Agent 省了 34%，且耗时只要 0.43×。两边都交付了 11 页结构同源的 PPT。

缓存命中率

90.7% vs 75.8%

请求轮数

14 vs 23

三句话事实

OpenClacky 缓存命中超高（90.7%）。 14 个请求里，13 个都命中前一轮的 prompt cache——这是同时省钱（账单 $1.18）和省时间（2 分 29 秒）的根本原因。
Pi Agent 单轮 token 更瘦（−40%）。 平均每次 prompt 只有 33.5k，比 OpenClacky 的 55.6k 轻，是它「小步多走、上下文精简」设计哲学的明证——单轮对模型更友好。
代价：cold start 长达 7 轮全 miss + 中段 6 次缓存中断。 账单贵 54%（$1.82 vs $1.18）。

实验设定

唯一变量是 agent 框架本身。

Skill

guizang-ppt-skill

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

模型

claude-4.7-opus

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

Prompt

10 页 AI Agent 趋势 PPT

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

测试时间

2026-05-09

两次实验同日执行，同时段同模型实例

查看完整 Prompt 摘要

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

查看原始 prompt.md →

执行过程录像

Process · Evidence

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

OpenClacky

≈ 3min

Pi Agent

≈ 6min

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

全部关键指标

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

指标	OpenClacky	Pi Agent	说明
请求数	14	23	调用底层模型的总次数
Agent 迭代轮次	11	23	本任务两边均 1:1 与请求数相等
任务总耗时	149s	342s	OpenRouter Σ generation_time（首请求到末请求）
总花费	$1.18	$1.79	OpenRouter 账单（含 cache 折扣）
Prompt tokens 总量	778,403	769,349	送入模型的所有 input token
Cached tokens 总量	705,787	582,868	命中 prompt cache 的 token
整体缓存命中率	90.7%	75.8%	Σcached / Σprompt
缓存中断次数	1	7	命中率 < 50% 的请求数（含冷启动）
每轮平均 prompt	55,600	33,450	单次请求送入的 token 体量
每轮平均输出	1,054	823	单次响应的输出 token 体量
每轮平均生成耗时	10.6s	14.9s	OpenRouter generation_time_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，除冷启动 1 轮外命中率全部 ≥ 86%，没有任何中途清空。代价是单轮 prompt 体量大、生成耗时偏长。

Pi Agent

23 请求

#1 3,249 0%

#2 5,786 0%

#3 5,962 0%

#4 6,137 0%

#5 6,856 0%

#6 7,044 0%

#7 10,735 0%

#8 11,987 90%

#9 12,122 0%

#10 12,376 97%

#11 14,314 84%

#12 27,138 44%

#13 45,614 32%

#14 46,108 31%

#15 47,303 97%

#16 47,915 97%

#17 47,915 99%

#18 67,074 71%

#19 68,111 70%

#20 68,576 98%

#21 68,724 99%

#22 69,090 99%

#23 69,213 99%

前 7 轮全部 0% 命中（cold start 期长），中段 #9 / #12 / #13 / #14 / #18 / #19 共 6 次命中率跌破 70%（其中 3 次跌到 30% 左右）。这是它「小步多走」设计哲学的直接代价——prompt cache 喜欢稳定累积的上下文。

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

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

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

上下文管理

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

OpenClacky

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

Pi Agent

「小步多走」策略下，cold start 长达 7 轮 0% 命中，中段又有 6 次命中率掉到 30–70%。优点：单轮 token 占用一直较小；代价：缓存利用率天然较低。

工具粒度

OpenClacky 提供较多内聚的专用工具；Pi 倾向于通过更多轮次的轻调用组合完成。

OpenClacky

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

Pi Agent

23 轮里 19 次 tool_use，每轮调用更轻、决策粒度更细。这与 Pi 强调 「session 可观测、可公开分享」的设计目标一致——细粒度的 step 更利于事后复盘和数据集化。

单轮负担

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

OpenClacky

单轮平均 prompt 55.6k，平均生成耗时 10.6s。每轮更慢、更重，但 14 轮就收工。

Pi Agent

单轮平均 prompt 33.5k，比 OpenClacky 轻 40%。单轮对模型更友好——这是 Pi 在「单轮负担」维度的真实优势。代价是需要 23 轮、且每轮重算成本更高。

稳定性

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

OpenClacky

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

Pi Agent

0 次输出截断、0 次错误，23 轮中 22 轮 tool_calls/stop，1 轮 finish_reason 为空（不影响结果）。

如何理解这组数据: Pi 用「单轮轻量 + 小步多走」实现了更小的单轮 token 占用和更细的 session 可观测性；OpenClacky 用「累积上下文 + 专用工具」拉满了缓存命中率和单次工具的信息密度。两条路径都做完了 PPT——但在按 token 计费、且大头由 prompt cache 命中率决定的现实下，OpenClacky 的 90.7% 命中率把账单压到了 Pi 的 66%。哪种取舍更合适，取决于你更在乎「session 可分享 / 单轮轻」还是「整体省 / 整体快」。

最终产物对比

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

OpenClacky 新标签打开

Pi Agent 新标签打开

缩略图为同步缩放预览。建议在桌面浏览器中查看，含 WebGL 双背景和动画。

小结

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

差异主要在过程：OpenClacky 用累积上下文 + 专用工具，14 个请求拿下任务、缓存命中率 90.7%、$1.18、2 分 29 秒完成；Pi 用轻量上下文 + 小步多走，单轮 prompt 体量更小，最终用 23 个请求、$1.79、5 分 42 秒完成。

需要尊重的是：Pi 是 GitHub 46.9k star 的完整 agent harness 平台，其设计目标包含「OSS session 公开分享」「self-extensible」「多 provider 统一 API」——「单轮轻量、小步多走」是这套设计的自然结果，不是 bug。在 prompt cache 计费模型下，"单轮轻"和"跨轮高命中"是相互拉扯的两个目标。

这是一组诚实的「设计取舍」对照：没有谁压倒谁，只有谁更适合什么场景——需要可分享 session 数据集 / 细粒度 step 复盘 / 多 provider 切换的场景，Pi 的工程价值不可替代；追求缓存命中率最大化、整体省钱省时间的场景，OpenClacky 的累积式调度成本更低。

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