HS Knowledge Vault

2026-08-13 决策：skill 策略定版 + Prime 拆小任务 + 开源优先定调

25分钟阅读

2026-08-13：skill 使用边界定版 + Prime 长任务拆小策略 + 开源优先定调

1. Prime skill 使用边界定版（用户深度思考后）

背景：用户发现矛盾——创意任务（website 优化）加载 skill hub 会带偏见；重复性非创意任务 skill 好用；双盲测试不该带平时 skill。自认混乱，要求捋清。

决策：

  • skill 不是”要不要”——是”什么时候加载什么”，每个任务单独决定：
    • 🎨 创意/优化（website）→ 不加载 skill（自由探索，避免框架偏见）
    • 🔁 重复/标准化（报价/部署）→ 加载 skill（一致性、快）
    • 🔬 双盲/验收 → 明确禁 skill（--no-skills，判断不被污染）
  • 不建”方法论 skill”、不建”索引 skill”（避免隐性引导/限制思路）
  • 用【任务书】做”活索引”：派活时写清楚——该用什么脚本（名字+路径）／该不该加载 skill（每任务声明）／双盲任务明确标”禁 skill”
  • 事实依据：Prime SKILL.md = 0 个；固化形态 = 脚本（460+ .py）；脚本 = 它的输出（工具），skill = 它的输入（说明书）——互补非竞争

What changed：派活规范新增”skill 声明”一行（加载 XX / 禁 skill —no-skills）；放弃之前”建脚本索引 skill”的轻量方案提议。

2. Prime 长任务拆小执行策略（8/13 定）

背景：file-browser session 大任务连续 5 次中途退出（Phase 3/4/5，多步+长测试）；timeout 包装 exit 0 但 WSL 子进程其实还在跑（“假退出”，session 占用报错实证）。

决策：

  • 大任务拆成子任务逐个跑（A-D 小块，每个 20 分钟内完成），完成即报告，不贪多
  • “假退出”处理：timeout 退出 ≠ 任务失败——先查 WSL 子进程是否还在写文件（文件在写=在工作），别急着重派（会撞 session 占用锁 Session is already active）
  • 真中断才续跑：-r <绝对路径>.jsonl（-r <id> 格式不可用）+ timeout 1700

3. 8/13 定调：现成开源优先 + 手机缓存只做小图

  • 「大胆想法」不必从零开发——现成开源工具优先（FileBrowser 例证：30 分钟部署 vs 自研数天）
  • 手机存储有限 → 离线缓存只做缩略图/小图（不自研大文件全量缓存）

4. 验收纪律强化（8/13 再确认）

  • 线上 URL 实测为准；报告自述 + 落盘文件不足采信（WO 盲审「可上线」vs 实测 404 即例证）
  • 部署只认 glm_return 目录（WO Route 404 根因复盘：从无 wo 路由目录部署覆盖了线上）

5. Prime 脚本指引方案（Task 20 定案，8/13 上午）——「索引 skill」最终解法

背景：用户三连问——①要不要给 Prime 建 skill 索引指引？②Prime 是否记得同 session 里每个脚本的用处？③谁来读全部 460+ 脚本做指引？用户愿意接受重型任务（token 便宜），但要求 flash only。

决策：

  • 不建索引 skill、不让我（Hermes）读全部脚本——理由：①460+ 个脚本大部分是一次性任务产物（报价生成器/项目特定），索引=维护”尸体清单”；②我读=重复劳动且不如 Prime 懂自己代码（它写时有 IPython 上下文）
  • 由 Prime 自己筛：601 个 .py → 37 个可复用工具（5 类分组）→ 产出 Prime_Script_Guide.md（11KB）存共享知识库 prime_setup/——跨 session 互通（新 session 的 Prime 也能读），我派活时查指引建议用哪个（闭环）
  • 认知补充：session 内 Prime 记得脚本但上下文 131K 会压缩（文件还在、“用途”可能忘）；跨 session 不互通 → 用户”分 session 长期使用”策略正确 + 少数高价值脚本由我记忆兜底
  • 预算铁律：Prime 全程 flash——严禁转 Pro（用户明确）

