自动股票研究中断怎么办：从已核对的数据步骤继续
股票研究中断后，应从对当前问题仍然有效的数据步骤继续，而不是重复整段对话或相信上次回答写着“已完成”。保存源值、口径、可得时间、步骤结果和尝试次数，恢复时先检查，再复用；失败或失效步骤重跑，只有全部前置数据合格才重算下游指标。检查点记录的是执行状态，不是漂亮的研究摘要。
本文实现价格、外供EPS、PE三步离线流程，使用合成输入与JSON状态。它不恢复Vibe会话、不运行模型、不重启真实定时服务，也不证明CoTrading已有对应持久化功能。示例实际执行序列化再读取，目的是确保恢复不依赖没有保存的内存对话或隐含上下文；真实磁盘可靠性仍需另行设计。
定义决定能否复用的研究合同
任务T1针对AAA、2027财年稀释EPS、人民币，价格日2026年10月26日，决策时刻当日UTC+08的16:00。完整合同生成内容摘要作为运行键，价格日或决策时间变化就成为新版本。只用证券代码无法唯一标识估值，因为同一公司在不同日期和假设下可以有许多合法结果，不能都压到一个“完成”标记。
每个已接受步骤保存数值、证券、币种、来源标识、可得时间和到期时间。价格另存价格日期，EPS另存目标年度与稀释口径。本例故意采用严格的当日到期政策来检验失效，并不是说所有预测真实有效期只有一天。正式流程应按字段和来源定义政策，不能用任意统一期限代替对数据时效的研究判断。
Python datetime用于比较带时区时间，要求来源在决策时已经可得，且有效期覆盖决策时刻。价格日期必须满足合同，EPS年度和口径也必须相同。旧值仍然存在于缓存，只能说明曾经保存过它，不能自动证明它能支持新的决策日期。时点检查必须每次复用时重新执行。
保存足以解释中断的状态
检查点分为缓存、各版本运行记录和完成标识列表。运行记录保存合同、已接受步骤、各步骤次数和状态。T1开始时已核对价格24，价格尝试一次；EPS第一次请求失败，也记录一次；PE尚不存在。程序先用JSON编码再解码这个状态，模拟从保存记录重新载入，而不是直接调用仍带有旧局部变量的函数。
Python JSON文档说明这里的交换格式。财务数字存为字符串，重载后再明确转Decimal，避免展示或序列化引入含糊。样例真实完成编码解码，但不提供磁盘原子替换、断电写入保证或分布式存储。接入真实持久化时要补这些保证，同时不能削弱本文的数据可复用条件。
支持的PE要求有限正价格和EPS。Python Decimal用于计算，额外拒绝NaN及正负无穷。无效数不属于可复用已接受步骤，若需保留原载荷，应放诊断区，不要混入有效数值缓存。否则“之前已经取过”可能绕过数值守卫，在恢复阶段重新放行错误结果。
恢复T1，只补失败的EPS
恢复函数先按T1检查价格，24仍有效，因此复用。EPS进行第二次允许尝试，返回1.2，计算24 / 1.2 = 20，保存完成结果。实际轨迹为reuse:price、fetch:eps、calculate:pe-v1。程序还单独记录真正来源调用，断言这次恢复只请求了EPS，没有重新请求价格，避免仅靠轨迹文字声称复用。
完成记录保存已接受步骤和公式版本的依赖摘要。Python hashlib提供所用SHA-256。摘要可以发现保存内容与原依赖记录不一致，不能鉴定来源是否真实，也不是数字签名。数据源核验、文件权限和内容完整性属于不同层次，不应因为输出了一串哈希就宣称研究资料可信。
if valid(saved_row, kind, contract):
record["steps"][kind] = copy.deepcopy(saved_row)
else:
# 只有对应步骤仍有尝试预算时，才重新获取。
pass下载完整示例。需要Python 3.12+，仅用标准库和合成数据，运行python R554.py。文件包含状态转换、有效性校验、来源替身、依赖摘要、预算和断言，不需要网络或外部服务。
重复恢复不重复完成
再次恢复完全相同的T1，程序先检查完成记录依赖是否仍兼容、内容摘要是否一致，并用保存输入核对PE，之后返回complete_reused，没有来源调用，也不新增完成标识。调用方可能因为丢失响应而重复请求，重复恢复不能因此再次发布或覆盖原完成结果。合同、依赖与结果必须共同支持这个完成状态。
样例另复制一份完成记录，将保存价格改为99而不更新依赖摘要，恢复返回checkpoint_invalid，PE不可用。这是局部一致性反例，不是完整加密来源验证。发现记录被修改或格式异常时，应保留证据供复核，而不是凭旧status=complete绕过数据校验。若操作人员合法修正源值，应走有版本的重算流程。
新价格不能与过期EPS拼接
任务T2把价格日和决策时刻改为10月27日。26日价格不满足合同，重新取得30。缓存EPS1.2按合成政策已在26日晚到期，不能复用；新的EPS请求故意超时，所以T2仍partial，PE为空。此时绝不能算30除旧1.2得到25，再声称27日研究完成，因为旧EPS已经被当前合同拒绝。
轨迹为fetch:price、fetch:eps。旧EPS可继续留在历史缓存里，但保留和授权使用是两个动作。新价格已经通过的部分也保留，下次恢复不用再取。把这些状态独立保存，才能同时说明本次哪里成功、哪里失败，而不是失败后清空所有有效输入，或为了给答案而偷偷复用被判失效的数字。
下次恢复T2，27日价格30仍有效，直接复用；EPS第二次取得1.5，得到PE20。T1记录完全不变，完成标识共两个。两个结果恰好同为20不意味着可以合并，它们分别来自24/1.2与30/1.5，日期、来源和依赖都不同。保存独立历史才能解释后来为什么重跑以及输入如何变化。
有限重试并说明停止原因
每个合同每步骤最多尝试两次。失败副本中，T2的EPS再次超时耗尽第二次，下次恢复返回retry_budget_exhausted，不再请求来源，没有PE。T1仍完成，T2仍无估值。预算使持续缺失不会变成无限循环，用户能得到明确停止状态和需要补查的字段，而不是等待一个永远没有结果的自动任务。
超时、财年不匹配和非正EPS需要不同处理。超时可在预算内重试；相同查询一直返回错年，重试本身不能解决问题；非正EPS则可能是方法不适用。紧凑样例保留失败原因，真实工作流应把原因路由到相应动作，不要每次都当技术网络故障，更不要通过清空计数悄悄获得无限预算。
下游失效与交付检查
保留合同、JSON检查点、源载荷、有效期政策、次数、轨迹、公式版本和完成键。上游输入改变必须由新接受依赖重算，孤立旧PE不能代替依赖记录。真实存储和多工作器还需持久化、互斥和发布政策，但核心约束应保持：有效输入可复用、失败前置阻断下游、重复完成不增产物、不同日期保留独立历史。
恢复前也要核对任务问题是否仍然相同。用户若把目标年改为2028、币种改为港元或采用基本EPS，不能只改文章标题继续用旧值。合同摘要能够区分这些变化，实际有效性检查则防止错误复用。把问题、源数据和派生公式共同版本化，才能让“从已核对步骤继续”有明确含义，而不只是恢复聊天中的上一句话。
区分有效缓存与完整任务记录
缓存是可供后续检查的候选数据，不是永久通行证；运行记录则说明某个合同曾接受了哪些输入、用了几次尝试、生成什么结果。T2补到新EPS后可以更新当前缓存，但不能把T1依赖也指向可变缓存，否则历史PE会在没有重算的情况下失去原来源。程序深复制步骤，正是为了让完成历史保有自己的依赖副本。
人工介入时不要直接把partial改为complete。应补齐缺失步骤、重新通过有效性检查和公式计算，再生成完成记录。若需要重置预算，明确保存新的尝试政策或新运行版本，不能通过反复删除计数让限制失效。预算是停止条件，来源修复和重新授权是另一个动作，两者应有可见记录。
依赖摘要覆盖源字段与公式版本，但不能证明JSON文件写入过程没有丢失，也不能防止有权限者同时改值和摘要。真实环境需补可信存储、备份及并发协调。准确说明这些边界，既保留本地示例真正验证的复用和阻断，也不会把一个合成检查点误称为可上线的会话恢复平台。
常见问题
过期EPS还能留在检查点吗？
可以作为历史数据保留，但不能通过当前有效性检查，不能据此计算新结果。
内容哈希证明预测来源真实吗？
不能，它只检查保存依赖是否一致，来源真实性需要另外核验。