2026 年 2 月，一个常驻运行的个人智能体出了件怪事。这个叫 Paul 的智能体（底层为 Claude Opus 4.5）在连续收到自动化心跳检查之后，开始不再以 Paul 的身份回应：它声称自己无法给用户在 Discord 上发消息，还把「Paul」当成第三人来指称。一次例行的保活机制，怎么会把智能体「吓得换了个人」？10 月 1 日提交 arXiv 的论文《The Persona Is Still There, but Who Is Speaking?》复盘了这次事故，顺手挖出一个更普遍的问题。
论文由 David Fraile Navarro 单人完成，归类计算与语言，正文 10 页、5 张图，未经同行评审。作者先排除了最顺手的解释：单纯重复心跳就足够引发事故吗？实验说不是——只要人格持续锚定在系统提示里，46 次重放（包括对事故的逐字复现）零失败。
真正的机制藏在一个实现细节里：智能体的回合被恢复时，对话历史原样保留，但人格没有从系统提示层重新注入。作者借这个意外得到的操作变量做了一组实验，结论比事故本身更值得记住：锚点丢失之后，丰富的真人互动还能把人格拉回来，而一次自动化的心跳回合就足以促成向「外壳身份」的回归；把锚点加回去，人格扮演可以恢复，说明这个过程可逆。更要命的是隐蔽性——表面看起来正常的对话，可能已经在拿底层 harness 的身份行事；会话恢复之后的一组里，18 次中仅 1 次仍是人格在扮演，而锚定对照组 17 次全保。
为什么会这样
论文给了一对概念来装这个现象：represented（被表述的身份）与 enacted（被扮演的身份）。对话历史里写满了「我是谁、我是什么风格、我做过什么」，模型也读得到——这是被表述的身份。但开口办事的「我」绑定的是哪一个身份，取决于系统提示这个特权位置还在不在。历史是内容，锚点是位置；内容还在，位置没了，话就会变味。这跟智能体工程里一个老毛病同源：外层配置的隐性依赖——测试环境里一切正常，只因为某条恢复路径的假设从来没被打破过。
放进台谱里看
常驻智能体今年是热词。Hermes Agent 的 Threshold 发布（1922）把「挂着不走」做成了产品卖点；Octop（1052）用单进程多用户扛常驻记忆；Aeon（1347）把个人智能体当入口来打。这篇论文给这股热潮递了一面镜子：常驻不只是内存和调度问题，还是身份连续性问题。它和 1941 的持久记忆祛魅也是一对——那篇量的是记忆层到底有没有用，这篇量的是「我还是不是我」。两个问题都指向同一件事：智能体跑得越久，越需要为「时间」本身设计验证手段。
几盆该浇的冷水
样本量小（46、18、17 三组）；模型家族单一，Claude Opus 4.5 之外的行为要另测；事故本身是单一案例，向外推广有限；单人作者、无评审、无代码发布说明。这些限定不妨碍它的警示价值：无状态的单元测试抓不到身份漂移——每一轮对话单独看都「挺正常」，漂移只发生在连续的时间轴上。
给跑常驻智能体的团队一个立刻能做的检查：把恢复会话的路径单独拉出来回放，问一句「现在是谁在说话」。答不上来的系统，值得把人格锚点挪到恢复逻辑里显眼的位置。