2026-05-09

计划 45 岁攒够 100 万回老家开始退休生活，现在还差 130 万

说下我外甥吧，00 年的。

当年高考复读了两年，最后上了本科线。那时候年轻也比较叛逆，不太听家里人的建议，执意跑得远远的，去了新疆那边读了个二本，学的是网络相关专业。

24 年毕业回来后，应该也是知道现在行情不好，就开始考公了。毕竟还有个应届生身份，好像大四的时候就已经开始考了。

结果这一考，就考了 3 次。今年还是没上岸。

今年成绩出来后，本来五一都计划好来我这边玩的，后来也取消了。我都不敢想象他现在压力有多大。

现在也 26 岁了，还是 0 工作经验。相当于这么多年一直都在读书，后面又花了两年时间考公。专业估计也差不多荒废了，毕竟只是个普通二本。

他们老家是小镇上的，家里条件在镇上应该算中上吧。父母已经在市里买了房，不过还在镇上工作。他爸好像还是 67 年的，记得他爸 50 岁的时候就说想抱孙子了，那时候他确实也还小。

结果这一晃，他爸也快 60 了。

所以有时候我也会突然庆幸自己，毕竟没有生活在这个时代。早了 10 多年毕业，还赶上了互联网的末班车。

真的是：

时代的一粒沙，落在个人身上，就是一座山。

绩优，加薪 4%

最近看到一个出版社改错别字的视频，非常有趣。
最有趣的地方在于人们（包括我自己）发现自己错了的时候的反应。

先看错别字，以下词语里有错别字：

披萨
被弄懵了
不知所踪
睡眼朦胧
山青水秀


修改后，以下用字正确：

比萨
被弄蒙了
不知所终
睡眼蒙眬
山清水秀


这个视频不得了，弹幕一大堆问号，评论区争论了几千条，其中很多人无法承认错误，能看出来他们的情绪与抵抗。
其实这种现象在炒股论坛也很常见，例如雪球，可以看到很多人不肯承认错误、不肯接受事实。
字写错了，问题不大，但投资的认知错了，是真的会亏钱。因此这种现象是非常值得重视的，学会修正自己的认知，百利而无一害。

而想要修正自己的认知，第一步也是最难的一步，就是要愿意。这说来简单，但多数人意识不到这个问题，意识到了也一千一万个不愿意。想找理由找借口让自己逃离，不去面对错误，是非常容易的，很多人也是这样做的，而且会说 “我不是，我没有，从未发生过，不知道你在说什么！”

写在开头

FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟

友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资

想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？

• GitHub： https://github.com/juntao-ai/GenericAgent
• 论文： https://arxiv.org/pdf/2604.17091
• 教程： https://datawhalechina.github.io/hello-generic-agent/

---

1. 核心问题：Agent 为什么跑着跑着就变蠢了？

做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。

作者把这个问题归结为两个根本挑战：

挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。

挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。

这两个挑战的交汇点指向一个核心问题：LLM 的上下文到底应该塞什么？

---

2. 第一性原理：上下文信息密度最大化

GA 给出的答案是一个形式化的设计目标：

D(C) = 决策相关信息量(C) / 上下文总长度(C)  → max

翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。

这个目标拆开来看有两个维度：

• 完备性（ Completeness ）：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。
• 简洁性（ Conciseness ）：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。

作者提出了一个关键洞察：完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。

所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。

---

3. 为什么"上下文越长表现越差"——三重陷阱

这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式：

1. 位置偏差（ Lost-in-the-Middle ）：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。

2. 注意力稀释（ Attention Dilution ）：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。

3. 有效窗口远小于名义窗口：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。

这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。

核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。

---

4. GA 的系统性解法：四层信息密度优化

GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化：

4.1 最小原子工具集——减少"先天噪声"

工具定义是上下文中每轮都要重复支付的固定成本。GA 的策略是极端克制：只保留 9 个原子工具。

为什么不是越多越好？作者指出工具膨胀有两层代价：

• Prompt 层：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。
• Policy 层：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。

GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。

关键设计：code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。

code_run 本质上是图灵完备的！

实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。

4.2 分层按需记忆——只加载"当前需要的"

传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构：

层级	定位	是否 always-on	典型大小
L1 索引层	目录卡片，告诉 Agent "有哪些知识可用"	是	~200 token
L2 事实层	环境事实、用户偏好、服务器信息	否，按需 file_read	数百~数千 token
L3 SOP 层	标准操作流程、技能脚本	否，按需 file_read	每个 SOP 数百 token
L4 原始日志	完整对话历史，用于追溯和审计	否，极少访问	无限增长

