osiman/reader
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2df0af5b8220cbe8d6d723c3aaf00ae24d904844
reader/docs/openclaw/digest-optimization-summary.md
T

7.1 KiB
Raw Blame History

Digest Optimization Summary

背景

reader → OpenClaw 日报链路原先的问题主要有两类：

  1. OpenClaw public digest 输入过重

    • public digest 直接读取完整 openclaw-delivery-payload.json
    • 其中混有大量不直接服务公开日报的字段
    • public digest 这一步在 OpenClaw 侧消耗了较多 token

  2. public / internal 生成逻辑没有充分拆分

    • public digest 与 internal review digest 都基于完整 payload 推导
    • 容易造成重复消耗
    • public digest 还可能被 review / 内部流程语义污染

本轮优化的目标不是重写 reader 主流程，而是在不破坏现有 delivery payload 的前提下，先把 public digest 的输入和生成方式收敛下来，并验证整体 token 与内容质量的变化。

本轮改动

1. reader 新增 digest-brief.json

在 FreshRSS pipeline 写出：

  • outputs/freshrss/rerun/<run-id>/candidates/openclaw-delivery-payload.json

之后，额外生成：

  • outputs/freshrss/rerun/<run-id>/candidates/digest-brief.json

用途：

  • 供 OpenClaw 生成 public digest 时优先读取
  • 作为 public-only 的轻量输入视图

当前约束：

  • 仅保留 selection_decision == "keep" 的候选
  • 默认最多保留前 5 条
  • 高亮 highlights 最多保留 3 条
  • schema 标识为 digest-brief.v1

保留字段：

  • title
  • source_name
  • summary
  • highlights
  • category
  • digest_rank
  • selection_decision
  • url

附带计数：

  • source_candidate_count
  • candidate_count

2. public / internal 输入边界拆分

当前推荐口径：

  • public digest

    • 优先读取 digest-brief.json
    • 仅使用 public-only 输入视图

  • internal review digest

    • 继续读取完整 openclaw-delivery-payload.json
    • 保留 keep / review 的决策上下文

这样做的原因：

  • public digest 需要更轻、更干净的公开输入
  • internal review digest 仍然需要完整上下文来支撑判断、待确认与建议沉淀

3. digest 成稿的正式落盘位置

正式 run 生成出的 digest 成稿，不应停留在 OpenClaw 的临时目录，而应回写到同一次 reader run 目录下。

推荐正式产物位置：

  • outputs/freshrss/rerun/<run-id>/digest/public_digest.md
  • outputs/freshrss/rerun/<run-id>/digest/internal_review_digest.md
  • outputs/freshrss/rerun/<run-id>/digest/combined.json

这样可以保证：

  • 一次 run 的所有输入、输出、摘要结果和日报成稿都收在同一目录下
  • 后续 Hugo 发布与 chat 回传基于同一组正式产物，而不是临时文件
  • 便于回溯、复盘和后续自动化收口

4. 一次生成两份 digest 的生成模式

推荐把：

  • public digest
  • internal review digest

改为在 OpenClaw 侧 一次调用同时生成两份。

推荐输入：

  • PUBLIC_DIGEST_INPUT → digest-brief.json
  • INTERNAL_REVIEW_INPUT → openclaw-delivery-payload.json

推荐输出：

{
  "public_digest_markdown": "...",
  "internal_review_digest_markdown": "..."
}

这样可以减少重复 prompt / 调用开销，同时保留 public / internal 两种视图的边界。

5. internal review digest 风格收敛

internal review digest 经过一轮人工验证后，收敛成以下规则：

固定结构：

  1. 今日候选概况
  2. 已入选重点
  3. 待你确认
  4. 建议沉淀到 IMA
  5. 原始候选清单

表达规则：

  • 不显示 rank
  • 不显示英文 machine state
  • 使用中文状态：
    • keep → 已入选
    • review → 待确认
    • drop → 暂不纳入

