原则与记录

第2章 · 笔记 2

笔记 2

2026-08-31 · [如花] speaker 切换幻觉吞词新形态+full_verify 传参怪癖（t_f1d03f50） · 内参 20260831 合成后校验发现 96.4s 阿普→乾婆切换处「这个区别关键」整句被吞，三 ASR（whisper base/small+SenseVoice）均听出「威当不宁/微当不宁」类幻觉词；另有 tts_full_verify 的 [3]speed/[5]speaker 两项 WARN 非真实问题 · ①speaker 切换幻觉除了铁律 19 的「产生 0.6s 短幻觉声」，还有吞词形态——下一句开头整句被幻觉替代（本案例吞掉乾婆「这个区别关键」）；修复=短句重合成+silencedetect 边界+三段拼接（铁律 24 流程），修复区 ASR 验证通过；②怪声 rework 246.7-247.98s（疑问语气「结果呢」高 ZCR 0.318）双 ASR 复核为正常台词放行；③云端 4 处 suspect 转写均吻合脚本、哨声无频谱纯音佐证=omni 误报放行；④full_verify 传参怪癖：--scene 内参 不被 speed_validation 识别（应为「赫尔墨斯内参」）；speaker 在行首格式时 full_verify 固定 --offset 0 误报 68 处（需手动 offset 1 复核 71/71 全过） · 🔍三 ASR 交叉验证+修复区 ASR+双 MD5 交付核对 · t_f1d03f50

2026-08-31 · [阿普] 模型切换工具链第四层校验落地：cron jobs.json 资产联动校验（R-0831-05，t_2ed14499） · 8/28 羊毛雷达 cron（07108b7a1519）静默 drift_skip 一夜：此前 switch 操作只改模型名，jobs.json 里 model/provider 主字段变 null 只剩旧快照，被框架 drift guard 拦截跳过；verify_model_switch.py 三层校验只验切换目标本身不扫 cron 资产 · ①新增 ~/.hermes/scripts/verify_cron_assets.py（D 层校验模块，可独立巡检）；②verify_model_switch.py 集成 D 层调用（仅 profile 模式，显式参数模式不碰 jobs.json），D 层 FAIL 触发 switch 自动回滚；③switch_profile_model.sh 注释同步。判定规则（源码实证 cron_model_drift_axes + scheduler.py:5691，勿凭直觉改）：主字段空+快照有值=孤儿主字段 FAIL（必 drift_skip）；主字段空+快照空=WARN（无保护跟随全局）；pinned job 快照缺失是框架正常行为（_compute_provider_model_snapshots 故意不给 pinned 轴生成快照）不是异常；no_agent job 跳过 · ①pinned job 无快照≠异常——初版把「快照缺失」判 FAIL 导致 7 个健康 job 误报，读框架源码后修正；②修 2 个真异常孤儿主字段 job（410163303ac8 记忆例行压缩、490c86bf5979 泡影结算）用 HERMES_HOME=/Users/mac/.hermes hermes cron edit <id> --provider <p> --model <m> pin 回快照值——CLI 操作全局 jobs.json 必须带 HERMES_HOME 环境变量（jobs.json 锚定活动 profile home，gateway 跑在全局 home，裸 CLI 读 profile 目录找不到 job）；③修复后全量 PASS · 🔍源码实证（config.py/scheduler.py/jobs.py）+ 5 场景构造用例（null 主字段/孤儿快照/漂移/正常/no_agent）+ 真实 jobs.json 81 job 全量 + 端到端 D 层 FAIL→整体退出码 1 验证 · t_2ed14499

2026-08-31 · [阿普] terminal 安全守卫 \$()嵌套引号误拦修复（R-0831-03+P-0713-05，t_b92ac10e） · 合法复合命令（sed -n "\$(grep 'pat' f.py),+30p"、date+curl+ls+md5+ffprobe 一气呵成）被 hardline「malformed executable payload」无条件拦截，8/30 明慧对谈交付被迫拆 5 步；blocked-scripts 存档 8/24-8/31 至少 8 条同类误拦 · 根因链：_iter_shell_command_starts 正确把 \$() 内部识别为命令起点 → _quoted_grep_pattern_spans 对 \$() 内 grep 从自身位置 tokenize 到段尾 → 外层闭合引号（属 sed 的 "\）被 grep 视角误判为开启 → 引号失衡 tokens=None → fail-closed hardline。修复：tokens=None 时先整段视角复验（_shell_tokens_with_spans(segment,0)），整段通过=伪失衡→跳过该 grep（pattern 文本保留在检测输入中，只 over-match 不 under-match）；整段也失败=真畸形维持 fail-closed。改动仅 tools/approval.py _quoted_grep_pattern_spans 一处 · ①安全零回退实证：rm -rf /、mkfs、fork bomb、\$() 包裹恶意、合法\$()+尾部恶意、grep 参数内恶意全部仍拦；真畸形（grep 单引号真未闭合）仍 fail-closed；②测试套件修复前后 16 failed/392 passed 完全一致（全部存量失败，零回归）；③生效条件：hermes editable 安装（.pth finder），新进程即生效；6 个 gateway 均早于修复启动仍跑旧代码，自然重启（升级/卡死自愈）后生效，未主动重启（重启 apu=杀自己任务，重启其他 5 个中断进行中工作，收益不抵成本）；④验证脚本本身也会被拦：内嵌 heredoc+引号嵌套的 python -c 验证命令触发同款拦截，验证逻辑一律写成脚本文件再跑 · 🔍3 条真实被拦命令（blocked-scripts 存档）复现→修复后放行 + 恶意命令 10 项拦截回归 + 测试套件基线对照（stash 前后 16F/392P 一致） · t_b92ac10e

2026-08-31 · [阿普] web_search_plus 插件 fallback 显性化（R-0831-02，t_a98c04cd） · 广智显式传 provider=tavily 实际执行 exa（响应头 [Provider: exa] 无任何 fallback 提示），调用方误以为在用 Tavily 判断搜索覆盖面 · 根因链：Tavily 432 配额超限（非标准码，TRANSIENT_HTTP_CODES={429,503} 不含）→ race 竞速中 exa 先返回胜出 → search.py 已标 routing.fallback_used=true 但 __init__.py _format_results 非 auto 分支只输出 [Provider: exa] 丢弃 fallback 字段；且 race cancel 场景（tavily future 未完成被取消）fallback_errors 为空、stderr 日志因「还有 remaining」前置条件漏记。修复：①_format_results 三分支重构——显式 fallback 输出 [Provider: X · FALLBACK from requested 'Y']+失败原因行、auto 路由 fallback 输出 FALLBACK from auto-routed 'Y'（回归实测发现的同源问题）、冷却跳过附注；②race 循环失败必记 stderr 去掉 remaining 前置条件 · ①race cancel 是静默 fallback 的隐蔽形态：竞速赢家先返回时输家的 future 被 cancel，errors 列表为空，事后无法从 errors 还原失败原因，只能靠 routing.fallback_used 标记；②auto 路由同样受影响：路由选中的源失败后 fallback_used=true 但 auto_routed 仍 true，原逻辑走 auto 分支吞掉 fallback 信息（回归实测发现）；③432 是 Tavily 专属配额码：不在 transient 集合不重试（正确），但连续失败会进熔断冷却（provider_health.json），冷却期显式指定 tavily 会被 cooldown_skips 跳过直接走其他源；④插件是目录级 symlink（profiles/guangzhi/plugins/web-search-plus → 全局），改全局即改广智，零冗余 · 🔍单测 7 场景（显式 fallback×3/正常/auto+冷却/auto fallback/缓存）+ 真实端到端 2 场景（auto 路由 serper→brave、显式 tavily 432→exa/serper）+ py_compile + .pyc 已清 · t_a98c04cd

2026-08-31 · [乾婆] Memory 治理巡检 cron（ed72357de414）摘要投智囊团无 @ 乾婆——agent 型 cron 断头报警断点在 prompt 输出要求 · 正生指出：cron 每10天输出巡检摘要投智囊团，含「建议建卡项/告警/待裁决」却不 @乾婆，乾婆无法被唤醒处理，正生看到也只能手动转发（典型断头报警） · agent 型 cron（ed72357de414）断点在 prompt「输出」要求——只要求投递摘要，未要求按内容附唤醒；与 no_agent 型断点（在脚本里）不同 · 修复=改 cron prompt 加「唤醒铁律」（cronjob update，非脚本）：有建卡项/告警/待裁决→摘要末行必须输出真艾特 <at user_id="ou_ae20bf295662774a64380c274c43677f">乾婆</at> + 报告路径 + 待处理数；全部处理完→明示「本轮无待处理项」不加 at。open_id 用乾婆 app 视角（与 kanban_event_collector/FEISHU_AGENT_MENTIONS 同源），机制同 daily_briefing @阿普 先例。已读回 jobs.json 验证落盘 · ①agent 型 cron 的断头报警先查 prompt 输出要求（no_agent 型才查脚本）——凡输出含待办/建议/告警类内容的投递，输出要求必须二选一硬编码：有待办→真艾特负责人，无待办→明示无事，禁止中间态裸投；②本轮遗留：报告 P1「apu memory 自清 97%/93% 双超阈值」已建 t_ef308f84 给 apu；2 个 P3 观察项（ruhua 84%/paoying 82%）由巡检每10天自动复查不重复建卡；③已固化 dead-end-alert-closure 技能缺口修复记录 · 🔍读回 jobs.json 确认 prompt 含唤醒铁律+open_id · t_ef308f84