What changed：放弃凌晨”任务书=活索引”的唯一方案——现在任务书 + Prime_Script_Guide.md 双轨；派活流程：查指引 → 任务书写明脚本路径/用法。

6. App Portal 独立域决策（8/13 上午）——新系统先建图、独立域隔离

背景：用户”零零碎碎 webAPP 越来越多”要统一入口；担心后续维护 portal 时误覆盖 hsdesign.biz 公司 landing page（同属 Cloudflare 部署）。

决策：

  • 不做真 superapp（各 app 技术栈不同——Cloudflare Workers/本地 FastAPI/FileBrowser——统一嵌入是大工程不值）→ 独立 portal 导航页（卡片网格，点击跳转）
  • Cloudflare Pages 公网部署（portal 本身永远能开——不怕 Tailscale 断线/忘记开）；跳转分两组：公网组直接跳（master app/life-map/hsd-cashflow/hsdesign.biz）+ 内网组 🔒 提示开 Tailscale（WebWatch/FileBrowser/cached_files/stats/Viewer）——安全不妥协
  • 独立 portal 域 session（app_portal/ 目录，Prime 域结构 三域→四域）——portal 维护与 hsdesign.biz 完全隔离，覆盖风险归零

What changed：新系统图谱 AppPortal_Graph 建立并登记 Company_Graph；portal 域 session 8aafa6e6eb65 派工（后台 proc_89ac0a58d3f1）。

Related（追加）

7. Portal 单点登录（SSO）+ 统一密码策略（8/13 午定案）

背景：用户打开内网工具频繁被 token/登录拦——希望「进 Portal 一次 → 子网页全部免登录」。同时用户主动提供新密码 LezTByUE8f2UXk（之前 generate 过的）要求 Portal 换用。

决策：

  • Portal 登录门 + token 自动注入：进 Portal 输一次密码（session 内记住）→ 点内网卡片自动带 token 跳转（WebWatch/cached_files 免登录）；FileBrowser 无法免登录（现成软件不支持 URL 认证——接受）；Stats 无需 token
  • 配套：cached_files 新增 ?token= URL 认证（任务 22，与 Bearer 等效 + 常量时间比较）——⚠️ URL 带 token 有日志泄露面，访问日志需 token 脱敏
  • 统一密码：Portal 与 Life Map 登录门共用同一个密码（用户指定）；master app 密码独立（wrangler secret）；hsdesign.biz 保持公开（官网不锁）——现状 = 各自认证 + portal 聚合，不做真统一登录
  • Life Map 登录门实现：遮罩式（IIFE 开头加遮罩，不动核心逻辑——Prime v6.1.1 代码零风险）、sessionStorage 记住、错误密码提示；部署 D1 写入+读回验证+线上 lm-gate 实测

What changed：Portal 密码从 hsdesign2026 → 用户指定新密码（值存 Telegram 会话/用户记忆，vault 只留 Credentials_Graph 指针）；Life Map 从「无登录」→「登录门（统一密码）」；cached_files 认证面从仅 Bearer → Bearer + ?token= 双通道。

8. 模型分配策略定版（8/13 傍晚）——DeepSeek-V4 Pro 0813 正式版 + 质量优先原则（反转上午「严禁转 Pro」）

背景：V4-Pro-0813 正式发布（1M 上下文 / 384K 输出上限；官方价 miss 0.87 vs Flash 0.28——约 3.1×）。用户最近开始赚钱 → 明确「质量优先 > 成本，输出最大化复利」；且自认大多数任务都是多架构（一句话任务背后是查项目→建夹→出 DQ 的连锁）。

