AI 前沿资讯聚合

路径约定

变量	含义	默认值
`{skill_dir}`	本 Skill 所在目录	（由 OpenClaw 自动解析）
`{work_dir}`	运行时工作目录	`{workspace}/ai-news-data/`

Skill 目录只含通用默认配置、文档和脚本。所有用户特定配置和运行时数据在 {work_dir} 中：

{work_dir}/
├── config/
│   ├── api_keys.env             # API 密钥
│   ├── business-context.md      # 用户业务上下文
│   ├── sources.md               # 自定义信息源
│   └── keywords.md              # 自定义关键词
├── output/YYYY/MM/              # 报告存档
├── logs/                        # 执行日志
├── _rss_cache/                  # RSS 缓存
└── state/
    ├── last_run.json            # 上次执行时间
    ├── preferences.json         # 用户偏好数据
    └── sent_items.json          # 去重记录

使用方式

手动获取：「获取最新 AI 资讯」「获取今天的 AI 资讯」
指定时间范围：「获取最近 3 天的 AI 资讯」（最多 7 天）
定时执行：通过 cron 设置定时任务（如每天早晚各一次），自动执行并推送
增量更新：自动与上次结果去重（URL + 话题级），不会重复推送同一事件
偏好反馈：回复「[3]很有用」「开源类太多了」等，系统自动学习并调整后续报告
深入追踪：对某条资讯要求进一步研究，也会被记录为兴趣信号，后续相关内容会优先展示
配置自审视：每周自动审视关键词和信息源，根据你的业务变化和反馈趋势建议更新，确认后生效

⚡ Token 预算与效率规则（最重要，必须遵守）

本 Skill 运行在隔离子会话中，context 上限 200K tokens，超时 20 分钟。

thinking 中绝不复述已采集内容 — thinking 只记结论（「X 源获取 8 条，Y 源失败」）
不要在 thinking 中逐条审核 — thinking 只做分类决策，不抄原文
工具调用尽量并行 — 步骤 2-3 中独立调用放在同一轮
控制 web_fetch maxChars — 每个源 ≤ 3000 chars
xAI x_search 最多 2 轮调用 — 每轮合并多个 handle/关键词
某步骤耗时超过 5 分钟 → 跳过
URL 必须原样复制，严禁凭记忆拼写 — 写报告时，每条资讯的链接必须从采集阶段的工具返回结果中直接复制，绝不能凭印象或记忆构造 URL。如果找不到原始 URL，宁可标注「链接缺失」也不要编造

核心流程

步骤 0（首次）→ 1 → 1.5 → 1.8 → 2 → 3 → 4 → 5

步骤 0：首次运行配置（仅首次执行）

检查 {work_dir}/config/ 是否存在。已存在 → 跳过此步骤。

0.1 创建目录结构

创建 {work_dir}/ 及子目录：config/、state/、output/、logs/、_rss_cache/。

0.2 生成业务上下文

读取 USER.md 和用户记忆中的业务信息
参考 {skill_dir}/references/business-context-example.md 的格式
生成 {work_dir}/config/business-context.md
向用户展示，询问是否调整

0.3 初始化信息源和关键词

复制 {skill_dir}/references/sources.md → {work_dir}/config/sources.md
复制 {skill_dir}/references/keywords.md → {work_dir}/config/keywords.md
根据用户业务方向，建议增加业务相关的关键词和搜索词
向用户展示，等待确认

0.4 配置 API Keys

复制 {skill_dir}/references/api-keys-example.env → {work_dir}/config/api_keys.env
告知用户：
- xAI API Key（X/Twitter 搜索）— https://console.x.ai/ 获取
- Tavily API Key（搜索引擎）— https://tavily.com/ 注册，每月 1000 次免费
不配 Key 也能正常运行，只是 X/Twitter 和 Tavily 搜索层不可用，其余信息源不受影响
用户提供 Key 后写入；暂不提供则留空

0.5 确认

向用户展示配置摘要，完成后进入步骤 1。

步骤 1：确定时间范围

所有时间统一使用 Asia/Shanghai 时区（标题、覆盖时段、日志文件名）
用户指定时效 → 按指定（最多 7 天）
未指定 → 默认 24 小时
如上次成功执行在默认时效内 → 只取上次执行后的增量
上次执行时间记录在 {work_dir}/state/last_run.json

步骤 1.5：加载 API 密钥

必须先加载 API 密钥：

source {work_dir}/config/api_keys.env

包含 XAI_API_KEY（xAI Grok x_search）和 TAVILY_API_KEY（Tavily 搜索）。

如果文件不存在或 Key 为空 → 跳过搜索层（步骤 2 第 3 层和步骤 3 的 Tavily），不影响其余源。

对于 xAI x_search，exec 中使用 source {work_dir}/config/api_keys.env && curl ...。对于 Tavily MCP，通过 mcporter call tavily.tavily_search 调用（mcporter 已配置 key）。

步骤 1.8：加载用户偏好

读取 {work_dir}/state/preferences.json：

