ytyyt

同为 agent 从业者，看完这篇认真读了两遍。几个点说说我的理解：

市面上大多数 Agent 产品的营销重点都放在"能做什么"，很少有人把 Harness 层的工程决策拿出来往清楚讲。cache 命中率、工具集大小、压缩破坏缓存这些细节，真正用本地 agent 跑复杂任务的人都会懂——账单是真实的痛。

"Insert-then-Compress"这个设计我觉得是文章里有意思的一点。把压缩指令插进当前对话流而不是新开 LLM 调用，避免了 cache 失效，又几乎没有额外成本，这是典型的"做对了一件小事，但复利效应很大"的工程决策。很多团队不是不知道，而是在原有架构上打补丁补不进去。

Ruby 重写的理由我觉得合理。最开始看到 Ruby 我也下意识觉得奇怪，但"Agent 瓶颈在 LLM 调用而非语言性能"这个判断是对的，DSL 和元编程确实更适合描述 Session/Cache/Tool 三层关系，选语言的逻辑是清醒的，不只是情怀驱动。

一个小疑问：benchmark 里 Claude Code 在 cache 命中率上（ 95.2%）高于 OpenClacky （ 90.6%），文章解释是闭源 Harness + 自动切 haiku 的优势。但如果 OpenClacky 在新版本里命中率也接近 100% 了，那总成本对比会更有说服力，期待后续公布更新后的数据。

开源 + MIT + BYOK 这个组合对独立开发者和小团队来说确实实在。去 star 了，准备上手试试，后续持续关注。