决策：

  • Hermes 主 agent → deepseek-v4-pro + reasoning max（config.yaml 8/13 17:40 生效）——反转上午「全程 flash 严禁转 Pro」铁律（用户主动）
  • Prime 按任务复杂度分配：多架构/重活（报价系统/部署/安全审计）→ Pro max；简单任务 → Flash max
  • Cron 全局锁 deepseek-v4-flash（救治/监控/提醒非多架构——省钱且够用）；模型切换触发「配置漂移安全跳过」已验证有效（Prime卡死救治 job 被跳过防意外花钱）→ 已更新恢复
  • 实验数据佐证（同任务书=装修报价系统，双盲从零）：Pro 37 分钟完成 + 三层验收全绿 vs Flash 110 turns 被掐未完成；成本 0.08（RM 差 1——绝对值可忽略）；Pro 贵 4 倍但”真正做完”——Flash 半成品=钱白花
  • 真实成本认知修正：message.usage 有精确 token 数据（27 session / 4,990 条：miss 9.74M / hit 3.66 亿 = 97% / out 3.8M ≈ 3-8 极低，全切 Pro 估 $6-8——以后直接读 usage 不再估算

What changed：Hermes config 模型 flash→pro + thinking max；cron 全局 flash 锁定；派活规范新增「模型分配」一行（按复杂度 Pro/Flash）；「严禁转 Pro」废止。

9. prime-agent「限制全开」配置清单 + 慢响应被杀根因（8/13 傍晚实验 3 次根因修复）

背景：Flash vs Pro 实验连续 3 次失败——Pro 首次响应（重度任务书 + max thinking）超时被杀；Flash 也被 daemon 模式启动冲突误杀；Prime Watch 显示”空闲”造成卡死假象。

根因：①models.json 只注册 flash（v4-pro 无 thinking map → xhigh 静默降级 high——实验不公平）②daemon idle eviction 默认几分钟就把「等待 API 响应的慢 session」杀掉（autonomous-gate-timeout 默认 5 分钟 < Pro 首次响应时间）③max-tokens 80K / max-turns 12 / continuations 3 对长任务不够。

决策（限制全开清单，长任务默认配置）：

  • models.json 注册 v4-pro（max→max thinking map + 正确价格）
  • settings.json 加 idleEvictionMinutes: "off"（源码级确认 settingsManager.getIdleEvictionMinutes() 可配 off）
  • gate 超时 5min→25min、总超时 30min→90min
  • max-tokens 80K→1M、max-turns 12→100（跑到底任务 500）、continuations 3→20
  • ⚠️ --autonomous-max-turns N 是硬顶 ≠ 限制全开——用户要求「无限运行除非死循环」，用监控兜底
  • 监控 watch_exp.py（5 分钟轮询）：12min 无写入=卡死报警 / 8min +40 消息无产出=死循环报警 / 每域进程数检查（>1=双进程冲突报警）——只报告不误杀，报警后 Hermes 判断
  • 双进程冲突：重跑前必须确认旧进程杀干净（2 进程抢同一 session 目录 → 写入打架/显示异常）

10. Prime Watch 显示修复 + system-fix 归档（8/13 傍晚）

背景：Prime Watch 把「旧重跑残留 jsonl」当活 session 显示（两个 flash 卡死 + 两个 Pro 进行中的假象）；总览面板点击后 menu bar 跳到页面底部；system-fix session 显示卡死。

决策：

  • scan_sessions() 每域只取 mtime 最新 jsonl（旧文件忽略）→ session 数 27→12；状态判定逻辑零改动
  • 总览面板 overlay 化（.overview position:fixed; inset:0; z-index:60 + 关闭按钮——不挤压页面布局，实测 navY=0）
  • system-fix 归档：8/11 00:25 旧 session（早已死无进程——非卡死）；早期命名后来统一 system-ops → 移 archive/ 不再显示（Prime Watch 现 11 域）
  • 执行：Prime（Pro max，60 turns）+ Hermes 独立验收（源码 + 线上实测——不信自报）

What changed：Prime Watch 显示可信（每域 1 个）；总览为全屏 overlay；遗留 system-fix 从监控消失。

Related（傍晚场）

