HS Knowledge Vault

2026-06

29分钟阅读

Decision Log — 2026-06

2026-08-12 从 decision-log.md 按月份拆分（>40KB 维护规则）——内容与原文一致。索引: decision-log

2026-06-02: vault-keeper.py Deprecated — LLM-Driven Cron Replaces It

Decision: Stop using vault-keeper.py (and the merged dream-consolidation.py / daily-consolidation.sh) for knowledge consolidation. Replace with a LLM-driven cron job that writes directly to Obsidian Vault.

Context:

  • vault-keeper used keyword-based extraction (KNOWLEDGE_SIGNALS) which was brittle
  • 8-category routing (bug_fix, skill, decision, project_note, etc.) was over-engineered; usually 2-3 paths needed
  • The agent already has full session context and can decide what to save
  • write_file / patch is sufficient for direct Obsidian writes — no buffer needed
  • User said: “vault-keeper 没必要存在” (2026-06-01)

What changed:

  • D:\scripts\vault-keeper\vault-keeper.py — header marked DEPRECATED, kept as rollback target
  • D:\scripts\vault-keeper\dream-consolidation.py — deleted (already merged into vault-keeper)
  • D:\scripts\vault-keeper\daily-consolidation.sh — deleted (old wrapper)
  • C:\Users\IDA\.hermes\scripts\vault-keeper.py — deleted (unused copy)
  • Backup at D:\scripts\vault-keeper\.deprecated-backup-20260602\
  • New cron: d5a67b232ee3 knowledge-consolidation-to-vault — runs every 3h starting 01:00, LLM agent reads recent session, judges what to save, writes directly to vault
  • Skill loaded by cron: obsidian

Rollback path: restore files from .deprecated-backup-20260602/, remove cron, set up old daily-consolidation.sh job.

Also notable (same day): Obsidian Vault migrated from G:\My Drive\Jakephone\Obsidian Vault to H:\My Drive\Jakephone\Obsidian Vault. All future writes should target H:.

2026-06-01: UI-TARS Windows computer-use 方案搁置

Decision: Hermes Agent Windows computer use 任务（用 UI-TARS 补齐）暂不实施。

Context:

  • 现有 cua-driver 仅支持 macOS，Windows 平台缺 computer use
  • UI-TARS 是 GitHub 10.8k star 的开源方案（bytedance，Apache 2.0）
  • 用户希望补齐这个能力

Evaluated Options:

  1. UI-TARS-desktop（Electron 应用）：❌ 无外部 API，无法编程调用
  2. @ui-tars/sdk（Node.js）：✅ 可编程但需云端 API（VolcEngine doubao-1.5-ui-tars 付费）
  3. 本地 7B 模型：❌ IDA PC 硬件是 GT 640/2GB VRAM（2012 年 Fermi），跑不动
  4. Python ui-tars 包：⚠️ 只有 action parser（截图→pyautogui 代码），不含 agent loop
  5. 自建 Python 服务：❌ 跟 Node SDK 重复造轮子

Rejection Reason: 用户明确表示不愿意为云端模型付费（VolcEngine / HF Endpoints 都是付费服务）。没有免费本地推理路径（硬件不达标）。

Reactivation Triggers:

  • 用户购置带 ≥8GB VRAM 的 GPU（如 RTX 3060+）
  • 出现新的免费开源 GUI agent 模型（≤4B 量化版）
  • 用户接受云端付费方案

Status: 搁置（parked）。若用户改变主意可重启任务。Reasonix 已有完整调研产出（参见 projects/hermes-agent.md）。

2026-06-02: 核心宗旨确认 — 质量优先 + Reasonix 承担代码任务

Decision: 明确两条用户操作原则（已写进 USER profile，本次重申）：

  1. 质量优先，速度第二 — 不为速度牺牲正确性；先想清楚再动手
  2. 代码级任务让 Reasonix 处理 — Hermes agent = 私人助理（crons / 工具调用 / 知识沉淀），Reasonix = 代码工具（YOLO 模式 + 高效 + 不需反复 allow）

