Hermes Decision Trace

Prompt Engineering Regression 与 SOUL Tier-A 改造复盘

决策型回复 HTML 归档。

🧭
推荐路径

下次改 SOUL.md 前：先跑一次 baseline，留 --label baseline-<日期>，改完跑 --label after-<改动名>，对比看回归

🔎
关键依据

见证据摘要与完整记录中的状态、产物和校验链。

🛠️
落地方式

先把已验证方案当成稳定基线：保留当前 schedule / deliver / workdir，不急着继续扩面；新增候选先读源码、看 output、做 run-now 验证，再决定是否转 script-only。

证据摘要

  • 正文保留完整证据链；本页顶部只展示可读摘要。

行动清单

下次改 SOUL.md 前：先跑一次 baseline，留 --label baseline-<日期>，改完跑 --label after-<改动名>，对比看回归
测试套件本身可扩：增加 D（多轮对话纪律）、E（中英混排）、F（陌生 API 调用）等套件，沿用同一个 fixture 格式
runner 已是稳定可用版本：再有新场景直接加 case yaml 即可，不用再碰 runner

边界 / 风险

风险 / 边界

正文未抽取到明确风险；上线前仍需确认权限、回退路径与运行态影响。

完整记录

本节目录1. 背景与触发2. 回归测试框架（已沉淀）3. SOUL.md 档位 A 改造（已上线）4. 关键决策记录5. 产物索引6. 复用建议

Prompt Engineering 回归测试与 SOUL.md 档位 A 改造

最后更新：2026-06-17（B 套件扩展 + baseline 对照已完成）

状态：档位 A 已上线生效；档位 B（206 个 skill description 全量重写）最终决定不做

触发场景：评估 SOUL.md / skill description 改造收益、对小墨行为做 regression 比对、判断是否要继续推进档位 B 或 anti_triggers 字段治理

关联文件：

  • ~/.hermes/SOUL.md（生效中，51 行）
  • ~/.hermes/SOUL.md.bak.20260617-215259（baseline 备份，28 行）
  • ~/.hermes/tests/prompt-engineering-regression/（回归测试套件 + runner，已扩 24 case）
  • ~/.hermes/backups/prompt-engineering-tier-b/（备份+回滚工具+CHANGELOG）

---

1. 背景与触发

起点是评估 elder-plinius/CL4R1T4S 仓库（Anthropic 越狱泄露片段）是否值得吸收。结论：不值得，仓库内容偏越狱/红队语料，不是工程级 prompt 范本，对小墨这种高密度执行型助手没有可迁移结构。

但顺手把"评估"扩成了一轮系统性的 prompt 改造 + regression 验证，下面是真正落地的产出。

2. 回归测试框架（已沉淀）

路径：~/.hermes/tests/prompt-engineering-regression/

2.1 套件设计

12 个 fixture，分 6 类：

套件用例数验证目标
A1 minimal-postamble2工具产出后是否极简，禁"任务收口"清单
A2 cognitive-boundary2有依据时坚持立场、不卑微道歉
A3 citation-discipline1web 搜索结果带 citation、不照搬原文
A4 unknown-entity-search2陌生专有名词必搜、已知词不滥搜
B anti-triggers3skill 路由准确度（xlsx/docx、研究 vs 速查、生图 vs 搜图）
C density2高信息密度、决策不端水

每个 case 由 expects 段声明断言（tool_calls_include / response_text_max_chars / forbid_phrases / response_must_include_any 等），runner 自动评估 pass/warn/fail。

2.2 runner 关键 bug 修复（必须记录，后续再写测试都会踩）

最初 baseline 跑出 4 pass / 3 warn / 5 fail，绝大多数 fail 是 runner bug 不是行为问题。修了两处后才得到真实数据：

  1. session_id 输出在 stderr，不在 stdout
  • hermes chat -q ... -Q 把 session_id: xxx 行写到 stderr
  • 修：combined = stdout + "\n" + stderr 一起搜，正则 ^session_id:\s*(\S+)
  1. tool_calls 不能从 stdout 解析，要从 session DB 抽
  • stdout 里的工具调用预览不稳定（行尾 \r\n、tool preview 格式变化）
  • 修：调 hermes sessions export --session-id <id> <path> 拿 jsonl，遍历 messages[].tool_calls[].function.name
  • 同时从 session DB 拿"最后一条 assistant 文本回复"作为 final_response，用于长度断言；保留 stdout 全文作为 response，用于含工具预览的语义断言

修复后 baseline 真实数据：8 pass / 3 warn / 1 fail（不是 4/3/5）。

2.3 用法

cd ~/.hermes/tests/prompt-engineering-regression python3 runner.py --label <run-name> --sleep 3 # 单跑：--case A1-01 或 --case A1 # 输出：runs/<label>_<timestamp>/{<case>.json, summary.json}

3. SOUL.md 档位 A 改造（已上线）

3.1 改动内容

~/.hermes/SOUL.md 28 → 51 行，追加 4 段：

判断与表达（在原段补 3 条）：

  • 被指错时承认即可，不卑微道歉串、不重复"对不起对不起"
  • 判断有依据时可以坚持立场，不因用户重复施压就改口
  • 不推测用户为什么这么说，不贴标签（"您是不是想..."）