核心机制：L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。

作者的消融实验验证了这个设计的有效性：

记忆配置	记忆大小（ token ）	任务成功率 TSR
No memory	0	52.44%
Full memory （全量注入）	575	52.44%
GA 分层记忆	165	66.48%

165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。

4.3 上下文截断与压缩——主动瘦身

即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理：

1. 工具返回值截断：code_run 输出超长时只保留头尾
2. 历史轮次压缩：早期对话轮次被摘要化
3. 消息驱逐：超出预算的最旧消息被移除
4. 工作记忆锚点注入：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失

第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。

4.4 反思驱动的自我进化——让未来的上下文更精炼

GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。

这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。

---

5. 架构实现：92 行的 Agent Loop

GA 的主循环只有约 92 行，结构是标准的 perceive-think-act：

while not done:
    context = assemble(system_prompt, always_on_memory, tools, history)
    response = llm.chat(context)
    if response.has_tool_calls:
        results = execute(response.tool_calls)
        history.append(results)
    else:
        done = True

整个系统由 4 个文件构成：agent_loop.py （主循环）、ga.py （工具实现）、agentmain.py （入口 + 前端适配）、llmcore.py （ LLM 调用封装）。总计约 3300 行。

这个极简架构的好处是：没有隐藏的复杂度。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。

---

6. 约束下的涌现：三个原语长出整个生态

这是 GA 设计中我觉得最有意思的部分。

传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。

GA 走了另一条路：不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。

三个基础原语

原语	本质	一句话描述
自托管 CLI 入口点	Agent 就是一个命令行程序	任何能调用命令行的程序都能调用 GA——包括 GA 自己
文件协议	目录约定的跨进程通信	input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止
反射模式	轮询 + 热重载	外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启

涌现出的高级行为

子 Agent 并行分发：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。

看门狗监控：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。

定时任务调度：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。

自主空闲行为：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。

为什么这能工作

这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的：当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。

关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。

作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事：当原语选对了，复杂行为不需要复杂实现。

---

7. Benchmark 数据

作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）：

指标	GA
总 Token 消耗	188,829
任务成功率（ TSR ）	66.48%

Token 消耗对比（同一组任务）：

系统	Token 消耗	相对 GA
GA	188,829	1x
Claude Code	538,207	2.85x
OpenClaw	633,498	3.35x

完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）：

系统	Full Prompt Length （ token ）
OpenClaw	43,321
CodeX	23,932
Claude Code	22,821
GA	2,298

---

8. 从 Prompt Engineering 到 Context Engineering

作者提了一个我觉得很有价值的视角转变：

• Prompt Engineering 优化的是"一句话怎么说"
• Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么"

在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。

GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。

---

9. 我的使用体感和局限

用了一段时间后的观察：

1. 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。
2. 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。
3. code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。
4. SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。
5. 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。

---

10. 总结

GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学：在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。

它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。

如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。

---

项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/

写在最后

在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！

贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。

我做出如下承诺： 1 、今后只写提示词，不写文章。 2 、在提示词中要求文章内容去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到：“余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。”

另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！

最后附上上面这篇文章的提示词：

欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！

原文： 在一个家族中第一个接触金融、股票、基金、债券、期货的人，看似是不务正业，实则是为整个家族完成了一场认知的提升， 这个不是赌博，更不是投机，而是选择成为资本流动的参与者，而非旁观者。 劳动能让你存活，只有资本才能让你自由。 可悲的是，很多人经常恐惧资本的风险，却坦然接受了通货膨胀和货币贬值以及意外事故和大病返贫的更大风险，多少人宁愿承受确定性的贫穷，也不敢面对不确定性的可能的财富。 如果你是家族中第一个敢吃螃蟹的人，那么你的孤独和试探实则是整个家族财务史上的转折点，是打破传统致富模式的尝试。 你建立的不只是一笔投资，而是一种心理遗传，是对复利的理解，是对风险的度量。 这条路的价值不在于你第一个账户的数字是多少，而在于从此以后家族后代面对财富时眼里多了一种选择。

这阵子，美股一顿涨，多少 v 友有不上班的念头了，确实跟之前 v 友说的似的，每次美股下跌就是给你加仓、定投的机会呀。v 友诚不欺我，感谢感谢。

纯 gpt5.5, 注册即有 5$额度，套餐低至 0.1 倍率， 欢迎体验： https://hyperapi.cc

