Hermes Decision Trace

text

这是一条由 Feishu 长回复 guard 自动补救生成的 decision trace。原回复超过飞书安全展示阈值，已转为 HTML/wiki/retain 后再回发短入口。

HTML完整论证

Wiki可检索归档

Feishu短入口交付

🎯

核心结论

这是一条由 Feishu 长回复 guard 自动补救生成的 decision trace。原回复超过飞书安全展示阈值，已转为 HTML/wiki/retain 后再回发短入口。

🧭

推荐路径

可以吸收，但只吸收为“微信文章原文采集源”这一层，不要上升为 Hermes 微信知识库主架构。

🛡️

关键边界

不调用真实 executor；生产动作另走审批。

关键判断

判断项	摘要
推荐方案	可以吸收，但只吸收为“微信文章原文采集源”这一层，不要上升为 Hermes 微信知识库主架构。
关键依据	见完整记录中的评分依据、状态摘要和证据链。
落地方式	按行动清单推进，保持可回退。
风险边界	不跨执行边界；真实执行需另走审批。

证据摘要

由 Hermes 会话生成。证据点 1
如涉及外部事实，应在正文中保留来源或验证路径。证据点 2

行动清单

可以吸收，但只吸收为“微信文章原文采集源”这一层，不要上升为 Hermes 微信知识库主架构。

优先级判断：

如果目标是“快速把少量公众号文章保存成本地 Markdown”：它值得马上试。

如果目标是“建设稳定微信资料归档 pipeline”：它只能作为参考实现，不能直接承担主链。

如果目标是“接入 Hermes 知识治理”：先做 wrapper + staging，再做规范化 ingest，不要直接把输出当最终知识库。

我建议下一步做一个很小的验证任务：

边界 / 风险

风险点

未记录额外风险。

完整记录

本节目录结论摘要完整记录与现有 Hermes 知识治理的关系关键风险清单最终建议

text

结论

这是一条由 Feishu 长回复 guard 自动补救生成的 decision trace。原回复超过飞书安全展示阈值，已转为 HTML/wiki/retain 后再回发短入口。

摘要

代码块或：代码块然后由 Hermes ingest 做后处理。 Phase 3：做 Hermes native adapter 如果试用稳定，再考虑拆成 native adapter：代码块这时 wechat-notebank 的 parser 和 importer 逻辑可以参考，但不一定直接依赖它。 --- 与现有 Hermes 知识治理的关系 wechat-notebank 更像一个“原文采集器”，不是“知识治理器”。 Hermes 现有偏好的知识落点是： - 索引类内容：优先 wiki - 正式入库…

完整记录

~/llm-wikis/wechat-archive/raw/

或：

~/.hermes/data/wechat-notebank/staging/

然后由 Hermes ingest 做后处理。

Phase 3：做 Hermes native adapter

如果试用稳定，再考虑拆成 native adapter：

wechat URL queue -> browser fetch -> parser -> markdown normalizer -> asset downloader -> metadata registry -> wiki/retain/feishu doc -> Feishu card receipt

这时 wechat-notebank 的 parser 和 importer 逻辑可以参考，但不一定直接依赖它。

---

与现有 Hermes 知识治理的关系

wechat-notebank 更像一个“原文采集器”，不是“知识治理器”。

Hermes 现有偏好的知识落点是：

索引类内容：优先 wiki
正式入库：飞书主库
决策型回复：短卡片 + HTML + wiki/retain
长期项目：项目状态文档
技能流程：skill/reference

因此，微信公众号文章归档可以映射为：

wechat-notebank 输出原文 Markdown -> Hermes 规范化元数据 -> 原文层入 llm-wikis/wechat-archive/raw -> 重要文章生成引用素材 / 摘要 / 复盘 -> 必要时入飞书主库 -> retain pointer 只保留索引，不塞全文

这样不会把 Obsidian 四层结构和 Hermes 现有体系打架。

---

关键风险清单

风险	严重度	说明	建议
微信页面结构变化	高	selector 依赖 `#js_content`、`#activity-name` 等	保留 parser 回归样本
图片长期失效	高	目前更像保留远程图片 URL	Hermes 后处理下载图片
npm 未发布	中	只能从 main tarball 安装	pin commit 或 fork
配置依赖 cwd	中	cron/agent 下容易找不到配置	wrapper 强制 `-o`
Markdown 不够纯	中	正文可能仍是 HTML	加 HTML→Markdown 规范化
社区成熟度低	中	无 release/PR，star 不多	先试用不主线依赖
大规模去重性能	中	扫目录 Frontmatter	Hermes 用 registry/sqlite
登录态/受限文章	中	未覆盖复杂微信场景	明确只支持公开 URL

---

最终建议

可以吸收，但只吸收为“微信文章原文采集源”这一层，不要上升为 Hermes 微信知识库主架构。

优先级判断：

如果目标是“快速把少量公众号文章保存成本地 Markdown”：它值得马上试。
如果目标是“建设稳定微信资料归档 pipeline”：它只能作为参考实现，不能直接承担主链。
如果目标是“接入 Hermes 知识治理”：先做 wrapper + staging，再做规范化 ingest，不要直接把输出当最终知识库。

我建议下一步做一个很小的验证任务：

固定 commit 安装或临时 clone。
找 10 篇公众号文章。
跑单篇和 Excel 批量。
生成验收表：

成功率
标题准确率
发布时间准确率
图片可用率
代码块保真率
Frontmatter 可 ingest 率

若通过，再沉淀 Hermes skill。

---

gpt-5.5 · 2026-05-26 · 12:51 (2/2)