11. 分工规则定版：重活派 Prime（带配方），Hermes 轻活+验收（8/13 夜，用户明确）

背景：跨机浏览器自动化（IDA PC 开 portal 登录 + 建快捷方式）Hermes 亲自下场卡 20+ 轮——5 个坑现踩现学，其中 SendKeys 把密码打进 Telegram 输入框=安全事故；用户 21:12 明确「让 prime agent 帮忙执行这种任务，你只适合做很轻量的对话或者很轻量的修复」。

决策：

  • 代码/部署/跨机操作 → Prime（带配方任务书）；Hermes = 轻量对话 + 轻量修复 + 验收/决策/汇总
  • 配方链路成立（实证）：Hermes 踩坑 → 固化 skill（winrm-remote-control 远程浏览器自动化五坑：禁 SendKeys／WebClient Proxy=null 直连／禁 portproxy／CDP 绑 127.0.0.1／分段写文件）→ Prime 照配方执行一次成功（IDA PC 开 YouTube 搜「prime agent」，Flash max）——「探索成本付一次，以后只付配方成本」
  • 委派时机：环境试探型任务卡到第 3 个坑 → 停下来写配方委派，不硬啃

12. Prime daemon 常驻模式 + 全局 Pro max（8/13 夜）

背景：用户长期要求「demo 模式可随时插队」；--autonomous-* 一次性模式不能插队 + Prime Watch 显示不出；21:14 用户发现 6 个 daemon 常驻 agent 全是 Flash（settings.json defaultModel=deepseek-v4-flash 被继承）。

决策：

  • 标准流程（官方 long-running-agents.md）：每域一个常驻 agent——TUI 启动 → detach（worker 常驻）→ prime-agent send <agent> 派活（--steer busy 也注入=真插队）→ rename 命名 → schedule 定时；废弃一次性 autonomous 模式
  • 全 Pro max 统一：settings.json defaultModel → deepseek-v4-pro；6 个 daemon 全停 → 起 6 个 Pro max TUI worker（按域命名，显示 “DeepSeek V4 Pro • max”）→ detach 常驻；cron 仍锁 Flash
  • 多 Pro 并行无碍（独立 session 独立 context + DeepSeek 并发 500）

13. WO 防枚举完成上线 + 域分工 + Portal SSO 完成（8/13 夜）

  • WO 防枚举交付：D1 woKey 列 + 全量回填 32 位随机 key；部署 f0e1d506；线上实测无 key 404 / 对 key 200 / 错 key 404——WO 链接（分包商成本+银行账号）不再可枚举
  • 派错域教训：WO 是 master app 代码任务 → 应派 master-app 域（先派 system-ops 错误）；域分工：master-app（master app 代码）/ system-ops（系统基建）/ portal（portal）/ 各站各自域
  • Portal SSO 完成：HMAC 签名短期 token（10 分钟有效+单次+密钥不暴露）；life-map 302/重放 403/篡改 403；master app 免登录实测成功
  • Portal 7 天免登录进行中（Prime，Pro max）：登录门勾选 + localStorage + 服务端会话票 TTL 24h→7d（不改 TTL 免登录会断在子站跳转）
  • 质量审查：3 个 Pro 任务共 1.03（RM 4.6）；⚠️ turns 全超任务书（98-348 vs 40-120）——派活 turns 预算留余量

Related（夜晚场）

14. 全 Pro max 统一 + OpenClaw 修复 + CLI→daemon 铁律（8/13 深夜）

背景：21:14 用户发现 6 个 daemon 常驻 agent 全是 Flash（settings.json defaultModel 被继承）——重起 Pro max 后，用户 21:20 追问「你自己和 miss agent 有没有这个漏洞」，并批评 portal 7 天任务为何用 CLI 独立进程（daemon 才能插队）。

