HS Knowledge Vault

2026-08-15 决策：全 DSH 派工 + Delegate Watch 公网化 + CF token 审计 + SSO 排障止损

31分钟阅读

2026-08-15：全 DSH 派工 + Delegate Watch 公网化 + CF token 审计 + SSO 排障止损

1. 后续任务全部派 DeepSeek Harness（8/14 22:41 用户定案）

背景：用户等待 portal 密码轮换时明确「prime agent 太久了」。

决策：接下来的任务全部用 DSH（DeepSeek harness）做——用户原话「接下来的任务你全部都用 DeepSeek harness 去做」。Prime workers（system-ops/webwatch/hsdesign/master-app/portal）保留为常驻守摊，新任务优先 DSH。

What changed：派工默认路由 = DSH headless；Prime 只做常驻/长记忆任务。

2. 知识沉淀机制：统一由 Hermes 沉淀（8/14 22:00 用户确认）

背景：用户长期目标 = 经验累积 + 随时换 Agent 的准备；问 DSH 完成任务后是「报告给 Hermes 总结」还是「DSH 自己写」。

决策：统一由 Hermes（主 Agent）沉淀——即本 3 小时知识同步 cron 机制。DSH 完成任务不需要额外报告动作（用户照常派活；DSH 知识注入命中缓存 ≈ 免费）。

理由：单一沉淀入口 → 格式统一、不重复、Agent 可随时替换（知识在 vault 不在 agent 脑子里）。

3. Delegate Watch 升级方案（webwatch → Delegate Watch，8/14 22:54–23:44 定案 + 完成）

背景：用户要「Prime Watch 升级为 Delegate Watch，监控 DeepSeek 和 Prime 状态；公网 HTTPS 直接访问（免 Tailscale）；Portal 凭密码快速打开；通知自带链接」。

决策：

  • 监控对象：DSH（3300 健康 + session 扫描）+ Prime 会话双监控
  • 网络形态：公网 HTTPS（CF Funnel 暴露 /，SSO 保护）——不再依赖 Tailscale；Funnel 默认全路由公网 → 只留 /，viewer/fb/files 退回内网（安全红线：无鉴权路由不裸奔）
  • 入口：Portal 登录（密码）→ 卡片 → SSO mint 短票（10 分钟）→ 免密进入（与 master/life-map 同机制）
  • 通知：带链接，跳项目排期 Sheets
  • UI 改进清单（待执行）：双色（DSH 蓝/Prime 青绿）+ 异常优先排序（异常 > 进行中 > 空闲 > 完成）+ 状态 SVG 图标 + 统一任务模型（DSH 任务型 vs Prime 常驻型）+ 动态缓存（实时流只留最近 200-500 条、last_event_id 增量拉取、虚拟滚动、DOM 上限折叠）

What changed：webwatch 面板升级为 Delegate Watch（公网 https://desktop-f9ksppp.tail1b1993.ts.net/）；DSH 首单 headless 完成全链路。

4. Cloudflare Token 审计结果 + 新 token（8/14 23:21–23:35）

背景：DSH 报告 CF token 失效 → 独立验证（tokens/verify，Account f6b7326e471bbe3d1b0a0e2ba770f47d）。

结论：

  • cfut_zal1…（cloudflared hs hermes）有效（2027-03-31 过期，Tunnel 用）
  • cfut_a8y7…（worker scope）有效（永不过期）
  • cfat_nGPv…（泄漏的 API token）已失效 401 → 泄漏风险自动解除，无需吊销
  • 新 token：cfut_dKTXL8a4GUntdE0iFxB15ozsrbOXwKGCpev0fCrW3035000c（Edit Cloudflare Workers 模板，Pages+Workers 权限齐）→ 同步 .env + WSL wrangler → Pages 部署能力恢复

教训：cfut 前缀 = Tunnel 专用（不能部署 Pages）；Pages 部署需 API token（Pages:Edit）；CF token 值只在创建时显示一次。

5. SSO 排障止损原则（8/15 03:13）

