中文 ENG

行业前沿顾问 Bot / Topic Intelligence System __openClaw in Practice #1v2

Author Lens

Start with a short note that points to where this idea came from before the main argument begins.

行业前沿顾问 Bot / Topic Intelligence System

openClaw in Practice v2

0. 项目概述

项目名称

行业前沿顾问 Bot 英文可定义为：Topic Intelligence System for Frontier Research & Industry Tracking

一句话定义

这是一个围绕用户指定 topic 周期性运行的前沿情报系统。它自动从学术、开源、产业与社区等多源信息中获取候选内容，完成筛选、去重、归因、摘要、关联分析与趋势提炼，最终生成高可读性的 Markdown 快报，并通过邮箱或消息机器人分发给用户。

核心目标

不是单纯“搜最新内容并总结”，而是输出一种高信噪比、具备上下文和判断力的前沿快报，帮助用户持续理解某个领域正在发生什么、为什么重要、目前推进到哪里、以及接下来该追什么。

1. 背景与问题定义

1.1 用户痛点

当前前沿信息获取存在几个典型问题：

  1. 信息源分散 论文、会议、GitHub、实验室主页、技术博客、社交媒体分布在多个平台，手工跟踪成本高。

  2. 信息噪声过大 许多更新只是营销包装、重复转载或低价值讨论，真正值得看的技术信号很容易被淹没。

  3. 缺乏结构化分析 即便获取到原始信息，用户仍需要自行判断：

    • 这条信息是否真的重要
    • 它解决了什么问题
    • 它比过去的方法推进了什么
    • 它对研究、工程或行业落地意味着什么

  4. 缺乏持续上下文 每天看到的是零散更新，难以形成对一个 topic 的长期理解，容易停留在“看过很多，但没形成判断”。

1.2 本系统要解决的问题

系统希望将“前沿跟踪”从一次次临时搜索，变成一个围绕 topic 持续积累和演化的情报流程。 最终输出的不是信息堆砌，而是：

  • 高价值更新
  • 背景与上下文
  • 关键突破与限制
  • 趋势判断
  • 后续追踪建议

2. 产品定位

2.1 产品定位

一个面向个人研究者、技术学习者和前沿观察者的轻量级情报代理系统。

2.2 目标用户

适合以下用户：

  • 持续关注某些技术方向的学生/研究者
  • 需要跟踪行业动态的工程师
  • 对具身智能、机器人、控制、AI 工程、脑机接口等方向有长期兴趣的人
  • 想建立“个人技术前沿雷达”的用户

2.3 典型使用场景

例如：

  • 每天早晨收到一份机器人与具身智能快报
  • 每周收到一份脑机接口方向的学术趋势总结
  • 定期追踪 ICRA / IROS / RSS / CoRL 等相关会议中的新工作
  • 监控某些实验室、作者、GitHub repo、公司 research blog 的更新
  • 将多个来源的进展合并成一份可快速阅读的 Markdown briefing

3. 产品目标与非目标

3.1 产品目标

本系统的核心目标包括：

G1. 构建 topic 驱动的情报跟踪能力

每个用户可定义若干 topic，系统按 topic 独立采集、分析和输出。

G2. 提供高信噪比的增量快报

只输出“值得看”的内容，避免泛滥摘要和无差别罗列。

G3. 提供分析而非仅仅摘要

输出需要回答：

  • 解决了什么问题
  • 相比已有工作新在哪里
  • 有什么意义
  • 暴露了什么新问题
  • 是否值得持续追踪

G4. 支持长期演化视角

系统应识别持续演化中的研究方向、团队和问题，而不是每天重新开始。

G5. 输出高可读性的阅读产品

最终产出应是适合快速扫读又可深入阅读的 Markdown 快报，可投递到邮箱或消息机器人。

3.2 非目标

本阶段不做以下事情：

  • 不做自动论文全文精读与精确复现
  • 不做全自动科研结论判断器
  • 不做实时高频推送系统
  • 不做闭环执行 agent，不进行外部写操作或危险权限操作
  • 不替代用户的深入阅读与技术判断，只做高质量筛选与辅助分析

