腾讯元器今日停服：你的智能体还有 61 天可导出

腾讯元器在今天停止服务了。

这不是“新建入口没了”那么简单。官方停服公告写得很直白：应用访问、数据读写、API 调用和控制台等面向公众的服务都会关闭；已经发到公众号、服务号、微信客服等渠道的智能体，也不再响应用户对话。

如果你的智能体只放在后台自己玩，影响可能只是少一个工具。可一旦它挂在真实入口上，今天先要处理的不是“选哪家替代品”，而是两个更实际的问题：用户此刻还能不能得到回应？手里的导出包，到底能不能把业务恢复出来？

官方留了一个过渡窗口：平台停服后，到 2027 年 1 月 9 日 前仍可通过数据导出控制台申请或下载备份。今天是 11 月 9 日，按日历算还有 61 天。这个窗口救的是数据，不自动替你完成迁移。

先把两个截止点分开

第一个截止点就是今天。元器主平台的应用访问、控制台、数据读写和 API 已经停掉。不要因为“还能导出”就误以为原来的机器人仍能接单、答疑或发起流程。挂在公众号、服务号、微信客服里的入口同样会失去响应。

第二个截止点是 2027 年 1 月 9 日。官方说，过渡期内可通过独立的数据导出控制台下载备份；过了这个日期，除依法需要保留的日志外，用户数据会被删除，也不再受理导出申请。

这两个日期对应两张不同的工单。

• 今天就要关的工单：把已失效入口从用户路径里找出来，补上人工客服、表单、公告或临时跳转，别让用户对着一个不回话的智能体反复输入。
• 过渡期内要完成的工单：导出、校验、重建和切换。压缩包下载成功只代表第一步完成。

很多迁移翻车都发生在这里：团队拿到一个 ZIP 文件就宣布“数据保住了”，等换到新平台才发现工作流缺节点、外部工具权限失效，或者用于验收的历史样本根本没带走。

把“下载成功”拆成导出、清点、恢复验证和切换四个动作。

导出的不是一份文件，而是一套可恢复性证据

腾讯官方公告列出了智能体配置、工作流和对话记录等可备份内容。实际导出字段以控制台生成的文件为准，但做迁移时，建议把它们按“以后能不能重新跑起来”来整理，而不是按下载页面上的文件名来整理。

第一类是智能体定义：提示词、角色设定、模型选择、欢迎语、示例问题、路由条件。它们决定新平台上的第一个版本能否保持原来的行为边界。把它们导出后，最好另外生成一份可读的 Markdown 或 JSON 清单，写明每项来自哪个智能体、最后修改时间和当前用途。

第二类是知识与原始素材：不只要拿走“知识库”这个名字，还要确认原始文档、网页正文、图片附件和更新说明是否能重新被读取。新平台的切分规则、检索方式和模型可能不同，所以“索引已导出”不等于“答案会一样”。原始材料才是以后重新构建检索链路时最硬的底稿。

第三类是工作流和外部依赖：节点顺序、变量名、回调地址、工具说明、错误分支、定时任务，任何一处漏掉都会让智能体在新环境里看似上线、实际断链。密钥、令牌和第三方账号凭据不要塞进普通迁移包；迁移后应在新环境按最小权限重新签发，并在交接记录里标明负责人和失效时间。

第四类是对话与验收样本：历史对话不只是运营回忆录。挑出 20～50 条典型问题，尤其是会调用知识库、工作流或人工兜底的样本，去掉不该带入测试环境的个人信息后，做成回归集。没有这批样本，你只能凭感觉判断迁移后的回答“像不像”。

下面这张表可以直接放进迁移工单：

要保存的东西	导出后先检查什么	恢复时怎样算通过
智能体配置	是否有提示词、模型、路由与入口说明	新版本能复现核心角色与边界
知识原文	文件是否可打开、链接与附件是否齐全	典型问题能命中正确资料
工作流与工具	节点、变量、失败分支、外部依赖是否完整	一条端到端任务能成功，也能在失败时停止
对话样本	是否已脱敏、是否覆盖高频和高风险场景	新旧结果由业务负责人逐条验收
渠道入口	公众号、客服、页面链接由谁维护	用户不会落到失效机器人上

