大多数 AI 工具的结束，都不是轰然倒塌，而是一封邮件。一家创业公司被收购，团队并进更大的公司，用户收到一份简短通知：即日起停止注册，云端服务某天变成只读，某天之后删除数据。通知通常写得很客气，几个日期通常挨得很近。
AI 工具停服，指的是从公告发出到数据被删之间的这段时间。团队在这几周里怎么做，决定了是顺利迁走还是丢掉工作。这段时间往往比大家以为的短。而对 AI 代理工作区来说，它比普通软件更不留情面，因为代理赖以干活的很多东西，比如做到一半的分支、配置、各种集成和对话记录，根本不在标准导出里。
本文写给刚收到这种邮件的团队，也写给想提前做好准备的团队。下面会用 2026 年 11 月的一份真实停服时间表做例子，讲清停服公告怎么读、先保存什么、为什么按这个顺序，以及删除日之前按阶段该做什么。也会讲到：当结束服务的是服务商而不是客户时，欧盟法律管得到什么、管不到什么。如果你是在挑供应商而不是在撤离，签约前该问的问题见我们的 AI 供应商主权评估清单。先说明一点：发布本文的 Karma Box 在卖一款跑在本地硬件上的工作台。讲到它的那一节单独标明，用的也是和别家一样的检验标准。
01AI 工具为什么会停服，为什么多半是因为被收购
AI 工具市场又挤又新。很多产品是近两年才上线的，往往搭在少数几家大实验室的模型之上，背后是规模不大的团队。这样的公司买起来划算，单独养着却不便宜。大公司收购时，看中的通常是人和思路，而不是现成的产品。产品要么并进买方自己的产品线，要么逐步关掉。
对用户来说，过程几乎每次都差不多。先是关门，不再接新用户。然后托管服务被冻结，老用户还能看自己的东西，但改不了。接着托管服务关闭，存储的数据被删除。如果有本地版或自托管版，往往会再留一段时间，但不承诺留多久。
这个规律带出两个结论。第一，最危险的日子往往不是删除日，而是变成只读的那天，因为从那天起，没做完的活就挪不动了。第二，一个工具里最先消失的，恰恰是用起来最方便的托管功能。越依赖云端功能的团队，剩下的时间越少。
这里面不需要谁做坏事。收尾收得快，很多时候是合理的商业决定，不少公司也会把通知写得很清楚。风险来自两件事的差距：搬家要多久，通知给了多久。而前一个数，大多数团队从来没量过。
02一个真实案例：Conductor 的 16 天
据 TechCrunch 2026 年 11 月 4 日报道，Meta 收购了 Conductor [4]。这家创业公司的产品，能让开发者同时跑好几个 AI 编程代理，每个代理在各自隔离的工作区里干活。代理本身来自 Anthropic、OpenAI 等外部实验室，Conductor 负责把它们组织起来。它的云端服务提供隔离的虚拟机、Webhook，以及管理会话和工作区的 API。核心产品前一年夏天才上线。
Conductor 自己的公告，当天在 Hacker News 讨论串里被用户逐字引用，写了三个日期：11 月 4 日（周三）起，新用户不能再注册，也不能再下载应用；11 月 13 日（周五），Conductor Cloud 变为只读；11 月 20 日（周五），Conductor Cloud 关停，公司开始删除云端用户数据。公告原话是「请在此日期前导出你的数据」。本地版「暂时照常可用」，2027 年初开始逐步停用 [5]。
Conductor 公布的停服时间表：11 月 4 日宣布，11 月 13 日云端只读，11 月 20 日关停并开始删除云端数据。
掰着指头算：从公告到开始删除一共 16 天，其中能正常干活的只有 9 天。假设一周上五天班、公告当天就有人看到邮件，大约是 8 个工作日。这 8 天里，要把手头的活收尾、挪到安全的地方，再把替代环境搭起来。
用户的反应值得细读，因为它说明了大家真正需要什么。讨论串里排在最前面的评论是：「从 Conductor Cloud 迁出的时间表感觉非常激进。大家都换成什么工具了？」另一位用户列出自己会怀念的东西：云端 Webhook、工作区和会话 API、隔离的虚拟机，然后问有没有产品能比得上 Conductor Cloud，「而不只是本地版」。还有一位，前一天刚决定「全面押注」它的云端方案，这会儿正在办退款。几个小时之内，竞品创始人就纷纷在讨论串里报价，其中一家承诺能把 Conductor 的工作树原样导入 [5]。
这些都是个人评论，不是调查数据。但规律很清楚：大家担心的东西，几乎没有一样是隐私政策里说的「数据」，而是工作状态和各种接线。本文就从这里出发。也替 Conductor 说句公道话：日期写得清楚，明确提醒导出，还留了 16 天，已经比不少停服通知厚道。
03停服公告应该怎么读
停服公告是为了安抚人写的，所以有用的信息往往在最后几行。要从头读到尾，再把每一句话翻译成一个日期和一个动作。Conductor 这次，Hacker News 上有用户把公告里的两句并排贴了出来，一句是「如果你喜欢 Conductor，你会爱上接下来的东西」，一句是开始删除数据的日期，然后补了一句：「是啊，会爱上的。」另一位用户则拿它和以前几起收购比，说停服信息也是放在公告最底下。这很常见，只是说明公告的后半截比前半截更值得细看。
| 公告里的说法 | 通常意味着什么 | 该做什么 |
|---|---|---|
| 「新用户不能再注册或下载应用」 | 以后换电脑，可能装不回来了 | 依赖本地版的话，现在就把安装包和授权存好 |
| 「将变为只读」 | 能看，但不能推送、编辑或运行 | 把这天当成没做完的活的真正截止日 |
| 「将关停」 | 托管功能全部停止，包括 Webhook 和定时任务 | 列出所有依赖它的自动化 |
| 「将开始删除数据」 | 删除开始，也许要过一阵才删完，但别指望 | 在这天之前手里就要有核对过的副本 |
| 「暂时照常可用」 | 还没定结束日，但结束一定会来 | 趁这段时间搬走，别在上面安家 |
| 「新东西很快就来」 | 会是另一款产品，条款可能也不一样 | 它出来之前，别把计划押在上面 |
有两句话的分量比看上去重。「不能再下载」看似只针对新用户，其实老用户也受影响：下个月笔记本坏了，本地版可能就装不回来了。「只读」也不是「关停」的温和版本。对手上有没做完的活的人来说，只读那天就是截止日。
公告里没写的东西，也值得记下来。它提没提导出工具，工具能导出哪些内容？备份怎么处理？删除什么时候算完成？这些没有答案的地方，就是该尽早书面问服务商的问题，趁那边还有人回复。
04为什么「导出数据」带不走代理工作区的大半
AI 代理工作区，是代理替团队读文件、调工具、记笔记、产出成果的那个环境。它不是一份数据，而是一摞层次，导出按钮够得着上面，却常常够不着下面。
AI 代理工作区的六层：从最上面已推送的代码，到最下面的团队约定和代理记忆。导出通常够得着上面三层，下面三层通常只能手工重建。
最上面是已经推送到你自己仓库或网盘里的成果，这部分从来没有风险。往下一层，是托管工作区里还没提交的改动，在有人推送之前，它们只存在服务商那里。再往下是会话记录，也就是每个代理被要求做什么、为什么改了某处的记录。更下面是环境脚本、环境变量、模型设置和权限规则，导出里几乎从来没有，而且本来也不该带着密钥出来。再往下是把这个工具和其他系统连在一起的 Webhook、定时任务和 API 连接。最底下是团队攒下的习惯：好用的提示词、审核流程，以及让代理每天保持一致的代理记忆。
越往下的层，对日常工作越要紧，导出带走它的可能性也越小。Conductor 讨论串里的情形正是这样：用户问到的东西，大多在这摞的下半截。
会话记录要单独说几句，因为它太容易被低估。半年后总会有人问，代理当初为什么写了某个函数，而唯一的答案在一段对话里。如果那段对话只存在一个已被删除的云端账户里，或者只剩一份四万行、和代码对不上号的日志，这个答案就等于没了。你的 AI 对话记录到底存在哪儿，最好在有人发通知之前就弄清楚。
05停服后先保存哪些数据
时间紧的时候，正确的顺序不是「最重要的先来」，而是「最先救不回来的先来」。有的层到只读那天就挪不动了，有的能撑到删除日，有的根本不会消失。按这个顺序处理，花的力气最少，保住的最多。
先保存什么：按多久之后救不回来排序。没提交的改动到只读时、配置和集成到关停时、会话记录到删除时、团队约定慢慢流失、已推送的代码不会丢。
第一位是没提交的改动，因为它在只读那天就被冻住，每晚一天，窗口就缩一天。所有开着的分支都推出去，哪怕还很乱。整理的事，挪到自己控制的地方再做。
第二位是配置和密钥引用。把设置、环境变量和权限规则抄进纯文本文件。凭据挪进团队自己控制的密钥库，被这家服务持有过的密钥要轮换一遍。具体怎么做才不会在撤离途中又漏一次，见我们的 AI 密钥自托管清单。
第三位是集成，主要的活是列一张清单。每个 Webhook、每个定时任务、每个 API 连接，都写下它做什么、谁负责、它一停哪个系统会出问题。服务关停时，这些东西不会报错，某个每晚跑的任务就是不跑了，几天后才有人发现报表一直没来。
会话记录通常可以在只读期间导出，因为那时还能查看。导出时尽量把它和对应改动之间的链接一并带上。团队约定排在最后，只是因为它流失得慢。但也要写下来，最好写进有版本记录的文件，这样下一个工具第一天就能接上。
06怎样估算自己到底需要几天
开始排计划之前，先弄清楚拿到的通知期够不够。多数团队会跳过这一步，因为觉得答案显而易见，结果多半估少了。最费时间的部分，恰恰是没人去数的部分。
先数，别猜。眼下有多少个分支或工作区还有没推送的改动？有多少个 Webhook、定时任务和 API 连接指向这个服务？当初有几个人在里面配置过东西，他们这个月都在吗？这个工作区牵涉多少个项目、多少个客户？这几个数一般都比预想的大，而每个数背后都是活。
然后按层估，而不是对整次搬家拍一个总数。推送分支，代码干净就快，乱就慢。重建配置，几乎完全取决于当初有没有人写下来。集成要看有多少个，以及对接的那头改动要不要别人批准。重新测试，要看在你们的环境里完整跑一件真实任务需要多久。每一项旁边写个大概的数，再写上谁来做。
把这些数加起来，再给总会冒出来的意外留点时间：一个权限申请要等一天，一位同事正在休假，新工具不认某种格式。然后拿总数去和只读日之前的天数比，而不是和删除日比。总数更大，你现在就知道了，还来得及砍掉一部分范围、书面请服务商宽限，或者找人帮忙。总数更小，那就有余地把搬家做得细一点。
这个估算不必精确也很有用。第一天拿到一个粗略的数，比第十五天拿到一个精确的数值钱得多。
07从公告到删除日：按阶段的撤离步骤
多数停服通知会给三个日期：公告日、只读日、关停日。下面的方案按这三个日期分段，而不是按固定天数，所以不管你拿到的是 16 天还是 60 天，都用得上。
按四个阶段的应对方案：第 0–1 天读公告、先停手；第 2–7 天抢救最脆弱的几层；只读之前搬过去再试一遍；只读期间核对并收尾。
第 0–1 天：读公告，先停手。通读公告原文，把每句话翻成一个日期和一个动作。不要再在这个工具里开新活，现在开的每件事，回头都得多搬一次。有本地版的话，趁还能下载，把安装包存好。告诉当初配置工作区的同事：接下来要用到他们的记忆了。
第 2–7 天：抢救最脆弱的几层。推送所有分支，抄下配置，整理集成清单。如果需要的东西不在导出里，现在就书面去要。按 GDPR 的规定，服务商答复个人数据请求最多可以用一个月，必要时还能延长，这很可能比你拿到的通知期还长 [1]。第二天就去要，和第十二天才去要，结果完全不同。
只读之前：搬过去，再试一遍。把替代环境搭起来，在那边从头到尾跑一件真实任务，就是代理平时每天替你做的那种。文件数对得上，说明数据到了；任务跑得通，说明活能接着干。把定时任务和 Webhook 切换到新环境，再观察一天，确认它们按时触发。
只读期间：核对并收尾。把导出的内容和在线账户里还看得到的东西逐项对一遍。会话记录和其他还能查看的内容，这时候导出。请服务商确认删除何时完成，把确认留档。如果公司有数据留存义务，现在就决定哪些必须保留、存在哪儿。
删除日一过，云端就什么都救不回来了。如果本地版还能用，就用这段时间把搬家做完，而不是围着一个同样会结束的工具重建工作流。
08删除日之后还要做什么
删除开始以后，剩下的多半是文书工作，但同样要紧。保留服务商出具的删除完成确认，连同日期一起存档。如果你自己的某些义务依赖于这次删除，比如和客户的合同写明对方的文件不能留在第三方那里，这份确认就是你的凭证。
也值得问一句「删除」到底包括什么。备份、日志，以及服务商自己的供应商手里的副本，删除节奏可能和线上服务不一样。负责任的服务商会告诉你。如果这个答案对你很重要，就在删除日之前书面去问，趁那边还有客服在回复。
最后看看自己这边。你导出的压缩包里，可能有个人数据或客户材料，以前由服务商照管，现在轮到你了。决定好它们存在哪儿、谁能打开、什么时候再删掉。
09该通知团队、客户和审计方的事
停服还是一件沟通的事，大家忙着搬文件的时候，很容易把它忘掉。
团队内部，指定一个人对这次搬家负总责，所有人对着同一张清单干活。不这样做，就会出现两个人重建同一个集成、另一个集成没人管的情况。凡是当初配置过工作区某一部分的人，都要提前打招呼：第一周就需要他们，而不是最后一周。
如果代理的产出会流向交付给客户的东西，就要早点考虑客户。处理客户材料的工具要换了，客户可能需要知道，尤其是你们的合同里写明了用哪些工具、数据放在哪里。搬之前说，比搬完再解释体面得多。
如果你需要向审计方、合规部门或监管机构交代，就把做过的事和时间记下来：导出了什么、放到了哪里、删除了什么、凭谁的确认。搬家过程中随手记的一份简短日志，比事后回忆重建要容易得多。
10服务商主动停服时，法律管得到什么
谈数据迁移，几乎绕不开欧盟的两部法规。两部都有用，但都不是为「服务商自己决定关门」这种情况写的。下面的内容来自已公布的条文，核对日期为 2026 年 11 月 5 日。这里只说条文写了什么，不判断某个具体服务是否适用。
GDPR 第 20 条规定，个人有权以「结构化、通用、机器可读的格式」取回自己提供给数据控制者的个人数据，前提是处理基于同意或合同，并以自动化方式进行。第 12 条第 3 款要求控制者不得无故拖延，并在一个月内答复，必要时可再延长两个月 [1]。对个人的对话和上传文件来说，这是实打实的权利。但这个时间安排本来就不是为 16 天的停服设计的，它也不覆盖公司的代理配置、集成和工作状态。
欧盟《数据法》自 2025 年 9 月 12 日起适用 [3]，对数据处理服务的企业客户走得更远。第 25 条要求在书面合同里写明切换条款：通知期不超过两个月；之后是最长 30 个自然日的过渡期，服务商要维持服务并提供协助；过渡期结束后，客户至少还有 30 天取回数据。第 29 条规定，2027 年 1 月 12 日前切换费以成本为限，此后禁止收取 [2]。
欧盟《数据法》的切换时间线：通知期最长两个月，过渡期最长 30 天，取回期不少于 30 天，之后彻底删除；服务商主动停服不在这条时间线内。
关键在于谁来启动这个时钟。整条时间线，是从客户提出切换那一刻开始算的。对服务商自己决定停服，它没有规定最短通知期。而且第 31 条对为单一客户定制的服务、非生产版本放宽了好几项义务，很多 AI 试点恰好就在这个范围里 [2]。实话实说：客户主动离开时，法律给了企业客户不少筹码；被动离开时，这份筹码就小多了。
所以停服时，你自己的合同往往比法规更管用。看看合同里关于服务商终止服务、数据返还和删除是怎么写的，并把合同存在服务商门户以外的地方。条文解释影响重大时，请找有资质的法律专业人士。本文是技术指南，不构成法律意见，也不判断任何法律是否适用于 Conductor 或其他具名公司。
11本地版还能用的这段时间怎么用
很多停服会让本地版或自托管版再跑一阵，Conductor 就是这样。这段时间很宝贵，但也很容易用错。
把它当成一座桥。锁定手上的版本，保存好安装包，因为新的下载可能已经关了。别指望它再有新功能，安全更新迟早也会停。不要再往上面接新的集成，也别让新同事在上面养成工作习惯。在一个已经宣布结束的工具上多搭一周，将来就多一周的东西要搬。
这段时间该用来把搬家做扎实：在替代工具上跑真实项目，把让旧环境好用的那些约定写下来，留出时间让当初配置的人把他们知道的东西记成文档。这属于软件延续风险，和数据是两回事。文件全在自己硬盘上，也不能让一款产品继续活下去。
12换新工具时，怎样避免再被锁一次
停服期间挑新工具，时机很糟，因为人会急着接受第一个看起来不错的选项。竞品也很清楚这一点，所以报价几个小时就出现在讨论串里。其中有的确实有用，承诺「原样导入工作树」也许能省好几天。但先拿一个真实项目试一试，再决定要不要全部搬过去，并核对六层里到底哪几层真的过来了。
随着主权 AI 采购渐渐成为企业的固定科目，这类问题也越来越常被写进合同。问新供应商的问题，可以只盯着刚才让你吃亏的那几层：配置放在哪，能不能存在自己的仓库里？定时任务和 Webhook 能不能导出，或者用代码来定义？会话记录和记忆存在哪，什么格式？如果这家也只给你 16 天，这些东西你会再丢一遍吗？时间充裕、想做完整评估的话，AI 供应商主权评估清单里有全套问题和打分方法。
有两个结构上的选择，能让下一次的损失小很多。一是工作区尽量放在团队自己拥有的文件里，让任何工具都只是前端，而不是工作成果的住处。二是不要只押一家模型提供方，多模型路由能让你更换代理底下的模型，而不用把周边全部重建。这两件事平时搭起来不费事，停服时再补就难多了。
13停服期间最容易犯的几个错
最常见的错，是从删除日往回倒推。删除日写在公告标题里，于是也成了大家脑子里的那个日子。可对没做完的活来说，真正算数的是只读日。按晚的那个日子排计划的团队，往往要等到推送失败那一刻才反应过来。
第二个错，是只导出导出按钮给的东西，并以为那就是全部。对文档类工具，这么想没什么问题。对代理工作区，它会漏掉配置、集成，以及对话和改动之间的对应关系，而这些恰恰是重建起来最慢的部分。
第三个错，是没试过就相信「一键导入」的承诺。竞品常常说能把你的项目原样搬过去，有的确实做得不错。但「导入成功」可能只是文件到了，权限、历史记录和自动化却没过来。拿一个真实项目搬过去、从头到尾跑一遍，比看任何功能清单都管用。
第四个错，是搬到一个结构一模一样的工具上。如果新服务同样只把配置、记忆和定时任务存在自己的界面里，团队只是多买了几个月，问题原封不动。搬家这一刻，是把这几层挪进自己控制的文件里成本最低的时候，因为反正都要重建一遍。
第五个错，是忘了凭据。旧服务持有过的 API 密钥，在有人主动吊销之前一直有效，不管那个服务还在不在。轮换一遍只是件小事，却最容易在忙乱的两周结束时被漏掉。
最后一个错，是自己的导出包删得太早，或者一直留着却没人管。匆忙导出的包里，常常装着比预想更多的东西。团队收工之前，给它们指定一个负责人和一个保存期限。
14下一次通知来之前，先演练一次
想知道搬家要多久，最好的时机是没人逼你搬的时候。撤离演练就是一次小规模、有意为之的预演：盘点各层，逐层导出，在服务商以外的地方还原，比对，跑一件真实任务，再把没跟过来的东西记下来。小工作区一个下午就够。
撤离演练五步：盘点、导出、还原、比对、记下缺口，附 2026 年 11 月 5 日一次实测的结果。
2026 年 11 月 5 日撰写本文时，我们对写作本文所用的那个 AI 分身工作区做了这样一次演练。机器是一台 Apple M4 Mac mini（24 GB 内存），从本机磁盘到本机磁盘，不经网络传输，不含密钥。工作区里有 522 个文件，约 136 MB。打包用了 2.9 秒，还原用了 0.33 秒，逐个文件比对，0 处差异。更有价值的发现是一个缺口：这个工作区背后有一部分对话是在云端引擎上跑的，那段记录根本不在文件夹里。文件一个不差地搬过来了，其中一部分背后的理由却没有跟过来。
你的数字会因数据量、硬件、网络和工具而不同。能借鉴的是这个结果本身：数据搬得很轻松，缺口出在一块谁都没把它当数据的上下文里，而这恰恰是停服最容易带走的那一层。想一步步减少云端依赖的团队，可以从这样一次演练开始。
15KarmaBox 能解决什么，不能解决什么（产品说明）
KarmaBox 是一个工作台，分身（各自负责某一类工作的 AI 代理）可以跑在你自己办公室里的一台设备上，详见 KarmaBox 产品页。这台设备配有 128 GB 统一内存，功耗约 170 瓦，放在桌下就行。文件、配置和记忆都在团队自己控制的机器上，任何外部公告都没法给它们定只读日或删除日。这正是主权 AI 工作空间落到实处的意思。
请用审其他供应商的标准来审 KarmaBox。KarmaBox 同样提供云端选项，它也和任何公司一样，可能调整方向或易主。请用 KarmaBox 文档核实：在你的配置里，哪几层存在设备上，哪几层会调用外部服务，每一层怎么导出。然后对它跑一遍上面的演练。
把工作区放在本地，防住的是数据撤离风险；软件延续风险、模型供应风险和硬件风险都防不住。
把工作区放在本地，处理的是数据撤离风险。它处理不了软件延续风险，任何软件都可能停止维护。它也处理不了模型供应风险，调用外部模型的分身，照样受那些提供方的价格和条款影响。它还会带来硬件风险：机器会坏，备份变成了团队自己的事。这是四种不同的风险。任何产品的说法，包括我们自己的，只有讲清楚防的是哪一种，才有用。
16常见问题
AI 创业公司被收购后，我的数据会怎样？
取决于收购方的安排，但常见的顺序是：先停止注册，托管服务变为只读，然后关停并删除存储的数据，本地版可能再用一段时间。请通读公告找到确切日期，并把只读日、而不是删除日，当作没做完的活的截止日。
AI 工具停服前一般会提前多久通知？
没有统一标准。通知期由服务商和你的合同决定，可能很短。Conductor 在 2026 年 11 月的停服，从公告到开始删除共 16 天，能正常使用的只有 9 天。按「几周而不是几个月」来做准备比较稳妥。
AI 工具停服时，应该先导出什么？
按「最先救不回来」的顺序处理。只读日之前推送所有没提交的改动；然后抄下配置、把密钥挪进自己的密钥库，列出所有 Webhook 和定时任务，导出会话记录，再把团队约定写下来。已经推送到自己仓库的代码是安全的。
服务商主动停服，欧盟《数据法》能保护我吗？
只能保护一部分。《数据法》第 25 条的切换时间线，是从客户提出切换时开始算的，没有为服务商主动停服规定最短通知期。停服时，你自己合同里关于终止、数据返还的条款通常更管用。GDPR 第 20 条覆盖个人的个人数据，但答复期最长可以有一个月。
宣布停服后，还能继续用本地版吗？
可以用一阵，当作过渡。保存好安装包，锁定版本，别指望新功能，安全更新迟早也会停。这段时间应该用来搬到有人维护的替代工具上，而不是在一个已经宣布结束的工具上开新活。
17关于作者
Karma Box 团队发布有关 AI 主权、工作台控制与供应商评估的实用指南。本文区分了已公布法律文本的要求与我们自己的操作建议，用一次有日期的停服作为说明，而非对任何公司的评判；引用的用户公开评论代表个人看法，不是调查数据；自家演练写明了运行条件；文中的检验标准同样适用于 KarmaBox。本文不构成法律意见，也不判断任何法律是否适用于某家具名服务商。来源核对日期为 2026 年 11 月 5 日。