4. 核心产品理念

4.1 从“搜索”转向“Topic Profile”

系统不是简单搜关键词，而是围绕一个 Topic Profile 工作。 每个 topic 需要有自己的画像，至少包括：

  • Topic 名称
  • 核心关键词
  • 同义词/相关术语
  • 排除词
  • 优先数据源
  • 关注作者/实验室/公司/项目
  • 关注问题类型
  • 输出偏好（偏学术 / 偏工程 / 偏产业）

示例

Topic: Robotics & Embodied AI

  • Keywords: embodied ai, visuomotor policy, manipulation, whole-body control, sim2real

  • Exclusions: marketing, funding only, generic AI news

  • Preferred Sources: arXiv, conference proceedings, GitHub, lab pages

  • Focus Questions:

    • 最近解决了什么瓶颈？
    • 是否有新范式？
    • 哪些方向开始从 paper 走向工程化？

4.2 从“摘要器”转向“情报快报系统”

系统输出不应该只是“这篇论文说了什么”，而应该尽量接近：

  • 哪些是真正的重要信号
  • 这些信号之间如何关联
  • 当前主线是什么
  • 还存在哪些缺口
  • 接下来值得盯什么

5. 信息源设计

为了提高质量与稳定性，建议采用多源分层采集，而不是只抓网页。

5.1 一级源：学术主源

用于捕捉研究前沿：

  • arXiv
  • OpenAlex / Semantic Scholar
  • 顶级会议官网或 proceedings
  • 实验室主页 / 作者主页
  • Google Scholar 相关条目页

主要回答：

  • 最近有哪些新论文/新方法
  • 哪些团队在推进哪些方向
  • 哪些问题正在成为热点

5.2 二级源：工程与开源实现

用于识别可复现和可落地信号：

  • GitHub repo 更新
  • release note
  • 官方 project page
  • benchmark 页面
  • 开源 demo / 技术 blog

主要回答：

  • 哪些工作已经有工程实现
  • 哪些方向开始有复现和生态积累
  • 哪些项目值得继续跟踪

5.3 三级源：产业动态

用于连接研究与落地：

  • 公司 research blog
  • 新产品发布中的技术信号
  • 技术型 startup 发布
  • 行业媒体中的技术更新

主要回答：

  • 哪些技术开始走向产业
  • 学术突破是否正在转化为产品能力
  • 哪些方向具备明显落地势头

5.4 四级源：社区与讨论

用于感知争议、共识与升温话题：

  • Hacker News
  • Reddit 特定板块
  • 专业 newsletter
  • 专家社交媒体列表
  • 播客和技术访谈

主要回答：

  • 社区正在讨论什么
  • 哪些方向开始形成共识或争议
  • 哪些信息虽然未成文论文，但值得警觉

6. 系统能力定义

6.1 核心能力

系统应具备以下能力：

C1. Topic 管理

创建、修改、删除 topic 画像与监控规则。

C2. 多源采集

按 topic 从不同信息源获取候选内容。

C3. 内容标准化

将不同来源内容统一转成可处理的结构化对象。

C4. 去重与归并

识别重复内容、同一事件的多次转载、同一工作的多处提及。

C5. 相关性筛选

根据 topic 相关性、技术密度、来源可信度进行筛选。

C6. 分析与总结

对入选内容做技术分析、背景补充、价值判断、局限识别。

C7. 趋势提炼

把多个离散更新归纳成几个更高层的变化主线。

C8. 报告生成

按预定义模板输出 Markdown 快报。

C9. 分发通知

将快报投递到：

  • 邮箱
  • QQ 机器人
  • 其他消息通道

C10. 历史记忆

记录已处理内容、趋势簇、重点关注对象，支持后续增量分析。

7. 系统架构

7.1 总体架构

系统采用周期性批处理架构，而非复杂常驻 agent。

