常驻循环的目录与设计：8 个循环与 3 条规则
系列：Idea-to-Production · 机理篇。同系列：《无人值守调度的三件机件》（Job 如何触发）、《十三个阶段与它们的工件》（工件链）。
发布不是终点，而是另一组循环的起点。系统上线之后接手它的不是”更努力的人”，而是八个按节奏运转的常驻循环。本文是一份可对照的循环目录：先列目录与节奏，再讲三条设计规则（循环与排班分离、不进看板、失败不断链），最后走一遍客户 issue 从提报到随发布闭环的完整旅程。你可以拿它逐条检查自己的”定时 Agent”是否真的可靠。
为什么值得看
一次性任务好管，周期性任务难管：多实例会重复触发、失败会静默断链、跑久了没人记得它该干什么。给周期性工作建档的方式，决定了它三年后还在不在运行。
你将学到三点
- 循环（Loop）和排班（Job）是两个世界的东西：循环在知识层定义”做什么”，排班在调度层的一行记录里定义”谁、何时”——分开了，扩容和改版互不牵连。
- 闭环靠”两阶段关闭”防止假修复：修复提交只贴标签，携带该修复的发布完成时才真正关闭 issue。
- 循环的入口数据必须诚实：报告类循环被明令禁止编造指标——数据不可达就如实标注，宁可难看，不可虚构。
目录：八个常驻循环
每个循环对应控制中心 scheduled_jobs 表里一行静态记录，由作业运行器按节奏推给恰好一个在线实例（机制见《无人值守调度的三件机件》）：
| 循环 | 负责角色 | 节奏 | Job 名 |
|---|---|---|---|
| 客户 issue 分诊 | PM | 每日 09:00 | issue_triage@all |
| PR 质量巡检 | 架构 | 每日 09:00 | pr_review@all |
| E2E 门禁 | QA | 每日错峰（近 24h 有代码变更才跑） | e2e_daily@all |
| 迭代发布 | QA | 每月 1 日、15 日 | app_release@all |
| 运营四报告（用量/订阅/健康/漏斗） | 运营 | 双周派发、7 天窗口，按应用各一行 | ops-<skill>@<App> |
| 增长四报告（社交/成本/内容/竞品） | 增长 | 双周派发、7 天窗口，按应用各一行 | growth-<skill>@<App> |
| 治理报告 | 行政 | 每周一 09:00 | admin-report@KylinLab |
| 全链路看护（哨兵） | 平台 | 常驻连续 + 周质量记分卡 + 月流程改进 | ——（无排班行） |
注意最后一行的特殊性：哨兵是常驻看护进程而非排班作业——这正好印证《无人值守调度的三件机件》的分工哲学：确定性机件活在平台代码里，LLM 只负责需要判断力的循环。
设计规则一：循环与排班分离
一句话版本：“做什么”写在知识层，”谁、何时”写在调度层。
知识层的一篇工作流文档描述”分诊怎么做”（读哪个仓库的 issue、怎么分桶、任务写给谁）；调度层的一行 scheduled_jobs 记录描述”这条循环由哪个角色、在什么时间、用什么载荷运行”（target_role、schedule_kind、timezone、payload、next_run_at）。
分离带来的直接好处：
- 改版不动排班：优化分诊逻辑只改知识层文件，符号链接即刻全网生效；
- 扩容不动逻辑：PM 角色加实例，Job 仍然每天恰好触发一次；
- 审计不靠记忆：每次运行（完成/失败/跳过）都记进
scheduled_job_runs历史表，治理报告直接拿它当数据源。
另一个关键决定：Job 不进任务看板、不走认领锁。 周期任务不是一条”待办的卡”，而是到点推送的事件——它没有”完成”状态可标，只有”运行记录”。把两者混进同一块看板，是”定时 Agent”系统最常见的架构性错误。
把”完成”留给一次性任务，把”运行记录”留给周期任务——一块看板装不下两种生命。
设计规则二：闭环靠两阶段关闭
客户 issue 的完整旅程，展示三个循环如何咬合：
客户在公开发布仓库提 issue
→ 每日分诊（PM）：小修→1 条任务；大改→设计+实现成对任务；重复→评论关闭
→ 实现（全栈）：修复提交 → 在 issue 上评论"将于 v1.0.4 发布" → 贴 fix-applied 标签
……修复在两周窗口内持续累积 ……
→ 双周发布（QA）：git diff 有变更才构建发布；发布成功后清扫 fix-applied
的 open issue → 带发布 tag 逐条关闭
为什么坚持两阶段？因为修复提交时客户还下载不到它。在 commit 时刻关闭 issue 等于向用户宣布一个尚未兑现的”已修复”——术语叫 ghost close。发布完成才是事实成立的时刻。
同理，双周发布自带智能跳过：git diff <上个tag>..HEAD 为空就跳过并记审计，绝不为凑日历发空版本。每个应用独立版本线、独立跳过判定、独立配置——一台舰队管多个应用，互不牵连。
设计规则三：循环在初始发布时自动”上弦”
L（运营）与 M（增长）的八个报告循环，不需要任何人记得去创建排班——Initial Launch 完成的那一刻，QA 角色为托管应用批量创建这些 scheduled_jobs 行。报告的产出也遵守诚实条款：允许的状态只有”数据在线 / 可达但不可用 / 数据受阻”三种，实测什么写什么，禁止编造指标；文件名带 ISO 周编号，天然幂等（见《无人值守调度的三件机件》的机件三）。
报告落进档案层后沿着工件链回灌：运营与增长的需求信号、健康告警（严重违规会生成一条 Critical INCIDENT 任务触发自主回滚评估）、竞品动态与内容表现，全部回流到需求侧——想法→生产→报告→新想法，整个系统因此是个闭环而不是一条流水线。
总结
- 给周期性工作建档的方式，决定了它三年后还在不在运行：循环定义进知识层、排班进数据库行、运行史进审计表——三者齐备，一条循环才”可交接、可扩容、可追问”。
- 把”完成”留给一次性任务，把”运行记录”留给周期任务：一块看板装不下两种生命，硬装的结果是僵尸卡片和假成功。
- 现在就检查你的定时 Agent：它的下一次触发写在哪里？如果答案是”提示词里让它明天再叫自己一次”，你缺的正是本篇的第一条规则。
延伸阅读：同系列《无人值守调度的三件机件》（Job 如何触发）、《十三个阶段与它们的工件》（工件链），均收录在 Idea-to-Production 系列中。
如果你也在维护类似的常驻循环，欢迎在评论区聊聊你踩过的坑。