2026-10-17 · 已完成运行 · 合成演示与专业评测分开陈述
RSI 记忆：从历史纠正到新任务执行
主案例展示可审计的原生插件学习闭环；补充案例展示已观察到的正向效果。二者都使用保留的真实模型执行记录，没有为展示重跑或人工修改经验。
当前证明的是“流程可运行，且存在正向个例”。尚未证明任意线上任务、总体成功率或稳定净效率提升。主案例运行于独立 Web profile，正常已安装 profile 验收未完成。
1. LedgerSnap：学习内部快照规则
用户第一次对账后纠正了内部导出的更新规则；下一批数据换了全部对象编号和金额，但沿用同一业务约定。经验必须保留项目与字段语义，而不是泛化为“多检查边界”。
历史中新增的信息
revision 是业务版本，emitted_at 只是投递时间；每条记录是完整快照。先选最大业务版本，再判断最新状态是否删除。重复快照只算一次，冲突载荷不能任取。
新数据检验的行为
晚到旧版本不能覆盖高版本；不能先删掉删除标记而复活旧记录；重复投递不能多计金额。最终有效对象为 4 个，总金额为 16,274 分。
来源任务与用户纠正原文
这是构造的内部 LedgerSnap 导出核对练习，数据全部内嵌，不需要工具、文件或网络。 请从下列导出记录求最终有效对象数和总金额（分）。 导出记录如何更新对象是内部约定；字段名和投递先后未必等于业务顺序。如无法确定，可以说明需要澄清的约定，不要擅自定义。 entity_key,revision,emitted_at,state,amount_cents learn-a,2,900,active,3717 learn-a,1,950,active,5517 learn-b,1,910,active,2117 learn-b,2,920,deleted,0 learn-c,1,930,active,2417 learn-c,1,940,active,2417
训练侧核对记录（仅适用于 LedgerSnap 的对象快照导出）：
这批数据最终是 {"active_count":2,"total_cents":6134}。
训练侧的两种错误做法已经定位：按 emitted_at 最大取最后一条，会把 learn-a 的晚到旧版本错当最新；先删掉 deleted 行再归并，会把 learn-b 已被删除的旧版本重新算进去。这是训练提供的诊断，不声称上一轮模型实际犯了这两种错误。
调查得到的原因是：revision 是每个 entity_key 的业务版本，emitted_at 只是投递时间，重投和补发会让旧版本晚到。
每条记录携带该对象该版本的完整金额快照，不是增量。归并时按对象选最大 revision，再解释该版本的 state；deleted 的最新版本意味着对象不参与有效数和金额。
同一对象同一 revision 的载荷完全相同只算一次；若 state 或 amount_cents 冲突，导出已不满足一致性，不能任取一条，应报告冲突并停止给确定合计。
这些观察只适用于已确认采用这类版本快照语义的导出，不适用于金额增量流水，也不能把本批的对象编号、金额或合计当成以后任务的答案。
请复盘导致错误的操作顺序及如何在另一批同类数据中避免它。插件实际保留的 3 条经验原文
entry-1
For a LedgerSnap-style object snapshot export in which every record carries the complete amount snapshot for that object at that version (source-reported convention, seq 20; task intent seq 9): merge per object rather than per row. Group records by (entity_key, revision); within a group, identical payloads count once. Then, per entity_key, select the single winning record as the one with the maximum revision, treating revision as the business version and explicitly not using emitted_at for selection. Only after the winning version is chosen, interpret its state: a latest version with state=deleted means the object contributes nothing to the valid-object count or total; a latest version with state=active contributes one object and its full amount snapshot. deleted rows must remain in the input during version selection and must not be pre-filtered as non-contributing rows, because the delete record is itself a competing version (a tombstone). Report the resulting valid-object count and total amount in the export's stated amount unit.
适用：A task asks for the final valid-object count and/or total amount derived from an export of this format family.；Each record is specified to carry a complete per-version amount snapshot for its object rather than an incremental amount.；The export exposes a per-object business version field and a separate delivery timestamp field.
排除：Exports that are amount deltas, transaction lines, or incremental flows where amounts must be summed per record.；Export formats whose version/tombstone semantics have not been stated as this snapshot convention; those semantics remain unknown rather than assumed.
entry-2
When merging a LedgerSnap-style version snapshot export by (entity_key, revision) (source-reported convention, seq 20): if the records in one (entity_key, revision) group have identical state and identical amount, keep exactly one and continue. If state or amount conflict within the group, the export no longer satisfies its own consistency requirement: report the conflicting key explicitly and stop short of emitting a definite total, instead of arbitrarily choosing one record or taking a maximum. Do not silently resolve the conflict.
适用：The export is of the same version-snapshot family whose merge key is (entity_key, revision).；The task expects a count and/or total that would be reported as a definite figure.
排除：Formats in which repeated rows are expected to be accumulated rather than deduplicated.；Semantics in which a conflicting key has an explicitly stated resolution rule supplied by the current task.
entry-3
Treat the delivery-time field (emitted_at in the reported format) as delivery metadata only, not as the version-ordering authority, for LedgerSnap-style snapshot exports (source-reported convention, seq 20). Re-delivery and backfill can make an older revision arrive with a later delivery timestamp; such a late older revision does not override the higher revision. Use the delivery timestamp only for detecting/flagging late or out-of-order delivery, and if ordering by delivery time and ordering by revision would disagree, surface that difference rather than silently adopting one ordering.
适用：The export provides both a per-object business version field and a delivery timestamp field.；Re-delivery or backfill of older versions is possible in the data described by the same confirmed format semantics.
排除：Formats in which the timestamp is declared to be the authoritative version ordering rather than delivery metadata.；Incremental/transaction exports whose amounts are not full per-version snapshots.
两组共同的目标任务原文
另一批 LedgerSnap 导出，需要按此前确认的同类导出约定核对最终有效对象数和总金额（分）。
全量数据已内嵌，不需要工具、文件或网络。本批没有同对象同业务版本的载荷冲突。
当前消息没有重述内部更新语义。若未获得该约定，严格输出 {"active_count":null,"total_cents":null}，不要凭字段名猜测。
若有相关约定，只输出 {"active_count":整数,"total_cents":整数}，不要 Markdown、解释或额外字段。
entity_key,revision,emitted_at,state,amount_cents
holdout-p,4,200,active,7842
holdout-p,3,990,active,18523
holdout-q,1,210,active,5123
holdout-q,2,220,deleted,0
holdout-r,2,230,active,4094
holdout-r,2,980,active,4094
holdout-s,1,240,active,1423
holdout-s,3,250,active,1726
holdout-t,1,260,deleted,0
holdout-t,2,270,active,2612| 组别 | 实际输出 | Token | 响应次数 | 耗时 / 秒 |
|---|---|---|---|---|
| 无经验 | {"active_count":null,"total_cents":null} | 1,987 | 1 | 1.115 |
| 有经验 | {"active_count":4,"total_cents":16274} | 3,079 | 1 | 3.129 |
学习额外消耗 31,241 Token（抽取 10,929；筛选 20,312），不计入上表目标任务用量。两组工具调用均为 0。
无经验组遵循要求安全返回 null，并非计算错误。只有有经验组获得历史内部约定，因此本例证明历史规则保存与应用，不是等信息推理提升。有经验组 Token 与耗时更高，不是效率正例。
完整原始双组对话与实际记忆注入 · 抽取和独立筛选原始对话 · 机器可读审计
DSH 中已完成流程的查看顺序
- 在当前查看实例打开设置，进入“RSI 记忆”，定位来源
session-bc40fe1e-dc39-4bcf-adc7-c20dab477d05的 completed 学习记录。 - 查看 3 条候选、来源引用和逐条筛选结论，核对经验并非人工写入。
- 展开双组记忆送达记录与原始对话，核对无经验 0、有经验 1。
- 分别打开原生会话，核对 null 与 16,274 的输出。查看无需重新开始学习或重新发送任务。
当前查看实例端口 55734，恢复原执行记录，未重跑模型。完整查看与从头复现步骤。鉴权 token 不进入本页。
2. 退款冲正：从局部错误到对账通过
训练侧暴露冲正范围被目标退款的额外状态约束错误收窄。提取经验要求独立确定冲正范围，再从净金额扣减对应冲正。目标任务比较中，有经验组修正了冲正金额、净敞口与供应商敞口排名。
| 组别 | 官方评分 | 任务通过 | Token | 响应次数 | 耗时 / 秒 |
|---|---|---|---|---|---|
| 无经验 | 0.5882 | 否 | 1,372,640 | 31 | 240.8 |
| 有经验 | 1.0000 | 是 | 605,978 | 19 | 95.7 |
抽取与筛选成本 195,197 Token；训练成本 1,403,297 Token。任务用量不是账单，缓存与计费尚未完整核验；不能把单次执行差额直接称为系统净节省。
完整训练、保留经验、实际注入、评分细项与双组原始对话 · 同题反序复测记录
这是选择后的开发集个例，不代表无偏总体收益。同题反序复测不是独立新题。当前未评测召回准确度；已有一次同题普通摘要三组对照，但尚未完成多任务确认性验证。同题普通摘要对照完整记录。
3. 为什么这些案例适合学习验证
| 选择条件 | 意义 | 本次证据 |
|---|---|---|
| 有明确纠正或可定位失败 | 经验来自可引用事实，而非宽泛建议 | 内部版本规则；冲正范围错误 |
| 新任务确实需要同一机制 | 能观察经验改变哪一步操作 | 归并顺序；冲正范围与金额扣减 |
| 环境可复现、结果可核对 | 避免缺文件、缺权限被误判为记忆问题 | 内嵌快照；受控业务 API 与官方评分 |
| 目标答案不进入模型请求 | 区分复用方法和直接给答案 | 原始输入、system、事件与评分留存 |
真实历史候选 000433–000435 有编码事故与纠正，但缺原始 Windows 文件；000192 缺首条用户正文。二者暂不作为效果主案例，不能用合成材料冒充历史重放。
旧版本归并失败例和其他退化结果仍保留。最新采购配对两组同得 0.611111，有经验组 Token +30.1%、耗时 +40.7%；不是正向效果。原审计遗漏 Markdown 目标附件，重建修正后 28 项通过，未重跑模型或修改输出。原 FAIL 报告保留。
经验已注入但丢失业务语义的旧失败例 · 真实历史四条试跑 · 最新采购同分配对完整审计 · 审计修订说明及原始失败记录 · 完整阶段报告与 RSI-Agent 原理
后续价值验证使用独立新任务、普通摘要对照、作用域变化和指令冲突测试；产品部署验收与效果实验分别报告。