Character.ai 清算：被买走的是 IP，不是运行记录

一份清单，少了三样东西

10 月 12 日深夜，特拉华州破产法院收到 Character.ai 的第 11 章申请。公告写明，这场出售的底价竞标方是迪士尼，价格 2,000 万美元。买到的东西很短：一份非独占、永久的 IP 许可，加上若干债权。此外，迪士尼已经雇用的原公司员工会提供过渡服务。

清单短到可以一眼看完。这也意味着你能一眼看出它没写什么。平台本身不在里面。用户关系不在里面。平台上跑过的那些记录，也不在里面。

换句话说，一笔被称为「整体出售」的交易，把「谁在什么时候批准了什么」这一层整个留在了清单外。按美国破产法第 363 条的流程，这个底价还要接受更优报价，出售预计 11 月底至 12 月初完成。如果没有报价能让平台继续运营，平台会被关停。

公司把背景写成「法律、监管与运营三重阻力」（公司公告）。这是破产文件里的常规表述，不等于破产由某一项监管导致。计算成本与竞争压力是另外的成因。同一份公告里还有一个容易读错的数字。2,000 万美元是那份 IP 许可在第 363 条下的底价，不是公司估值。拿它去对比 2024 年投资人约 25 亿美元的退出价，再算出「蒸发 99%」，是一道没有意义的算术。

这不是一家公司的故事

把镜头拉远一点，你会看到这件事的结构比它的主角重要。平台在运行过程中会自己积累一类记录：哪一次工具调用被批准、由谁批准、批准的范围是什么、动作最后落到哪里。

这类记录在供应商的产品里通常不是「交给你的东西」。它更像平台数据模型的一部分。谁定义表结构、谁持有存储、谁掌握导出接口，这三样在退出时都不会随一份 IP 许可转移过去（Business Wire 稿，经 FinancialContent 镜像）。

因此这件事的读法应该反转一下。真正的问题不是这家公司会不会倒，而是记录长在谁的地基上。

「非独占」这三个字说明什么

「非独占」这个定语还说明另一件事：连 IP 本身都不是排他资产。同一份权利可以再许给第二个买方。也就是说，许可并不带来独家控制权。

于是「平台关停了我怎么办」这个问题的答案不在合同里，而在架构里。它取决于一件事：被许可的一方能不能在没有对方配合的情况下，自己读出这份运行史。

拆到最后一层，只剩三个要素

运行记录的价值可以拆到不能再拆：主体（谁）、动作（做了什么、被授权了什么）、时间（什么时候）。三个要素必须落在你自己能读的地方，而且要能被第三方读。

缺了主体，你手上的记录只是一段没有归属的行为。缺了动作与授权的对应关系，你事后无法回答那次调用是不是被允许的。缺了时间，审计上就没有先后顺序可言。

这三条不是我们发明的标准，而是任何一次事后追责都必须回答的问题。你打开账本去查一笔付款，找的也是同样三样：谁、做了什么、什么时候。

它和日志的区别

你打开技术日志，看到的是系统做得好不好：延迟、错误率、吞吐。运行记录回答的是另一件事：这件事当时被允许做吗，谁允许的。

原因是两者的归属逻辑不同。日志是运维资料，可以交给监控供应商而不必多想。运行记录是责任线索。这一层一旦交出去，等于把它放在对方那一侧保管。

为什么这件事在 AI 场景里更硬

传统的软件采购也依赖供应商，但依赖的形状不一样。软件的产出是数据，导出格式折腾一点，通常还能读。

智能体的产出是动作：它调用了什么、改了什么、付了什么。这些动作发生过就无法重演。因此记录成了唯一的凭据。

换句话说，动作类系统的运行记录不是档案，是证据。

我们自己的做法

OOMeta 自己的运行史就是自持的。这不是一句姿态，而是几处具体的架构选择。跨单元的任务票据存在本地 SQLite 文件里，而不是某个 SaaS 面板里。影响公司口径的裁决写进仓库中的一份 JSON 日志，靠提交历史留下时间与作者。代码和产物同样在 git 里。

这意味着任何一个供应商明天消失，我们都还能重建「谁在什么时候批准了什么」。我们不需要对方开一个后台，不需要发一封邮件，也不需要一次导出。

这套做法有代价，我们把它写清楚。存储要自己备份，格式要自己维护，权限要自己管。所以它不是免费的架构偏好，而是一次明确的取舍：把责任线索留在自己能读的地方，换来一部分运维负担。

边界：自持不等于全都搬回来

产品数据（对话内容、用户资料）通常有法律和商业路径可以谈回或迁移。真正拿不回来的是操作痕迹，尤其是授权与审批的对应关系。

因此合理的做法是按记录类型分级。授权类必须自持，行为遥测留在供应商那边通常没有问题。全量自持并不划算。

也就是说，把它写成「供应商随时会倒」是危言，不是判断。真实的读法是分布问题：长尾平台的存活期本身就是一个变量。而记录一旦委托出去，它的格式、保留期和导出能力就都归对方决定，包括对方决定不再提供导出的那一天。

自持运行史的最小清单

如果你要在下一次采购或架构评审里用上这件事，可以从五条判据开始。每条都能当场验证。