内容规则：

  • 已入选重点

    • 标题 + 来源
    • 状态
    • 较完整的一段摘要
    • 一段判断（解释为什么值得入选，以及它在今天 digest 中承担什么角色）

  • 待你确认

    • 标题 + 来源
    • 状态
    • 较完整的一段摘要
    • 原因
    • 建议

  • 原始候选清单

    • 也用中文状态，而不是 decision=keep/review

目标：

  • 保留 internal review digest 作为“给人看的审阅稿”的属性
  • 避免它沦为 payload 的原样转写或机器中间态展示

6. public digest 风格收敛

public digest 当前推荐结构：

  1. 今日概览
  2. 今日重点
  3. 趋势观察
  4. 延伸阅读
  5. 信息来源

表达规则：

  • 不暴露 internal workflow 词汇
  • 不写 待确认 / 建议沉淀到 IMA / keep/review/drop / selection_decision
  • 保持适合 Hugo 公开浏览的表达方式

内容规则：

  • 每个 今日重点 条目除了摘要和 highlights 外，增加一句编辑性总结
  • 推荐形式：
    • 这篇内容更值得关注的原因在于……

目标：

  • 保证 public digest 不只是“摘要列表”
  • 而是一份带有编辑性提炼的公开日报

实测结果

基于真实 run：

  • run 目录：outputs/freshrss/rerun/20260401-074614

1. public 输入压缩效果

  • 完整 payload：8701 字符
  • digest-brief.json：3080 字符

压缩比例：

  • 减少约 64.6%

按中位 token 粗估：

  • 完整 payload：约 3955 tokens
  • public brief：约 1400 tokens

public 输入侧单次大约减少：

  • 约 2500 tokens

2. 一次生成两份的总成本估算

基于真实输入输出的中位估算：

  • 旧方案（两次生成）：约 10328 tokens
  • 新方案（一次生成两份）：约 7734 tokens

节省：

  • 约 2594 tokens
  • 约 25%

说明：

  • 第一步 public 输入瘦身带来的是“输入量级下降”
  • 第二步一次生成两份带来的是“调用层重复开销下降”
  • 两者叠加后，已经形成比较明显的成本优化效果

当前默认口径

public digest

  • 输入：digest-brief.json
  • 风格：公开浏览稿
  • 每个重点项包含：
    • 摘要
    • 关键信号
    • 一句编辑性总结

internal review digest

  • 输入：完整 payload
  • 风格：内部审阅稿
  • 每个重点项包含：
    • 更完整摘要
    • 判断
  • 每个待确认项包含：
    • 更完整摘要
    • 原因
    • 建议

生成方式

  • 优先采用 一次调用同时生成两份

当前阶段结论

本轮优化已经形成一个可用版本：

  • reader 新增 public-only 轻量输入视图
  • public / internal 边界清楚
  • internal 风格和 public 风格都收敛到了可接受版本
  • token 成本下降有明确实测支撑
  • skill 文档与流程规范已经同步更新

当前更适合的策略不是继续抽象设计，而是：

  • 按这套新流程再跑几次真实日报
  • 观察稳定性、质量波动和实际使用感受

后续可选方向

1. internal 输入进一步轻量化

潜在方向：

  • 新增一个 internal 专用的轻量视图
  • 但需要谨慎，避免削弱 internal review 的判断价值

2. digest 阶段模型分层

潜在方向：

  • reader 上游继续用便宜模型做抽取和结构化
  • OpenClaw digest 阶段单独切到更便宜或更合适的模型

3. 自动化执行收口

潜在方向：

  • 把“一次生成两份”的逻辑进一步标准化
  • 更顺滑地接 Hugo 发布与聊天回传
  • 让 reader → OpenClaw → Hugo / chat 的路径更接近真正的稳定生产流程
Reference in New Issue View Git Blame Copy Permalink