从散落病例到可控记忆：AI PM如何设计宠物照护 Agent

宠物看病资料分散在不同医院，复诊时难以快速调取，这背后是典型的 AI Agent Memory 设计问题。本文从宠物照护场景出发，拆解 Memory 的存储、召回与写入机制，提出分层记忆模型，帮助产品经理理解如何构建真正有用的长期记忆系统。

最近，我在学习 AI Agent 的 Memory 机制时，想到朋友带宠物看病的一段经历。

这只宠物需要反复看病。日常的小问题，她会选择离家近的宠物医院；遇到更复杂的疾病，又要去外地寻找擅长相应专科的医院。时间久了，她手里积累了不同阶段的 DR（数字 X 射线影像）、血液报告、核磁报告和处方。有些是纸质材料，有些保存在不同医院的微信小程序里，还有一些病例只留在医院内部。

检查已经做了不少，下一次就诊时资料却不一定能顺利接上。在她经历的就诊流程里，如果没有提前向医院索要报告，可能带不走完整资料；换一家医院后，还需要打电话联系上一家医院调取病例。不同医院开的药品品牌可能不同，宠物主人面对一串名字，很难准确说清哪些药正在吃、什么时候开始吃、剂量有没有调整。

这让我意识到，宠物长期照护面对的是一个典型的 Memory 问题：信息跨医院、跨时间、跨文件格式不断出现，到了需要使用时，用户却无法快速找到与当前任务有关的那一部分。

如果为这类用户设计一个“宠物成长与照护档案 Agent”，它的价值不应该是把所有聊天和报告塞进一个数据库，而应该是帮助主人回答几个具体问题：这只宠物过去发生过什么？现在正在使用什么药？这次复诊需要带哪些资料？哪些结论来自哪一家医院、哪一份原始报告？

Memory 的目标不是无限增加保存量。它是一套决定什么值得记住、什么时候调用、什么时候更新，以及什么时候必须忘记的产品系统。

一、为什么云盘和聊天记录还不够

看到朋友的经历，我们很容易想到一个直接方案：做一个宠物版云盘，让用户把所有 PDF、照片和报告上传进去。

这当然有价值，但它只解决了“文件放在哪里”，没有解决“下一次怎么用”。

假设一只猫两年内去过五家医院，留下四十多份文件。主人下周要去神经专科复诊，真正需要的可能只是最近半年的核磁报告、神经症状变化、当前用药和两次关键的血液检查。如果产品只是按照上传时间展示四十个文件，用户仍然需要自己逐个打开、回忆和筛选。

AI Agent 的不同之处在于，它不仅可以保存信息，还可以围绕当前目标主动选择信息。例如用户说：“帮我准备下周复诊要带的资料。”Agent 需要先判断是哪只宠物、看什么专科、当前问题是什么，再从长期记录中召回相关内容，形成一份有来源的复诊材料清单。

市面上已经出现了相近的产品思路。MyPet Health 的官方介绍提到，它允许用户上传 PDF、化验结果、影像资料和手机照片，再将这些文件组织成可分享给兽医的时间线，并保留原始附件供核验。这说明“跨医院资料分散”不是一个只存在于想象中的问题。对这类产品来说，生成一段漂亮的 AI 总结远远不够，结构化信息还必须能够回到原始证据。MyPet Health 官方介绍

因此，一个宠物照护 Agent 至少要完成三件不同的事：

1. 保存原始资料，保证信息没有在 AI 总结中丢失；
2. 把资料整理成能够按宠物、时间、疾病和就诊事件检索的结构；
3. 根据当前任务选择性召回，而不是每次把所有历史都交给模型。

第三点，才是 Memory 产品设计最容易被忽略的部分。

二、Memory的关键是“选择性保存和召回”

我最初对 Memory 的理解比较简单：用户喜欢什么、不喜欢什么，产品就把它记下来。如果用户重复强调两三次，系统就把它写进长期记忆。

但继续学习后，我发现这个规则并不可靠。

