RFC: RSIBridge — Unified Evolution Data Layer for Memory & Skills / 记忆与技能共享演化数据层

[pclin1212]

RFC: RSIBridge — Unified Evolution Data Layer for Memory & Skills / 记忆与技能共享演化数据层

状态：Draft（讨论中）
Related: #5645 #5646 #5539 #3888 #5906 #5333
实现形态：独立可信扩展包（全栈插件 + 扩展槽位），零宿主核心改动
版本：v0.1

---

背景：当前架构的不足

DeerFlow 的 Harness 定位（v2.x）强调 long-horizon 能力，但在「从运行经验中自我改进」这条线上，现有架构存在四个结构性缺口：

缺口 1：Skill 自演进与记忆演进是两条互不相通的平行线。 #5645 为 Skill 文档定义了受控变更通道（guarded mutation、崩溃恢复、与人工编辑协调），但学习策略外置、尚无认领者；记忆侧 #5906 的 signal_classification 只能在批次层面打 reinforcement / correction 标签并影响下一次提取提示词——没有独立经验存储、没有修正回路。同一个用户纠正事件，可能同时证明记忆有错和 Skill 指导有缺陷，但两套系统各看各的，数据互不可见，甚至可能得出矛盾的改进结论。

缺口 2：记忆只有「生长」，没有「演化」。 记忆提取的所有决策权在宿主（prescreen / signal_classification 三态由部署配置控制且默认关闭），提取产出只有「关于世界的事实」，不产生「关于提取策略该如何改进的经验」。已存记忆写错了无法被使用反馈回溯修正——没有遗忘与改写机制。用五阶段框架衡量（信号采集→归因→经验生成→审批→固化），记忆系统完成度约 45-50%：信号采集较好，归因只到标签级，审批与元层完全缺失。

缺口 3：受控变更接口只覆盖 Skill，没有 memory mutation API。 #5645 是当前唯一受控变更通道。没有对应记忆接口，记忆自演进只能停留在「提示词注入」级别，永远无法形成修正闭环。

缺口 4：信号源碎片化。 SystemModelCallObserver、TaskLifecycleContributor、循环检测、#5906 的批次标签——宿主其实已经在产生丰富的演化信号原料，但没有统一聚合层，无法以「证据链」的形式被任何改进策略消费。

我们要做的方向：RSIBridge（共享演化数据层）

核心主张：「运行经验」是中立资产，不应归属任何单一子系统。同一份结构化经验，记忆侧可用它修正事实与提取策略，Skill 侧可用它修订工作流指导——一份经验、多个消费者视图。

flowchart TB
    subgraph Host["DeerFlow 宿主（零核心改动）"]
    SO["system_model_observer"]:::have
    TL["task_lifecycle"]:::have
    ER["RunEvidenceReader（#5645）"]:::have
    MUT["evolution mutation API"]:::gap
    end
    subgraph RSI["RSIBridge 扩展包"]
    SH["SignalHub 统一信号枢纽<br/>采集·去重·证据链"]
    AE["AttributionEngine 归因引擎<br/>信号→改进目标路由"]
    XS["ExperienceStore 经验存储<br/>版本化·可回滚·多消费者视图"]
    PG["PolicyGate 三态门控+人工审批"]:::have
    end
    SO & TL & ER --> SH --> AE --> XS --> PG
    PG -- "memory 视图" --> MEM["记忆修正/提取策略改进"]
    PG -- "skill 视图" --> SK["经 #5645 受控变更"]
    PG -- "meta 视图" --> META["归因策略自身的改进数据（L2 预留）"]
    classDef have stroke:#4a4
    classDef gap stroke:#e33,stroke-dasharray: 5 5

Loading

四个组件一句话定义