背景：Portal → WebWatch 卡片 SSO 免密在浏览器里反复 401（curl 全通、127.0.0.1 通、公网 401）。已排查：缓存旧版（app.js?v=20260815 缓存破坏已部署）→ SameSite=Strict 改 Lax → 疑 webwatch secret 与生产 portal 不一致（未确认）。

决策：自己折腾止损 → 派 DSH 用 Playwright 真实浏览器复现根因；同时部署临时方案（卡片带 token 直进）保证用户可用。

What changed：临时 token 卡片已生效（点卡片直接进）；SSO 正式修复由 DSH 完成（预计 1-2 小时）。

6. SSO 根因定案：前端自杀式鉴权（8/15 03:13–03:47 修复完成）

背景：§5 止损派 DSH 后，DSH 用 Playwright 真实浏览器复现出根因——不是服务端、不是 secret、不是 SameSite（虽然三者都排查/修过）。

根因：webwatch index.html 加载时 if(!TOKEN) 直接清空 body（自杀式鉴权）——服务端 SSO 链路一直通（curl 302 全通），但浏览器端 JS 一看 URL 没 token 就把页面清空成「未授权」。

决策：删自杀鉴权行 + api() 条件拼 token → 合并 UI 版与 SSO 修复版 → 生产部署 → 真实浏览器全链路验收（portal 登录 → 点卡片 → 免密进 Delegate Watcher）✅

教训固化：① SSO nonce 单次消费（先公网后本地测试顺序）② DSH 并行任务互杀服务（8787/8788）→ 并行必须隔离服务/文件 ③ apply 脚本空 env 启动 → SSO 显示未配置（重启带 .sso_secret）

7. 任务漏派防漏机制定案（8/15 03:18–03:54 用户追问后固化）

背景：用户发现 Delegate Watch UI 改进需求（22:5x 提出）一直没执行——「任务不是很早就派了吗？为什么会没有完成？是我们派任务的方式错了吗」。

根因（诚实复盘）：① 任务书只含「当前消息」需求，更早口头需求没进任务书 ② 记录 ≠ 派发（记录在 followup 文件 ≠ 派发）③ 派发时无待派清单检查 ④ 调度无闭环。

决策：

  • PENDING_TASKS.md 总清单（D:\hermes\hsdesign_work\bench\PENDING_TASKS.md）——派发任务前必读 + 每天收尾检查
  • 三条铁律写入 Hermes 记忆：① 任何任务 → 写任务书 → 立即派 DSH（并行 2-3 个），不存在「排 PENDING/明天」② PENDING 只留「等用户输入」的 ③ 新需求随时插队
  • 用户偏好确认：「别列清单，立即执行」「AI 无需睡眠持续工作」——晚上照常派活

What changed：任务派发流程 = 记录 →（派发前查 PENDING）→ 立即派 DSH；用户反馈「总结就是只能靠你的记忆去勉强维持任务输出完整度」→ 驱动了 §8 的插队机制调研。

8. DSH 插队机制定案：检查点方案（8/15 03:25–05:17 调研 + 定案）

背景：用户问「能不能像我和你沟通一样中途插队，让 DeepSeek harness 自己重新排优先级」。

调研结论（实测）：DSH headless = 启动读一次任务书 → 跑完退出，无原生插队（stdin 已关实测不可写；杀进程丢进度）；DSH web UI（3300）能看到所有 headless session（重大发现）；Prime 常驻天然支持插队（send 消息）。官方 README 确认 DSH 无插队 API。

决策：插队检查点机制（提示词工程）——任务书模板 task_template.txt 带【插队检查点段】（每阶段结束读 INTERRUPT_<任务名>.md，有新指令就处理）；规范写入 DSH_CONTEXT.md。类比用户中途说话 → Hermes 完成当前回合再响应（阶段间响应）。

What changed：未来所有 DSH 任务书自动带检查点段；新需求 → 写 [INTERRUPT] 文件 → 任务阶段间自动响应。

9. Computer Use 视觉分层链定案（8/15 03:49–04:49 调研 + 落地）

