AtomTopicClaw / Topic Intelligence Delegate System

nanobot as runtime kernel · delegate layer by design

0. 项目概述

项目名称

AtomTopicClaw

英文可定义为：
AtomTopicClaw: A Personal Topic Intelligence Delegate for Frontier Research & Industry Tracking

一句话定义

AtomTopicClaw 是一个围绕用户长期关注 topic 持续运行的个人情报代理系统。
它以 nanobot 作为 runtime kernel，通过飞书与用户交互，周期性或按需从学术、开源、产业与社区等多源信息中采集候选信号，完成筛选、去重、归因、分析、趋势提炼与长期追踪，并将结果沉淀为可持续积累的 Markdown 情报产品与知识对象。

核心目标

AtomTopicClaw 的目标不是“自动搜资料并总结”，而是构建一个 topic intelligence production system：

替用户持续发现重要前沿信号
替用户完成初步解释与结构化判断
在时间维度上长期追踪同一 topic 的演化
将碎片信息沉淀成可复用的个人知识资产
在可控边界内对自身工作流提出优化提案

1. 背景与问题定义

1.1 用户痛点

当前前沿信息获取与理解存在几个核心问题：

信息源高度分散
论文、会议、实验室主页、GitHub、公司 blog、专业 newsletter、社区讨论分布在不同平台，人工持续跟踪成本很高。
真正重要的信号密度很低
大量信息只是转述、营销包装、情绪化讨论或无实质技术增量的重复报道，高价值内容容易被淹没。
缺乏从“信息”到“判断”的中间层
即便用户看到了原始内容，仍然需要自己回答：
- 这条信息是否真有价值
- 它到底在解决什么问题
- 它比过去推进了什么
- 它属于长期主线还是短期噪音
- 它是否值得继续追踪
缺乏长期上下文
大多数前沿追踪都停留在一次次临时搜索。
用户每天看到零散更新，却难以形成“这个领域过去几周到底在怎么变化”的连续判断。
用户注意力有限
用户有大量其他事务，不可能持续主动做前沿扫描、信源整理、增量归纳与长期 watchlist 管理。

1.2 本系统要解决的问题

AtomTopicClaw 希望把“临时搜索 + 零散收藏”升级为一个 围绕 topic 持续积累、持续演化、持续产出的情报流程。

系统最终输出的不应是信息堆砌，而是：

高价值增量信号
一手与二手信息的区分
关键变化的上下文
趋势与阶段判断
未解决问题与后续观察建议
可沉淀为个人知识资产的结构化结果

2. 产品定位

2.1 产品定位

一个面向个人研究者、技术学习者与前沿观察者的 轻量级 topic delegate。
它不是通用聊天助手，也不是泛资讯聚合器，而是一个围绕特定主题持续工作的个人情报代理。

2.2 目标用户

适合以下用户：

长期关注若干技术方向的学生 / 研究者
需要理解行业动向的工程师 / 创业者
对具身智能、机器人、控制、脑机接口、AI 工程、多智能体等方向有长期兴趣的人
想建立“个人技术前沿雷达”和“topic knowledge pipeline”的用户

2.3 典型使用场景

例如：

每天在飞书收到一份具身智能 / 机器人行业前沿与学术前沿简报
每周收到一份某一 topic 的趋势综合分析
长期跟踪某些会议、实验室、作者、repo、公司研究 blog 的动向
追踪某个 topic 过去 30 天的变化主线，而不是只看当天新消息
记录用户临时抛出的“以后帮我盯这个方向”的 topic，并加入后续 watchlist
让系统对自身报告质量与 topic 追踪逻辑提出改进提案，但不直接越权修改高风险配置

3. 产品目标与非目标

3.1 产品目标

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

每个 topic 都是一个独立的观察对象，拥有自己的边界、问题图谱、信源策略、输出频率与长期追踪状态。

G2. 提供高信噪比的增量产出

系统只输出“值得进入用户注意力”的内容，而不是泛化罗列。

G3. 提供解释与判断，而不是仅仅摘要

输出需要尽量回答：

它在解决什么问题
它属于哪条更大的主线
它和已有进展相比新在哪里
它是结构性变化还是局部更新
它是否值得继续投入注意力

G4. 支持长期演化视角

系统应具备 topic trajectory tracking 能力，能够识别：

某条主线是否持续升温
某类问题是否反复出现
某个团队 / 公司 / 实验室是否形成连续推进
某种叙事是否只是 hype

G5. 生成高可读性的知识产品

系统不仅生成聊天回复，还应沉淀：

日报 / 周报
分析卡片
watchlist 更新
topic dossier
阅读队列
长期趋势总结

G6. 作为 agentic AI 学习项目具备“可观察性”

项目本身也应帮助用户学习 agent engineering，包括：