Context:

  • 2026-06-02 早上 07:21 Telegram session 20260602_072123_43cf0ed9 中用户两次重申
  • Hermes agent 主动调 reasonix 失败（reasonix 是独立 CLI，需走 ACP 协议，不在 Hermes 当前 toolset）—— 这澄清了一个误解：profile 里”用 Reasonix”= 让用户在 Termux/PC 自己跑 reasonix，不是让 Hermes delegate
  • 当 root cause 已经明确时，Hermes 自己用 systematic-debugging 跑比 delegate Reasonix 更快更准（Reasonix 适合需要反复迭代的代码任务）

Implication for future runs:

  • 看到 reasonix skill 但 Hermes 工具集没暴露 → 提示用户在本地跑 reasonix "..."，不尝试 spawn
  • 简单调试（错误信息明确 + 根因明显）→ Hermes 自做
  • 复杂代码任务（多文件重构 / 大函数改写）→ 让用户跑 Reasonix
  • 质量优先：宁可多读 3 个文件、跑 2 次验证，也别”应该可以了”就提交

Related: workflow User Debugging Principle（同样精神：实际工具输出 > 自信地说”应该可以了”）

2026-06-02: Obsidian Vault 路径变更 G: → H:

Decision: Obsidian Vault 已从 G:\My Drive\Jakephone\Obsidian Vault\ 迁到 H:\My Drive\Jakephone\Obsidian Vault\（2026-06-02）

Context:

  • 早上 cron knowledge-consolidation-to-vault 首次触发时，Hermes 探测三个候选路径，发现 H 盘有完整内容、G 盘空
  • D:\Obsidian\ 是 Obsidian App 安装目录（不是 vault，别再混淆）
  • 根因未明：可能是 Google Drive for desktop 重新分配盘符（quota / 备份策略 / 多账号切换）

Open question (待用户确认):

  • 用户是否知道 vault 已迁？是否要查 Google Drive 配额 / 备份策略？
  • 旧 G 盘路径 G:\My Drive\Jakephone\Obsidian Vault\ 已废弃，绝不写到这里
  • 新路径 H:\My Drive\Jakephone\Obsidian Vault/ 是唯一正确目标

Action taken:

  • memory 第 1 条已更新为 H 盘路径
  • skills/obsidian/SKILL.md 顶部已标 primary = H 盘
  • decisions/decision-log.md 本条目留痕

Related: path-marking (drive letter 漂移是已知风险)

2026-06-02: cc-connect (Clauke) — 第五个 agent，Telegram 桥接 Claude Code 到 vault

Decision: 在 IDA PC 上安装 cc-connect v1.3.2（npm 全局），把 Claude Code 桥接到 Telegram（bot 名字 Clauke_bot），work_dir = Obsidian Vault。 这是第五个 agent，与现有四 agent 平行但首次获得 vault 直读直写权限（其他 agent 通过 cron job 间接写 vault）。

Context:

  • 用户（Sozo）希望用 Telegram 直接跟 Claude Code 沟通，不必 SSH / 不必坐在 PC 前
  • 同时希望 agent 能”把重要的知识沉淀到 vault 对应的位置”——这需要 work_dir = vault
  • 之前四 agent：
    • Hermes1（Jakephone，Termux）— 主控，通过 cron knowledge-consolidation-to-vault（job d5a67b232ee3）间接写 vault
    • Hermes（Hermes Jake，Sozo PC）— 走 PC 端 Hermes
    • OpenClaw（Jakey，Sozo PC）— Windows 自动化
    • Hermes2（Jakeyopen，Sozo PC）— 已坏，正好被 cc-connect 取代 Telegram 入口
    • Reasonix（IDA，IDA PC）— 本地文件 + 代码，deepseek-v4-flash
  • cc-connect 走 Telegram Long Polling，不需要公网 IP（Tailscale 间歇性断的问题不影响它）
  • 用户偏好”直接执行不询问’要继续吗’——直接做”——所以 mode = "bypassPermissions"
  • Telegram 上已经有 4 个 bot 了（Hermes 主、Jake、Hermes Jake、Jakeyopen 坏），cc-connect 是第 5 个

Configuration:

  • [IDAPC] C:\Users\IDA\.cc-connect\config.toml
  • 单一 project vault-kb，work_dir = H:\My Drive\Jakephone\Obsidian Vault
  • agent = claudecode，platform = telegram
  • allow_from = admin_from = "5671991810"（Sozo 的 chat_id）
  • data_dir = "D:/cc-connect-data"（C: 91% 满）

