Ai-Agent

受够了 OpenClaw 的失忆，我本周爱上了 Hermes Agent 大多数人以为 Hermes 只是一个 AI 聊天框架。但它实际上是一个可长期运行、多角色协作、多入口接入的 Agent Runtime，已经非常接近真正意义上的 AI Operating System。 Hermes Agent 在不到三个月内突破 14 万 GitHub Star，并根据 OpenRouter 的数据成为目前全球使用量最大的 Agent。在折腾了 2 个月，受够了 OpenClaw 的失忆后，我尝试用业界火热的 Hermes Agent，效果居然出奇的好，因此写下这篇安利文章。 关键词：#openclaw #Hermes 能力标签：多Agent协作 · 长期记忆隔离 · 子代理并行 · 多用户隔离 · 任务编排 · Agent Runtime 为什么这么火？三个根本原因 1. 解决了 Agent 领域最痛的问题——失忆 Hermes 要解决的正是这个问题，不是用 prompt 技巧，而是在架构层面内置了一个闭环学习机制——运行时间越长，它就越了解你。 2. 自我进化的技能系统 Hermes 有四个核心差异化能力，其中最突出的是"自进化技能"——它会自己编写并优化 skill 文档。每当 Hermes 解决一个困难问题，它就会写下一份可复用的 skill 文档，之后永远不会忘记这个解法。这些 skill 可搜索、可共享，并兼容 agentskills.io 开放标准。 ...

Superpowers 14 个 Skills 全解读：AI 编程纪律框架的完整拆解 最核心的价值不是某个单独 skill，而是这条链路： 需求澄清 → 设计确认 → 计划拆解 → 隔离开发 → TDD → review → 验证 → 收尾 这条链路正好针对 AI coding 最常见的失败模式：过早实现、缺少测试、猜测修复、跳过验证、过早宣布成功。 注意：要经常更新 skills 的代码版本和自己结合实际使用，将自己的经验和要求增加到 skills，以便更好的编程和业务准确性，最好是将自身业务的要求单独作为 skills 引入到编程工具里。 Superpowers 是一个给 AI 编程 Agent 的完整软件开发方法论，由一组可组合 skills 和初始指令组成。它的基本工作流是：先澄清需求、写设计、写实施计划、TDD 实现、代码审查、验证、最后合并/PR/清理。 该不该装？三层判断 层面 判断 技术层面 不必须。没有它，AI coding agent 也能写代码。 工程质量层面 对复杂项目，强烈建议。它强制 TDD、审查、验证，能减少"AI 自信但没验证"的问题。 Superpowers 自身规则层面 一旦安装并启用，它的 using-superpowers 明确要求：只要有 1% 可能适用，就必须先调用相关 skill；README 也说这些是 mandatory workflows, not suggestions。 我的建议：重项目安装，轻任务选择性使用；团队协作/生产代码建议默认启用；纯探索、一次性原型可以不用或显式绕开。 1. using-superpowers — 入口规则 这个 skill 不是某个开发动作，而是**"调度所有 skills 的总开关"**。它要求 agent 在任何任务开始前先判断是否有相关 skill；只要有一点可能适用，就要先调用 skill，而不是凭经验直接干。它还规定了优先级：用户明确指令最高，Superpowers skills 其次，默认系统行为最低。 ...

我用 Superpowers 治好了 AI 写代码的"急躁症" 你有没有这种经历？ 跟 AI 说一句"帮我加个登录功能"，它三秒钟就开始生成代码了。你还没来得及说"我要 OAuth 不要密码登录"，它已经把整个 auth 模块写完了。跑一下，报错。让它修，改了三处引入两个新 bug。再改，需求理解全歪了。 折腾一小时，还不如自己写。 问题不在 AI 笨——现在的 Claude、GPT 编程能力已经很强了。问题是它太急了。还没搞清楚你要什么，就急着动手。没有设计，没有测试，没有验证，凭着"感觉"改代码，改完说一句"看起来没问题"就算完成。 我最近发现了一个开源项目，专门治这个毛病。 Superpowers 是什么 Superpowers 是一个给 AI 编程 Agent 装的插件。它不改变模型能力，而是给 Agent 加了一套强制执行的开发流程。 你可以把它理解为：一个严厉但好心的技术 Lead，站在 AI 后面盯着它—— "停，先搞清楚需求再写代码。" "计划呢？计划写好再动手。" "测试呢？测试先写，代码后写。" "代码审查过了吗？没过不许继续。" 它由 Jesse Vincent（Prime Radiant 公司）开发，目前版本 v5.1.0，MIT 协议。支持 Claude Code、Codex CLI、Gemini CLI、Cursor、GitHub Copilot CLI 等主流 AI 编程工具。 实际用起来是什么体验 装上 Superpowers 之后，你和 AI 的交互模式会完全不一样。我用一个实际场景走一遍。 场景：让 AI 帮你做一个用户通知系统 没有 Superpowers 时，对话通常是这样的： 你：帮我做一个通知系统 AI：（立刻开始写代码）我创建了一个 NotificationService…… 你：等一下，我要邮件通知，不是站内信 AI：好的，我重新写…… 你：还需要支持批量发送 AI：我再加一个…… ...