背景：用户想提升 Hermes computer use；目标 = 视觉模型足够便宜时大量任务走 computer use（权限大、不被拦截）。

调研结论：OmniParser V2 本地（1050 Ti）25-30s/帧不可行（社区评价偏实验）；UI-TARS-1.5-7B API 0.20 每 M（ScreenSpot-V2 94.2 断层第一）；Qwen3-VL-235B OSWorld 66.7 开源最强 $0.26/M；Gemini 3.7 Flash OSWorld-2.0 47.9%（免费配额优先）。S-Tier（Claude Mythos 85.4% / GPT-5.6 Sol）尚不成熟仅关注。

决策（用户定案分层链，最优先→兜底）：① Windows MCP（现役最好）→ ② Gemini 3.7 Flash（免费配额白嫖优先）→ ③ UI-TARS-1.5-7B API → ④ Qwen3-VL-235B → ⑤ OmniParser 本地 → ⑥ 本地 7B（4GB 显存已排除）——完成不了换下一个。

落地：用户提供 OpenRouter key（1.54）→ vision_switch.py 扩展 6 档 → auxiliary.vision 切 Qwen3-VL-235B。教训：DSH 派发 bash 嵌套引号拿空 key → 401（key 提取用 Python 稳定方案）。

10. 演示→技能工作流定案（8/15 04:49–05:12）

背景：多平台发布需先演示流程、后定时执行；用户问 GitHub 上「通过演示把流程记录下来成为 skill」的生态。

决策：

  • 工作流固化：「新平台/界面大改 → 用户演示 → 记录步骤/坐标/验证标志 → 固化 skill → cron 定时执行；界面变更 → 提醒重演示」（已写入 multi-platform-content-publishing skill）
  • F9/F10 录制流程：F9 → 桌面 toast 通知（用户 desktop 无 speaker——禁用声音）→ 演示 → F10 → toast 已保存 → 用户说「录好了」→ Hermes 提纯成 skill
  • Demo-to-Skill 概念验证：OpenAdapt 1682★ 真实（把演示 GUI 流程编译成确定性本地执行代码）；open-record-replay macOS 专用排除 → 自研录制器派 DSH（产物直接进 Hermes skill）

What changed：多平台发布 = 演示优先工作流；明天首次 F9/F10 配合（短视频全平台发布演示）。

11. Peak 时段暂停规则定案（8/15 09:22 用户定案）

背景：用户指出高峰时段不应跑重任务（影响其电脑使用），此前已有类似口头约束。

决策：peak 时段（9-12、14-18）暂停全部 DSH 任务，只处理日常/紧急事务；off-peak 恢复清单制（记录在 PENDING_TASKS.md，12:00 恢复时全部执行）。

What changed：派工调度加入时段窗口；peak 暂停的任务显式登记（bench/paused_sessions.md）供前端显示「暂停」而非「卡死」（见 §14）。

12. Hermes×DSH 双层架构方案评估（8/15 10:27–10:49）

背景：用户提供外部「CEO + 施工队」双层 Agent 协同架构方案书（Hermes 调度层 / DSH 执行沙箱 + Task Spec 契约 + Recovery Session + PTC/Cordis 插件），问是否值得参考。

决策：核心哲学（分层解耦/契约隔离/验收导向）= 我们已实践 80%，吸收 3 点轻量改进： ① 任务书补结构化字段：Task ID / Retry Budget（内部自愈 ≤3 次，耗尽阻断上报）/ Execution Mode ② 上行简报精简格式：Status: SUCCESS/BLOCKED/FAILED + Artifacts（改动文件）+ Validation（数字）+ Blockers（≤3 条）——不贴长日志 ③ Recovery 显式化：失败 → 看证据 → 决定重跑/改任务书 拒绝 4 点（理由）：Hermes 上下文 4-8K 不现实（系统提示+技能已超）；「严禁直接介入代码调试」绝对化（紧急直修保留——今早 guard 误杀 8787 就是直修恢复的）；FE/BE 领域长驻 session（维护成本高——CONTEXT 文件是轻量等价）；Cordis PTC 脚本库/插件框架（重投入——工具库替代，见 §14）。