用户只说一次“我的猫对某种药有过严重不良反应”，它也可能值得保存；用户连续三次说“这次复诊不要安排周一”，却只是一项临时限制。重复次数只能增加置信度，不能决定信息应该进入长期 Memory 还是当前任务。

在 Learn Claude Code 的 Memory 课程中，Memory 被拆成四个过程：存储、召回、提取和整理。系统不会把完整聊天记录每次都塞给模型，而是先保留简短索引，根据当前请求选择相关记忆，再加载正文；一轮对话结束后，模型提出候选记忆，系统继续判断它是否真的具有长期价值；记忆积累后，还要合并重复和过期内容。Learn Claude Code：s09 Memory

这套机制对 AI PM 很有启发。Memory 的产品闭环可以概括为：

用户交互 → 候选识别 → 写入判断 → 结构化存储 → 相关性召回 → 任务使用 → 反馈修正

这里每一步都有不同的产品问题。

候选识别要回答“用户刚刚提供的信息以后还会不会用到”；写入判断要区分长期事实、项目状态和临时要求；召回要判断当前任务真正需要哪些内容；反馈修正则要允许用户指出“这条信息已经过期”或者“你记错了”。

因此，Memory 不是数据库里增加一个 memory 字段就结束了。它连接着用户输入、模型推理、数据结构、权限、纠错入口和产品责任。

三、先分清楚：到底要记住哪一类信息

宠物照护中的 Memory 不能只按“用户信息”统一保存。照护者、宠物身份、长期疾病项目、就诊事件、反馈和原始资料需要分层，并在召回时同时校验宠物身份、任务和来源。

文档中的教学实现把记忆分成 User、Feedback、Project 和 Reference。放进宠物照护场景后，我认为还需要增加 Episode，也就是带有明确时间的事件记忆。

1. User Memory：照护者相对稳定的信息

这类记忆描述的是宠物主人或家庭，而不是某一次看病。例如主要照护人、常住城市、家庭中谁负责喂药、用户希望提醒的时间、是否有多只宠物。

它们能够帮助产品减少重复询问，但不能和宠物档案混在一起。一个家庭有三只宠物时，“每天晚上九点方便接收提醒”属于照护者，而“需要每天服药两次”属于其中一只宠物。

2. Pet Profile：每只宠物的身份档案

课程中的类型可以根据业务扩展。宠物产品必须为每只宠物建立独立身份，包括名字、物种、品种、性别、出生日期、芯片信息，以及经过确认的过敏或重要既往信息。

这一层首先要保证身份隔离。多宠家庭中，如果系统把 A 宠物的药物记录召回给 B 宠物，Memory 越丰富，风险反而越大。

3. Project Memory：一个持续照护问题的状态

“Project”并不一定是工作项目。在宠物照护里，一次长期疾病管理也可以被视为项目。例如慢性肾病管理、术后恢复或皮肤问题排查。

它要记录当前目标、涉及医院、已经完成的检查、下一次复诊时间和仍然没有解决的问题。项目结束后，这些内容应归档，而不是永远作为当前状态出现在每一次回答中。

4. Episode Memory：带时间的就诊与生活事件

每次就诊、突然呕吐、体重变化、食欲下降、疫苗接种，都属于一次事件。事件需要包含日期、地点、涉及人员、用户观察、医院结论和对应附件。

如果只做一份“月度总结”，很多关键细节会消失。正确的做法应该是保留事件卡片，再在其上生成月度或阶段总结。总结帮助阅读，事件和原始报告负责证明。

5. Feedback Memory：主人可复用的反馈

例如“这只猫很难吞咽大颗药片”“主人希望先看到简短结论，再展开原始报告”。它们会影响后续交互，但不等于医疗事实。

6. Reference Memory：原始报告和外部来源

DR、血液报告、核磁报告、处方 PDF、医院小程序导出的文件，都应该作为 Reference 保存。AI 可以从中提取结构化字段，但不能让结构化结果取代原始文件。

在医疗相关场景里，来源本身也必须进入 Memory。一条“正在服用某药”的记录，必须能够回答：谁提供的？来自哪次就诊？原处方怎么写？用户后来是否确认仍在使用？

