什么值得记、什么不值得记
不是所有对话都有价值：守门员思路与筛选逻辑
本页解决的问题
先给结论「什么值得记、什么不值得记」要解决的关键问题是什么？
不是所有对话都有价值：守门员思路与筛选逻辑
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
重要事实（生日、城市、职业）
长期习惯（早起、吃素、用 Mac）
明确表达的需求模式
一次性问题（今天天气怎么样）
纯闲聊（无具体信息量）
已经过时的临时信息
「猜一猜：这 10 条消息，哪些该记」的能力藏在每次交接里
「不是所有对话都有价值：守门员思路与筛选逻辑」说明，Agent 的表现不只由模型决定。模型、上下文、工具、状态、权限和人之间的每次交接，都会改变任务能否继续以及出了问题能否恢复。
先写清状态，再增加能力
从「不是所有对话都有价值：守门员思路与筛选逻辑」出发，可以把流程拆成起始状态、下一步动作、工具返回、状态更新和停止条件。这样调试时找的是第一处丢失信息或权限的位置，而不是笼统地说“模型变笨了”。
成功路径不能代表系统可靠
用「不是所有对话都有价值：守门员思路与筛选逻辑」重放一次成功和一次失败，记录每一轮真正传入的上下文、工具结果和负责人；只要第二个人能复述这条链，系统才有可维护性。
从「猜一猜：这 10 条消息，哪些该记」走到「守门员的判断标准」
「猜一猜：这 10 条消息，哪些该记」先把问题落在「想一想哪些值得存入长期记忆，然后点击下方揭晓 揭示守门员的判断 0 值得记住的 0 不值得记的」上；到了「守门员的判断标准」，讨论继续推进到「记忆守门员 值得记 用户的偏好（喜欢/不喜欢） 重要事实（生日、城市、职业） 长期习惯（早起、吃素、用 Mac） 明确表达的需求模式 不值得记 语气词（嗯、好的、哈哈） 一次性问题（今天天气怎么样） 纯闲聊（无具体信息量） 已经过时的临时信息 如果什么都记，记忆库很快变成垃圾场。守门员比记忆力更重要。 一个好的记忆系统，重点是知道什么该记、什么不该记，能记多少反而是次要的」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析 Agent 时，沿着状态、动作、工具结果和下一步的顺序走一遍；每次交接都要能说明信息从哪里来、由谁确认、失败时停在哪里。
- 「猜一猜：这 10 条消息，哪些该记」：想一想哪些值得存入长期记忆，然后点击下方揭晓 揭示守门员的判断 0 值得记住的 0 不值得记的
- 「守门员的判断标准」：记忆守门员 值得记 用户的偏好（喜欢/不喜欢） 重要事实（生日、城市、职业） 长期习惯（早起、吃素、用 Mac） 明确表达的需求模式 不值得记 语气词（嗯、好的、哈哈） 一次性问题（今天天气怎么样） 纯闲聊（无具体信息量） 已经过时的临时信息 如果什么都记，记忆库很快变成垃圾场。守门员比记忆力更重要。 一个好的记忆系统，重点是知道什么该记、什么不该记，能记多少反而是次要的
最后的「最后把结论落到实践」把讨论落到「不是所有对话都有价值：守门员思路与筛选逻辑」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。