What changed：bench/task_template.txt 更新（新字段 + 简报段 + 模块 CONTEXT 引用段）；后续所有任务书自动带新格式。

13. 领域 CONTEXT 轻量复刻定案（8/15 10:54–11:12）

背景：用户纠正「webwatch 连续 6 轮优化、master-app 也常连续迭代——领域 session 判断不严谨」；并要求把 Prime 常用 session「生豆版复刻」过来（只复刻有质量的，过滤噪音）。

决策：

  • 轻量领域上下文 ×5（bench/）：webwatch / master_app / portal / system_ops / hsdesign _CONTEXT.md——含模块身份/已知事实（路径+机制+凭据位置）/验收基线/历史时间线；任务书引用替代重写（webwatch 6 轮优化教训）
  • Prime 深度知识提取（176 段 → 只留最终交付/发现/弱点，过滤「Let me/Now I…」过程噪音）：
    • master_app_CONTEXT：CashflowApp 蓝图（vault HS Design/CashflowApp_Optimization_Blueprint.md 36KB）、5 项优化已实现（🔴-01 收据入口/02 逾期筛选/03 地址预填/05 余额聚合/06 一键批量发票）、盲审 7 BUG（P0×2：收据 amountWords const n 重赋值 dev 必崩 + 一键生成无去重）、已知弱点（收款 4 次非原子写 payments/route.ts、BQ 断链、模板先删后建、?t= 竞态、ESLint 坏 v9 flat config、构建 320s）、验证惯例（tsc 预存 64 错/备份目录必须在项目树外）
    • hsdesign_CONTEXT：site review 3 个 P0 已处理（token 公开/部署目录失控 1210 文件/30 地区页空壳）+ SEO 短板未修（无 hreflang/地区页无 OG/H1 重复）+ wrangler pages deploy . 整目录警示
    • webwatch/portal/system-ops 无深度内容——不硬凑

What changed：DSH 连续迭代任务零重复探索零重复试错；vault 仍是最终真相源（用户确认——CONTEXT 只是加速索引，漏了知识 vault 兜底）。

14. 触手升级：轻量工具脚本库 + 三层固化体系（8/15 11:15–11:20 用户定案）

背景：用户：「DeepSeek 是你的触手，不升级触手能力范围每次任务效率都低；Hermes 是 CEO 不用带太多工具，但打工人（DSH）必须重装」。此前评估中 Cordis 插件框架被泼冷水（§12），用户质疑是否判断失误。

决策：

  • 轻量工具脚本库 bench/tools/（纯 bash/python，零框架）：累积规则写入 DSH_CONTEXT【任务中发现「下次还会用」的操作 → 固化进 tools/ → 引用替代重写】；首批 webwatch_ctl.sh（8787 status/start/stop/restart/log，已实测）
  • DSH 固化能力查证：有 Cordis 插件（cordis.patch.yml + @deepseek-ai/dsh-* 包）+ —patch 覆盖层，但无 Prime /refine（storages 仅 session 缓存/工作区）→ 外部三层固化体系 = 知识层（CONTEXT+skill）/ 行为层（tools）/ 流程层（任务书模板）——等效 refine
  • 插件框架暂不开发：工具库 ROI 更高（零学习成本、任何任务可引用）；除非未来出现 DSH 内置高频行为（如自动读 CONTEXT）再封装成插件
  • 用户补充：「AI 不休息 + 成本低 → 学习成本可摊薄」——但选投入产出最高的路径（工具库 > 插件框架）；Prime ipython 优势确认，DSH 用 python 脚本等效（慢一点并行补回）

What changed：DSH = 重装打工人（工具越全执行越快）；每任务顺手沉淀 = 我们的 refine 等价物（用户确认：工具库累积本质就是 skill/refine 的性质）。

12. VHDX 迁移 D 盘执行完成（8/15 12:41–12:46，C 盘二次满盘 → 当场迁移）

