每天上午十点半我的微信里会准时弹出一条推送一份整理好的 AI 行业日报按“模型与框架”“产品与平台”“开源项目”“产业与政策”分好类每条资讯带着一句话摘要和一句“为什么值得关注”。这活儿不是我手动干的也不是某个公众号的定时发送而是我给 WorkBuddy 设的一个定时任务。用一句话说清楚这个事我用自己的 AI Agent 搭了一条自动化流水线每天定时抓取 AI 相关资讯用大模型做清洗和摘要最后通过微信推送到我手机上。这篇内容适合谁看两类人。一类是已经在用 WorkBuddy 或者类似 Agent 工具、但只拿它做单轮问答的人想看看怎么把“一次性对话”变成“持续运行的工作流”。另一类是每天需要追 AI 资讯的从业者比如开发者、产品经理、投资人手动刷信息流太费时间想搭一个属于自己的信息管道。下文会讲清楚整体设计思路、关键技术细节、完整实操过程和我在踩坑中总结出来的排查方法你可以直接照着搭一套。1. 整体设计与思路拆解这到底在解决什么问题1.1 需求本质是把“每天早上刷手机找资讯”这件重复劳动自动化先拆一下这个需求。我想做的事情很朴素每天早上花十几分钟浏览各种渠道的 AI 资讯挑出值得关注的几条整理成摘要发给同样关心这些信息的朋友们。听起来不复杂但真做起来有几个痛点。第一个痛点是信息源太分散。推特上的 AI 圈动态、Hugging Face 的热门模型、GitHub 趋势榜、几个关键博客的更新、arXiv 上的新论文各有各的入口。手动逐个刷一遍少说也要二十分钟。第二个痛点是信息量过载。AI 行业每天新增的资讯量非常大其中大量是产品发布通稿、PR 稿件、重复报道真正值得关注的也许只有几条。筛选需要判断力而这恰恰是消耗精力的核心环节。第三个痛点是推送渠道。整理完信息之后怎么让我在手机上方便地看到邮件太容易被忽略短信成本高最自然的还是微信——它是我每天打开次数最多的应用。如果把整个流程拆开看会发现它就是一个标准的“采集—清洗—加工—分发”数据管道。采集对应的抓取信息源清洗对应去重和过滤噪音加工对应用大模型做摘要和分类分发对应推到微信。手工模式下这四个环节都由我来做自动化之后这四个环节交给了不同的工具WorkBuddy 负责编排和调度内置的搜索工具负责采集大模型负责加工微信推送 API 负责分发。1.2 为什么用 WorkBuddy 而不是自己写一套 Python 爬虫脚本这里有一个很现实的问题这个需求用 Python 也能实现甚至很多教程里会教你怎么用 requests 抓 RSS、用 OpenAI API 做摘要、再用企业微信机器人推消息。那我为什么选 WorkBuddy先说说自己写脚本的痛处。首先是维护成本。RSS 源会变网页结构会改API 的 token 会过期任何一个环节出问题脚本就静默失败。你得定期去检查、修 bug、调参数。其次是工具拼装的复杂度。你要自己写抓取逻辑、自己处理各种反爬、自己管理 API key、自己写重试逻辑。一套跑通没问题但要持续稳定运行工作量比想象中大得多。WorkBuddy 这类 Agent 工具的核心价值是把“工具调用”和“任务编排”做成了配置化能力。我可以直接用自然语言描述任务目标Agent 会自己决定用哪些工具、按什么顺序执行。比如我说“抓取这几条 RSS 源过滤掉重复内容按分类整理成日报”它会把抓取、清洗、分类、摘要这些环节拆解成一个个步骤自动执行。更重要的是WorkBuddy 支持持续运行的任务常驻 Agent 或定时任务我可以给它们定规则让后续所有类似任务都自动遵守。另外一个隐藏优势是迭代成本低。写脚本的时候想改个分类规则你得去改代码在 WorkBuddy 里我只需要改一段提示词或规则描述。对于一个信息整理类的需求业务逻辑的变化远比代码逻辑频繁所以用“模型 规则”而不是“代码 分支”来处理长期看更高效。1.3 “上午十点半”不是随便选的定时策略里全是细节标题里特意写了“每天上午十点半”这个时间点背后是有考量的。第一它避开了早上信息密集发布的时段。AI 圈的资讯发布高峰集中在凌晨到早上八点左右包括海外开发者发布新项目、公司发新闻稿、社区讨论升温。九点整抓的话很多信息还没发出来十点半抓能覆盖到当天的早间资讯又不会太晚确保上午就能看完。第二它考虑了使用场景。我一般在十点到十一点之间开早会或者进入工作状态这时候收到一份整理好的日报刚好可以作为当天信息输入的起点。如果推到晚上信息时效性就打折了推到早上八点用户大概率还在通勤路上根本没空细看。第三从系统可靠性角度看避开整点也是一种习惯。很多定时任务都设在整点或半点如果你用的服务或 API 有峰值限流策略整点集中触发更容易撞上限流。我实际测试中发现设在十点三十一分比十点三十分更容易稳定触发虽然差别很微小但这种细节累积起来会让任务更稳健。定时任务的频率设计也很关键。对于资讯日报这种场景一天一次是合理的频率太低比如每周一次会让信息量过大、重点被稀释频率太高比如每小时一次则会造成大量重复内容还会增加 API 调用成本。原则是“够用就好”不要为了自动化而自动化。2. 核心细节解析与实操要点2.1 WorkBuddy 里三个容易混的概念Agent、Skill、Rule打算实操之前得先把 WorkBuddy 的几个核心概念理清楚因为这些概念直接决定了整个任务怎么搭。不同版本的产品界面和名称可能略有差异但核心逻辑基本是通用的。Agent是执行任务的主体。可以把它理解为一个“数字员工”它接收任务描述调用工具生成输出。在日报场景里Agent 负责理解“去抓资讯”“整理摘要”“推送到微信”这一连串指令并把它们拆解为可执行步骤。每个 Agent 可以有独立的系统提示词用来设定它的角色和行为边界。Skill是外挂技能包。一个 Skill 通常打包了一套工具或一套提示词流程。比如“搜索 Skill”可能封装了调用搜索引擎或 RSS 抓取的能力“微信推送 Skill”封装了调用推送 API 的完整逻辑。WorkBuddy 能识别用户创建和安装的各种 Skill在任务执行时按需调用。日报任务里我需要确保至少有一个“信息获取 Skill”和一个“消息推送 Skill”可用。Rule是全局规则它不针对单个任务而是对所有任务生效。比如你可以定一条规则“所有输出必须使用简体中文不得出现英文缩写之外的术语。”这条规则一旦设定后续所有 Agent 任务都会自动遵守。我在做日报任务时会把“日报必须按四个板块分类”“每条资讯必须包含一句话摘要”这类要求写成规则而不是塞进某一次的提示词里。这三者之间的关系类比一下就是Agent 是员工Skill 是他会用的工具Rule 是公司的规章制度。员工干活用工具但所有活都受制度约束。2.2 时间触发器的工作逻辑cron 表达式和时区是两大坑定时任务的核心是一个触发器WorkBuddy 一般用类似 cron 的表达式来定义执行时间。cron 表达式的格式是“分 时 日 月 周”五个字段依次对应分钟、小时、日期、月份、星期几。我设的“每天上午十点半”对应的 cron 表达式是30 10 * * *。含义是当分钟等于 30 且小时等于 10 时触发其他字段日、月、周都是 *表示任意值均匹配。这样就是一个每天十点三十分执行的任务。真正容易出问题的是时区。当 Agent 帮你生成定时任务时它默认通常在本地时区解析时间但如果你用的服务端部署在海外或者 Agent 运行环境是 UTC 时区就可能在时间换算上出错。我踩过的坑是第一次配置时报文显示“每天 10:30 触发”实际执行却在每天 18:30——因为环境用 UTC 时间存储和解析而我在东八区。所以配置完一定要在调度记录里确认实际执行时刻而不是只看界面上显示的 cron 表达式。另一个容易被忽略的点是定时任务的“最小执行间隔”限制。你现在不太可能用 WorkBuddy 做每秒钟或每分钟级别的任务通常最小支持到 5 分钟或 10 分钟。做日报这种低频任务完全没影响但如果你未来想做实时监控类的任务就得换一套方案了。2.3 微信推送的几种方案各自原理和适用场景把日报推到微信是整套流程里最容易出问题也最需要选型的一环。微信自身没有对个人开发者开放的“主动推送”API所以常见的做法都是间接实现。我对比过三种方案核心原理和适用场景如下表方案实现原理适用场景优点缺点Server 酱ServerChan通过关注“方糖”公众号获取 SendKey向服务器发送请求后消息以服务通知形式推送到公众号从而到达微信个人自用配置最简单一分钟搞定依赖第三方服务免费版有调用频率限制企业微信群机器人在目标群添加自定义机器人获取 Webhook 地址向该地址 POST 一段 JSON 即可发到群里团队共享、日报同时推给多个人免费、稳定、可同时多人看到需要企业微信个人可免费注册消息有长度限制PushPlus与 Server 酱类似通过关注公众号获取 token调用 HTTP 接口推送个人自用支持多种消息类型免费版有限制稳定性依赖第三方我实测下来最顺手的组合是个人日报用 Server 酱团队日报用企业微信群机器人。前者胜在配置极简后者胜在稳定和多人共享。这俩可以并存不冲突。需要特别注意所有第三方推送方案都有长度限制Server 酱单条消息上限通常在一两千字左右企业微信机器人则要求 2048 字节以内超出会被截断或报错。我早期把整份日报不分段压缩成一条消息推送结果总是在中段被截断格式全毁。后来的做法是摘要标题当一条消息正文细节分几条消息或者干脆在日报里只发摘要和分类详情留在云端。3. 实操过程与核心环节实现从零搭一个 AI 日报流水线接下来是这套自动化任务的实际搭建过程。我会按照关键环节一步步说明并给出可直接复制的配置和模板。3.1 第一步建一个专门的日报 Agent给它立好人设在 WorkBuddy 里创建一个新 Agent给它命名比如“AI 日报员”然后设置系统提示词。系统提示词是 Agent 行为的底座相当于给它立“人设”。我的系统提示词在反复调整后稳定成这样你是一个行业资讯编辑职责是每天为用户生成一份高质量的人工智能行业日报。 你偏好高质量、非重复、有长期价值的信息主动忽略 PR 通稿、营销文案和纯八卦。 所有输出使用简体中文语言精炼不带个人情绪。这段提示词解决三个问题。第一明确角色是“编辑”而非“搜索引擎”强化筛选意识。第二明确偏好和“忽略清单”把常见的噪音类型直接排除。第三明确语言和风格避免 Agent 突然切换成英文或输出带情绪的内容。创建完 Agent 后建议先手动运行一次输入一个测试指令比如“请抓取今天的 AI 资讯简单列出 5 条最值得关注的”看它输出的格式和判断力是否符合预期。这一步很重要因为后续的定时任务本质上是在重复执行这个 Agent 的行为基线质量不对自动化之后只会放大问题。3.2 第二步配好信息源用 RSS 做主输入并让搜索兜底日报的信息质量七成靠信息源。我在 WorkBuddy 的 Skill 配置里把信息获取设计成了“RSS 为主、搜索兜底”的双通道模式。主通道是 RSS。我选了 5~8 个信息源原则是覆盖不同子领域综合性 AI 媒体比如少数派、机器之心、量子位这类平台开发者社区和论文平台以及几个在 GitHub 上活跃的开源项目发布源。RSS 的好处是格式统一、抓取稳定不会因为网页结构调整而解析失败。兜底通道是让 Agent 在 RSS 信息不足时自行搜索。在任务提示词里我会留一句“如果某个板块信息不足或发现重大新闻未被 RSS 覆盖请自行搜索补充”。这时候 Agent 会调用 WorkBuddy 的搜索 Skill 去补充信息。这里有个配套的关键配置去重规则。RSS 里经常出现同一个新闻被多个源重复报道的情况如果不去重日报里会出现三条内容几乎一样的条目。我在 Rule 里加了一条规则“在生成日报前先根据标题和核心内容识别并去除重复条目保留来自最权威或信息最完整来源的一条。”这听起来像常识但如果你不明确写进规则里Agent 经常会犯“忠实搬运所有来源”的机械错误。另外需要注意RSS 源不要配太多。我试过配十五六个源结果每天日报变得又长又重复筛选成本反而超过我手动刷信息流。五个高质量的垂直源加上一个搜索兜底足够覆盖 AI 行业日常动态。3.3 第三步写日报生成的提示词模板这一段是核心竞争力日报的内容框架由一段核心提示词决定。这是我调了大概一个星期后稳定下来的模板你可以直接抄请按以下结构生成今天的 AI 行业日报 【模型与框架】大模型、Agent、新架构等信息关注技术突破和发布 【产品与平台】新产品、功能更新、平台政策变化关注对开发者/用户的实际影响 【开源项目】GitHub 热门项目、开源工具发布关注 Star 增长快的项目和实用性 【产业与政策】融资、商业化、行业机构动态关注产业链层面的影响。 每个板块挑选不超过 3 条最重要资讯。 每条资讯格式 - 一句话标题含来源或公司名 - 摘要不超过 50 字说清楚“发生了什么事” - 为什么值得关注不超过 40 字说清楚“对谁有影响、影响是什么” 整份日报总字数控制在 800 字以内。写这段提示词时踩过的坑和对应策略坑一不分类导致内容大杂烩。一开始我只让 Agent “挑出重要资讯”结果它按来源而不是按主题组织内容看着很乱。加了四个固定板块之后结构就稳定了。这其实是给 AI 设定了输出框架比让它自由发挥可靠得多。坑二摘要写成了原文复述。早期模板只要求“摘要”Agent 倾向于把原文前两句抄过来没有提炼。后来我在模板里明确要求“说清楚发生了什么事”并且加了“为什么值得关注”这个字段强制它做二次判断。坑三长度失控。Agent 一旦没有字数约束能给你输出三四千字的“日报”信息密度反而变低。800 字这个上限是我反复试出来的平衡点能覆盖大部分重要内容又不会让推送超长。实际推送时800 字正文加上标题和格式正好落在 Server 酱单条消息的可读范围内。3.4 第四步把日报接进微信分个人版和团队版两种配法按 2.3 节的选型我分别给出两种推送配置的可复制方法。个人版Server 酱。先去方糖官网用微信扫码登录绑定你的微信得到一个 SendKey形如SCTxxxxx。这个 SendKey 就是你调用推送 API 的凭证。然后把它配置到 WorkBuddy 的“消息推送 Skill”里。调用方式就是一个 HTTP POST 请求curl https://sctapi.ftqq.com/SCTxxxxx.send \ -d title今日 AI 日报 \ -d desp日报正文内容支持 Markdown在 WorkBuddy 的任务提示词中只需要加一句“日报生成后调用消息推送 Skilltitle 为‘今日 AI 日报’正文为完整日报内容发送到我的微信。”Agent 会自动执行这个 HTTP 调用。团队版企业微信群机器人。在企业微信里创建一个群哪怕是只有你自己的群点击群设置添加群机器人拿到一个 Webhook 地址。向这个地址 POST JSON 即可curl https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key \ -H Content-Type: application/json \ -d {msgtype: text, text: {content: 今日 AI 日报内容纯文本}}团队版最大的优势是机器人发布的消息团队所有成员都能看到而且不用逐个配置 SendKey。我后来把日报推送到团队群后组内其他成员直接受益不需要他们做任何设置。3.5 第五步设定时任务然后“先手动跑两次再定时”所有组件都配好后最后一步才是设定时任务。这里有一个我强烈推荐的操作顺序不要先定时而是先手动触发两次确认输出稳定再上定时。第一次手动触发让它生成一份“基于昨天的资讯”的日报检查格式和信息质量。大概率你会发现排版问题、分类不合理或某些板块信息过少——这些都值得趁这时候调模板。第二次手动触发再跑一遍确认同样的任务能稳定输出而不是偶尔成功偶尔失败。确认无误后在 WorkBuddy 的自动化配置面板里新建定时任务选择刚刚创建的日报 Agent触发时间设为每日 10:30对应 cron 表达式30 10 * * *状态设为启用。设置完成后的头三天每天十一点前后记得检查一下推送是否到达。我遇到过一种情况第一天推送正常第二天没推后台看调度记录显示任务执行了但推送失败原因是 SendKey 前一天刚好到期需要重新验证。这种“间歇性异常”只有连续盯几天才能暴露出来。4. 常见问题与排查技巧实录我踩过的坑都在这里这套流程跑通之后的稳定性比较理想但过程中我遇到过不少问题按频率和影响大小排个序集中在下面几个场景。4.1 定时任务执行了但微信没收到推送这是最让人头疼的情况因为任务看似跑完了但你什么都没收到。我总结的排查顺序先看调度记录确认任务是否真的执行。如果任务没触发多半是时区问题检查 cron 表达式的解析时区是不是 UTC必要时把执行时间调成本地时区对应的表达式。其次看执行日志确认 Agent 是否成功调用了推送 Skill。如果日志显示调用成功但你手机没收到分两种情况Server 酱的话检查 SendKey 是否过期、免费额度是否用完企业微信机器人检查机器人是否被移除出群、Webhook 是否仍有效。判断微信侧问题最直接的办法手动把推送 URL 复制到浏览器里访问一次看返回状态码。返回成功但手机没消息问题在第三方服务返回失败问题通常在你自己的 token 或参数上。4.2 日报里出现大量重复内容或者多个来源扎堆同一件事这个问题早期非常频繁因为 RSS 源互相转载的情况太常见了。光靠提示词里写“请去重”还不够我后来加了两道保险。第一道是在 Rule 里写死“同一个事件如果多个来源都有报道只保留信息最完整的那个来源并把其他来源视为重复内容丢弃。”第二道是在提示词中让 Agent 主动维护一个“今日已收录事件清单”每加一条前比对一遍。实测下来后者的效果更好因为强制 Agent 在生成过程中做“比对”而非“事后总结”。4.3 日报太长或者推送时格式乱掉这在 3.3 节提过两次核心原因微信推送对消息长度有硬限制。Server 酱和 PushPlus 对超长文本的表现不同——Server 酱会截断PushPlus 可能直接报错。最稳妥的做法是给提示词加“总字数控制在 X 字以内”的硬约束。另外如果你拖动了推送内容里的 Markdown 格式注意 Server 酱和企业微信机器人对 Markdown 的支持程度不同。Server 酱对 Markdown 支持较好企业微信机器人的 text 类型只支持纯文本如果你直接投 Markdown 符号对方会看到一坨#和**。团队版推纯文本个人版可用 Markdown。4.4 Agent 偶尔“上头”连续多天推同一则旧闻这是个很有意思的坑。Agent 在抓取信息时有时候会把几天前的旧文当作“值得关注”重新推送导致连续几天日报里出现同一条资讯。我在 Rule 里加了这样一条“资讯的时间标准是今天或昨天更早的资讯只允许在重大事件的后续进展语境下出现。”加了时间约束之后这个现象基本消失。你也可以在提示词里要求 Agent 关注“每条资讯的发布日期”如果信息源本身没有日期字段就让 Agent 先尝试从正文中提取时间信息。常见问题速查表症状可能原因解决路径任务没触发时区解析错误检查环境时区调整 cron 表达式对应时间任务触发但没推送SendKey 过期 / 机器人被移除重新获取 token更新 Skill 配置推送内容被截断单条消息超长加字数约束或拆成多条消息发送内容重复率高多源转载Agent 未去重增加去重规则和“已收录事件清单”连续推旧闻时间识别缺失在 Rule 里加资讯时间窗口约束日报分类混乱提示词缺少输出框架在提示词里写死固定板块不自由发挥5. 从一个日报到一整套自动化工位Agent 的规则复用带来的杠杆效应日报跑通之后我最大的感受是这套东西的边际成本很低而且越用越顺手。因为 WorkBuddy 的规则、Agent 和 Skill 都是可复用的日报只是第一个吃螃蟹的任务。我随后加了两个自动化任务。一个是“每周 AI 产品复盘”周日晚七点自动运行让 Agent 把本周新发布的 AI 产品按类型整理成一份清单输出它们的核心功能、目标用户、和我已有项目的关联度。这个任务的 Agent 和日报共用了同一个“信息获取 Skill”只是系统提示词和输出模板不同。另一个是“竞品动态监控”针对特定几个竞品和开源项目一旦检测到版本更新、公告发布或 GitHub Star 数显著变化就推送一条提醒到团队群。它的信息源比日报窄得多因此可以设定更高的检查频率每六小时一次。这些任务能快速搭建核心原因是当初建日报时沉淀下来的三样东西信息获取 Skill、消息推送 Skill、以及那几条全局 Rule。每次新任务只需新建 Agent 写输出模板不需要重新接工具、重新设推送。如果要说后续还能怎么扩我计划让日报增加一层“行动建议”让 Agent 不只告诉我发生了什么还自动判断哪些信息值得我实际去调研或跟进把日报从“信息汇总”变成一个轻量级的决策辅助工具。最后说点个人体会。这套日报系统跑了一个多月最大的收益不是省了那每天早上二十分钟的时间而是它改变了我获取信息的节奏。以前刷信息流是被动的、碎片化的、容易被情绪带偏的现在有了定时推送的日报我每天在固定时间点做一次集中输入而且是经过筛选和整理的输入。至于自动化能做到什么程度我的真实感受是它最适合的是“有明确格式、有明确边际、不需要临时判断太多”的任务像资讯整理这种业务逻辑稳定但操作繁琐的是最理想的自动化对象。如果一个任务连你自己都说不清模板那先不要急着自动化先把模板想清楚再说。