runtime loop 是如何运行的
memory 在何时读写
skills 怎样被调用
topic intelligence layer 如何建立
delegate 边界如何设计

3.2 非目标

本阶段不做以下事情：

不做通用型万能私人助理
不做实时高频交易式或秒级推送系统
不做全自动论文精读器与结论裁判器
不做自动对外发文、发消息、发邮件的高权限闭环 agent
不做自由修改 runtime / 凭证 / 系统配置的自进化系统
不替代用户做最终技术判断，只提供高质量筛选、结构化解释与追踪辅助

4. 核心产品理念

4.1 从“关键词搜索”转向“Topic Object”

系统不应把 topic 视为关键词集合，而应视为一个 持续演化的观察对象。
每个 topic 至少包含：

Topic 名称
核心定义与边界
关键词 / 同义词 / 相关术语
排除词
关注问题类型
关注实体（作者 / 实验室 / 公司 / repo / 产品）
输出偏好（学术 / 工程 / 产业 / 综合）
观察窗口（日更 / 周更 / 深挖）
长期关注问题
当前阶段假设

示例

Topic: Robotics & Embodied AI

Keywords: embodied ai, manipulation, visuomotor policy, humanoid, dexterous manipulation, whole-body control, sim2real
Exclusions: generic AI news, funding-only news, pure marketing narratives
Preferred Sources: arXiv, conference proceedings, GitHub, lab pages, company research blogs
Focus Questions:
- 最近哪些瓶颈被持续触碰？
- 有无从 paper 向工程化迁移的信号？
- 哪些公司 / 团队的叙事在变强，哪些仅停留在概念层？
- 学术与产业的主线是否在对齐？

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

系统产物不应只是“这篇内容讲了什么”，而应尽量靠近：

哪些是真正值得纳入注意力的信号
它们之间有什么关系
当前 topic 的主线是什么
当前最大的不确定性和未解决问题是什么
接下来应该继续盯谁、盯什么、为什么

4.3 从“短时记忆”转向“知识资产沉淀”

系统不是为了当下回复而已。
它应把有效信息沉淀为：

daily log
durable memory
topic dossier
signal cards
entity watchlist
trajectory notes
evolution proposals

4.4 从“会做事”转向“在边界内自治”

AtomTopicClaw 的自治必须受控：

可以自动采集、分析、沉淀、生成报告
可以对自身工作流提出优化建议
不能直接修改高风险配置
不能直接扩权
不能在未经批准时执行高影响外部动作

5. 信息源设计

系统采用多源分层采集，而不是简单网页抓取。

5.1 一级源：原始研究信号

用于捕捉学术与技术前沿：

arXiv
顶级会议官网 / proceedings
OpenAlex / Semantic Scholar
实验室主页 / 作者主页
project page / benchmark page

主要回答：

最近有哪些新工作 / 新问题 / 新范式
哪些团队在持续推进
哪些问题开始形成热点

5.2 二级源：工程与开源信号

用于识别实现与复现层面的真实进展：

GitHub repo 更新
release note
官方 demo 页面
技术博客
benchmark leaderboard / toolkit 更新

主要回答：

哪些工作开始出现可用实现
哪些方向开始形成生态
哪些项目值得加入长期 watchlist

5.3 三级源：产业与产品信号

用于连接研究与落地：

公司 research blog
公司技术发布
startup 技术叙事
行业媒体中的技术更新
产品发布中的技术线索

主要回答：

哪些能力正在走向产品化
哪些叙事只是包装，哪些有技术实质
哪些方向正在形成产业孵化势能

5.4 四级源：社区与讨论信号

用于感知争议、共识、噪音与升温：

Hacker News
Reddit 特定社区
专业 newsletter
播客 / 访谈
专家社交媒体列表

主要回答：

社区在讨论什么
哪些叙事在快速升温
哪些信号虽然不成熟，但值得设为观察项

5.5 信源分层原则

系统需要区分：

一手源 vs 二手源
事实更新 vs 观点解读
技术增量 vs 舆论增量
持续主线 vs 短期热点

6. 系统能力定义

6.1 核心能力

C1. Topic 建模与管理

创建、修改、删除 topic object，并维护其边界、问题图谱、观察策略与输出设置。

C2. 多源采集

按 topic 从多个层级的信息源获取候选内容。

C3. 内容标准化

将不同来源的内容统一为标准对象，保留元数据、来源层级、时间戳、原始摘要与实体信号。

C4. 去重与归并

识别：

同一工作的多处转载
同一事件的多源报道
同一主题下的相似信号
同一实体的连续更新

C5. 相关性筛选与排序

基于 topic 匹配、技术密度、来源可信度、连续性和 novelty 进行优先级排序。

C6. 单条分析卡片生成