• SignalHub：统一信号模型（user_correction / outcome_failure / loop_detected / extraction_anomaly 等），复用宿主全部已有观察面，信号带 EvidenceRef（引用 + 内容摘要，防证据漂移），不复制证据本体；
• AttributionEngine：把信号路由到 memory / skill / meta 目标，默认纯规则引擎（零 LLM、低延迟），产出可解释的 ProposedChange 增量补丁；
• ExperienceStore：插件自管存储（对齐 bookmarks 先例），经验永不直接改写目标本体——独立经验层 + 消费时按需合并，可整体禁用/回滚零残留；
• PolicyGate：off → shadow → enforce 三态门（语义对齐 feat(memory): add Jev pre-screening and signal classification over a shared TypeSafe client #5906），第一期所有 enforce 动作人工触发，审查界面走 feat(plugins): full-stack plugin APIs and bookmarks #5647/feat(plugins): support manifests and static asset directories #5685 的全栈插件页面能力。

信号模型（Signal Model）

@dataclass(frozen=True)
class EvolutionSignal:
    """一条可归因的运行经验信号。冻结、含溯源、含证据引用。"""
    signal_id: str                    # uuid，不可变
    created_at: str                   # ISO-8601

    # 溯源（三重定位）
    run_id: str
    thread_id: str
    task_id: str | None

    # 信号分类
    kind: SignalKind
    payload: Mapping[str, Any]        # kind 专属载荷

    # 证据链（至少一条，弱证据信号在归因时降权）
    evidence: tuple[EvidenceRef, ...]

    # 来源标记
    origin: Literal["memory_prescreen",       # 复用 #5906 输出
                    "system_model_observer",
                    "task_lifecycle",
                    "user_explicit",
                    "agent_loop"]

    # 消费者路由提示（归因前的初筛，非最终决定）
    consumer_hint: tuple[ConsumerDomain, ...] = ("both",)

class SignalKind(StrEnum):
    USER_CORRECTION     = "user_correction"      # 用户纠正先前输出/事实
    USER_REINFORCEMENT  = "user_reinforcement"  # 用户确认/强化既有行为
    OUTCOME_FAILURE     = "outcome_failure"     # 任务终态 failed / aborted
    OUTCOME_SUCCESS     = "outcome_success"     # 任务终态 completed（正信号）
    FAILURE_RETRY       = "failure_retry"       # 同类失败后重试
    LOOP_DETECTED       = "loop_detected"       # 宿主循环检测触发
    TOOL_MISUSE         = "tool_misuse"         # 工具参数反复被拒/调用畸形
    DRIFT_DETECTED      = "drift_detected"      # 长会话目标漂移
    EXTRACTION_ANOMALY  = "extraction_anomaly"  # 记忆提取结果与后续行为矛盾

@dataclass(frozen=True)
class EvidenceRef:
    """指向宿主运行证据的不可变引用。RSIBridge 不复制证据本体，只存引用。"""
    kind: Literal["message", "tool_call", "model_call", "task_record", "memory_fact"]
    ref: str        # 宿主侧稳定标识（message_id / span_id 等）
    digest: str     # 内容 SHA-256，防证据漂移
    # 复核时经 RunEvidenceReader 重新拉取并比对 digest，不一致则该信号作废

归因引擎（AttributionEngine）

class AttributionResult(TypedDict):
    target: ConsumerDomain         # "memory" | "skill" | "meta" | "none"
    target_ref: str | None         # 记忆事实 id / skill 文档 id / 策略版本 id
    confidence: float              # [0,1]，低于 CONFIDENCE_FLOOR 的进 shadow 不进提案
    rationale: str                 # 可解释归因理由（审查页面展示）
    proposed_change: ProposedChange | None

@dataclass(frozen=True)
class ProposedChange:
    """领域无关的增量补丁提案。具体消费者负责解释性合并。"""
    change_id: str
    patch_format: Literal["json-patch", "structured-diff"]
    patch: Mapping[str, Any]        # 对目标内容的增量变更（绝不整包覆盖）
    evidence_ids: tuple[str, ...]   # 支撑该提案的 signal_id 集合
    generated_by: str              # 归因策略版本号（L2 层的 A/B 基础）

归因路由规则（第一期为纯规则引擎 + 可选 LLM 辅助，默认纯规则）：

• user_correction + 矛盾指向已存记忆 → memory（事实修正）
• user_correction + 矛盾指向 Skill 指导出的行为 → skill（工作流修正）
• outcome_failure 反复 + 同类 tool_misuse → skill（技能缺陷）
• extraction_anomaly 聚类上升 → meta（提取策略问题，不修数据修策略）
• 无法归因 → none，仅入统计

