跳转到主要内容

03 — 超越 Hermes：你的体系独有的差距和机会

2026年4月24日
8 分钟阅读
框架分析

03 — 超越 Hermes：你的体系独有的差距和机会

这一篇不局限于 Hermes 的借鉴，而是站在你的体系全景上，识别 结构性的差距和被低估的机会。

一、断裂点：你的体系中信息不流通的地方

1.1 cclog 与 CC 内部记忆的断裂

这是你体系中最大的断裂点。

cclog 拥有：

  • 所有历史会话的完整索引
  • 按项目/时间/关键词的搜索能力
  • LLM 生成的会话摘要
  • 按日/周的 digest

但 CC 在会话中完全看不到 cclog 的数据。当你在 CC 中问"上次我处理 eco-flow 时做到哪了？"，CC 只能：

  1. 看 MEMORY.md 的索引（可能有也可能没有）
  2. 看 HANDOFF.md（如果你写了的话）
  3. 看 tasks.json（如果 SessionEnd hook 触发了的话）

它看不到 cclog 里那些详细的会话记录和摘要。

机会：把 cclog 的搜索能力暴露为 MCP tool。CC 就能直接 search_sessions(query="eco-flow 生态流量计算") 拿到相关历史会话的摘要。这比任何记忆系统都精确，因为它搜的是原始对话。

1.2 Memory 跨项目不互通

你的记忆是按项目隔离的：

~/.claude/projects/-Users-tianli-Dev/memory/          # ~/Dev 的记忆
~/.claude/projects/-Users-tianli-Work-eco-flow/memory/ # eco-flow 的记忆
~/.claude/projects/-Users-tianli-Dev-cc-configs/memory/ # cc-configs 的记忆

当你在 ~/Dev 下工作时，CC 看不到 eco-flow 项目的记忆。当你在 eco-flow 下工作时，CC 看不到 ~/Dev 的全局记忆中关于 eco-flow 的部分。

机会：建立一个 跨项目记忆搜索 机制。可以是一个 command /recall，搜索所有项目的记忆文件，返回相关结果。或者更好的方案——把所有记忆建 FTS5 索引，通过 MCP 暴露。

1.3 tasks.json 与 HANDOFF.md 的冗余

两者都在解决"跨会话连续性"问题，但方式不同：

  • tasks.json: 自动生成，结构化，但粒度粗（session 级别）
  • HANDOFF.md: 手动创建（/handoff 触发），细粒度，包含架构决策

机会：考虑合并或明确分工。比如：tasks.json 负责"状态总览"，HANDOFF.md 负责"详细上下文"。tasks.json 中加一个 handoff_path 字段指向对应的 HANDOFF.md。

二、隐性知识：你体系中没有被显式化的东西

2.1 工作流模式

你有很多隐性的工作流模式没有被 skill 化：

例子 1：新项目启动流程 每次新建一个项目，你大概会做：

  1. mkdir ~/Dev/new-project && cd ~/Dev/new-project && git init
  2. 创建 CLAUDE.md
  3. 创建 .gitignore
  4. 创建 GitHub repo
  5. 更新 repo-map.json
  6. （可能）运行 /harness init

这个流程散落在你的记忆中，但没有一个 /new-project skill 来固化它。

例子 2：水利项目标准流程 从你的 skill 体系看，水利项目有一套标准流程：

  • 数据准备 → 计算 → 报告生成 → 审阅 → 修订
  • 每个阶段有对应的 skill 和 command

但这个端到端流程本身没有被显式化。如果有一个 "项目阶段路线图" skill，CC 就能主动提示"数据准备阶段完成了，下一步应该做 XX"。

2.2 失败模式和陷阱

你的 feedback 记忆记录了很多"不要做 XX"：

  • 不要硬编码
  • 不要问用户要 API key
  • commit+push 不要分轮

但这些是被动防御——只有 CC 碰巧读到这条记忆时才会避免。更好的方式是把这些失败模式做成 pre-flight check。比如在 /deploy 之前自动检查是否有硬编码的路径。

2.3 决策日志

你的架构决策散落在 HANDOFF.md、记忆文件、CLAUDE.md 的注释中。没有一个统一的地方记录"为什么选了方案 A 而不是方案 B"。

Hermes 在这方面也没做好，但 ADR（Architecture Decision Records）是一个成熟的工程实践。对你最有用的场景：

  • 为什么 dashboard 用 Streamlit 而不是 Next.js
  • 为什么脚本拆成 4 个 repo 而不是 1 个 monorepo
  • 为什么 auth 用 CF Access 而不是自建

这些决策的上下文一旦丢失，未来再碰到类似选择时会重新纠结。

三、效率瓶颈：你的体系中哪些地方在浪费时间

3.1 Skill 维护的手动开销

你有 43 个 command + 14 个 skill。每次 CC 更新功能（比如新增 Agent tool 参数），你可能需要更新多个 skill 的 prompt。

