舆情监测简报

舆情这件事，整理得再漂亮，晚了就没用。人工盯盘盯不住——渠道分散、更新频繁，而且大量内容是同一件事的重复转载，翻二十条可能只有三件事。等人工归并完出简报，往往已是第二天上午。

真正需要的不是"全都看一遍"，是"有没有需要今天处理的"。

需要长期跟踪的官网、帮助中心、行业站点，用 Web 站点知识库接入：填 URL 自动爬取建库，支持增量更新。这类内容交给平台按周期同步，不必每次重新抓。

有开放接口的数据源，在工作流里用 HTTP 请求节点拉取，节点上配好超时与重试。网络抖动是这类采集的常态，重试配置能显著降低空跑率。

内容送进问题分类节点。它本质是预设了分类逻辑的 LLM 节点，配置更简单、输出更稳定——固定输出 class_name，下游直接接条件分支节点分流。

分类定义要舍得写细。除了正面/负面/中性，单独设一类「需立即处置」，并在描述里写清边界：涉及产品安全、涉及监管表述、涉及高影响力账号的负面内容。分类描述越具体，准确率越高，这是这个节点最需要调的地方。

判定为需立即处置的走单独的加急分支，不与常规简报同一条路径——它的时效要求完全不同。

同一事件的多家转载用代码执行节点做相似度归并：保留最早发布的一条作为主条目，其余折叠为转载数和渠道分布。

这一步做与不做，简报的可读性差别极大。呈现的应该是"发生了三件事，其中一件被转载了 47 次"，而不是五十条按时间排列的条目。

整条流程挂定时任务，按小时或按天运行。工作流的结束节点选「输出文本」模式，用 {{变量}} 把主条目、倾向分布、趋势与原文链接拼成成稿简报。

选这个输出模式的意义是：拿到的就是能直接转发的内容，不需要谁再做一次排版。这类周期性产物，最后一公里的人工成本常常比生成本身还高。