团队使用问题

[BaBiQ888]

关于以下问题中，提到的evidence，是否是后续的发展？

项目组使用：5–10 人团队共享一套"项目 SOP"

场景：一个支付团队在做对账系统重构，6 个工程师每天用 Agent 写代码、查日志、处理工单。

• 证据来源：6 人的 sessions 全部汇入同一个 skill repo。G(对账差异定位) 这一组里，可能 A 工程师靠"先查 Kafka offset"成功、B 工程师漏了这步失败 →
  evolver 提取出共识。
• 自主进化的体现：当某个新依赖（比如换了消息队列）被频繁出现在失败 sessions 里，evolver 触发 create 一条新 skill；旧 skill 通过夜间 A/B
  验证，回归通过才单调合入 deployment pool 推送到所有人。
• 价值/局限：这是 SkillClaw 论文最贴合的甜点区——人数够多产生统计信号，又共享同一 codebase 让 skill 真正可复用。主要风险是项目语义漂移（重构期间老
  skill 还没失效就被 refine 进了过时知识），需要给 evidence 加时间窗权重。

[Upper9527]

哈喽同学，感谢您的问题！

场景描述非常准确 — 5-10 人团队共享 skill repo、evolver 从多人 session 中提取共识，这正是 SkillClaw 当前架构已经支持的核心流程。A 成功 / B 失败 → evolver 聚合提取共识的路径已经 work。

但您指出的"语义漂移"风险（重构期间老 skill 被过时 evidence refine）确实是当前的一个盲区。目前 _build_session_evidence() 对 session 是等权处理的，没有时间窗衰减、也没有 evidence 失效机制。在项目稳定期这不是大问题，但在重构密集期会成为真实风险。

我们后续计划的改进方向：

1. Evidence 时间衰减 — 在 _build_session_evidence() 中引入 recency weighting，近期 session 权重更高，或者给 evolve prompt 标注每条 evidence 的时间距离
2. Evidence TTL / 时间窗过滤 — 在 _drain_sessions() 或聚合阶段加入可配置的时间窗，超过阈值的老 session 降权或丢弃
3. 代码变更信号关联 — 更长远地，如果能检测到 codebase 有大规模变更（比如 commit frequency spike），自动提高 evidence 的新鲜度要求

这个问题和 #14 提出的跨轮记忆也有交叉 — 如果有 evolve_memory，就能记住"第 N 轮重构开始，之前的 Kafka 相关 evidence 可能已失效"这类元信息。