pa的用户画像和用户能力边界能不能放在一块？我把用户画像放在working memory这个设计是否合理

回复 群友 2236： 能不能放一块，取决于你把“画像”和“能力边界”当什么。这两个东西的更新频率、可信度、谁有权改，都不一样，混在一个区块里迟早出事。 先拆开看： 用户画像是什么：偏好、习惯、常用表达、时间安排、说话风格、对什么东西不耐烦。它是从交互里归纳出来的，本质是概率性推断，会漂移，会过时，也经常错。 用户能力边界是什么：这个用户能做什么、不能做什么、乐意做什么、授权你做什么。比如“不会写前端”“后端可以自己搞，别替他敲代码”“涉及付款必须确认”“某些目录不许碰”。这是约束，是事实性或授权性的，错了会直接造成事故。 区别在于：画像错了，顶多是不贴心；边界错了，是会越权。所以这两者的可靠性要求完全不同，画像可以容错、可以模糊，边界必须明确、必须可覆盖、必须能追溯到来源（是用户明说的，还是你猜的）。 那放 working memory 合不合理？分两说： 边界不该只放在 working memory。因为 working memory 是会话级、短生命周期的，而“不许动这个目录”“花钱要先问”这类东西是长期契约，会话清空就丢，等于每次重新赌一次。边界应该进一个持久化、有优先级的层——比如常驻的系统层或者独立的 policy store，能覆盖、能被用户一句话修正、能被审计。 画像放 working memory 是合理的，但要注意两点。一是 working memory 里应该放的是“本次相关的画像切片”，不是全量画像。比如这次是聊代码，那就带上“偏好短答、讨厌啰嗦注释、习惯用 pnpm”，不必把“周末不加班”“爱喝什么”全塞进来。全量画像放持久 store，working memory 只做按需加载。二是画像要有置信度和来源，别让一句玩笑话沉淀成“该用户不喜欢 X”写死进去。 更具体的建议，分三层： 第一层，持久画像库。结构化一点，每条带 key、值、置信度、最后更新时间和来源（用户明说 / 推断）。用久了会积累噪声，所以必须能衰减和删除，这是硬需求。 第二层，约束层，也就是能力边界。单独存，优先级高于画像和当次对话。这一层里要区分硬约束和软偏好——硬的是“不能”，软的只是提醒。而且硬约束冲突时应该让 agent 停下来问，不是自己找折中。 第三层，working memory。每次会话开始时按当前任务选画像切片 + 全量约束装进来，会话结束把新观察写回第一层，绝不写回第二层。 所以回答你的问题：不要放在一块，工作区里可以并排出现，但底层存储要分开。画像进 working memory 合适，边界进 working memory 不合适，边界至少要有持久层做底，working memory 里那份只是当次快照。 顺带提醒一个容易漏的坑：边界要支持“本次例外”。用户说“这次就改这个目录”，你不能把这个例外写回持久层，得标记成本次会话有效。很多人图省事直接写进画像，结果一周后 pa 还觉得那个目录能动——这就是典型的把授权和偏好混在一起。