作者你好，Horae 重度用户，先谢插件，长篇RP的账本全靠它。
动机
- rulesPrompt（格式规则）常驻主 prompt 约 3-5K token，主 API 用按量计费模型时是每次请求的固定开销
- 主 AI 同时要 RP + 严格输出全部 horae 字段，长对话里注意力一分散就漏标签、或正文质量下降
- 所以想让主 AI 完全不知道 Horae 的存在：专心写正文，记录的活儿全部外包
我的本地实现（基于 v1.10.1 魔改，供参考）
- 主 AI 收到的注入只保留 dataPrompt（场景/服装/在场/物品/关系/情绪）+ 向量召回，不再注入 rulesPrompt
- onMessageReceived 后异步调辅助 API，喂 5 类材料：当前正文、状态快照（generateCompactPrompt）、最近 20 条 events 时间线、现有 trackEvents 列表、最近 N 条历史正文（N 可配，默认 3）
- 辅助 API 反解出标签后写入 horae_meta，面板在主回复显示后 2-5 秒异步更新
实测（副 API 用 DeepSeek V4 Flash，跑了一个多月）
- 正文末尾不再有标签，主 AI 文风明显更稳
- 已知局限：辅助 API 逐条看正文，10-20 楼前埋的长程伏笔可能漏判 trackEvent；swipe/regenerate 会重跑一次辅助 API
为什么发 issue 而不是 PR
我的基线还停在 v1.10.1，和现在的 main 差了几十个版本，直接 PR 冲突会非常多。另外注意到 v1.14 的"发送前自动补全上一条 AI 消息时间线"其实已经具备了核心能力——如果把它从"缺标签时兜底"扩展成一个可选的常态模式（主 AI 不注入规则、每条消息都由辅助 API 分析），架构上应该是顺路的。
如果这个方向你有兴趣，我可以把 diff 整理出来供参考。再次感谢维护这个插件。
作者你好，Horae 重度用户，先谢插件，长篇RP的账本全靠它。
动机
我的本地实现（基于 v1.10.1 魔改，供参考）
实测（副 API 用 DeepSeek V4 Flash，跑了一个多月）
为什么发 issue 而不是 PR
我的基线还停在 v1.10.1，和现在的 main 差了几十个版本，直接 PR 冲突会非常多。另外注意到 v1.14 的"发送前自动补全上一条 AI 消息时间线"其实已经具备了核心能力——如果把它从"缺标签时兜底"扩展成一个可选的常态模式（主 AI 不注入规则、每条消息都由辅助 API 分析），架构上应该是顺路的。
如果这个方向你有兴趣，我可以把 diff 整理出来供参考。再次感谢维护这个插件。