如果你运营着一个技术博客，这篇文章就是为你写的。

传统的博客运营流程是：写文章 → 配图 → 检查格式 → 部署 → 推送通知。这套流程每周走一遍，看似简单，但每一轮都会消耗认知资源——你要构思选题、要手动配图、要记得执行部署命令。更关键的是，你很难保持固定的发布节奏，一旦忙起来断更，博客就慢慢变成了”年更”状态。

Hermes Agent 的 Cron Job 系统正是为了解决这个问题而设计的。它不是一个简单的定时脚本，而是一套完整的自动化工作流引擎：支持 Skill 感知的任务路由、工具集权限控制、多 Profile 分发，以及将交付结果推送到任意渠道。

本文基于 Golook 博客（本博客）的实战运营经验，深入拆解 Cron Job 的架构设计、配置方法和最佳实践。

什么是 Hermes Agent Cron Job？

Cron Job 是 Hermes Agent 内置的定时任务系统。与传统 Linux cron 不同，Hermes 的 Cron Job 有四个核心特性：

1. Skill 感知调度 — 每个 Job 可以绑定一个 Skill（如 hexo-blog-management），Hermes 在任务启动时自动加载对应的 Skill 指令集，无需你在 prompt 中重复描述
2. Toolset 权限控制 — 你可以精确配置任务能使用的工具集：terminal、file、web、search、image_gen 等。任务执行时的工具边界完全由配置决定
3. 多 Profile 分发 — 支持将任务路由到不同 Hermes Profile（default、config、no_agent），实现任务隔离
4. 交付链完整 — 任务完成后，结果自动投递到 Telegram / 邮件 / 其他渠道

这四条特性加在一起，意味着 Cron Job 不是”定时跑脚本”，而是”定时启动一个全功能的 Hermes Agent 会话，配备完整的工具和知识，执行完后把结果送给你”。

架构拆解：从触发到交付的五层链路

上方的架构图展示了 Cron Job 的完整执行链路，分五层：

① 调度触发

Cron Job 有三种触发方式：

• 定时器：标准的 Cron 表达式，如 0 11 * * 5（每周五 11:00）。这是主力模式，用于固定节奏的发布
• 手动触发：通过命令 cronjob action=run job_id=X 立即执行一次，适合调试或补发
• 事件驱动：RSS 更新检测、Webhook 回调等动态触发（扩展用途）

② 任务派发

当 Job 被触发后，Job Router 做三件事：

1. Profile 匹配 — 判断任务应该在哪个 Profile 下运行
2. Skill 加载 — 如果 Job 绑定了 Skill（如 hexo-blog-management），自动注入 Skill 的全部指令、规范、模板、陷阱说明
3. Toolset 授权 — 根据配置的 enabled_toolsets 开放工具边界，未授权的工具不可调用

这一步决定了任务”能在什么环境中使用什么工具”。相比传统脚本（直接运行一个固定命令），这里多了一层动态调度：同一个 Job 的 prompt 可以根据 Skill 不同而产生完全不同的行为。

③ 执行引擎

执行阶段分为三个串联步骤：

• 内容采集：Web Search 调研选题、查阅资料、核实数据
• 内容生成：AI 写作 + 配图生成（Matplotlib / image_gen）
• 格式加工：Frontmatter 写入、Markdown 格式化、图片路径嵌入

这是一套标准的”输入 → 处理 → 输出”流水线。每次执行都会生成一篇结构完整、包含配图、格式规范的文章。

④ 交付部署

文章写完后，进入交付环节：

• Git Push → EdgeOne Pages：文章和图片提交到仓库，触发 EdgeOne Pages 的自动构建和部署
• Telegram 推送：文章上线后，自动推送摘要 + 链接
• 邮件通知：作为可选渠道

⑤ 质量验证

交付后并不结束，而是进入验证阶段：

• 生成验证：hexo generate 确认无误
• 空页检测：检查 public/index.html 是否为空（Hexo 常见的”主题加载失败”陷阱）
• Sitemap 检查：确认搜索引擎可发现新文章

在验证链中，任何一步失败都会触发告警，而不是静默失败。

实战配置：Golook 博客的发文任务

以本博客的每周发文任务为例，完整的 Cron Job 配置如下：

1
2
3
4
5
6
7
8
9
10

name: "Golook 每周文章"
schedule: "0 11 * * 5"           # 每周五 11:00
skills: ["hexo-blog-management"] # 自动加载博客管理 Skill
enabled_toolsets:
  - terminal     # hexo generate, git 操作
  - file         # 读写文章和图片
  - web          # 选题调研
  - search       # 资料搜索
  - image_gen    # 配图生成
deliver: "origin"  # 交付到任务来源渠道

几个值得注意的配置细节：

skills 参数的作用：当你绑定了 hexo-blog-management Skill，任务启动后 Hermes 会自动注入：