经验存储（ExperienceStore）

@dataclass(frozen=True)
class Experience:
    """中立经验资产。同一份经验，多消费者视图。"""
    experience_id: str
    version: int                     # 经验本体可修订，版本单调递增
    status: Literal["draft", "shadowed", "approved", "applied", "retired"]

    target: ConsumerDomain          # "memory" | "skill" | "meta"
    target_ref: str | None
    change: ProposedChange

    signal_ids: tuple[str, ...]     # 证据链上溯（signal → evidence → 宿主运行记录）
    attribution: AttributionResult   # 含 generated_by 策略版本

    lifecycle: tuple[LifecycleEvent, ...]   # 全程审计轨迹
    applies_to: Mapping[str, Any]   # 消费者侧合并时的适配参数

存储约定（对齐 bookmarks 先例）：插件自管 SQLite + table_prefix: "rsibridge_" 注册到 alembic 排除清单；经验永不直接改写目标本体，消费侧按需合并，RSIBridge 可整体禁用/回滚零残留。

三态门控与治理（PolicyGate）

# 部署配置（运维主权，运行期只读）
rsibridge:
  memory_evolution: off        # off | shadow | enforce
  skill_evolution: off         # off | shadow | enforce；enforce 依赖 #5645 合并
  meta_evolution: off          # 第一期强制 off
  attribution_confidence_floor: 0.7
  require_human_approval: true  # enforce 应用前必须人工批准（第一期不可关闭）

三态语义对齐 #5906：shadow 记录「若 enforce 会做什么」并对照实际后续运行验证；enforce 才真正进入消费者合并。第一期所有 enforce 动作人工触发（审查页面按钮）。

关键设计决策

1. 增量补丁而非改写：经验以 JSON-patch 式增量存储，与 feat(skills): add guarded evolution host APIs #5645 的受控变更模型字段级对齐；feat(skills): add guarded evolution host APIs #5645 合并前 Skill 侧仅 shadow；
2. 消费 feat(memory): add Jev pre-screening and signal classification over a shared TypeSafe client #5906 而非重算：复用 signal_classification 已有标签作为信号源之一，避免两套归因打架（见开放问题 1）；
3. 零宿主改动起步：八个扩展槽位足够完成信号采集、存储、审查界面全链路；Skill 写入等 feat(skills): add guarded evolution host APIs #5645，记忆写入暴露缺口（见开放问题 2）；
4. 为 RSI 预留递归结构：每份经验记录产出它的归因策略版本号，L1（改进记忆/Skill）→ L2（改进归因策略）→ L3（改进改进过程）三层可递归，第一期只做 L1。

对接矩阵

RSIBridge 组件	宿主接口	状态
信号采集	system_model_observer() / task_lifecycle()	✅ 已有
证据复核	RunEvidenceReader	✅ 已有
常驻与存储	service() + table_prefix	✅ 已有
审查界面	plugin() 页面/操作/工具	✅ 已有
Skill 写入	#5645 mutation API	⏳ 审查中
记忆写入/修正	——	❌ 缺失（开放问题 2）

开放问题（本 RFC 希望与社区讨论的核心）

1. 信号标签升格：feat(memory): add Jev pre-screening and signal classification over a shared TypeSafe client #5906 的 reinforcement/correction 输出目前是记忆内部消费，建议升格为公共信号 API 或定义稳定导出格式；
2. Memory mutation host API 缺位：若无记忆侧受控变更接口，记忆自演进无法闭环。是否应作为 RFC: Skill Evolution Host APIs / Skill 自演进宿主接口 #5646 范围扩展或独立 RFC？
3. 经验可移植性：是否与 [RFC] Export current custom skills as portable .skill packages #5333（.skill 便携包）对齐，使经验可跨部署迁移？涉及隐私边界需讨论。

第一个集成原型（Proposal）

以一个最小可用的 RSIBridge 插件作为 bookmarks 之后的第二个全栈插件集成：manually triggered candidate proposal + 插件自有审查页面（提案、验证结果、证据链可视化），学习策略完全留在插件内。这同时验证：全栈插件扩展点是否足够、#5645 契约是否够用、以及暴露记忆侧缺失的公共接口。

