把推理搬到家里的电脑后，网络也进入了关键路径。模型快了，下载多花几分钟，用户未必觉得更快。
要解决什么
当前消息带有创建时生成的输入、输出签名 URL。任务排队很久，领取时地址可能已经失效。重试若还复用旧输出位置，旧节点也可能覆盖新文件。
有哪些方案
把文件全部经 VPS 中转，简单但占用它的带宽；把长期凭证发给 Worker，权限范围又太大。我继续用对象存储直传，消息里传稳定引用，领取后按执行权限换短期地址。
具体怎样改
先调整 03_taskService/internal/fileclient/ 和两个 Worker 的任务消息。消息只保留 schema 版本、步骤 ID、generation 和追踪信息；领取响应提供本次执行需要的产物引用、参数与访问地址。
换地址时，服务端检查节点身份、有效 attempt、输入文件所属任务。输出只能写这次 attempt 分配的位置。地址过期可以重新申请，但过期 attempt 不能继续获得写权限。已有签名地址可能到期前仍能上传，因此最终结果仍要靠数据库的有效 attempt 检查来决定。
产物记录用途、生产步骤、输入 revision、大小与可验证的摘要。完成前检查对象存在且符合预期。文件记录和任务状态在不同数据库，不能假装是一笔事务：先幂等确认文件，再由任务库条件提交引用；失败留下的孤立文件后续回收。
当前转码产物被转写消费后没有完整保留在任务关系中，先补上引用。也检查转码 Worker 的临时文件清理：输入已做删除，正常生成的输出 WAV 还需要在使用结束后清理。
性能上先采用“任何节点都能从存储恢复”的基础路径。测到中间 WAV 的上传、下载占比很高，再增加同节点亲和与有容量上限的本地缓存。缓存键包含输入摘要、处理版本和参数；缓存丢失时必须能回退，不能成为唯一副本。
边缘环境还要验证签名里的主机名从设备上可达。不要在签名后随手替换域名；应在生成地址时就选对访问端点。
怎么验收
故意等旧地址失效，再通过有效 attempt 换新地址完成任务。让旧 attempt 上传文件，确认它无法改变最终结果引用。最后删掉某台机器的缓存，用另一台机器完成后续步骤。
这一轮优先保证文件能被正确找到、旧结果不能覆盖。是否值得缓存，用第 12 篇的数据决定。