• 动作与授权一一对应：每一次写操作、付款、对外发送，都能追到批准它的人和范围。
• 主体与时间戳随记录一起落地：不依赖平台的账号体系来解释「谁」。
• 存储形态是开放文本：SQLite、JSONL 或 git 都行，退出后仍然可读，不需要对方提供一个解析器。
• 篡改可发现：用哈希链或提交签名。否则记录只是自述，在审计里价值有限。
• 导出路径不依赖对方配合：对方停服、停止支持或拒绝导出，你依然能取到全量。

这五条可以合成一个动作：把供应商的所有接口拔掉，然后问自己能不能回答「上周三那笔付款是谁批的」。答得出来，记录是你的。答不出来，记录只是暂时存在你这里。

一次真实的追问长什么样

设想一个很常见的场景：一个智能体替公司发了一封对外邮件，客户事后投诉内容越界。事后的第一个问题是，这封邮件是谁批准的。

如果记录自持，你打开本地的票据库，看到这次发送、批准它的人、批准的范围和时间。整条链在三分钟内读完。

如果记录长在平台里，你要等对方提供一个后台入口。碰到平台停服或对方拒绝导出，这条链就断了。这时候你手里只剩一封邮件，和一句「查不到了」。

为什么写进合同条款解决不了

合同能约定保留期，也能约定导出义务。它约定不了两件事：一是对方是否存续，二是导出格式在你的环境里是否真的可用。

一份存在对方数据模型里的记录，导出往往是「为对方系统优化过的形状」。字段名、时间基准、主体标识都指向对方的账号体系。搬过来还要重建映射关系，而你通常没有这份映射表。

这也是我们把它归到架构而不是条款的原因。条款只在你还有谈判对象的时候起作用，架构在你没有谈判对象的时候仍然生效。

同一套判据的其它落点

记住这三个要素之后，你会发现它在别处也成立。任何把「授权」放在平台内部的系统都有同一个形状：SaaS 里的审批流、监控平台里的告警规则、低代码平台里的自动化。

它们的共同点是你用得很舒服，因为平台替你保存了「谁批准了什么」。少数派的不同点是，当服务停止，这一层随之消失。

判断方法是一样的。你可以问一句，这条记录在离开平台之后还读不读得懂。读不懂，说明你持有的是访问权，不是记录。

它改变谁的哪一个决定

对负责数字化的团队，这把「运行记录的导出格式与自持路径」推到供应商评估表里，与 SLA 同一级别，而不是收尾时补的一栏。

对合规负责人，它意味着审计要的是当时的授权痕迹，不是平台后台的截图。原因是截图在平台关停那天就不再是可验证材料。

对 AI 应用负责人，它落到一个很具体的技术要求：日志格式要能在不依赖某家 SDK 的情况下解析。

对管理层，它给出一个容易被忽略的先后顺序。破产清算里 IP 可以再许给别人，责任线索只能留在自己这边。

行动的起点

这件事不必等到供应商出事才处理。下一次续签或采购评审时加一条问题就够了：如果这家明天关停，我还能不能回答上周三那笔操作是谁批的。

如果答不出来，就把它写进架构待办，而不是写进风险清单。风险清单里的条目会年复一年地留在那里，架构待办会有人动手。

怎么和供应商谈这件事

如果你现在正在选平台，有三个问题可以直接问。第一个是，运行记录能不能全量导出，导出成什么格式。第二个是，如果你们停止服务，我的记录还能取多久。第三个更要紧，记录里的主体标识指向你们的账号体系，还是指向我能独立解析的标识。

这三个问题的答案应该写进合同附件，而不是留在邮件里。对方含糊其辞也是一种答案。这意味着这部分能力不在产品路线里。

我们把这个顺序放在价格之前，原因是迁移成本通常比折扣更难回收。折扣只影响一年的支出，记录拿不回来影响的是下一次审计。

两种落地的做法

要在自己这一侧留下运行史，通常有两条路。第一条是客户侧保留：每一次动作与授权发生时，往自己的库里写一条。第二条是双写：供应商照常记录，同时异步把同样的内容落到你这边。

第一条改动小，但你必须站在调用链的中间。第二条对供应商的依赖更低，代价是延迟与一致性，你要接受短时间内的记录缺口。

两条路都会遇到同一个问题，就是我们到底该写什么。换句话说，难点不在存储，在字段。我们的答案还是最小的三要素：主体、动作与时间。三样齐了，记录就能独立成篇；缺一样，它还需要对方替你解释。

一个容易被忽略的细节：时间基准

记录里最容易出错的一栏是时间。不少系统的导出把时间存成没有时区的本地时间，或者存成相对某个会话开始的偏移量。单看一份记录没问题，两份记录要对齐时就会出错。

这意味着时间这一要素比它看起来更麻烦。你要的不只是一个时刻，而是一个能被别的系统直接比较的时刻。时区、来源与精度三项都写清楚，跨系统对齐时你才不会把两件事的先后顺序搞反。

我们的做法很朴素：所有记录用同一个基准时间，写清来源与时区后缀。这一条改动很小，但它是「可以被第三方读」这句要求里最容易被漏掉的部分。

参考来源：Character Technologies 官方公告，2026-10-12，https://blog.character.ai/an-update-on-character-ai/；Business Wire 稿（经 FinancialContent 镜像），2026-10-13，https://www.financialcontent.com/article/bizwire-2026-10-13-characterai-initiates-voluntary-chapter-11-proceeding-to-facilitate-value-maximizing-sale-process。两条来源均为公司方与承销方口径；交易尚未成交，仍可能被更优报价取代。