2026-08-31 · [阿普] SpeedCAT 半死节点：进程活着+7892 端口监听正常但出口 HTTPS TLS 握手全断，自动切节点在半死节点上重试无效 · API 可达性告警：FishAudio/GitHub 全部 SSL EOF（UNEXPECTED_EOF_WHILE_READING），DeepSeek/飞书走直连不受影响；告警自动切节点 3 次全失败 · 根因：SpeedCAT 当前节点半死——进程存活、端口监听正常，但代理出口对所有 HTTPS 站点 TLS 握手全断（FishAudio/GitHub/httpbin 全部 SSL EOF）；DeepSeek/飞书直连所以正常，与告警现象吻合；自动切节点那 3 次仍留在半死节点上重试故全失败 · 处置：手动跑 speedcat_node_health.py 强制切换（重启 SpeedCatCore+完成节点切换）；恢复验证 httpx 实测（FishAudio HTTP 404=真实响应可达、GitHub 200、httpbin 200）；fish_audio_availability.py（每5分钟）检测到「不可达→可达」转变会自动补发恢复通知，无需额外操作 · ①「进程活着+端口监听」≠「代理可用」——半死节点是 TLS 出口层故障，检测必须实测 HTTPS 出口而非只听端口；②自动切节点若在半死节点上重试会连续失败，需强制切换工具兜底；③恢复通知由 fish_audio_availability.py 自动补发，恢复闭环不断 · 🔍httpx 实测三站点恢复（FishAudio 404/GitHub 200/httpbin 200）

2026-08-30 · [乾婆] 飞书 markdown+艾特混用 → post 富文本不渲染 @（第二次踩，首次 8/2） · 回复里带 markdown（加粗/表格）+ <at user_id="ou_xxx">名</at> 混用，正生看到「尖括号+一长串 open_id 数字」原样显示 · 飞书 adapter 检测到 markdown 后把消息转成 post 富文本类型发送，而 <at user_id> 原生 @ 语法只在 text 消息正常渲染；在 post 的 md 元素里飞书不渲染，原样显示尖括号和 open_id 数字 · ①给正生的艾特回复要么纯 text 不带 markdown；②要么把艾特放开头第一句（纯文本部分），正文再用格式；③发送前自检：消息里提到的每个人都用了 <at user_id="ou_xxx"> 真艾特且消息类型为 text · 🔍8/2 首次反馈已在知识库记录（「2026-08-02 正生看到艾特后面跟一长串数字即此场景」），8/30 第二次踩同一坑，本次已固化教训 · 群聊铁律

2026-08-30 · [如花] 明慧对谈 Day39 长文本尾部表现力漂移（正生耳测） · 成品 9:40「藏识若清净，诸识浪不生」听感「机器人无情感朗读两句，像剪进去的」——既不像陈明也不像陈慧 · ① seg2 长达 293.9s（约 5 分钟）超双人建议 3-4 分钟，80% 尾部位置 Fish Audio 表现力漂移：音色 ID 不变（声纹 0.84/基频 219Hz 均指向 1c70ffcf），但问题句音高动态范围（p25-p75）仅 61Hz，正常句 105-172Hz，语调被压平 → 听感像另一个人/机器人；② 拼接点 5:39 不在 9:40，且 seg2 整段一次合成无单独替换——排除「剪进去」误判 · ① seg 长度控制：双人合成段尽量 ≤4 分钟，超长分段（每段 ~3-4 分钟）而非两段 5 分钟；② 用户报「某句音色不对」先走三查：合成日志 voice_ids / 声纹 / 基频动态范围，确认音色 ID 无误后查表现力压平（动态 <70Hz）；③ 修复=短句重合成（原参数）+ silencedetect 定位替换区间边界 + 三段拼接，成本低 · 🔍修复后问题句动态范围 98Hz 恢复，全链验证通过，成品 MD5 70b1a657 · t_20d95341

2026-08-30 · [如花] qianpo_log_standardize.py 数字转写漏网 8 类（t_6ff330dc） · 乾婆日志 20260830 标准化后剩余 104 个数字字符：run 编号（2205-2208）、90/90 被斜杠日期规则误转「九十月九十号」、需求编号序列 R-0829-01/02/03 被拆成「R 零八二九零一/二月三号」、大数字（131072/98304/204/400/429/403）、1M、qwen3-235b、时间缺「分」（04:10→四点十） · ① 90/90 是「预算耗尽」语境却被 14.9 斜杠日期规则当 m/d 日期转（90 月 90 号）；② 需求编号序列 /01/02/03 被斜杠日期规则二次误转；③ num_to_cn 只支持 4 位，131072 六位无法转写；④ 时间规则漏「分」字；⑤ 斜杠数字规则逐对匹配残留中间 /；⑥ qwen3-235b 中小写 b 不匹配 14.14 大写 B 规则 · ① 斜杠日期规则加月份限制 1-12（([1-9] · 1[0-2])/([1-9] · [12]\d · 3[01])）；② 需求编号序列规则增强：R-0829-01/02/03 展开为多个完整编号；③ num_to_cn 扩展 5-6 位（万/十万）；④ 时间规则非整点补「分」；⑤ 斜杠数字整串一次匹配（(?:\d{1,6}/)+\d{1,6}）；⑥ qwen 规则+小写 b 规则+@→在；⑦ 1-3 位裸数字兜底规则（400/429/403/16/12） · ①新增数字规则必须重跑并 grep 剩余数字核对（残留只允许任务ID hex）；②斜杠日期规则必须限定月份 1-12，否则「90/90」这类比值写法被误转；③连续斜杠数字必须整串匹配，逐对匹配会残留分隔符 · 🔍重跑后剩余数字仅任务 ID（t FF5FC4AF 等 30 字符），run/90/90/需求序列/大数字/时间全部正确 · t_6ff330dc

2026-08-30 · [如花] 独立 [pause] 行触发 s2.1 空转幻觉 7.3s「啊」声（t_20d95341） · seg1 开头结构「绕口令行< · speaker:0 · >[pause] + 空行 + 独立[pause]行（由[开场留白]经 pause_tag_fix 转换）+ 空行 + 正文」合成后，绕口令结束后出现 7.3s 连续非语言声（whisper「啊 啊 啊 啊」、SenseVoice「那那。」），正文首句被推后至 12.68s 才开始；trim_tongue_twister VTT 段合并故障（正文首句未被识别为独立段）裁切点 0.000s 失败，且脚本误用 7.735s 裁切点落在怪声中间 · 独立成行的 [pause] 无文本锚点 → s2.1 空转幻觉机制（与发声指令类标签独立行同源）。绕口令行已带 [pause]（全文开头最多一个 [pause] 铁律 4），独立 [pause] 行是冗余的第二 pause，触发空转 · ① 合成前检查 tts_input 开头：绕口令行已带 [pause] 时删后续独立 [pause] 行（[开场留白] 转换的独立 [pause] 优先删除）；② 合成后必查开头 0-15s 结构（正文首句应在绕口令结束后 0.5-1.5s 出现，4s+ 空洞=异常）；③ 重合成 seg1 成本极低（~3s），发现即重做不将就；④ trim 脚本 VTT 故障时手动定位：whisper_light + silencedetect 交叉，绕口令尾音后静音段 silence_end 作裁切点+补 1s 静音；⑤ speaker_mapping_check 用 --offset 0（绕口令 speaker 不在行首）+ --role-map 冒号格式 · 🔍本地验证（whisper+SenseVoice 双 ASR、silencedetect/volumedetect 波形、修复版 5.08s 起干净） · t_20d95341

