我每天早上的固定动作曾经是这样的先打开十几个资讯源扫一遍看看有没有新的 AI 产品发布再把值得关注的几个扔进收藏夹等晚上有空了挨个点开看。这个流程持续了小半年之后我终于意识到自己其实是在重复做一件完全没有技术含量的事——搜索、筛选、记录每一步都是机械劳动。于是某个周末我给我的智能助理 Hermes 加了一个每日自动执行的任务让它自己搜索 AI 产品、自己整理摘要、自己把结果推送到指定渠道。现在这条链路已经稳定跑了两个多月这篇文章就是想完整记录一下我是怎么把每天早上人工扫信息这件小事变成一套由 Hermes 独立完成的自动化流水线的。如果你手上也有一台能跑脚本的服务器或者一个自托管的智能体环境并且每天也要花不少时间在行业信息收集上那么这篇内容应该能给你一套可以直接参考的落地思路。我会从整体架构讲到每个环节的具体实现包括搜索源怎么选、摘要提示词怎么设计、推送格式怎么排以及上线之后踩过的那些坑。1. 为什么一个会自己跑任务的智能体比闹钟提醒更靠谱1.1 信息过载的真正解法不是看得更多而是筛得更好我最早想解决的问题其实很简单每天新冒出来的 AI 产品实在太多了。有些是真正的技术突破有些只是套了一层 AI 壳的普通工具还有一些干脆是蹭热点的营销页面。如果靠人工一个个点开看时间成本高不说还特别容易被标题党带偏。但用工具自动汇总这个思路也有问题。市面上现成的资讯聚合工具我也试过不少它们的问题在于太通用——要么是全网所有内容的搬运工要么只能按固定分类输出没法针对我关心的新产品新模型新开源项目做精准筛选。我需要的是有一个像助理一样的角色它知道我关心什么、知道哪些信息值得报给我、也知道用什么样的格式报给我最舒服。这正是 Hermes 被设计出来的动机。它不是一个简单的 RSS 抓取器而是一个带理解能力的执行体先按我维护的关键词池去搜索再用规则和模型双重筛选最后把结果整理成结构化摘要推送过来。整个过程完全自动我只需要偶尔看一眼推送点开真正感兴趣的条目。1.2 Hermes 需要扮演的角色搜索员、分析师、编辑、邮差在动手搭之前我先明确了一个原则Hermes 的任务不是把所有内容都抓下来而是把值得我花时间的内容挑选出来。所以整套系统实际上要同时扮演四个角色。搜索员负责定时出去搜集信息它需要知道去哪里找、找什么关键词、用什么时间频率最合适。分析师负责判断一条信息是否值得进入候选列表它需要理解AI 产品这个概念在我这里的实际边界。编辑负责把原始信息改写成适合人阅读的摘要既要保留关键亮点又要控制篇幅。邮差负责把最终产物投递到我手边可能是即时通讯里的一个通知卡片也可能是一封邮件得保证稳定到达。这四个角色拆开来看都不复杂但合在一起形成一个闭环之后价值就出来了。我每天花在信息收集上的时间从原来的四十分钟压缩到了五分钟而且信息质量反而更高了。2. 整套自动任务的链路设计与分工谁在什么时候做什么2.1 四个环节触发-采集-加工-投递Hermes 的每日任务从结构上看就是一条单向流水线拆成四个环节以后每个环节都能独立修改也不会互相拖累。触发环节决定任务什么时候启动。我用的是定时触发方式每天早晨九点整拉起来跑一次。这里要注意不要选在凌晨跑很多搜索源和产品页面的更新时间都在上午九点左右能抓到相对完整的前一天信息。采集环节负责真正把内容拿回来。这一层同时做三件事根据关键词池向搜索接口发请求、读取预设来源列表里的更新条目、把返回的页面正文提取出来。采集之后的原始数据是乱的标题、链接、正文片段、发布时间混在一起所以紧接着要做规范化处理。加工环节是整条链路的核心。先跑一遍规则过滤器把明显不合格的条目扔掉再用模型对剩下的内容做精排和摘要生成。这个环节消耗的资源最多也是决定推送质量最关键的部分。投递环节把加工好的结构化结果封装成固定格式的消息通过即时通讯渠道的 Webhook 推送到我手机上。如果推送失败会自动重试连续失败三次就发一条告警通知提醒我去看日志。这四段式的分工参考了经典的管道设计好处是每一段的输入输出都是清晰的数据结构。我后来调整过其中任何一段都不用动其他段的代码。2.2 定时调度的选择为什么我最终选了轻量定时触发器其实一开始我纠结过要不要用常驻进程让 Hermes 一直挂在后台监听消息。后来想明白了这个任务的特点就是每天一次、时间固定、执行时间不超过几分钟完全没有常驻的必要。用轻量定时触发器是最省心的方案。我用的是系统自带的 crontab 来跑入口脚本表达式是0 9 * * 1-5周一到周五每天早上九点整触发。周末不跑因为我周六早上本来就不太想看业务信息留到周一再汇总反而更清爽。这种方式的优势很明显没有常驻进程就不会有内存泄漏的风险出问题也就是第二天任务不跑排查起来非常直接。任务启动以后还会写一条日志到本地文件记录本次执行的成功失败状态和耗时数据我偶尔抽查一眼就能掌握链路运行状况。唯一需要注意的就是服务器本地时间和定时表达式的关系。如果服务器配置在境外记得把 cron 表达式里的时区换算清楚否则任务会按服务器时区而不是你所在时区触发。3. 搜索环节把找 AI 产品这件事从玄学变成工程3.1 关键词池与来源清单决定搜索质量的隐藏因素搜索环节的产出质量九成取决于两个东西关键词池长什么样来源清单覆盖哪些站点。刚开始我以为只要把AI、人工智能这些大词扔进去就行结果第一天就翻车了——返回的全是行业宏观分析文章几乎没有具体产品。后来我把关键词拆成了几类产品类词汇比如AI 助手智能写作AI 编程工具技术类词汇比如大模型文生图Agent行为类词汇比如发布上线开源。每次搜索用产品词 行为词组合的方式比如智能写作 发布这样匹配到的结果大多是新产品的发布信息而不是泛泛的观点文章。来源清单也要维护。我筛了一批固定的信息源包括几个技术社区的新鲜事栏目、几家头部 AI 公司的官方博客、还有几个专门收录新工具的产品目录站点。固定来源的好处是稳定性高缺点是有遗漏所以搜索接口和固定来源两条腿走路彼此互补。这里有个容易被忽略的细节不同来源的内容格式差异很大有的直接给出完整介绍有的只有一句话加一条链接。所以采集完成后必须统一转成同一种内部格式保存成产品名、链接、简介、发布时间四件套方便后面加工。3.2 去重指纹与初次粗筛先干掉 70% 的噪音采集回来的内容里面重复现象特别严重。同一个产品经常同时出现在三四个信息源里标题还各不相同所以必须做一层去重。我用的是最简单的指纹去重方案把标题统一转成小写去掉所有空格和标点符号然后算一个哈希值。这个哈希值就是文章的唯一指纹存进本地数据库新抓到的内容如果指纹已经存在就直接丢弃。中文内容在去标点时要注意别把全角符号和半角符号混在一起最好统一做一次字符归一化。去重之后的粗筛规则我也整理了一套。标题里包含明显广告词的内容直接扔掉发布时间超过十五天的内容不纳入汇总正文长度少于五十字的条目没有分析价值还有一条比较狠的规则——标题里同时出现三个以上竞品名称的基本可以判断是行业综述文章也不是我们要找的具体产品。这一套规则跑下来大约能干掉七成噪音剩下来进模型的内容量就小多了。3.3 抓取与正文处理的注意点抓取页面正文这件事看起来简单实际全是坑。很多站点做了防爬手段直接请求会返回验证页面。我目前的处理方式是请求头里伪装成普通浏览器的 User-Agent并且控制抓取频率同一个域名两次请求之间至少间隔三秒避免给对方服务器造成压力。正文提取我用的是体重轻量级解析方式优先拿页面里的结构化数据字段拿不到再用正文提取规则。遇到拿不到正文的页面就用它的简介字段兜底。这里的原则是绝不硬抓——如果某个页面连续三次都取不到有效内容就把这个条目标记为内容缺失但不会让整个任务失败。采集到的原文也不会直接存数据库而是先做一次清洗去掉网页尾巴、去广告、拆出核心段落。清洗后的正文通常也就三五百字足够后续模型判断和生成摘要了。4. 加工环节提示词怎么写才能让摘要像人写的简报4.1 两步式加工规则打分 模型精排加工环节刚开始我也犯过错以为把所有内容一股脑丢给模型让它挑出来就行。结果 token 消耗巨大而且模型会把一些流量很高的营销软文当成优质内容留下。后来我改成两步式方案先规则打分后模型精排。规则打分给每个候选条目算一个基础分分数由四部分组成标题匹配度最高三十分看关键词覆盖了多少关键词池里的词发布时间权重十五分越新越高来源权重二十分我信任的优质源加分正文关键词密度二十五分剩下的十分给链接完整度。分数超过及格线的条目才进入下一轮。到了模型精排这一步输入内容量已经很小了。模型的主要任务不是找,而是判断和改写判断这条产品是否确实有值得关注的点然后把原始信息改写成一段有条理的摘要。这一步跑完输出结果的质量明显上了个台阶。4.2 一个可以直接抄走的 JSON 输出提示词模板模型生成的摘要我要求它严格按 JSON 结构输出这样后续推送到不同渠道都很方便。参考模板大致长这样你是资深 AI 产品分析师。根据下面提供的原始内容生成一条产品简报。 要求 1. 只输出 JSON不要解释不要多余文字。 2. JSON 字段固定为 name, brief, highlights, fit, risk, source。 3. highlights 最多三条每条不超过四十字。 4. 如果原始内容不足以判断 fit 或 risk对应字段写信息不足。 原始内容 {title} {summary} {date}对应输出样例{ name: 某智能写作助手, brief: 面向长文写作者的 AI 写作工具支持一键生成结构化大纲并在写作过程中实时提供引用建议。, highlights: [ 支持多文档联合检索引文来源可追溯, 内置主流写作风格模板可自动调优语气, 免费版每月可用次数较同类产品更宽裕 ], fit: 适合每天有大量文字产出任务的内容创作者、自媒体运营者, risk: 信息不足未找到明确的隐私政策说明, source: 某技术社区产品发布帖 }这里有个小经验JSON 输出一定要加上不要输出多余文字这个约束。不加的话模型时不时会在 JSON 前面加一段开场白后面解析程序就会崩。4.3 Token 成本控制的经验数值跑了一段时间后我统计了一下成本消耗。目前每天进模型的条目数量控制在六十条以内每条原始文本经过裁剪后大约三百字模型按日常思考模式跑一次每天一共消耗的 token 量并不多按市面上常见模型的定价算一个月成本非常低。要是哪天搜索源特别多有超额风险就要启用量化裁剪策略只保留每条内容的标题与前两个关键段落其余全部截断。这个操作会把上下文长度压下去一大截虽然摘要内容可能会少一些但核心信息基本都在。另外建议把模型的温度参数调低一点。这类生成摘要的任务是在做信息压缩不是创意写作温度越低输出越稳定也不容易出现天马行空的跑偏描述。5. 推送环节结果用什么姿势送到你面前5.1 推送渠道的选择即时通讯 Webhook、邮件还是自建页面加工完成的结果不能躺在服务器里得推到我随时能看见的地方。目前我用的主要渠道是即时通讯工具的自定义 Webhook 机器人。这种方式的优势非常明显手机端实时推送、支持富文本消息、还能把多条结果收进同一条汇总消息里体验比邮件轻很多。邮件渠道我也预留了作为兜底方案。Webhook 偶尔会因为服务不稳定出现延迟这时候邮件至少能保证信息不丢。自建一个展示页面的方案我也考虑过专门用来截图存档每日推送但暂时还没有实施因为 Webhook 加邮件的组合目前够用。加 Webhook 的时候要配置一个新增消息的接口地址把加工完的 JSON 数据结构转成目标平台的消息卡片格式。提醒一句推送目标平台的消息格式限制要提前查清楚比如长文本截断长度、字段最大长度、是否支持自定义标题这些否则消息内容会被悄悄切掉。5.2 推送内容的排版与样式模板为了让推送出来的一堆消息不至于变成流式刷屏每条产品简报我固定用同一套排版模板产品名称加粗作为第一行下面是简介然后是一个包含三个要点的小列表最后附上来源链接和适合人群。整体效果类似下面这个样子某智能写作助手面向长文写作者的 AI 写作工具支持一键生成结构化大纲并在写作过程中实时提供引用建议。支持多文档联合检索引文来源可追溯内置主流写作风格模板可自动调优语气免费版每月可用次数较同类产品更宽裕 适合人群内容创作者、自媒体运营者 来源某技术社区产品发布帖排版这件事不要低估。同样一条信息排版清楚和排版混乱给人的阅读成本差别非常大。我自己迭代过好几个版本最终定下加粗名称 单段简介 短横线列表 灰色来源行的组合实测阅读效率最高。5.3 幂等与重试别让同一条消息刷屏推送接口调用不能傻乎乎只调一次。网络抖动、目标平台服务异常都可能导致推送丢消息所以必须加重试逻辑。我的策略是失败后等待十秒重试一共重试三次三次都失败就把消息状态标记为失败并转移到一个独立队列第二天随当日推送一起补发。但如果重试逻辑写得不仔细就可能出现同一条内容被重复推送好几遍的情况。尤其要注意的是重试前必须检查当前消息是否已经被成功推送过用消息的唯一日志ID做标记避免重复发送。我就在这上面栽过一次某天推送接口超时但实际消息已经发出去了重试之后同一内容出现在屏幕上两次后来加了幂等标记才解决。6. 上线两周后踩过的坑与逐步调优记录6.1 坑一搜索接口返回了大量伪 AI 产品营销文上线到第四天我发现推送里混进来好多明显是营销软文的条目。点进去一看全是同一模板批量生成的内容标题蹭了 AI 关键词但正文都是在推广某个培训课程。这个坑直接暴露了关键词池方案的缺陷——只看关键词匹配挡不住营销文案。当时想了几种对策最终管用的有两招第一在规则打分里加了一个营销信号惩罚项标题中出现免费领取限时优惠包教包会这些词的直接扣分第二手动维护了一个不可靠来源黑名单凡是名单里出现过的域名直接不给进入候选列表的机会。两招下来营销文占比立刻降到了可控范围。6.2 坑二模型偶尔幻觉出不存在的新功能模型生成摘要的另一个问题是有时会脑补。原始内容里只提到了支持多人协作它生成的亮点里却变成支持多人实时协作编辑。这个偏差单独看没什么但一旦整理进推送读者就会误以为产品已经具备了这个能力。作为信息汇总工具忠实于原文是底线。我目前的处理方式分两步。一是提示词里明确写亮点必须可以在原始内容中找到对应依据禁止推测和引申。二是在流程里加了一个校验动作生成亮点后让程序检查亮点文本里的关键词是否出现在原始内容关键词列表中匹配不上的自动降级为信息不足。这个方法虽然粗暴但能有效拦截幻觉。6.3 坑三每天推送变成了信息轰炸跑了九天之后出现了一个新的困扰工作日每天推送十条左右的简报数量并不夸张倒是排版风格很拖——上午推送一次下午偶尔又补发一条信息碎片化反而让人烦躁。我意识到了推送节奏的问题不只是推什么还包括何时推多久推一次。于是我把策略调整成两个层级。每个工作日保持九点推一次但把全部内容聚合到下午统一推。同时允许非工作日只推重要内容数量超过十五条的日期再加一个今日最值得关注 Top 3置顶区省得让我在海量条目里自己挑重点。6.4 调优把推送频率从高到低、内容聚合成日报后来我把推送进一步格式化从九点一次实时推送改成每日九点推送昨日汇总日报。这个调整执行之后阅读率提升了不少。原因也很简单实时推送在情绪上会给人一种被消息追着跑的紧迫感汇总日报则更像一份可以从容浏览的材料信息密度更大且没有干扰。聚合日报的格式说实话就是前面 5.2 节模板的扩展版本——开头一个今日关注推荐区列出三条重点正文按新工具新模型开源项目观点文章四个分组排列结尾一行统计今日抓取、筛选和最终推送的条目数量。加了这个统计信息后我对每日系统的运行状况一目了然。7. 这套系统目前的状态以及如果有时间我会再做点什么7.1 关于可维护性的体会这套 Hermes 每日任务到现在已经稳定跑了两个多月最大的体会是让一套自动化系统长期可靠运行麻烦不在于跑起来而在于持续维护。关键词池会过时、来源站点会改版、推送渠道会调整接口哪个环节断了整个链路都会出问题。所以我隔两周会花半小时扫一遍仓库里的配置项并根据近期的推送效果手动优化关键词池及时补充新发现的优质来源剔除已经失效的信息源。日志也很重要。从第一版开始我就坚持让每个环节都写结构化日志至少记录输入条数、过滤条数、生成结果数、推送状态这四个核心指标。当某个渠道的推送效果变差时回溯日志能很快定位到是采集量下降还是筛选尺度过严。7.2 最后说一点个人建议如果你也想给自己的智能体安排类似的任务我的建议是先跑通一个最小路径不要一开始就搭建复杂的架构。第一天先让脚本能抓五个固定来源第二天加上最简单去重第三天加一个粗糙的推送接下来再逐步往里面加功能。每一次修改都要保证当天能验证效果这样整套系统的技术债能被压到最低。还有一个值得投入的方向是把历史推送积累成数据库。我目前每天推送之后都会把原始整理结果存进本地库现在数据库里大概积累了上千条产品信息后续可以用来做趋势分析甚至可以反向训练一个推荐模型。当初只是为了一时方便现在看这成了一个额外资产。技术项目做到这种程度往往才会发现它带来的好处已经超出了最初的设计目标。