AI Agent定时任务实战：打造自动推送微信的个人日报系统

我最近把手机里三十多个公众号和七八个资讯App精简成了一道工序每天上午十点半微信会准点收到一份整理好的AI日报。这不是什么新闻订阅插件的效果是我给 WorkBuddy 设了个闹钟——一个定时跑起来的任务链让 AI Agent 自动完成信息搜集、筛选、摘要生成最后推送到微信。整个流程跑通之后我每天早上不用再刷几十个页面一杯咖啡的时间就能看完当天值得关注的内容。这篇东西不是讲理论是一份可以照抄的实操记录。我会把定时触发怎么设、日报内容怎么让 AI 产出真正有用的信息、以及最终如何安全合规地把内容送进微信聊天气泡一步步拆开讲清楚。如果你也在用 WorkBuddy 这一类 AI 代理工具做自动化任务或者正打算把某个信息流整理成定时推送这篇应该能帮你少走不少弯路。1. 为什么需要给 AI 设闹钟从主动刷信息到被动收日报先说一个真实场景。我做技术产品相关的工作每天需要追踪的最新动态包括大模型发布、AI Agent 框架更新、开源项目进展、还有几家核心机构的论文和博客。过去我的早晨是这样的先刷一遍 Twitter 时间线再看几个知识星球然后打开微信公众号列表挨个点开标题判断要不要读最后还得抽时间看一眼 arXiv 有没有相关新论文。这套流程下来少则四十分钟多则一个半小时。而且最难受的不是花时间是刷完之后经常发现真正重要的两条信息还是从别人的转发里看到的。我的核心需求其实很简单让信息来找我而不是我去追信息。市面上有没有现成方案有但都不够满意。邮件订阅类的 Newsletter 是通用编辑帮你挑不够贴合我的关注方向RSS 阅读器需要自己维护源而且仍然是你打开它才更新的主动获取逻辑微信里的公众号和社群更不用说了信息碎片化严重有效浓度太低。我需要的是一个能理解我关注方向、每天自动执行、并且把结果直接送达的消息推送——这恰恰是 AI Agent 擅长的事情。于是我把目标定为用 WorkBuddy 设定一套任务规则每天上午十点半自动生成一份 AI 日报并发到微信。我只需要打开微信点开一个置顶对话框就行跟读一条普通消息的体验没有区别但内容是一份经过筛选和组织的技术情报。这个方案的本质是把信息获取这件事从人力驱动切换成了任务驱动。人只负责定义规则——关注哪些源、筛什么内容、格式什么样、几点推送——剩下的执行全交给 Agent。后面所有步骤都是围绕这个任务化过程展开的。2. 先搞懂 WorkBuddy 能干什么不是聊天框是个能编排任务的 Agent接触过 WorkBuddy 或者同类产品的朋友应该有个直觉它看起来就是个对话式 AI问一句答一句。但真正拉开差距的地方在于WorkBuddy 的底层执行逻辑不是单轮问答而是任务编排。你可以给它一个包含复杂目标的指令它会自己拆解成多个子步骤按顺序调用工具最终交付一个完整结果。用生活里的例子类比普通聊天 AI 像个只会回答问题的实习生你问一句他答一句从来不会主动往下做而 WorkBuddy 在配置好之后更像一个领了任务就自己去跑流程的老员工——先查资料、再做筛选、然后写摘要、最后把结果放到你指定的位置。你只需要在开头交代清楚目标和约束后面就不用管了。我之前在实际使用里总结过WorkBuddy 有三层能力值得关注工具调用它能调用搜索、网页抓取、代码执行等外部工具不是只靠训练数据里的旧信息回答。这对日报类任务是最重要的基础能力否则内容时效性根本保证不了。上下文管理多步任务之间能保持上下文连贯。比如第一轮先确定当天有哪些重要发布第二轮针对这些发布做深入摘要它能记住第一轮的产出不会各说各话。规则持久化这一点特别关键。你可以给它定几条长期生效的规则比如所有推送类任务都用同一种消息格式遇到付费内容跳过不引用这些规则会沉淀下来影响后续所有任务。我的日报任务充分利用了这三层能力。信息搜集靠工具调用生成摘要靠上下文管理而稳定的输出格式、推送渠道这些偏好则靠规则固化。如果你也在规划类似的定时任务我的建议是先别急着设计复杂的流程花两天时间把 WorkBuddy 的对话式用法摸熟喂它几个任务让它跑跑看感受它拆解问题的方式。它会怎么规划子步骤、会不会自作主张、在哪些地方容易理解偏差——这些观察会直接影响你后面写任务指令的细致程度。3. 给 WorkBuddy 上闹钟定时触发机制的三种实现路径任务本身设计好了接下来要解决的是谁在十点半喊它起床。这里有三条路我挨个测试过各有优劣直接说结论。方案一用全局规则让 Agent 自持一个定时循环。理论上可以让 WorkBuddy 记住每天上午十点半执行日报任务这条规则让它自己到点开跑。但实际跑下来这个方案只适合 WorkBuddy 的客户端保持常开、网络稳定、且 Agent 的调度机制足够可靠的场景。一旦客户端关闭或者休眠这个闹钟就跟着睡了。我个人的经验是不要把关键任务的定时器押在客户端常驻上风险太大。方案二外部服务器定时触发 WorkBuddy 任务接口。这是我现在用的方案也是推荐大家优先考虑的。核心思路是WorkBuddy 只负责干活搜集信息、生成摘要到点叫我这件事交给一个外部定时器——比如你手头的一台小服务器、家里的 NAS甚至一个云函数。用 cron 表达式设定时间到点后通过 WorkBuddy 提供的任务触发接口启动预设任务。方案三用第三方自动化平台做联动。如果你本身在用 n8n、Zapier、Make 这类自动化工具也可以在上面配一个 Schedule 触发器到点调用 WorkBuddy 的接口。这条路的好处是不需要自己维护服务器坏处是等于多引入了一层依赖问题排查链路会变长。我最终选了方案二最核心的原因是解耦两个字。定时器和执行器分开定时器挂了不影响 WorkBuddy 本身的使用反过来 WorkBuddy 如果偶发执行失败我也只需要重新触发一次任务不用去动定时配置。下面是我实际在服务器上用的 cron 配置如果你也用 cron 做定时触发可以直接参考# 每天上午 10:25 触发日报生成任务留 5 分钟缓冲10:30 推送 25 10 * * * /usr/local/bin/workbuddy-cli trigger daily-report /var/log/workbuddy-daily.log 21几个细节值得注意为什么定在 10:25 而不是 10:30给任务留出缓冲时间。信息采集和摘要生成可能耗时三到五分钟触发定在 25 分正好让日报在 30 分前后完成推送。日志一定要落盘。自动化任务最怕无声失败没有日志你都不知道它是没触发还是触发了没跑完。我现在所有定时任务都会把标准输出和错误输出重定向到文件里。时区和环境变量要显式声明。cron 运行时的 PATH 和你在终端里手动执行时的 PATH 往往不一样直接导致命令找不到或者 Python 模块导入失败。我踩过一次这个坑后面学乖了cron 脚本里开头就写清楚环境。如果你手边暂时没有服务器还有一个更轻量的办法本地电脑开机时用系统自带的定时任务工具macOS 的 launchd 或 Windows 的任务计划程序在每天十点半触发一次。前提是那台电脑每天那个点处于开机状态。我一开始就是拿家里一台旧笔记本这么干跑通的后来稳定性要求高了才迁到服务器上。4. 日报内容生成的关键信息源清单和筛选逻辑比提示词更重要闹钟响了任务跑起来了真正的重头戏才刚开始——日报内容的质量。很多人以为这一类任务只要写一段帮我总结今天 AI 圈的重要消息的提示词就完事了实际远远不够。大模型擅长的是组织和表达它不擅长判断什么对你重要。这个判断标准必须由你来定义而且定义得越具体日报质量越高。我把日报任务拆成四个环节来设计采集、过滤、聚合、格式化。4.1 信息源清单先定源头再谈筛选日报的第一层关键不是模型而是信息源清单。WorkBuddy 去哪些地方取信息直接决定日报的上限。我的清单是这么列的来源类型具体源提供的信息价值官方发布渠道几家核心 AI 公司的官方博客和产品发布页新品、模型版本更新、定价变化论文预印本arXiv 的相关分类订阅技术前沿学术突破高质量技术社区几个我长期信任的英文技术资讯站综述、深度分析、行业评论开源项目动态GitHub Trending 和自己 star 过的仓库工具链迭代、社区活跃度个人偏好补充我维护的一份博客订阅列表平时沉淀的业内人士观点有了这个清单以后WorkBuddy 每天就只盯着这些源转不会漫无目的地全网乱扫。这一步的价值被严重低估——信息源的质量某种程度上决定了日报的天花板提示词只是保证它能达到这个天花板的工具。4.2 过滤逻辑让 AI 做语义相关性判断而不是简单关键词匹配信息源铺开以后返回的原始信息量依旧很大尤其 arXiv 每天新增的论文数量相当可观。如果靠传统的关键词过滤很容易漏掉那些题目里没有关键词但内容相关的文章。这里 WorkBuddy 的优势就体现出来了它可以交给大模型做语义级判断。我在任务指令里给定了一个相关性定义类似这样核心相关与 AI Agent、工作流自动化、大模型应用直接相关的内容边缘相关AI 基础设施建设、芯片算力动态、开源许可争议这类偶尔收进来作为背景无关内容纯商业八卦、非技术向的 AI 政策评论一律丢弃实际跑下来语义过滤的效果比关键词匹配高不少。有一回某团队发布了一个不太起眼的机器人框架更新光看标题完全不觉得跟自己有关系但模型识别出该框架支持我们常用的那个编排协议直接放进了头条摘要——这种判断力用传统规则很难写出来。4.3 生成模板给 Agent 硬性约束输出结构日报要让每天快速读完成为可能稳定结构比文采重要得多。我给 WorkBuddy 固化了一张输出模板每天严格按照这个结构来# AI 日报 - 2025年X月X日 ## 今日要闻不超过 3 条 每条包含一句话结论 影响分析 原文链接 ## 产品与工具动态不超过 5 条 按我对它们的关注优先级排序附一句话值得关注的理由 ## 值得精读的文章2-3 篇 每篇给一段 200 字以内的摘要说明为什么值得花时间读原文 ## 一句话简报若干条 其余有信息量但优先级低的内容每条不超过 50 字这个模板看起来很朴素但它的核心价值在于约束了信息密度。今日要闻不能超过三条和每条一句话结论这两条硬限制逼着 Agent 在大量信息里做取舍而不是把日报变成一篇什么都往里面塞的长文。推送形式后面会讲模板在李群里渲染出来效果也很干净。4.4 给 WorkBuddy 定规则的实操写法规则怎么落进 WorkBuddy不同版本的产品入口可能不太一样。我用的时候主要是通过两种方式一是直接在会话里用自然语言交代并明确说这是一条长期规则适用于后续所有任务二是如果产品支持配置文件或技能Skill体系把规则写成结构化的配置项。我的建议是把日报任务规则当作一个独立的技能包来维护里面包含信息源清单、相关性定义、模板格式、推送方式。这样改起来方便比如你某天想把某个新博客加进信息源只需要更新这个包不用去翻历史对话。下面是我在规则里写的一段核心指令的简化示意供参考你是我的日报助理。每天早上执行以下流程 1. 依次检查我提供的信息源清单采集过去 24 小时内的新增内容。 2. 按照相关性定义过滤去除无关信息和明显重复的内容。 3. 用我给定的日报模板组织内容注意条数和长度限制。 4. 在内容末尾添加一句今日总结给出你判断的最值得重点关注的方向。 5. 将最终内容通过我的微信推送渠道发出。 规则所有日报必须使用同一模板链接必须保留原文地址不确定的信息不要猜测标注待核实。这些约束看着繁琐但每一句都是在真实使用中长出来的教训。最初我的指令只写了帮我整理一份日报结果第一周出现过好几次把三天前旧闻当新闻放进来的情况。加上过去 24 小时内这个时间窗口约束后问题立刻消失。5. 推送进微信不碰微信数据库的正规路子到了最敏感也最容易翻车的一环内容到底怎么送进微信。网上讨论过很多旁门左道的方法比如逆向协议、数据库读取、自动化机器人登录个人号之类这些方案听着强大但要么有封号风险要么把自己账号置于不安全的位置。我的原则很明确只用官方渠道、正规接口绝不为推送便利去碰不该碰的东西。真正可靠且常用的是下面几种途径按推荐优先级排个序首推企业微信群机器人 Webhook。这是几个方案里最省事也最稳的。你在企业微信里拉一个只有自己的群添加群机器人会得到一个 Webhook 地址。任何人往这个地址发 POST 请求群里的消息栏就会出现一条推送。不需要申请开发者资质不用审核一个群机器人五分钟就能建好。这个方案唯一的限制是每分钟最多 20 条消息——对日报场景绰绰有余。其次微信公众号测试号模板消息。如果你想要的消息形态更接近服务通知可以通过公众号测试号接口给用户推送模板消息。测试号不需要正式注册企业主体个人就能创建但模板消息的格式有严格限制自由排版的空间不大。我现在主要用企业微信方案原因就是模板消息发出来的内容样式太固定了不适合长文本日报。另外可选Server 酱这类推送服务。国内开发者做的消息推送中转服务思路是服务方给你一个专属发送链接你往这个链接 POST 内容它通过微信服务号模板消息转给你。优点是接入简单缺点是多了一层依赖而且免费档有限流。我自己最终落地的是企业微信群机器人。整个流程只有两步第一步在企业微信里建一个单人群添加一个自定义机器人把生成的 Webhook 地址存下来。第二步在 WorkBuddy 的日报任务末尾加一个推送消息动作把生成的日报内容 POST 到这个 Webhook。下面是核心代码用 Python 写的逻辑很简单import requests import json webhook_url https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的机器人Key def send_markdown_to_wechat(content: str): payload { msgtype: markdown, markdown: { content: content } } resp requests.post( webhook_url, datajson.dumps(payload), headers{Content-Type: application/json} ) resp.raise_for_status() result resp.json() if result.get(errcode) ! 0: raise RuntimeError(f推送失败: {result})企业微信机器人支持 markdown 格式所以我在日报模板里用的那些##标题和链接在手机微信里能直接渲染成层次分明、带可点击超链接的阅读界面。体验比纯文本好很多。几点实操提醒Webhook 地址一定要当密钥保管。任何拿到这个地址的人都能往你的群里发消息所以不要把地址贴到公开仓库或者分享给别人。群里记得关闭机器人消息的免打扰。拉好群之后第一件事是把群置顶同时在消息通知里打开接收消息但不提醒的群消息开关保证只出现红点不强提示不然每到十点半手机就响一次几天下来就烦了。推送失败要能感知。我在代码里对返回的errcode做了判断一旦推送失败就把错误写进日志同时发一条备用通知给邮箱。宁可多用一层备用通道也不要让日报某天悄无声息地消失。6. 从能跑到跑稳我在这个流程里踩过的坑系统跑通只是开始真正花时间的是让它稳定地每天跑。我前后调了两周左右踩了几个典型问题列出来供大家排查时参考。6.1 定时器触发了但任务没有真正启动这是我遇到的第一个问题。cron 日志显示workbuddy-cli trigger执行了但 WorkBuddy 那边完全没有反应。排查链路是这样的先手动在终端跑同一条命令发现能正常触发说明命令本身没问题再对比 cron 环境发现是PATH 里少了一个关键目录导致命令调用时找不到某个可执行文件。这类问题非常典型凡是涉及 cron 的自动化任务第一步先怀疑环境变量。解决方法是所有定时脚本开头显式声明环境#!/bin/bash export PATH/usr/local/bin:/usr/bin:/bin:$PATH export LANGen_US.UTF-86.2 任务跑了一半卡住日报永远停在正在生成这个坑更隐蔽。后来看日志发现WorkBuddy 在调用某个外部搜索工具时偶发超时导致整个任务链中断。单个信息源响应慢了整条流水线就堵住了。我的处理思路是给任务的每个子步骤加超时和重试机制。WorkBuddy 的任务配置里如果支持超时参数直接设置如果不支持就在外层脚本里做一个简单包装检测到任务超时后重新触发一次。同时把信息源按重要性拆分核心源失败时允许降级从必须全部成功改成核心源必须成功次要源允许跳过。这样日报即使偶尔缺少某一块内容也不会整体失败。6.3 推送发出去了但手机上排版错乱有几天收到日报后发现 markdown 链接没有正常渲染代码块样式丢失整篇消息变成了密密麻麻的纯文本。这种问题通常不是接口的问题而是推送内容里混入了不合法的 markdown 语法。比如某些信息源抓回来的原文标题里带着特殊字符直接拼进日报内容就把整个格式破坏了。解决方式是加一道消毒环节在推送之前对生成内容做一次格式检查把容易出问题的特殊字符替换掉并去掉不规则的空格和换行。我把这个处理逻辑直接并入了推送脚本每天发送之前自动跑一遍之后就没再出现排版问题。6.4 内容太干模型筛选出的信息跟我的需求有偏差这个不算程序错误而是使用方式问题。前几天的日报确实每天都有内容但总觉得隔靴搔痒真正想知道的东西没出现在头条。后来我反思了一下问题出在相关性定义写得不够精细。我给信息源里加了我自己长期关注的技术方向甚至在相关性定义里直接写上了几个我更在意的细分主题词。迭代了几轮之后日报的内容命中率明显不一样。提示词和规则是要反复打磨的第一版跑通只是起跑线。另外有件事要特别提醒不要把生成和推送绑定得太紧。我开始时是任务一结束立刻推送结果有两次生成内容因为半夜临时加塞的新消息变得过时。后来我把流程改成生成→人工抽查可选→推送三段式。如果出门在外不方便抽查就设置一个置信度阈值Agent 自己判断没有明显异常就直接发出如果在家办公我可以先扫一眼再放行。这套机制下来日报的容错空间大了很多。7. 这套AI 日报还能扩展成什么我看到的三层进阶玩法日报跑稳之后我很快意识到这套框架的本质不是每天一份报告而是一条定时任务驱动的 AI 内容流水线。把输入换一换、输出换一换它就能变成完全不同的东西。第一层扩展是换内容方向。日报的信息源和相关性定义改一改就可以做竞品监控日报、行业政策追踪、甚至某个小众技术方向的周报。我后来额外加了一个每周技术周报任务把一周内的日报自动汇总、去重、提炼成更精练的深度复盘。这样从日到周有了天然的层级结构。第二层扩展是加上人工反馈闭环。我现在每天的日报末尾会自动附一行今日最有用/最没用的内容是哪条我在微信里随手回复这个数字WorkBuddy 能读到我的反馈第二天的筛选权重就会向我喜欢的方向偏移。这其实就是最简单的推荐系统闭环——用户的反馈进入模型模型调整策略输出更贴合个人的内容。虽然没有你刷短视频那种千人千面做得精密但对我来说已经够用了。第三层扩展是从看新闻变成等任务完成。这句话可能有点抽象举个例子我有个需求是每天早上醒来看到我关注的 GitHub 仓库有没有出现值得跟进的新 issue 或 PR 讨论。这套定时任务框架可以做同样的事情——定时抓 GitHub 动态让 AI 判断优先级把真正需要我处理的项推送过来。本质上它已经不是信息日报而是AI 替我盯盘只把重要的事递给我的助理模式。想折腾的朋友还可以尝试给多个定时任务之间建立依赖关系比如先跑数据采集任务成功后再触发日报生成或者接上团队的知识库让日报内容直接从内部文档和外部信息流里共同提炼。这些玩法都是在同一套定时 Agent 推送的基本盘上做加法越到后面你会发现最耗精力的永远不是技术搭建而是定义清楚什么对我是重要的。我在把这个流程跑稳定之后最大的感受是这类自动化的真正门槛不在工具会不会用而在你敢不敢把一部分每天亲手做的判断交出去。信息源清单、相关性规则、模板约束、反馈机制——这些东西沉淀下来以后不仅每天省了四五十分钟的刷信息时间更重要的是我收到的信息颗粒度和相关性比我自己漫无目的地刷要高得多。建议你从一个小闭环开始尝试哪怕是每天下午六点给我推送三条今日大模型相关论文这样最小化的需求跑起来之后你自然会知道下一步往哪里进化。