2026-08-30 · [阿普] doukou@OpenRouter context_length 虚标 1M → 400 拒绝死循环（t_d899a847/t_3d945741） · 豆蔻切 openrouter 通道（qwen3-235b-a22b-2507，provider_routing only Parasail）后 kanban worker 连续 4 run protocol violation：输入 16-30 万 token、输出仅 265-425、assistant 正文全空只有 tool_calls、干转退出 rc=0 · 根因链：① doukou config model.context_length: 1048576（1M）虚标——qwen3-235b 官方 256K，而路由锁定的 Parasail endpoint 实测上限 131072（400 错误原文「This endpoint's maximum context length is 131072 tokens」）；② 压缩阈值基于虚标窗口计算（threshold=262,144），豆蔻 worker 工具（技能+经文文件）单轮吃 ~90K，第 6 次请求 134,509 tokens 被 400 拒绝；③ 死循环：每次压缩 7-8 分钟（qwen streaming 极慢）→ 压缩后 prompt 91,765 < 262,144 判定「已恢复」→ 重发 91,765+17,993(tools)+32,768(output预留)≈142K → 又 400 → 每会话 4 次 400、3 次压缩后放弃；④ 重放错乱加剧：压缩重插后消息顺序错乱（摘要→旧 tool_calls 重放→最初 user 消息重现），模型每次看到的「最新指令」都是最初的 work kanban task → 从头重跑 → 上下文再涨 → 再压缩；⑤ 任务描述中的现象全是这个循环的果；最小 agent 循环实测（3 轮 tool_calls 收敛、正常输出正文）证明 qwen3-235b 走 openrouter 的 tool_calls/多轮行为完全正常，排除模型行为与鉴权问题 · ① OpenRouter 分路由下 context_length 必须写路由锁定 endpoint 的真实窗口——模型标称≠路由 endpoint 实际（qwen3-235b 标称 256K，Parasail 实际 131072），配置虚标→压缩阈值失真→400 死循环；② 修复四项：model.context_length 1048576→131072、providers.openrouter.context_length 同步 131072、compression.threshold_tokens 98304（绝对兜底 cap）、protect_last_n 20→8；③ 数学验证：修复后 threshold=78,643，最坏 prompt+tools+output=129,403 < 131,072，结构性保证不再触发 400 循环；④ 诊断锚定提醒：现象「正文全空只有 tool_calls」极易误判为模型行为问题，先查配置层（context_length/压缩阈值）再怀疑模型 · 🔍本地验证（state.db 会话 token 数据+400 错误原文+最小 agent 循环实测+修复后数学验证） · t_d899a847

2026-08-30 · [阿普] 模型切换前置校验机制固化：verify_model_switch.py 三层校验+切换脚本集成（t_dc6548ad） · 8/30 凌晨事故（t_d899a847）暴露结构缺口：切换动作与「切换后验证」之间无强制环节，切完直接进生产链，配置宣称值与端点实际能力无核对 · ① 新建 ~/.hermes/scripts/verify_model_switch.py 三层校验：A 静态核对（model 块与 providers 段 context_length 两层一致+threshold_tokens ≤ 真实窗口）；B 端点实测（openrouter 走 /api/v1/models/<id>/endpoints 公开 API 查路由端点真实窗口，provider_routing.only 精确匹配锁定端点、无锁定取最小窗口=最坏情况；其他 provider 走内置注册表；config 宣称 > 端点实际 → FAIL 拦截）；C 动态循环（2 轮 tool_calls 往返实调，复现 kanban worker 工作模式）；② 集成 switch_profile_model.sh：cmd_switch 第 7 步（FAIL 自动回滚）+ cmd_override 写入前校验（ctx/threshold/key 取任务 assignee profile 真实配置，FAIL 不写入）；③ 退出码 0=PASS/1=FAIL 应回滚/2=WARN 放行 · ① 校验脚本读 config 用 SWPM_HERMES_HOME 覆盖（HERMES_HOME 在 gateway 内指向 profile 子目录，同 t_7c690cf8 坑 3）；② override 校验的 profile 来源是 kanban.db tasks.assignee，不是 ARGS[0]（那是 task_id）；③ 校验读的是切换后的 config——cmd_switch 第 7 步对「切换后正常态」PASS 是正确行为，端到端测 FAIL→回滚须让切换后 config 仍虚标（注册表 ctx 填超过端点最大值）；④ OpenRouter 同一模型不同端点窗口可差 8 倍（qwen3-235b: Parasail 131072 / GMICloud 262144 / Venice 128000），必须按锁定端点核对；⑤ 与 8/27「最小暴露窗口」纪律合并成八步清单（见 hermes-profile-model-config 技能）：冒烟→备份→改配置→回读断言→重启健康检查→前置校验→轻量首任务→24h 费用观察 · 🔍实测：doukou 全 PASS（端点 131072 命中+2 轮 tool_calls 真实往返）、apu 全 PASS（zhipu 直连）、虚标反例 FAIL exit 1（1M vs 端点 128000）、沙箱端到端 FAIL→自动回滚链路验证（run18） · t_dc6548ad

2026-08-30 · [阿普] 压缩重放错乱死循环模式：旧 user 消息重现导致任务从头重跑（t_d899a847） · 上述 400 死循环的伴生模式，独立记录因为它是通用陷阱（不依赖 context_length 虚标也会发生） · 机制：压缩重插后消息顺序错乱——压缩摘要（assistant 角色，micro-compact marker 设计行为）→ 旧 tool_calls 重放 → 最初的 user 消息（work kanban task）重现且时间戳保持轮次开始时间；模型每次看到的「最新指令」都是最初的任务指令 → 从头重跑 → 上下文再涨 → 再压缩 → 再错乱，形成第二重死循环；识别特征：① 同一 tool_calls 序列反复重复（如 kanban_show→skill_view→read_file 循环出现）；② user 消息重复出现且时间戳相同；③ 会话 input 16-30 万但 output 仅几百 · ① 压缩重放错乱是「干转退出 rc=0」类 protocol violation 的通用嫌疑，排查时先查 messages 表 user 消息是否重复+时间戳是否相同；② 压缩摘要为 assistant 角色是 _splice_micro_compact_result 代码设计行为，非异常；③ 该模式与 context_length 虚标互为放大器：虚标→压缩频繁触发→错乱概率上升 · 🔍本地验证（doukou state.db messages 表逐条比对，tool_calls 序列重复+时间戳相同实证） · t_d899a847

2026-08-30 · [阿普] OpenRouter 免费档四模型横评：限流是一票否决项+inkling 403 硬拒（t_5c501e94） · 正生拍板部分代理工作量迁移免费模型（长期费用超支背景），需实测候选能否胜任 agent 多轮工作；8/27 教训「免费档上游路由不稳定」需量化验证 · ①限流压测（30 连发+1min 后 10 连发）：minimax-m3:free（GMICloud 路由）46 次零 429；laguna-s-2.1:free（Poolside 单上游）26% 软限流（metadata.raw=upstream 限流，退避 30s 可恢复）；glm-5.2:free 跨 26 分钟 40+ 次 100% 429 全灭；inkling:free 403 硬拒（agentic harness only，非限流）；②中文 3 题×2 次对照 glm-5.3-flash 基线：minimax 接近基线（诊断题洞察深但内容方差大、q3 数错 heartbeat），laguna 代码题强（SWE-bench 70.2% 属实）但运维题 JVM/Linux 命令错配 macOS；③结论：minimax 可切泡影，laguna 降级可用（纯代码），glm-5.2/inkling 否决，阿普暂不切 · ①:free ≠ 裸 API 可用——inkling 类 agentic-harness-only 模型列表可见但调用 403，选型前先发 1 次探测；②免费档日限额（官方文档🔍）：未充值 50 次/天、充 $10 后 1000 次/天，本 key is_free_tier:false（充 $3.30 未满 $10）仍按 50 次档——切换前必须先充值；③429 分平台限额（X-RateLimit 头）与上游限额（metadata.raw）两类，读响应体区分；④Hermes agent.api_max_retries 默认 3（共 4 次）对速率限制自动重试后才 fallback——软限流可被吸收、持续限流救不了；⑤glm-5.3-flash 直调思考吃 max_tokens 预算致正文为空，必须带 reasoning_effort:low · 🔍实测：四模型 probe+压测+质量全流程（OpenRouter 侧约 130 次调用），key 状态 GET /api/v1/key 实查，官方 limits/configuration 文档核实 · t_5c501e94