RSI 三层路线图

层	内容	第一期	预留的结构
L1 经验层	从运行学习，改进记忆与 Skill	✅ 本 RFC	—
L2 策略层	用 L1 数据改进归因/生成策略自身	仅埋点	ProposedChange.generated_by 策略版本号 + meta 目标域
L3 递归层	改进「改进策略的生成过程」	❌	ExperienceStore 的版本化与审计轨迹即证据基础

[AnnaSuSu]

支持把运行经验作为 Memory 和 Skill 共用的证据来源，并把学习策略放在独立插件里。手动生成候选、通过插件页面审查的原型也适合作为起点。我建议先把下面几处边界说清楚，再推进实现：

1. 现有 Memory 能力的描述需要收窄。 当前 DeerMem 已有事实更新、删除、过期审查和合并机制，例如 MemoryUpdater 中的 update_memory_fact / delete_memory_fact。这里值得补的是“将使用反馈关联到具体记忆及其版本，再通过面向插件的受控接口修正”的闭环；已有内部修改能力与公共 mutation 契约应分开描述。“没有遗忘与改写机制”以及缺少计算依据的“完成度 45–50%”容易让讨论偏离实际缺口。

2. 信号、归因和补丁生成需要分开。 outcome_failure 加 tool_misuse 可以触发调查，但原因也可能是环境、工具接口变化，或 Agent 没有遵循 Skill。规则路由适合作为初筛；生成修改前还需要定位实际使用的 Memory / Skill 版本、支撑归因的行为证据，以及正确修改内容的来源。同样，运行状态 completed 不应直接等同于任务结果正确。

3. 审批和安全校验之外，需要明确效果验证。 shadow 能记录候选，但仅观察未应用候选的后续运行，不能证明候选会改善结果。明确的用户事实纠正可以主要核对来源、范围和冲突；从经历归纳出的策略或 Skill 修改，则应有相同任务和预算下的新旧对照及回归检查。后续还应记录用了哪个版本、是否实际遵循指导、结果如何；applied 只能表示应用成功。

4. 需要区分运行时叠加与持久发布。 “经验永不改写目标本体、禁用后零残留”和“经 feat(skills): add guarded evolution host APIs #5645 发布 Skill 修改”目前没有清晰衔接。如果是叠加，禁用可停止后续注入，但历史影响仍存在；如果是正式发布，关闭插件不会撤销已接受的修改，撤回也必须处理后续人工编辑和版本冲突，不能承诺零残留。

5. 建议把第一期验收压到一个具体闭环。 可以先选一个已有 Skill：明确问题和证据 → 手动生成一个候选 → 页面展示差异和新旧验证结果 → 人工发布 → 记录后续效果，并验证撤回条件。feat(skills): add guarded evolution host APIs #5645 合并前先做候选和评估；Memory 公共变更接口根据实际接入缺口单独讨论，不扩进 feat(skills): add guarded evolution host APIs #5645。共享证据结构可以保留，但不必第一期接齐所有信号源；L2/L3 继续留在后续路线图。

这样原型既能检验现有扩展点是否够用，也能回答最关键的问题：同一份经验经由这层机制，是否确实改善了之后的任务。

[pclin1212]

感谢逐条审阅，这几点都成立，我们接受并已列入 RFC v0.2 修订。逐点回应：

1. Memory 能力描述——接受，修正措辞。 已核实 MemoryUpdater（deermem/core/updater.py）确有事实更新、删除、过期审查与合并。RFC v0.2 会把“没有遗忘与改写机制”改为准确的缺口陈述：内部修改能力已存在，缺的是（a）将使用反馈关联到具体记忆条目及其版本的闭环，（b）面向插件的受控修正接口。撤回"45-50%"的量化表述——那是一次粗略自评，没有计算依据，不应出现在 RFC 里。

