案例③:把"研发助理"请进门——代码开发、调试与文档自动化
案例③:把”研发助理”请进门——代码开发、调试与文档自动化
写代码这块,AI 工具的竞争已经卷成红海了。所以我得先说清楚 Hermes 在这里的差异到底在哪——不然你完全没必要换。
差异就一句话:IDE 里的补全工具每次都在”重新认识你的项目”,Hermes 是”记得上次为什么这么改”。 前者的上下文生命周期等于一次对话,后者有 MEMORY.md 存架构决策、有 SQLite FTS5 存全部历史会话、有 SKILL.md 存你验证过的排查流程。你三个月前踩过的那个坑,它真的能翻出来。
再加一个更实际的差异:Hermes 是终端原生的。它不在编辑器里等你点”接受修改”,它直接 terminal 跑测试、patch 打补丁、process 管后台进程、execute_code 跑脚本。这更像招了个实习生,而不是买了个插件。
这一节我用一次真实的排障过程走完全流程。
一、工具组合与分工
▲ Hermes 桌面版流式对话与文件工作流
┌─────────────────────────────────────────────────────────────────┐
│ 上下文层(会话开始前自动就位) │
│ ───────────────────────────────────────────────────────────── │
│ SOUL.md(全局身份,slot #1,只从 HERMES_HOME 加载) │
│ AGENTS.md / CLAUDE.md(项目上下文,从 CWD 向上发现,自动注入) │
│ MEMORY.md(环境事实、架构决策、约定) │
└────────────────────────────┬────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ 执行层(干活的手) │
│ ──────────────────────────────────────────────────────────── │
│ terminal 跑命令 / 测试 / 查日志(支持后台+通知) │
│ process 后台进程 list/poll/log/wait/kill/write │
│ read_file 读文件 │
│ search_files ripgrep 全仓搜索 │
│ patch 模糊替换,返回 diff(比整文件重写安全) │
│ write_file 新建/覆写 │
│ execute_code 跑 Python,可程序化调用 Hermes 工具 │
└────────────────────────────┬────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ 智力放大层(省 token、召回历史) │
│ ──────────────────────────────────────────────────────────── │
│ session_search FTS5 查全部历史会话,返回真实消息,~20ms │
│ delegate_task 派子代理隔离上下文并行调研,只回摘要 │
│ memory 把结论写成跨会话记忆 │
│ skill_manage 把验证过的流程沉淀成 SKILL.md │
└─────────────────────────────────────────────────────────────────┘两个工具值得单独强调:
patch 优于 write_file。 它是模糊替换并返回 diff,你能看清改了什么。让 AI 整文件重写是灾难之源——它会顺手”优化”掉你不想让它碰的东西。
session_search 是研发场景的核心武器。 它查的是本地 state.db 的 FTS5 索引,返回真实消息、无 LLM 摘要、无截断,约 20 毫秒。这意味着”上次这个报错是怎么解决的”是一个可以精确回答的问题,而不是靠模型编。
二、先把项目上下文配对:为什么你的规范”写了但没生效”
这是新手最常踩的坑,先讲这个。Hermes 会自动发现并注入项目上下文文件,但每个会话只加载一种项目类型,首匹配即生效:
| 文件 | 级别 | 发现位置 | 优先级 |
|---|---|---|---|
.hermes.md / HERMES.md | 项目 | CWD 向上直到 git 根 | 1(最高) |
AGENTS.override.md | 项目 | CWD + 渐进子目录(私有覆盖,常 gitignore) | 2 |
AGENTS.md | 项目 | CWD + 渐进子目录 | 3 |
CLAUDE.md | 项目 | CWD + 渐进子目录(Cursor 兼容) | 4 |
.cursorrules / .cursor/rules/*.mdc | 项目 | 仅 CWD | 5 |
SOUL.md | 全局 | 仅 HERMES_HOME | 始终独立加载(slot #1) |
⚠️ 看懂这张表你就明白那个玄学 Bug 了:你在 AGENTS.md 里写了规范,但仓库根目录还有个 .hermes.md——那么 AGENTS.md 整个不会被加载。 不是”合并”,是”首匹配生效”。检查一下你仓库里有几个上下文文件。
AGENTS.override.md 的设计很聪明:团队共享的规范放 AGENTS.md 进版本库,你个人的偏好放 AGENTS.override.md 并 gitignore,优先级更高但不污染队友。
懒得手写?让它自己扫:
cd /path/to/your-repo
hermes/init 补充说明:这是个 FastAPI + Postgres 项目,测试用 pytest,
部署走 GitHub Actions,密钥统一走 .env 不许硬编码/init [notes] 会扫描仓库生成或更新 AGENTS.md。
上下文文件字符上限可配(未设时动态 20,000–500,000,超限按头 70% / 尾 20% / 中 10% 标记截断;会话中渐进发现的文件每个上限 8,000 字符):
context_file_max_chars: 40000三、真实流程:一个 OAuth 报错的完整排查
场景:本地服务突然登录不了,报 invalid_client。这是我实际遇到过的。以下是完整对话流,你能直接照着用。
第 0 步:进项目,带隔离
cd ~/projects/my-api
hermes --worktree # 在隔离 git worktree 里工作,不污染当前分支--worktree(-w)会开一个独立的 git worktree,Agent 的所有改动都在那里,你的工作区干净。修 Bug 场景强烈建议加。
第 1 步:开局就让它调历史,别急着让它猜
线上 OAuth 登录报 invalid_client,昨天还好的。
先做三件事再动手:
1) session_search 搜 "invalid_client" 和 "OAuth" 相关的历史会话
2) 读 MEMORY.md 里关于本项目认证模块的架构决策
3) terminal 看最近 200 行应用日志和昨天到现在的 git logHermes 的实际动作:
# session_search 命中三个月前一次同类故障(FTS5,真实原文,非摘要)
# → 上次结论:密钥在 CI 里被 secret masking 截断
# terminal 执行
tail -n 200 ./logs/app.log
git log --oneline --since="2 days ago"关键就在这里。 session_search 直接把三个月前的排查记录捞出来了,包含当时的原始报错、试过哪些方向、最后是哪一条奏效。这不是模型”记得”,是本地全文索引命中。它于是没有从头猜,而是直接优先验证”密钥被截断”这个假设——排查时间从半小时压到两分钟。
第 2 步:定向验证假设
按历史结论优先验证密钥完整性。注意:不要把密钥明文打印出来,只对比长度和首尾 4 位。它会跑类似这样的检查(execute_code 里做,比一堆 shell 管道可读):
import os, hashlib
v = os.environ.get("OAUTH_CLIENT_SECRET", "")
print("len:", len(v), "head:", v[:4], "tail:", v[-4:],
"sha8:", hashlib.sha256(v.encode()).hexdigest()[:8])
# 期望 len=64,实际 len=40 → 确认被截断⚠️ “不要明文打印密钥”这条指令要显式写。Hermes 的日志确实会自动脱敏,但你终端的滚动缓冲区、你的录屏、你的截图都不会。养成习惯:只比长度、首尾、哈希前 8 位。
第 3 步:改配置(用 patch 不用重写)
用 patch 修 .env 里的 OAUTH_CLIENT_SECRET,改完给我 diff,
密钥值我贴给你——注意不要提交 .env,确认它在 .gitignore 里patch 返回 diff,你眼过一遍再放行。同时 Hermes 有文件写入安全层(拒绝列表 + 可选写入沙箱),.env 这类敏感文件的写入本身会走审批。
第 4 步:重启验证
重启服务并验证:后台起服务,等健康检查通过后跑认证相关的 pytest# terminal 支持后台执行,配合 process 工具管理
uvicorn app.main:app --reload &
# process poll / process log 查状态,不用盲等
pytest tests/test_auth.py -vprocess 工具能 list/poll/log/wait/kill/write,这比”起个后台进程然后 sleep 10 秒祈祷”靠谱得多。
第 5 步:沉淀(这一步决定你半年后是否还在重复劳动)
这次排查到此结束。做三件事:
1) memory 记一条:本项目 OAUTH_CLIENT_SECRET 长度必须 64,
CI secret masking 会截断超长值,部署后必须校验长度
2) skill_manage 把这套排查流程沉淀成 oauth-invalid-client-triage
3) 给我一份会话摘要,以及一条符合仓库 commit 规范的提交信息沉淀出来的 Skill 骨架(agentskills.io 标准):
---
name: oauth-invalid-client-triage
description: OAuth invalid_client 报错的标准排查流程
version: 1.0.0
metadata:
hermes:
tags: [debug, oauth, backend]
category: devops
requires_toolsets: [terminal, file, session_search]
---
# OAuth invalid_client 排查 SOP
## When to Use
出现 invalid_client / unauthorized_client,或认证在部署后突然失效。
## Procedure
1. session_search 检索历史同类故障
2. 校验密钥长度与首尾(禁止明文输出)
3. 对比 .env 与密钥管理平台的原始值
4. 检查 CI/CD 是否发生 secret masking 截断
5. patch 修正 → 重启 → 跑认证测试
## Pitfalls
- 密钥尾部空格/换行会导致同样报错,用 len() 而非肉眼比对
- 容器环境变量可能被镜像层缓存,需重建而非重启
## Verification
pytest tests/test_auth.py 全绿,且日志无 invalid_client。下次同类报错,Agent 会直接命中这个技能,流程从”探索”变成”执行”。这就是官方说的”程序性记忆”——技能被明确定位为这个东西。
四、并行调研:大仓库的正确读法
让 Agent 一口气读完一个十万行的仓库是自杀式操作,上下文瞬间爆。正确做法是派子代理:
delegate_task 派三个子代理并行调研,各自只回摘要:
A:认证与权限模块的调用链和关键抽象
B:数据层 ORM 模型与迁移历史,标注有历史包袱的地方
C:CI/CD 流程与部署脚本,标注所有密钥注入点delegate_task 在隔离上下文里派生子代理,只把最终摘要返回主会话。主会话拿到的是三份浓缩结论,而不是三万行代码。官方在优化技巧里明确推荐多主题研究用这个手法。
另一个省 token 的招:批量文件操作用 execute_code 写 Python 一次做完,别让它逐条发终端命令。二十个文件的批量重命名,一条脚本 vs 二十轮工具调用,成本差一个数量级。
五、避坑
⚠️ 上下文文件优先级是”首匹配”不是”合并”(见上文表格)。这一条我重复第二遍,因为它太容易踩了。
⚠️ --yolo 用在代码仓库上要看清边界。 它跳过危险命令审批,但硬线阻止列表仍然生效(rm -rf / 及变体、fork bomb、dd 写块设备、把不可信 URL 管道给 sh)。可是 git push --force 这种不在硬线里——它能把你同事的提交冲掉。用规则挡住:
approvals:
mode: smart # smart | manual | off
deny: # 用户拒绝规则,fnmatch glob,优先于 yolo
- "git push --force*"
- "git reset --hard*"
- "*curl*|*sh*"deny 规则先于 yolo 生效,这是个很好的安全阀。另外 hermes approvals suggest --apply 1,3 能从你的历史审批记录里挖规则建议出来。
⚠️ 容器终端后端跳过危险命令审批。 如果你把 terminal.backend 设成 docker/modal/daytona,设计上认为容器就是安全边界,审批被跳过。所以镜像要锁版本,别挂载不该挂的宿主目录。
⚠️ 别用 Hermes-4 模型做工具调用。 Nous Portal 上有 Hermes-4-70B/405B,但官方明确说这系列是为聊天和推理调优的,不推荐在 Agent 里作为工具调用模型。研发场景对工具调用准确率极度敏感,选 Claude Sonnet/Opus 4.x 或 GPT-5.x 这类。
⚠️ 上下文超限先 /compress 再考虑换模型。 /compress focus <模块名> 定向压缩,保留你正在改的那部分。也可以显式设 model.context_length。
⚠️ Windows 上写文件显式指定编码。 cp125x 默认编码写中文注释或 markdown 会 UnicodeEncodeError,脚本里统一 encoding="utf-8"。
⚠️ 本地模型跑 Agent 要给足上下文。 官方要求本地模型上下文至少 64000;Ollama 若设了 num_ctx,Hermes 侧的 context_length 必须匹配,否则会出各种诡异截断。本地端点读超时自动放宽到 1800s,仍超时就设 HERMES_STREAM_READ_TIMEOUT=1800。
本节能造出什么数字员工
“研发助理”——一个记得项目历史决策的排障搭子。
| 字段 | 内容 |
|---|---|
| 员工名 | DEV-01(建议独立 profile,与内容号隔离) |
| 职责 | 读代码库、定位 Bug、打补丁、跑测试、补文档、写符合规范的提交信息 |
| 触发 | 人工发起排障 / 每日跑测试的 cron / 消息平台里丢个报错截图 |
| 工具集 | terminal、process、file(read/write/search/patch)、code_execution、session_search、memory、delegation、skills |
| 上下文 | AGENTS.md 项目规范自动注入 + MEMORY.md 架构决策 + SOUL.md 工程师人格 |
| 安全边界 | approvals.mode: smart + deny 规则挡 force push;--worktree 隔离改动 |
| 产出 | diff 补丁 + 测试结果 + 会话摘要 + commit message + 新增/更新的 SKILL.md |
| 复利机制 | 每次排障都往记忆和技能里存一笔,同类问题第二次出现时直接执行 SOP |
最后说个数据感受一下上限:社区里有人在单台笔记本上跑 4 个 Agent 24/7,34 个工具、5 个 MCP 服务器;有人开 12 个实例并行构建;有人保持了 297 天连续使用、消耗 50 亿+ token。这东西的天花板不在工具,在你愿不愿意把流程沉淀下来。
下篇预告
三个案例走完,你手上应该已经有一个”值班室”加三个能干活的员工了。
下一节我们收口:怎么把这些散装员工组织成一支军团。 多 profile 之间怎么分工、@提及 群组协作的实际手感(2–6 个 Bot 一个房间,最多 3 轮串行回合,Bot 能 @user 把问题升级给人类)、hermes peer 跨机编排怎么让家里的 NAS 和云上的 VPS 互相派活、kanban 工具集怎么当多代理的任务总线。以及一个绕不开的现实问题——养一支军团一个月到底要花多少钱,以及怎么用辅助模型分层把这个数字压到零头。
延伸阅读
- 官方文档(工具、上下文文件、安全):https://hermes-agent.nousresearch.com/docs
- 中文社区:https://hermesagent.org.cn/docs
- GitHub 仓库:https://github.com/NousResearch/hermes-agent