原因：

  • 更可控
  • 更稳定
  • 成本更低
  • 易于权限隔离
  • 易于审计与回放

7.2 核心模块

1) Scheduler

负责按 cron 或其他调度方式定时触发任务。

2) Topic Manager

维护 topic 配置，包括：

  • 关键词
  • 源优先级
  • 过滤条件
  • 输出频率
  • 分发方式

3) Source Collectors

针对不同源的适配器，优先级：

  1. API
  2. RSS / structured feed
  3. structured page
  4. browser scrape

4) Normalizer

将不同源条目统一成标准结构，如：

  • id
  • source
  • title
  • url
  • published_at
  • authors
  • abstract/snippet
  • raw_content
  • metadata

5) Filter & Ranker

对候选项进行打分与筛选。

6) Analysis Engine

调用 LLM 完成：

  • 信息抽取
  • 摘要
  • 技术意义分析
  • 趋势归纳
  • 快报撰写

7) Memory Store

保存：

  • 已处理条目
  • 历史快报
  • 趋势簇
  • watchlist
  • topic 状态

8) Report Generator

按模板输出 Markdown / HTML 报告。

9) Delivery Layer

负责邮件、QQ 机器人等通道投递。

8. 数据流设计

8.1 单次任务执行流程

  1. 定时器触发 topic task
  2. 加载该 topic 的 profile
  3. 调用各 source collector 获取候选项
  4. 对候选项做清洗、标准化、去重
  5. 执行相关性判断和优先级排序
  6. 选择 Top-N 条目送入分析引擎
  7. 输出单条分析卡片
  8. 聚合为本期 briefing
  9. 生成 Markdown 报告
  10. 写入本地 reports 目录
  11. 同步投递至邮件/机器人
  12. 更新 memory store

8.2 标准化候选对象建议结构

{
  "item_id": "source_hash",
  "topic": "robotics_embodied_ai",
  "source_type": "paper",
  "source_name": "arXiv",
  "title": "Example Title",
  "url": "https://...",
  "published_at": "2026-03-21T08:00:00Z",
  "authors": ["A", "B"],
  "summary_raw": "...",
  "content_raw": "...",
  "signals": {
    "keywords": ["manipulation", "sim2real"],
    "entities": ["lab_x", "dataset_y"]
  }
}

9. 评分与筛选机制

9.1 为什么要做 Ranker

不是每条信息都值得进入报告。 系统需要先判断“值不值得分析”，再决定“如何分析”。

9.2 候选打分维度

建议至少包含以下维度：

  • Topic Relevance：与 topic 的相关性
  • Source Authority：来源权威性
  • Novelty：是否相对近期内容具有新意
  • Technical Depth：是否有真实技术内容
  • Engineering Value：是否有实现或落地意义
  • Trend Continuity：是否属于持续主线
  • Redundancy Penalty：是否高度重复
  • Hype Penalty：是否营销化、噪声大

9.3 输出策略

例如：

  • 每日版：仅保留 3~8 条最高价值信号
  • 周报版：按主题聚合，控制在 5~12 个重点项
  • 对明显低质量内容直接丢弃，不进报告

10. 分析引擎设计

10.1 单条分析目标

系统对每一条候选内容，不应只做表面摘要，而应产出一个分析卡片。

10.2 单条分析卡片模板

建议固定结构：

  • 标题
  • 来源与链接
  • 这项工作在解决什么问题
  • 核心方法或思路是什么
  • 相比已有工作新在哪里
  • 结果或证据是什么
  • 限制与前提是什么
  • 对工程/行业的潜在意义是什么
  • 它提出了什么新问题
  • 是否值得持续跟踪

10.3 趋势层分析

在单条分析之上，再做一层聚合：

  • 最近 7 天主要主线是什么
  • 哪些方向正在升温
  • 哪些突破是“范式变化”
  • 哪些只是局部改良
  • 目前尚未解决的瓶颈是什么

11. 记忆层设计

11.1 为什么需要 Memory

如果没有记忆层，系统每天都像第一次看这个领域，无法输出增量洞察。