2026-08-30 · [阿普] switch_profile_model.sh v2 全量升级：五profile+短名+override层+双防护（t_7c690cf8） · 模型切换要手改 config+备份+SOUL 同步+重启，操作重且易错；旧版只支持 doukou/apu、无 override 层、thinking 硬编码 enabled 会破坏 07-25 拍板 · ①重写 switch_profile_model.sh：PROFILES 注册表（profile · 温度 · thinking 按 07-25 拍板）、短名模糊匹配（glm/ds-pro/minimax 等+唯一前缀兜底）、provider/model 全名解析、--override/--override-clear 走 hermes kanban set-model（dispatcher spawn 透传，无需重启）；②内嵌 heredoc 拆成 _swpm_*.py 五个辅助脚本（网关静态扫描拦 python3 -c/heredoc）；③双防护：冒烟失败配置不动+重启后 launchctl 健康检查失败自动回滚；④zhipu 切换同步写 agent.reasoning_effort（真正生效层），切走时删除恢复原状 · ①default（乾婆）不纳入本脚本（正生 8/30 拍板，乾婆用 qianpo_switch_model.sh，两套互不干涉）；②演练 doukou/guangzhi 全流程通过（切换→验证→回滚，config/SOUL 均还原）；③override 层实测写入/清除/未注册全名三场景通过 · 🔍实测：doukou+guangzhi 切换→验证→回滚全流程、override 写入/清除、冒烟失败自动放弃（配置未动）、--list 全 profile 状态 · t_7c690cf8

2026-08-30 · [阿普] setdefault("extra_body",{}) or {} 空dict falsy 陷阱：写入静默丢失（t_7c690cf8） · guangzhi 切 glm 后回读断言 temp=None——apply 明明写了 temperature · entry.setdefault("extra_body", {}) or {}：键不存在时 setdefault 返回新建的空 dict，空 dict 是 falsy，or {} 又创建另一个新 dict，temperature/thinking 全写进孤儿对象，entry 里的还是空 dict。v1 未暴露是因为 doukou/apu 的 entry 本来就有非空 extra_body（truthy） · 去掉 or {}，直接 eb = entry.setdefault("extra_body", {}) · ①setdefault(k, {}) or {} 是 Python 反模式——setdefault 已保证返回 dict，or 兜底反而制造孤儿对象；②「写入成功但读不回」先怀疑对象身份分裂（id() 对比），不是写入语句没执行；③回读断言必须断言到叶子字段（temperature/thinking），只断言 model.default 会漏掉 extra_body 丢失 · 🔍实测：备份文件复现实验（id 对比+dump→reload 确认 extra_body:{}），修复后 guangzhi 切换回读 temp=0.5+reasoning_effort=high · t_7c690cf8

2026-08-30 · [阿普] SOUL.md 模型名替换子串误伤：provider 短词破坏复合词+大小写不匹配漏替换（t_7c690cf8） · guangzhi SOUL「通过 DeepSeek-v4-flash 运行」被切换脚本破坏成「通过 智谱-v4-flash 运行」 · SOUL 里写的是 "DeepSeek-v4-flash"（大写D），既不匹配 display name "DeepSeek V4 Flash"（空格）也不匹配小写 model id "deepseek-v4-flash"（大小写），但 provider 短词 "DeepSeek" 是其子串被先替换 → 破坏复合词且模型名替换漏掉 · _swpm_soul.py 改正则边界断言替换（前后不能是字母/数字/连字符/下划线）+ IGNORECASE；破坏串「智谱-v4-flash」注册进 SOUL_EXTRA_PHRASES 由回滚流程自动修复 · ①SOUL 模型描述写法不统一（大小写/连字符/空格混用）是替换类工具的天然雷区，边界断言+IGNORECASE 是治本；②provider 短词（DeepSeek/智谱）永远不能裸替换，必须带边界；③SOUL.md 是受保护文件，patch 工具直接编辑会触发审批超时——破坏修复走 SOUL_EXTRA_PHRASES 注册让脚本自己修 · 🔍实测：guangzhi 回滚后 SOUL 恢复「DeepSeek V4 Flash」+ 再切换无破坏（x1 精准命中） · t_7c690cf8

2026-08-30 · [阿普] HERMES_HOME 环境变量污染脚本路径：gateway 内指向 profile 子目录（t_7c690cf8） · switch_profile_model.sh --list 全部「读取失败」，_swpm_read_cfg.py 报 can't open file '/Users/mac/.hermes/profiles/apu/scripts/...' · gateway 进程环境里 HERMES_HOME=/Users/mac/.hermes/profiles/apu（profile 子目录），脚本 ${HERMES_HOME:-$HOME/.hermes} 继承后把辅助脚本路径解析到 profile 子目录下（不存在）。8/29 验证脚本实踩过同款坑（model-quick-switch 技能有记录），但主脚本没防 · 脚本改用专用变量 SWPM_HERMES_HOME 覆盖，不信任继承的 HERMES_HOME：HERMES_HOME="${SWPM_HERMES_HOME:-$HOME/.hermes}" · ①在 gateway 内跑的脚本凡用 HERMES_HOME 做路径解析都要防污染——gateway 环境的 HERMES_HOME 是 profile 级不是全局级；②同类脚本（qianpo_switch_model.sh 用绝对路径写死）不受影响；③通用教训：环境变量做路径解析前先确认其在目标执行环境里的真实值 · 🔍实测：--list 修复前全失败/修复后五 profile 全部正确显示 · t_7c690cf8

2026-08-30 · [阿普] OpenRouter provider routing 锁定落地：doukou config 顶层 provider_routing.only=[Parasail]（t_d14a769b） · 豆蔻千问通道费用爆表根因（默认路由分散 7 家上游价差 3.3 倍+provider 切换致 prompt cache 全失效）需在配置层根治，为下次切回千问预修通道 · ①doukou config.yaml 顶层注入 provider_routing: {only: [Parasail]}（备份 .bak.20260830，444 回锁）；②源码核实生效链路：gateway _load_provider_routing()（run.py:9774）→ AIAgent providers_allowed → _provider_preferences_for_agent()（chat_completion_helpers.py:563）→ OpenRouter profile build_extra_body() → wire extra_body.provider；③官方子键集 only/ignore/order/sort/require_parameters/data_collection，不支持 allow_fallbacks——only:[X] 语义=只允许 X 禁止 fallback 到列表外，等价于 order:[X]+allow_fallbacks:false；④实测：doukou key 最小请求 only:[Parasail] → 响应 provider=Parasail ✅，默认路由对照 → Novita（分散实锤） · ①provider_routing 是 config.yaml 顶层键（与 model: 同级），不是 providers 段内——providers.openrouter.extra_body 注入 provider 参数不是官方路径；②only 语义等价 order+no-fallback，无需硬 hack；③deepseek 主模型不受影响（DeepSeek profile 不消费 provider_preferences）；④改完必须重启对应 profile gateway 才对网关会话生效；⑤锁定上游大小写须与 endpoint 名一致（Parasail 非 parasail） · 🔍实测：三组对照请求（only/order+no-fallback/默认）响应 provider 字段验证 + YAML 回读断言 + diff 备份确认仅新增 routing 块 · t_d14a769b

2026-08-30 · [阿普] session DB 重复持久化三形态归因：压缩重放/stalled 重试重持久化=mid-turn bug 实锤，网关重启注入=非 bug（t_f32a0862） · 巡检接入时对历史重复会话归因发现三种形态机制不同：①apu 20260709 会话 12575 行中 11660 行完全重复（同 role+毫秒时间戳+content），重放副本插入时间与 [CONTEXT COMPACTION] 事件秒级相关（00:21:48 压缩→00:21:53 副本）=压缩 rotation 整块重放；②default 20260809 会话同一消息 24 次、每次时间戳不同，每个副本前都有 assistant「Operation interrupted: waiting for model response (26.0s)」或压缩标记=stalled 重试重持久化（#78981 同类）；③apu 20260630 会话 23 条 [System note: ...interrupted by a gateway sh...] 间隔 13-49s 且两会话同秒交错=网关重启循环向所有活跃会话广播注入，每条对应一次真实重启 · ①「相邻重复」检测口径只暴露冰山一角（9 组），按「同 session+role+timestamp+content」完全重复口径两库合计 24355 行冗余（apu 16170/default 8185），重灾区 20260709 会话 92.7% 是重复行；②归因判别要点：重放行保留原始毫秒时间戳=整块重插（压缩/rotation），副本带新时间戳+前有 stalled/压缩标记=重试重持久化，System note 类=网关重启注入（非 bug）；③归因工具已固化：check_session_dup_persist.py --detail <session前缀> 输出重复 run 时间戳明细 · 🔍本地验证：sqlite 逐行核验三会话 rowid 序列+时间戳+交错行定位插入时刻；检测脚本 --json/--detail 实测；wiki_guardian.py 巡检集成实测出报告 · t_f32a0862