决策：

  • settings.json defaultModel → deepseek-v4-pro；6 个 Flash daemon 全停 → 重起 6 个 Pro max TUI worker（master-app/portal/hsdesign/webwatch/system-ops/file-browser 按域命名）→ detach 常驻
  • OpenClaw 也切 Pro（加 v4-pro 定义 + 默认改，重启生效）；Hermes 主 agent 本已 Pro max；cron 继承主模型（旧「cron 锁 flash」配置已不存在）
  • CLI→daemon 铁律：所有任务走 prime-agent send（可插队/可接续）；CLI autonomous 只用于隔离实验，绝不用日常任务

What changed：全家桶（Hermes/Prime 6 域/OpenClaw/cron）统一 V4 Pro max；日常任务全部 daemon 化可插队。

15. 自适应模型路由定案：默认 Pro，不建自适应机制（8/13 深夜，用户定调）

背景：用户 21:23 算账——Pro 1h 3 任务 ≈4，平均单任务 Pro 更便宜；「钱花得快」= 产能提升的错觉。21:27 用户主动要求客观评估要不要给 Hermes 建小任务自适应转 Flash 的机制。

决策：

  • 默认 97-98% 任务 → V4 Pro Max；只有 SOP 零出错任务 → Flash max（闲聊/填资料走 API/纯文本提醒）；判断标准：任务有没有「出错的可能」
  • 不建 Hermes 自适应机制（三条客观理由）：①Hermes 模型会话级配置运行中不能切换（smart_model_routing 查源码是死配置零引用）；②3-5% 小任务 Pro 差价≈分钱级；③Flash 真省钱在「批量」——将来出现大批量 SOP 填单场景才起 Flash daemon worker（YAGNI）
  • 旧 Ollama embedding（nomic-embed-text）判断难度=用错工具 → 自适应彻底算了
  • 自适应路由 skill 重写（8/13 生效）

16. 「假活」定义 + watchdog 第四层慢工具检测（8/13 深夜）

背景：portal 卡在跨盘递归 grep 32 分钟——工具在跑、CPU 在烧、但跑的是无价值操作；用户提出「不直接截断，检查它在干嘛」的人性化方式。

决策（三种停滞定义 + 90% 覆盖近似）：

  • ①死卡（进程活无输出）→ watchdog 已覆盖；②死循环（反复同一件事）→ 已覆盖；③假活（新）：工具在跑但无价值（find /、无界 grep -r、全盘扫挂载盘）
  • 信号 1：单工具调用 >15 分钟 → 进入检查；信号 2：命令命中黑名单（find /、无界 grep -r、全盘扫挂载盘）→ 自动 kill 工具子进程；信号 3：命中 1 不在 2 → 广播 Hermes 人工判断
  • 关键洞察：杀工具 ≠ 杀 agent——只 kill 工具子进程，agent 思考/进度全保留（截断的是手，不是脑袋）
  • 已派 Prime（system-ops 域）落地 watchdog 第四层判定（与豁免 1-7 独立不冲突）

17. file-browser + cached_files 归档（Google Drive 动态缓存覆盖，8/13 深夜）

背景：用户发现 Google Drive 手机版自带动态缓存（最近打开的文件不清 cache 就保留）→ 动态缓存机制（cached_files 8081 + file-browser）原始动机失效；且两工具功能重叠。

决策：同意归档——portal 移除 file-browser + cached-files 两张卡片 + stats 卡修 unauthorized（8787 服务 token 鉴权，非直开）；服务层面先只移卡片不杀服务（零成本挂着），用户满意后再彻底停。前端 JS 内含 stats 明文 token 是既有设计（非新增风险）。

18. DSH 调研 + 双盲测试启动（从零生成 + 无硬上限 + 记忆插件化方向，8/13 深夜）

背景：用户分享 DeepSeek Harness 分析文，要求查证 + 提议 Prime vs DSH 双盲测试（「能不能像 prime agent 一样成为 Hermes 的主触手」）+ 好奇 DSH 是否省 token。