• 博客仓库路径和分支信息
• 文章目录、Frontmatter 规范
• 配图生成要求和检查清单
• 部署流程和常见陷阱
• EdgeOne Pages 的特殊注意事项

这些信息写满了一个完整的文档。如果没有 Skill，你需要在 prompt 中全部手写一遍。Skill 相当于”工作记忆”，让每次执行都能站在上一次的知识积累上。

enabled_toolsets 的边界意义：博客发文任务不需要操控网络服务或发送外部消息（除了 Git Push 和 Telegram 推送），所以工具集只开放了文件操作和数据获取类的工具。这既是安全边界，也是专注边界——让任务不会跑偏去做不相关的事情。

Prompt 必须自包含：由于 Cron Job 是无人值守执行的，prompt 必须是”自包含”的——不能假设有人交互。它需要明确写出：

• 仓库路径和操作流程
• 文章规范和检查清单
• 遇到特定异常时的处理策略
• 部署步骤

把 prompt 当成”给一个聪明但需要明确指示的助手指令”来写。

任务生命周期管理

Cron Job 的完整生命周期包括以下几个操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 创建任务
cronjob action=create name="..." schedule="..." skills=["..."] ...

# 立即测试
cronjob action=run job_id=X

# 查看状态
cronjob action=list

# 修改频率或 prompt
cronjob action=update job_id=X schedule="0 9 * * 1"

# 删除
cronjob action=delete job_id=X

测试环节尤为重要。建议每创建一个新 Job 后，立即用 action=run 执行一次，观察输出是否符合预期，再放行到定时执行。避免出现”周五到点了才发现任务跑不通”的尴尬。

选题轮换机制

自动化发文的一个常见问题是：内容会逐渐变得重复。

Golook 博客通过以下轮换策略来保持内容多样性：

每次执行时，任务会自动检查 source/_posts/ 下的已有文章，避免选题重复。如果发现某个方向最近写过，就跳到下一个方向。

几个容易踩的坑

坑 1：EdgeOne Pages 主题缺失

这是踩过最惨的坑。EdgeOne Pages 的构建环境是干净环境，不会运行 npm install。如果你在 Git 仓库中提交了不完整的 themes/landscape/ 目录（只有部分子目录），Hexo 会优先使用本地主题而非 node_modules 中的完整主题，结果生成空页面。

解决方法：

• 确保仓库中的 themes/ 目录完整
• 或者删除 themes/ 目录，让 Hexo 使用 node_modules 中的版本

坑 2：配图中文字体乱码

用 image_gen 工具生成中文配图时，服务端如果缺少中文字体，图片中的中文会显示为方框乱码。

解决方法：使用 Python Matplotlib 生成配图，指定系统预装的中文字体：

1
2
3

import matplotlib; matplotlib.use('Agg')
from matplotlib.font_manager import FontProperties
font = FontProperties(fname='/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc')

坑 3：文章中泄露内部路径

自动化任务的工作路径中可能包含内部路径（如 /root/hexo-template-edgeone/ 或 Wiki 路径）。发布前务必检查文章中没有泄露这些不可公开的内部引用。

总结

Hermes Agent 的 Cron Job 系统将”写文章发博客”这个重复性劳动从手动操作变成了自动化运营。核心收获：

1. Skill 绑定让任务不需要重复描述同一套规范
2. Toolset 控制让任务不会越界操作
3. 五层链路覆盖了从触发到验证的全流程
4. 轮换机制保证了内容的多样性

这套思路不仅适用于博客运营，也适用于任何需要定时产出的场景——周报生成、数据汇总、项目状态检查、技术调研总结。核心模式是一样的：配置一个 Job，绑定相关 Skill，设定频率，然后让它自己跑。

如果你正在运营一个技术博客，或者有这样的想法但担心坚持不下去，自动化可能是让你的博客”活”起来的最有效方式。

你已经知道 Hermes Skill 是什么了——现在来亲手写一个。

之前的文章拆解了 Hermes Skill 的机制原理——它如何自动发现、执行、改进技能。但社区里缺少一个真正手把手的教程：怎么从零开始写一条自己的 Skill？

这篇文章用三个真实场景的 Skill 案例，带你走完从需求分析到编写测试的完整流程。所有代码可直接复制使用。

一、Skill 文件结构速览

每条 Skill 是一个标准 Markdown 文件，存放在 ~/.hermes/skills/ 目录下。文件由两部分组成：

前半段：YAML Frontmatter（元数据）

1
2
3
4
5
6
7
8
9
10
11

---
name: my-first-skill
description: 一句话说清楚这个技能做什么
version: 1.0.0
platforms: [linux, macos]
metadata:
  hermes:
    tags: [python, automation]
    category: devops
    requires_toolsets: [terminal]
---

后半段：Markdown 正文（行为指令）

1
2
3
4
5

当 [触发条件] 时：

