jingxuanc/quant-agent-skills/news-radar

消息雷达

何时使用

• 今天有什么消息 / 最近发生了什么？
• 扫一下消息面，有什么值得关注的？
• 看看今天有哪些公告 / 有没有重要公告？
• 最近有什么政策 / 行业新闻？
• 今天盘面为什么动，有什么消息吗？
• 有什么消息是我该知道的吗？（用户没有具体标的，就是想"扫一圈"）

边界（与相邻技能的分工，务必分清）：

⚠️ 本技能只负责发现与筛选消息，一旦用户指定了具体消息要算冲击，交棒给 event-impact；要算传导链交棒给 event-propagation。不要在本技能里越界做冲击计算。

轻问 vs 深问（成本控制）

轻问（默认，1–2 个工具）：只想知道「今天大概有什么」。

• 调 news-get_events（读已落库的事件，不触发采集，最快）；若库里为空或明显过期，再用 astock-data-get_a_news 现取个股新闻。
• 成本：一次读库，秒级。默认走这条。

深问（3–5 个工具 + 分类清单）：用户要「扫一圈 / 全面看看」。

• 先 news-get_events（读库）→ 不足则 news-run_pipeline（采集+去重+分类落库）→ 再补 astock-data-get_a_announcements（公告）、astock-data-get_a_limit_up_pool + get_a_zt_reason（涨停及原因）、astock-data-get_a_hot_reason（强势股理由标签）。
• 最贵的一步：news-run_pipeline —— 它要现场抓 3–6 个外部源（新浪/华尔街见闻/财联社/东财公告/龙虎榜/热榜），是唯一有网络等待的一步。只在库里数据过期时才调，不要每次问都重采。
• 第二贵：astock-data-get_a_announcements —— 按标的逐个查公告，标的多了会线性变慢。一次不超过 10 个标的。

批量/重任务：本技能不涉及回测/训练。若用户要"扫全市场所有公告"，那属于数据管道批量任务，应走异步路径并告知用户，不要在一次调用里堆几百个标的。

工具链

第 0 步：先读库，别急着抓（本技能最重要的一条）

• 工具：news-db_stats（可选，看库里有没有货）→ news-get_events
• 顺序铁律：先 `get_events` 读已落库事件；只有读不到、或数据明显过期（最后事件时间早于用户问的时点）才触发采集。
• 理由：get_events 是秒级的本地读；run_pipeline 是现场抓六个外部源。绝大多数「今天有什么消息」都能被已落库的数据回答。

第 1 步：采集（仅当库里为空或过期）

• 工具：news-run_pipeline
• 参数：
• sources：源名数组，取值见 news-list_sources。常用 ["wallstcn","sina","cls"]（快讯三源）；要公告加 "notice" 并配 codes；要盘面情绪加 "lhb" / "hot_rank" 并配 date_from/date_to。
• limit：每源条数，默认 20。扫消息面给 15–20 够；给 200 只会把重要消息淹掉。
• persist：建议 `true` —— 落库后下次问同类问题就直接读库，不再重复抓。
• codes：仅 `notice` 源需要，股票代码数组。
• 返回：stage（bronze/silver/gold 各层计数）+ events（分类后的事件数组）。
• 读法：stage.silver.deduped 是近重复被剔除的条数（SimHash 判重，汉明距离 ≤3）；stage.gold.dropped_no_type 是判不出事件类型被丢弃的条数。这两个数字要如实写进报告——它们说明"你看到的清单已经过筛，不是全量"。

第 2 步：补充盘面事实（深问）

• 工具（按需，全部来自数据组）：
• astock-data-get_a_limit_up_pool：涨停池（含封单、连板高度）
• astock-data-get_a_zt_reason：涨停原因标签 —— 这是把"消息"和"盘面"连起来的关键
• astock-data-get_a_hot_reason：强势股理由标签（同花顺编辑口径）
• astock-data-get_a_board_emotion：板块情绪（炸板率、连板高度）
• astock-data-get_a_announcements：公告全文（需标的列表）
• 用途：单看快讯不知道市场在意什么；涨停原因 + 热榜理由才是"市场实际在为什么付钱"的答案。

第 3 步：筛选与排序（不要原样倾倒）

按下面的优先级排序，默认只给前 8–12 条，其余折叠为"其他 N 条"：

sectors 为空是常见现象（关键词规则匹配不到就为空），不要因此断定它不重要，但也别硬给它编板块。