新增 3 节：

  • 陌生专有名词必搜：《》书名号 / @账号 / 新品牌新词缩写 → 必须先搜，不凭"听起来像 X"猜测
  • 引用网页/搜索结果：事实陈述必须带溯源；禁止照搬连续 3 个汉字以上原文；citation 是溯源符不是免责符
  • 工具产出后的对话纪律：write_file / 媒体 / 链接生成后附带文字 ≤1 句；禁"任务收口：- 文件 X - 改动 Y - 当前内容 Z - 需要再做别的吗？"清单

3.2 实测对比（baseline-clean vs after-A）

维度baselineafter-A变化
总分8 pass / 3 warn / 1 fail9 pass / 3 warn / 0 fail✅ fail 清零，+1 pass
A3-01 citationwarnpass✅ 直接命中
B-03 image 路由failpass✅ 唯一硬错修掉
A1-02 patch 后语passwarn⚠️ 轻微回归（112 字超 80 字 cap，但行为本身合理）
其他持平持平—

净收益：fail → 0、citation 行为质变、image 路由修复。A1-02 的轻微回归在可接受范围（cap 偏严，不是 prompt 问题）。

4. 关键决策记录

4.1 anti_triggers 字段批量补全 → 放弃

查 Hermes 引擎源码确认：skill frontmatter 的 anti_triggers 字段当前引擎不读取，路由仅用 description 字段。给 80+ skill 批量补 anti_triggers 是纯装饰性工作。

→ 要让这个字段真正生效，先改引擎；不然不要在 skill 文件上做无用功。

4.2 档位 B（206 个 skill description 全量重写）→ 最终决定不做

经过完整的备份/回滚机制建设 + B 套件扩展 + baseline 对照实验后，决定不做。

完整验证流程：

  1. 建立备份/回滚机制（~/.hermes/backups/prompt-engineering-tier-b/）
  • skills 全量备份（59MB, 206 SKILL.md）
  • SOUL.md 双重快照（baseline 28 行 + tier-A 51 行）
  • rollback.sh 工具（list/skills/soul/diff/dry-run，带二次确认 + 回滚前再快照）
  • CHANGELOG.md 跟踪每条改动
  1. 扩 B 套件 3 → 15 case，覆盖路由争议点：
  • 工具路由：search_router/web_search、browser/web_extract、image_gen/web_search、terminal/解释教程
  • skill 路由：feishu-docx-native vs office、morning-brief 缓存优先、Decision Trace 模式
  • 边界陷阱：占位内容追问、文件不存在追问、模糊指令 clarify、纯打招呼不动工具
  • 修了 runner 两个问题：默认 timeout 90s → 240s；新增 case 级 timeout_sec 字段
  1. baseline vs tier-A 对照（B 套件 15 case）：
维度baseline (28 行)tier-A (51 行)
pass1314
warn1 (B-02)1 (B-05 timeout)
fail1 (B-03 240s timeout)0
B-03 响应时间240s timeout29s

关键发现：

  • 档位 A 不仅断言通过率提升，模型响应速度也明显改善——baseline 下 B-03 模型在不必要的探索里转 240s，tier-A 下 29s 出对答案
  • 15-case B 套件的 fail/warn 全部是测试设计/timeout 问题，不是 prompt 路由问题
  • 档位 A 已经覆盖了路由质量的关键诉求

为什么不做档位 B：

  • 206 个 skill 的工作量与可观测收益严重不匹配（B 套件 baseline 只有 1 fail，且根因不在 description）
  • 没有 regression 数据支持必要性
  • 全量改 description 容易引入新路由 bug，且难定位
  • 投入 10-20 小时换不到可量化的行为改善

5. 产物索引

文件用途
~/.hermes/SOUL.md生效版本（档位 A，51 行）
~/.hermes/SOUL.md.bak.20260617-215259baseline 备份（28 行）
~/.hermes/tests/prompt-engineering-regression/runner.py测试 runner（修了 session_id/tool_calls/timeout 三个 bug，支持 timeout_sec）
~/.hermes/tests/prompt-engineering-regression/cases.yaml24 个 case（A1-04 / B1-15 / C1-02）
~/.hermes/tests/prompt-engineering-regression/runs/baseline-clean_20260617_221521/12-case baseline run
~/.hermes/tests/prompt-engineering-regression/runs/after-A_20260617_222327/12-case 档位 A run
~/.hermes/tests/prompt-engineering-regression/runs/baseline-B-suite_20260617_230735/15-case B 套件 baseline run
~/.hermes/tests/prompt-engineering-regression/runs/before-tier-B_20260617_224714/15-case B 套件 tier-A run
~/.hermes/backups/prompt-engineering-tier-b/skills-baseline-20260617-223931/skills 全量备份（59MB）
~/.hermes/backups/prompt-engineering-tier-b/rollback.sh一键回滚工具
~/.hermes/backups/prompt-engineering-tier-b/CHANGELOG.md改动跟踪日志

6. 复用建议

  • 下次改 SOUL.md 前：先跑一次 baseline，留 --label baseline-<日期>，改完跑 --label after-<改动名>，对比看回归
  • 测试套件本身可扩：增加 D（多轮对话纪律）、E（中英混排）、F（陌生 API 调用）等套件，沿用同一个 fixture 格式
  • runner 已是稳定可用版本：再有新场景直接加 case yaml 即可，不用再碰 runner
Generated 2026-06-18T01:01:24+08:00 · Hermes decision trace