四、PM要设计一套“写入闸门”

一条信息是否进入长期记忆，不能只看用户说了几次。PM还要判断它是否可复用、适用于什么范围、来源是否可信，以及是否涉及药物、诊断或隐私等高风险内容。

Memory 最危险的误区，是模型觉得重要就自动保存。

对于宠物照护 Agent，我会让每条候选信息经过至少六个判断。

第一，它未来是否可复用。主人问“今天医院几点关门”，通常没有长期保存价值；主人说“这只狗对某种食物长期过敏”，可能会影响未来多个任务。

第二，它适用于什么范围。是某只宠物、某一次就诊、某个长期疾病项目，还是整个家庭？“这次不要做镇静检查”不能自动变成永久医疗偏好。

第三，它是事实、用户观察，还是模型推断。“医院报告写明体重下降”与“主人觉得最近瘦了”需要分开；“AI 推测可能食欲下降”更不能和医院结论放在同一层。

第四，它的来源和置信度是什么。PDF 原报告、用户口述、OCR 识别和模型归纳的可信程度不同。系统应该保存这种差异，而不是把它们整理成看起来同样确定的句子。

第五，它是否敏感或高风险。涉及诊断、药物、剂量和过敏信息时，即使只出现一次，也值得提醒用户确认；而且产品必须清楚说明这些记录不能替代兽医判断。

第六，它多久以后可能过期。宠物的品种通常长期稳定，当前体重、正在使用的药物和复诊计划却会变化。没有有效期和最后确认时间，Memory 很快就会从“帮助用户”变成“用旧信息误导用户”。

一条结构化记忆至少应包含：内容、类型、适用宠物、适用项目、来源、创建时间、最后确认时间、置信度、有效期、敏感等级和当前状态。

例如，系统不应该只保存“豆豆正在服用药物 X”，而应该保存：该信息来自 8 月 10 日 A 医院处方；OCR 识别后由主人确认；剂量仍待复诊核对；最近一次确认是 8 月 15 日；状态为“可能仍在使用”。

这样的记录读起来没有一句笼统总结漂亮，却更接近真实产品需要承担的责任。

五、把它做成一个可落地的 MVP

MVP暂时不连接所有医院系统，而是从用户侧上传开始。AI负责提取和整理，用户负责确认；确认后的内容进入宠物时间线，并用于生成带来源的复诊资料包。提醒与待办则进入独立的Task System。

如果把“宠物成长与照护档案 Agent”做成 MVP，我不会一开始就连接所有医院系统，也不会承诺 AI 能理解全部医学报告。

第一阶段应该聚焦一类用户：拥有多只宠物，并且至少有一只宠物需要多次复诊或长期照护的家庭。

这个人群的问题频繁、资料数量足够多，也更容易验证 Memory 是否真的节省了时间。

第一步：一只宠物一个身份空间

用户先创建宠物档案。每次上传或对话，都必须明确当前对应哪只宠物。无法确认身份时，系统宁愿停下来询问，也不能自行猜测。

家庭成员可以共同照护，但要区分管理员、可编辑成员和只读成员。谁修改了药物状态、谁上传了报告，都应该留下记录。

第二步：上传资料，AI提取，用户确认

MVP 支持上传纸质报告照片、PDF、影像报告截图和医院小程序导出的文件。AI 提取医院、日期、检查类型、关键指标、药品名称等字段，再把结果展示给用户确认。

这里不能把 OCR 或模型抽取包装成确定事实。看不清的剂量、单位和药名应该明确标记“无法确认”，让用户回看原图，而不是由模型补全。

确认后的结构化信息进入时间线，原始文件始终挂在对应事件下面。

第三步：建立两种视图，而不是一个万能聊天框

成长档案适合展示体重、疫苗、饮食、行为和生活事件；就诊档案适合展示症状、医院、检查、诊断记录、处方和复诊计划。

两种视图可以共享底层事件，但面向的任务不同。主人回顾一只幼猫一年的成长，与准备明天的专科复诊，需要看到的信息密度完全不同。