背景：上午 12:14 发现 C 盘 100% 满（WSL ext4.vhdx 膨胀至 21.6GB）；12:40 用户下令「所有任务暂停，现在就移」。

决策与执行：立即迁移 vhdx C:\Users\Sozo\AppData\Local\wsl\{ecd12f2f-1dcd-4493-8c1f-b3abe4c9f206}\ext4.vhdx → D:\wsl\；注册表 BasePath 已更新；WSL 重启后从 D 盘启动（根 937GB 可用）；webwatch 本地/公网恢复；C 盘可用 9.5GB → 32GB；Prime daemon 恢复（5 workers 全 flash）。

What changed：以后 vhdx 再长不占 C 盘。教训：迁移前无需备份（CONTEXT 全在 D 盘，vault 由 cron 同步）；用户铁律重申（14:15）——安装任何东西一律 D 盘，不碰 C 盘。

13. 高峰放行判定 + 只入队不派发（8/15 14:04–14:27）

背景：peak 时段（14-18）token 花费翻倍，4 个 DSH 任务在跑。

决策：① 运行中任务进度 ≥80-90%（部署收尾）→ 放行跑完；明显卡住/零产出 → 立即暂停（onexox 48 分钟零产出 + CPU 1.7% → 进程树全清 + 登记 paused_sessions.md，off-peak 重跑）② 新任务一律 --queue-only 入域队列，18:00 off-peak 自动派发 ③ 验证依据：DeepSeek 官方 8/16 起新计费 flash peak 0.22/M 正好翻倍——用户 peak 纪律完全正确。

14. 域 Session 队列机制定案（8/15 14:13–14:22，用户批评后）

背景：用户批评「按任务开 session 而不是按域排队」——portalstyle 与 viewer 同时部署同一个 hs-app-portal 互相覆盖（DSH 思考里出现”自己没部署过的东西”）。用户从第一天起就要求按域分（master-app/人生导图/system-ops）。

调研：DSH headless 无 —resume（查 bin.js 源码确认）；tui 未装——原生层面无复用 session 能力。

决策（调度层实现，等效 Prime 常驻 session）：

  • bench/domains/<域>/ 九域：portal / master-app / life-map / system-ops / webwatch / whatsapp / hsdesign / research / misc
  • bench/tools/domain_ctl.sh（enqueue / next / finish / status，实测通过）；同域任务永远串行（RUNNING.lock）；跨域任务必须拆开（viewer 服务=whatsapp 域、portal 卡片=portal 域）
  • 域记忆 = CONTEXT.md（领域知识）+ history.md（完成自动追加；>300 条自动 compact 到 200 + 归档段，完整记录永存 done/）
  • 插队三通道全保留：运行中任务 INTERRUPT 检查点 / 排队任务 cancel+重新入队 / --urgent 跳队（!URGENT- 前缀，实测通过）
  • 铁律入记忆：同域串行、跨域 ≤3、peak 只入队不派发；用户「如果你有打算安装什么东西，记得装在 D，不要装在 C」→ 零安装方案（全 D 盘脚本）

What changed：新任务全部走域队列；18:00 恢复清单 = portal（夜间+logo）→ master-app（bfentry 检查）→ whatsapp（viewer SSO）→ research（onexox），全串行。任务↔session 1:1 绑定事实（13:22 查证）：DSH headless 每次调用 = 独立进程 + 独立 session + 独立工作目录（目录名即工作目录）。

15. DeepSeek V4 规格确认（8/15 14:24）

背景：用户问 DSH 上下文窗口是否 128K——用户记忆正确，Hermes 知识过期。

结论：DeepSeek V4 官方规格 CONTEXT = 1M / MAX OUTPUT = 384K；8/16 起新计费 flash peak 0.22/M。域 history 压缩阈值放宽至 300 条（≈100KB，占 1M 窗口 10%）——不早压缩、不精简过度，质量优先。

16. 报价写入路径澄清 + HSP00015（8/15 12:36–13:00）

