说实话，搞这套自动化系统，完全是因为我快被信息淹死了。技术圈geng新太快，每天刷GitHub、刷博客、刷邮件，根本刷不过来。你懂的，信息多是好事，但问题是你根本没时间一个个kan。我关注了20多个技术博客，GitHub上也follow了好几个项目，但每次有新版本、新文章，我dou是后知后觉。害，太被动了。

我受够了。于是我决定搞个AI版技术秘书，每天帮我过滤噪音、提炼重点。说白了就是搞个AI Agent，7×24小时帮我盯着技术动态、邮件、服务状态，然后把关键信息推到微信上。这样，我手机一响，就知道今天该关注啥、该处理啥。

这套系统跑在WSL2上，用的是Hermes Agent这个开源框架。为啥选它？因为它轻量、本地跑、代码全开源，而且支持微信推送。咱就是说这玩意儿简直是懒人福音。

下面我来带你kankan，我是怎么一步步搭起来的。中间踩了5个大坑，每个dou让我浪费了半天到两天不等。但跑通之后效果是真的香。

四个自动化任务，从刚需到惊喜 任务1：企业邮件实时监控

我Outlook每天收50+封邮件，其中70%是系统通知、Jirageng新、CI/CD构建结果。真正需要我处理的人类邮件每天大概15封，混在里面hen难找。我搞了个脚本，每15分钟检查一次只有人类邮件才推送到微信。从每天被打断20次降到真正需要处理时才收到通知。

这个任务的核心是用Microsoft Graph API读邮件，然后用AI过滤掉系统通知。代码里我用了Device Code Flow认证，不需要管理员审批，自己就Neng跑。不过这个认证方式有个坑，后面我会说。

任务2：自动生成工作日报

写日报是我Zui讨厌的事。每天18:00要花15-20分钟回忆今天干了啥，然后组织语言。既然邮件记录了我的大部分工作，为什么不AI自动生成？

每天18:00，系统会分析当天邮件，用AI出工作要点，然后推送到微信。准确率大约85%，有时候会漏掉口头沟通的工作，但对于一个自动生成的日报来说Yi经henNeng打了。

任务3：服务健康监控

我搭了好几个定时任务和Web服务，但有一次某个服务挂了整整两天我才发现——因为它不会主动告诉你它挂了只有用到的时候才报错。我需要一个"监控的监控"。

这个脚本跑了一个月，帮我提前发现了两次WSL内存不足导致的服务假死。有了它我才放心地把其他自动化任务全权交给系统跑。

任务4：技术动态追踪

技术圈信息爆炸，我关注了20多个技术博客和GitHub项目，但经常错过重要geng新。尤其是GitHub上关注的仓库发新版本了或者常kan的博客出了深度文章，靠手动刷根本刷不过来。

每天早上9点，微信收到一份精炼的技术动态摘要。再也不会错过Next.js大版本geng新或者关注博主的新文章了。AI帮我把20+信息源压缩成3-5条要点，阅读时间从30分钟降到了2分钟。

系统架构

核心就三层：WSL2跑Agent → Agent调度Python脚本 → 脚本把结果推送到微信/飞书。

WSL2的好处是它Neng无缝共享Windows的网络和文件系统，同时提供完整的Linux开发环境。我选择它，是因为公司电脑是Windows，直接用Linux虚拟机太重了。

踩坑实录

上面讲的dou是跑通后的样子。实际上，这套系统我前前后后折腾了两周，踩了5个大坑。每个坑dou让我浪费了半天到两天不等。

坑1：邮件认证失败

现象：Microsoft Graph API认证一直失败，报 AADSTS650053: The app is not pre-authorized。

原因：公司Azure AD管理员限制了普通用户注册应用，只允许管理员创建的App Registration。微软文档示例里用的Graph API Explorer的Client ID在我们环境不可用。

解决方案：使用Office的公共客户端ID，配合Device Code Flow：

