工作流升级最怕的，不一定是新功能没打开，而是新写出的历史记录让旧Worker再也读不懂。Temporal Python SDK 1.35选择了一条更克制的路径：先让读取端识别经过编解码器处理的外部存储引用，暂不默认写出这种新形式。对运行跨天、需要回放的企业流程来说，升级先后顺序本身就是交付的一部分。

快速看点：1.35于10月28日发布，新增的是面向后续写法的读取兼容；编码引用的写出开关仍关闭，不能宣传为本次已经全面启用。版本同时加入实验性Google Cloud Storage驱动，外部存储配置、凭据、生命周期和故障处理仍由实施方负责。

移出去的是载荷，不是恢复责任

在外部载荷存储模式中，较大的数据可保存在对象存储里，工作流历史留下用于取回它的引用。这样，读取方必须同时具备理解引用、找到驱动以及访问外部对象的能力。即使历史记录仍在，只要对应对象被提前清理、驱动名称不匹配或访问权失效，恢复和回放也会遇到问题。

本次兼容工作针对引用本身：后续版本将可以把引用也交给已配置的Payload Codec处理，并用专门元数据标记帮助读取端识别。1.35的正式代码已包含这一读取流程，同时明确把新引用写出开关设为关闭。发布说明要求先升级所有Worker，再迎接以后版本可能写出的新形式，不是让团队现在手动打开内部开关。

需要特别区分“支持Codec”和“默认加密”。Codec可以承担编码、压缩或加密等工作，实际性质取决于应用配置；SDK增加兼容能力，不会自动给整个对象存储或历史系统补上密钥、访问策略和加密方案。已有外部存储也不是在这次才首次出现。

一次读取，要按正确顺序还原两层内容

相关转换器先识别带标记的引用，在需要时用配置的Codec还原引用，再通过外部存储驱动取回原载荷，随后解码载荷并恢复应用值。没有配置外部存储，或引用不能被正确解码，会明确报错；不能把这些情况理解为自动绕过保护、忽略错误或回退为一份完整原始数据。

新增测试覆盖了旧式未标记引用仍可读取、普通内联载荷不被误标记、缺少Codec或存储配置时失败等情况。还有专门测试模拟未来写出形式，随后关闭写开关，检查读取是否仍然成立。这些是上游测试代码表达的预期，本站未执行测试，也未把它等同于所有历史记录已经完成迁移。

实施团队因此要盘点的不只是线上Worker版本，还包括需要读取或回放数据的客户端、工具以及使用的Codec配置。升级后能处理今天的任务，不代表历史重放、诊断工具或另一批长期未更新的Worker也一定兼容；应分别保留旧数据与新形式的验证样本。

GCS驱动能接入，仍有清晰的实验性边界

新GCS驱动及其适配器明确标为实验性。配套说明要求使用已经存在的存储桶，具备对象读取和创建权限，并在需要存取载荷的客户端与Worker上注册相同名称的驱动；配置的异步存储客户端也要在这些组件使用期间保持可用。下载能力不是一次安装之后自动遍及所有运行进程。

默认外部存储选择阈值是256 KiB，而GCS驱动默认接受的序列化载荷上限是50 MiB。前者决定何时考虑外存，后者是驱动自身限制；二者都不是Temporal服务端的一般消息上限，更不能当作模型上下文容量。修改数值之前，还应核对序列化结果、网络和存储约束。

驱动以序列化字节的SHA-256摘要组织对象，结合工作流或活动上下文命名，并在取回时核验摘要。相同字节在相同上下文可以复用对象，但不同转换器版本可能产生不同字节，不能据此承诺跨版本完全去重。摘要校验是完整性检查，不代替访问授权，也不是加密。

配套适配器不另加重试；凭据、超时和重试策略依赖底层Storage客户端配置，中断上传需要重新开始。对象删除和生命周期由应用负责，保留期应覆盖工作流历史需要的回放窗口。企业还需自行安排失败告警、存储费用与清理策略，不能把“外部存储可用”写成零丢失或自动灾备保证。

此次只核验外部引用兼容与GCS相关代码、文档和测试。1.35另外包含AI集成包迁移等升级事项，不能把这一局部路径当作整个版本都无破坏性变化。本站没有创建存储桶、上传业务载荷或运行回放实验，也不报告生产提速、费用下降或投资回报。

小编判断

这次升级的可复用经验，是先让消费者读懂新格式，再改变生产者写法。外部存储能否成为可靠基础设施，取决于版本、Codec、驱动、权限和保留期是否一起交付。把读写顺序与失败条件写进升级清单，比把实验性驱动说成一键解决大载荷更有价值。