对话框应该是入口之一，而不是全部产品。用户也需要时间线、原始文件、修改记录和分享控制。

第四步：生成“有证据的复诊资料包”

用户选择本次要去的专科和关注问题后，Agent 生成一份复诊前摘要，包括当前症状、近期关键检查、正在使用的药物、历史重要事件、仍待确认的信息和建议向兽医询问的问题。

每个关键结论旁边都应显示来源。例如“7 月 12 日血液报告”“8 月 3 日 B 医院处方”，用户和兽医可以一键打开原始文件。

这份摘要不是诊断报告。它的任务是减少主人翻找材料和重复叙述的成本，帮助兽医更快看到连续信息。

第五步：就诊后生成任务，但不要把任务当成记忆

复诊日期、服药提醒和需要补充的检查属于 Task System。Memory 可以记住它们产生的背景，却不负责待办状态。

例如“9 月 1 日复查血液指标”需要有截止日期、提醒、完成和延期状态；检查完成后，结果再成为新的就诊事件。把 Memory 与任务状态分开，产品才能知道用户是“记得这件事”，还是“已经做完这件事”。

六、Memory也要敢于说“我不知道”

宠物照护Agent可以整理资料、保留来源、生成复诊清单，但不能自行诊断、判断药物等效或修改剂量。产品应把“不确定”和“需要兽医确认”设计成正常状态，而不是异常失败。

宠物照护涉及医疗信息，因此这个 Agent 除了回答问题，还必须学会在信息不足或超出责任范围时停止。

第一条边界是不得自行诊断。Agent 可以整理“主人记录到连续三天食欲下降”，可以提醒用户联系兽医或紧急机构，但不能根据长期记忆直接宣布某种疾病。

第二条边界是不得擅自修改用药结论。朋友的经历里，不同医院可能开出不同品牌、看起来功效接近的药品。产品可以整理药名、成分、处方来源和时间，但不能自行判断两个药完全等效，更不能建议停药、换药或调整剂量。

第三条边界是旧信息不能伪装成当前状态。一条处方曾经有效，不代表宠物今天仍然在服用。产品需要显示“历史处方”“主人确认正在使用”“已停用但原因未知”等不同状态。

第四条边界是总结不能脱离原始来源。Apple 在人类健康档案产品中采取了类似思路：Health Records 将来自不同医疗机构的过敏、用药、检验和诊疗信息组织到同一视图中；HealthKit 还保留数据来源元信息，并将健康数据访问权交给用户管理。宠物产品未必能够直接复制人类医疗系统的标准和接口，但“聚合展示、保留来源、用户控制权限”是可以借鉴的产品原则。Apple Health Records；Apple 健康数据安全说明

七、用户必须能够看见、纠正和删除 Memory

很多产品把 Memory 当作后台能力，只在推荐更准确时让用户感知它。但一旦记忆涉及宠物的疾病、用药和家庭信息，这种“看不见的智能”会迅速变成不信任。

当前 ChatGPT 的 Memory 产品设计提供了几个值得 AI PM 关注的方向：用户可以查看 Memory Summary，了解系统记住了什么；可以修改或删除记忆；可以查看某次个性化回答使用了哪些来源；也可以关闭 Memory，或者使用不读取也不创建记忆的 Temporary Chat。OpenAI 的说明还直接提到，旧记忆可能变得陈旧或互相矛盾，这也是持续更新机制要解决的问题。OpenAI Memory FAQ

把这些思路放进宠物照护 Agent，至少要提供四类控制：

• “为什么使用这条记录”：告诉用户当前摘要调用了哪些医院、报告和历史事件；
• “这条信息不对”：允许用户修正宠物身份、日期、药名和状态；
• “不要再使用”：让一条过期或不相关的记忆退出召回；
• “彻底删除”：同时处理结构化记忆、原始附件、索引和分享链接，而不是只在页面上隐藏。

此外，分享给医院的资料应该默认最小化。用户去看眼科，不一定需要把所有生活记录和家庭信息一起分享。产品应该让用户选择时间范围、资料类型和有效期限，并在分享前预览。