决策：报价单走 master-app 系统（hsd-cashflow / quotation SaaS），不是 Google Sheets（Hermes 曾误用 Google Workspace，被用户纠正）。分工：Hermes 只做 item 整理（已完成），写入由 DSH 执行（遵循「任务派 DSH」规则，Prime 只守摊）。用户原则：日常任务与系统架构改动分离——Hermes 作为外部 Agent 通过 API 填资料，不动系统底层（避免越做越多 bug）。HSP00015（Anne 报价）已建，等定价指示；补充项：正门口 grill door（已记 PENDING_TASKS.md）。

17. WhatsApp 新号码规划 + viewer 公网化定案（8/15 13:03–13:14）

  • 旧号 01116880145 迁移行为澄清：WhatsApp 联系人会在迁移后收到换号通知（自动联系新号）；直接打电话仍打到旧号
  • 新号码 = oneXOX 长期 prepaid（免长期订阅、存活约 28 个月，待核实）——只为保留聊天记录而开新号，成本最小化
  • viewer 公网化：用户接受 token 保护（资料不多），不想依赖 Tailscale → 从 portal 进入免 token（SSO）任务已排队 whatsapp 域（14:26）；被拦截时尝试 CDP / OpenClaw CDP
  • 分工重申（13:14 用户原话）：「你的任务是总结和提供 context 等等，然后由 DeepSeek harness 去执行，不是你去执行」

18. 视觉链最终化——OmniParser 排除（8/15 12:20–12:22）

实测三重证据：慢（26s/图 = YOLO 2s + OCR 8s + caption 16s）、实验性质（社区评价）、结果不稳定 → 排除 OmniParser；本地 2B/7B 已删（释放 ~5GB）；用户 research 印证 UI-TARS-1.5 OpenRouter API（ScreenSpot-V2 94.2% 点准）性价比最高。

最终视觉链（用户定案，免费优先）：① Windows MCP（AX 树）免费·最准·多平台发布首选 → ② Gemini 3.7 Flash 免费配额 → ③ UI-TARS-1.5-7B API（OpenRouter，0.20 每 M）→ ④ Qwen3-VL-235B。

19. DeepSeek Harness 开源发布确认（8/15 13:37–13:43）

YouTube 视频 = 【DeepSeek Harness 预览版发布】8/13 开源、MIT、基于 Cordis——就是我们已在用的 DSH。核心信息：① 一切皆插件（模型/工具/沙箱/循环/UI）② 同模型接不同 Harness 任务成功率/成本可差 4 倍以上（框架选择很重要）③ 四种模式：标准 / PTC / 极简 / 创造 ④ 仅追加会话日志（全链路可追溯）⑤ 支持近 40 家模型 ⑥ 内置沙箱安全 + 失败关闭。视频未提及 “pi agent”。

20. 12:00 冲刺前置 + 8787 守护上线（8/15 12:02–12:19）

Prime workers 全部切 v4-flash（settings + 注册表双改，实测生效）；UI-TARS 2B/7B 删除（~5GB）；Prime Google provider 换 Gemini 3.7（仅备用，预算超支短期不用）；8787 守护 webwatch_guard 修复上线（Windows 计划任务每 5 分钟检查，4 次复测全过，schtasks 注册成功）。

21. PI Agent 正式入列——第三 harness 定案（8/15 16:21–16:30，用户定案）

背景：用户问 DSH 作为 coding agent 缺什么（架构师视角）→ 调研发现开源生态：dsh-market 插件市场（541 插件）+ PI agent（earendil-works/pi ★90K MIT，每日迭代）。

Benchmark（Composio 发布）：Pi 通过率 66.7%（vs Hermes 50%）/ $0.012 每任务（最便宜）/ 132s（最快）——三项全胜。

