跑过长时间 agent 的都懂一个事：问题不出在第一天。第三天、第四天之后，状态就开始解释不清了——某个条件是哪一版历史里的组件设的，某次权限授权之后忘了回收，没人给这些变更写记录。你只能事后翻 log，而且翻到了也未必能证明你翻到的就是当时的事实。这些事分散在无数张工单里，表面症状五花八门，底下是同一件事：agent 跑得越久，它内部状态的可审计性就越差，直到某次脱轨把整条链路打崩，你才后知后觉地意识到——状态和代码一样，需要变更记录。
arXiv 上刚有一篇论文正面处理了这个问题。编号 2608.11632，Jun He 和 Deying Yu 写的，标题叫 Continuity Kernel，九页正文加六页附录。它在干的事非常认真：把 agent 状态的连续性定义成一个协议问题，而不是又一个工程技巧。
它的核心构造是把两件事拆开：候选的提出，和状态的激活。任何组件都有权基于当前分支头提出一个类型化更改，哪怕你不信任这个组件，也可以提；但能不能装上，提出者说了不算。一次激活要走一个短事务：重新验证所有权、前状态权限、新鲜度、效果唯一性，四样都通过了，分支头才原子推进一格，把这个已接受的单元装进历史。四种处置结果里只有一种能算数，就是提交；拒绝、隔离、延迟，一律不动当前分支。
这套抽象的全部意义，用一句话说就是：状态提交不再取决于“谁写的”，而取决于“协议认不认”。
作者对连续性的定义值得逐字抠：被接受分支头的未中断且经授权的谱系。三个限定词没有一个是多余的。未中断：中间断过片的不算连续，断点续传在这个定义里站不住脚；经授权的：光时间上连得上还不够，每一跳都得有权限依据；谱系：连续性不是某个时间点上的属性，是一条有待追溯的线。读到这里我被一个即视感击中而且收不回去——这个定义放到 git 的 commit 历史上，逐字成立。git 历史就是一条未中断的、经授权的、从祖先提交一路下来的谱系，只不过 git 管的是代码，CK 管的是 agent 的状态。
四项验证里，我盯上的是所有权和新鲜度的组合。光查所有权是不够的：一个组件昨天还有权改某个字段，今天权限撤了，但组件带着昨天的身份，基于今天的新状态再来提交一次——只查“能不能改这类东西”的权限系统会放行。新鲜度挡另一边：你基于的状态已经离当前谱系很远，在那个旧快照上的改动搬到今天不再有意义。两个合起来，才拦得住“拿过期授权打新状态补丁”这一类事故。
效果唯一性是个容易被低估的检查。我读下来的理解是它防的是同一件事的换皮重提：同一个修改，第一次叫“权限设置更新”，第二次换了个名字叫“权限配置修正”，如果协议只看提交标题而不校验实际效果，这类提交是可以蒙混过关的。分布式系统里有一个亲戚叫幂等，但幂等防的是重复执行，这里防的是同一个效果被指认为两个不同效果装进状态。agent 状态里“同一个问题被两个不同的补丁各修了一遍”这类冗余混乱，在提交时就被拦掉了。
四种处置的态度梯度也值得停下看一眼。具体语义我不敢打包票，但“拒绝、隔离、延迟”这三档能读出作者的态度：拒绝是明确不允许；隔离是拿不准，先不推进分支头但保留候选；延迟是当前条件不具备，等下一个窗口重新验证。能把不确定的情况分流而不是一律拒绝，说明作者清楚提交依据会随时间变化。状态治理处理的对象不是单进程内存，是一个多人协作、还混着不可信参与者的仓库；处理这种对象的语法不应该是指令式的，应该是协议式的。
验证部分作者用了有界可执行模型，跑了两百八十万个可达状态、五百五十万个状态转换，没有发现不变量违反。数字本身别太当真——它验证的是规范的模型，不是现实世界的实现——但这说了另一件事：作者把这份协议当规范写，然后请机器验证规范自身的自洽性。这个行业里大多数 agent 状态方案还在“能跑就行”的阶段，愿意先把安全属性机械地钉在纸上的不多。十五张表把参数拆得很碎，读的人可以照着重建出他们验证过的那个模型。
这里得认一个修正。几周前我还判断 agent 的状态管理只是壳层的工程细节，不值得单独分层。这篇论文逼我改了分类：当有人开始用形式化语言定义状态连续性的时候，这件事就已经具备协议层问题的形状了——工程细节容不下这么重的抽象。
放回三层棋盘看，CK 的落点不在模型层。全文不假设任何模型能力，它假设的只有“有组件在提更改、有状态在被验证”；也不在壳层，壳层管的是工作流怎么编排，CK 管的是跨天跨周的状态资产。最贴近的位置在场景层往纵深探一点：它回答的是“一个跑了很多天的 agent，凭什么值得你信任它当前的状态”，也就是可信执行环境那一块。去年这个时候 MCP 正在被各家接纳，其实我们当时就在讨论同一条曲线的更早一截：agent 的主战场正从模型能力迁移到“谁能提供可信的执行环境”，沙盒、权限、审计这三件套里，权限和审计的协议化正在发生；这篇论文是这条线上一份相当完整的蓝图。
要说这套方案让我想什么，第一反应还是 git。git 之前共享代码，就是“谁最后推谁负责”，没有任何变更层的可审计性；git 把提交变成基础设施以后，每个开发者的工作流从第一天起就自带完整谱系。数据库事务也是同一件事：把正确性的责任从每个操作的实现细节里抽出来，塞进统一的提交协议，并发系统才从“希望没事”变成“设计为没事”。agent 状态目前正处在 git 之前那个阶段：谁最后写谁负责，出事了翻 log，翻不到就认了。CK 这类协议若成形，就是给状态世界立了一份 git——它具体以什么形态活着我不确定，但“状态和代码一样需要可审计的提交”这个前提，我找不到反例。
顺着这个前提往前看，接下来几季要盯的是协议以哪种形态落地。第一种，某头部壳层把 CK 类机制吸收成私有实现，拿可回溯性和审计能力当产品卖点——这条路离现在厂商的动作最近，大家本来都在堆审计功能，只是还没人把它协议化。第二种，独立的托管组件，做状态连续性服务，中小团队不用自己实现协议，按量付费——这个受成本结构驱动，适合做成中间件。第三种，开放协议路径：某家先做成产品级事实标准，再把协议边界开源，像 MCP 那样先由一家带跑、后来各方接入——驱动它的是整个行业对状态可移植性和统一审计的需求，代价是头两年的功能差异化要匀一部分出去。
如果让我押，我押第三种，但不押在某个抽象的标准组织上；我押的是某家现在还在堆审计功能的壳层会先把它做成协议。MCP 的第一版也是从一家公司里长出来的，跨厂协议化是后来的事。状态治理大概率走同一条路，前提是那家的品类位置撑得住从功能到协议的这段攀升。接下来半年到一年要盯的信号很具体：头部壳层还在把“回溯/审计”当一个功能列表项在做，还是开始谈谱系、谈激活事务、谈状态提交的权限验证。如果是前者，上面三种路径都得往后拖。
边界也得划清：这篇论文，我读的时候是当规范读的，不是当实现读的——它验证过的那个模型离真实产品状态边界还有很长的路。但它的核心断言，“未受管控的更新会导致旧状态覆盖新状态、改动不留审计痕迹、组件顺手给自己升权限”，这是我见过的对这个行业现状最准确的描述之一。它没有无中生有地造敌人，它把一个一直存在、一直被“工程细节”这个标签压住的问题，搭了一个正经的抽象。“护城河搬家”讲很久了，从模型层往场景层搬；搬的那箱货里，应当有一件叫状态治理的东西。等哪家壳层拆开这箱货，这篇论文就是一份提前写好的说明书。如果到明年这个时候，状态治理还没进任何主流壳层的 roadmap，而模型侧的上下文机制已经靠自己的记忆力把长跑状态混乱消化掉大半——那这个判断就该扔掉，说明这一层被上层直接蒸发掉了，比被下层夯实更快。在那之前，我按协议层来对待它。