2. 信号/归因/补丁生成分离——接受，拆为三段。 归因引擎改为 triage（规则初筛）→ investigation（定位实际使用的 Memory/Skill 版本、收集支撑归因的行为证据、确定正确内容的来源）→ patch generation。明确两点：规则路由只做 triage，不直接产出补丁；completed 只代表宿主终态，新增 outcome_validity（unknown/correct/incorrect）独立记录，“运行成功”不进入经验生成。tool_misuse + outcome_failure 的调查结论也允许是“环境变化”或“Agent 未遵循 Skill”——此时产出的是调查记录而非修改候选。

3. 效果验证——接受，applied 语义收窄。 applied 仅表示“应用成功”。验证分两类：用户事实纠正类候选主要核对来源、范围与既有事实冲突；从经历归纳的策略/Skill 修改必须做同任务同预算的新旧对照 + 回归检查，且记录：使用了哪个版本、是否实际遵循指导、结果如何。shadow 期对未应用候选的后续观察只作为挑选进入对照实验的信号，不作为改善证明——这条会写进 v0.2 的“验证协议”一节。

4. 叠加 vs 持久发布——接受，这是 v0.2 最重要的一处修正。 明确二分：运行时叠加（Memory 侧 hints/overlay 路径）：禁用后停止后续注入，但已注入对话的历史影响仍在，不承诺“零残留”；持久发布（Skill 侧经 feat(skills): add guarded evolution host APIs #5645）：禁用插件不撤销已接受的变更，撤回必须处理发布后的人工编辑与版本冲突。“禁用后零残留”的原表述撤回。

5. 第一期验收——接受，压到单个 Skill 闭环。 v0.2 的第一期范围改为：选定一个已有 Skill → 明确问题与证据 → 手动生成一个候选 → 页面展示差异与新旧验证结果 → 人工发布 → 记录后续效果 → 验证撤回条件。feat(skills): add guarded evolution host APIs #5645 合并前只做候选与评估；Memory 公共变更接口按实际接入缺口单独开 RFC 讨论，不并入 feat(skills): add guarded evolution host APIs #5645，也不阻塞本 RFC 的 Skill 侧推进。共享证据结构保留，但第一期不接齐所有信号源（先 task_lifecycle 一路）；L2/L3 留在路线图。

[Totoro-qaq]

方向我支持：把运行证据做成 Memory/Skill 共用的一层、学习策略放独立插件、默认关闭并要求人工审批。我在 main（8a3a309d）上核对到的几处事实，供你改稿时参考：

• 图里 RunEvidenceReader 标成了 feat(skills): add guarded evolution host APIs #5645，我核对到它来自已合并的 feat(extensions): expose incremental run evidence reader #5405/feat(extensions): add request-scoped run evidence access #5727。它按 (thread_id, run_id, seq) 翻页，据我看事件里没有 event_id 和内容摘要；带 event_id、content_sha256 的是 feat(skills): add guarded evolution host APIs #5645 里尚未合并的 completed_run_evidence。EvidenceRef 或许可以选定其中一个来定义。
• bookmarks 用的是独立 SQLite 文件（storage_path），并没有用 table_prefix（后者是给写进宿主库的表用的）。RFC 里两种存储方式好像混在了一起，可以再确认一下想采用哪一种。
• feat(skills): add guarded evolution host APIs #5645 的 stage() 接收的是完整 SKILL.md 内容加 expected_revision，所以 JSON-patch 可能更适合作为插件内部的表示，和 feat(skills): add guarded evolution host APIs #5645 谈不上字段级对齐。
• feat(memory): add Jev pre-screening and signal classification over a shared TypeSafe client #5906 的信号标签目前只进 extraction_callback（默认只打日志），扩展拿不到，origin: memory_prescreen 可能需要先和 Vanzeren 商量导出方式。另外 main 上已有 skill_manage 和 skill_evolution: 配置项，键名与 RFC 里的重名而含义不同，可以考虑换个名字避免混淆。
• 第一期原型和 RFC: Skill Evolution Host APIs / Skill 自演进宿主接口 #5646 下 AnnaSuSu 邀请 RykerFeng 做的第一步（手动触发候选 + 插件自有页面）基本是同一件事，我没看到他回复。或许可以先问问 RykerFeng 有没有排期；如果他暂时没有，我可以来做这个第一步。

