Agent 实战三部曲 · 第3篇
摘要：开源库每天几十条 issue，以前我每天泡两小时打标签写初评。现在全交给 Agent，十分钟扫一眼就发。完整项目直接能抄——结构、配置、主循环、4 个真踩过的坑，换个仓库名就能跑。
大家好，我是程序猿Joe。
先说个数字：每天两小时。这是我以前泡在 GitHub issue 列表里的时间——一条条看、打标签、写初评，像上班打卡一样准时。
我们团队的开源库每天新增几十条 issue，bug、需求、“怎么配环境”、还有那种一句话里塞了三个问题的。你懂这种感受吧？明明手头有一堆正事要干，却得先当半个客服把 issue 清完。
后来我做了个 Agent 替我干这事。它读 issue、分类、打标签、写初评，全程自动。我把初稿扫一眼确认，十分钟结束。
这篇文章不是 PPT 架构吹水，是我真在用的项目，代码能跑。完整结构、配置、主循环，还有四个只有真上手才会踩到的坑，全摊开给你。改个仓库名和标签映射就能搬走。
先画个边界：Agent 只负责读和写评，最后一步"发 Slack 通知相关人"必须我手动确认。原因很简单——写操作和对外发送是危险动作，我不放心全自动。这个教训后面第四个坑会细说。
一、为什么从 Issue 分诊下手
没选别的场景，三个原因：
第一，够真实。不是
