WorkBuddy+企业微信机器人+crontab：搭建每日AI日报自动推送

每天早上十点半我手机微信里会准时弹出一条消息一份已经整理好的 AI 日报。从热点资讯到值得细读的几篇文章再到一句总结性的速评全部由 WorkBuddy 自动生成、自动推送——这个流程我已经稳定跑了三个多月中间只手动干预过两次。今天把整个配置过程、踩过的坑和最终方案完整写出来给也想让 AI 按时“上班”的朋友一个可以直接抄作业的参考。这套东西解决的是我自己的一个真实痛点以前每天早上到公司第一件事是打开十几个网页、公众号、资讯 App花二三十分钟翻完再手动整理一份发给团队。后来我想这类“收集信息 提炼摘要 固定格式输出”的活儿本质上就是 AI 最擅长的任务编排。于是我用 WorkBuddy 搭了一个专用的日报 Agent又用企业微信群机器人解决了“怎么把内容送进微信”的问题最后用系统定时任务让它每天十点半准点执行。整个过程不需要自己写爬虫不需要维护网页解析规则本地也不需要常驻任何界面程序。如果你手里有 WorkBuddy 或者类似的 AI Agent 工具跟着下面这套思路走一遍基本能复刻出一模一样的每日推送。重点我会放在 Skill 怎么写、微信推送怎么接、定时任务怎么做到“不跑丢、不重跑、报错能查”这三件事上。1. 为什么是 WorkBuddy一个能“自己干活”的 AI 工作台1.1 它和普通聊天机器人的本质区别很多人第一次接触 WorkBuddy 时会把它当成又一个“对话式 AI”问一句答一句。实际用下来会发现它更像一个能自己安排工作流程的智能体工作台。聊天机器人是“你提问它回答”WorkBuddy 是“你布置任务它自己拆解、调用工具、完成任务、输出结果”。这个区别在做日报这种自动化场景里非常关键。我打个比方聊天机器人像一台问答机你投硬币进去它才说一句话WorkBuddy 更像一个助理你告诉它“每天早上把行业动态整理成简报发我”它就会自己规划先干什么、后干什么。它内部可以定义多个 Skill每个 Skill 是一套完整的“岗位说明书 工具箱”。比如做日报我需要一个“抓取资讯的 Skill”、一个“生成摘要的 Skill”、一个“发送微信消息的 Skill”WorkBuddy 会把它们按顺序执行中间的数据流自己串起来。这也是我建议别把它当成普通聊天工具用的原因。它真正值钱的地方在于任务编排能力你可以把一个重复性工作拆成若干步骤写清楚每步的输入输出然后让它在固定时间自己跑完。日报只是一个例子同样的思路还能做晚间复盘、周报汇总、竞品监控、股票盯盘之后的简报等等。1.2 日报这件事为什么值得交给它先说我以前的方案这样你更能理解为什么最后选 WorkBuddy。最初我做日报用的是“爬虫 模板”的老路子写 Python 脚本抓几个资讯站的 RSS再用字符串模板拼成一段文字最后调用推送接口发出来。这套方案的问题很现实——信息源一改版解析规则就崩RSS 不全的时候内容质量参差不齐更尴尬的是它只会“搬运”不会“总结”所谓日报就是一堆标题堆在一起读者看两行就不想看了。换成 WorkBuddy 之后日报的逻辑变成了三层收集、理解、表达。收集还是靠工具抓取但理解和表达交给了大模型。比如同一个新闻脚本方案只能把标题原样贴出来WorkBuddy 能读懂正文后告诉你“这条为什么重要”“对做 AI 的人有什么参考意义”。输出也不再是死板的标题列表而是像人写的内容简报。这正是我想要的日报形态。热词里经常看到 WorkBuddy 和 CodeBuddy 混在一起讨论。简单区分一下CodeBuddy 更偏向写代码场景的辅助WorkBuddy 则是一个通用的 AI 智能体工作台适合做各种自动化任务和日常工作流编排。我做日报用的是 WorkBuddy 的通用能力不涉及写代码业务所以下面内容也都围绕 WorkBuddy 展开。2. 环境准备装好 WorkBuddy 并建一个专属 Agent2.1 安装与基本配置WorkBuddy 支持桌面版和命令行版本两种形态。我的选择是直接装在服务器上的命令行版本理由很简单定时任务需要机器在固定时间开机运行我不能指望自己的电脑每天早上都开着、还要保持 WorkBuddy 界面常驻。服务器天然满足这个条件配合系统定时任务最省心。安装流程不复杂大致三步# 1. 从官方 release 页下载对应平台的压缩包放到 /opt/workbuddy 下 # 2. 解压后把二进制放到 PATH 里 sudo ln -s /opt/workbuddy/wb /usr/local/bin/wb # 3. 初始化配置目录 wb init安装包的下载地址和版本号迭代比较快网上搜索“WorkBuddy 安装教程”也能找到很多版本记录这里不贴死链接直接以官方仓库 release 页为准。初始化完成后会在你的用户目录下生成一个配置文件里面主要需要填两块内容大模型服务的 API 接入信息和默认的工作目录。配置模型服务时我建议用自己的 API Key 而不是依赖产品自带的免费额度。原因有两点一是免费额度一般有频率和上下文限制跑定时任务容易撞上限二是日报任务每天固定跑一次对稳定性要求高独立的 API Key 出了问题也好排查。模型选择上我自己用的是 DeepSeek 和通义千问都试过这两种在国内直接可以调用速度和成本都合适。你完全可以根据自己的偏好换但记得把上下文长度调够——日报抓取的材料加起来可能几千字模型至少需要 8K 以上的上下文才转得开。2.2 创建“日报助手”Agent 时的几个关键参数WorkBuddy 允许你创建多个 Agent每个 Agent 相当于一个专职角色。我建了一个叫daily_report的专用 Agent而不是所有任务都扔给默认 Agent。这么做的原因很朴素一个 Agent 的技能和指令集太杂容易互相干扰。专号专用排查问题时思路也清晰。创建时几个参数值得留意工作目录单独建一个/data/workbuddy/daily_report/用来放 Skill 文件、中间产物和执行日志。目录独立后面做备份和排查会非常方便。执行超时我设成了 120 秒。日报任务需要抓取多个信息源再让模型生成摘要太短容易跑到一半断掉太长又会让失败任务拖很久。重试次数建议设 2 次。网络抓取偶尔会抖动允许重试能显著降低失败率。创建 Agent 之后可以先手动跟它对话测试一下。比如问“你能做什么”确认它的基础响应正常再进入下一步写 Skill。这里提醒一句不用急着把所有配置一步到位先让 Agent 能跑起来后面逐步完善。很多人在配置阶段就花了大量时间调参数其实没必要——那些参数后面的真实任务会告诉你该怎么调。3. 写日报 Skill把“怎么干活”讲清楚3.1 Skill 的目录结构与作用Skill 是 WorkBuddy 里最核心的概念你可以把它理解成一份“岗位说明书 工具箱”。Agent 负责调度Skill 负责定义某个具体任务的执行细节。我的日报任务里Skill 的目录结构长这样daily-report/ ├── SKILL.md ├── prompt.md └── send_wechat.pySKILL.md是技能的清单文件声明这个技能的名字、描述、入口prompt.md是给模型看的指令告诉它“你要生成一份什么样的日报遵循什么格式”send_wechat.py是实际干活的脚本负责把最终日报文本推送进微信。WorkBuddy 在执行这个 Skill 时会先读取SKILL.md然后按照里面的指令调用模型和脚本。把指令和脚本分开是有意的安排prompt.md负责“想”send_wechat.py负责“做”。这样调整日报的措辞风格时只改 prompt不碰代码推送逻辑变了只改脚本不用动模型。以后想把这个 Skill 复用到别的场景也只需要复制整个目录再改名即可。还有一个不算细节的细节Skill 目录最好跟着 Agent 走放在 Agent 的专属工作目录里。WorkBuddy 扫描技能时会优先加载当前 Agent 工作目录下的*.skill目录放错位置会导致“技能识别不到”这种奇怪问题。3.2 一份可直接抄的日报 Skill下面这份是我自己改过多轮的版本你可以直接复制再按需求微调。SKILL.md的内容--- name: daily_report description: 自动收集 AI 行业信息生成日报并推送到微信 version: 1.0.0 --- ## 执行流程 1. 使用内置浏览器工具打开下面这些信息源抓取当天最新内容 - 机器之心 - 量子位 - Hacker News 的 AI 板块 - arXiv 的 cs.AI 分类最新论文标题 2. 对抓取到的内容做去重和筛选保留与 AI 强相关的条目。 3. 调用 LLM 完成摘要生成严格按 prompt.md 中定义的格式输出。 4. 将生成的日报文本交给 send_wechat.py 发送。prompt.md的核心是我反复打磨过的部分你是一位资深的 AI 行业编辑擅长在大量信息中捕捉真正值得关注的动态。 请基于用户提供的信息源内容生成一份中文 AI 日报。 输出必须严格按照以下结构 【今日热点】3-5 条每条用一句话交代事件 为什么值得关注 【值得细读】2-3 条给出文章标题 让你推荐它的理由 【一句话速评】对当天趋势的直觉判断不超过 50 字 要求 - 语言简洁禁止使用感叹号和营销词汇 - 判断“值得”时优先考虑对从业者的实际价值而不是新闻热度 - 如果信息不足直接说“今日暂无推荐”不要编造最后两行非常重要。加“禁止使用感叹号和营销词汇”是因为 AI 生成内容天然喜欢夸大其词不加约束的日报读起来像广告推送加“信息不足就写暂无”是为了避免模型在抓取失败时硬编内容。这两行字帮我避免了大量垃圾日报。send_wechat.py的内容我会在下一节推送通道的部分一起讲因为它和微信 Webhook 的配置强相关。3.3 跑通一次手动测试Skill 写完之后先别急着配定时任务先手动跑两遍确认输出质量。我的做法是进入 Agent 工作目录后执行wb run daily_report /tmp/daily_report_first_run.log 21 cat /tmp/daily_report_first_run.log第一次跑完你应该能看到两类结果要么是完整的日报正文要么是某个环节的报错提示。对于日报抓取类任务最常见的第一次错误是某个信息源访问超时或者网页结构变化导致抓不到内容。这些都不需要慌看日志定位到具体步骤对症调整就行。手动测试还有一个好处——趁这个机会调 prompt。把生成的日报从头读一遍看哪些地方像“机器人写的”哪些地方判断让你失望然后把意见反馈到 prompt.md 里。这个迭代过程至少做两轮等你自己满意了再谈自动化。我自己的经验是日报的质量天花板在 prompt不在模型。4. 微信推送不写一行界面代码把日报送到手机4.1 推送方案怎么选日报生成之后剩下的问题是怎么送进微信。这里其实没太多神秘的东西思路就是在“能调用的推送接口”里找一个微信生态内、合规稳定、个人也能用的。我对比过几个常见方案方案成本稳定性说明企业微信群机器人免费很稳用 Webhook 发消息个人可注册企业微信实现微信公众号测试号免费较稳需要配置 AppID/Secret模板消息体验一般第三方推送服务通常免费额度有限看服务商少一层自己维护成本但多一个中间环节我最终选了企业微信群机器人。注册一个企业微信、建一个只有自己的群、添加群机器人就能拿到一个 Webhook 地址发送消息只靠一个普通的 HTTPS POST 请求。整个过程不需要审核不需要小程序开发也不需要任何微信私有接口完全走官方公开能力合规这一点让人放心。顺便说一句网上总有人问“企业微信多开会会不会封号”之类的问题其实正常用途完全不用担心这类操作风控关注的是异常高频或群发营销行为。我们这种每天一次、发给自己群的技术日报离触发风控差着十万八千里。4.2 企业微信群机器人接入步骤创建机器人的步骤很直接我拆成四步注册企业微信并创建一个企业。个人用户用手机号就能注册不需要营业执照注册后会有一个自己的企业。在企业微信里创建一个群聊。哪怕只有你一个人也可以建群这个群就是日报的收件箱。在群里添加“群机器人”。进入群聊 → 右上角设置 → 群机器人 → 添加机器人给它起名叫“AI 日报助手”。复制 Webhook 地址。地址形如https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx这个地址就是你的日报入口。拿到 Webhook 后可以用最简单的curl先试一条消息确认通道是通的curl -s https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key \ -H Content-Type: application/json \ -d { msgtype: text, text: {content: 日报通道测试} }如果群里立刻收到“日报通道测试”说明通道没问题可以把地址写进send_wechat.py。4.3 在 WorkBuddy 里调用发送脚本推送脚本我用的 Python标准库就能实现不依赖第三方包这样在干净环境里也不会因为缺库跑不起来。脚本内容如下#!/usr/bin/env python3 import json import sys import urllib.request WEBHOOK https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key def send_markdown(content): data { msgtype: markdown, markdown: {content: content} } req urllib.request.Request( WEBHOOK, datajson.dumps(data).encode(utf-8), headers{Content-Type: application/json} ) with urllib.request.urlopen(req, timeout10) as resp: result json.loads(resp.read().decode(utf-8)) if result.get(errcode, -1) ! 0: raise RuntimeError(f微信推送失败: {result}) if __name__ __main__: content sys.stdin.read() send_markdown(content) print(push ok)脚本从标准输入读取日报正文以 markdown 消息类型发送。企业微信群机器人的 markdown 消息支持基础语法日报里的**【今日热点】**这类标题格式刚好能用上读起来比纯文本利索不少。这个脚本需要放在 Skill 目录里并且在SKILL.md中注明“最后一步调用send_wechat.py把日报文本通过标准输入传入”。测试时可以用管道直接把一段内容喂给它echo 测试推送 | python3 send_wechat.py如果微信收到消息整个链路就通了AI 生成日报 → Python 脚本推送 → 微信收到消息。到这里手动版已经可以用了。接下来才是重头戏——让它在每天十点半自己跑起来。5. 定时触发十分钟配置好“十点半闹钟”5.1 两种定时方式的取舍实现定时触发有两条路一条是依赖 WorkBuddy 内部的计划能力如果它提供 schedule 配置的话另一条是直接用系统 crontab 或 Windows 任务计划程序。我最终选了更朴素的系统级 crontab原因有三个不依赖 WorkBuddy 常驻。系统定时器到点直接执行一次命令执行完就退出不占资源。日志更好管。cron 的输出可以重定向到固定文件配合 Linux 的日志轮转机制排查问题非常清晰。通用性强。就算你以后换了别的 Agent 工具这套定时方案依然能继续用。如果你用的机器是 Windows也可以用“任务计划程序”达到同样效果只不过触发器配置换成了图形界面逻辑完全一致。我自己是在 Linux 服务器上操作的所以下面以 crontab 为例。5.2 Cron 表达式与日志处理每天上午十点半对应 cron 表达式是30 10 * * *。五段分别是“分钟 小时 日 月 星期”这个表达式的意思就是“每一天的 10:30”。在服务器上执行crontab -e然后加入这一行30 10 * * * cd /data/workbuddy/daily_report wb run daily_report /var/log/daily_report.log 21特别提醒几个容易出问题的点第一时区。如果服务器是 UTC 时区30 10 * * *会变成北京时间下午六点半。先执行date确认服务器的本地时间是不是你想要的时区。建议直接把服务器时区设为 Asia/Shanghai省得每次换算。第二环境变量。cron 执行时不会加载你登录 shell 的那些环境变量。如果你的 WorkBuddy 配置里有 API Key是放在单独的环境变量文件里的那要在命令前加上source或者通过包装脚本加载。我为了避免这种麻烦直接把 API Key 写进了 WorkBuddy 配置文件的 keyring 方式里这样 cron 启动后也能读到。第三防止任务重入。有时候一个执行还没结束下一个又开始了或者手动执行和定时执行撞车会导致推两条日报。加一个简单的文件锁可以解决30 10 * * * flock -n /tmp/daily_report.lock -c cd /data/workbuddy/daily_report wb run daily_report /var/log/daily_report.log 21flock -n是“拿不到锁就退出”保证同时只有一个日报任务在执行。配完后可以先用一个“两分钟后的时间”做一次真实验证。比如现在 10:27先添加一条29 10 * * *的临时任务等它跑一次确认推送正常后再换回正式的30 10。这比干等一小时有效率得多。5.3 日志至少应该看什么日志文件不是写了就完事还得会看。我的日志习惯是每行记录执行时间和关键步骤比如“开始抓取”“抓取完成 共 12 条”“开始生成摘要”“推送成功”。这样一旦某天没收到日报扫一眼日志就能定位是哪个环节断了。如果哪天发现没收到推送第一件事不是怀疑定时任务而是看日志尾部tail -50 /var/log/daily_report.log正常的日志尾部应该有类似“push ok”的标记。如果日志尾部停在“开始抓取”说明网络阶段出了问题如果停在“开始生成摘要”说明模型调用失败或超时。日志能帮你把问题缩小到具体环节接下来再做针对性排查就快了。6. 稳定运行实录踩过的坑与排查清单6.1 高频问题与解决办法三个月的运行里我整理出一份自己的“高频问题速查表”每次出问题先对照这张表现象原因解决办法没收到日报日志显示推送失败 ercode 45009群机器人频率超限通常一分钟内超过 20 条检查是否有重试脚本反复调用把推送频率降到每分钟一条以内日报内容还是昨天的抓取的信息源走了缓存或者目标站点当天确实没有更新给抓取请求加随机时间戳参数绕过缓存在日报里标注“信息截止时间”cron 到点没反应时区不对或环境变量缺失最常见是 PATH 里找不到 wb 命令在 cron 行使用 wb 的绝对路径例如 /usr/local/bin/wb微信收到的 markdown 格式乱掉日报正文里包含特殊字符被当成语法解析对内容里的#*做转义或者在发送前先做一次纯文本降级处理模型输出过长被微信截断企业微信 markdown 消息有长度限制超长部分会被截掉在 prompt 里加“全文控制在 800 字以内”或在脚本里做长度截断最值得说的是频率限制那个坑。有一次我调试时手动跑了五六次每次推送都成功结果定时任务竟然没推成功。看日志才发现前面手动跑的次数把频控占满了。从那以后我养成了一个习惯调试推送时改用测试专用的 Webhook不占用正式日报的额度。还有一个内容质量问题值得单独说如果你发现某天日报特别水大概率不是模型变笨了而是信息来源抓取不完整。比如某个信息源改版后抓不到正文只剩个标题模型只能拿标题硬写。这时候去检查那个信息源比调 prompt 更有效。6.2 三个让任务更稳的小习惯稳定运行不是配完就一劳永逸的。结合我的实操经验有三个习惯很重要第一在日报里加“生成时间”标记。正文开头加上“生成于 2025-06-XX 10:30”你一眼就能看出这条是不是当天的。如果发现时间不对说明定时任务或时区配置出问题了。这个习惯还能避免把昨天的日报当今天的看。第二信息源要有冗余。我一开始只做了三个信息源后来发现某个源偶尔会连续几天不更新那几天的日报明显单薄。现在我的抓取列表里常备五六个源其中两三个是互补的这样单个站点出问题其他源也能兜住基本盘。第三每周抽空看一眼日志。定时任务这东西就是这样跑顺了没人记得它存在直到某天没跑才想起来。我给自己设了个每周五的提醒花五分钟看一下本周日报的生成记录顺手处理潜在问题。这五分钟帮我避免了很多“等到发现时才想起来它已经坏了三天”的情况。最后再说一点我的体会这套“WorkBuddy 企业微信机器人 crontab”的组合本质上就是一个极轻量的自动化工作流。它不依赖任何复杂的平台或者昂贵的服务所有环节用的都是公开能力和基础工具。我做这套的时候最大的感触是先让流程转起来再谈优化。很多人在第一步就纠结于“我要不要把日报做得像某某媒体那样精致”结果折腾几周还没开始推送。我的建议是先用最简单的版本跑起来哪怕第一版日报只有三条摘要也很香后面按天迭代 prompt 和内容源就行。如果你也想给自己的 WorkBuddy 加个闹钟我建议从“把任务拆成收集、生成、推送三个环节”开始先把每个环节手动跑通再加定时。我下一步准备加一个晚间任务每天晚上九点把第二天的重点会议和待办整理成清单推给自己逻辑和日报一模一样只是 prompt 和触发时间不同。如果你玩出了更有意思的定时 AI 工作流欢迎一起交流。