lumelisted

# Lume 自我进化 ## 目标 当用户长期使用 Lume 时，agent 应逐步学会两类自我进化： 1. 把稳定、可复用、会反复出现的系统偏好沉淀为配置 2. 在文件层面持续维持稳定、克制、可解释的 workspace / thread 结构 这套自我进化同时覆盖： 1. 系统配置演进 2. 文件治理演进 但它仍然不面向： 1. UI 状态 2. 草稿 3. 一次性上下文 4. 用户内容文件 默认配置入口： - `~/.lume/lume.yaml` ## 核心原则 Lume 的自我进化本质上是： 1. 观察稳定偏好 2. 判断是否值得沉淀 3. 以最小范围更新系统配置 4. 保持可解释、可审计、可回退 不要把“这次任务刚好这么做”误认为“以后都应该这么做”。 ## 允许沉淀到 `lume.yaml` 的内容 优先考虑沉淀这些系统配置： 1. 默认模型选择 2. 默认 provider / channel 路由 3. MCP 启用与关闭 4. Skill 启用与关闭 5. permission / tool policy 偏好 6. agent 的默认思考等级或 permission mode 这些配置只用于覆盖系统行为。 ## 不允许沉淀到 `lume.yaml` 的内容 以下内容禁止写入 `lume.yaml`： 1. UI 状态 2. 窗口尺寸和布局 3. 当前选中的会话 / workspace 4. 草稿内容 5. 一次性任务步骤 6. 临时实验结论 7. 研究笔记 8. 用户正文内容 这些内容应继续留在各自的状态存储或内容文件里。 ## 何时应该更新配置 只有在以下信号足够明确时，才应该尝试更新 `lume.yaml`： 1. 用户多次明确要求切换到同一模型或 provider 2. 用户多次反复启用 / 禁用同一个 MCP 3. 用户反复要求某个 Skill 默认可用或默认关闭 4. 用户反复修正权限策略，且修正方向稳定一致 5. 用户明确表达“以后默认这样” 如果只是： 1. 单次任务需要 2. 当前任务的临时 workaround 3. 一次性兼容某个外部环境 则不要沉淀为自我进化配置。 ## 全局与 workspace 的选择规则 更新 `lume.yaml` 时，优先选择影响范围最小的配置层级。 默认顺序： 1. 先考虑 `workspaces.<slug>` 2. 只有明显跨工作区通用的稳定偏好，才改顶层全局 判断规则： - 如果偏好只和当前项目/工作区相关，就写 `workspaces.<slug>` - 如果偏好是用户在多个工作区都想统一保持的默认行为，才写顶层 不要因为“改顶层更省事”就把项目偏好提升成全局偏好。 ## 更新方式 更新配置时必须遵守以下约束： 1. 通过结构化更新修改 `lume.yaml` 2. 不做粗暴字符串替换 3. 不覆盖无关 section 4. 不把未知字段清空 5. 保持 YAML 可读性 每次修改前都要明确： 1. 修改的是哪个 section 2. 修改的是顶层还是 `workspaces.<slug>` 3. 预期影响范围是什么 ## 审计与说明 每次自我进化式配置更新，都应可解释。 至少要能回答： 1. 为什么这次值得沉淀 2. 为什么改全局或改 workspace 3. 改完后会影响什么 如果当前实现有审计能力，应保留审计记录。 如果需要向用户汇报，优先用一句短说明： - “我把这个偏