一个会记忆的 Agent，首先应该是一个允许用户管理记忆的产品。

八、PM应该怎样判断Memory做得好不好

Memory 数量不是一个好指标。记住一万条信息，却在错误的场景召回，价值可能还不如准确保存十条。

我会从五组指标判断宠物照护 Agent 的 Memory 是否有效。

第一是写入质量。系统生成的候选记忆中，有多少被用户确认？有多少需要纠正？如果大量内容被删除，说明写入规则太激进。

第二是召回质量。复诊摘要中出现的信息是否真的与本次就诊相关？用户删除了多少无关内容？关键资料有没有遗漏？

第三是任务效率。用户准备一次复诊资料需要多长时间？是否减少了翻找相册、登录不同小程序和打电话调病例的次数？

第四是持续使用价值。用户是否愿意在下一次就诊后继续补充资料？家庭成员是否共同维护？长期使用后，时间线是否比最初更有用，而不是越来越混乱？

第五是安全和信任。错误宠物身份、错误药物状态、越权分享和无来源结论都应该作为严重失败案例单独统计，不能被整体满意度平均掉。

MVP 阶段不需要一开始追求海量用户。可以先邀请十到二十个有多宠物或长期复诊经历的家庭，让他们上传三到五份真实但经过授权的历史资料，完成一次“建立档案—生成复诊摘要—纠正错误—导出分享”的完整任务。

这一轮要验证三个更朴素的问题：资料能不能被正确归到对应宠物和时间；用户能不能快速发现并纠正错误；下一次看病前，这份档案是否真的减少了准备成本。

九、如果面试官问“作为PM，你会怎样设计Agent Memory？”

以前我可能会回答：根据不同业务定义记忆内容，用户重复强调两三次就保存，再通过 Memory 提供个性化服务。

现在我会换一种答法。

我会先从下一次任务出发，明确 Memory 要帮助用户完成什么决策；然后定义用户、项目、事件、反馈和参考资料等记忆类型；设计显式输入、引导采集和被动抽取三种来源；再通过复用价值、适用范围、来源、置信度、有效期和敏感等级建立写入闸门。

保存之后，系统不应每次加载全部历史，而要根据当前任务选择性召回，并把来源展示给用户。最后还需要更新、合并、过期、纠错和删除机制。

以宠物照护 Agent 为例，它可以帮助多宠家庭整理跨医院的就诊资料，并在复诊前生成带原始来源的摘要。但它不能自行诊断，也不能擅自判断不同药物等效或修改用药结论。产品是否成功，要看复诊准备时间、记忆纠错率、召回有效率和严重安全错误，而不是单纯看保存了多少条记录。

这个回答的重点不在于列出多少 Memory 类型，而在于说明 PM 需要设计一套从采集、判断、存储、召回到纠错和遗忘的完整流程。

结语：好的Memory，不是让Agent显得更了解你

宠物长期照护中的资料分散，让 Memory 的价值变得非常具体。

它不是让 Agent 在对话中突然说出宠物的名字，制造一种“它还记得”的惊喜；也不是把所有报告压缩成一段看起来专业的总结。它应该在主人下一次带宠物去医院之前，把过去真正相关的信息找出来，说明每条信息来自哪里，并让主人有机会确认、修正和决定是否分享。

当 Memory 进入健康、财务、教育等高责任场景后，“记住更多”不再天然代表体验更好。错误的长期记忆会不断影响后续回答，缺少来源的总结会放大误解，无法删除的个性化甚至会让用户失去控制感。

所以，我现在更愿意用一句话理解 Agent Memory：

它不是替用户保存过去，而是帮助产品在下一个重要时刻，准确、克制地使用过去。

对于 AI PM 来说，需要设计的正是这种准确和克制。

参考资料：

Learn Claude Code：s09 Memory

OpenAI：Memory FAQ

Apple：Health Records

Apple：Protecting access to user health data

MyPet Health：From PDFs to a vet-ready timeline

本文由 @Molly 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议