以前只是听过很贵，没有买来吃过，现在倒闭了，更没机会吃上了。

之前的公司欠薪。投诉了社保、公积金。一审二审都打完，现在在走强制执行了。今天公积金中心打电话让我过去补缴公积金，公司已经把公积金补了。社保局之前打电话说不配合，让我过去签字移交稽核科，一直拖着没去。公积金我确定要去，但是社保局不知道去不去啊，五个月的社保，最低基数，让豆包算了一下，大概要补 2000+，退休后每个月能多拿 70-80 。大哥们出出主意啊！！

虽然这种应用已经很多了，但是在实际工作流里面，考虑到公司的要求，根本也不会弄那么多酷炫的效果。

还是老老实实按照公司的模板来调整，一页一页的做。

AI 实现的 PPT 这时候可用性就不太强。

也欢迎大家讲讲自己的实际体验看看？

去海鲜市场搜了下，发现最低 30 块的都有，感觉坑很多啊

有没有比官方便宜又稳得渠道？

目前是 149-50=99 ，啥都不送

https://solodev.cool/

Hi V 友们，我是李亚飞，ClackyAI 创始人，老 V 友。

上次给大家介绍过我们的云端版 ClackyAI （v2ex.com/t/1175020），主打"不懂技术也能从 0 做出可上线的产品"。这次发的是另一条线：我们把 ClackyAI 的内核完全开源，用 Ruby 原生重写成第三版架构，做成本地可用的通用 AI Agent —— OpenClacky 1.0，今天正式发布，100% MIT。

一句话定位：最省 Token 的开源 AI Agent ，能力对齐 Claude Code ，成本仅 Hermes 的 1/6 。

官网：openclacky.com

GitHub：github.com/clacky-ai/openclacky（求 Star ⭐）

一、为什么做这件事

现在用 AI 干活的人越来越多——不只是程序员写代码，做 PPT 、写营销方案、跑竞品调研、整理会议纪要、做日常办公自动化的人都在用。但用过一段时间，绝大多数人都会撞上同一堵墙：账单。

市面上不少"知名" Agent 是结构性的吞金兽——一个完整任务下来 30 美金不算夸张。问题往往不在模型本身，而在 Agent 的 Harness 工程：Cache 设计不合理、工具集膨胀、压缩破坏缓存、上下文反复重建。每一层都在悄悄烧钱，用户却只能在月底被账单教育一次。

OpenClacky 的取舍从第一天就很明确：把"省 Token"做成顶层 Harness 设计目标，而不是事后做的优化补丁。前两代架构（第一代 RAG 、第二代云端多 Agent ）我们踩过很多坑，最后得出的结论是——用户想要的只是把任务又快又好地完成，最好的架构不是盲目追求多 Agent 和复杂编排，而是在单 Agent 上把效果和成本控制做到极致。

第三代架构因此诞生：Ruby 从零重构，历时三个月，围绕 Cache 、工具集、压缩、自进化等七个核心决策重新设计——这就是今天的 OpenClacky 。

架构做完了，效果到底怎么样？我们花了十多天做横向评测，把市面主流的几个 Agent——Claude Code 、OpenClaw 、Hermes——拉到同一条起跑线。统一用 claude-opus-4-7 作为底层模型：这是目前最强、单价也最贵的模型，最容易暴露各家 Harness 的真实水平，省一点点都是真金白银。

二、直接亮数据：3 个任务横评 4 家 Agent

如前面说的，统一用 claude-opus-4-7 作为底层模型；同 prompt 、同 skill 、同时间段，4 家 Agent 跑同样 3 个真实任务：

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

一句话总结：51 个请求 + 90.6% 命中率 → $5.10 ； Hermes 218 个请求 + 60.3% 命中率 → $30.14 。

数据来源：OpenRouter 逐请求账单 CSV。不是我们自己的日志，是第三方账单。

→ benchmark 总览页：openclacky.com/benchmark

---

三、三个任务评测实战（带 prompt 、产物、全程录屏）

写代码自不在话下，评测的 3 个任务，是最常见的日常办公/创作场景：

第一个：10 页商务 PPT （ AI Agent 行业趋势汇报） /benchmark/guizang-ppt-skill OpenClacky **$1.23** · Claude Code $1.45 · OpenClaw $5.07 · Hermes $10.96

第二个：AI 客服 SaaS 营销方案 + 可运行官网首页（双交付） /benchmark/marketing-psychology OpenClacky $1.72 · Claude Code **$1.20** · OpenClaw $7.47 · Hermes $4.65 （这一项 Claude Code 胜出）