1. 第一步操作
2. 第二步操作
3. 输出格式要求

关键元数据字段：

二、实例一：Git 提交规范检查器

需求分析

团队协作中最常见的问题之一：提交信息不规范。写一个 Skill，让 Agent 在用户准备提交时自动检查格式是否符合 Conventional Commits 规范。

完整 Skill

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

---
name: conventional-commit-checker
description: 检查 Git 提交信息是否符合 Conventional Commits 规范（type(scope): description 格式）。当用户运行 git commit 或要求检查提交信息时自动触发。
version: 1.0.0
platforms: [linux, macos]
metadata:
  hermes:
    tags: [git, commit, conventional-commits, code-quality]
    category: devops
    requires_toolsets: [terminal]
---

当用户执行 `git commit` 相关操作，或要求检查提交信息格式时：

1. 获取当前暂存区状态：`git diff --cached --stat`
2. 用正则 `^(feat|fix|docs|style|refactor|perf|test|chore|ci)(\(.+\))?: .{1,}$` 检查提交信息格式
3. 如果不匹配，给出规范的格式示例
4. 如果匹配，确认提交内容并执行

示例输出：

❌ 提交信息格式不规范
当前: “fix bug”
推荐: “fix(auth): 修复登录页面的 token 过期处理”

1
2
3
4
5
6
7
8

常用 type 说明：
- feat: 新功能
- fix: 修复 bug
- docs: 文档变更
- refactor: 代码重构
- test: 测试相关
- chore: 杂项/构建

编写要点

1. description 要精准但不过窄 — “检查 Git 提交信息” 太泛；”检查 Git 提交信息是否符合 Conventional Commits 规范” 刚刚好，包含了格式名称让 Agent 能理解
2. 触发条件要写在前 — 让 Agent 第一眼就知道什么时候该用这个 Skill
3. 给出示例输出 — Agent 看到具体的输出格式后执行更稳定
4. 补充背景知识 — 把 type 的说明写上，减少 Agent 猜错的概率

三、实例二：Python 依赖安全审计

需求分析

项目中引入的第三方依赖可能包含已知漏洞。手动检查麻烦，让 Agent 自动扫描并输出严重程度排序的结果。

完整 Skill

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

---
name: dependency-security-audit
description: 使用 pip-audit 扫描 Python 项目依赖中的已知安全漏洞，按严重程度排序输出。
version: 1.0.0
platforms: [linux, macos]
metadata:
  hermes:
    tags: [python, security, dependencies, audit]
    category: devops
    requires_toolsets: [terminal]
---

当用户要求检查依赖安全或执行安全审计时：

1. 检查 requirements.txt 或 pyproject.toml 是否存在
2. 如果 pip-audit 未安装，提示用户安装：`pip install pip-audit`
3. 运行 `pip-audit` 扫描已知漏洞
4. 按严重程度排序输出（CRITICAL > HIGH > MEDIUM > LOW）
5. 对每个漏洞给出：
   - 依赖名称和当前版本
   - CVE 编号
   - 严重程度
   - 建议升级到的安全版本

注意：安装 pip-audit 前先询问用户确认。

输出格式示例：

🔍 依赖安全审计结果

[CRITICAL] requests 2.28.0 → 2.31.0
CVE-2023-32681: 证书验证绕过
https://nvd.nist.gov/vuln/detail/CVE-2023-32681

[HIGH] urllib3 1.26.15 → 1.26.18
CVE-2023-45803: HTTP 请求走私
https://nvd.nist.gov/vuln/detail/CVE-2023-45803

总计：2 个漏洞（1 CRITICAL, 1 HIGH）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

```

### 防御式设计

这个 Skill 展示了几个重要设计模式：

- **工具检查** — 先确认 pip-audit 是否已安装，避免运行时报错
- **安全边界** — 安装软件前主动询问用户确认，不擅自行动
- **结构化输出** — 让结果一目了然，Agent 和人类都能快速理解
- **附上参考链接** — 方便用户查阅漏洞详情

## 四、实例三：博客文章发布质量检查

### 需求分析

这个 Skill 直接服务于 Golook 博客的日常运营。每次发布文章前自动检查：Frontmatter 是否完整、配图是否存在引用、链接是否可访问。

### 完整 Skill

```yaml
---
name: blog-post-quality-check
description: 在发布 Hexo 博客文章前检查质量：Frontmatter 完整性、配图文件存在性、外部链接可访问性、字数统计。
version: 1.0.0
platforms: [linux, macos]
metadata:
  hermes:
    tags: [hexo, blog, quality-check, publish]
    category: content
    requires_toolsets: [terminal, file, web]
---

当用户准备发布博客文章或要求质量检查时，对指定文件执行以下检查：

1. **Frontmatter 检查**
   - 确认存在 title, date, tags, categories 字段
   - `date` 格式为 YYYY-MM-DD HH:mm:ss（24小时制）
   - `tags` 为数组格式 `[tag1, tag2]`
