Gumloop 功能规格 - Reflections

初始上下文

1. 概览

背景

在 Reflections 之前，Gumloop Agent 的学习机制由两个被动组件构成：

两者的问题相同：用户必须先发现并指出问题，Agent 才能改进。如果用户习惯了某个低效流程、从未注意到某个重复错误、或者不知道「可以有更好的方式」——Agent 永远不会改进。

Reflections 填补了这个盲区。官方描述：「一个在自动驾驶仪上运行的内置绩效评审。Agent 审查历史工作，跨对话寻找模式，并主动提议改进——Agent 自己在搜寻你没有发现的问题。」

Gumloop 由此形成完整的三层 Agent 学习体系：

┌─────────────────────────────────────────────────────────────────────┐
│                     Gumloop Agent 学习体系                           │
├───────────────────┬───────────────────┬─────────────────────────────┤
│  实时反应层         │  自主发现层         │  指令/知识层               │
│  (reactive)        │  (proactive)       │  (static)                  │
├───────────────────┼───────────────────┼─────────────────────────────┤
│  Self-Improve      │  Reflections       │  Agent Instructions        │
│  Instructions      │                    │  Skills Library            │
│                    │                    │                            │
│  "用户说改什么       │  "Agent 自己发现     │  "用户预设的               │
│   就改什么"          │   该改什么"          │   行为规则"                │
└───────────────────┴───────────────────┴─────────────────────────────┘

目标

1. 发现盲区问题：Agent 自动发现跨对话的系统性模式——用户可能习惯了某个低效流程但从未意识到可以改进
2. 降低改进成本：一次审批替代数十次手动调整——从 O(n) 到 O(1)
3. 建立学习飞轮：使用越多 → 反思数据越多 → Agent 越聪明 → 使用体验越好 → 使用更多
4. 知识沉淀：发现的模式转化为永久性的 Skill/Instruction 改进，而非一次性修正

2. 核心机制

2.1 五步反思流程

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  Step 1  │───▶│  Step 2  │───▶│  Step 3  │───▶│  Step 4  │───▶│  Step 5  │
│ Gather   │    │  Mine    │    │ Validate │    │  Check   │    │ Propose  │
│ 收集活动  │    │ 挖掘模式  │    │ 对话验证  │    │ 查重去冗  │    │ 提议改进  │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │               │
     ▼               ▼               ▼               ▼               ▼
  工具调用        候选模式        真实+一致        已有知识        改进提案
  对话记录        +置信度         +值得修         未覆盖          (卡片形式)
  错误日志        +支持数         复的             的             进入审核队列

Step 1 — Gather Recent Activity（收集近期活动）

Agent 聚合自上次 Reflection 运行以来的所有操作日志——工具调用（tool calls）、对话记录（conversations）、错误信息（errors）。这构成分析的原始数据集。

数据范围：仅分析上次运行以来的增量数据——不是全量历史。这使每次运行的计算成本可控，但也意味着低频但重要的长期模式可能被遗漏。

Step 2 — Mine for Patterns（挖掘模式）

系统自动分析原始数据，识别以下候选模式：

• 重复请求类型：用户反复要求 Agent 做同一类事（如「每次查完数据都要帮我转格式」）
• 反复出现的错误：相同 API 错误码、相同超时模式（如「Snowflake 查询在下午 3 点总是超时」）
• 低效的工具调用序列：同一组工具按相同顺序被多次调用（如「搜索 Jira → 按状态筛选 → 格式化表格」出现 8 次）
• 频繁被重复抓取的数据：同一数据在多次对话中被反复获取

每个候选模式附带：

• 置信度分数（confidence score）：算法对该模式真实性的评估
• 支持交互次数（count of supporting interactions）：该模式出现了多少次

Step 3 — Validate with Transcripts（对话验证） — 关键步骤

这是五步流程中最重要的质量控制环节。Agent 阅读每个候选模式对应的实际对话记录（transcripts），验证三个问题：

1. 模式是否真实存在？（不是统计噪声）
2. 模式是否跨不同交互一致？（不是单次特定情境）
3. 模式是否值得修复？（修复的成本是否低于继续承受的代价）

被拒绝的情况：

• 一次性事件（只出现一次）
• 已被处理过的已知问题
• 任务固有的行为特征（如「每次 API 调用都要传认证头」——这是正确行为）

Step 4 — Check Existing Knowledge（检查已有知识）

Agent 审查当前 Instructions 和 Skills，确保提议的修改未被已有配置覆盖。同时检查之前的 Reflections：

• 同一模式反复出现 → 标记为「持续性问题」（persistent pattern）
• 之前的修复已解决该模式 → 标记为「已解决」（resolved）
• 已有类似改进在审核队列中 → 避免重复提议

Step 5 — Propose Improvements（提议改进）

对每个验证通过的模式，Agent 选择最合适的改进类别（见 2.2），撰写包含以下内容的详细提案：

