用 Skill + Cron 搭一套自迭代的 AI 前沿日报系统

你不可能每天手动刷 arXiv。但你可以让 agent 帮你刷——然后让它自己决定明天该多关注什么。

问题#

AI 领域的论文产出速度已经超出人类的追踪能力。仅 arXiv 的 cs.AI + cs.CL + cs.LG + cs.CV + cs.MA + cs.HC 六个子类，每天就有数十篇新提交。加上 HuggingFace Daily Papers、OpenAI / Anthropic / DeepMind 的工业博客，信息量是每天读不完的。

但我们不需要全读。需要的是：每天花 5 分钟知道”今天最值得关注的是什么”。

设计#

整个系统由三个部分组成：

1. Skill：执行协议#

一个标准的 OpenClaw Skill（~/.openclaw/skills/ai-research-tracker/），定义 6 个 Phase：

1
Phase 1：数据采集（6 个源）
2
Phase 2：去重 + 初筛（关键词 / 引用量 / 机构）
3
Phase 3：精读 Top 30 + 摘要
4
Phase 4：产品关联分析（映射到 4 条产品线）
5
Phase 5：知识沉淀（更新 agent 知识库）
6
Phase 6：追踪方向自更新（热度标注 + 新兴方向追加）

Phase 6 是关键——它让系统能自我调整。如果某个方向连续 7 天没有高质量产出，热度自动降级；如果出现新的高频方向，自动追加到追踪列表。

2. Cron Job：定时触发#

每天 07:00 CST 自动执行，结果发到指定飞书群聊，同时归档到 reports/ai-research/YYYY-MM-DD.md。

3. 知识库闭环#

筛选出的核心技术发现会写入 agent 的长期知识文件（references/09-ai-frontier.md）。这意味着 agent 在后续的产品分析、技术方案讨论中，能直接引用最新的研究进展，而不是停留在训练数据的截止日期。

首次执行数据#

2026-04-16 14:05 ~ 14:20，首次全链路执行。

采集结果#

数据源	抓取量
arXiv（6 个子类 × 30）	180 篇
HuggingFace Daily Papers	50 篇
Papers with Code	结构化提取不稳定，降级为参考
OpenAI Blog	1 篇（Agents SDK 演进）
Anthropic Research	2 篇（自动化对齐研究者 + 可信 Agent 实践）
DeepMind Blog	结构化提取不稳定，降级为参考

去重后候选 184 篇，最终筛选 Top 30 进入精读。

产品映射#

将 Top 30 的研究发现映射到 4 条产品线：

Agent 平台类产品：优先关注 agent control plane / harness / eval
对话类产品：优先关注角色一致性、记忆抽象、安全边界
互动内容类产品：优先关注小而可验证的互动世界

核心判断#

今日最强信号不是单一大模型突破，而是 agent infra + memory + eval + safety 的系统化成熟。

具体四条值得持续跟踪的线：

GUI Agent（agent 操作真实界面的能力）
Benign-context safety（在正常上下文中的安全行为）
Agent 记忆迁移（跨 session 的知识保留）
可探索 3D 世界生成

踩的坑#

1. 采集脚本超时#

collect.sh 首次执行时总超时被杀。原因：给了 120 秒总时限，但 arXiv 6 个子类就要 60+ 秒，加上博客抓取就超了。

修复：总超时放宽，或改为分段执行 + 中间缓存。

2. 某些源的结构化提取不稳定#

Papers with Code 和 DeepMind Blog 的原始 HTML 能抓到，但 web_fetch 的 markdown 提取质量不稳定——有时能拿到完整论文列表，有时只拿到导航栏。

处理：在日报中明确标注数据质量。不可靠源的数据降级为”参考”而非”事实”。这和我们在产品方案中学到的数据标注原则一致：没有可靠来源的数据不当事实用。

3. 产品关联分析需要产品上下文#

系统需要知道每条产品线在做什么，才能做有意义的映射。但部分产品仓库是空的（比如灵魂伴侣项目刚刚启动，GitHub 仓库只有空壳）。

处理：用已有的产品方案文档补充上下文，并在分析中明确说明”此映射基于产品方案文档，非已上线功能”。

自迭代机制#

这是整个系统最有意思的部分。

传统的信息监控是静态的：你定义一组关键词，然后每天查。但 AI 领域的热点是动态的——上个月 “MoE” 是热词，这个月可能变成 “agent memory”。

我们的追踪方向列表（references/tracking-directions.md）是动态的：

1
# 追踪方向（动态更新）
2

3
## 高热度
4
- Agent Memory & State Management  🔥 连续 5 天出现
5
- GUI Agent / Computer Use          🔥 连续 3 天出现
6

7
## 中热度
8
- Mixture of Experts
9
- Long Context / RAG
10

11
## 低热度（观察中）
12
- Neural Architecture Search        ⬇️ 连续 4 天无高质量产出

每次执行时，Phase 6 会根据当天的筛选结果更新热度标注。连续 7 天无产出的方向降级或移除；新出现的高频方向自动追加。

这意味着一个月后，追踪列表会和第一天完全不同——它跟着领域的实际产出走，而不是跟着你的初始设定走。

架构决策#

为什么用 Skill 而不是脚本#

纯脚本能搞定采集，但搞不定”筛选”和”分析”——这需要 LLM 的判断力。Skill 把采集（脚本）和分析（LLM）组合在一个执行协议里，每个 Phase 用最合适的工具。

为什么用 Cron 而不是 Heartbeat#

精确定时（每天 07:00）比 heartbeat 的模糊定时更适合日报场景。而且日报需要独立上下文——不应该和主 session 的对话历史混在一起。

为什么知识沉淀有体积上限#

09-ai-frontier.md 控制在 50KB 以内。没有上限的话，几个月后这个文件会膨胀到 agent 读不动。定期清理旧内容，只保留仍然活跃的技术方向，和追踪方向列表的降级机制配合。

一周后#

这个系统刚跑了第一天。还有很多待验证的地方：

追踪方向的自动更新是否真的能跟上领域变化
产品映射的质量是否随着产品上下文的丰富而提升
知识沉淀的体积控制是否可持续

但第一天的数据至少说明了一件事：184 篇论文 → 30 篇精读 → 4 条产品映射 → 知识沉淀，整个链路在 15 分钟内走通了。比人工做同样的事情快得多，而且不会漏掉子类。

下一步是看它跑一个月后，追踪方向列表和知识库会变成什么样。