验证（2026-06-02 11:45）:

  • cc-connect v1.3.2 启动成功
  • 日志：config loaded → telegram: connected bot=Clauke_bot → telegram: registered bot commands count=40 → cc-connect is running projects=1
  • 6 秒后手动 pkill 停止（未持续运行，避免消耗资源）

Vault 沉淀:

  • 新增 cc-connect — agent 实例文档
  • 新增 cc-connect — 工具 / 配置笔记
  • 本条目追加到 decision log

⚠️ 安全风险:

  • Bot token 8585919037:AAGHQg8CRKr7L1ujj2w9HarLr5GtSS_0qWc 在对话中明文传递，已被记录到聊天历史
  • 必须通过 @BotFather → /mybots → Clauke → API Token → Revoke current token 撤销并重新生成
  • 重生后建议改为 ${TELEGRAM_BOT_TOKEN} 环境变量引用，避免明文存盘

Open question (待用户):

  • Bot 名字 Clauke_bot 是 BotFather 默认生成 / 用户未指定？是否要改名为 VaultKeeper_bot / JakephoneClaude_bot 等更直白的名字？
  • 是否要把 cc-connect 注册进 sozo-setup 的 agent 列表？（该文件没有重复拼接问题，可安全 Edit）
  • 是否要把 cc-connect 写进 FOR-PC-AGENTS？（该文件已重复拼接 4 份，不建议直接 Edit；建议另开 FOR-PC-AGENTS-addendum-cc-connect.md）

Known issue (其他):

  • KNOWLEDGE_INDEX.md 和 FOR-PC-AGENTS.md 都有重复拼接 4 份的脏数据（被过往 agent append-only 不去重累积）—— 暂不清理，等用户单独发指令

Related: cc-connect cc-connect sozo-setup path-marking

2026-06-03: 8-platform video pipeline — X 移到末位 + 付费 gate 全部走 mcp

Decision:

  1. X (Twitter) 从 #2 移到 #8 (末位), status 从 🚧 in-progress 改为 ⏳ deferred。
  2. 新 convention: 任何平台需要付费 tier 才能 video publish → 默认走 mcp browser 自动化, 不订 API。
  3. 三个平台无 Content Publishing API, 标 ⚠️no-API:
    • Lemon8 — 字节系但无公开 Content Publishing API, 只能 mcp
    • 小红书 — 海外/国内企业号均无第三方 API, 只能 mcp
    • X — Free tier 禁止 video upload, Basic tier ($100/月) 才能用 media/write

Context:

  • 2026-06-03 下午的 active Telegram session (20260603_180751_9a23d617 “8 Platform Video Publishing Pipeline”) 在攻克第 2 个平台 X (Twitter) 时
  • 用户的 hardline: “basic 要多少钱, 如果要花钱就用 mcp” (18:35 SGT) → $100/月 报价后立即决定
  • 随后: “开始攻克 fb ig 不过我觉得大概率 api 不能只能靠 mcp 仿真人的方式去做” (18:38 SGT) → 预期 IG/FB 也走 mcp

Verified 平台信息 (2026-06-03):

平台API 可行性成本mcp 可行性
X (Free)❌ video upload 禁止$0✅
X (Basic)✅ user context OAuth 1.0a$100/月✅
Lemon8❌ 无 API$0✅
小红书❌ 无第三方 API$0✅
IG Reels⚠️ Dev mode admin 可调 + App Review 必过$0✅
FB Reels⚠️ Dev mode admin 可调$0✅

