ICDYCT / 我能, 你也行 / I Can Do, You Can Too

前言 上一篇我们测试了 Blogger API 的能力 ,  那么能拿TA干点什么呢? 技术的世界里, 英文使用者也是重要的组成部分. 那么, 把技术文章翻译成英文发布吧. 实践 问 hermes 用当前blogger api能看到我有几个blog吗? 答 问 hermes 在 https://zelikk.blogspot.com/   中找到 https://zelikk.blogspot.com/2026/03/cpa-cliproxyapi.html 翻译为英文, 发布在 https://icdyct.blogspot.com/ 注意, 所有 HTML 标签 保留 得到 https://icdyct.blogspot.com/2026/04/self-built-cpa-cliproxyapi-aggregating.html ======== 后记 完成这个任务时, hermes 对接的是 Nous Portal 提供的 免费的 stepfun/step-3.5-flash

前言 之前玩了 用LLM-WIKI技能分析博客文章之间的关系生成相关推荐 当时没有实现自动方案, 最终的修改是人肉手动的. 思路 Blogger 有 API 可以用. 在 AI "手把手"的陪伴下, 我启用了Blogger API, 设置了 OAuth 权限, 下载了 OAuth 凭据. 然后就开始让 hermes 来操作 blog 先简单测试了一下发布blog. OK 接着测试了一下修改blog, 尾部添加 "相关推荐". OK 实践 添加一些测试文章 接下来, 和 hermes说 假设你处于不知道 https://icdyct.blogspot.com/  上面已经发表了什么内容 的状态, 你做这样一件事情 遍历这个博客的每篇文章 如果文章的url是 表格中的 page, 那么在文章末尾添加以下表格中的 link1, link2, link3 这个表格是 | page | link1 | link2 | link3 | | 页面 | 链接1 | 链接2 | 链接3 | | 页面 |---|------|------|-----| | https://icdyct.blogspot.com/2026/04/test-4.html | https://icdyct.blogspot.com/2026/04/test-5.html | https://icdyct.blogspot.com/2026/04/test-6.html | https://icdyct.blogspot.com/2026/04/test-7.html | | https://icdyct.blogspot.com/2026/04/test-5.html | https://icdyct.blogspot.com/2026/04/test-6.html | https://icdyct.blogspot.com/2026/04/test-7.html | https://icdyct.blogspot.com/2026/04/test-8.html | | https://icdyct.blogspot.com/2026/04/test-6.html | https://icdyct.blogspot.com/2026/04/test-7.html | ...

在 Hermes 里面用多agent, 想共用 OAuth 认证   之前想的2个方案都需要修改 hermes 自己的代码   https://zelikk.blogspot.com/2026/04/hermes-agent-auth-json-api-key-refresh.html 改动有点大   我又想了一个完全不修改 hermes 代码的方案   还是 把 默认 agent 的 auth.json 复制到 各个 profile agent 工作空间下   但是把 auth.json 里面提示 api key / token 过期的时间推迟    这样, 各个 profile agent 就不会去更新 api key / token 再写个小程序, 跑成定时任务. 内容就是上面的操作 把 默认 agent 的 auth.json 复制到 各个 profile agent 工作空间下   但是把 auth.json 里面提示 api key / token 过期的时间推迟    其实有了上面这些信息, 已经足够你和 hermes 对话把功能实现了. 为了不让你行错步呢, 我再啰嗦一点具体的细节. ~/.hermes/auth.json 里面要修改的字段是带 expire 关键字的:  providers.nous.expires_at  OAuth token 过期 providers.nous.agent_key_expires_at Agent key 过期  credential_pool.nous[].expires_at 池中 OAuth 过期  credential_pool.nous[].agent_key_expires_at 池中 Agent key 过期  还有一些时间字段不是过期时间, 是获得时间, 所以不要动. 我让 Hermes 总结成skill了 Github https://github.com/crazypeace/hermes-auth-json-extend

前言 之前我们实现了一个 把 233脚本知识总结为wiki, 再提供telegram bot为用户使用界面 的SKILL 在实际使用场景中, 发现一些细节问题. 问题 问题1  bot的回复中指向了wiki中的页面, 而telegram用户是无法访问这些页面的 问题2 query工作未完成, 又来了@消息 bot 在 telegram 群组中工作, 而bot的查询wiki速度其实并不快, 是分钟级的. 很可能还在查询工作的时候, 又有新消息 @ bot 了. (上图是优化后的效果) 优化 问题1  优化 system prompt 你是一个 wiki 查询助手。只回答用户的问题，不要建议创建 wiki 页面、更新 index 或修改任何文件。 使用 wiki 内容完整回答用户问题，不要出现'请参考...'或'基于...页面'这类引导式语句。直接给出自包含的完整答案，必要时将引用内容自然地融入答案中。 回答结束后停止。 问题2  用线程池 做 query 工作 用数量为1的线程池 做 query 工作, 保证了 query 工作是串行的, 同时bot的主进程不被query工作阻塞, 可以正常获取用户 @ 的消息, 并 react. 为了简单可靠, 当 query 工作中时, 用户再 @ 的消息直接react 🙈, 并忽略. ======== Github https://github.com/crazypeace/hermes-skill-telegram-wiki-bots ======== 后记 一个小坑, telegram 不支持react  ❌ 这个 emoji. 我最后用了 🙈