2026-08-30 · [乾婆] Apple Notes 备忘录 osascript 读取正文变掩码：隐私摘要折叠，SQLite 直读绕过 · 正生录入 3 把 OpenRouter 完整 key 到备忘录，乾婆 osascript 读 plaintext/body 全部显示「sk-or-...77bb」掩码，key 任务装不上 · Apple Notes 对含敏感样式（卡号/key 类长 token）内容自动做摘要折叠，AppleScript 接口拿到的是折叠后的展示层，非真实存储内容。绕过：直读 ~/Library/Group Containers/group.com.apple.notes/NoteStore.sqlite 的 ZICNOTEDATA.ZDATA（gzip 压缩 protobuf），解压后为完整 HTML 正文 · ①读备忘录拿不到预期内容时，先怀疑展示层折叠而非「没写」；②敏感 key 类信息系统可能多层折叠，SQLite 直读是可靠路径；③key 装载后临时文件即删，明文不落聊天 · 🔍实测：osascript plaintext/body/note id 三路均掩码，SQLite 解压得 3 个完整 key（73 位）逐一验证 /auth/key 200 · 20260830-key

2026-08-30 · [乾婆] 分流规则缩写致语义漂移：两次人名/主体错误被正生抓出（「不分流广智」实为「保留阿普」） · memory 压缩条目时把「分析/判断类保留阿普Pro不降级分流」缩写成「永不分流广智」——主体（阿普）丢失、宾语（广智）错位 · 压缩改写规则类条目时丢主体/丢语义是系统性风险：规则条目的「谁该做」是人名级事实，缩写改写不能凭记忆重组，必须逐字对照原拍板记录 · ①凡涉及「谁该做」的规则，写 memory 前核对拍板原文；②分流三问已固化进 task-creation-sop（含 default 自留分支——三流完整：阿普=复杂技术/根因诊断、泡影=标准运维、乾婆=default=管理/设计/监督判断类自留，8/23+8/26+8/30 拍板） · 🔍实测：memory 条目已改正；SOUL 筛查任务实案验证（先误派阿普，按分流标准应派泡影，正生指出后改派并固化三问） · 20260830-分流

2026-08-30 · [阿普] Hermes 版本横幅「upstream 61a2ff63」是 v0.20.5 的基线记录而非本地 HEAD——升级跨度从误判的 45 天（7/13→8/27）修正为 6 天（8/21→8/27），内参选题分析据此误判 P1 背景规模（t_74783b27） · 内参选题分析与看板任务背景均写「本地 HEAD 停在 7/13（61a2ff6348），落后约 1507 commit」；git 实测：本地 HEAD=fcbd1076a9=官方 tag v2026.8.19（8/21 发布），61a2ff6348 是版本横幅里「upstream 61a2ff63 · local fcbd1076 (+9460 carried commits)」的基线字段；1507 commit 跨度属实但区间是 8/21→8/27 爆发期（8/23 单日 237 commits），且 8/25 已升级过一次（stash@{0} pre-v2026.8.19-local-patches-20260825 为证） · 评估报告（升级风险评估-20260830.md）开篇设「版本事实修正」节，先修事实再下结论；升级风险重估：跨度 6 天、有 8/25 完整先例路径可复用、TCC 风险因本地 venv 是 miniforge symlink（非 uv-store）而降低 · ①版本横幅多字段语义要逐个核实：「upstream X」=基线、「local Y」=HEAD、carried=本地领先数，把基线当 HEAD 会把升级跨度放大数倍；②hermes CLI「11 commits behind」计数与 git rev-list 实测（1507）不符，版本跨度判断以 git rev-list 为准，CLI 自报计数不可信；③评估类任务先核实任务背景中的事实前提，背景错了结论全歪——本次「1507 commit」碰巧对但「7/13 起点」错，半对半错最危险 · 🔍git log -1 fcbd1076a9（=v2026.8.19 tag 指向）+ git rev-list --count fcbd1076a9..99c3cad857（=1507）+ git stash list（8/25 升级先例）+ venv/bin/python3 realpath（miniforge symlink） · t_74783b27、t_f32a0862

2026-08-30 · [阿普] apu 私有补丁技能体系整建制合并进全局外置技能（正生裁决：共享知识不拆两地） · apu-model-opportunity-patches 补丁被正生指出与「不在私有目录留冗余技能」约定不符——同一技能拆两地，别人（泡影挂载）只能用到外置部分，只有阿普能两部分合用；引申盘点发现 apu profile 共 14 个外置技能补丁（~269KB）+ 2 个整本迁移技能（hermes-config-diagnostic 225KB / hermes-gateway-operations 1078KB 含版本史） · 14 补丁正文全量并入外置对象 references/apu-patches-<名>.md + 本体加指针节，子 references 文件随迁（前缀 apu-<补丁>--），补丁目录删除；2 整本连版本史整目录迁回全局 devops/；cron/看板活跃任务/脚本三通道依赖核查零命中，8 处技能引用 + 2 处 memory 改指新路径，幽灵引用扫描归零，技能索引重跑 290 个 · ①技能归属边界：共享知识→合并进全局外置技能（跨 profile 软护栏 cross_profile=true 直接跨，正生已授权）；独属自己的→私有目录可以留；②外置只读技能的 apu-*-patches 新建路径退役，增量直接 patch 进外置本体升版本号；③删技能前查三通道（cron jobs.json / kanban skills 字段 / 脚本 grep），文本引用全库扫 · 🔍终验：14 目录清零 + 合并文件落位抽查 6/6 + 幽灵引用 0 + 活跃技能 81→63 对账（-14 补丁 -2 整本 -2 归档口径） · t_5c501e94 后续

2026-08-30 · [阿普] 豆蔻回迁 deepseek-v4-pro：跨 provider 切换后模型专属配置段（provider_routing）必须人工审查（t_bf5dbfda） · 豆蔻 8/30 凌晨切千问@OpenRouter 后 400 死循环（见 8/30 context_length 虚标条目），正生拍板回迁 DS V4 Pro 固定使用。回迁用 switch_profile_model.sh 一次通过（冒烟+备份+5项校验全 PASS）。配置里留有 t_d14a769b（8/30 OpenRouter 费用路由优化）有意注入的 provider_routing.only=[Parasail] 路由锁——该锁仅对 openrouter 通道有意义 · ①该锁在豆蔻走 deepseek 后完全不生效（provider_routing 只作用于 openrouter 路由），但保留是跨模型地雷：未来切 openrouter 任意模型（如 minimax，无 Parasail 端点）会被错误锁死导致 400/无可用端点；②已移除该段并在原位留注释（如需锁定端点，切换时再显式配置，方法见 wiki「OpenRouter provider 路由费用陷阱」页）；③providers.openrouter 段保留（可用清单无害）加「当前未启用」标注；④回迁后网关重启（break_glass.py restart doukou）+ api_server 实调冒烟，agent.log 实证 model=deepseek-v4-pro provider=deepseek HTTP 200；⑤t_d14a769b 的「待 doukou gateway 重启后生效」待办随本次重启+锁移除一并闭环 · ①切换脚本只管「切到谁」，不管「上个模型的路由残留」——provider_routing 等模型专属段在跨 provider 切换时必须人工审查（switch_profile_model.sh 不处理此段，已验证 grep 零命中）；②为特定目的打的配置补丁（如费用路由锁）在前提消失（模型退役）时必须同步退役，否则从优化变成地雷；③移除前先查该配置的注入历史（log.md/session_search），区分「事故遗留垃圾」与「他任务有意注入」——本次属后者，表述和处置都要尊重原意图；④豆蔻通道冒烟验证走 api_server（8645）实调 + agent.log 断言，比只看配置回读更实证 · 🔍实测：切换脚本 5 项校验 PASS + YAML 结构断言（provider_routing 已除/model 块两层一致/thinking dict）+ 重启后 agent.log「API call #1: model=deepseek-v4-pro provider=deepseek」+ api_server 200 · t_bf5dbfda、t_d14a769b

