把日报汇总、巡检告警、内容流水线这类重复劳动交给定时 Agent 实践一段时间后，踩过坑也修过车，沉淀出三条最基础的原则。它们不依赖特定技术栈，大多数自动化场景都适用。
原则一：config 驱动，而不是写死
栏目、风格、频率这类天天要调的东西，全部抽到配置文件里。改配置就是改产品——不用动代码，也不会改坏正在跑的任务。
我的内容流水线就是这样的：栏目、风格、频率全部写在 config 文件里，调整栏目或发布节奏时只改配置，任务代码一行不动。这个习惯是从云主机批量管理的实践里带过来的——主机清单、启用项全部登记在清单文件，脚本自动发现，从不写死名字。
原则二：边跑边落盘，随时可交付
长任务跑到一半被叫停是常态：预算调整、方向变化、临时要看结果。设计成边跑边落盘——中间数据与结果持续写入本地，叫停时立即用已存的数据交付，并如实标注未完成的部分。
这条原则保证了一件事：任务可以随时中断，但产出的东西不会丢。对需要长时间运行的 Agent 任务，它是可靠性的底线。
原则三：完成自动通知
任务在后台跑，人去做别的事。跑完自动推送结果摘要，人回来看一眼就能决策，不用盯屏等待。
通知按重要度分级：巡检告警类异常即时推送，日报汇总类定时送达。告警与汇报分开，避免通知疲劳——这也是跑了告警任务之后的实际调整。
适用范围与下一步
这三条原则解决的是「可靠地跑起来」，不解决「跑什么」。具体任务怎么做，仍要回到每个项目里逐个设计。
下一步：把三条原则固化成个人自动化项目的上线 Checklist，每个新任务在部署前逐条过一遍，减少同类坑的重复踩。