机会：skill 模板化。把通用的模式（比如"读取 repo-map.json"、"调用 cf_api.py"、"遵循 plan-first 原则"）提取为可引用的片段，减少重复。

3.2 Dashboard 部署流程

每次更新 dashboard 需要：

  1. 本地修改
  2. 运行 deploy.sh（task_analyzer → scp → rsync → pip install → restart）
  3. 等待部署完成

对于一个只有你自己看的 dashboard，这个流程偏重。

机会：GitHub Actions + 自动部署。push 到 main 后自动 rsync 到 VPS。你已经有 GitHub repo，加一个 workflow 文件就行。

3.3 记忆文件的增长管理

17 个项目目录，60+ 个记忆文件，还在增长。MEMORY.md 有 200 行截断限制。

机会：记忆归档机制。超过 N 天未被读取的记忆自动移到 archive/，从 MEMORY.md 移除。保持活跃记忆的精简。

四、被低估的机会

4.1 你的 cclog 是一个宝藏

cclog 可能是你体系中最被低估的资产。它有完整的会话历史，可以：

  • 训练个人 skill：分析历史会话，发现最常见的工作模式
  • 生成周报：自动从一周的会话中提取完成的工作
  • 效率分析：哪些类型的任务耗时最长？哪些 skill 最常被纠正？
  • 上下文恢复：比 HANDOFF.md 更完整的会话重播

但目前 cclog 主要只被用来"浏览和搜索"。它的数据价值远没有被充分利用。

4.2 Auggie MCP 的语义搜索

你的 CLAUDE.md 提到"优先用 auggie codebase-retrieval MCP 做语义搜索"。这是一个强大的能力，但它只能搜索 Git 仓库中的代码。

机会：如果能扩展 auggie 的索引范围（或用类似的方案），让它也能索引你的 skill 文件、记忆文件、CLAUDE.md 文件，就可以实现"跨所有知识源的语义搜索"。这比 FTS5 关键词搜索更智能。

4.3 Harness 作为产品

你的 cc-configs 仓库（43 commands + 14 skills + harness 分发系统）本身就是一个可分享的产品。

Hermes 是开源的、通用的框架。但你的 harness 是基于实战经验 构建的、针对 CC 的最佳实践集合。如果把领域特定的 skill（水利相关）剥离，剩下的通用部分（/audit、/ship、/groom、/health、/handoff、/recap、context、plan-first）对任何 CC 重度用户都有价值。

这不是说你现在就要做这件事，但值得意识到——你手里有一个 Hermes 不具备的东西：在 CC 原生生态里被验证过的 harness pattern。

4.4 Hook 体系的扩展空间

你目前用了 3 个 hook：Stop、SessionEnd、PostToolUse。但 CC 的 hook 点远不止这些。

可以考虑的扩展：

  • PreToolUse (Bash)：在执行危险命令前拦截（比如 rm -rf、git push --force）
  • SessionStart：自动检查 HANDOFF.md 是否存在，提示"上次做到哪了"
  • NotebookEdit：如果你开始用 Jupyter
  • 自定义事件：通过 PostToolUse 匹配特定工具调用模式

五、行动建议（按投入产出比排序）

快速见效（1-2 小时）

  1. 丰富 user_role.md — 加入技术栈熟练度、工作模式偏好、领域知识分布
  2. 在 /recap 中加 skill 候选分析 — 修改 prompt，加一段"是否有重复模式值得 skill 化"
  3. SessionStart hook — 检查 HANDOFF.md 和最近的 tasks.json，自动提示上下文

中等投入（半天到一天）

  1. cclog MCP tool — 把 cclog search 暴露为 MCP tool，让 CC 可以搜索历史会话
  2. 记忆 FTS5 索引 — 跨项目记忆搜索
  3. launchd 定时任务 — 每日 health check + git pull + 异常通知

长线投入（一周+）

  1. Dashboard 操作化 — 加 deploy/pull/scan 按钮
  2. Telegram Bot — 移动端运维入口
  3. Skill 自进化闭环 — skill 候选池 + 使用反馈追踪 + 自动更新提示
  4. Harness 通用化 — 剥离领域 skill，打包通用 harness 分享

六、一句话总结

你的体系在 静态配置层面 已经非常成熟（分层上下文、注册表驱动、凭证隔离、归档机制），但在 动态智能层面 还有很大空间 —— 让体系能自我观察（搜索、分析）、自我维护（定时调度、记忆清理）、自我进化（skill 候选、反馈闭环）。

Hermes 的核心启发不是某个具体功能，而是一个理念：agent 不应该只是执行指令，还应该从执行中学习，并把学习成果反哺给自己。你的体系已经具备了这个理念的基础设施（cclog、memory、/recap），缺的是把它们连通起来形成闭环。