查证结论：

  • 官方仓库 deepseek-ai/deepseek-harness 真实存在：2.1 万 star、MIT License、免费（npx @deepseek-ai/dsh web）、TypeScript + Cordis
  • 8/13 当天刚发布 developer preview（官方明示兼容性破坏变更随时发生）→ 短期不引入生产，观察 2-4 周；中期试点超长任务（WhatsApp 聊天模块那种大工程）；长期定位「长任务车间」第三种 worker（Hermes 管家 + Prime 打工人 + DSH 超长任务）
  • DSH 省 token 机制 = 架构设计（沙箱执行防污染 + 事件替换压缩），不是 API 折扣；对长任务省得多（打 Prime 348 turns 痛点）

双盲测试方法论（用户两批评定版）：

  • 从零生成范式：任务必须两边各自空目录起步、产物独立——操作共享目录 = 假双盲（Prime 先跑会改变 DSH 面对的环境）；第一个「磁盘分析」任务书因此废弃，改用「从零实现迷你 HTTP 静态服务器」
  • 不设完成上限：今天的教训（portal 被上限害过）——看卡死不看时间；max-turns 500/timeout 2h 仅防失控兜底，watch_exp 监控卡死，完成为止
  • 对比指标 4 维：完成质量（独立验收）/ 墙钟时间 / token 成本（真实账单）/ 轮次
  • Prime 基准（8/13 23:44 独立验收）：HTTP 服务器 8/8 全过 | ~25min | 19 轮 | $0.0475（瑕疵：VERIFY.md 缺失 + 收尾 aborted）
  • 安装坑：node-pty 原生编译缺 make（WSL 无工具链 + sudo 要密码）→ npm i -g @deepseek-ai/dsh --ignore-scripts 可用

记忆插件化方向（用户洞察，重要）：「一切皆插件」→ 共享知识库从「外包记忆」变「原生记忆」——检索责任从 Agent 转到 Runtime，会话启动自动按任务注入。Vault Memory 插件设计：L1 常驻核心（客户编号规则/SSOT 指针/业务铁律）/ L2 任务关联注入（客户名→Company_Graph 节点）/ L3 动态取用 + 写回自我进化（纠正过的规则自动更新 L1）。泼冷水：概念=RAG+提示注入、preview API 会变、DSH 是车间非管家、注入有 token 代价。行动：等 API 稳定（2-4 周）实现；Hermes 侧先做近似版 skill。

19. 撞期防护系统闭环（日历→D1 镜像）+ 幽灵目录结案 + Prime 基准成绩（8/13 深夜）

决策：

  • 日历→D1 镜像上线（撞期防护第三级）：sync_calendar_d1 脚本（开发副本 hsdesign_work\calendar_sync\ + 正本 scripts\ 各 11483 字节一致）+ cron job e5cc553267a5；实测拉未来 30 天事件 → 2 条 upsert D1（db=cd009bf4-3d28-4956-84e3-f60c4e7e2a5d，3.4s）——撞期防护三级闭环完成（skill 铁律 + 双兜底 cron 7:30/20:00 + D1 镜像）
  • 幽灵目录结案：exp-bench 复活根因 = 废弃会话进程未退出（每次写日志重建目录，rm 后 5.4s 复活）→ 清理后 8s 无复活
  • Prime Watch 卡死误报修复：idle daemon 不写文件被误判卡死 → daemon session 改由 prime-agent 注册表判活（6→0）
  • Prime 基准成绩：8/8 全过 | ~25min | 19 轮 | $0.0475（双盲测试 Prime 侧）
  • 8/14 关键：路税罚款截止；Mr Mark 改期话术（4:30pm/周五 10am 二选一）；带家私佬见 Ms Ong（Ambience 15:00）；早 9:00 Metal Life follow up（27 号 Austin Mr Chen 家安装 HSP00006）

Related（深夜场）

  • DSH_Graph（新——DeepSeek Harness 评估 + 双盲测试 + 记忆插件化）
  • PrimeAgent_Graph（全 Pro 统一 + 假活第四层 + 卡死误报修复 + bench 基准）
  • 2026-08-13（深夜场）

关系图谱

反向链接