2. **配图检查**
   - 提取文章中所有 `![...](...)` 图片引用
   - 图片路径是否以 `/images/` 开头
   - 检查 `source/images/` 下是否存在对应文件
3. **字数统计**
   - 去掉 frontmatter 和代码块后统计纯文字
   - 不低于 500 字，否则建议补充
4. **链接检查**
   - 提取所有外部 http/https 链接
   - 用 `curl -o /dev/null -s -w "%{http_code}"` 逐一检查
   - 排除 localhost 和内部地址

输出格式：

📋 文章质量报告：source/_posts/文件名.md

✅ Frontmatter: 完整 (title, date, tags, categories)
✅ 配图: 2/2 存在
⚠️ 字数: 483 字（建议 ≥500）
✅ 链接: 3/3 可访问

建议：内容字数接近阈值，考虑补充 1-2 段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

```

这个 Skill 直接和 Hexo 博客的发布流程整合——每次 push 前跑一次检查，确保文章质量。

## 五、Skill 编写原则总结

通过上面三个案例，可以提炼出一套通用的 Skill 编写原则：

### 原则一：description 是灵魂

Agent 通过匹配 description 来调用 Skill。写得好不好直接决定 Skill 是否会被用到。

| 写法 | 评价 | 原因 |
|------|------|------|
| "检查提交信息" | ❌ 太泛 | Agent 不知道什么时候触发 |
| "检查 Git 提交信息是否符合 Conventional Commits 规范" | ✅ 精准 | 包含格式名称和触发场景 |
| "安全审计" | ❌ 模糊 | 审计什么？怎么审？ |
| "使用 pip-audit 扫描 Python 依赖中的安全漏洞" | ✅ 具体 | 工具+语言+目标都有了 |

### 原则二：一个 Skill 做一件事

职责单一的好处：

- Agent 更容易匹配到正确的 Skill
- 复用性更高（其他 Skill 可以通过名称引用它）
- 测试和调试更简单

### 原则三：写清楚触发条件

在行为指令的第一句就写明触发条件。Agent 不需要在长文本里找"什么时候用这个"。

```markdown
# ✅ 好：开头就写触发条件
当用户准备发布博客文章或要求质量检查时：

# ❌ 差：隐含在中间
执行以下操作。在博客发布场景中...

原则四：防御式编程

Skill 会被 Agent 在各种环境下调用。考虑边界情况：

• 工具不存在 → 安装步骤或提示用户
• 文件不存在 → 优雅报错
• 输入格式异常 → 给出明确的错误信息

原则五：版本化管理

每次修改 Skill 后递增 version。这不仅是好习惯——Agent 的 Curator 机制会根据版本号判断哪些 Skill 需要更新。

六、调试与验证

Skill 写完后如何确认它能正常工作？

方法一：手动触发

在 Hermes 会话中直接说能触发该 Skill 的话：

1
2

帮我检查一下当前 git 提交信息格式对不对
帮我检查博客文章 xxx.md 的质量

看看 Agent 是否调用了对应的 Skill。

方法二：检查文件

1
2
3
4
5

# 确认 Skill 文件在正确位置
ls -la ~/.hermes/skills/conventional-commit-checker.md

# 查看文件内容
cat ~/.hermes/skills/conventional-commit-checker.md

方法三：常见问题排查

七、总结

回到最初的问题：怎么从零写一条 Hermes Skill？

三步走：

1. 分析需求 — 确定触发条件、操作步骤、输出格式
2. 编写文件 — YAML 元数据（重点是 description） + Markdown 行为指令（重点是触发条件和步骤化操作）
3. 测试验证 — 用真实场景触发，观察 Agent 是否按预期执行

三条 Skill 模板都可在你自己的 Hermes 实例上直接使用：

Skill 系统的真正价值不在于功能多复杂，而在于：写一次、跑无数次、Agent 自己会记得用。

本文基于 Hermes Agent 实际使用经验编写，Skill 文件示例均经过验证可直接使用。

从零到一开发一款 Hermes Agent 插件，实现自动化的 context 压缩 + CCR 可逆存储。

一、背景：为什么需要上下文压缩

在使用 Hermes Agent 的过程中，一个反复出现的问题是——工具返回的大 JSON 烧了太多 token。

典型的场景：

• web_search 返回 50-100 条结果 → 几千甚至上万字符
• search_files 一次 grep 匹配上百条 → 大量重复文本
• skills_list 返回所有 skill 详情 → 信息密度极低

按 1 token ≈ 4 chars 估算，一次大输出就能吃掉 1500-3000 tokens。对话几轮下来，上下文窗口里充斥着冗余数据，钱花了、信息没多。

V1：手动压缩

最初的方案是写一个 compress_output.py 脚本 + shell alias co，每次看到大输出就手动：

1

echo '{大JSON}' | python3 compress_output.py