对入选条目生成结构化分析卡片，而不是表层摘要。

C7. 趋势聚合与主线提炼

将离散更新提炼为：

当前主线
升温方向
未解决瓶颈
关键争议
值得继续追踪的实体

C8. 长期追踪

记录 topic 在时间维度上的变化轨迹，支持“过去 7 天 / 30 天 / 一个季度”的连续视角。

C9. 知识沉淀

将有价值内容写入：

topic dossiers
signal cards
entity watchlists
reports
durable memory

C10. 飞书交互

通过飞书进行：

日常对话
即时提问
指定 topic 深挖
手动收藏
人工反馈
审批高风险改动

C11. 有限自我改进提案

系统可以基于失败案例、报告质量与用户反馈生成改进 proposal，但默认只写 proposal，不直接 apply 高风险变更。

7. 系统架构

7.1 总体架构

系统采用 nanobot runtime kernel + custom delegate layer 架构。

其核心思想是：

nanobot 负责 runtime、消息循环、工具执行、workspace、memory、heartbeat / cron
AtomTopicClaw 在其上补出 topic intelligence layer
飞书作为主要交互壳
Markdown / state / knowledge files 作为知识沉淀层
通过审批机制约束高风险动作

7.2 架构原则

先最小化，再扩展
先 topic intelligence，再泛化为助手
先私有单用户，再考虑多人或更复杂协作
先提案式自我改进，再考虑自动应用
先文件化知识与状态，再决定是否引入数据库

7.3 核心模块

1) Feishu Interaction Layer

负责：

接收用户消息
发送摘要、报告、提案
承接审批与反馈

2) Scheduler / Heartbeat

负责：

日更 / 周更任务触发
watchlist 巡检
周期性 topic review
反思任务唤醒

3) Topic Manager

负责 topic object 的配置与状态：

profile
source preferences
output cadence
watchlist
current hypotheses

4) Source Collectors

按源类型分 adapter：

API
RSS / structured feed
structured pages
browser / scrape fallback

5) Normalizer

统一不同来源的对象结构，并补充：

source tier
evidence type
entity extraction
candidate claims
topic links

6) Filter & Ranker

计算候选项优先级，控制进入 LLM 深度分析的条目数量。

7) Analysis Engine

完成：

信息抽取
单条分析卡片
跨条目趋势归纳
读者导向报告撰写

8) Knowledge / Memory Store

保存：

daily logs
durable memory
processed items
topic dossiers
signal cards
entity watchlists
reports
evolution proposals

9) Report Generator

按模板输出：

daily brief
weekly synthesis
topic digest
reading queue
watchlist changes

10) Approval Gate

控制：

高风险改动提案
自我改进 proposal 的 apply
外部高影响动作

8. 数据流设计

8.1 定时研究任务流程

调度器触发某个 topic run
加载 topic profile 与最近状态
拉取各 source collector 候选项
清洗、标准化、去重
计算相关性与优先级
选择 Top-N 进入分析
生成 signal cards
聚合为本期 brief / synthesis
写入 reports 与 knowledge store
将摘要推送到飞书
更新 topic trajectory 与 watchlist 状态

8.2 用户驱动对话流程

用户在飞书发起提问或临时指令
系统识别是：
- 普通问答
- topic 查询
- 深挖任务
- 收藏 / 记忆指令
- 审批指令
若涉及 topic intelligence，则读取相关 dossier / recent reports / watchlist
输出回答
必要时更新 daily log 或 durable memory

8.3 知识沉淀流程

识别一条内容是否值得长期保留
判断其应进入：
- daily log
- durable memory
- topic dossier
- entity watchlist
- future reading queue
写入对应目录
为后续报告与检索提供引用基础

8.4 反思与提案流程

周期性读取本周报告、失败案例、用户纠正
识别工作流缺口
生成 evolution proposal
发飞书请求审批
仅在批准后修改低风险文件

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

{
  "item_id": "source_hash",
  "topic_id": "robotics_embodied_ai",
  "source_tier": "primary_research",
  "source_type": "paper",
  "source_name": "arXiv",
  "title": "Example Title",
  "url": "https://...",
  "published_at": "2026-03-24T08:00:00Z",
  "authors": ["A", "B"],
  "summary_raw": "...",
  "content_raw": "...",
  "entities": {
    "people": ["A", "B"],
    "orgs": ["Lab X"],
    "artifacts": ["Dataset Y", "Repo Z"]
  },
  "signals": {
    "keywords": ["manipulation", "sim2real"],
    "problem_types": ["dexterous manipulation"],
    "claim_candidates": ["improved transfer", "new benchmark result"]
  },
  "evidence": {
    "first_hand": true,
    "implementation_available": false,
    "quantitative_results_present": true
  }
}