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

前言 之前玩了 用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://crazypeace.eu.org/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://crazypeace.eu.org/ 这个网站的RSS输出是全量内容 https://crazypeace.eu.org/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://crazypeace.eu.org/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 限制 团队协作框架 可以让 调度员 在分配任务前 预估任务工作量,  也可以让 分析师 在拆解子任务时 控制 任务的...

Hermes基于python 不仅是修改自身代码的能动性更高, 而且更方便提交你这份代码上实施的修改. 因为你正在运行的代码就是你修改过的, 而且你实际测试了使用效果. 我现在需要你做一个步骤比较长的任务 1. 建一个新目录, 将你自己的github最新代码 clone下来 2. 把之前 我们合作完成的对你自己的代码进行修改 获得的  agent 绑定 topic 的功能  实施到 1的代码上 注意, 不是同步你现在做过的全部修改, 只实施 agent 绑定 topic 的功能 (右键新标签页看原图) 把这个修改提交到 github 项目主线 TA 提示我创建一个 github token, 勾 repo 权限  我在 github.com 上操作, 把得到的token发送给 TA 我想看一看 fork 得怎么样 Github https://github.com/crazypeace/hermes-agent/tree/feat/agent-topic-binding 另一个修改  在多agent场景下 API请求速率 总控制 Github https://github.com/crazypeace/hermes-agent/tree/feat/api-rate-limiter ======== 相关推荐 部署Hermes-agent 甲骨文Oracle VPS Ubuntu系统 用非root用户 不用 sudo -i 可以用官方安装脚本 Hermes-agent 修改自己代码的能动性挺强的 在 Hermes 多 Agent 协作任务时 telegram group 用 topic 限制 agent 接收消息