• 标题：一行概括（如「Snowflake 日期格式自动转换」）
• 理由：基于对话证据的解释（如「过去一周 8 次遇到此问题，每次浪费约 2 条消息纠正」）
• 确切的提示词（prompt）：Agent 获批后将执行的完整修改指令

2.2 四种改进类型

2.3 应用行为（Apply Behavior）

Auto-Apply 的安全机制：只有同时满足「低风险 + 充分证据」的建议才自动应用。任何存在模糊性的建议——即使只差一点——仍进入审核队列。系统默认宁可漏掉好建议也不自动应用坏建议。

2.4 调度与跳过

• Cron 调度：默认每日 UTC 22:00。可通过配置面板自定义（每 2 天、每周等）
• 自动跳过：如果自上次运行以来没有新活动（无对话/工具调用），Reflection 自动跳过——不消耗 Credits
• 建议频率：高频 Agent（每日 10+ 对话）每日运行；低频 Agent（每周几次）每 2-3 天或每周

2.5 报告投递

三个可选的通知渠道，均在 Configuration 面板中，默认关闭：

• Email Report：完成的 Reflection 报告发送到指定邮箱（需验证地址）
• Slack DM Report：完成的报告以 Slack DM 发送给 Agent 所有者
• Notify When Skipped：当因活动量不足跳过调度时发通知（需先开启至少一种投递渠道）

2.6 权限模型

• Owner / Editor：可查看、应用、驳回 Reflections
• Viewer：只能查看 Reflections 页面，不可操作
• 应用 Reflection 后的可见性：在 Agent 对话历史中创建一条交互记录，显示具体编辑了哪些文件、创建/更新了哪些 Skills、以及修改的理由

3. 功能需求

模块 A — 反思执行引擎

模块 B — 改进类型

模块 C — 审核与应用

模块 D — 报告投递

模块 E — 配置

4. 用户场景

5. 竞争分析

关键洞察

1. 「主动」是范式分水岭：所有现有 Agent 学习方案都需要用户先发现问题再触发改进。Reflections 是首个让 Agent 自主发现改进空间的产品化方案。这改变了 Agent 与用户的关系——Agent 不再只是「执行者」，而是「自我进化的协作者」
2. 验证步骤是核心壁垒：Step 3（读取对话记录验证模式真实性）是 Reflections 与学术界的 Reflexion/LangGraph 方案的关键差异——后者没有验证步骤或验证很弱。没有验证的自动学习 = 逐步学错 + 放大错误。Gumloop 通过「人工审核队列」建立了额外的安全层
3. 学习飞轮 vs 一次性分析：Reflections 的增量设计（每次只分析上次运行以来的新活动）比全量分析更高效，但可能遗漏低频但重要的长期模式——这是未来「长周期 Reflections」或「季度深度反思」的演进空间
4. 团队级学习是网络效应：当前 Reflections 是 per-Agent 的。如果未来扩展到跨 Agent（「3 个 Agent 都遇到了同一个 API 问题」），将产生网络效应——一个 Agent 学到的可以即时惠及整个组织

6. 遥测

7. 未来演进方向

关键演进判断

1. Review Queue → Auto-Apply 的转化率是关键信任指标：默认 Review Queue 是正确的保守策略。随着用户对提案质量建立信任，Auto-Apply 的使用比例将反映系统成熟度。如果 Auto-Apply 占比超过 70% 而用户纠正率未上升，说明系统足够可靠
2. 团队级学习是质变而非增量改进：单 Agent 学习是线性增长（1 个 Agent 学习 1 份经验），跨 Agent 学习是网络效应（N 个 Agent 共享 N 份经验）。当团队中的任何一个 Agent 学到的东西能即时惠及所有 Agent，迁移成本将达到极值——一个经过 6 个月团队级 Reflections 训练的组织，技术上可以迁移到其他平台，但知识积累全部归零
3. 验证步骤的质量退化是最大风险：如果 Step 3 因为成本压力或架构变更而弱化（如从「阅读完整对话记录」退化为「看摘要」），用户信任会迅速崩塌。这是 Reflections 的「不做就会死」的底线
4. 长周期 Reflections 捕获低频模式：当前增量设计只看上次运行以来的新活动——日频运行看不到「每月初报表格式需要调整」这种月度模式。需要专门的季度/月度深度反思

源文档参考

• spec_resource/gumloop-docs_reflections-full.md — Reflections 官方帮助文档完整存档（五步流程、四种改进类型、配置选项、FAQ、最佳实践）
• spec_resource/gumloop-docs_agents.md — Agents 帮助文档（Queue & Steer、Subagents 执行细节、凭据管理）

由 Claude 竞品情报系统生成 · 来源：Gumloop Reflections 帮助文档 · 评分 13/13（战略3 护城河3 用户3 复杂度2 创新2）