扣子企业版分阶段下线：时间表、退款规则与 Agent 迁移准备
2026年11月2日 · 2382 字 · 5 分钟 · 扣子 Coze 豆包 企业版下线 Agent 数据迁移
扣子企业版已经公布分阶段下线计划：2026 年 11 月 30 日暂停新售，旧版套餐于 2026 年底下线，新版企业套餐于 2027 年底下线。 已经部署生产级 Agent 的团队，需要先核对套餐和合同，再安排资源备份与迁移验证。扣子官方下线公告
本文核对时间为 2026 年 11 月 2 日。公告涉及现售企业套餐及列明的旧版套餐，不能据此推断扣子所有产品同步停服。官方仍将扣子编程列为独立产品，后续企业方案也尚待公告。扣子常见问题
扣子企业版什么时候下线？
| 时间 | 适用范围 | 用户需要关注的事项 |
|---|---|---|
| 2026 年 11 月 30 日 | 企业标准版、企业旗舰版暂停接受新客户购买 | 已签合同但尚未下单的客户，联系商务经理确认安排 |
| 2026 年 12 月 31 日 | 在火山引擎购买的旧个人进阶版、旧企业版、旧团队版全面下线 | 超出该日期的未使用部分自动退款至火山引擎账户 |
| 2027 年 12 月 31 日 | 企业标准版、企业旗舰版全面下线 | 新购、续费和增购席位的服务到期日均不得晚于这一天 |
暂停新售与全面下线是两个阶段。在合同有效期内、对应套餐下线之前，已购客户仍可使用套餐功能并获得约定的客户服务。团队应以自己购买的套餐和合同为准，分别确认采购截止时间与实际服务结束时间。火山引擎公告
旧版用户需要购买新版吗？退款、续费怎么算？
是否购买新版，应结合业务连续性和迁移进度决定。旧版用户可以退订旧套餐后购买企业标准版或企业旗舰版，作为迁移过渡，但最长只能使用至 2027 年底。无需继续使用的客户，可以按公告等待旧套餐超期未使用部分退款。官方下线公告
对现有企业版客户，扣子官方说明：套餐未到期时可续费或增购；到期后 14 天内仍可续费，超过该窗口则按新购处理。这些操作都受最终下线日期限制，不能靠续费延长至 2028 年。官方续费说明
如果已购新版套餐的服务期限超过 2027 年底，官方将结合合同单独沟通处理。涉及订单、退款和过渡采购时，建议向商务经理确认并保留书面记录。火山引擎客户服务与退款安排
对企业来说，采购过渡套餐与启动迁移可以同时进行。关键是把预算、验证周期和业务停机容忍度放在一起评估，避免只处理续费，却没有给迁移留出时间。
产品收缩与豆包整合：哪些已确认，哪些仍待公布？
企业版公告之前，扣子已经发生过多次套餐、模型和渠道调整：
| 时间 | 已公开的调整 | 对使用者的意义 |
|---|---|---|
| 2025 年 9 月 3 日 | 抖音分身功能下架 | 旧教程中的功能入口可能已经失效 |
| 2026 年 5 月 30 日 | 原专业版下线，原有账号调整为个人免费版 | 需要按新套餐重新确认权益 |
| 2026 年 7 月 1 日 | 低代码智能体发布至豆包渠道的入口下线 | 无法再通过该入口发布，已发布智能体不受影响 |
| 2026 年 7 月 | 部分官方模型服务下线 | 依赖具体模型的项目需要重新验证效果 |
| 当前账号规则 | 新注册账号默认使用扣子编程，不再开放旧版低代码平台 | 新旧账号的界面和开发路径存在差异 |
来源：开发平台常见问题、专业版历史说明、产品动态。其中抖音分身下架发生在 2025 年，不要与 2026 年企业版下线时间混淆。
组织层面，TRAE 官方中文社区在 2026 年 8 月 24 日转发的报道提到，TRAE、扣子团队并入豆包体系，办公场景的产品能力将进行整合。TRAE 社区转发的整合报道
把这些变化放在一起，我的判断是，字节正在收拢办公与 Agent 产品的组织和入口。但具体由什么企业产品承接、是否支持自动迁移、原有能力如何映射，仍需等待官方后续方案。组织整合不能直接当作数据迁移和服务承接的保证。
迁移前先做三件事
1. 建立套餐、资源与依赖清单
先确认账号属于旧版套餐还是新版企业套餐，并记录合同到期日、剩余权益和商务联系人。旧版用户应围绕 2026 年底安排验证和切换；新版企业用户有更长的过渡期，也需要提前评估复杂工作流的迁移成本。
按生产 Agent 建立资源清单：
- 配置：系统提示词、变量、模型参数、工作流逻辑和异常分支。
- 知识与文件：原始文档、知识库来源、更新方式及访问权限。
- 外部依赖：插件、API、鉴权方式、回调地址和调用限额。
- 运行状态：业务需要保留的对话、记忆、定时任务和日志。
记录密钥时使用现有的安全凭据管理方式，不把明文密钥放进共享迁移文档。
2. 备份当前可导出的内容，逐项验证恢复
官方公告把对话、记忆、文件、编程项目和低代码工作流等资源的导出、备份安排留待后续说明，因此目前不能假定会提供覆盖全部资源的一键迁移。官方资源导出说明
建议先使用当前账号已有的导出功能保存可导出的配置和资源；没有现成导出入口的部分，整理原始文件及必要的逻辑说明。导出后检查文件是否可读、内容是否完整，并用一个小项目尝试恢复。
长期记忆、对话上下文和运行状态尤其需要单独验证。它们能否完整导出、目标平台是否理解相同格式，不能只凭两边都有“记忆”或“工作流”功能来判断。
3. 用真实业务做 POC，再决定目标平台
迁移验证应选取有代表性的生产任务，包含知识检索、工具调用、失败重试和权限限制。除了回答效果，还要确认原有业务系统能否接入、运行成本是否可接受，以及发生故障时能否回滚。
| 验证项目 | 需要回答的问题 |
|---|---|
| 模型与工具 | 所需模型是否可用，函数调用和插件参数能否保持业务语义？ |
| 数据迁移 | 提示词、文档、工作流、对话和记忆分别能迁移多少？ |
| 企业治理 | 是否满足实际需要的权限、审计、隔离和部署要求？ |
| 运行维护 | 谁负责升级、告警、备份、故障处理和费用控制？ |
| 退出能力 | 将来再次迁移时，能否完整导出自己的配置和数据？ |
原有业务依赖企业微信等渠道时，还要把渠道接入列入验收。评估开源自托管或云端企业平台时，应分别核对目标版本的部署条件、服务合同和运维责任；不能把平台名称当作功能、私有化或 SLA 的保证。
字节系后续产品也可以列入观察，但在具体承接方案公布和验证之前，迁移计划仍应具备可独立实施的路径。
企业用户现在应该怎么安排？
旧版套餐用户的重点是，在 2026 年底前完成过渡采购或业务切换；新版企业套餐用户应尽早启动 POC，把复杂依赖逐一拆开。免费版和其他个人套餐需要查看各自的权益与公告，不能直接套用企业版下线时间。
对生产 Agent 而言，平台调整最直接的影响是服务期限、依赖变化和数据可迁移性。先把自己的资产整理出来，再用真实任务验证下一站，比等待一个尚未明确的承接方案更容易掌握进度。