第 4 步：合并输出（见下方契约）

记忆回路（前查后记）

本技能的记忆维度是 注意力校准：我过去判定"值得关注"的消息，事后有多少真的重要（真的影响了对应板块/标的的后续走势），有多少只是噪音。这是本技能唯一值钱的东西——它训练的是用户的注意力分配，而不是预测能力。

为什么这个记忆对用户有价值：消息面的核心难题不是"能不能拿到消息"（数据源都是公开的），而是注意力有限、噪音无限。"我上次重点标的那类消息后来是不是真的重要"这个经验，比任何重要性打分都更贴合这个用户自己的信息环境（他的持仓、他关注的板块、他的时间尺度）。积累几十次后，「哪些消息对你才真的算重要」就有了只属于他的答案。

输出格式

Agent 必须按下面小节输出，字段缺失就写「未取得」，不要编。

1. 一句话总览：先给当天消息面的性质判断，例如「今日消息面以产业类为主（AI 算力 3 条、半导体 2 条），政策面 1 条（央行），外围 2 条」——只描述构成，不评价好坏。
2. 重点消息清单（核心，按第 3 步优先级排序）：

• 「相关板块/标的」列只填数据里实有的 sectors / symbols；为空写「未标注」。
• 标题原样转述或压缩，不要改写成带倾向的标题（把"某公司拟收购"改写成"某公司大动作"属于违规）。

1. 盘面印证（仅深问）：涨停家数、炸板率、最高连板、涨停原因标签 top5、热榜理由 top5，以及一句话「消息与实际资金流向是否互印证」。
2. 被筛掉的部分（必写）：stage 里的各层计数与筛选口径——原始 N 条 → 去重后 M 条 → 判出事件 K 条 → 最终重点 8–12 条。必须让用户知道这不是全量。
3. 数据与方法声明（必写）：采集了哪些源、条数、是读库还是现采、库最后更新时间、sectors 未标注的比例、是否有源抓取失败（per_source 里为 0 的源要如实写）。
4. 不确定性与下一步：可验证的建议，例如「某源今日返回 0 条，可能限流，可稍后重试」「某事件仅单源报到，建议留意后续是否有其他源跟进」。

历史参照（必填小节）：若检索到同类历史，写明「类似情境 N 次，其中 X 次 当时标记的重点消息后续真的兑现为板块/个股异动」；

无历史则写「首次记录此类情境，本次判断已存入记忆供将来对照」。

合规边界

• 只做信息发现与事实陈述：事件类型、标题、时间、来源、相关板块与标的（以数据实有字段为限）。
• 不输出：买入/卖出建议、"值得关注（买）"这类暗示、目标价、涨跌幅或收益承诺、个股推荐排序的理由化包装。
• 不预测：本技能不做"这条消息会涨/会跌"的判断。用户若想知道影响，明确交棒给 event-impact（冲击计算）或 event-propagation（传导链）。
• 不改写标题倾向：转述消息时保持中性；禁止把"拟 / 传闻 / 据报道"改写成确定性表述。
• 不标"重要"而不给依据：每条重点消息必须能说出它为什么排在前面（多源印证 / 政策类 / 与涨停原因互印证），渠道靠前而无法说明理由的，降级或折叠。
• 若报告后接了预测模型（Kronos / ML 打分），必须加注：模型输出，非承诺，不得作为结论依据。

常见问题

1. 别每次问都重新采一遍：run_pipeline 要现场抓 3–6 个外部源。先 get_events 读库，秒级返回；只有库空或过期才采。这是本技能最容易浪费成本的地方。
2. `sectors` 为空是常态，不是异常：事件板块靠关键词规则匹配（gold_classify），匹配不到就是空。报告里如实写「未标注」，不要为了好看硬塞板块，也不要因此把整条消息丢掉——用标题自己判断相关性，但判断结果要标明是推断。
3. `notice` 源必须给 `codes`：公告是按标的查的，不传 codes 会拿不到任何公告。要"全市场公告"不是这个技能能做的事。
4. 采集结果里大量条目会被静默丢弃：silver 层做近重复剔除、gold 层丢弃判不出类型的条目。最终清单不是"抓到多少"，一定要把 `stage` 计数写进报告，否则用户会以为这就是全部消息。
5. 信息来源不等于可信：本技能只做发现，不做真伪判定。若用户追问"这条是不是假消息"，那是另一件事——不要用本技能的清单冒充可信度结论。