文件不存在或 feedback_log 为空 → 跳过，按默认行为
有效数据 → 加载 source_scores、category_scores、topic_scores、user_directives
调整规则见 {skill_dir}/references/preferences-guide.md

偏好数据影响步骤 4（排序、详略、业务启发）和步骤 3（高价值 topic 扩展搜索）。

步骤 2：拉取信息源

按 3 层优先级拉取，信息源列表见 {work_dir}/config/sources.md：

第 1 层：RSS 源（批量、快速）

{skill_dir}/scripts/fetch_rss.sh {work_dir}/_rss_cache {work_dir}/config/sources.md

按时间范围过滤条目。

第 2 层：web_fetch 源（逐个抓取）

对无 RSS 的信息源，用 web_fetch 抓取首页，提取最新文章标题、链接、摘要。

第 3 层：搜索类源

X/Twitter KOL 监控：

使用 xAI Grok API x_search，调用方式见 {skill_dir}/references/xai-x-search.md
按 allowed_x_handles 分批查询（每批最多 10 人），设置 from_date 为时间范围起点
⚠️ 每次调用耗时 30-60 秒，exec timeout 设至少 90 秒
必须先 source {work_dir}/config/api_keys.env

Tavily 搜索：

mcporter call tavily.tavily_search query="关键词" max_results=5 time_range=week
每月 1000 次免费额度，控制调用量

步骤 3：搜索热点

关键词库见 {work_dir}/config/keywords.md。

第一层：平台热点扫描

Hacker News（API/RSS）、GitHub Trending（web_fetch）、Reddit（web_fetch .json）
提取 AI 相关条目

第二层：关键词深度搜索

用 Tavily MCP 按关键词库检索，时间限定为本次范围
关键词分「业务强相关」和「通用 AI 热点」两组

步骤 4：LLM 筛选与分析（含偏好调整）

对所有收集的内容统一处理：

筛选：

只保留有价值的 AI 相关内容，过滤低质量、与 AI 无关、纯营销
即使源/分类被偏好降级，重大新闻（多源交叉报道）仍正常展示

去重（URL 级 + 话题级，双重检查）：

与 {work_dir}/state/sent_items.json 比对，排除已发送 URL
话题级去重：读取 {work_dir}/output/ 下当天已生成的所有报告，排除同一话题/事件（除非有显著增量）
判断标准：涉及同一产品/公司/事件/人物的同一行为或发布
同一事件的不同报道合并

分类（6 类，二级标题不加数字序号）： 基础研究与前沿探索 / 基础大模型动态 / 技术与产品动态 / 开源生态与开发者动态 / 个人及商业实践 / 观点、趋势与伦理讨论

分析（结合业务上下文和偏好）：

读取 {work_dir}/config/business-context.md，判断每条资讯对用户业务的启发
根据偏好数据调整详略（见 {skill_dir}/references/preferences-guide.md）
同一热点多方观点合并对比
与历史热点的关联（如有）
应用所有 active: true 的 user_directives

排序（结合偏好）： 重大事件 > 业务相关度 > 用户高价值维度 > 时间倒序

详略分级：

完整格式：标题 + 链接 + 来源 + 摘要(1-3句) + 💡 业务启发 → 高价值/中性条目
简报格式：标题 + 链接 + 来源 + 一句话，不加业务启发 → 低价值维度（score < 0.3, total ≥ 3）
简讯格式：仅标题 + 链接，归入末尾「简讯」区 → 极低价值维度（score < 0.2, total ≥ 5）

步骤 5：输出与存档

⚠️ 分段写入（防止 output token 截断）

严禁一次性 write 整篇报告，必须分段：

write 创建文件：报告标题 + 概览 + 前 2 个分类
edit 逐段追加：每次 1-2 个分类，每次 ≤ 2000 token
空分类跳过

控制 thinking 开销

采集阶段（步骤 2-3）直接调用工具，不需大量思考
筛选阶段（步骤 4）适度思考，保持简洁
写入阶段（步骤 5）最小化 thinking，把 token 留给 content

⚠️ URL 准确性

写入报告时，必须回到工具返回结果中逐条核对 URL，直接复制粘贴。常见错误：

X/Twitter 链接的 status ID 张冠李戴（不同推文的 ID 混淆）
博客文章的 slug 拼错
把 A 文章的 URL 贴到 B 文章上

如果某条资讯的原始 URL 在上下文中已找不到（被 compaction 清除），标注「链接待补」，不要编造。

输出格式（带编号）

每条资讯加全局编号 [1] [2]...（跨分类连续），方便用户引用反馈。

完整格式：

### [1] 标题
- 链接：URL
- 来源：信息源名称
- 摘要：1-3 句话概述
- 💡 业务启发：对用户业务的潜在参考价值

简报格式：

### [7] 标题（简报）
- 链接：URL | 来源：信息源名称
- 一句话概述

简讯区（报告末尾）：

## 简讯
- [12] [标题](URL)（来源）

热点汇总：

### [热点话题] 多方观点汇总
- 话题概述 / 各方对比 / 历史关联