OpenClaw 升级实战：我如何把 2026.5.7 平滑升级到生产环境 适用环境：OpenClaw 通过 npm -g 安装，Gateway 由 launchd 托管，配置目录在 ~/.openclaw。 实测时间：2026-05-14，目标版本 2026.5.7。 写作目的：不只想记录「怎么做」，更想把整个升级过程中我的思考、犹豫、判断写出来，方便有类似需求的朋友参考。 前言：为什么要升级？ 事情是这样的。 那天我像往常一样打开 Telegram，准备和我的 OpenClaw 助手聊几句，突然收到一条来自社区频道的推送——OpenClaw 新版 2026.5.7 发布了。看了一眼更新内容，我愣了一下： KV 缓存压缩比从 4:1 变成 1/128，内存占用直接降 90%？ 训练收敛速度提升 3-5 倍？ 缓存命中率从 70% 到 92%？ 单 token 延迟从 1.8s 砍到 0.7s？ 说实话，换做以前一些小版本更新，我可能就忽略掉了。但这几个数字太扎眼了。尤其是缓存命中率和响应延迟这两项，直接影响我每天的使用体验。 我的 OpenClaw 跑了有一段时间了，配置、记忆、定时任务、消息通道都配齐了。说实话，换机器重装一次很麻烦，所以每次升级我都比较谨慎——备份做没做？Gateway 会不会崩？定时任务会不会丢？ 但这次数字太香了，我决定动手。 动手之前，我给自己定了几条原则： 先搞清楚现状：本地什么版本，npm 最新什么版本 先备份，再动刀：万一出问题，要有退路 升级完必须验收：Gateway 状态、定时任务、消息通道，一个都不能漏 遇到问题不慌：npm 报错、launchctl 报错，都是有解法的 整个过程下来，确实踩了几个坑，但也验证了一套可复用的流程。写这篇文章，一来是给自己留个记录，二来希望帮到有类似需求的朋友。 第一部分：升级前，先搞清楚值不值得动手 1.1 新版本到底更新了什么？ 说实话，我不是一个「追新」的人。我的原则是：如果新版本没有解决我的痛点，或者新特性我用不上，那升级就是徒增风险。所以在决定升级之前，我把 2026.5.7 的 Release Notes 仔细看了一遍。 ...

AI Agent 时代，为什么我放弃 Markdown 全面转向 HTML 原文作者：Thariq（@trq212），Claude Code 团队工程师 原文发布于 2026 年 5 月 9 日 背景 Markdown 已经成为 AI Agent 与我们沟通时的主流文件格式。它简洁、可移植，具备一定的富文本能力，并且便于编辑。Claude 甚至已经擅长在 Markdown 文件中用 ASCII 字符绘制图表。 但随着 Agent 能力越来越强，我开始觉得 Markdown 成了一种束缚。 Markdown 的局限性 信息密度低 超过 100 行的 Markdown 文件读起来就很吃力。当 Claude 需要表达： 表格数据 设计系统（颜色、组件） 图表和插图 交互效果 Markdown 只能： 画丑丑的 ASCII 图 用 unicode 字符近似呈现颜色（如 🟣🟢🔴） 贴截图或图片链接 视觉体验差 Markdown 扁平化了一切。代码 diff、流程图、模块关系——这些空间信息在 Markdown 里全部被压成一维文字。 当方案的复杂度超过一屏时，Markdown 从"文档"变成了"阅读障碍"。 分享不便 大多数浏览器不能原生渲染 Markdown 文件。你只能： 作为邮件附件发送 粘贴到 GitHub 评论里 上传到某个平台（Notion、飞书等） 而 HTML？上传到 S3 或任何静态托管，一个链接就能分享。 ...

"如果要支持消费者级别的 Agent，每个用户有多个 Agent，每个 Agent 都写代码，容器是不够的。我们需要更轻量的东西。" — Kenton Varda, Cloudflare 引言：AI Agent 的代码执行困境 AI Agent 正在改变软件开发的方式。从简单的工具调用到自主编写代码执行任务，Agent 的能力边界不断拓展。但这里有一个核心问题：AI 生成的代码在哪里执行？ 直接 eval()？不行——恶意用户可以诱导 AI 注入漏洞。 用容器？太重——启动慢、内存大、需要预热。 Cloudflare 在 2026 年 3 月给出的答案是 Dynamic Workers：基于 Isolate 的轻量级沙箱，比容器快 100 倍，内存效率高 10-100 倍。 本文将深入解析 Dynamic Workers 的技术原理、架构设计、实际应用和最佳实践。 一、问题溯源：为什么容器不够用？ 1.1 传统容器方案的技术瓶颈 容器（Docker、containerd 等）是目前最主流的代码隔离方案。但在 AI Agent 场景下，它存在根本性问题： 问题 技术原因 实际影响 启动慢 需要启动完整 Linux 用户空间、初始化进程树、加载运行时 300-500ms 冷启动 内存大 每个容器需要独立的内核命名空间、文件系统层 100-300MB/容器 需要预热 冷启动延迟不可接受，必须保持池化 成本增加、资源浪费 安全妥协 预热池复用容器，破坏隔离性 安全风险 1.2 规模化困境的计算 假设一个消费者级 AI 应用： ...