第一期可以考虑压到一个只读、用户手动触发的"纠正归因视图"：对自己的一个会话展示纠正消息、用到的 skill、是否注入过 memory，给出归因并让用户标注同意/不同意。不写任何数据，先检验"一次纠正是否同时牵涉 memory 和 skill"这个核心假设；Skill 闭环等 #5645，Memory 变更契约另起 RFC。

[pclin1212]

感谢建议

[pclin1212]

RFC: RSIBridge — Unified Evolution Data Layer for Memory & Skills（v0.2 修订版）

状态：Draft（根据 @AnnaSuSu 审阅意见修订，见文末修订记录）
Related: #5645 #5646 #5539 #3888 #5906 #5333
实现形态：独立可信扩展包（全栈插件 + 扩展槽位），零宿主核心改动

1. 动机与缺口（v0.2 修正后的准确陈述）

DeerFlow 在「从运行经验中改进系统」这条线上存在三个结构性缺口：

缺口 1：信号源碎片化且互不相通。 SystemModelCallObserver、TaskLifecycleContributor、循环检测、#5906 的批次标签已在产生丰富的演化信号原料，但没有统一聚合层，无法以证据链形式被改进策略消费。同一个用户纠正事件可能同时关联记忆与 Skill，但两条线各看各的。

缺口 2（修正）：记忆的内部修改能力已存在，缺的是反馈闭环与公共受控接口。 DeerMem 已具备事实更新、删除、过期审查与合并（MemoryUpdater 的 update_memory_fact / delete_memory_fact 等）。真正缺失的是：(a) 将使用反馈关联到具体记忆条目及其版本的闭环——即「运行中观察到某条已存记忆有误」无法系统性地定位到 (memory_fact_id, version) 并进入修正流程；(b) 面向插件的公共 mutation 契约——内部修改能力与扩展可用的受控接口是两回事。（v0.1 中「没有遗忘与改写机制」及「完成度 45-50%」的表述不准确，已撤回。）

缺口 3（修正）：受控变更接口只覆盖 Skill。 #5645 为 Skill 文档定义了 guarded mutation，但没有对应的记忆公共接口。此缺口按实际接入需要单独开 RFC 讨论，不并入 #5645，也不阻塞本 RFC 的 Skill 侧推进。

2. 核心主张

「运行经验」是中立资产：一份带证据链的结构化经验，记忆侧与 Skill 侧以各自视角消费。RSIBridge 提供共享的信号聚合、归因调查、候选管理、验证与治理基础设施；学习策略、补丁内容与发布决策留在插件与人工。

3. 架构（v0.2：三段式管线）

flowchart TB
    subgraph Host["DeerFlow 宿主"]
    TL["task_lifecycle<br/>(第一期唯一信号源)"]
    SO["system_model_observer 等其它信号源<br/>(第一期不接入，结构预留)"]
    ER["RunEvidenceReader"]
    MUT["#5645 mutation API<br/>(合并前仅候选+评估)"]
    end
    subgraph RSI["RSIBridge"]
    T["① Triage 规则初筛<br/>只判定「值得调查」，不产出补丁"]
    INV["② Investigation 调查<br/>定位实际使用的 Memory/Skill 版本<br/>收集行为证据<br/>确定正确内容来源（user_explicit 优先）"]
    CG["③ Candidate 生成<br/>人工触发，附验证计划"]
    VP["验证协议<br/>事实纠正: 来源/范围/冲突核对<br/>策略与 Skill 修改: 同任务同预算新旧对照+回归"]
    PG["审批与发布治理"]
    end
    TL --> T --> INV --> CG --> VP --> PG
    ER -.供调查与复核.-> INV
    PG -- "Skill: 持久发布" --> MUT
    PG -- "Memory: 运行时叠加<br/>(独立 RFC 讨论公共接口)" --> O["hints/overlay"]
    SO -.-> T

Loading

三段式的关键约束（对应审阅意见 2）：

