## Role、Skill、Memory 与当前上下文的边界 建立 4 层分工： - 长期职责放 Role - 可复用做法放 Skill - 会跨任务复用的长期信息放 Memory - 这次任务的输入放当前消息、thread 或 Task 本章只讨论分层，不讨论文风或具体模板写法。 ```text 请把下面这段信息分到 Role、Skill、Memory 或当前任务上下文，并说明理由： 1. 这是哪个 Agent 长期负责的事情 2. 这类任务要按什么步骤处理 3. 这个客户一直偏好什么输出格式 4. 这次任务具体要交付什么 ``` AgentTeam 的可维护性，很大程度上取决于信息是否放在正确的层。 ### 四层各自解决的问题 | 层 | 解决的问题 | 典型内容 | | --- | --- | --- | | Role | 这个 Agent 长期负责什么 | 职责、边界、协作方式 | | Skill | 这类任务通常怎么做 | 步骤、检查项、输出格式 | | Memory | 哪些信息会跨任务复用，并应作为长期记忆资源被管理 | 长期事实、偏好、稳定约束、共享记忆基线 | | 当前上下文 | 这次具体要做什么 | 本次需求、附件、限制、验收口径 | 这四层不只是存放位置不同，而是作用时机不同。 - Role 在接任务时起作用 - Skill 在执行方法选择时起作用 - Memory 在补充长期背景时起作用 - 当前上下文在当前任务求解时起作用 ### Memory 为什么必须单独拎出来 Memory 负责保存会跨任务复用的长期信息。 在 AgentTeam 的产品模型里，Memory 也是一种可被管理、授权和绑定的长期记忆资源。团队可以把一份受管理 Memory 共享给其他成员，由具备权限的人查看或维护；也可以基于既有 Memory 派生副本，再绑定到指定 Agent，作为该 Agent 的长期记忆基础。 它和 Skill 的区别在于：Skill 保存的是“方法”，Memory 保存的是“事实、偏好和稳定背景”。它和当前上下文的区别在于：当前上下文只服务这一次任务，而 Memory 会继续影响下一次、再下一次任务。 举例来说： - “评审结果要按结论 / 风险 / 建议输出”更像 Skill - “这个客户所有评审都要求把 blocker 单独列出来”更像 Memory - “这次评审只看支付模块，不看埋点改动”则是当前任务上下文 ### 放错层会发生什么 如果信息被放错层，问题通常不是立即报错，而是系统会越来越难用。 #### 把客户长期偏好放进当前消息 结果是每次任务都要重新讲一遍，Agent 无法积累稳定背景。 #### 把临时需求写进 Memory 结果是短期噪音长期残留，后续任务会被过期要求污染。 #### 把 40 条步骤写进 Role 结果是 Role 不再定义职责边界，而变成庞杂操作手册，后续几乎无法复用。 #### 把团队岗位分工写进 Skill 结果是 Skill 不再是通用做法，而变成只适用于某一个 Agent 的私有说明。 ### 推荐的沉淀顺序 在实践里，信息通常不是一开始就知道该放哪层，而是逐步沉淀出来的。 更合理的顺序是： 1. 先用当前消息把任务跑通 2. 重复出现的方法再沉淀成 Skill 3. 长期稳定职责再提炼为 Role 4. 真的会跨任务影响判断的背景，再进入 Memory 这个顺序能避免两个常见错误： - 流程还没稳定就过早固化进 Skill - 任务刚做一次就把大量噪音写进 Memory ### 一个判断标准 当你拿到一段信息，最简单的判断方式是问 4 个问题： 1. 它是在定义长期职责吗？如果是，优先考虑 Role 2. 它是在定义稳定做法吗？如果是，优先考虑 Skill 3. 它是在描述可跨任务复用的长期事实吗？如果是，优先考虑 Memory 4. 它只是这次任务的输入吗？如果是，留在当前上下文 如果一段信息几天后就会失效，通常不值得写进 Role、Skill 或 Memory。 Memory 不应该承担所有历史记录；只有会跨任务继续影响判断的背景，才值得被长期保存。 常见反例： - Skill 里塞满客户背景：它在替 Memory 干活 - Role 写成 40 条步骤：它在替 Skill 干活 - Memory 里堆满临时聊天纪要：它在替当前上下文干活 Role、通用 Skill 和共享 Memory 规则的大改动，最好经过至少一次同行 Review。 来自仓库、文档库、工单系统或业务系统的长期稳定事实，可以进入 Memory；一次性抓取结果本身不必直接固化。 读完本章后，读者应该能把“职责、做法、长期事实、当前输入”四类信息稳定分开。