同一段音频第一次按单声道解析，第二次改为保留双声道。文件没有变，如果解析缓存只拿文件摘要当键，第二次任务可能直接复用第一次的元数据。后续步骤看到的声道数与本次配置不一致，却没有一个进程报错。

把Agent流程画成几个箭头还不够。每个步骤需要知道输入具体是哪份产物，以及这一步采用哪版规则。完成条件也应是“产生并验证了可消费的结果”，不能只有函数已经返回。

输入没变，不代表解析条件没变

以解码、片段划分、特征提取三步为例。解码结果依赖原文件内容和解码配置；片段结果依赖解码产物和切分规则；特征依赖具体片段及特征提取版本。

只把原始文件名传下去，既不能区分同名新内容，也不能区分同内容采用不同处理规则。可以为每一步建立受控的输入描述，再计算键。任务ID用于追踪一次执行，缓存键用于判断计算输入是否相同，两者职责不同。

import hashlib
import json

def step_key(source_sha256, operation, version, config):
    if len(source_sha256) != 64 or any(
        c not in "0123456789abcdef" for c in source_sha256
    ):
        raise ValueError("输入摘要无效")
    if not operation or not version:
        raise ValueError("步骤与版本不能为空")
    raw = json.dumps(
        {"source": source_sha256, "operation": operation,
         "version": version, "config": config},
        sort_keys=True, separators=(",", ":"),
        ensure_ascii=False, allow_nan=False,
    ).encode("utf-8")
    return hashlib.sha256(raw).hexdigest()

这个函数适用于受控JSON配置。先用schema限定字段类型、单位和默认值，避免一处写1秒另一处写1000毫秒，却被当成两个无法解释的配置。数组顺序仍然保留；如果某字段语义是集合，应在进入此函数前规范化。不要把临时下载链接或访问令牌纳入配置。

步骤键与产物摘要分别保存

步骤键描述“准备算什么”，产物摘要描述“实际上得到了什么”。两者不能互相替代。解析输出至少携带上游产物摘要、本步键、解析器版本、结构化元数据和实际输出摘要。

后续步骤消费的是已验收产物。若任务需要重新解码，片段步骤应引用新的解码摘要，不能仍引用一个叫decoded-latest的可变路径。配置变更后哪几步失效，也就可以沿依赖关系解释。

并非每次规则改动都需要重新跑所有旧任务。旧产物可以保留原规则版本，新任务按新规则生成；只有当前需要的依赖链重新计算。这样既能恢复执行，也能解释同一文件为何存在多套解析结果。

缓存命中仍然要检查产物是否可用

数据库里有一行成功记录，不代表对应对象还在。命中缓存后先校验产物存在、摘要与结构满足约定，再把它交给下游。对象丢失或校验不通过时，将缓存标记为不可用，重新执行受影响步骤，而不是给下游塞一个空对象。

写入阶段可以先将结果放在临时对象里，完成解码与字段校验后再登记成功产物。登记需要处理并发：相同步骤键被两个worker同时执行时，采用唯一约束与既定冲突规则。数据库事务不会自动让对象存储也参与原子提交，应为孤立临时对象留出清理流程。

素材解析失败也需要准确边界。无法解码时停止依赖解码的步骤；能够读取但不满足本任务声道或时长范围时，返回不适用原因。不要让Agent为了“继续前进”编出缺失的采样率或拍速。

本地检查了字典键顺序变化得到相同步骤键，声道配置或规则版本变化得到不同键，NaN配置被拒绝。使用合成摘要与配置，没有真实解码音频、部署Agent或访问对象存储；这些验证只覆盖键的确定性，不证明缓存服务具备并发一致性。

参考：Python JSON序列化参数、hashlib、SQLite事务范围，2026-10-20核对。步骤协议与失效方案为应用层设计。