开发记录 · 约 8 分钟阅读 · 2026年9月9日
前一阵看 Google 的 E-E-A-T 框架时，我觉得它与个人助理的处境有些相似：面对大量信息，判断哪些内容值得相信、值得保留、值得在此刻使用。
但真正翻过日志、追完调用链、做了几组对照实验之后，我的注意力落到了更基础的地方。
一条记忆从屏幕进入系统，再被送给回答问题的模型，中间经历了多少次信息损失？一次失败为什么会再次执行？一条有引用的事实，引用真的足以支持它吗？
今天最有价值的发现，都藏在这些问题里。
先看钱花在哪里
当天截至19:44的日志里，共有1,253次模型调用，记录到约368万 token。其中，记忆提取占65.2%，图谱整理占20.7%，两者合计85.9%。
这个分布改变了优化顺序。用户能直接感受到的是 Cue 和问答，但消耗的大头在后台。
继续追踪后发现，部分提取入口没有共用同一套失败退避。模型已经失败，另一路调度仍可能把工作重新送进去。成功批次有收据保护，失败批次的重试管理却不完整。
这让我意识到：讨论缓存和提示词压缩之前，必须先确认系统是否在重复支付失败的成本。
我们把任务成员固定下来，分别记录成功进度、内容失败和提供商故障，再让不同入口共享调度约束。一个持续失败的受控场景中，同样运行100轮，提取调用从100次降到了7次。
这个93%的下降只属于该实验，不能当作真实日账单的降幅。不过，它证明了一件很具体的事：失败不必随着每一轮采样重新付费。
个人记忆系统需要记住的不只是用户，也包括自己已经做过什么、失败在哪里，以及什么时候值得再试。
最明显的准确度缺口，出现在最后一步
今天最意外的发现，是问答链路已经取回了完整引用，但在组装最终提示时，只留下了记忆摘要和来源坐标，原文全部丢掉了。
模型知道“这条记忆有出处”，却看不到出处写了什么。
假设摘要是“用户周五有空”，原文却是“如果评审提前结束，我周五下午可以参加”。当条件从提示中消失，回答模型再谨慎，也很难恢复这段限定。
我们修复了这条明确问答路径，让完整引用随记忆一起送出，并用12个公开合成案例做真实模型对照。案例刻意包含摘要遗漏条件、说话人或状态的情况，不能代表日常问题的自然分布。
结果是：
| 指标 | 修复前 | 修复后 |
|---|---|---|
| 必要事实与限定完整覆盖 | 6/22 | 22/22 |
| 无依据断言 | 5处 | 0处 |
| 总 token | 5,909 | 7,835 |
| 模型耗时中位数 | 2.327秒 | 2.381秒 |
准确度改善付出了成本：这组问答的 token 增加了32.6%。
我认为这部分成本值得保留。压缩掉决定一句话含义的条件，得到的低消耗并不可靠。
随后做的消融实验也很有意思：只改指引、不补原文，覆盖仍是6/22；只补原文、沿用旧指引，已经达到21/22。
在这组案例里，主要收益来自模型终于看到了原本就应该看到的证据。
“来源与语境闭包”开始变得具体
我现在更愿意这样理解来源与语境闭包：
使用一条记忆时，让它成立、让它被正确理解的必要依据，也应该一同到场。
这至少涉及四件事：
- 来源仍然存在，并且仍被允许使用。
- 说话人、时间、条件、草稿状态等必要语境没有丢失。
- 引用实际支持这条记忆，而不只是包含几个相同关键词。
- 对当前问题，这些材料已经足够；不够时，系统能够承认缺口。
这些保证不能互相替代。
今天的源码检查就发现，一段引用即使字节位置完全合法，也可能省掉前面的说话人信息。即便把两段原文都带上，模型仍可能把草稿误解为已经确认的决定。
所以，“引用存在”是一个很有用的工程保证，但它离“理解正确”还有距离。
这也意味着，完整的闭包不能只靠一句更严格的提示词。采集、切片、提取、检索和回答，每一层都需要保留必要的结构。某个来源被遗忘或过期后，依赖它的记忆也需要重新判断是否还能成立。
这些更深层的依赖与失效机制，目前仍有不少设计和验证工作要做。今天完成的是其中一个明确缺口：让已经取回的依据真正到达使用它的模型。
一次没有通过的实验
我们也尝试给提取模型追加更严格的引用忠实性要求。
在16个公开案例中，无引用支持的命题从3处降到2处，但必要事实覆盖从13/21、另1项待定，下降到11/21；总 token 还增加了。
这个方案没有启用。
它提醒我，记忆系统很容易获得一种表面上的进步：少提取，就可能少犯错。但用户需要的是可靠地记住有价值的信息，遗漏完整的承诺、条件和安排，同样会损害体验。
因此，评估时必须同时看错误和遗漏。不能只展示下降的错误数，把丢掉的事实藏起来。
后台的一把锁，也会改变“智能”的体验
完成密钥授权后的实机测试，又暴露了一个与模型能力无关的问题。
一道简单问题最终答对了，却等了59.8秒。供应商实际处理问答只用了约1.3秒，其余时间主要在等待后台提取释放共享锁。
原来，模型适配器在整个网络请求期间都持有互斥锁。后台一次慢请求，就能把前台问答堵住。
修复后，每次请求短暂获取一致的模型配置快照，再独立执行网络调用。最终实测中，同一道问题在后台仍未结束时，用1.28秒返回了正确答案。
这是两次现场观察，不能当作完整的延迟基准。但调用链和受控并发测试都确认了阻塞原因。
用户不会区分模型慢、队列慢还是锁在等待。他感受到的只是：这个助理有没有及时回应。
对贴身助理来说，调度和并发也属于产品能力。
今天留下的判断
回头看，今天没有得到一个足以宣称“全面领先”的新架构，也还没有测出可比自然使用下的每日节费幅度。后台仍有提取校验失败和模型超时，需要继续处理。
但我对下一步该怎么做更明确了。
先减少没有价值的重复工作，再决定如何压缩单次输入。先检查证据在链路中有没有丢失，再要求模型表现得更聪明。评估准确度时，同时记录完整覆盖、无依据断言和遗漏，而不是只保留一个漂亮分数。
我想把 Harocue 做成一个越来越了解人的助理。今天的经验让我觉得，这种“了解”需要落实到具体细节：它知道一句话是谁说的、在什么条件下说的、后来有没有改变，也知道哪些部分自己还不确定。
接下来的架构工作，就应该围绕这些细节继续展开。