• Triage 只做初筛。outcome_failure + tool_misuse 触发的是调查而非补丁；调查结论允许是「环境变化」「工具接口变化」「Agent 未遵循 Skill」——此时产出调查记录，不产出修改候选。
• 调查必须完成三件事才允许生成候选：定位实际使用的 Memory/Skill 版本；收集支撑归因的行为证据；确定正确修改内容的来源（用户明确给出的纠正内容优先于推断）。
• completed 只代表宿主终态。新增独立字段 outcome_validity（unknown / correct / incorrect），「运行成功」本身不进入经验生成。

4. 叠加与持久发布：两种消费形态（v0.2 新增，替代原「零残留」表述）

原 v0.1 「经验永不改写目标本体、禁用后零残留」的表述与 #5645 的持久发布语义矛盾，撤回。明确二分：

	运行时叠加（Memory 侧，第一期形态）	持久发布（Skill 侧，经 #5645）
生效方式	检索时 overlay / 提取提示词注入	受控变更，正式合入目标文档
禁用插件后	停止后续注入；已注入对话的历史影响仍在——不承诺零残留	不撤销已接受的变更
撤回条件	停止叠加即等效撤回	必须处理发布后的人工编辑与版本冲突，撤回是一次新的受控变更

5. 验证协议（v0.2 新增）

applied 仅表示「发布成功」，不表示「有效」。 有效性由验证记录承载：

• 事实纠正类候选：主要核对来源、作用范围、与既有记忆的冲突；通过后批准。
• 策略 / Skill 修改类候选（从经历归纳而来）：必须做相同任务、相同预算下的新旧对照 + 回归检查，并记录三要素：实际使用的版本、是否实际遵循指导、结果如何。
• shadow 期观察（未应用候选的后续运行）只作为挑选进入对照实验的信号，不构成改善证明。
• 验证记录随经验持久化，构成发布决策与撤回评估的依据。

6. 状态机（v0.2 修订）

stateDiagram-v2
    [*] --> triaged: 规则初筛命中
    triaged --> investigated: 调查完成(版本/证据/来源)
    triaged --> rejected: 调查结论为环境变化等非候选
    investigated --> validated: 验证通过(对照/核对)
    investigated --> rejected: 验证不通过
    validated --> approved: 人工批准
    approved --> applied: 发布成功(#5645)
    applied --> retired: 撤回(一次新的受控变更)
    rejected --> [*]

Loading

每条经验携带验证记录（版本、遵循情况、对照结果）与全程审计轨迹。

7. 第一期验收：单个 Skill 闭环（v0.2 收窄）

第一期范围压到一个具体闭环，全部人工触发：

1. 选定一个已有 Skill，明确问题与证据；
2. 手动生成一个候选（含差异与验证计划）；
3. 页面展示候选差异与新旧验证结果；
4. 人工发布；
5. 记录后续同类任务效果；
6. 验证撤回条件。

边界：信号源第一期只接 task_lifecycle 一路（共享证据结构保留，其余信号源后续接入）；Memory 公共变更接口缺口单独开 RFC；L2/L3（改进归因策略自身、改进改进过程）留在路线图，本期仅以 generated_by 策略版本号埋点。

第一期的判定标准（回答「这层机制是否值得存在」）：同一份经验经由 RSIBridge，在对照条件下是否确实改善了之后的同类任务。

8. 现状

M0 原型骨架已就绪（examples/deerflow-extension-rsibridge）：四槽位注册（plugin / system_model_observer / task_lifecycle / service）、任务信号采集（含幂等去重）、规则 triage、审查页面（候选列表 / 批准 / 撤回）、只读检索工具。状态机将按 §6 扩展，新增验证记录字段。

修订记录

• v0.2（本次）：按 @AnnaSuSu 六点意见修订——①修正 Memory 缺口陈述，区分内部修改能力与公共受控接口，撤回无依据量化；②信号/归因/补丁生成拆为 triage→investigation→generation 三段，新增 outcome_validity，调查允许产出非候选结论；③新增验证协议，applied 语义收窄为「发布成功」，shadow 观察降级为实验挑选信号；④新增叠加 vs 持久发布二分，撤回「零残留」承诺；⑤第一期验收收窄为单 Skill 闭环，Memory mutation 缺口独立讨论、不并入 feat(skills): add guarded evolution host APIs #5645；⑥信号源只接 task_lifecycle。
• v0.1：初稿。