OFFICE_CLIENT_ID = "d3590ed6-52b3-4351-aeff-aad2292ab01c"
app = msal.PublicClientApplication(
    OFFICE_CLIENT_ID,
    authority="https://login.microsoftonline.com/common"
)
flow = app.initiate_device_flow

坑2：WSL重启后任务停止

现象：WSL重启后定时生成文章的任务突然停止工作。

原因：我把系列文章的计划文件存在了 /tmp/article-series-plan.md。WSL重启后 /tmp 被清空，计划文件没了依赖这个文件的后续任务全部失败。

解决方案：所有持久化数据迁移到 ~/.hermes/data/ 目录。

DATA_DIR = Path.home / ".hermes" / "data"
DATA_DIR.mkdir
PLAN_FILE = DATA_DIR / "article-series-plan.md"

这条规则现在刻在我的DNA里：持久化数据绝对不进 /tmp。

坑3：微信推送失败

现象：cron任务日志显示一切正常执行，但微信始终没收到任何消息。任务跑了好几天我完全没收到报告，还以为系统在工作。直到某天手动检查日志才发现报错。

原因：错误信息是 Timeout context manager should be used inside a task。这是因为cron任务的执行上下文和异步消息投递的event loop冲突了。cron在同步线程里执行，而微信通道投递需要async上下文。

解决方案：

# 错误写法 - cron线程里直接调用
def cron_job:
    hermes_send_weixin  # 💥 TimeoutError
# 正确写法 - 用asyncio包装
import asyncio
def cron_job:
    asyncio.run)

这个坑教会我一件事：定时任务"执行成功"和"消息送达"是两回事。一定要加监控确认。

坑4：Zscaler代理拦截

现象：在公司的Windows上Neng正常访问的网站，在WSL里全部超时。GitHub raw内容、Google、DuckDuckGo全部403或连接超时。

原因：公司网络走Zscaler安全代理，WSL的网络栈和Windows的代理配置不互通。

解决方案：

# ~/.bashrc 添加代理配置
export http_proxy="http://your-company-proxy:port"
export https_proxy="http://your-company-proxy:port"
export no_proxy="localhost,127.0.0.1,.internal.company.com"
# Ru果不想全局走代理，Ke以只对特定域名配置：
export no_proxy="*"
# 在Python脚本里按需使用代理
proxies = {"https": "http://company-proxy:port"} 
requests.get

坑5：WSL中文字体缺失

现象：用Playwright截图时所有中文dou是方块 □□□□。

原因：WSL默认没有安装中文字体。

解决方案：一行命令搞定：

sudo apt update && sudo apt install -y fonts-wqy-zenhei
# 安装后清除Playwright字体缓存
rm -rf ~/.cache/ms-playwright/

和思考

这套系统跑了一个月，Zui大的感受是：自动化不是省时间，是省注意力。省下的时间你可Neng又去刷手机了但省下的注意力是实打实的——我现在Neng连续写2小时代码不被打扰，这在以前是不可Neng的。

但也有明显的局限性：

单点故障风险高。整个系统跑在一台WSL上，Windowsgeng新重启WSL就全挂了。生产级方案应该跑在独立服务器上，配合systemdZuo进程守护。

邮件监控覆盖率有限。目前只Nengkan到邮件，微信、飞书、Slack里的沟通记录是盲区。Ru果Neng接入飞书消息APIZuo统一的"工作流感知层"，会强hen多。

安全边界需要明确。企业邮件数据走本地，不上传第三方，这个底线不Neng破。

下一步计划：给这套系统加一个异常告警机制——Ru果某个定时任务连续3次执行失败，通过飞书机器人告警。毕竟"跑了好几天发现消息根本没发出去"这种事，我再也不想经历了。

📌 关注我，「AI工具提效实战指南」系列持续geng新。下一篇聊聊：AI编程的真实效率到底提升了多少？我用数据说话。

---