第三个：B2B SaaS 竞品分析 + 一周社媒内容日历（ 6 步流水线） /benchmark/social-content OpenClacky $2.14 · Claude Code $2.84 · OpenClaw $3.15 · Hermes $14.53

每个落地页都包含：原始 Prompt 全文、四家原始产物、全程屏幕录像、逐请求数据表。一切都摆出来，不藏着。

---

四、坦白说几句，欢迎来挑战

离 "Claude Code" 还有多远，先把几件事说清楚：

1. Claude Code 在 cache 命中率上（ 95.2%）确实比我们高（我们 90.6%），这是世界顶级的闭源 Harness ，另外它内部有自动切换 haiku 模型的能力，会让它的成本优势相对明显。我们的优势是在 请求数 × 命中率 的乘积上更优，且完全开源、可自托管、BYOK。新的 1.0.1 版本已经在实际使用做到接近 100%的命中率。
2. 打个小广告：如果你使用 OpenClacky AI Keys 自托管方案，也可以享受子任务自动切便宜模型的特性（无须手工配置）
3. 欢迎你来挑战：
   • 装好 OpenClacky ，用你自己的 OpenRouter Key
   • 跑 benchmark 页面里的同款 prompt
   • 对比账单 CSV
   • 跑出比我们便宜的，欢迎 PR ；跑出我们更贵的，提 issue 我们改

---

五、凭什么这么省 —— 4 个 Harness 工程决策

不是"砍功能换省"，是每一层都做对了选择。这里挑 4 个最关键的讲，更完整的 7 条决策见技术内幕。

① 始终追求 100% Cache 命中 Session 全程 system prompt 永不重建，动态变化的内容（ Skill 列表、模型切换）以独立 [session context] 块插入，不破坏缓存断点；同时对最后 2 条消息双重打 cache_control，避免 N+1 轮时标记错位。绝大多数 Agent 一遇到 Skill 重载就重启 session 、所有缓存全部失效——这个代价我们降为零。

② 最小工具集：一切皆 Skill 核心工具仅 16 个（ Claude Code 40+ / OpenClaw 23 / Hermes 52 ）。靠 invoke_skill 这个元工具把所有复杂能力外包给 Skill 生态：sub-agent 调用、代码库探索、记忆召回、定时任务……全都在核心工具列表之外。工具数量不是竞争力，任务完成率才是。 用户安装新 Skill ，工具数不增、schema 不变、cache 不受影响。

③ Insert-then-Compress：压缩本身也命中缓存 常见做法是新开一个 LLM 调用做压缩——这会让所有已建立的 cache 全部失效。OpenClacky 把压缩指令直接插入当前对话流，在下一轮正常请求时顺带完成。压缩的 cache 天然复用，成本接近零。

④ BYOK ，模型渠道你挑 任意 OpenAI 兼容 API 即插即用。主任务 Claude 、子任务 DeepSeek ，再省一截。

六、关于 Ruby 重写

可能有朋友会问：做 AI Agent 不是 Python 的天下吗，怎么用 Ruby ？

第一代和第二代我们用的就是 Python 。迭代到第二版之后，Agent 的瓶颈在 LLM 调用而非语言性能这一点已经很清楚——决定一个 Agent 跑得好不好的，是 Harness 层的架构设计，不是底层语言的执行速度。

第三代用 Ruby 重写，主要是为了 Harness 工程的表达力：DSL 和元编程让 Session / Cache / Tool 三层关系写起来更顺，工具/Skill 系统的边界也更容易划清楚。前两代踩过的坑，反过来催生了这次架构层面的清算式重写——三个月，从零到一，做出了今天这个内核。

---

七、不止省钱 —— 这是一个完整的 Agent 工作平台

OpenClacky 不是只有一个跑得快的 Agent 内核，配套的是一整套日常工作流要用的能力：

• Web UI + CLI 双形态：Web UI 用浏览器进入，左侧会话列表 / 中间对话 / 右侧产物预览，零命令门槛；终端党直接 openclacky 进入对话模式，是 Claude Code 的开源替代
• Skill 技能库：官方内置 commit / deploy / pptx / browser-setup / cron 等一批，一行 /skill-add <url> 装社区 Skill
• Skill 自进化：每次任务结束 Agent 自己评估，值得沉淀的工作流自动写成新 Skill ，已用的 Skill 也会反写优化（仅修改用户自建 Skill ，不动官方）
• 长期记忆：关键决策/偏好自动持久化到 ~/.clacky/memories/，按相关性召回，不污染上下文
• 定时任务：自然语言描述，自动生成 cron
• IM 集成：飞书 / 企微 / 微信 直接 @ 召唤
• 浏览器自动化：驱动真实 Chrome / Edge 操作网页
• 三级权限控制：从逐步确认到完全自动三档可切，破坏性操作有护栏

