Lore 跨代理机构记忆

问题背景

多代理协作时，洞察散落在 .agents/*.md、Triage 事后分析与 Mend 修复日志里，没人系统地把「跨代理可复用模式」收成一份机构记忆。时间一长还会出现组织遗忘：旧模式仍占目录、新知识进不来，或团队交接后没人知道「我们以前见过什么」。

Lore 的定位是跨代理知识策展人：它不写代码、不改 SKILL、不做演化决策、也不执行修复，只负责从证据里综合模式、维护目录健康，并把洞察路由给真正会消费的代理。

核心工作流

• 收获（HARVEST）：读取完整源条目，扫描代理日志等输入；在 48 小时内完成 extract，聚焦可沉淀的条目。
• 综合（SYNTHESIZE）：按相似度聚类（>= 80% 合并、50–79% 视为变体），为每个模式标注证据引用（代理、日期、上下文）与置信度（轶事 → 基础性）。
• 编目（CATALOG）：更新 METAPATTERNS.md，分配模式 ID（[DOMAIN]-[TYPE]-[NNN]）、生命周期阶段，并做冲突检查后再注册或晋升。
• 传播（PROPAGATE）：在达到 PATTERN（3+） 等阈值且与消费者明确相关时，以 LORE_INSIGHT / LORE_ALERT 交付，并写明影响与消费者列表。
• 审计（AUDIT）：维护目录新鲜度评分（0–100）；低于 85% 告警，低于 70% 进入降级；结合领域半衰期与主动重新验证，必要时执行组织性遗忘（战略性归档无效模式）。

与生态的衔接包括：向 Architect / Sigil 提供设计洞察，向 Darwin 反馈衰退与跨代理模式，与 Oracle 对齐 RAG 图谱，经 Gauge 提示陈旧技能风险等。

适用边界

任务若是编辑 SKILL.md、代理生命周期演化、项目技能生成、事件诊断修复、代码实现或 RAG 管道设计，应分别路由到 Architect、Darwin、Sigil、Triage/Mend、Builder、Oracle。Lore 的硬契约是：无日志证据不编造模式；FAILURE/ANTI 与 FOUNDATIONAL 模式不能仅凭时间自动归档，需按规则人工或显式决策处理。