StareBrain

StareBrain的目标定位不是打造能力最强的Agent，而是打造一个“不会让你觉得在跟一个不了解你的东西说话”的Agent。

StareBrain的关键设计决策是：Agent必须在动作分发之前从设备上下文中解析参数，而非在分发过程中或事后询问用户。

StareBrain在每次动作分发前设置ContextResolver解析环节，接收原始意图和设备上下文，在向用户暴露信息之前尝试补全缺失参数。

StareBrain的解析结果分为三条处理路径：高置信度参数自动填充；中等置信度参数以预填建议形式让用户确认或修改；无法解析的参数标记为缺失并向用户提问。

StareBrain遵循的原则是“永远不要询问手机已经知道的信息”，并要求解析器在无法解析时返回UnresolvedParameter而非静默失败。

StareBrain定义了四级置信度HIGH、MEDIUM、LOW、UNRESOLVABLE，每个参数值携带置信度和来源信息ContextSource，并据此决定自动填充、预填确认或直接询问用户。

StareBrain的系统完全在设备端运行，没有任何上下文数据离开手机，这是该架构的硬性约束而非偏好。

由于完整设备上下文不允许上传，StareBrain无法使用云端模型对完整上下文进行推理，解析逻辑必须足够确定、轻量并能在本地执行，且需明确说明使用了哪些信号及如何权衡。

StareBrain的上下文解析解决了结构化数据层面的“本该知道”问题，但没有解决开放式推断（如“我在这里通常会做什么”）以及需要主动读取App内容的跨应用状态问题。

StareBrain团队在beta测试中反复收到用户抱怨，称手机AI助手要求用户重复提供设备中已存储的信息（如日历、通讯录、位置历史、邮箱航班确认信）。

StareBrain将端侧AI Agent所需的上下文拆分为两类：动作上下文（描述用户请求的动作、参数及可完成该动作的App）和设备上下文（手机已知道的相关信息，如即将到来的日历事件、已保存位置、最近搜索记录）。

StareBrain使用名为AgentContext的数据结构聚合动作上下文与设备上下文，其中DeviceContext包含即将到来的事件、已保存位置、最近使用的App和活跃通知摘要。

据StareBrain的技术分析，设备端动作中无障碍层确认UI操作已触发后，下游服务商是否已记录该操作属于另一个时钟，两个时钟之间的间隙是重复分发的来源。

StareBrain通过tryAccept()方法保障结构不变式：只有当delivery == CONFIRMED时才允许接受状态从PENDING转移，否则抛出异常。

StareBrain的ActionRecord将actionId、dispatchId、providerObjectId、两个状态枚举以及三个时间戳一起持久化。

StareBrain提出双轴状态模型方案：让每个产生可观测产物的动作追踪两个独立状态，DeliveryState回答产物是否存在，AcceptanceState回答产物是否正确。

StareBrain还原的常见故障链为：Agent派发动作 → 派发在确认到达前超时 → 系统看不到SUCCESS标记 → 判定为失败 → 触发重试 → 第二次派发产生重复。

在 StareBrain 的案例中，“最近一次感到本应自动完成的经历”是典型的关键事件提问，它把时间锚定在过去，把场景锚定在具体操作，从而绕过了假设性偏差。

StareBrain 团队彻底停止了用“你会用这个吗”来验证功能，每一次用户调研对话现在都以故事性提示开始，以花费或努力问题结束。

StareBrain 团队在开发 Android 端侧 AI 代理时，因使用假设性问题进行用户调研而浪费了大量时间。