客户遇到的问题非常具体
用户昨天明确说：“晚上 7 点后提醒我，早上不要打扰。”今天，智能指环已经记录他完成了全天运动。早上 7 点，助手仍然推送：“早上好，该开始今天的活动了。”
重复几次之后，用户会关掉通知、停用 AI 功能，甚至退货。用户找客服投诉时，客服又看不到 Agent 对话和设备触发事件，只能问：“能重新说明一下吗？”
真正的问题是上下文断了
早期 Agent 往往与产品其余部分隔离。用户偏好跨天消失；设备遥测没有变成 Agent 可用的实时事件；提醒系统仍按固定时间触发；客服只看到一张工单，看不到造成投诉的完整过程。
继续改提示词解决不了。
硬件公司需要让用户、设备、Agent 与内部团队共享同一份运行上下文。
这个场景需要怎样的基础设施
- 跨天上下文：偏好、目标、限制、康复状态与既往建议持续保留。
- 设备事件层：把原始遥测转成带时间、置信度、来源和用户身份的标准事件。
- 判断规则：联系用户前先检查目标是否完成、静默时段、信号冲突和风险。
- 知识与操作：产品说明、康复方案、训练计划、保修和客服动作在授权下可用。
- 客服连续性：接手人员看到相关对话、设备事件、已尝试动作和建议下一步。
- 评测系统：用历史与模拟案例测试重复提醒、错误建议、漏读事件和交接失败。
FDE 团队具体交付什么
团队先从交互日志、设备事件、提醒规则和客服案例中还原失败过程，再把这些系统接成一条可追溯的事件链。随后构建多组上下文与提醒抑制方案，用历史案例和沙箱模拟反复测试，再把效果最好的改动发布到有限真实流量。
最终交付不是一份 Personal Agent 概念介绍，而是这家硬件公司的 Agent 生产基础设施：已经接入产品、设备数据、客户上下文与客服运营。
如何验收结果
核心指标包括重复与错时提醒率、偏好记忆准确率、设备事件响应正确率、AI 功能持续使用率、人工介入率、退货相关咨询与客户满意度。客户没有用自己的基线确认之前，不应宣称生产效果。
证据说明：本文描述的是智能硬件常见失败模式，不发布未经确认的客户结果。