Agent 每天定时运行，要先确定三个问题：按哪个时区启动，处理哪段时间的数据，错过时点后怎样补跑。定时器只负责发出启动信号，输入是否齐全、报告是否仍有用、旧任务是否需要补做，都需要单独的业务规则。只写"每天生成日报"，模型就可能把运行当天、资料更新日期和报告所属日期混在一起。
以每天早上汇总昨日业务数据为例，任务可以约定北京时间九点触发，读取昨日 00:00（含）至今日 00:00（不含）的记录，产物标明对应业务日。ZGI 是可自托管的 Agent Runtime，可以把定时任务、数据读取、模型分析和工作流分支组织在同一运行环境中。业务日、数据截止点与补跑策略仍要由团队明确配置，不能依赖模型临场猜测。
触发时间和数据范围要分开写
启动时间回答"什么时候开始"，数据范围回答"这次处理什么"。上午九点运行的日报，通常不应读到当天八点的新记录。时间范围应由程序或工作流变量算好，再传给查询节点和模型；起点包含、终点不包含的边界要保持一致，避免相邻两天漏掉或重复包含午夜记录。
时区也要固定。服务器时区、业务时区和资料里的时间字段可能不同，部署在另一地区后，"昨日"就可能变成另一段时间。任务定义应同时保存业务时区与业务日，查询前统一换算时间，输出时再按团队使用的时区展示。模型只解释已经选定的数据，不负责决定日期边界。
还要区分数据发生时间与到达时间。昨日产生的记录可能今天才同步进来；九点发出的启动信号，并不能证明数据已经完整。可以在分析前检查同步完成标记或数据截止点，未就绪就进入等待分支，并设置等待截止时间。到点仍缺数据时，按业务规则选择延后或输出注明缺口的草稿，不把缺失项当成零。
同一个任务也可能由定时器、数据就绪事件或人工补跑启动。不同入口应传入相同格式的业务日和数据范围，并保留触发来源。这样人工补跑昨日任务时，模型仍处理昨日的输入，不会因为今天再次点击运行而改成今天的日报。
错过运行窗口后，先判断补跑是否有用
补跑要看产物的用途。用于历史留档的日报，晚几个小时生成仍可能有价值；用于晨会决策的提示，会议结束后再发送就可能失去意义。任务应写清最晚运行时间，以及超过时间后是跳过、仅生成归档稿，还是交给人决定。把过期结果发往原定渠道，会让接收者误判它仍对应当前业务状态。
补跑时固定原业务日，并说明采用哪一版数据。选择使用当时留存的数据，还是重新查询已补齐的记录，会影响报告内容。若旧报告已生成，新结果应能识别为同一业务日的修订，保留修订原因和原产物位置，让复核者知道变化来自资料更新。
检查结果也要区分清楚：输入未就绪是等待，超过窗口且规则要求不执行是跳过，已执行但未得到完整结果是失败。三种情况需要不同的后续动作。补跑入口应携带目标业务日和原因；遇到重复产物时，先决定替换、另存或停止，避免把每次点击都当成一份新报告。
在 ZGI 中，可以用 Workflow 的条件分支承接输入就绪与运行窗口的判断，用运行状态、步骤和结构化输出检查实际处理范围。具体的迟到阈值、数据版本与报告替换规则，需要在目标工作流中配置，并用实际输入验证；这些规则不能从"支持定时任务"直接推断为平台默认行为。
上线前可以准备三组验证输入：数据按时齐全、数据迟到、任务错过运行窗口。逐组核对启动时间、查询范围、最终产物和后续动作。验收通过的标准是每次运行都能说明处理了哪个业务日，为什么执行或跳过，以及下一次补跑会使用什么输入。
GitHub：https://github.com/zgiai/zgi