用一次“还原演练”代替一次“文件盘点”

真正有用的迁移包，不该只有一个下载目录。可以按下面的结构存一份独立副本，放在团队能访问、但权限受控的位置：

migration-yuanqi/
├── 00-source/        # 官方导出原文件，保留原样
├── 01-agent-spec/    # 提示词、模型、入口和配置说明
├── 02-knowledge/     # 原始资料、附件、来源与更新时间
├── 03-workflows/     # 流程图、节点说明、变量与依赖清单
├── 04-evals/         # 脱敏后的典型问题和验收标准
├── 05-channels/      # 公众号、客服、网页入口的切换清单
└── RESTORE.md        # 谁在什么环境、按什么顺序恢复

这里最容易被跳过的是 RESTORE.md。它不用写成长文，至少回答四句话：这个智能体服务谁；从哪里接到请求；依赖哪些知识和工具；恢复后拿哪几条问题验收。等真正要切换时，这四句话比一堆截图更值钱。

可以把演练压缩成一次 30 分钟的最小恢复：选一个影响较小的智能体，在隔离环境导入配置和资料，手工重建关键工具，跑完回归集里最常见的十条问题。目标不是把界面做得一模一样，而是证实三个事实：资料找得到、工具调得通、错误不会悄悄吞掉。

迁移的单位不是“一个机器人”，而是让它能持续工作的五类资产。

把失效入口当成一次线上事故处理

停服当天还有一件事比导出更靠前：列清楚用户从哪里进入这个智能体。官方特别点名了公众号、服务号和微信客服；但团队自己接上的网页挂件、菜单入口、二维码、运营话术和自动回复，也很容易被遗漏。

可以开一个很短的处置单：入口地址或菜单名、当前现象、负责人、临时替代动作、确认时间。对外入口如果已经失效，先给出人工渠道或明确的服务调整提示；对内入口则把调用方和失败日志留档。这样做不是为了留一份漂亮的表，而是避免用户继续提交问题，团队却误以为“最近没有咨询”。

导出的对话记录同样别直接丢进一个人人可见的共享盘。它们往往包含用户提问、业务上下文甚至联系方式。迁移测试只需要其中的代表性样本，应先按公司的数据处理规则脱敏、缩小访问范围，再作为回归集使用。历史数据保存得越完整，越需要把谁能看、保存多久、何时销毁写清楚。

再补一个小动作：给每一批导出文件留下载日期、文件大小和校验值，外加一份内容清单。不是为了把迁移做成合规表演，而是以后发现缺了一个知识库附件或一条工作流时，能判断它从来没导出，还是在交接里丢了。可追溯，才谈得上补救。

选替代平台之前，先写出不能丢什么

腾讯在公告中给出的相近能力包括腾讯云智能体开发平台（ADP）和公众号智能回复，也提供迁移权益与对应指引。它们是否适合，取决于你原来依赖的功能，而不是平台名称是否听上去相近。

如果原来的智能体只是把公众号文章接进知识库，重点应是内容同步、权限和答案质量；如果它要调用企业系统，重点会变成鉴权、幂等、审计与失败回退；如果它承担客服入口，优先级则是渠道切换、人工接管和首响体验。

所以别先问“能不能一键迁移”。先列一张不可妥协清单：必须保留哪些渠道？哪些工具调用不能丢？哪些资料有权限或保密要求？谁有权在回答越界时接管？替代方案能逐项接住，才是迁移；接不住，就把它当成一次重建，而不是导入任务。

这也是今天最现实的判断：平台停服固然突然，真正昂贵的不是换一个后台，而是在没有验收样本和入口兜底的情况下，把一套已经承担业务的智能体直接搬过去。

官方把导出窗口留到了明年 1 月 9 日，时间并非只够“下载一下”。把它用在一次可恢复性演练上，才不会在下一次平台变动时，又从一个压缩包开始猜。

你们团队的智能体迁移包里，最早被忽略、最后最难补的那一项是什么？