jolestar

现在 AI 类应用上市场都需要一个举报入口，但 holon 这种自部署的 Agents 服务，客户端是用户自己服务的远程入口，怎么弄这个举报呢？举报到哪里去呢？毕竟数据都在用户自己的设备上。有没有这方便有经验的朋友说说如何处理的。

OpenAI 的并发限制越来越严格了，老 429 错误，被迫改进 holon 的重试策略，给 OpenAI 增加专门的冷却等待机制。按这个限制，感觉 200$ 套餐用不完呀，我还攒了两个 resets 😂。

假期带娃自驾游，适合一家四口的酒店太难找，大多都是两大一小的房间。发现只有电竞酒店有四人间，于是试了一晚，带两个娃打了一晚上魔兽争霸冰封王座。一排电脑桌，两张高低床，恍惚间似乎回到了大学时候。

感觉 deepseek 也不便宜呀，我主力是 gpt 20x 和 glm 20x，deepseek-flash 主要做 fallback。难道是这两货经常服务超载，所以最后 deepseek 默默承担了？😅

Holon(@holonrun) 源于我自己日常使用 AI Agent 时的几个真实痛点，从一个满足自用的小玩具，变成了我每天都在用的主力系统。但它离成熟的通用工具还有不少距离。
如果你对这种长驻、异步、由工作项驱动的 Agent 感兴趣，非常欢迎体验并给我反馈。

给 Agent 调度系统加一个小决策模型
测了一下 Jev，又把我前段时间想给 @holonrun 做的语义调度系统捡了起来。
当时重构 Holon 的调度系统，目标是让 Agent 可以像人一样，在多个工作项之间切换：一个工作项需要等待外部流程时，就先切到另一个工作项继续执行。
但遇到了一些难题，Agent 收到一个输入后，系统很难只靠静态规则判断：
* 这个 GitHub event 应该插入当前 turn，还是进入队列？
* 它和哪个工作项有关？
* Agent 处于 sleep 状态时，是否应该被唤醒？
* 一个已经过期的后台任务结果，是否可以直接丢弃？
这些问题本质上不是普通的状态机判断，而是语义判断。每次都调用一次 LLM，成本和延迟又太高。当时我想自己训练一个分类器来处理这些判断，但训练结果不太理想，模型有点保守，为了避免出错不下结论。也可能是我自己的数据量太小，于是最后作罢，只留了一个 hook，没有真正实现。
Jev 这种专门做小决策的模型，刚好适合放在这里。昨天试了一下，效果比预期好，所以我准备重新启动这个方案，再测试观察一段时间，后面再出个详细的报告给大家。
我感觉各大厂很快会跟进这种方案，估计各家都会带一个专门的 Decision Model，用来处理这类场景。

Agent 写了个脚本，在后台启动。结果 while 循环里忘记给增加游标，弄了个死循环出来，输出把磁盘打满，然后把自己弄挂了😅。这种似乎 harness 里也不好防。

郭德纲改红歌被罚款事件的一个副作用是很多音乐服务都在下架红歌，谁能保证自己的版本是没改过的呢？😅

暑假里给两个娃电脑上都装了 Coding agent，我观察他们怎么玩。
哥哥有 Scratch 编程经验，有自己的想法，做过一些有创意的 Scratch 游戏。他玩了几次后就放弃让 AI 直接生成应用了，主要理由是 AI 生成的不是他想要的，他脑子里的想法给 AI 也说不清楚。还有，他感觉 AI 做的东西不是自己做的，找不到创造的感觉。
他最后的做法是让 AI 修改他的 Scratch 文件。Scratch 是拖拽式编程，文件格式不是给纯文本编辑设计的，AI 改起来很吃力。但他玩得也自得其乐，还让 AI 帮他做 Scratch 多人联机。我说 Scratch 已经限制了他的发挥空间，但他还是觉得生成的东西自己能看懂会更有掌控感。
弟弟还没有形成那么明确的创作目标，更容易接受 AI 给出的结果，生成啥玩啥，但又很难定义他在学编程。
AI 时代还需要学编程吗？如果要学，学的到底是什么？哥哥要的是掌控和创造的感觉，弟弟享受的是结果本身——哪一种才算"在学编程"，我也一直在思考这个问题，下次单独写写。

用多了 AI 后发现自己不太爱说话，包括网上，好久没发过推了。
以前古法编程，代码写多了会觉得憋的慌，于是会写写文章，群里唠嗑。但用了 AI 后，写代码就是唠嗑了，输出的配额似乎被用完了，没有输出的欲望了。
和人聊天也没有了耐心，刚聊两句，我就想说：“你还是去和 AI 聊一下吧”，或者 “我还是去和 AI 聊下吧”。
但这样久了感觉也不对，尤其是居家编程，整天也没人交流，网上不活跃就和隐居似的。后面要逼迫自己活跃一下，或者组织一些线下的交流活动了。

GPT 的订阅莫名其妙被 Google play 取消了，现在 android 版本的 GPT 上似乎么有订阅入口了？有人遇到类似的问题吗？

holon v0.19.0 发布了
这个版本 内置了一套 web UI，同时也把底层存储系统重构了一遍，api 和 event 系统重构了一遍，填了许多 AI 挖的坑。
原来用的是 JSONL，数据量大了后就很难维护。叠加上 AI 编程习惯是 grep 然后发现没有就加，导致有很多 api 和 event 冗余。
于是全弄到 sqlite 数据库中了，结果没想到积累到数据已经很大了，数据库超过了 4G，遇到了性能问题，于是继续优化，现在这个版本算稳定了。
欢迎大家尝试，Web UI 略微简陋，但 holon 的模式是同一套接口，支持 tui 和 web ui，看到的 agent 的视图是一致的。

codex device token 登陆突然要验证手机号了？并且发现 openai 的手机号在账户设置里找不到呀？改都似乎没地方改。

Agent 需要什么样的基础工具集合
看到大家在聊 Agent 工具集的问题——是不是提供一个 shell 就都搞定了？做了 holon 之后发现，其实没有那么简单。
读：为什么放弃了 Read/Glob，全走 shell
holon 的工具集改了几个版本，最后废弃了类似 Claude Code 提供的 Read（读文件）、Glob（模式搜索）这类专用工具，读取和查找全部通过 shell 来完成。这和 Codex 的路线一致——Codex 的 ExecCommand 一把梭，读文件就是 cat，搜代码就是 rg，不再单独给每种"读"操作定义一个工具。
这样做的理由很朴素：shell 是 LLM 最熟悉的"编程语言"。与其让模型去学你定义的 Read 工具的参数语义，不如直接让它写已经训练了几十亿次的 shell 命令。每多一个专用工具，模型的认知负担就加一层；而 shell 这个界面，模型已经足够熟练了。
但全走 shell 有一个代价：输出截断。框架为了避免 shell 返回值太长撑爆上下文，会给每个命令设输出上限。Agent 用 cat 读一个大文件，可能只拿到前半截，剩下的在 artifact 文件里，还得再 cat 一次甚至多次才能读完。Claude Code 的 Read 工具压缩阈值比通用 shell 高很多，读大文件一步到位，少了好几个来回。本质上是取舍：少定义工具降

和 gpt 交流多了后，自己也习惯用“收口”这个词了。一些任务完成后，但还有一些零碎的事情没搞，告诉它把剩下的事情收口，感觉很自然。我都忘了不用收口这个词之前是咋表达的😅。