2026-08-30 · [阿普] 广智轮次耗尽真凶是原典抓取（execute_code 自写循环抓网页），不是查重——既有教训归因修正（t_0d8a4cb1） · 乾婆 8/30 实测 cross_day_dedup.py 一键 77 秒跑通 14 条查重，但广智当天 90/90 轮耗尽被打断，任务背景假设「广智绕开一键脚本自写循环比对」；技能 §⑤ 既有教训也把 144 次调用归因为「查重循环」 · 广智 state.db 实证（session 20260830_045305_c886a4，426 条消息 13 分钟）：①去重脚本 05:03 已正确运行（14 条新素材→10 疑似，清单落盘），查重环节无问题；②57 次 execute_code 全是 subprocess+PROXY=7892 逐页抓原典网页（维基文库楞伽经 70 次、台大佛学站 big5 编码失败重试、CBETA XML 等），单次失败返回 50KB 乱码整块进上下文，tool 输出 484KB 占 95%，04:55-04:58 每分钟 54-72 条消息打满轮次；③Day38 同模式（24 次 execute_code 抓网页）；④轮次趋势 71→72→86→90 与抓取难度（原典页编码/反爬）相关而非查重 · ①诊断先看数据再信任务背景——「57 次 execute_code」的表象与「绕开查重脚本」的假设之间隔着一步实证，本次直接推翻了任务背景和既有技能教训的双重归因；②轮次黑洞主因=原典抓取无纪律：同页多方式重试+编码失败不换源+50KB 乱码整块进上下文；③一键脚本本身无易用性问题（14 条素材裸跑 3.3 秒，--new 单参数即可），无需改默认值；④技能 §⑤ 已修正归因并新增「原典抓取纪律」（同页最多 2 种方式、编码失败立即换纯文本源、失败 2 次改叙述性转述） · 🔍guangzhi state.db 逐 session 统计（execute_code 内容特征=抓取非查重）+ 每分钟消息分布 + tool 输出体量占比 + Day39 story_names.txt 裸跑实测 3.3s（14 条→7 疑似 7 通过，与乾婆 77s 实测一致） · t_0d8a4cb1、t_99651b6b

2026-08-30 · [阿普] 如花校验链合并为一键 tts_full_verify.sh：编排层三个坑（macOS 无 timeout / set -u 下 $! 展开 / role-map 需按场景映射）（t_3782da14） · 治本任务：如花 27 步决策树中合成后校验环节（post_synthesis_verify/speed_validation/tts_postcheck/check_emotion_labels/speaker_mapping_check）分散调用=每道脚本多个轮次，8/30 t_16ae9003 一轮 90 轮耗尽 193 次 terminal · 编排层脚本 tts_full_verify.sh（/Users/mac/.hermes/profiles/ruhua/scripts/）一次运行逐项调用+汇总 PASS/WARN/FAIL，单脚本逻辑零改动。实测踩中三坑：①macOS 无 GNU timeout 命令（exit 127）→ 三级回退 timeout→gtimeout→perl alarm；②bash set -u 下 perl -e 内联脚本的 $! 被 shell 展开 → unbound variable，须转义 \$!；③speaker_mapping_check 默认 role-map=阿普:0,乾婆:1，明慧对谈等场景必须传 --role-map 澄明:0,澄慧:1（编排层按场景自动选）+ speed_validation 在脚本无 speed 元数据时需按场景兜底（佛学 1.0） · ①编排层不复制逻辑、只做调度——单脚本保持独立可调用（排障指针），总入口只加参数组装+退出码映射（0/1/2→PASS/WARN/FAIL）；②macOS shell 脚本禁用 GNU 专属命令，超时用 perl alarm 兜底；③子脚本的默认参数不等于正确参数——role-map/speed 这类场景相关参数由编排层按场景表统一注入；④怪声 rework 分级触发时编排层如实报 FAIL，处置仍走铁律 21.5 双 ASR 复核（编排层不做语义判断） · 🔍Day39 明慧对谈四件套实测 4 轮迭代：终轮 [1]FAIL(怪声rework×2，已知误报区待人工复核)/[2]WARN/[3]PASS/[4]WARN/[5]PASS(131条全一致)，汇总报告+JSON 输出正常，退出码语义正确 · t_3782da14、t_16ae9003

2026-08-30 · [阿普] guangzhi/ruhua agent.max_turns 90→150（治标兜底，配合校验链合并治本） · 如花 8/26×2、8/27、8/28×2、8/30 连续多日 90/90 轮耗尽；广智 8/30 亦 90 耗尽（根因=原典抓取，另案处理） · break_glass.py set 两 profile agent.max_turns=150（444 回锁+审计日志+.pyc 清理）→ break_glass.py restart ruhua → gateway.log 实证 Agent budget: max_iterations=150（16:50:29）；guangzhi 因本 worker 是其子进程（claim lock 18404=guangzhi gateway PID），用脱离会话延迟重启脚本（Popen start_new_session，轮询 worker 退出→restart→抓日志实证→写持久证据文件） · ①重启 gateway 前必查进程树：kanban worker 常是某 gateway 的子进程（claim lock 的 PID 即该 gateway），直接重启=自杀，须用 start_new_session 脱离+延迟到 worker 退出后执行；②max_turns 上调是治标兜底，治本=校验链合并（同任务第 1 项），两者配合；③break_glass set 自带 444 回锁+审计+.pyc 清理，改配置优先走它不走手工 chmod · 🔍ruhua gateway.log 16:50:29 max_iterations=150 实证；guangzhi 证据文件 ~/.hermes/kanban/deliverables/t_3782da14_guangzhi_maxturns_evidence.txt（延迟脚本自动写入） · t_3782da14

2026-08-30 · [阿普] qwen3-asr-flash 必须纯 audio content 不带 text，带 text 即 400（t_ff6db6d4 听审引擎选型实测） · 为如花云端听审选型实测 8 轮：qwen3-asr-flash 走 dashscope 原生 multimodal-generation，content 数组带 {'text': '转写这段音频'} 时稳定 400 InternalError.Algo.InvalidParameter: The dedicated task 'asr' does not support this input，wav/base64/file:///SDK 四种姿势均同错 · 去掉 text 元素只留 {'audio': 'data:audio/mp3;base64,...'} 立即 200；实测转写准确率优于 GLM-ASR（GLM 限长 0-30s + 2.5s 极短段「没听到」幻觉 + 幻听加字），audio_tokens≈25/秒音频计量透明；qwen-omni-turbo（audio_output=false）怪声检出 4/4（含人工注入 1200Hz 哨声），一次调用同时返回内容+怪声定位+听感，定为听感引擎；gemini-2.5-flash 三通道全灭（Google API 香港出口不支持 + OpenRouter 直连/7892 代理均 403 地区限制）移出候选 · ①dashscope 专用 ASR 模型不吃文本指令，调用姿势=纯 audio content；②qwen2-audio-instruct 当前 403=免费额度耗尽（Throttling.AllocationQuota），非能力问题；③选型结论与调用要点固化在 wiki「云端听审引擎选型」概念页，报告 ~/.hermes/reports/t_ff6db6d4_听审引擎选型实测报告.md · 🔍8 轮实测 results_round1-10.json（4 段素材：正常 30s/真实 suspect×2/人工注入哨声 29s） · t_ff6db6d4

2026-08-30 · [阿普] 云端听审落地三坑：超短段转写需 context-pad / SequenceMatcher 对超短段不公平 / agent profile 下 HERMES_HOME 指向 profile 目录（t_178acca6） · audio_listen_relay.py（~/.hermes/scripts/，vision_relay 模式）接入 tts_full_verify.sh 第[6]项后，Day39 真实成品 12 段 suspect 首轮复核 5/5 全落 suspect——云端 omni 判 normal、ASR 转出「嗯/来/让」实义语气词，却因转写吻合度阈值 0.6 达不到而无法放行，云端复核没发挥「免人工抽听」价值 · ①suspect 段常 <1s，直接截取云端 ASR 转写质量差（转出"Yeah"等噪声字）→ --context-pad 1.5 前后各扩 1.5s 截取（判定仍以原始边界为基准，cut_window_sec 记录实际窗口），转写质量显著提升；②1 个字 vs 60 字窗口的 SequenceMatcher ratio 必然极低 → 超短段改用「转写包含于脚本窗口」（in_script）+「实义中文转写=人声证据」判定，不用 ratio 阈值；③agent profile 运行时 HERMES_HOME=~/.hermes/profiles/apu，load_env 只扫该目录会漏全局 key → 扫 ENV_SEARCH_ROOTS（全局 ~/.hermes + HERMES_HOME）双根去重合并。修复后 12/12 PASS 免人工抽听，人工注入哨声段正确 REWORK，云端故障降级 suspect 路径实测通过 · ①超短音频段的云端复核必须带上下文，裸截取的转写不可信；②相似度阈值判定对长度悬殊的字符串对比天然失效，短串应改用包含判断；③脚本要兼容 agent/CLI 双运行环境，凭证扫描不能只依赖 HERMES_HOME 单根；④编排层接入用「清单存在才调+故障降级 WARN」模式，云端依赖不阻断本地校验链 · 🔍Day39 成品 12 段全量复核 12/12 PASS + 注入哨声 REWORK + monkeypatch 网络故障降级 suspect + 30s/5段双上限实证（0-60s 请求实际截 30s，12 段清单默认只跑 5 段 truncated=7） · t_178acca6、t_ff6db6d4