11.2 记忆层最小化设计

即便整体任务仍是 stateless batch，也建议保留轻量记忆：

  • 已处理 item hash
  • 最近 30 天已出现的重要条目
  • watchlist 中的作者 / 实验室 / repo
  • topic 下的趋势簇
  • 历史报告索引

11.3 记忆层作用

使系统能够输出更有价值的判断：

  • 这是该团队近期的连续推进
  • 这是某条主线的后续演进
  • 与上周相比，焦点正在从 A 转向 B
  • 这是之前论文的开源实现或工程化版本

12. 输出产品设计

12.1 输出原则

快报应同时满足：

  • 可快速扫读
  • 信息密度高
  • 有背景与判断
  • 易归档与检索
  • 便于二次转发或整理

12.2 输出层级

建议做三层结构：

层 1：TL;DR

适合 1~3 分钟扫读，快速知道今天最重要的变化。

层 2：Top Signals

列出 3~8 条高价值进展，每条控制在短段落内。

层 3：Trend Synthesis

总结主线、变化、未解决问题和后续关注建议。

13. Markdown 快报模板

# Frontier Briefing | Robotics & Embodied AI
Date: 2026-03-21
Topic: robotics_embodied_ai

## TL;DR
本期最值得关注的变化是：
1. xxx
2. xxx
3. xxx

这些变化共同说明：
xxx

## Top Signals

### 1. [标题]
- 来源：arXiv / IROS / GitHub
- 链接：...
- 在解决什么问题：
- 核心思路：
- 新意在哪里：
- 为什么值得关注：
- 限制或风险：
- 我的判断：高优先级 / 中优先级 / 观察

### 2. [标题]
...

## Trend Synthesis
- 最近主线：
- 正在升温的方向：
- 仍未解决的瓶颈：
- 值得继续追踪的作者 / 团队 / 项目：

## Reading Queue
- 必读论文：
- 值得追踪的 repo：
- 建议下次重点观察的问题：

14. 交付通道设计

14.1 邮箱

适合作为主分发通道。

优点：

  • 格式完整
  • 易归档
  • 适合长内容
  • 可附带 Markdown/HTML 双格式

14.2 QQ 机器人

适合作为轻提醒或精简版投递。

建议发送：

  • 标题
  • TL;DR
  • 报告链接或摘要片段

14.3 通道策略建议

采用“双层分发”：

  • QQ 机器人：发摘要提醒
  • 邮箱：发完整版快报

这样既不会让消息通道过载，也保留完整阅读体验。

15. 工程与安全约束

15.1 运行方式

采用容器隔离运行：

  • 非 root 用户
  • 最小权限原则
  • 配置目录只读挂载
  • 报告目录单独可写
  • 不允许访问非必要路径

15.2 文件系统设计

建议继续使用独立工作目录：

/opt/openclaw/topic_intelligence/
├── docker-compose.yml
├── config/
│   ├── topics/
│   │   ├── robotics.yaml
│   │   ├── bci.yaml
│   │   └── ai_engineering.yaml
│   ├── system_prompt.md
│   └── source_registry.yaml
├── workspace/
│   ├── reports/
│   ├── cache/
│   ├── state/
│   └── logs/

15.3 权限原则

  • config/ 只读
  • reports/ 读写
  • state/ 读写
  • 禁止访问宿主机其他敏感目录
  • 网络访问仅限白名单源或代理层

16. 风险与工程考量

16.1 反爬与数据稳定性

风险：

  • 直接抓网页可能触发 WAF / Cloudflare
  • 页面结构常变导致 scraper 脆弱

策略：

  • 优先用 API / RSS / structured feed
  • 对 scraper 做 source adapter 隔离
  • 对失败源设置降级策略

16.2 Token 成本过高

风险：

  • 页面抓取内容冗长
  • 大量低质量候选项浪费 LLM 配额

策略：

  • 先用 lightweight filter 做预筛
  • 限制每源抓取深度
  • 只把 Top-N 项送入 LLM
  • 对长页面做截断与提取