完整功能：openclacky.com/features

---

八、谁用谁省 —— 几类典型场景

🛠️ 程序员 / 开发者 CLI 形态直接替代 Claude Code ，BYOK 用自己的 Key ，月底账单直接砍掉一大半。.clackyrules 自动加载项目规范，三级权限控制，diff 预览，跟 Claude Code 该有的都有。

🚀 Indie hacker / 副业开发者 同样的 200 美金预算，原本只够跑 1 个项目，现在能跑 6 个 —— 试错速度直接 ×6 。

📊 一人公司 / 自由职业者 做客户提案、写咨询报告、出竞品分析、整理材料 —— 原本一个月 AI 账单 $300 现在 $50 ，省下来的就是利润。

💼 行业从业者（市场 / 运营 / 销售 / HR / 律师 / 咨询） 日常做方案、写分析、整理资料 —— 每个任务从 $5 降到 $1 ，配合 Skill 库基本不用自己写 prompt 工程。

⚙️ 极客 / 重度 AI 用户 Web UI + CLI + 定时任务 + IM 集成 + 浏览器自动化 + Skill 自进化 + 长期记忆 —— 想搭多复杂的个人工作流都能搭。

简单粗暴的算账：每天 10 个任务，省下来的 Token 钱，一年就是几万刀。

---

九、怎么上手

桌面安装包（推荐，最省心）

• macOS / Windows / Linux 三平台
• 双击装完，环境/依赖/Skill 全自动就位

命令行（熟手）

• 一行命令安装
• openclacky 进入对话模式

模型怎么接

• 自带 Key 完全免费（任意 OpenAI 兼容 API ）
• 想省心也可以用 OpenClacky Keys （直连官方、99% 缓存命中、官方同价）

下载与文档：openclacky.com

---

十、最后

V 站老规矩：欢迎来拍砖、提 issue 、Star 支持。

特别欢迎跑你自己的真实任务来挑战 benchmark —— 跑得比我们便宜的，我们公开认；跑得比我们贵的，我们当 issue 修。

GitHub：github.com/clacky-ai/openclacky 官网：openclacky.com 评测：openclacky.com/benchmark

有想深度交流的朋友，V 站私信我，或者直接 GitHub issue 。

我的背景是 Web 开发，目前属于单干吧，电商为主，

最近利用 ESP32 做了一些产品，但是苦于后期无法击败华强北，发现 ESP32 还是太贵， 采样发现华强北那边用的基本都是杰里，降低 BOM 成本这种， 但是离开了开源世界真的好难受~！

我之前 Java 为主，所以早就习惯了开源时间，嵌入式实现低 BOM 成本我应该外包吗？ 我连个现代点的嵌入式论坛都找不到。

嘉立创我是跑通了, PCB SMT 这些的.

我现在拥有便携式示波器，烙铁，风枪，和一些兼职工人，也有很多 3d 打印机， 但是都是入门水平，头疼，自己学感觉时间成本比较大，毕竟电商很多事情 ... 我的主要工作是选品.

感觉硬件圈子比较适合我这种调包侠的就是 ESP 生态了,离开了我好想什么都不会,毕竟我底层一窍不通

以前我是个非常喜欢阅读各类书籍的人

直到一年前，自己用 n8n 搭了一个 AI 阅读的工作流，把 PDF 输入进去，AI 给我一段 1500 字的总结

刚开始效果非常好，有时候兴致上来了一天就能看 5 本这种 AI 嚼烂的内容

最近我突然发现我看见长文的时候会下意识滑走，甚至刷 v 站都会顺手用 ai 插件总结一下再看

我好像失去了什么，但是暂时还不清楚具体是什么

大家有这种感觉吗

此前没有 gg 卡，五一节后 codex 端登录账号（多个账号中的其中一个，bug 价充的一个月 plus ）发现弹手机号验证了。

现在买一张 gg 卡激活后用来接码是否有必要

家庭的所有开销都能像公司一样走流程化报销 是不是能让各项开销透明化 显著减少无用支出

这玩意入侵性越来越强，全是狗皮膏药，甚至还入侵文本框，设置也越来越复杂，很难关。

需求很简单，支持 openrouter 即可。