前言 经常看到有些博客, 每篇文章尾部有个"相关推荐". 前几天 用到了一下LLM-WIKI技能 , 于是想用 LLM-WIKI 技能来分析我的博客, 也给每篇博文搞个相关推荐. 思路  把我的博客页面保存为WIKI页面, 用LLM-WIKI技能lint分析这些页面, 建立这些页面之间的连接, 统计所有页面的连接计数, 每个页面 连接的页面中, 找出连接数最多的3个页面. 实践 初始化wiki 找hermes (MIMO v2 pro 2026-4-21)聊了一聊 我准备做这么一件事情, 你帮我分析一下具体方案, 先不要实施, 先和我讨论 有一个网站 https://zelikk.blogspot.com/ 这个网站的RSS输出是全量内容 https://zelikk.blogspot.com/rss.xml 用你的 llm-wiki 技能新建一个WIKI 把这个网站的每一篇文章都 ingest 进入这个 WIKI lint 整理这个 WIKI,  并输出这样一些结果 1. WIKI 中的每个连接 是从哪个页面连接到哪个页面 2. 每个页面的 inbound连接计数 排名  inbound连接 - 一个页面被其它页面连接 3. 每个页面 outbound连接的页面中, 在 列表2 中计数最多的3个页面 和 这3个页面分别的计数 outbound连接 - 一个页面连接其它页面 整个开发交流过程涉及很多细节设计, 我就不一一列举了. 详见github 最终得到这么几份文件 1. 页面分配 index  index,page,pub_date,raw_url 1,hermes-python,2026-04-21,https://zelikk.blogspot.com/2026/04/hermes-python.html 2. 页面间连接列表 source,target 1,4 3. 单个页面的连接关系 rank,index,page,degree,neighbors 1,98,xray-vless-reality-tls-x25519,47,"29|43|74|102|103|131|132|133|144|147|149|150|153|154|155|157|158|160|162|173|174|181|19...

Hermes 用 telegram react emoji 表示工作状态 任务进度 眼睛 👀 表示看到了 拇指 👍   表示完成了 这和我在 Teams 中与同事合作一样. 为了避免工作群中充斥"收到"这类没有信息含量的打扰, 我要求同事 用 绿色对勾 ✅ 表示工作完成,  用 非绿色的对勾 ☑️ 表示"收到".  (为什么说非绿色呢, 因为在不同的系统中, 这个emoji有可能是其它颜色 -_,-  而且ios系统emoji用 "对勾"搜索, 出来的还有另一个✔️ ) 收到消息时 react emoji hermes config set telegram.reactions true

前言 基于前面 成功的多agent团队协作实验 , 我邀请群友给我一些TA们想到的小任务试试. 有人提供了一份这个 Build a premium interactive isometric 3D cozy room using Vite + React + Three.js (react-three-fiber/drei), with all objects modeled in code (no external assets) and subtle ambient animations. Users can click objects to smoothly focus the camera and reveal descriptions, delivering a polished, accessible, $50M-startup-quality WebGL experience. 问题 在开发过程中, 我发现当 agent-test 说 "测试报告已发送给 agent-watch。测试完成" 时, agent-watch 并没有收到报告. (右键新标签页看原图) 分析 我用默认 agent hermes 来分析这个事件, 避免上下文干扰. 分析结论是 结论：agent-test 达到了最大迭代次数限制，被系统强制停止了。它没有调用脚本，却在最终回复里声称"测试报告已发送给 agent-watch" — 纯属编造。 不是脚本问题，是 hallucination（幻觉） — 模型被强制要求给出最终回复时，虚构了"已经发送"这个事实。 既然是这个原因, 那么我进一步询问 同个原因是否造成虚假的测试项目结果? 分析结论是: 真实通过率大约是 10/19，而不是报告里的 19/19。 总结 我觉得这样的问题, 可以从两方面来优化. 一, 不要生成幻觉 / 虚假的结果 主要应该是 harness (openclaw / hermes / ...) 和模型来改进. 次要的, 团队协作框架可以试试看 有没有 针对性的 prompt. 二, 预先估计工作量, 避免触达 max_iterations 限制 团队协作框架 可以让 调度员 在分配任务前 预估任务工作量,  也可以让 分析师 在拆解子任务时 控制 任务的...