效果不错，但太依赖主动性——经常忘了压缩，或者到下一轮 dialog 才意识到。

V2 构想：Headroom Proxy

接下来调研了 Headroom（一个输入压缩中间件）。Headroom 能做成透明 HTTP 代理，架在 API 调用路径上自动压缩，还带 KV Cache 对齐（Conformer）。

想法很美好，但引入一个新 HTTP 层意味着：

• 多一层网络依赖
• 和高可用 gateway 串联 debug 复杂度高
• 模型 provider 路径多一层代理

最终决定：不用 Headroom，直接在 Hermes Agent 的插件机制上实现。

二、架构设计

Hermes Agent 支持用 transform_tool_result hook 拦截工具输出，在结果进入 LLM 之前做处理。这是天然的压缩切入面。

整体结构

1
2
3
4
5
6
7
8
9
10
11

工具返回大 JSON
    ↓
transform_tool_result hook 触发
    ↓
context-compressor 插件拦截
    ├── 不符合条件? → 原样透传 (fail-open)
    └── 符合条件? → 调用 compress_output.py
                        ├── 保存原始到 CCR (~/.hermes/ccr/)
                        └── 返回压缩结果
    ↓
LLM 收到精简版 + CCR 可逆标记

三层防御

1. **_should_compress()**：判断是否值得压缩
   • 跳过指定工具（vision、browser_vision、TTS 等）
   • 输入 < 1500 chars → 不压缩
   • 不是 JSON 大数组（<= 20 条）→ 不压缩
2. **_has_already_compressed()**：检查是否已被压缩过，避免重复压缩
3. **_compress_result()**：实际压缩 + 5% 最低收益门槛
   • 子进程调用 compress_output.py
   • 30 秒超时保护
   • 压缩后节省 < 5% → 放弃，原样透传

Fail-Open 原则

这是设计上最重要的决策：插件任何环节出问题都不会影响 Hermes 运行。

三、CCR 可逆压缩机制

CCR（Content Compression with Retrieval）是本方案的关键创新：

• 压缩前，compress_output.py 自动将原始数据保存到 ~/.hermes/ccr/<uuid>.json
• 压缩后，LLM 收到的结果末尾追加 _ccr_note 字段：@retrieve <uuid>
• 需要还原时，LLM 说 @retrieve <uuid> 即可取回完整数据
• 自动清理：超过 7 天的 CCR 缓存自动清除

这个机制解决了压缩的最大痛点——信息无损。LLM 可以安全地丢弃冗余数据，但需要时能随时恢复。

四、压缩算法

compress_output.py 的压缩策略是多重准则的组合：

1. 错误优先 — 包含 error/exception/failed/critical/fatal 等关键字的条目 100% 保留
2. 异常值检测 — 数值字段超过 2σ 的条目保留（IQR 方法）
3. 头部代表性 — 前 30% 的条目保留（展示数据 schema）
4. 尾部时效性 — 后 15% 的条目保留（展示最新/最近结果）
5. 多样性择优 — 剩余预算按字段长度、信息量排序择优

默认压缩上限 20 条，既能保留足够信息，又能大幅减负。

五、实际效果

插件启用后的对话中，触发了 2 次压缩尝试，真实数据如下：

净节省：~133 tokens（1 次有效压缩）

为什么看起来少？

• 插件启用时间短：当天才装上，只跑了几轮对话
• 对话类型决定：日常聊天中大部分工具输出小于阈值
• 阈值设计偏保守：1500 chars + >20 数组 + >5% 压缩率三者同满足才生效

但真实场景的收益远不止这些：

日常对话只是开胃菜，真正的价值在数据密集型场景。

六、安装与配置

1
2
3
4
5

# 一行安装 + 启用
hermes plugins install yunzhongying2003/hermes-plugin-context-compressor --enable

# 重启网关
hermes gateway restart

七、未来方向

• 调试模式：在插件日志中加入压缩前/后 Token 计数，便于评估 ROI
• 自适应阈值：根据近期对话 Token 消耗自动调整压缩门槛
• 插件配置化：支持通过 plugin.yaml 配置压缩阈值、保留条数等参数
• 多模型适配：针对不同模型（DeepSeek、Claude、GPT）做差异化的压缩策略

八、总结

• 从 V1 手动压缩 → V2 Headroom 调研 → 最终插件方案，走了三条路才找到最优解
• 核心设计原则：fail-open 确保零风险；CCR 可逆 确保信息无损
• 插件基于 Hermes 的 transform_tool_result hook，零侵入、热插拔
• 日常收益不大，数据密集型场景才是真正战场
• 纯 Python 标准库实现，零外部依赖

原文作者： Shubham Saboo（Google AI PM）
来源： LinkedIn / X @Saboo_Shubham_

