历史、状态、记忆和知识不是一回事
一句话收获：信息的用途决定它进入历史、状态、记忆、知识还是 Skill。
这个场景在解决什么问题
这个场景要建立六类信息对象的清晰位置——历史、状态、记忆、知识、Skill 等，避免把它们混为一谈。原文的做法是让同一段信息依次进入不同的存储，观察它未来的用途和权威性各是什么。它值得单独学，是因为现实里最常见的错误就是"把聊天历史当状态""把个人偏好当组织规则"，而这些混淆会直接导致 Agent 做出错误判断。
先理清这条判断链（文字版）
这个场景是一条"按用途分库"的链：先看对话历史（回放用），再看任务与业务状态（决定能否继续），接着看用户记忆与组织知识（长期信息的两类），最后看 Skill（可复用方法）。验收标准是——能不能说清"一段信息该进哪个库、由谁维护、权威性如何"。
- 先看对话历史：它回答"发生过什么"，用于追溯，不是状态机。
- 再看任务与业务状态：它决定"当前能不能继续"，需要结构化维护。
- 接着看用户记忆与组织知识：两者主体、权限、生命周期都不同，要分开准入。
- 最后看 Skill：可复用的方法制品，与事实存储解决不同问题。
逐层详解
第 1 步：对话历史
原文：保存发生过的交流和工具消息，用于回放。
白话：对话历史就是把发生过的交流内容和工具消息原样存下来，主要用途是"回放"——回头看当时到底发生了什么。
类比：像会议录音或行车记录仪——它忠实地记录"发生了什么"，但你不会拿录音去判断"现在车开到哪了"。
举例：一个客服 Agent 把"用户第 1 轮提问、Agent 查物流的工具返回、用户补充凭证"按顺序存成历史，事后可以回放整段对话来复盘。
为什么重要：历史回答发生过什么——历史的价值在于追溯"发生过什么"，而不是"现在是什么状态"。
怎么验证（证据点）：
- 消息顺序
- 原始轨迹
- 可审计
别踩的坑（边界）：历史记录不能直接代表当前状态——历史里写"已退款"不等于现在订单真的是已退款状态，状态要去权威系统查。
落地检查：历史用于追溯，不是状态机——落地时把历史定位成"审计/回放用"，判断"当前状态"时去查结构化状态，而不是翻聊天记录。
第 2 步：任务与业务状态
原文：任务状态记录执行进度，业务状态来自外部权威系统。
白话：状态分两种——任务状态记录"这个任务执行到哪一步了"，业务状态来自外部的权威系统（比如订单系统、数据库），记录"业务对象现在实际是什么样"。
类比：像"我今天做午饭做到哪一步了"（任务状态）和"冰箱里实际还剩几个鸡蛋"（业务状态，来自冰箱/账本这个权威源），两件事来源不同。
举例：客服 Agent 处理退款，任务状态=「已查询物流、待用户补凭证」，业务状态=订单系统里「已付款未发货」。前者记录执行进度，后者来自订单系统的权威数据。
为什么重要：两类状态共同决定当前能否继续——只有任务状态（做到哪）和业务状态（实际什么样）都对得上，才能判断下一步能不能走。
怎么验证（证据点）：
- 任务阶段
- 外部对象状态
- 更新时间
别踩的坑（边界）：聊天摘要不能覆盖权威业务状态——从聊天里总结出的"大概状态"永远不能替代从订单系统实时查出来的权威状态。
落地检查：状态需要结构化维护——落地时用结构化字段（如枚举、时间戳）维护状态，而不是用一段自然语言描述来当状态。
第 3 步：用户记忆与组织知识
原文：用户记忆服务个体连续体验，组织知识服务多人共享判断。
白话：用户记忆是"服务某一个用户的连续体验"（比如他的偏好、他的习惯）；组织知识是"服务多人共享的判断"（比如公司的制度、规范）。两者主体、权限、更新责任都不同。
类比：像"你对某位老客户的私人备注"和"公司公开的员工手册"——前者是服务你一个人跟这位客户的往来，后者是全公司共用的判断依据。
举例：用户记忆里存"这位客户偏好邮件沟通、不喜欢被打电话"；组织知识里存"退款超过 500 元必须经理审批"。前者只服务这个客户，后者是所有客服都要遵守的规则。
为什么重要：主体、权限和更新责任不同——用户记忆由用户（或个人代理）维护，组织知识由组织统一维护，混在一起就会出权限和责任问题。
怎么验证（证据点）：
- 主体明确
- 来源明确
- 生命周期不同
别踩的坑（边界）：个人偏好不能自动成为组织规则——一个用户说"我喜欢这样"，不能直接变成公司规则去约束别人。
落地检查：两类长期信息要分开准入——落地时给用户记忆和组织知识设不同的准入流程和权限，别让个人偏好自动升级成组织规则。
第 4 步：Skill
原文：Skill 保存可重复执行的方法、资料、工具和验收条件。
白话：Skill（技能，指可复用的方法制品）保存的是"一套能反复执行的方法"——包括方法步骤、配套资料、要用到的工具、以及验收条件。
类比：像一份标准操作手册（SOP）——它不只写"结论"，还写"第一步做什么、第二步用什么工具、最后怎么算合格"。
举例：一个"合同风险审查" Skill，里面存了审查方法（逐条检查哪些条款）、资料（风险条款清单）、工具（调用合同解析工具）、验收条件（输出必须覆盖全部风险点并给出依据）。
为什么重要：方法制品与事实存储解决不同问题——Skill 存的是"怎么做"，历史/记忆/知识存的是"发生了什么/是什么"，两者不能混。
怎么验证（证据点）：
- 适用条件
- 执行方法
- 验收规则
别踩的坑（边界）：一段成功对话不能直接成为 Skill——某次对话碰巧做对了，不等于它就沉淀成可复用的方法，中间还差验证和抽象。
落地检查：Skill 需要验证、版本和失效管理——落地时给 Skill 加验证、版本号、失效机制，不能把一段对话直接存成 Skill 就完事。
落地可行性小结
本场景涉及的技术栈：对话历史存储（如消息日志）、状态管理（结构化字段/枚举）、用户记忆存储、组织知识库、Skill 制品管理。真实落地做法：把信息按"用途"分流——历史进日志库、状态进结构化存储、用户记忆与组织知识分开建库并设不同权限、Skill 作为受版本管理的方法制品单独维护。要检查的：状态是否有权威源、个人偏好是否被误当组织规则、Skill 是否有验证和版本。常见坑：用聊天记录当状态、把用户偏好直接写成公司规则、把一次成功对话直接沉淀成 Skill。
回顾
- 信息的用途决定它进哪个库：历史、状态、记忆、知识还是 Skill。
- 历史回答"发生过什么"，用于追溯，不是状态机。
- 状态分任务状态（执行进度）和业务状态（外部权威系统），都要结构化维护。
- 用户记忆服务个体、组织知识服务多人，主体/权限/生命周期不同，要分开准入。
- Skill 是可复用方法制品，需要验证、版本和失效管理，不能由一段对话直接变成。