唤醒工作台全实录（六）：数据层——5ms 竞态窗口与“查询即引用“

第五幕的表针停在 9 月 21 日。这一幕先把它拨回八月中旬------云侧提示词一版版重写的同时，端侧数据层动了两场设计手术；再把表针拨到 9 月 22 日晚上，那里有一场无声的故障等着。

1. 查询即引用

8 月 13 日，数据模型重构的讨论从盘现状开始，一口气盘出八个问题，最后收成一条原则，档案原话：

不存关系，只存事实；关系靠查询现场生成。

落到地上：目标不存条件引用，只存"需要什么"的描述；条件缺口靠实时检索判断，库里不维护任何"谁引用谁"。眼熟的读者会认出来------这是第一幕条件池原则在数据层的同构：只存"有什么"，不存"缺什么"；缺口是检索的结果，存下来的缺口只会过期。

第二天升级成认知型三层模型：raw 原文层，一个字不改；cognition 认知层，每条信息一句完整描述；outline 粗索引，只记"有什么"的目录。检索三级递进：outline 定位命中 → search 取 cognition → 需要时回 raw 读全文，配一层 infoCache 和极简 RAG。

2. turn_id 端侧驱动

9 月 14 日方案定稿，16 日实施：彻底抛弃云侧维护的 conversation_id，每轮对话的轮次 ID 改由端侧在写入时生成------谁写入，谁发身份证。方案文档 1280 行、16 条核心决策，口号四个字：云侧零维护。数据库同步升到 v4。这个机制在下一节的无声故障里还会登场。

3. 9 月 22 日，丢单

先补一句背景：云侧每次要读写数据，调用的是端侧的"意图"插件（Insight Intent），HistoryAppend 就是负责把对话写进历史的那一个。现象从用户视角看只有一句话：杀掉进程冷启动后，向小艺（HarmonyOS 的语音助手）提一个新问题，云端分析模型没拉到这个问题，存储流程也没存它。紧接着的第二次提问一切正常------只有冷启动的第一轮中招。

备选假设"云侧没收到消息"先被排除：端侧日志显示 HistoryAppend 在 21:19:48.316 已经到达。没有报错，没有崩溃，问题无声消失，历史里留下一轮没有问题的"孤儿回复"。用户后来复盘的感受：这是"丢单"，不是"报错"。

失败轮的日志值得整段看（进程 19813）：

text 复制代码

21:19:48.311  Ability onCreate                ← 发起异步 DB 初始化
21:19:48.316  HistoryAppend onExecute START  ← 意图到达，onCreate 后仅 5ms
21:19:48.319  appendHistory: store not initialized
21:19:48.319  append DONE: turnId=155259f0...  ← 未写入，却报成功
21:19:48.373  RouseDatabase init DONE        ← DB 就绪，比意图晚 57ms

时间线把三连缺陷钉在一起。其一，fire-and-forget 的初始化 ：onCreate 里发起 init 后不保存 promise------初始化在天上飞，但没有任何人能等它。其二，静默失败 ：意图比就绪早到，getStore() 拿到 undefined，appendHistory 只打一行日志就 return，原签名 Promise<void>，失败传导不出去。其三，假成功：实现类不检查写入结果，无条件返回成功码，还现编了一个 turnId、标志位全填默认值------云侧被骗得连重试的机会都没有。

损害是链式的：用户问题永久丢失 → 同窗口的 current_turn_id 占用也丢 → 思考和回复另起新 turnId（轮次碎片化）→ 历史读回缺了问题 → 存储水印（已处理到哪一行）无增量，流程无感。竞态的结构性根源改不了：HistoryAppend 以后台模式拉起进程------冷启动的第一件事就是写数据，而进程刚醒，数据库还没初始化完。意图既是客人，也是开门的原因。

4. 让意图在门口等门开

既然竞态无法消灭------init 不可能跑赢拉起进程的意图------方向就不是抢跑，是等待。修复五点：一，RouseDatabase 缓存 initPromise，新增幂等的 ensureReady()：已就绪短路返回，初始化在飞就等它，失败清空可重试；二，七个依赖数据库的意图 onExecute 首行统一 await ensureReady()，未就绪返回 code=0 真失败（不涉数据库的 CurrentTime 不改）；三，appendHistory 签名从 Promise<void> 改成 Promise<boolean>，失败可传导；四，UI 页面加载前同样 await------冷启动白屏是同一个竞态的另一张脸；五，turnId 占用时机后移，写入成功才占用。

当晚 23:32 复测，同一个场景：

text 复制代码

23:32:53.263  HistoryAppend onExecute START
23:32:53.278  RouseDatabase init DONE      ← 意图原地等待 15ms
23:32:53.290  appendHistory: chat_history 7a56a49b... OK

四项验证全过：时序正确、假成功消失、新问题入库可读回、turnId 全轮连续（user/think/assistant 同为 7a56a49b）。冷启动首意图原地等待约 15ms，用户无感。

这次排查的素材包里压着四条"禁虚构铁律"------时间戳、日志、代码一律原文引用，未发生的推测必须标注------恰好也是本系列的写作纪律。延伸讨论里有一句值得单独抄出来：假成功比失败更危险 。失败会触发重试和降级，假成功什么都不触发------云侧拿着现编的 turnId 继续走，污染后续整轮。分布式系统的老话在端云协作里同样成立：报错是礼物。

5. 派生值：goal.status 不可手设

9 月 24 日，数据层最后一刀：goal.status 定为纯派生值 ------一切以任务完成度为准：零任务且零子目标 → paused；存在未完成项 → active；全部完成 → completed。三个值都由端侧自动维护，不可手动设置；状态变化沿 parent 链向上传播，防环用 Set 兜底。

这和"查询即引用"是同一条纪律的两面：关系不落库，状态不手设------事实与推导分开，推导交给确定性代码。零提示词改动：云端拿返回值自然回复即可。按纪律标注：这一刀当时端侧实施完成（intentVersion 0.0.3→0.0.4），档案里还挂着"待实测"。它的实测来得意外------两周后，坐在了审核席上（第七幕）。

本章沉淀

不存关系，只存事实；关系靠查询现场生成
认知三层：outline 定位、cognition 取义、raw 兜底
turn_id 端侧驱动：谁写入谁发身份证，云侧零维护
竞态无法消灭时，让消费者等就绪：ensureReady 幂等门，15ms 换冷启动不丢单
假成功比失败更危险：失败触发重试，假成功污染整轮------报错是礼物
可推导的值不手设：goal.status 纯派生，事实与推导分离

下章预告

数据层稳住，功能闭环，项目走向第一个正式版本，向 AppGallery 提审。提交之后才发现，两个"上架对象"在互相等待：智能体要等 App 上架才能发布，App 的核心功能又要智能体先发布才算可用。第三幕埋下的那颗雷，到这里炸了。下一幕：死锁破局与四轮审核。

懿路向前 · AI辅助整理

2026-10-31