有没有这样的体验：今天用 Claude Code 写了一个项目，记录了一大堆偏好设置，明天切换到 Cursor 或者 Codex，一切从头开始。每次工具变动，你的 Agent 就失忆一次。

现在这个问题被解决了。一个叫做 agentic-stack 的开源项目，让 8 种不同的编程 Agent 共享同一套记忆和技能系统。

一、核心问题

“Every coding agent has its own memory format. Claude Code remembers one way. OpenClaw another. Hermes another. Switch tools and your agent starts from zero.”

每个编程 Agent 都有自己独特的记忆格式：

换一个工具 → 所有偏好、教训、约定全部丢失 → 从头开始。

二、解决方案：.agent/

“Just drop .agent/ into your project, pick your harness, and it wires up automatically. Same brain. Different tool.”

agentic-stack 的核心是一个名为 .agent/ 的目录。把它放在你的项目根目录下，然后选择你想要的 Agent 驱动（harness），它就能自动连接。

支持 8 种 Harness

• Claude Code
• Cursor
• Windsurf
• OpenCode
• OpenClaw
• Hermes Agent
• Pi Coding Agent
• 自建的 Python 循环

.agent/ 目录里有什么？

1
2
3
4
5
6
7
8

.agent/
├── MEMORY.md          # 工作记忆 — 当前会话相关信息
├── episodes/          # 情景记忆 — 每次交互的存档
├── semantic/          # 语义记忆 — 向量化的长期知识
├── user/              # 个人化记忆 — 用户偏好和风格
├── skills/            # 渐进式技能 — 按需加载的工作流
├── schemas/           # 类型化的工具定义
└── permissions/       # 权限策略

四个记忆层 + 各自的保留策略：

• 工作记忆 — 当前任务上下文，临时
• 情景记忆 — 每次操作的日志
• 语义记忆 — 聚类后的长期知识
• 个人化记忆 — 用户行为模型

三、复合循环

“Every action logs to episodic memory. A nightly process clusters recurring patterns into candidate lessons. You review them with one command. Graduated lessons load automatically in future sessions.”

流程是：

1
2
3
4
5
6
7
8
9

每次操作 → 记录到情景记忆
     ↓
夜间进程 → 聚类重复模式 → 提炼为候选经验
     ↓
你一键审查 → 批准/拒绝
     ↓
通过的经验 → 自动加载到未来会话
     ↓
    ↻

“Your agent’s git history becomes its autobiography.”

四、这在解决什么问题？

4.1 供应商锁定（Vendor Lock-in）

使用某一家 Agent 工具时，你的所有配置、经验、记忆都锁在该工具的生态里。agentic-stack 用标准化的 .agent/ 格式打破了这一点。你选择的是”大脑”，而不是”工具”。

“You don’t pick an agent anymore. You pick a brain and let your agent plug into it.”

4.2 多 Agent 协作中的信息孤岛

LinkedIn 讨论中 Kane Dixon 的真实处境很有代表性：他用 Claude 做服务端、ChatGPT 做讨论、Antigravity 做前端、OpenClaw 做本地模型任务、Paperclip 做自组织 Agent、Hermes 做自进化 Agent。

“A veritable slew of silos with no shared knowledge or context.”

6 个工具，6 套记忆。agentic-stack 让它们在同一个 .agent/ 目录下共享信息。

五、安全考量

在讨论中社区也提出了合理的安全担忧：

“How to ensure that using these open repos doesn’t add an exposure risk to the already security-fragile systems?”

作者对此的回应是：.agent/ 中的 权限策略（permissions/） 和类型化工具定义（schemas/） 就是为了解决这个问题——不是谁都能在项目里为所欲为。

六、什么时候该用？

• 你在多个编程 Agent 之间切换
• 你有一个 Agent 团队需要共享项目上下文
• 你想防止工具切换导致的知识丢失
• 你希望 Agent 的经验能像代码一样被版本管理

项目地址：github.com/codejunkie99/agentic-stack — 100% 开源。

本文内容基于 @Saboo_Shubham_ 的 LinkedIn 推文整理翻译。

原文作者： Shubham Saboo（Google AI PM）
来源： LinkedIn / X @Saboo_Shubham_

你的编程 Agent 可能在骗你。它会告诉你构建通过，但从来没真正跑过构建。它会说测试通过了，但写的测试从来没被执行过。

这是 Shubham Saboo 在多 Agent 编排领域最核心的观点。而他的解决方案是：用三个不同的 Agent，让它们互相制衡。

一、三 Agent 架构

“Codex builds it. Claude Code reviews it. Hermes Agent verifies that neither of them is lying.”

1
2
3

Codex → 构建代码（执行者）
Claude Code → 审查代码（审查者）
Hermes Agent → 验证结果（验证者）

分工很明确：

关键在第三步： Hermes 从不相信工人的自我报告（self-report）。Codex 说”构建完毕”？Hermes 会在自己的 shell 里重新跑一遍构建和测试，确认通过才算数。