16.3 输出同质化

风险：

  • 报告变成千篇一律的摘要拼接

策略：

  • 增加趋势层分析
  • 引入历史上下文
  • 增加“值得跟踪/不值得跟踪”的判断字段

16.4 信息可靠性问题

风险：

  • 某些源存在夸大宣传或二次误传

策略：

  • 增加 source trust 权重
  • 尽量回到一手来源
  • 对关键结论标注“依据不足”或“仍待验证”

16.5 任务膨胀

风险：

  • topic 过多导致系统退化成泛资讯聚合器

策略：

  • 初期限制 topic 数量
  • 每个 topic 控制数据源范围
  • 明确报告周期和最大候选量

17. MVP 设计

17.1 MVP 目标

先验证一件事： 系统生成的快报，用户是否真的愿意持续阅读。

17.2 MVP 范围

建议第一阶段只做：

  • 1~2 个 topic
  • 2~3 类数据源
  • 每日或每周一次运行
  • Markdown 报告输出
  • 邮箱投递

17.3 MVP 推荐 topic

适合从以下 topic 开始：

  1. Robotics / Embodied AI
  2. BCI / Neurotechnology
  3. AI Engineering / Multi-Agent Systems

17.4 MVP 推荐数据源

优先：

  • arXiv
  • GitHub
  • 指定实验室/博客
  • 顶会页面

先不急着接入太多社交源。

17.5 MVP 成功标准

  • 报告平均阅读率高
  • 用户觉得信息密度明显优于手工搜集
  • 报告中的多数条目被认为“值得看”
  • 每期不会出现明显刷屏式重复

18. 迭代路线

Phase 1：最小可用版

目标：

  • 跑通 topic → source → filter → summarize → report → delivery

产出：

  • 每日/每周 Markdown 快报
  • 邮箱投递

Phase 2：分析增强版

新增：

  • 去重
  • 历史记忆
  • 趋势归并
  • watchlist
  • 更强的 report template

目标：

  • 从“摘要器”升级到“顾问型快报器”

Phase 3：个性化研究助手版

新增：

  • 阅读优先级建议
  • 值得精读论文推荐
  • 针对用户兴趣图谱做追踪建议
  • topic 间关联发现

目标：

  • 从“前沿快报”升级到“个人研究情报基础设施”

19. 成功指标

19.1 产品指标

  • 每期报告的平均阅读完成率
  • 用户主观满意度
  • 条目点击率
  • 被收藏/归档次数
  • 报告中“真正有价值条目”的占比

19.2 质量指标

  • 重复信息比例
  • 低价值条目比例
  • 报告平均长度
  • 单次运行 token 消耗
  • 平均每期被保留的高优先级信号数量

19.3 系统指标

  • source 成功抓取率
  • 单次任务耗时
  • 失败重试率
  • 邮件/机器人投递成功率

20. 开放问题

当前仍需要进一步明确的问题：

  1. Topic Profile 的配置粒度要细到什么程度
  2. 是按“数据源”还是按“topic”做调度任务
  3. 历史记忆是存数据库还是轻量文件状态
  4. QQ 机器人用作主通道还是提醒通道
  5. 报告频率是每日、隔日还是每周
  6. 是否需要支持“专题深挖版”而不仅是 brief
  7. 是否需要加入“本期最值得精读的 3 篇论文”模块

21. 最终定位总结

这个系统的本质不是“自动搜资料”，而是：

围绕用户长期关注的 topic，持续捕捉真正重要的前沿增量信号，并将其压缩成高可读、高价值、可持续积累的情报快报。

它不是简单的爬虫，也不是普通摘要器。 它更接近一个：

  • 面向个人研究者的前沿雷达
  • 面向技术学习者的趋势归纳器
  • 面向长期成长的个人情报基础设施

如果你愿意，下一条我就直接把这版继续展开成两部分： 1）可执行的目录结构 + 配置文件草案 2）第一版 system prompt 与 report prompt