personal agent 怎么做状态管理？系统建模？和编程实施

回复 群友 1597： 这个问题我在 Joye 的公开资料里没找到专门讲 personal agent 状态管理的文章，下面是我基于前面几条回复的思路整理的，不代表 Joye 的官方方案。 先分清三类状态，它们的生命周期和存储方式不一样，混在一起最容易出问题。 第一类是会话状态，也就是当前这轮对话的上下文和正在进行的任务，比如"用户刚让我订明天的票，还缺出发时间"。它生命周期短，放内存或短期缓存就行，结束后要么归档，要么丢弃。 第二类是任务状态，适用于需要跨多步、跨时间的事情。建议建成显式的状态机，比如 pending、running、waiting_user、done、failed 几个状态，每次迁移都记录原因。这样 agent 中途断掉或者等用户确认之后，能从断点接着做，而不是重新猜。 第三类是长期记忆，也就是用户画像和偏好。这一层最需要建模。每条记忆建议至少包含这些字段：内容本身、来源（哪次对话或哪个场景产生的）、时间戳、可信度（用户明说还是系统推断）、作用域（属于哪个场景）、状态（active、superseded、expired）。推断出来的内容和用户明确表达的内容一定要分开标，否则后面没法校正。 系统建模上，我会把它拆成几个实体：用户、场景、目标、任务、记忆条目、工具和账号授权。其中场景是一等公民，很多越界问题就出在这里。同一个人在工作场景和生活场景里的记忆应该分开存，检索时先按场景和权限过滤，再做相关性排序和摘要，越界数据不能进入摘要请求。 编程实现上，有几点比较实用。第一，用事件日志做事实来源，每次对话产生的写入、修改、纠正都作为事件追加保存，当前状态由事件回放或者快照推导出来。这样出了问题可以追溯，也能做回归测试。第二，写入要有门槛。一次随口的话不直接升格成画像项，同一主题多次重复出现或用户明确确认后才提炼。第三，新信息覆盖旧信息时，把旧条目标为 superseded，而不是直接删除，同时保留可回溯的记录。第四，过期机制要有，长期没被确认的推断自动降权或失效。第五，用户要能看到系统记了什么，并且能纠正或删除，这决定了记错之后能不能收敛。 存储层面，早期用 SQLite 加 JSON 字段就够了，关键是 scope 和 status 两个字段要建索引，检索时强制带上过滤条件。 测试上，建议把真实对话脚本录下来做回放，检查三件事：该记的有没有记、不该记的有没有进画像、换场景之后有没有越界召回。这比调召回算法更能暴露问题。 如果你是在做这块，可以先把"记什么、何时升格、何时过期、谁能读"这四条规则写成文档，再去搭表结构，顺序反过来通常会返工。