晨星
文档角色：参考资产（Reference Asset）
版本：v1.0 — 2026-05-01
对应正式实现：.trae/目录下的 skills/self-improving-agent/（主要记忆写入者）、skills/skill-language-policy/SKILL.md（记忆记忆写入规范）
Trae 原生记忆系统概述
Trae 的"Core Memory"系统通过两个机制工作：
会话启动时注入
新对话启动时，IDE 从本地加密数据库中读取 user_scope 和 project_scope 的记忆条目，封装为 XML 结构注入到 Agent 的系统提示词中。Agent 看到的记忆形式如：
<core_memories>
<user_scope>
<m id="abc123">
<title>代码与规则设计偏好</title>
<keywords>稳定实现|鲁棒性|规则设计|显式映射</keywords>
<content>偏好稳定、可靠、可审计的实现...</content>
</m>
...
</user_scope>
<project_scope>
<m id="def456">...</m>
...
</project_scope>
</core_memories>运行时操作工具
Agent 可在会话中通过 manage_core_memory 工具操作记忆：
字段结构
每条记忆包含以下字段：
当前 Skill 对记忆系统的使用
使用概览
核心流程：写入链路
触发条件（命令失败/用户纠正/新发现）
↓
self-improving-agent
├── 分类（Core Memory / Project Rule / New Skill）
├── 去重检查（是否已有相似记忆？）
├── 低价值过滤（是否值得记录？）
└── manage_core_memory ADD/UPDATE
├── scope: user / project
├── category: Knowledge / Rule / Experience
└── via: discovery / request核心流程：维护链路
触发条件（用户说"帮我整理记忆" / 接近20条上限 / 记忆碎片膨胀）
↓
self-improving-agent → resources/memory-maintenance.md
├── 说明限制（告知用户记忆集可能不完整）
├── 用户确认实际总量
├── 审计五步（枚举 → 分类 → 合并 → 删除 → 验证）
└── manage_core_memory DELETE + ADD核心流程：知识晋升链路
发现模式重复 3+ 次的教训
↓
self-improving-agent → resources/promotion-guide.md
├── 判断是否满足晋升条件（跨文件适用？预防再犯？）
├── 选择目标（Core Memory UPDATE / .trae/rules/ 新规则 / 新 Skill）
├── 作者晋升
└── 更新原条目状态实际记忆条目的分类分布
当前项目中的记忆条目按 category 的分布情况：
当前局限性
容量相关
可见性与可验证性
跨会话与持久性
工具能力不足
当前 Skill 覆盖的缺口
局限性对实际工作的影响
记忆丢失风险
最实际的风险场景：
用户在多个会话中逐步积累记忆 → 达到 20 条上限 →
新会话写入新记忆 → 系统静默淘汰一条旧记忆 →
该旧记忆中可能包含关键的配置约束或用户偏好 →
Agent 在后续任务中违反该约束 → 用户困惑当前 mitigation：memory-maintenance.md 要求创建前检查容量，但 Agent 无法获知真实条数，只能凭注入内容推测。
Agent 盲区
会话 A 中记录了"项目已从 npm 迁移到 pnpm"
会话 B 启动时，这条记忆未被注入（受选择策略影响）
会话 B 的 Agent 继续执行 npm install → 失败当前 mitigation：无。这是注入策略透明性问题，Skill 层面无法绕过。
"帮我整理记忆"的用户摩擦
用户说"帮我整理记忆"
Agent 需要用户手动去设置页面确认实际条数
用户觉得麻烦 → 放弃
记忆继续膨胀 → 自动淘汰触发当前 mitigation：memory-maintenance.md 已设计流程，但无法消除用户操作步骤。
与外部记忆系统的对比
当前项目为何仍优先使用 Core Memory
尽管存在上述局限，当前项目仍将 Core Memory 作为默认写入路径（而非文件系统）。原因：
-
自动注入：新会话无需 Agent 主动读取；Skill 和 Rule 中定义的核心约束会自动进入上下文
-
结构化字段：title/keywords/scope/category 便于语义匹配和精准检索
-
与 IDE 集成：设置在"规则与技能 → Memories"下可见，用户可查看
-
无需手动管理路径：文件系统方案需要决定放在哪、叫什么名字、谁来读、何时读
项目采用三级晋升路径做权衡：
Core Memory（高频、轻量、自动注入）
↓ 模式重复 3+ 次
.trae/rules/ 规则（明确触发条件，alwaysApply 或 globs）
↓ 通用多步骤工作流
skills/ 技能包（完整执行契约）文件系统作为补充路径
对于以下场景，当前项目使用文件系统而非 Core Memory：
-
完整的参考文档（如本文档本身）：超过 400 字符、需要结构化的参考资料
-
Skill/规则的模板和示例：需要版本追踪、多人可读
-
执行契约（SKILL.md）：需要完整的工作流、输入输出契约、失败处理
现有缓解措施
当前项目已建立的缓解措施：
未解决的局限性（需要 IDE 层面改进）
以下局限在当前 Skill 层面无法缓解，需要 Trae IDE 或系统提示层面的改进：
-
LIST/COUNT 工具缺失：Agent 无法枚举或统计记忆库，无法独立验证完整性
-
注入策略不透明：无法确定 Agent 看到的是全部记忆还是子集
-
会话内快照不刷新：写入后同一会话内的后续步骤无法感知变更
-
无搜索/检索接口：Agent 不能按关键词查询记忆库
-
无跨会话一致性保证：两个会话可能同时写同一个 scope，冲突时后写者覆盖
-
无自动过期/TTL：需要手动审计，无法自动化
-
无版本历史：UPDATE/DELETE 不可回滚
总结
Trae 的 Core Memory 系统提供了一条低摩擦的"自动注入 + 结构化写入"路径，在当前项目中扮演高频、轻量、自动的记忆角色，与文件系统的"低频、重型、持久"路径形成互补。
主要权衡：
当前 Skill 体系通过"创建前检查/审计流程/晋升路径"三件套缓解了大部分容量和碎片问题，但注入不透明性和LIST 工具缺失这两个根本局限需要在 IDE 层面解决才能彻底消除盲区。