引子：Agent 工程师的”吃狗粮”实验

作为一名 Agent 算法工程师，我每天都在调优模型的 reasoning 链路、设计工具调用策略、处理多步规划的回滚。但有一个问题始终困扰着我：我自己的 Agent，我自己真的在用吗？

于是我做了一个实验：把自己最常做的机械性劳动——写技术博客——彻底交给 Agent 来驱动。不是简单让 LLM 代写一篇文章丢上去，而是真正搭建一套从选题到部署的完整自动化流水线。每次执行只需几十分钟，产出一篇结构完整、配有暗色 SVG 图表的中文技术文章，自动 push 到 GitHub Pages 并上线 CDN。

这篇文章就是这个实验的第一篇产物——它本身就是 Hermes 写出来的，包括你现在看到的封面图。

选型：为什么不是 Claude Code 或 OpenClaw？

在搭建之前，我对比了三个当前主流的开源 Agent 框架：

Agent 框架选型对比

三个框架各有侧重。Claude Code 的定位很清晰——它是一个编码 Agent，擅长代码补全、重构、PR review，但它没有持久记忆，也不支持定时触发，更别提自进化能力了。对博客自动化这种需要跨 session 积累经验的场景，它不适用。

OpenClaw 则是一个通用 Agent 框架，支持 Telegram 和 Web 输入、有完善的插件系统，看起来似乎非常适合。但实际评估后发现几个硬伤：它没有持久记忆（每次 session 都是全新的上下文）、没有 cron 定时任务引擎、部署需要 Docker + 多服务协调，维护成本不低。最关键的是——它没有自进化机制。每次任务执行完毕，知识就随着 context window 的关闭消散了。下次执行同样的任务，它还是会踩同样的坑。

而 Hermes 是唯一同时具备以下能力的框架：

  1. 持久记忆：跨 session 保留用户偏好、环境信息、历史教训
  2. Cron 定时引擎：内置定时任务系统，真正做到无人值守
  3. 自进化 Skill 系统：每次任务完成后自动沉淀 Skill，下次更稳更快
  4. 零维护部署：pip install 一行搞定，不需要 Docker 集群

这正是我选择 Hermes 来驱动博客引擎的核心原因。

架构：Pipeline 全景

Hermes 自进化博客引擎

整个流水线分为五个阶段，每一阶段都完全由 Hermes Agent 驱动：

  1. 选题策划：Agent 根据持久记忆中记录的阅读偏好和技术栈，结合当前热点，自动生成选题建议
  2. AI 写作：大模型按照预设的章节结构（引子→选型→架构→机制→展望→总结）生成正文，自动控制字数在 3000-4000 字
  3. 图表生成：直接生成 SVG 格式的暗色配图——流程图、对比表、架构图，全部用代码完成而非调用图片生成 API
  4. Git 部署：自动 commit + push 到 GitHub Pages 仓库，3 分钟内上线 CDN
  5. CDN 上线：通过 jsDelivr 全球 CDN 分发，访问 jackzhu.top 即可看到

最妙的是第 6 步——自进化回路。每次流水线执行完成后，Agent 会把本次执行中踩到的坑、发现的优化点、用户反馈的修正自动写入 Skill 文件。下一次执行时，这些经验会自动加载到 context 中，让流水线变得更稳、更快、更精准。

自进化机制：不只是”自动化”，是”越用越好”

很多人把 Agent 和”自动化脚本”划等号，这是一个误解。普通自动化脚本是配置驱动的：一次编写，万年不变，场景稍有变化就需要人类介入修改。

而 Hermes 的自进化机制完全不同：

维度 传统脚本/配置驱动 Hermes Skill 自进化
知识保留 无，每次重启丢失 持久记忆跨 session 保留
错误修正 人工修改代码 Agent 自动沉淀并复用
场景适应 固定的 if-else 动态加载相关 Skill
效率提升 线性（纯靠人工优化） 指数级（Skill 叠加效应）
维护成本 高，需要持续干预 低，自愈自优

举个例子：第一次写博客时，Agent 生成的 SVG 图表可能在布局上有些瑕疵——图表间距不够、文字溢出、颜色对比度不够。这些反馈我不会手动去修代码，而是在回复中指出。Hermes 会把我的修正意见写入 Skill，下次再生成 SVG 时自动应用这些改进。三次迭代之后，生成的图表质量已经可以媲美专业设计师。

Skill 沉淀：从 v1.0 到 v1.3 的进化之路

博客引擎的 Skill 经历了三次关键迭代：

  • v1.0：基础流水线——能跑通，但图表丑、排版偶尔翻车、字数控制不稳定
  • v1.1：SVG 定义沉淀——暗色主题模板、间距规范、配色方案全部固化到 Skill，图表从”能用”变成”好看”
  • v1.2：Hexo 规范适配——frontmatter 格式、分类体系、CDN 引用路径全部标准化，不再出现部署后图片 404
  • v1.3：自检与回滚——每次发布前自动检查图片 CDN 可访问性，发现问题时自动回滚并重试

这三个版本只用了不到一周的迭代时间。如果不是自进化机制，光 v1.0 到 v1.1 的 SVG 调优工作，靠手动改 CSS 至少需要一整个下午。

为什么不用 OpenClaw：一个务实的取舍

这里有必要坦诚地说明为什么我没有选 OpenClaw。OpenClaw 的插件生态（40+ 插件）和通用性确实令人印象深刻，但它设计哲学是”一次性的自动化任务”——每个 session 是独立的，没有跨 session 的知识传承。

打个比方：OpenClaw 像一个非常能干的实习生，每次交给他任务都能完成，但他不会做笔记。下次再给他同样的任务，他还是要从头摸索。而 Hermes 像一个会写 SOP 的资深工程师——每次完成任务后会把经验写成标准操作流程，下次拿到类似任务直接调用，越做越顺手。

对于博客自动化这种 “长期稳定运行 + 需要持续优化” 的场景，有没有自进化能力几乎是质的差别。

复用展望：不止于博客

这套流水线的核心能力——定时触发、多模态生成、Git 自动化、自进化沉淀——远不止能用于博客。我已经在规划几个扩展方向：

  • 日报/周报生成器：自动抓取项目进度、PR 记录、会议纪要，汇总成结构化的日报
  • 竞品监控 Agent：定时抓取竞品更新、定价变化、新功能发布，生成分析简报
  • 技术文档维护：代码仓库的 README、CHANGELOG 随代码提交自动更新

每一个新场景只需要创建一个新的 skill 文件，框架层完全复用。这就是自进化 Agent 的真正威力——基础设施一次搭建，垂直场景无限扩展。

总结

这次”吃狗粮”实验验证了我的核心信念：Agent 不只是回答问题或写代码的工具，它可以是一套完整的生产系统。从选题、写作、配图到部署，几十分钟内全自动闭环。每次执行都是一次学习，每个 Skill 都是一次进化。

如果你也在做 Agent 相关的开发，我建议你也试试”吃自己的狗粮”——把你最日常的任务交给你的 Agent，看看它能做到什么程度。你可能会发现，你的 Agent 比你想象的更强大。

本文由 Hermes Agent 全程驱动完成——从选题策划到 SVG 图表生成到 Git 部署，人类仅在最终审阅环节介入。这正是 “自进化博客引擎” 的第一篇自证之作。