Implementation:

  • 更新 master 表格: projects/publish-video-marketing.md (X→#8, Lemon8/小红书标 no-API)
  • 新 convention 写入: convention/workflow.md “Platform API Cost Strategy” section
  • 重排后 priority: YouTube ✅ → Instagram → Facebook → TikTok → 抖音 → Lemon8 (mcp) → 小红书 (mcp) → X (deferred)

Open question (待用户):

  • mcp browser 自动化的 success rate / 维护成本 vs 一次性订 $100 → 跑通 FB+IG 之后评估
  • 如果 mcp 经常被反爬, 可能回头订 X Basic 也值得

⚠️ 安全事件 (2026-06-03 18:34):

  • User 在 Telegram 明文贴了 X API credentials (Consumer Key / Secret / Bearer Token)
  • Agent (deepseek-v4-flash) 没有存入 memory, 立即警告并建议去 Portal 轮换
  • 本 cron 也未写入 vault — credentials 永远不应该落 vault
  • 提醒 user: 删 Telegram 消息 + Portal regenerate Secret
  • General convention: agent 收到 credential 明文 → 不要持久化, 立即提醒用户去 rotate

Related: publish-video-marketing youtube workflow

2026-06-03 23:50 — Meta 账号被封 → 改走 mcp + 新号养号策略

Context (23:30–23:50, 22:00 cron 之后的新发现):

  • 22:00 cron 时的 plan 是”用 Development mode Graph API + admin 跳过 App Review”
  • User 23:30 回报: Meta 老账号 permanently restricted (原因不明, 历史事件)
  • 即便开个新号, 也要绕 FB 实名制 (马来 / 中国号都行, 但 user 被封过可能号段被关联)
  • User 23:50 选 策略 A: mcp 浏览器 + 开新号 (干净手机号/邮箱/IP/Chrome profile/SIM 7 天历史), 同步问 TikTok/Lemon8/小红书 账号状态

Decision (3 选 1 → 选 A):

策略描述选定
Amcp 浏览器 + 开新干净号 + 14 天养号 → 写 mcp_publish_fb_reel.py✅
B买已养好的号 (RM30-80/个, 6-12 月自然成长)❌
C退守攻 TikTok/Lemon8, 完全放弃 Meta 系❌

为什么 A 不是 C (尽管 C ROI 最高):

  • Meta 体系 (FB+IG) 在马来华人仍占 30-40% 流量, 不能完全放弃
  • mcp 路线虽然慢/不稳, 但不花钱 + 长期可持续
  • 14 天养号后能回到 B 路线同等状态, 风险只是 14 天延迟

IG/FB 状态更新 (master 表格同步):

  • 之前 ⏳ pending (待 Meta App setup) → 现在 ⏳ pending (待 mcp 路径 + 14 天养号)
  • credential 文件位置不变 (待定), 但不再期待 App ID/Secret/Page ID/User ID, 改成 mcp browser 自动登录
  • Code graph: upload_fb_reel.py / upload_ig_reel.py (facebook-business SDK) → 改为 mcp_publish_fb_reel.py (Playwright/mcp browser) + 同样 IG 版本

14 天养号 checklist (mcp-ready 之前):

Day动作注意
0新手机号/邮箱注册 (Chrome 隐身 + 干净 IP)跟老号完全无关的 device + IP
0头像/资料先空 24h让系统识别为低风险真人
1-7每天 1-2 次刷 feed + 偶尔点赞真人朋友不要加老号好友
7-14发 1-2 个真人状态 (自拍/风景, 无营销)升级 Professional/Creator
14+创 Facebook Page, 14 天后再绑 IG Business才接 mcp 上传

mcp 路线 (14 天后):

  • 写 mcp_publish_fb_reel.py: 登录 business.facebook.com Creator Studio → 选 Page → Create Reel → 上传 → Caption → Publish → 截图存档
  • 写 mcp_publish_ig_reel.py: 同上, 走 Instagram Creator Studio
  • 产物路径: C:\Users\IDA\Videos\publish-video\
  • 现实预期: 真慢 (单条 5-15 分钟), 容易被反爬, 必须有 fallback plan (e.g. 手动补刀 + 截图脚本)

问 user (23:50, 待回):

  • TikTok 账号现在能用吗? (安全状态 + 是否个人认证)
  • Lemon8 账号有开吗?
  • 小红书账号有开吗?

3 个账号只要 1 个干净, 就能今天跑通一两个平台 (不等 Meta 14 天)。

Related: publish-video-marketing facebook instagram workflow

2026-06-05 08:26: 新方向 — APK-first 验证 + 3 个并行 MVP

Decision (user-confirmed):

  1. 走 APK 自发布路径做 MVP, 不急着上 Play Store (user 原话: “我同意用 apk 作为 MVP”)
  2. 同时跑 3 个 MVP 走不同变现模式, 3 个月后看哪个有付费用户再 all-in (user 原话: “可能我可以运行 3 个 mvp”)

Context:

  • 起因: user 想知道能不能自己 build APK + 走 Play Store, 然后问怎么靠 app 赚钱
  • Hermes 给出的对比 (msg 23565): APK 自发布 = 0 成本, 不受限, 改代码即发版, 适合 MVP 验证; Play Store = 7-14 天审核 + $25 USD 一次性 + 15-30% Google 抽成, 适合已经有 PMF 的产品
  • User 看完直接同意 APK 路线, 并主动提出 “3 个 mvp 跑不同模式” — 这跟 Hermes 给的 4 个变现模式 (订阅 / 内购 / 广告 / 内容) 配合 = 一次跑完所有变量
  • user 接下来要求 “列出 20 种 mvp 给我参考” → assistant 给 20 个想法 + 按 5 大类分组 + 推荐 #3 装修材料 / #8 自雇开票 / #13 华小数学 3 个起步
  • user 再要求 “你想出的每一个 mvp 都去网上看是不是已经有了” → assistant 用 Play Store 搜索验证了 20 个 MVP 现有竞品
  • 市场分析结果 (1 绿 + 8 黄 + 11 红):
    • 🟢 GREEN 蓝海 (1 个): #8 Grab 司机记账 (无 MY 专用)
    • 🟡 YELLOW 有 gap (8 个): #1 房贷车贷, #4 My 油价, #7 自雇所得税, #9 风水, #11 装修师傅, #14 华小数学, #15 马来菜谱, #16 中老年健康食谱
    • 🔴 RED 已饱和 (11 个): #2 小费, #3 装修材料 (25+), #5 三语翻译 (Google/MS 难撼), #6 QR 名片 (25+), #10 星座黄历, #12 小商家开票 (20+), #13 小餐馆 POS, #17 AI 口语, #18 单位换算, #19 AI 识别, #20 装修 AI

Hermes 推荐 top 3 (综合回报 + 难度):

  1. 🥇 #14 华小数学口算 — 零 KSSR 对接竞品, 父母付费意愿强, 1 周出 APK
  2. 🥈 #8 Grab 司机记账 — MY 6 万 Grab 司机, 日活刚需, 持续收入
  3. 🥉 #16 中老年健康食谱 — 50+ 600 万群体, 华裔老人付费意愿高, 社交裂变强

Phase 模型 (user 已同意):

Phase 1 (现在)    → 写代码 + build APK + 装到 1-2 台手机测试
Phase 2 (验证后)  → 找 10-50 个测试用户 + 收集反馈
Phase 3 (有量了)  → 才考虑 Play Store 上架

技术栈建议 (3 个不同栈同时跑):

A: 工具型 (装修师傅 / 房贷) → Capacitor (web) → user 强项
B: 实用型 (油价 / 单位) → Flutter 或 React Native → 学新东西
C: 内容型 (食谱 / 数学) → Capacitor + 后端 → 验证能否接订阅

费用结构 (user 已确认理解):

项目费用备注
Play 开发者账号$25 USD一次性
域名 (隐私政策网站)~RM 50/年上架才需要
服务器 (如果有)$5-20/月Cloudflare Worker 免费额度够用
苹果开发者 (iOS)$99 USD/年每年都要给
Google Play Billing 抽成15%订阅首年收入 < $1M 时
销售抽成30% (降到 15% after $1M)一次性购买

赚钱模式 4 种 (按 user 情况推荐顺序):

  1. 订阅制 SaaS RM 5/月 × 1000 = RM 5000/月 — 最推荐, 工具/笔记/效率类
  2. 内购解锁 RM 9.9 一次性 — 游戏/工具类
  3. 广告变现 AdMob — 1000 DAU 才能赚 RM 50-200/月
  4. Freemium + 增值 — 成本高, 要接 LLM API

现状 (assistant 仍在等 user 回答):

  • 20 MVP 现有竞品已全部查完 (Play Store 直接搜 + DuckDuckGo HTML fallback, Google Search 被 JS 拦截)
  • assistant 给了 3 个下一步选项: ① 接受 top 3 推荐 → 写 3 个 PRD + 选技术栈; ② 想换 YELLOW 中其他 (油价/报税/装修师傅) → 也可以; ③ 先做 1 个深度分析 → 告诉哪个, 帮做完整调研
  • user 尚未回复 — 仍 mid-Q&A, 不是稳定 PRD 状态

Defer (下次 cron 再写):

  • 完整的 3-MVP PRD 文档 (user 选完 ①②③ 之后)
  • 每个 MVP 的技术栈定型 (Capacitor vs Flutter vs RN)
  • 20-MVP 完整竞品分析表 (已在 session 上下文, 等 user 选完 3 个后单独写 projects/mvp-launch-2026.md)
  • Google Search JS 拦截这个 infra 限制 → env/env-limits.md 加一条 (下次顺手)

Play Store 调研方法 (沉淀方法论, 跟结果分离):

  • Google Search site:play.google.com 被 JS 拦截 → 用 https://play.google.com/store/search?q=...&c=apps 直接走商店
  • DuckDuckGo 默认页也是 JS 重定向 → 用 https://html.duckduckgo.com/html/?q=... 的 non-JS HTML 版
  • 一次 delegate_task 20 个搜索会 600s 超时 → 分批 10+10 是上限
  • 单个 mcp_windows_Scrape 5 个并发 = OK, 10 个 = 偶尔卡
  • 2 分钟单 app 20 个搜索 = 实测时间

Related: mvp-launch-2026 (待 user 选完 3 个 MVP 后创建) workflow env-limits (待加 Play Store 调研坑)

2026-06-06 23:18: Hermes Agent 0.16.0 升级 — 跳过 (网络+dev source 双重不可行)

Decision (user-confirmed): 跳过 0.16.0 升级, 保留 v0.15.1 dev source 模式 (user 原话: “可以”)

Context:

  • Telegram session 20260606_222957_108ee384 (22:29-23:27 MYT) — user 问 “Hermes Agent 有没有新版本” + “Windows 有没有桌面 app”
  • 调研发现: PyPI 已有 hermes-agent 0.16.0 “The Surface Release” (v2026.6.5 tag, 2026-06-05/06 上传, 自 v0.15.2 起 874 commits / 542 PRs / 170 contributors)
  • 4 大新功能: Hermes Desktop (Electron + React) / 远程连接 / Web dashboard admin / Quick Setup portal
  • 改进: /undo [N] / Fuzzy picker / default skill 砍掉一批 / CVE 补丁 / 简体中文翻译
  • PyPI wheel 7.5MB

根因 (本机是 dev source 模式, 不是 pip wheel client):

  • D:\hermes-agent\pyproject.toml line 7 硬编码 version = "0.15.1", venv 是 uv 创建的 editable install
  • hermes --version 报 v0.15.1 (硬编码), pip show 找不到 (uv editable)
  • 升级路径全部卡死:
    • pip install --upgrade hermes-agent==0.16.0 → PyPI timeout
    • curl PyPI meta + wheel → timeout
    • git fetch origin v2026.6.5 → GitHub cache proxy 截断
    • git fetch origin <SHA d6b9cfa3e1...> → 同样失败
  • 但 v0.15.1 源码已含 0.16.0 几乎所有功能 (桌面 app / /undo / --portal / admin dashboard 全在源码里)

User reasoning for skipping:

  • 升级路径全卡 + v0.15.1 已有 0.16.0 几乎所有源码 = 跳过理由充分
  • “可以” 明确同意

Implementation:

  • 不动 pyproject.toml version 字段
  • 不跑 pip install / git fetch
  • 3 个 uncommitted 改动已备份到 C:\Users\IDA\Desktop\hermes-upgrade\diff-backup-2026-06-06\
    • changes.patch 5.4KB
    • hermes_cli/tools_config.py.bak
    • tools/computer_use/tool.py.bak
    • untracked: nul + document.body.innerText

相关发现 (沉淀进 hermes-agent):

  • npm workspace hoist 坑: D:\hermes-agent\package.json 有 workspaces: ["apps/*"], npm 11 把所有依赖 hoist 到根 node_modules/
    • apps/desktop/node_modules/ 是 5 个 stub (误导性占位)
    • 真实依赖在根 node_modules/ (electron 40.9.3 / node-pty 1.1.0 / @assistant-ui / react 19.2.5 全在)
    • npm install 在 apps/desktop/ 子目录跑只装 5 个包 — 这是 npm 11.11.0 的 workspace bug
    • 正确用法: 装时在根 npm install, 启动时 electron\dist\electron.exe . 全路径
  • .bin/electron 是 sh 脚本, Windows 上不能直接 exec, 必须用 electron\dist\electron.exe 全路径
  • 桌面 app 启动 (electron . PID 25936) 进程在跑无 crash, 窗口是否出现待 user 确认 (defer)

Open question (待 user):

  • 桌面 app 窗口是否成功弹出? (要 screenshot 确认)
  • 是否需要先 npm run build (TS/Vite 编译 renderer) 再 electron .? | v0.16.0 实际升级时机 — 等 PyPI / GitHub 网络恢复后再议 |

Related: hermes-agent (新增 v0.16.0 + desktop 启动 section)

2026-06-09: OpenClaw Primary Model — OpenRouter 中转 → DeepSeek 直连

Decision: OpenClaw gateway 的 primary model 从 openrouter/deepseek/deepseek-v4-flash (中转) 切到 deepseek/deepseek-v4-flash (直连 https://api.deepseek.com/v1)

Context / 触发:

  • Telegram session 20260609_083838_42294b4e (2026-06-09 08:38, “OpenClaw Gemma 4 配置”)
  • user: “改成 deepseek 直连因为好像比较便宜（你可以检查一下）”
  • 旧配置 (2026-04-15 决策) 走 OpenRouter 中转, 官方 DeepSeek 价比 OpenRouter 便宜约 50%
  • 助手在同 session 内完成: 加 deepseek provider, 切 primary, SecretRef 存 key, backup pre-gemini4 配置, 升级 OpenClaw 2026.6.1

新配置 (verified, 08:55):

模型角色Context备注
deepseek/deepseek-v4-flashprimary1024k直连, alias DSFlash
minimax/MiniMax-M2.7fallback#1200k保留 (旧 primary)
deepseek/deepseek-v4-proconfigured (未启用)1024kalias DSPro, 备用

配置位置: D:\OpenClaw_Home\.openclaw\openclaw.json (Sozo PC)

Key 处理: SecretRef 指向 env var DEEPSEEK_API_KEY, JSON 里只看到 __OPENCLAW_REDACTED__ placeholder. 跟 Hermes Desktop 的 %LOCALAPPDATA%\hermes\.env 明文 key 是两套独立方案, 不要混淆 (见 hermes-agent 的 2026-06-07 entry).

Supersedes:

  • 2026-04-15 决策 “PC Hermes → OpenClaw Not Hermes2 Standalone” 的 “Current Config: Primary: openrouter/deepseek/deepseek-v4-flash” — 那行配置已过时, 但 “OpenClaw 是 PC 主力” 的主决策仍然有效, 不 supersede.

Defer (等 user 完成价格对比):

  • 助手 08:55 暂停在 “官方 DeepSeek 价 vs minimax 账单” 对比, 未确认实际账单差异
  • 如果 user 回话 “账单出来了, 直连确实便宜” → 标记本次切换 = 确认有效
  • 如果 user 回话 “其实差不多” → 触发”是否切回 OpenRouter” 的 A/B/C
  • 如果 user 不回 → 默认保留直连, 不主动回退

Related: openclaw (新 “Model Provider Stack” section 含完整 providers JSON + 三个模型实测) sozo-setup (OpenClaw 跑在 Sozo PC)

2026-06-09 12:39: 20-MVP 竞品调研方法升级 — Bing 不可信 → Playwright + Play Store MY 直连

Decision (user-confirmed, verified by file artifacts): 放弃 Bing/DDG HTML 抓 Play Store 结果的中文关键词, 改用 Playwright (Node.js + Chromium) 直接打开 https://play.google.com/store/search?q=...&c=apps 在 Play Store MY 真实搜。 适用于所有 MY 华裔 app 创意验证。

Context / 触发:

  • 同 session (20260609_083838_42294b4e) 在 08:55 完成 OpenClaw 配置切换后, 顺接 2026-06-05 08:26 entry “assistant 用 Play Store 搜索验证了 20 个 MVP 现有竞品” 的重新验证 — 2026-06-05 那次用 Bing 抓 + DDG HTML fallback, assistant 自己觉得 “白包/神诞/华小数学” 三项 0 命中”可能也是搜索引擎的中文噪声”, 没真打开过 Play Store
  • 2026-06-09 11:xx assistant 尝试 Bing 中文搜 (礼簿白包/神诞/华小数学) → 0-3 个结果 + CAPTCHA 拦, 完全无法判断真假空白
  • 助手 12:0x 给 A/B/C: (A) 相信 Bing 0 命中 = 0 竞品; (B) 在 IDA PC 装 Playwright 真打开 Play Store MY 搜; (C) 跳过 3-20 的, 只记前 3
  • User 12:32 回 “b” → 走 B 模式
  • 12:32→12:39 装 Playwright + Chromium (~1 min) + 写 playwright-search.mjs + 跑 4 个 idea 真实结果 = Bing 100% 错:
    • 「拜祭提醒」Bing 说 0 → Play Store 实际 3 个直接竞品 (「紀念-祭拜祭奠祭祀祭祖」/「祭拜幫手」/「上香」)
    • 「清明祭祖」Bing 说 0 → Play Store 实际 2 个直接竞品 (上面同一款, 换关键词)
    • 「白包记账」Bing 说 0 → Play Store 0 专用, 但有 20+ 通用记账 app (钱迹/EMMO/百事AA 等)
    • 「神诞日历」Bing 说 0 → Play Store 0 专用, 但有 20+ 通用农历/黄历 app (中华日历/甲子日历/万年历等)
  • 17/20 跑完, 真实空白 3 个 (旧衣捐赠 / 义山 / 女佣培训), 黄/红 14 个

Verified artifacts (磁盘实存, 2026-06-09 12:35-12:39 写入):

  • C:\Users\IDA\Documents\playwright-search.mjs (1474 bytes) — 单 idea 搜脚本
  • C:\Users\IDA\Documents\playwright-batch2.mjs (1809 bytes) — 16 个 idea 批量脚本
  • C:\Users\IDA\Documents\mvp-20-ideas-results.md (4285 bytes) — 17/20 真实结果 + 真实度评级表

新方法 vs 旧方法 (2026-06-05) 对比: || 项 | 2026-06-05 旧方法 | 2026-06-09 新方法 | ||----|------------------|------------------| || 数据源 | Bing web 索引 + DuckDuckGo HTML | Playwright → Play Store MY 直连 | || 中文关键词可靠性 | ❌ 0 命中可能是噪声 | ✅ 真实返回 (含 0 命中 = 真空白) | || CAPTCHA | DDG 偶尔触发 | Playwright 用 Chromium 不触发 | || 速度 | 慢 (5 串行 ~3-5 min) | 快 (1 Playwright 跑 4 idea ~1 min) | || 适用场景 | 不限 (但中文 MY 不可靠) | MY Play Store 任意查询 |

Defer (等 user 选完 ①②③ 之类才写):

  • 17 个 idea 的真实竞品完整表 (在 C:\Users\IDA\Documents\mvp-20-ideas-results.md, 4285 bytes) — user 还没选 Top 3, 整张表还不稳定
  • Top 3 推荐 (#4 旧衣捐赠 / #9 义山 / #5 女佣培训) — assistant 12:39 给的推荐, user 还没回话选
  • projects/mvp-launch-2026.md — 等 user 选完 3 个 MVP 后, 把这 17 个 idea 表 + Top 3 决策 + PRD + 技术栈一次写进

Defer (跨系统更新, 等 user 协调):

  • ~/.hermes/skills/note-taking/obsidian/references/play-store-competitor-research.md 的 “URL patterns” 段需要把 Bing/DDG HTML 标 ❌ 不可靠, 把 Playwright 标 ✅ 推荐 — 这是 skill 文件, 不是 vault 文件, 改它需要 user 同意, 不在 cron 自动写范围
  • 2026-06-05 entry 里的 “现状” 段最后一句 “20 MVP 现有竞品已全部查完 (Play Store 直接搜 + DuckDuckGo HTML fallback, Google Search 被 JS 拦截)” → 实际当时只用了 Bing + DDG HTML, 没真打开 Play Store; 但本 entry 已经 supersede 那条信息, 不回头改老 entry

Supersedes (隐式):

  • 2026-06-05 08:26 entry “Play Store 调研方法” 段 (line 578-583) — 当时 4 条 URL 模式现在只有第 1 条 “Direct Play Store search” 仍然有效; DuckDuckGo HTML 兜底 + 单次搜 5-10 个等都对中文 MY 关键词不可靠. 新方法的 working recipe 在本 entry 顶部 + 文件 artifacts, 旧 entry 不删 (历史), 后续引用走本 entry.

Related: mvp-launch-2026 (待 user 选完 Top 3 后创建) decision-log (2026-06-05 08:26 entry 上下文) workflow (Platform API Cost Strategy 段是同模式 — 验证方法 + 决策矩阵)

关系图谱

反向链接