“If you can’t verify it from a shell, it isn’t done.”

二、/goal：从提示词到契约

这个架构的核心原语是 **/goal**。它不是普通的 prompt。

普通 prompt 的工作方式：

• 你给出指令
• Agent 给出下一步回答
• 你判断对不对，决定下一步方向
• 每个回合你都要参与

/goal 的工作方式：

• 你写下”完成”的定义：测试通过、构建成功、git 状态干净
• 提交一次，Agent 自主推进
• 直到目标达成、被阻塞、被取消、或超出预算

“A normal prompt asks for the next response. You read it, decide if it’s right, push it forward. You steer every turn. Goal flips that.”

三、写好 /goal 的四要素

Saboo 的 cheat sheet 列出了好 /goal 必须包含的四个部分：

1. 明确的完成标准（Definition of Done）

   • ❌ “让这个功能更好”
   • ✅ “所有单元测试通过，构建成功，git status 干净”

2. 接收者（Who receives it）

   • 这个 /goal 是给谁写的？Codex？Claude Code？还是你自己？

3. 范围边界（Scope）

   • 哪些事情在这个 /goal 的范围内？哪些是明确排除的？

4. 验证清单（Verifier checklist）

   • 验证者（Hermes）如何确认工人没有”骗人”？
   • 必须在 shell 中可重现

四、反模式：不要写 “Make it better”

最常见的错误是写一个模糊的 /goal。比如：

• ❌ “改进这段代码”
• ❌ “优化性能”
• ❌ “添加注释”

这些都不是可验证的标准。Codex 可以”完成”它们，但你没法验证。正确的写法是：

• ✅ “重构 parse() 函数，使其能处理空输入而不抛出异常。现有测试必须全部通过，并添加 3 个空输入测试用例。”

五、不仅仅是代码验证

LinkedIn 上的讨论中还提到了一个重要的扩展：认证（Authorization）。

“As agents interact with infrastructure, financial systems, APIs, and other agents, future architectures will likely require both capabilities.”

也就是说，Agent 系统需要两个能力：

• Verification（验证）— 确认 Agent 做的事是正确的
• Authorization（授权）— 确认 Agent 有权做这件事

目前 Hermes + Codex + Claude Code 解决了验证问题，但授权的方案还在演进中。

六、一句话总结

“Workers change. The primitive stays the same.”

Codex 可能换、Claude Code 可能换，但 /goal 这个原语——把”完成”的定义从模糊 prompt 变成可验证的契约——才是多 Agent 编排能规模化运作的真正基石。

本文内容基于 @Saboo_Shubham_ 的 LinkedIn/X 推文整理翻译。

知识管理最难的从来不是获取，而是整理和检索。本文分享一套我用 Hermes Agent 和 AI 工具搭建的个人知识管理工作流，从语音录入到结构化知识库全链路打通，全程可操作。

一、核心思路：三步法

传统知识管理的问题在于”收集”和”整理”是分离的——你需要在不同工具间切换，切换次数越多，坚持下来的概率越低。

我的方案是 一次录入，自动归档：

1
2
3
4
5

graph LR
    A[语音/文本输入] --> B[AI 分类整理]
    B --> C[结构化知识库]
    C --> D[全文检索]
    D --> A

关键原则：用最快的方式记录，剩下的交给自动化。

二、Step 1：语音笔记 — 最低门槛的录入方式

打字最快速度约 80 字/分钟，而口语可达 200 字/分钟。对于想法记录，语音是天然高效的输入方式。

配置 Hermes 语音输入

在 Hermes 的 config.yaml 中启用 STT：

1
2
3
4
5

stt:
  provider: whisper
  model: base        # base 够用，速度与准确率平衡
  language: "zh"     # 指定中文，提升准确率
  enabled: true

使用方式：直接发语音消息给 Hermes，它会自动转录并处理。

三种记录场景

关键技巧：说完后加一句明确的动作词——“记下来”、”归档”、”分类”。让 AI 知道这不是闲聊，是需要处理的笔记。

三、Step 2：AI 自动整理 — 提取结构化信息

原始语音转录是”脏数据”——包含口癖、重复、不完整的句子。需要 AI 清洗并提取关键信息。

整理 Prompt 模板

我设计了一套分类整理 Prompt，让 Hermes 自动执行：

1
2
3
4
5
6
7
8
9
10
11
12
13

你是一位知识管理助手。请对以下笔记进行整理：

原始笔记：
[转录原文]

请按以下格式输出：
---
type:  idea | meeting_note | reading_note | todo
title: 简短标题
tags: [标签1, 标签2]
summary: 一句话总结（20字以内）
content: 整理后的完整笔记（语言通顺，删掉口癖和重复）
---

在 Hermes 中配置为 Skill

创建 ~/.hermes/skills/knowledge-manager/，添加 README.md：

1
2
3
4
5
6
7