报告末尾固定添加反馈提示：

---
💬 对本期内容有反馈？直接回复即可，如"[3]很有用"、"开源类太多了"、"多关注XX方向"

存档

报告 → {work_dir}/output/YYYY/MM/YYYY-MM-DD-HHmm.md
更新 {work_dir}/state/sent_items.json（对象列表：{"url", "title", "topic"}，保留 30 天，超期自动清理）
更新 {work_dir}/state/last_run.json

日志

保存到 {work_dir}/logs/YYYY-MM-DD-HHmm.log
记录每个源的拉取状态（成功/失败/跳过）、耗时、获取条目数

附录 A：主会话反馈处理

本附录由主会话 agent 执行，不在子 Agent 报告生成流程中。

触发条件

用户回复关于 AI 资讯报告的反馈：

条目评价：「[3]很有用」「第5条没价值」
分类/来源偏好：「开源类太多了」「基础研究简略点」
通用偏好：「多关注 Agent 落地案例」
隐式兴趣信号：用户要求针对某条资讯进一步了解、深入研究、展开分析 → 视为 valuable

处理流程

定位报告：读取 {work_dir}/output/ 下最新报告
解析反馈：
- 指向条目 → 匹配编号，提取 source / category / topics
- 指向分类/来源 → 直接匹配
- 通用偏好 → 记为 user_directive
- 要求深入了解某条目 → 匹配条目，评为 valuable
评级映射：
- 正面（有用、有价值、有启发…）或要求进一步研究 → valuable
- 中性（还行、一般、值得看看…）→ worth_reading
- 负面（没用、无聊、太多了…）→ no_value
更新 {work_dir}/state/preferences.json：追加 feedback_log，更新 scores，更新 updated_at
简短确认：一句话回复用户

preferences.json 结构

{
  "version": 1,
  "updated_at": "ISO8601",
  "feedback_log": [
    { "date": "YYYY-MM-DD", "report_file": "...", "item_index": 3, "item_title": "...",
      "source": "...", "category": "...", "topics": ["..."], "rating": "valuable",
      "raw_feedback": "原文", "timestamp": "ISO8601" }
  ],
  "source_scores": { "源名": { "valuable": 0, "worth_reading": 0, "no_value": 0, "total": 0 } },
  "category_scores": { ... },
  "topic_scores": { ... },
  "user_directives": [
    { "date": "YYYY-MM-DD", "directive": "原文", "type": "detail_level|focus_more|focus_less",
      "target": "名称", "active": true }
  ]
}

topics 提取规则

从条目标题和摘要中提取 2-5 个关键词（小写英文或中文短语），如 agent、mcp、开源模型。

配置

如需调整信息源、关键词、业务上下文：

直接编辑 {work_dir}/config/ 下对应文件
或告知 agent 更新

附录 B：定期配置自审视（主会话执行）

建议每周执行一次（可通过 cron 提醒或 heartbeat 触发），由主会话 agent 执行。

目的

用户的业务方向、关注点会随时间变化。定期审视配置，确保信息源和关键词始终贴合用户当前需求。

触发方式

cron 定时提醒：每周一次，向主会话注入系统事件，提示执行配置审视
手动触发：用户说「审视一下资讯配置」「更新一下关注方向」等

审视流程

收集上下文：
- 读取 USER.md 和近期记忆（memory/ 最近 7 天）
- 读取 {work_dir}/state/preferences.json，分析近期反馈趋势
- 读取最近 5-7 期报告（{work_dir}/output/），观察哪些话题反复出现或缺失
- 了解用户近期工作重点、新项目、新兴趣
对比现有配置：
- 读取 {work_dir}/config/ 下的 business-context.md、keywords.md、sources.md
- 识别：
  - 应新增的：用户近期频繁讨论但关键词库中没有的话题
  - 应移除的：长期无相关资讯或用户已不关注的关键词
  - 应调整的：业务方向描述过时、信息源失效或质量下降

生成建议（不直接修改文件）：

列出建议的新增/移除/调整项，附简要理由

示例：

📋 配置审视建议：

关键词：
+ `Manus AI` — 你最近多次讨论，但关键词库中没有
+ `AI 硬件 Rabbit R1` — 近期热点，与智能硬件方向相关
- `AI SaaS impact 2026` — 近 4 周无相关结果，建议替换为更具体的搜索词

信息源：
+ 建议增加 `https://www.deepseek.com/blog` — DeepSeek 近期动作频繁

业务上下文：
~ SkillHub 三层递进战略 → 建议补充最新的「圈组价值论证」结论

确认后我来更新，或者你告诉我调整方向。

等待用户确认：用户确认或调整后，更新对应配置文件

审视原则

只建议，不自动修改 — 配置变更必须经用户确认
轻量级 — 建议控制在 5-10 条以内，不要信息轰炸
有依据 — 每条建议附理由（来自记忆/反馈/报告数据）
保守移除 — 移除关键词要谨慎，优先标记为「待观察」而非直接删除

ai-news