决策：

  • PI 0.84.2 入列（WSL/D 盘零 C 盘），DeepSeek V4 原生直连（DEEPSEEK_API_KEY + provider deepseek），试跑 PI_OK
  • 域队列支持 --harness pi（enqueue 时指定，默认 dsh）；PI session = 明文 jsonl v3 自带 usage+cost
  • webwatch 集成 + Agent Filter（全部/Prime/DSH/PI 多选 chips）入队 webwatch 域
  • 用户策略：主力 PI + 定期观察其他——等真实任务对比数据再最终定夺
  • 注意：PI 无内置权限系统（靠容器化）、默认 4 工具（read/write/edit/bash）

DSH 插件市场（中期候选，装前审查）：distill（蒸馏成技能）/ dsh-compaction（确定性压缩）/ dsh-premise-guard / dsh-mnemon（跨 agent 记忆）/ hermes-dsh-collab

22. 2×2 矩阵实验定案（8/15 16:57–17:15）

目的：同一重度任务下交叉对比 PI/DSH × high/max effort——测 effort 甜点区 + harness 分工（谁省/谁快/谁质量高）。

任务书两轮升级（用户纠正）：报价单生成器不够重（测不出 effort 差异）→ master-app 全核心域模拟（14 实体/21 功能/30 测试，SQLite 代替 D1，不连线上）——用户：「重 = 对，真实场景预演，以后升级架构 agent 要读懂的正是这种量级」。

四路（18:00 off-peak 同时启动）：A PI high / B PI max / C DSH Code Mode high / D DSH Code Mode max；4 路独立工作目录零记忆；DSH Code Mode patch（tools.mode: code，dump-config 验证）；timeout 放宽 4h；成本预估每路 $0.3-0.8。

关键发现：DSH 有 Code Mode + 完整 Subagent 体系（Gemini 3.7 flash 分析经查证为真）——之前一直用默认 native 模式，Code Mode 这个省 token 杀手锏没用上；DSH reasoningEffort: max 可能是成本偏高原因之一。

自愈补齐：任务假活 watchdog（tools/task_watchdog.sh）——5 分钟查 session 增长，15 分钟无产出 kill+重派（≤2 次），2 次仍假活通知人工；三层自愈 = 调用级重试（harness 内置）→ 上下文溢出（PI 原生/DSH 1M）→ 任务级假活（Hermes watchdog）。

23. MasterDB_Graph 归档定案（8/15 17:03–17:08，用户推动）

决策：Sheets 时代图谱 MasterDB_Graph.md → archive/MasterDB_Graph_archive.md（归档非删除，保留演进历史）。

依据（查证）：活信息已 100% 被 D1 覆盖——Item 均价→ItemLibrary 表（47 items）/ 客户主档→Customer 表（27 客户）/ 项目总览→Project 表（18 项目）/ 跟进状态→master-app 跟进筛选。5 个引用文件（KNOWLEDGE_INDEX / Company_Graph / Quotation_Graph / Customer_Lifecycle_Graph / CashflowApp_Graph）全部更新指向 D1 时代真相源。

教训：旧图谱会污染数据读取（agent 读错地方）——但归档前必须查证活信息是否已迁移，不能直接删（ColdCall 跟进表等曾是活信息）。

24. Hermes 版本看门狗（8/15 16:10–16:12）

事实：Hermes v0.20.0 落后 upstream 158 commits；DSH rc.6 已最新；OpenClaw 有更新。

决策：登记每周一 08:00 版本看门狗 cron（自动检测 + 确认升级 + 升级后验证——不全自动，防破坏）；升级 SOP 固化进 skill。用户诉求：agent 要随官方迭代自动迭代。

25. WhatsApp 导出补齐 + Elbert 找回（8/15 17:43–18:09）

背景：用户发现 viewer 里没有 Buildsmart/Elbert 的聊天。

查证：Elbert 聊天从未导出（本地 14 个没有）；邮箱有 32 个聊天导出，本地只下载了 14 个——当时批量下载漏了 18 个（子杰/警察 Marul/阿雄/Perumal/Afiq 等）。

完成：Elbert 找回（79.7MB / 320 条消息 / 228 媒体，含 3 个工地视频）；批量补齐 18 个进行中——8 Drive + 10 Gmail 附件；教训：MCP 并发下载会打崩 MCP server → 必须串行；大 zip（子杰）MCP 120s 超时 → 换 curl/urllib 直连 Drive（走 confirm 流程）。

