Pro 团队默认部署保留期缩短至 30 天：存储成本与回滚能力的平衡

平台近期调整了 Pro 团队的默认部署保留策略：新 Pro 团队现在默认只保留 30 天的部署历史。这一变化直接回应了 Coding Agent 普及带来的部署频率激增问题——当自动化编码工具持续推送构建产物，部署历史会以远超以往的速度膨胀，进而推高存储开销。

为什么是 30 天

官方给出的理由很直接：Coding Agent 加速了开发流程，部署频率随之上升，存储的部署历史量也水涨船高。缩短保留窗口能在"保留近期可查历史"和"限制旧历史及其存储成本"之间取得平衡。

这个判断背后有一层容易被忽略的逻辑：部署历史的价值随时间快速衰减。绝大多数回滚和排查发生在最近几次发布之内，超过一个月的旧构建被检索的概率很低，但它们占用的存储空间并不会因为"没人看"而减少。把默认值设为 30 天，本质上是用概率思维替代"全都留着"的囤积习惯。

部署保留期（Deployment Retention） 指的是平台自动保存历史部署记录及其构建产物的时间窗口。每一次部署都会生成一份不可变的构建快照（包含代码、依赖和产物文件），这些快照既用于快速回滚，也用于排查线上问题时的版本比对。保留期到期后，平台会按策略自动清理过期快照以释放存储。理解这个概念的关键在于：保留期并非简单的"日志留存"，它直接决定了一个团队在事故发生时能回退到多远的历史版本。因此保留期的设定本质上是在"可回溯深度"与"存储成本"之间做权衡，而不是一个纯技术参数。

用量越大，成本越明显

部署存储和函数存储均按 $0.10/GB-month 计费。单看单价不起眼，但在高频部署场景下，累积效应相当可观。

假设一个团队在 Agent 辅助下每天产生多次部署，每次构建产物几百 MB 到数 GB 不等，30 天与 90 天的历史留存差距可能意味着数倍的存储账单。对于同时运行多个项目、多个环境的团队，这个差距会被进一步放大。默认值从长周期缩短到 30 天，等于替团队省去了一次需要主动决策的成本优化。

GB-month（GB·月） 是云存储计费的常见单位，表示"1 GB 数据保存一个月"的费用。它并非按瞬时占用量计费，而是对存储时长做积分：如果 10 GB 数据保留一整月，计费为 10 GB-month；如果只有 5 GB 保留整月、另 5 GB 只保留半个月，则约为 7.5 GB-month。这种计量方式意味着，即使团队没有新增部署，陈旧历史只要还在保留期内，就持续产生费用。理解 GB-month 有助于看清保留期调整的真实收益——缩短窗口不只是减少"存了多少"，更是缩短了"存了多久"，两者相乘才是账单变化的来源。

需要更长历史怎么办

30 天只是默认值，不是硬性上限。团队可以在设置中选择更长的保留周期，用于需要更长历史来做检查或回滚的场景。对于发布节奏慢、但每次变更风险高的项目，延长保留期是合理选择。

这里有一个需要提前意识到的风险：超出保留策略的旧部署会被删除，且删除后无法恢复，也无法用于回滚。也就是说，保留期本质上是一道"不可逆的删除线"。如果团队依赖某个特定历史版本作为兜底方案，必须在它被清理之前主动延长保留期，而不是等到需要回滚时才发现构建已经不在了。

Coding Agent（编码智能体） 指能够自主或半自主完成编码任务的 AI 工具，它们可以持续生成代码、提交变更并触发构建与部署流水线。与传统"人工提交—人工发布"的节奏不同，Coding Agent 按机器节奏工作，可能在一天内产生数十次部署。这种高频特性正是本次策略调整的背景：过去按人工发布频率设计的存储默认值，在 Agent 场景下会迅速被填满。理解 Coding Agent 的运作方式，有助于判断自己团队的部署频率是否已进入"高频"区间，从而决定是否需要延长保留期或优化构建产物的体积。

对团队的实际影响

这次调整传递出两个信号。

第一，Agent 驱动的开发模式正在改变基础设施的默认假设。过去按"人工发布节奏"设计的存储默认值，在自动化高频部署面前已经不合时宜。平台把默认值调低，是在用产品层面的改动消化 Agent 带来的副作用。

第二，成本控制正在从"事后优化"转向"默认合理"。与其让团队在账单上涨后自己去翻存储优化指南，不如把更省钱的选项设为默认，把"需要更多"变成一次主动选择。这种默认值设计思路，对使用类似平台的团队有参考价值。

对 Pro 团队而言，当下最实际的动作是检查自己项目的部署保留设置：确认默认 30 天是否满足回滚需求，对关键项目评估是否需要手动延长，并重新审视存储优化指南中的建议。