2026-08-30 · [阿普] 泡影 minimax 切换后全瘫根因：凭据池 seed 硬编码只读 OPENROUTER_API_KEY 变量名，profile 专用 key 名（OR_PAOYING_API_KEY）池子拿不到（t_b867b5a7） · 泡影 11:11 切 minimax free 后当天真实消息零成功；17:08 如花 @ 泡影无响应，gateway 日志 credential pool no available entries ×5 + openrouter unhealthy(payment/credit error) + RuntimeError No LLM provider configured，仅发 91 字错误兜底 · 根因链：①agent/credential_pool.py:2961 openrouter seed 硬编码 _get_env_prefer_dotenv("OPENROUTER_API_KEY")，不读 config 的 key_env 字段；②泡影运行时 HERMES_HOME=profiles/paoying，load_env() 只读 profile/.env——那里只有专用名 OR_PAOYING_API_KEY，没有 OPENROUTER_API_KEY 变量名 → 池子拿不到专用 key；③池子回退读全局 auth.json 的 OPENROUTER_API_KEY（另一把 key），17:08 该条目被标 payment error → 全灭；④switch_profile_model.sh 冒烟找 key 顺序 profile/.env→全局.env，profile 缺变量名时静默回退全局 key 冒烟通过 → 验证失真误报成功 · ①治本采纳乾婆轻量方案：泡影 profile/.env 追加 OPENROUTER_API_KEY=<OR_PAOYING_API_KEY 同值>（零源码改动，load_env 按 mtime 热加载免重启）；实证：池条目 secret_fingerprint=sha256:74e4ef36d125=专用 key 指纹，last_status 清空；②真实飞书消息驱动完整回复（18:17 入站→18:18 回复 5.8s API 200）；③冒烟缺陷修复：解析顺序对齐运行时（profile ${key_env}→profile 专用名 OR_<PROFILE>_API_KEY→全局回退），key 来源打进日志，4 profile 场景复测全过；④如花 OR_RUHUA_API_KEY 同款地雷已被冒烟修复覆盖 · 🔍本地验证：池条目指纹+agent.log API 调用+冒烟 4 场景 · 20260830-paoying-key

2026-08-30 · [如花] audio_listen_relay.py JSON 结构化提示词削弱 qwen-omni-turbo 怪声检出（t_178acca6 交付缺陷，修复任务 t_6f7d6df3） · 上游选型（t_ff6db6d4）用自然语言长提示词逐项问 → omni 怪声检出 4/4 全中（含人工注入 1200Hz 哨声）；relay 封装后对同一段注入哨声素材（/tmp/audit_test/seg_artifact29.mp3，15s 处 1200Hz 哨声）判 normal 漏检 · relay 把上游验证过的自然语言提示词换成 JSON 结构化约束（DEFAULT_LISTEN_PROMPT 含「判定标准」），JSON 约束削弱了 omni 的怪声检出能力；乾婆 listen_B1/B2/B3 三份报告 + relay 源码交叉验证结论成立 · ①云端听审诊断提示词优先自然语言逐项问，不要为可解析性牺牲检出灵敏度；②「verdict 可解析」与「检出能力」分开设计——结构化输出可以做，但约束不能砍掉模型逐项听的自由度；③修复方向=恢复自然语言提示词思路+保持 verdict 可解析，三条哨声素材（含 seg_artifact29.mp3）已写入 t_6f7d6df3 回归清单 · 🔍同文件同引擎实测对比：长提示词检出「第8秒处明显哔声」vs relay JSON 提示词判 normal；listen_B1/B2/B3 三份报告 · t_6f7d6df3、t_178acca6、t_ff6db6d4

2026-08-30 · [阿普] web-search-plus 熔断器 v2 落地 + 代理链路根因（t_f7ae40d0，P-0802-03 治本） · web_search_plus 三 provider（Tavily/Brave/Serper）频繁同时超时，7 月爆发 5+ 次；历史痛点 P-0707~P-0714 反复收敛证明表层补丁治不住 · 根因链：①三 provider 共享 SpeedCAT 代理链路，代理波动期全体同时超时（广智库 state.db 251 条「Search timed out after 75s」集中 6/30、7/1、7/12、7/16-18，与 SpeedCAT 波动期吻合）；②插件熔断器只建了一半——mark_provider_failure 会写冷却状态但 provider_health.json 从未落盘（消费点存在但状态从未生效）；③race 模式代理一挂全 provider 同时进冷却，只剩 1 个硬试无半开探测；④tavily 超时重试 3 次（+13s backoff）叠加 research 串行 3×30s=270s > 外层 180s 必爆；⑤brave 返回 gzip 响应时 utf-8 解码崩溃（Cloudflare 强制 gzip） · 修复（search.py 熔断器 v2）：①连续失败阈值熔断（WSP_CB_FAILURE_THRESHOLD=2，单次抖动不熔断）；②半开探测（冷却期满放行 1 个探测请求，成功即完全恢复）；③代理故障直连 fallback（滑动窗口+代理/直连双探测，WSP_CB_PROXY_FALLBACK=1 默认开）；④make_request/make_get_request/you/searxng 4 处接入 _read_response_body 处理 gzip/deflate；⑤备份 search.py.bak-20260830。测试：熔断器 11 项单测 + gzip 3 项 + E2E 4 项全过（断 key→自动跳过走备选→恢复后自动放行） · 🔍本地验证：E2E 真实 CLI 搜索 + mock 代理死直连路径真实搜索 3 条结果 · t_f7ae40d0

2026-08-30 · [阿普] audio_listen_relay.py 漏检修复落地：双层架构（自然语言提示词+频谱交叉验证）+ omni 两大幻觉形态实证（t_6f7d6df3） · 承接 86 条（如花发现 JSON 约束漏检）：59 轮提示词 A/B 实验证明单层提示词无法两全——自然语言逐项提示词检出 3/3 但对正常段幻觉报哨声 3/3（位置幻觉甚至超素材时长），旧 JSON 提示词 0/3 误报但检出 0/3；且 omni 存在「分析-结论脱节」（B1 素材 3/3 复现：分析文本报哨声 7.95-8.06s 但 verdict 字段填 normal），盲信 verdict 字段是第二层漏检 · 修复（audio_listen_relay.py v2，~/.hermes/scripts/）：①提示词层=自然语言逐项分析+verdict JSON 尾置+片段实际时长位置自洽约束（LISTEN_PROMPT_TMPL，{dur} 截取后填入）；②解析层=parse_verdict 脱节修正（分析文本报怪声+位置自洽 > verdict 字段，B1 形态 normal→noise）+位置超时长视为幻觉不采信；③物理层=频谱窄带纯音交叉验证 detect_tone_windows（800-2400Hz 分窗 FFT，峰纯度≥0.40 且 SNR≥12dB，≥2 窗持续；判据在 6 条素材 6/6 区分：注入哨声纯度 0.40-0.50 vs 语音谐波 ≤0.144）；④决策矩阵=noise+纯音→rework / noise+无纯音→suspect（防幻觉误杀）/ normal+纯音→rework（兜底漏检）/ normal+无纯音+转写佐证→pass；numpy 缺失自动跳过降 suspect 不阻断 · ①omni 幻觉是模型固有行为与提示词无关：上游 round2 原版提示词对 A 系列正常段同样幻觉报哨声（upstream_prompt_check 实测 3 条中 2 条报怪声），提示词只能调检出/误报的平衡点，防误杀必须靠物理层；②位置幻觉是稳定特征但位置自洽≠真实：A 系列幻觉位置（1.5-2.0s）在 3s 时长内完全自洽，文本层无法证伪，只有频谱层能证伪；③omni 报告的怪声位置不可用于局部窗验证：B3 报 8.75-9.65s 真实哨声在 15-16s，局部窗扫描会漏检，必须全片段扫描；④「分析-结论脱节」是独立于提示词的模型缺陷，verdict 字段只能当参考不能当唯一依据；⑤频谱判据（纯度+SNR+持续性三条件）是窄带纯音 vs 语音谐波的有效区分器，纯度阈值 0.40 恰好卡在两类分布的间隙 · 🔍端到端回归 6/6：B 系列 3 条真哨声素材全 rework（EXIT=2）、A 系列 3 条正常段全 suspect 无假 rework（EXIT=1）；单元回归：round58 真实回复 parse_verdict 6/6（B1 脱节修正生效）+ detect_tone_windows 6/6；B1 漏检形态双层拦截验证（parse 修正+频谱兜底独立有效）；--context-pad 1.5 场景（tts_full_verify.sh 实际调用形态）验证通过；py_compile 通过+.pyc 已清 · t_6f7d6df3、t_178acca6、t_ff6db6d4