26. 2×2 实验出结果 + 盲评 → 全面切 PI max（8/15 18:24–19:00，用户拍板）

实验结果（同一重度任务 4 路并行）：PI high 38min/0.054/54 测试；DSH CodeMode high 30min/0.099/58 测试。

盲评（8 维 rubric 匿名 4 包，DSH 独立评分）：PI max 67 分 🥇 / DSH high 59 / PI high 58 / DSH max 57（对账 signed 求和 difference=2000 失真）。

决策：

  • 所有任务全面派 PI max（用户 19:00：重视质量，差价可承受）——domain_ctl.sh 默认 harness dsh→pi + --thinking max
  • 盲评结论修正初判：PI 的 max 值得（+9 分质量）；DSH 的 max 不值得（-2 分还贵 75%）；DSH Code Mode 省钱 40-60% 属实但同配置下 PI 更便宜
  • 月成本（150 任务/月）：Prime ~12（省 63%）
  • 盲评 rubric 固化 skill agent-benchmark-blind-review（以后每次对比实验复用）

27. DeepSeek 8/16 涨价确认 + 应对策略验证（8/15 19:28–19:30）

官方新价（8/16 16:00 UTC 生效）：flash off-peak 0.22/0.014/1.32；官方 peak 时段 = SGT 09-12 & 14-18 = 我们的派发纪律 ✅。

决策：三重应对组合拳（换 PI max 引擎 + off-peak 派发 + 域队列纪律）= 涨价 2× × 0.5 × 0.37 ≈ 0.37× 原成本，比涨价前还省。涨价后月预测：Prime ~33 / PI max ~$29。

28. hsdesign.biz 博客自动化 + about/contact 独立页（8/15 19:44–20:06，21:14 验收）

决策：定期发布博客（每 3 天一篇）提升 Google/AI SEO 信任——blog/blog_queue.md 18 主题（防水/定制柜/扩建/电路/假天花/合同避坑…）+ cron a088262455a8（8/18 20:05 首篇，全套：查证→三语→sitemap→部署→Indexing API 推送）。

about/contact：独立 URL 页上线（/about /contact 200，sitemap 95 URLs，Indexing API 推送，86 文件互链，Drive 源码同步）——补 E-E-A-T 基础信任信号（主页本有内容，缺独立页）。

教训：判断站点缺什么先看 landing page（用户纠正）；源码真相源 = H:\My Drive\hsdesign-site-source\（PI 挂不了 H:，部署后 Hermes 需同步 Drive 源防回退）。

29. briefing 顾客入口方案（8/15 20:42–20:55）

决策：每个顾客 = D1 briefing 记录 + 外链 key（/bf/?key=xxx）+ Drive 顾客文件夹「Briefing Form - 请填写.txt」入口（三语）——点开 Drive → 填一次 → 自动进 D1（upsert 幂等）。已落地 Mr Mark（HSP00015）+ Mr Lee（HSP00016）。

遗留：Lee Drive 文件夹编号 HSP00013 vs D1 HSP00016 不一致；Mr Lee source=call-in vs Google lead——未擅改，等指示。

30. 验收/执行流程教训（8/15 18:31–20:47）

  • agent 自报 commit 必须查 origin（2ac58ed 在 origin main，本地 refs 误报丢失）——验收必检 git log --all + origin
  • 执行类任务整单派 agent（webwatch filter 改动 Hermes 亲自动手被用户纠正）：改代码+验证+重启一条龙给 PI，Hermes 只验收
  • 并行任务改同一仓库防覆盖（portal 夜间模式 vs viewer SSO 补丁第二次互踩）——跨域同仓库场景域队列仍未覆盖
  • PI 卡死救治：jsonl 14 分钟零写入 + CPU≈0 = 死卡（API 挂起）→ kill + 同 session-id 重启接续（jsonl 持久化不丢进度）

关系图谱

反向链接