AI Agent 定时任务怎么避免重复执行：幂等、锁和增长日志
这篇文章拆解我在博客增长运营数字员工里使用的定时任务防重复方法：先检查状态，再用幂等文件、执行锁、Git 差异和增长日志，让 AI Agent 每天稳定产出而不是重复添乱。
当我开始让 AI Agent 每天自动运营 blog.786668.xyz 时，最怕的不是它写得慢，而是它重复执行同一件事：同一个主题连发两篇、同一个文件反复追加、部署失败后又假装成功、Git 里混进无关修改。
定时任务一旦从“手动触发”变成“每天自动跑”，就必须先解决一个基础问题：这次运行到底是不是安全、必要、可验证的？
这篇文章记录我给博客增长运营数字员工设计的最小防重复方案。它不复杂，但能让 Agent 从“会执行命令”升级成“能长期值班的运营同事”。
一、为什么 AI Agent 定时任务容易重复添乱？
人的工作有上下文记忆：昨天刚发过什么、这次为什么要改、哪些文件不能碰。Agent 如果每次只看当前指令，很容易把长期运营做成一次性脚本。
我在博客自动运营里最常见的重复风险有 5 类：
- 主题重复：昨天刚写过“数字员工日志”，今天又写一篇相似标题；
- 文件重复：同一个增长日志被追加多次，但没有区分数据、动作和验证；
- 部署重复：构建失败后仍继续部署，或部署成功但没有生产验证；
- Git 重复：把前一个任务留下的无关改动一起提交；
- 结论重复：没有读到 GSC / Cloudflare 数据，就写成“数据无变化”。
所以定时任务不能只写成：
生成文章 → 构建 → 部署 → 汇报更可靠的流程应该是：
读取计划与状态
↓
检查本次是否已执行 / 是否有冲突
↓
选择一个真实增长动作
↓
构建与生产验证
↓
只提交相关文件
↓
写入增长日志这和我前面写过的 AI Agent 错误处理闭环 是同一套思路：失败不可怕，重复且不可解释才可怕。
二、第一层防线：运行前先读状态
定时任务一启动，我会让 Agent 先读四类状态，而不是直接写文章。
1. 仓库状态
最基本的一步是：
git status --short如果仓库已经有未提交文件，Agent 必须判断这些文件是不是本次任务产生的。不能为了“完成发布”直接 git add .，否则长期下来，仓库会变成多个自动化任务互相污染的地方。
我的规则是：
- 本次只新增文章，就只提交该文章和增长日志；
- 如果发现无关文件，先不提交它；
- 如果无关文件会影响构建，再记录为阻塞，而不是强行修。
2. 文章目录
增长任务不是每天随机选题，而是先看已有内容：
src/content/posts/我会检查最近发布的标题、标签和发布时间。这样可以避免今天刚写“AI Agent 失败复盘”，下一次又写一篇几乎相同的“AI Agent 故障处理”。
更好的做法是把内容缺口分成主题集群：
- 数字员工岗位说明书；
- 定时任务与日志；
- 错误处理与权限边界；
- 内容资产产品化；
- AI 图片 / 视频 / IP 工作流。
每次新增文章时，都要补一个集群缺口，而不是单篇孤岛。
3. 构建状态
在真正改动之前先跑一次构建，可以知道站点当前是否健康：
npm run build如果修改前就构建失败，那么本次增长动作的第一优先级不是写新文章，而是修复站点。因为一个不能构建的博客，再多内容也发布不上去。
4. 生产可访问性
我会检查首页、sitemap 和 robots：
https://blog.786668.xyz/
https://blog.786668.xyz/sitemap-index.xml
https://blog.786668.xyz/robots.txt这一步不是为了做复杂监控，而是确认搜索引擎能看到基础入口。尤其是增长目标是日独立 IP 2000，站点可抓取性比“又多写一篇”更底层。
三、第二层防线：给每次运行一个“幂等判断”
所谓幂等，简单说就是：同一个任务重复运行多次，不应该造成多次副作用。
在内容运营任务里，可以用一个很轻的幂等判断：
日期 + 动作类型 + 目标文件 / URL例如今天的动作是：
2026-05-18 · 新增文章 · ai-agent-scheduled-task-idempotency-lock-growth-log.md如果任务中途失败，下一次重跑时应该先检查这个文件是否已经存在：
- 如果文件不存在：可以继续创建；
- 如果文件存在但未部署：进入构建 / 部署 / 验证阶段；
- 如果文件存在且生产 URL 已可访问：不要再创建同主题文章，只补增长日志或结束；
- 如果文件存在但内容不完整：先修复同一文件，不新建第二篇。
这比“每次都生成新标题”安全得多。
四、第三层防线：执行锁，避免两个任务同时改博客
如果一天有多个定时任务，最怕它们同时操作同一个仓库。比如 9:00 的自动发布还没部署完，9:15 的增长运营又开始写新文章。
一个简单执行锁可以这样设计：
~/.hermes/locks/cloudflare-blog-growth.lock任务开始时：
- 检查锁文件是否存在；
- 如果存在，读取锁里的时间和任务名；
- 如果锁很新，说明另一个任务正在跑，本次退出或只做只读检查；
- 如果锁超过合理时间，比如 30 分钟，记录为陈旧锁，再谨慎接管；
- 任务结束时删除锁。
对个人博客来说，不一定要一开始就写复杂的分布式锁。关键是让 Agent 有“不要同时动同一仓库”的意识。
五、第四层防线：增长日志必须写清楚，不写流水账
增长日志不是为了好看，而是给下一次任务看的上下文。
我希望每条日志都固定包含：
日期
基线 / 数据
执行动作
发布或修改 URL
验证结果
下一步这样下一次 Agent 才知道：
- 今天到底读到了什么数据；
- 如果没读到，是通道受限，还是确实没有变化；
- 本次新增了哪一个可索引资产；
- 生产页是否已经验证；
- 下次应该接着补什么。
尤其要注意：没拿到 GSC / Cloudflare 数据，不等于没有变化。 这两句话在运营上完全不同。
正确写法应该是：
GSC / Cloudflare 数据通道本次未确认；使用公开页面、sitemap、文章目录和已有内容缺口做 fallback。而不是：
今天数据没有变化。这也是增长运营数字员工必须有的基本诚实度。
六、第五层防线：只提交本次相关文件
自动化最容易偷懒的命令是：
git add .但对长期运营来说，这个命令风险很高。更稳的方式是明确提交文件：
git add src/content/posts/xxx.md \
/Users/william/.hermes/content-system/blog-2000-ip-growth-log.md
git commit -m "Add post about AI Agent scheduled task idempotency"如果本次还改了资源页或导航，也应该列出具体路径，而不是把整个仓库一起打包。
这个习惯能避免很多隐蔽问题：临时文件、构建产物、其他任务留下的草稿、错误修改的配置，都不会被顺手提交。
七、我现在使用的最小检查清单
如果把上面的内容压缩成一张 SOP，我会这样写：
AI Agent 博客定时任务防重复 SOP
1. 读取运营计划，不凭空选题。
2. git status，确认没有无关改动。
3. 读取文章目录和最近文章，避免主题重复。
4. 检查首页、sitemap、robots 是否可访问。
5. 尝试读取 GSC / Cloudflare；不可用时明确写 fallback。
6. 选择一个真实增长动作：新文章、旧文深改、集群页、内链、标题描述优化。
7. 如果目标文件已存在，修同一文件，不新建近似重复文章。
8. npm run build 必须通过。
9. 部署后验证生产 URL。
10. 只提交本次相关文件。
11. 增长日志写清楚数据、动作、URL、验证和下一步。这张清单的价值不在于复杂，而在于它让 Agent 每天运行时都有边界。
八、下一步：把防重复机制产品化
对我自己的博客来说，这套机制首先服务于 blog.786668.xyz 的 2000 日独立 IP 目标。但它其实也可以变成一个更通用的模板：
- 博客自动发布 SOP；
- AI Agent 定时任务检查清单；
- 内容增长日志模板；
- 自动化任务错误复盘表；
- 一个人内容系统的运营看板。
这正是我做这个博客的核心思路：不是只写“AI 很强”，而是把真实自动化过程里的坑、规则和模板沉淀成可复用资产。
如果你也在做自己的 AI 自动化系统，可以先不用追求全自动。先让每一次定时任务做到三件事：不重复、不乱改、可验证。
这三件事做好了，数字员工才有资格每天上班。