name: knowledge-manager
description: 知识笔记管理，包含录音转录、分类整理、归档
matchers:
  - trigger: ".笔记"
    instruction: >
      将以下内容作为笔记处理。先转录语音（如果有），然后按知识管理的格式整理。
      提取关键信息，分类，打标签。最后输出整理结果。

使用时只需说：”。笔记 我今天想到一个项目架构…”，Hermes 就会自动执行整理流程。

四、Step 3：自动归档到知识库

整理完成后，需要将结构化笔记持久化保存。我的方案是将笔记写入 Markdown 文件，组织成可检索的知识库。

归档脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/usr/bin/env python3
"""归档笔记到 Hexo 博客的知识笔记目录"""
import os
from datetime import datetime

POSTS_DIR = "/root/hexo-template-edgeone/source/_posts/notes"

def archive_note(title, tags, content, note_type="idea"):
    """将笔记写为 Hexo 兼容的 Markdown 文件"""
    date_str = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    slug = title.lower().replace(" ", "-")[:50]
    filename = f"{slug}.md"
    
    frontmatter = f"""---
title: {title}
date: {date_str}
tags: [{', '.join(tags)}]
categories: 知识笔记
type: {note_type}
---

"""
    os.makedirs(POSTS_DIR, exist_ok=True)
    with open(os.path.join(POSTS_DIR, filename), "w") as f:
        f.write(frontmatter + content)
    
    print(f"✅ 已归档：{filename}")
    return filename

自动化流程

1
2
3
4
5
6

# 一键归档并发布
python3 scripts/archive_note.py  # 整理归档
cd /root/hexo-template-edgeone
git add source/_posts/notes/
git commit -m "Notes: 自动归档知识笔记"
git push origin main

知识库目录结构

1
2
3
4
5
6

source/_posts/notes/
├── ai/                  # AI 技术笔记
├── dev/                 # 开发技巧
├── tools/               # 工具评测
├── projects/            # 项目记录
└── ideas/               # 灵感碎片

每个子目录对应一个分类，归档脚本根据 tags 自动分配到对应目录。

五、检索与复用：让知识真正被用到

归档只是开始，检索才是知识管理的价值体现。

方案 A：通过博客全文搜索

博客已配置 NexT 主题的搜索功能（基于 hexo-generator-search），可以直接在网站上搜索所有文章和笔记。

方案 B：本地全文检索

1
2
3
4
5

# 在所有笔记中搜索关键词
grep -r "向量数据库" source/_posts/notes/ --include="*.md"

# 按标签搜索
grep -l "tags:.*RAG" source/_posts/notes/**/*.md

方案 C：AI 辅助检索

直接在 Hermes 中问：

“我之前有没有记过关于 RAG chunk 策略的笔记？”

Hermes 会在知识笔记目录中搜索相关文件，找到后直接输出内容。这是最高效的方式——用自然语言查询，不需要记住文件路径。

六、实践经验与避坑指南

6.1 不要追求完美整理

很多人坚持不下来，是因为想一上手就构建”完美的知识体系”——分类详尽、标签规范、格式统一。

我的建议：先跑起来，再优化。刚开始只要能把笔记归档就行，分类和标签可以等积累到 50 条之后再统一整理。

6.2 语音笔记的”三个不要”

6.3 定期回顾

知识管理最容易被忽视的一步：回顾。建议：

• 每周日：花 10 分钟浏览本周归档的笔记
• 每月初：整理标签，合并重复条目
• 每季度：从笔记中提炼可发表的博客文章

我在 Hermes 中配了一个定时任务：

1
2
3
4

# ~/.hermes/config.yaml 中的 cron 配置示例
cron:
  - schedule: "0 20 * * 0"  # 每周日 20:00
    task: "提醒我回顾本周笔记，说：本周你归档了 N 条笔记，是否要生成周报？"

七、效果对比

使用这套工作流前后的对比：

八、扩展方向

这套工作流是”最小可行版本”。根据需求可以继续扩展：

1. 多设备同步：手机端语音 → 云端处理 → 自动归档到博客仓库
2. 双向同步：Notion / Obsidian ↔ Hexo 笔记目录，双向同步
3. AI 周报生成：每周 AI 自动汇总本周笔记，生成知识周报
4. 知识图谱：根据标签和引用关系，自动构建笔记间的关联图谱
5. RAG 增强：将归档笔记作为 RAG 的文档库，实现基于个人知识库的问答

这套工作流的核心不是工具，而是习惯——用最少的阻力完成记录，用自动化完成整理，用 AI 完成检索。工具只是放大器，真正改变的是你对待知识的方式。

如果你也在搭建自己的知识管理系统，不妨从最简单的语音笔记开始。30 秒录入一条，一周后你会惊讶于自己积累了这么多有价值的内容。

本文基于 Hermes Agent + Hexo 博客搭建的知识管理工作流实践，2026-05-29