2026-08-29 · [阿普] pitfall_distribute.py argparse 改造：「查帮助=写数据」隐患修复（R-0829-03，t_bbbf8463） · 泡影查脚本用法跑 --help 却触发实际分发写入——脚本全文无 argparse，main 入口用手工 if "--dry-run" in args 字符串匹配，--help/-h 等未知参数不被拦截，静默落入默认 apply 模式直接写技能 SKILL.md · 手工参数解析对未知参数零防御：任何非识别参数都走默认写入路径；且 dry-run 模式还有一个隐藏写入面（未匹配清单 pitfall_undistributed.md 的写/删不受模式约束） · ①main 入口改 argparse.ArgumentParser，--apply/--dry-run/--status/--list-orphans 互斥组，--help 正常打印 exit 0；②cron no_agent 无参默认 apply 语义保留（jobs.json 实证该脚本无参调用，幂等防重兜底不变）；③额外修复 dry-run 隐藏写入面：undistributed.md 写/删改为仅 apply 模式执行 · ①带副作用的脚本入口必须 argparse 互斥组+显式 flag，手工 in args 匹配对未知参数零防御；②「查帮助=写数据」类隐患修复要枚举全部写入面——undistributed.md 写入面是任务未点名、实读代码才发现的；③改造无参默认写入的 cron 脚本时默认语义必须保留并实测 no_agent 调用路径 · 🔍本地验证：--help exit 0 零 SKILL.md 改动（find -newer marker=0）；--dry-run 输出清单 state/undistributed mtime 不变；互斥冲突 exit 2；无参跑 cron 路径 exit 0 幂等；模拟无新增静默退出 rc=0；py_compile OK · t_bbbf8463

2026-08-29 · [阿普] wiki_mechanism_selfcheck.py frontmatter 手写 split 不识别行尾注释致 A2 误报，升级 yaml.safe_load（R-0829-02，t_d2f2af47） · 泡影发现 status: active # 说明 是 YAML 合法写法，但自检脚本 parse_frontmatter() 用手写逐行 split 解析，把「active # 说明」整串当 status 值 → A2 误报非法值 · 手写 split 只做「冒号切分」，无 YAML 语义：行尾注释、引号、锚点等合法语法都不识别；PyYAML 6.0.3 本地已装却未用 · ①parse_frontmatter() 正则截出 frontmatter 块后改用 yaml.safe_load()（原生支持行尾注释）；②yaml.safe_load 返回 None（空 frontmatter）兜底 {}，非 dict 同样兜底；③YAMLError 回退旧版逐行 split——保证存量非法 YAML 页不因解析失败被误判缺 status（A1 新误报） · ①frontmatter 解析一律用 yaml.safe_load，手写 split 只配当 YAMLError 兜底不配当主解析器；②升级解析器必须做全库新旧对比回归（本次 115 页 status/freshness 零差异），防存量页解析漂移；③yaml.safe_load 对空块返回 None 是常见坑，必须 isinstance(dict) 兜底 · 🔍全库 115 页新旧解析零差异 + 行尾注释测试页 A2 不再误报 + 空 frontmatter 页正确报 A1 不崩溃 + 全量自检 EXIT=0 与旧版一致 · t_d2f2af47

2026-08-29 · [如花] trim_tongue_twister.py 静音兜底误判「皈依法→皈依僧」间 66ms 停顿为尾音后静音→残留整个「皈依僧」（t_eea8e1cc） · 专业前沿日报 20260829 裁切：trim 脚本 VTT 分段正确（绕口令 0-4.08s，正文 4.08s 起），但「静音兜底」把裁切点从 4.080s 提前到 3.273s，成品开头 ASR 出现「故意一生」残留；whisper_light 独立复核显示「皈依僧」实际 3.36-3.90s，正文「你」从 4.22s 开始 · 与 t_926de517/t_34c91f83（VTT 把正文并进绕口令段）不同：本次 VTT 分段完全正确，但静音兜底用 -45dB 检出 3.28-3.35s 的 66ms 停顿（「皈依法」与「皈依僧」之间的自然停顿），误当「绕口令尾音后静音段」锚点，把裁切点提前到「皈依僧」内部；验证 A 关键词命中 60%（「歸一聲 一指是想看看」）仍判通过，未拦截 · 波形分析（ffmpeg 逐 10ms RMS）定位真实边界：绕口令尾音 3.82-3.90s、静音段 3.90-4.21s、正文「你」4.22s 起 → 手动 ffmpeg 裁切点 4.21s 重做 + 补 1s 开头静音；裁后 whisper_light 开头 ASR「你只是想看看一个命令怎么用」完整无残留 · ①「静音兜底」是双刃剑：VTT 分段正确时也可能误把绕口令内部停顿当尾音后静音，把裁切点提前进绕口令；②验证 A 关键词命中率达标≠无残留——ASR@裁切点文本若含「歸一聲/归一/皈X」类词即残留铁证，必须 whisper_light 独立复核开头；③正文真实起点以波形能量为准（VTT/whisper 段边界 ±0.3s 均可能偏早），静音段后能量回升处才是正文 · 🔍裁切后 whisper_light 开头「你只是想看看一个命令怎么用」完整 + 开头静音 1.004s + ffprobe 128kbps/44100Hz/单声道 + 全文验证 opening 11/11、4 处 whisper 幻觉 SenseVoice 复核全为正常台词 · t_eea8e1cc

2026-08-29 · [如花] qianpo_log_standardize.py 新增 14.14 规则误伤任务ID（t_3fcb7a9d） · 新增「模型参数后缀 B：235B→二百三十五B」规则时正则 (?<![a-zA-Z0-9])(\d{1,4})B(?!\d) 把任务ID t 110BC207 的「110B」误转成「一百一十BC207」 · 14.14 后边界 (?!\d) 只排除了后面是数字的情况，但任务ID hex 中 B 后跟字母（C207），不满足排除条件 · 后边界改为 (?![a-zA-Z0-9])——排除所有字母数字后继，任务ID hex 不再误伤（t_110bc207 事故），grep 确认产物恢复「任务 编号 t 110BC207」 · ①新增数字替换规则时后边界必须 (?![a-zA-Z0-9]) 而非 (?!\d)，否则误伤 hex 任务ID/模型名；②每条新规则加完后必须重跑并 grep 任务ID 完整性 · 🔍重跑标准化 + grep「t 110BC207」「t D2F3BD63」完整保留，残留数字仅任务ID · t_3fcb7a9d

2026-08-29 · [阿普] token_daily_report.py v4→v5：新增 OpenRouter 平台统计（快照差分口径） · 豆蔻 8/28 切 OpenRouter 后费用完全缺失（正生 8/29 指出）；OpenRouter 无按日账单 API（/activity 需 provisioning key 403，usage_daily 是 UTC 日窗口） · 新增 query_openrouter()：快照差分（state/openrouter_usage_snapshot.json 存 key 累计 usage，两次运行差分归入统计日）；同日重跑复用 delta 不推进基准（幂等）；首日冷启动用 key 全量；delta<0 按 0+interval_anomaly 标注；间隔>36h 标注异常；汇率固定 7.2；wiki 幂等增强——条目存在但缺 OpenRouter 标记且本次查询成功时原位替换（补历史条目）；输出/总费用/¥20 阈值/日志行全部含第三平台；OpenRouter 失败隔离不影响 DeepSeek/智谱 · ①快照差分是「只有累计值接口」场景的通用按日化方案；②固有近似=相邻两日 00:00~00:30 用量差（深夜不跑≈0）；③wiki 条目幂等判断从「日期存在」升级为「日期存在+平台标记齐全」，平台扩展时自动补历史 · 🔍实测：8/28 统计 OpenRouter ¥23.58=$3.275×7.2 与 /auth/key usage、/credits total_usage 双源一致；重跑幂等（总费用不变/快照不推进/wiki 不重复）；py_compile 通过+.pyc 已清 · t_53a7feb0

2026-08-29 · [阿普] 乾婆切智谱 glm-5.3-flash 后报「The model provider failed after retries」：智谱 400 错误 1210「该模型始终思考，不支持关闭思考；请使用 low、high 或 max」 · 双因叠加：① glm-5.3-flash 是始终思考模型，请求必须带 reasoning_effort ∈ {low,high,max}，不带或缺省值会被拒 400；② 乾婆 config 02:04 写了 reasoning_effort: max 但 gateway 是 8/28 07:30 老进程，配置未加载，实际请求仍无该参数 → 400 → 非 4xx 判定重试 5 次耗尽报错 · ①配置「写入」≠「生效」，改 provider 配置必须重启对应 gateway（break_glass set --restart）；②始终思考模型参数为硬性要求，切换模型前先 curl 直测一轮再上线；③错误排查从 errors.log grep 400 响应体直接定位 · 🔍实测：errors.log 400 报文 + curl 直测 glm-5.3-flash reasoning_effort=high 成功（reasoning_tokens=168）+ gateway 02:27 重启后 WS 重连正常 · 乾婆模型切换