Repository navigation
团队使用问题 #16
Description
关于以下问题中，提到的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 加时间窗权重。
Activity
Upper9527 commentedon Apr 23, 2026
哈喽同学，感谢您的问题！
场景描述非常准确 — 5-10 人团队共享 skill repo、evolver 从多人 session 中提取共识，这正是 SkillClaw 当前架构已经支持的核心流程。A 成功 / B 失败 → evolver 聚合提取共识的路径已经 work。
但您指出的"语义漂移"风险（重构期间老 skill 被过时 evidence refine）确实是当前的一个盲区。目前 _build_session_evidence() 对 session 是等权处理的，没有时间窗衰减、也没有 evidence 失效机制。在项目稳定期这不是大问题，但在重构密集期会成为真实风险。
我们后续计划的改进方向：
这个问题和 #14 提出的跨轮记忆也有交叉 — 如果有 evolve_memory，就能记住"第 N 轮重构开始，之前的 Kafka 相关 evidence 可能已失效"这类元信息。
Upper9527 commentedon Oct 21, 2026
补充一个范围说明，避免前面的回复让人误解：共享会话聚合和技能更新已经存在，但“夜间 A/B 验证保证单调改进”、evidence 时间衰减和 TTL 并不是当前默认实现的承诺。默认
direct发布与可选validated候选验证流程也应区分。这里保留跟踪 evidence 新鲜度/失效策略，局域网部署的具体配置示例由 #28 跟踪。Upper9527 commentedon Oct 21, 2026
已合并 #104，先落地可配置的 evidence 时间窗：在 evolver 设置
EVOLVE_EVIDENCE_MAX_AGE_SECONDS=604800可只接受最近七天的会话文件；默认0保持原行为。workflow/agent 两个引擎共用过滤逻辑，过期、未来、无时区或无效时间戳不会进入演化，也不会被当作已消费对象删除，而是保留供核查。13 项回归测试通过。边界：目前文件 timestamp 是上传时间，不是每个原始回合的发生时间；这不是时间衰减权重、已有技能过期策略，也不是 A/B 单调改进保证。被排除的文件会在后续轮次再次扫描，需要人工归档/清理。若你的重构场景需要按 commit/原始回合时间作废证据，请补充希望使用的时间来源及窗口，我们可以据此继续扩展，而不直接假定上传时间足够。