圈内内参。这期不碰大厂内部，记一件更小但更锋利的事：有人在 dev.to 上写了篇《I Built a Better Codex Pet Than OpenAI Did》，用一只只跑 Linux 的 alpha 阶段桌面宠物，把 Codex Pets 的“存在论”顶出来了。结论先放：Codex Pets 叫了“宠物”这个名字，但它没有持久状态；Mochi 的作者抓住的裂缝不在“做得好不好”，在她把复杂度全押在了“自己的状态”上。信源交底：这期没有任何内部消息，全靠一篇公开文章、它的评论区、作者主页，所以公开能核验的部分我标确认，剩下凡是判断都标分析。
Codex Pets 的公开信息，可以直接记（确认）：OpenAI 在今年五月推了这个功能，给编程 agent 配一个浮层式可视形象，跑 Windows 和 macOS，实时显示 Codex 状态，任务完成或需要输入时发通知。首发八个内置宠物，支持用户上传图片生成 AI 动画风格定制。Mika 在文章里也交代了，她对 Codex Pets 的了解来自公开报道和文档，不是内部渠道。这点我反而觉得是要记的——她清楚自己是在外部看自己的批评对象。
但问题根本不在“看没看全”。问题在自定义宠物到底是个什么东西。Mika 拆得很直接：自定义宠物就是一个清单文件加一张精灵图。换句话说，你上传的、AI 帮你动画化了的那个形象，本质是个换皮开关。它绑到单个 agent 线程的状态上，没有跨会话的持久内部状态，也没有独立于 Codex 状态之外的行为。评论区的 Onizuka 管它叫“带尾巴的状态灯”，Mika 在评论里认了这个定位。
（分析）这个批评想成立，得先接受一个前提：宠物的价值应该在于它有一个“自己”的状态，而不是 agent 状态的投影。我观察下来，这个前提在这件事上站得住，原因是 OpenAI 自己给东西起的名字——Pets，不是 status indicator，不是 activity icon。起名就是承诺。你叫了“宠物”，用户就有权问一句“它记得我吗”。Codex Pets 目前不记得。
Mochi 的作者给出的方案是什么，她写了不少，但真正有信息量的不是“我这个更好”，是她把复杂度花在了什么地方。按 Mika 的描述，Mochi 的核心是一个单一权威行为状态机，用来协调点击、拖拽、睡眠、打字检测、媒体播放、应用上下文感知这几个相互竞争的系统。注意这个措辞，“相互竞争”。这是她那篇里我觉得最有信息量的一句话。因为任何做过桌面驻留程序的人都清楚，不是这些功能本身难，是它们同时跑起来之后互相抢状态难。点击打断拖拽、睡眠打断所有、媒体播放的时候要不要继续检测空闲、应用切换的时候宠物该不该抬头，每件单独做都简单，全放一起就不是一回事。
Mika 没有展开状态机的内部设计，但给了一个很具体的信号：她写的大部分代码文档与生命周期和所有权有关。两个例子——“确保被中断功能的过期动画回调不会再次触发”“菜单收起后不留下不可见的输入抓取”。（分析）这两个例子选得很诚实。会提到过期动画回调和不可见输入抓取的人，不是在写 demo，是在处理真实桌面环境的边界条件。这种 bug 只有运行时间足够久才会冒出来，而且一旦出现，用户看到的是一只有时候会自己动一下的幽灵宠物。这比任何架构图都更能说明 Mochi 的设计冲动来自亲身体感。
评论区有一个追问值得单独拎出来。Joseph Boafo Afful，KNUST 的计算机专业学生，问的是：这个单一权威状态机是初期规划，还是被生命周期与所有权缺陷逼出来的演化结果。这个问题问得刁。因为如果是演化出来的，说明作者先踩了坑、发现多状态源互相打架了之后才收敛到单一权威源；如果是初期规划，那说明她一开始就明白分散状态在桌面驻留场景里是死路。两个答案都成立，但对想学的人意味着完全不同的路径成本。Mika 在评论里没回这个。截至写这篇，那条讨论没有后续。但问题本身比回答有信息量。复杂桌面交互的长驻进程里，状态源只能有一个，其他的都是投影。
再看 Mochi 怎么感知外界。作者给出的方案是一个本地规则式的 AmbiSense：把打字、视频播放、文件浏览、当前应用这些桌面活动降维成隐私安全的语义信号。关键约束：不用大模型、不依赖云服务、不碰真实按键内容、文件名或窗口标题。实现上走 D-Bus 跟 GNOME Shell 辅助组件通信，拿的是粗粒度信号。我的判断（分析）：一个开源项目打隐私牌，架构必须自己把这个约束放进核心，因为如果嘴上说隐私安全，实际把桌面活动分类交给第三方模型服务，那这张牌看一眼架构就空了。Mochi 的隐私承诺有架构支撑，不是文案。代价也摆在明面上：跨平台很窄，目前只跑 Linux。作者回应 macOS 版本请求的时候说，自己缺少可用的 macOS 测试环境，欢迎提 issue 或 PR 帮忙移植。这个回应是个很好的可信度信号，没有吹跨平台路线图。她主页的信息也撑住了这个判断：自学开发者，坐标弗吉尼亚州亚历山德里亚，今年 9 月 11 日才加入 dev.to。一个人、一台 Linux 机器、一个自己抓出来的痒处。
评论区 Sina Rezaei 提了个反对意见——用一个功能跟一个产品做深度比较不公平，“更好”未必等于实现更多，可能只是范围不同、能围绕单一目的优化整个系统。（观点）有道理，但没打中要害。Codex Pets 和 Mochi 的产品约束确实完全不对等：OpenAI 要做的是跨两个主流平台、挂进 agent 生态、可规模扩展的通用组件；Mochi 做的是一个人在一台 Linux 机器上想要的桌面物品。范围不同，深度自然不同。但这不构成对“无持久状态”的豁免——你叫了宠物，没有持久状态就是产品范畴内的缺失。功能没做可以补，名字和功能不一致只能选一边。
评论区最有分量的一个问题来自 Mr Say Nothing：宠物是读取智能体的真实执行结果——退出码、失败的测试、沉默——还是只反映它声称的状态。这个区分决定了它属于玩具还是工具。我的分析是，这句话切中了一个工程事实：agent 真正发生了什么，和它认为自己发生了什么，在长任务里经常不一致。一个 agent 可能报告“working on it”，但 context window 已经被错误信息塞满；可能报告“task done”，但退出码是 1、测试挂了两个、然后沉默了。如果宠物只绑定 UI 层状态回调，它就会在任务实际上已经死掉的时候继续欢快地跑。反过来讲，如果宠物真的去读退出码、失败日志、静默时长，那它就不再是装饰层了，它是可观测性入口。这两者不是同一个产品类别。Mochi 目前显然没接到 agent 上，它是独立桌面宠物。但作者的设计方向恰好跟“读真实状态”同路：单一状态机、粗粒度环境感知、独立于外部状态的自我行为。它在原理上具备那个接入口，只是还没接。
回到 Codex Pets 的制造角度。有一个信号值得记：它首发八个内置宠物，支持用户上传图片生成 AI 动画风格定制。OpenAI 在“形象”这条路上投了不少资源，但“状态”这一层只做了一根线。这是选择，不是意外。（分析）更可能的是，目前的 AI 编程产品团队还没把“智能体执行状态的可观测性”当成一个需要产品化的方向。如果你连“这个 agent 到底在干什么”都还没有一个清晰的、跨会话的、持久可回溯的数据模型，那宠物只能做到“它说它在干嘛”的程度。不是 OpenAI 做错了什么，是这个阶段状态灯已经不够用了。需要有人把状态变成数据，再把数据变成可以交互的东西。
Mochi 的 Bond 成长系统是刻意非惩罚的。作者明确说：没有连续打卡、没有衰减、漏掉一天不扣分，经验值来自打字时长和喂食。这个选择很具体地表明了她的态度：这不是一个 gamification 插件，是一件想让人舒服的桌面物品。它还有番茄钟式专注会话、独立计时器在拖拽或点击打断时持续运行、表情目录带稀有度分级和羁绊解锁门槛。这些细节单看像黄油，但组合在一起指向同一件事：Mochi 把“存在感”建在自己的时间轴和跟用户相处的时长上，而不是某个 agent 线程的存活状态上。
把两个东西放一起，模式很清晰。Codex Pets 把“形象”当初 agent 的一个附属 UI 功能；Mochi 把“个体状态”当核心。前者的风险是用户理解不了为什么叫宠物；后者的风险是作者一个人撑不下去——单人 alpha 阶段开源项目，这风险真实存在，不是客气话。
几个值得盯的信号。一、Codex Pets 的 issue 区和文档里，用户会不会开始提“跨会话状态”“历史精修”“agent 真实执行日志”这三件事，尤其“真实执行日志”是 Mr Say Nothing 那条评论的同款需求。二、Mochi 的仓库里，Mika 会不会把那个单一权威状态机抽象出可复用的 API，让 agent 接入从“原理上可能”变成“真能接”。三、Codex 下次更新的时候，自定义宠物是只加皮肤类型，还是出现了任何让宠物有自身状态的东西。四、Linux 之外如果出现社区贡献的 macOS 移植，说明这个项目在开发者生态侧开始沉淀真实的跨平台协作。这四条都能通过公开渠道核验，到时候对着看。
本期到这。有更准确信源的同学欢迎匿名补充——尤其是真摸过 Codex Pets 内部设计的，和真在 Mochi 代码里看到过那个状态机的。