一次自动文件交付把同一份内容发送到了同一目标两次。原请求产生了两个兄弟任务，也就是从同一父请求派生的两个独立执行。第一个任务可能已经完成外部动作，但界面证据无法确认最终文件名，因此结果被记录为未知。第二个任务稍后恢复，只看到自己的本地执行尚未发送，于是再次越过交付边界。

这次重复暴露了智能体与工作流系统中常见的一处缺口。每个执行者的局部状态都可能看起来安全，组合后的外部行为却会产生重复副作用。这里的副作用指改变外部系统状态的动作。修复需要围绕一次外部交付建立全局判断，并明确处理“可能成功、确认不完整”的结果。

这次结果属于可能成功

脱敏证据确认了四项事实：

• 两个任务指向同一个目标，内容字节也 …

一份长期学习路线可以排得很完整，却无法说明学习者今天真正会做什么。日历能够列出未来十八个月的 Linux、容器、云基础设施和可靠性工程，但它通常回答不了几个实际问题：

• 昨天的任务已经完成，还是只读过一遍？
• 学习者能否脱离原步骤解释结果？
• 哪个薄弱知识点应该在本周重新出现？
• 下周应该减量、保持，还是适度加量？

为了解决这些问题，我把学习路线实现成了一个带状态的反馈闭环。课程表负责定义预期顺序，每日计划从中选择有限任务，提交的证据推动进度状态变化，周复盘再按明确边界调整后续负载。

日历为什么不够

最初设计是一条按周排列的长期主题序列。它能说明范围，却不能可靠处理学习中断、调度器重复运行、理解薄 …

一个按周运行的媒体流水线需要支持同一 ISO 周内发布多期内容。原来的周标识不再唯一，因此任务目录和历史记录改成了 2026-W32-0、2026-W32-1、2026-W32-2 这样的版本化形式。

但增加序号只解决了一半问题。调度器可能在分配任务后、记录成功前异常重启。如果每次重跑都重新申请“下一个序号”，同一次逻辑运行就会消耗多个任务 ID。对于付费流水线，后果不只是目录混乱：后续命令还可能初始化第二个任务，并向供应商重复提交请求。

重试为什么会重复创建任务

这套流程必须同时满足两个看似冲突的要求：

1. 同一周内的不同运行必须获得递增序号；
2. 同一次定时运行的异常重试必须拿回原序号。

只看 …