# Gumloop 功能规格 — Reflections（Agent 反思学习系统）

版本：v1.2 | 来源：官方帮助文档（完整验证） | 日期：2026-06-01

> **文档状态**：已完成 — 基于官方文档完整重写
> **源文档**：[spec_resource/gumloop-docs_reflections-full.md](../spec_resource/gumloop-docs_reflections-full.md) — docs.gumloop.com/core-concepts/reflections.md 完整存档
> **评分**：13/13（战略3 护城河3 用户3 复杂度2 创新2）

---

## 初始上下文

- **产品/团队**：Gumloop / AI Agent 平台
- **功能**：Reflections — Agent 定时自主审查历史工作、跨对话发现模式、自动提议改进的学习系统
- **版本起源**：v9.7.0 "Port Hope" (2026-05-22)
- **描述**：Reflections 是 Agent 的「元认知层」。Agent 按照 Cron 计划定期回顾自上次运行以来的所有交互——对话记录、工具调用、错误日志——通过五步流程（收集→挖掘→验证→检查→提议）自动发现跨对话的系统性问题，并生成具体的改进提案。提案以卡片形式进入审核队列，用户审核后一键应用。四种改进类型覆盖：新建 Skill、修复 Skill、更新 Instructions、调整 Tool Access
- **解决的问题**：Agent 的改进完全依赖用户主动发现并手动纠正问题——用户没意识到的重复错误和低效模式永远不会被修复
- **战略动机**：此前 Agent 仅在被手动纠正或编辑指令时才改进——「这无法规模化」。Reflections 开启了 Agent 的**学习飞轮**：更多使用 → 更多反思数据 → 更好的 Agent → 更多使用。这是从 Tool-Agent 到 Learning-Agent 的关键跃迁
- **目标用户与痛点**：(1) 高频 Agent 用户（每日 10+ 交互）——手动改进跟不上使用速度 (2) 团队 Agent 管理者——希望 Agent 从团队协作中持续优化 (3) Agent Builder——减少手工微调工作量
- **平台范围**：Web 端。报告可通过 Slack DM 或 Email 投递。仅 Owner/Editor 可应用 Reflections
- **关键成功指标**：Reflection 提案采纳率、Reflection 启用率、Agent 用户纠正频率下降比例、Auto-Apply 占比

---

## 1. 概览

### 背景

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

| 机制 | 触发方式 | 能力 |
|------|---------|------|
| **Self-Improve Instructions** | 用户实时纠正 → Agent 更新 Prompt | 对话内即时修正 |
| **Skill Editing** | 用户要求或 Agent 学到新事物时 | 创建/修改 Skill |

两者的问题相同：**用户必须先发现并指出问题，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 四种改进类型

| 类型 | 触发条件 | 复杂度 | 示例 |
|------|---------|--------|------|
| **New Skill** | ≥3 次一致的多步骤工具调用序列 | 高 | 搜索 Jira → 按状态筛选 → 格式化为表格 模式出现 8 次 → 创建「Jira 状态报告」Skill |
| **Skill Fix** | 现有 Skill 覆盖场景但遗漏边界情况 | 中 | 「客户外联」Skill 未处理 Out-of-Office 自动回复 → 增加 OOO 检测和重试逻辑 |
| **Instruction Update** | 行为规则或领域知识，非工作流 | 低 | 用户总是纠正「用 UTC 不要用本地时间」→ 更新指令添加「所有时间戳使用 UTC」 |
| **Tool Access** | Agent 在用 hack 方式绕过缺失的集成 | 中 | Agent 反复用 sandbox curl 调用某 API（而非通过 MCP）→ 提议添加该 MCP 集成 |

### 2.3 应用行为（Apply Behavior）

| 模式 | 行为 | 适用场景 | 风险 |
|------|------|---------|------|
| **Review Queue（默认）** | 每个提案进入人工审核队列。批准前不对 Agent 做任何修改 | 生产环境、面向客户的 Agent | 低——完全人工控制 |
| **Auto-Apply Eligible** | 低风险、证据充分的建议自动应用。高风险/不确定的仍进入审核队列 | 内部 Agent、个人助手 | 中——系统被描述为「保守」 |

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 — 反思执行引擎

| ID | 触发场景 | 系统行为 | 优先级 |
|----|---------|---------|--------|
| A1 | Cron 触发器到达调度时间 | 系统检查自上次运行以来是否有新活动，无则跳过（零 Credit 消耗），有则启动五步流程 | P0 |
| A2 | Step 1 — 收集 | 聚合上次运行以来的所有工具调用、对话记录和错误日志，形成分析数据集 | P0 |
| A3 | Step 2 — 挖掘 | 自动分析数据集产出候选模式列表，每个附带置信度分数和交互支持次数 | P0 |
| A4 | Step 3 — 验证 | Agent 逐个阅读候选模式对应的实际对话记录，验证真实性、一致性和修复价值 | P0 |
| A5 | Step 4 — 检查 | Agent 审查当前 Instructions/Skills/待处理 Reflections，去重并标记持续性/已解决模式 | P0 |
| A6 | Step 5 — 提议 | 为每个验证通过的模式生成改进提案卡片（标题 + 理由 + 确切提示词）| P0 |

### 模块 B — 改进类型

| ID | 触发场景 | 系统行为 | 优先级 |
|----|---------|---------|--------|
| B1 | New Skill 场景（≥3 步重复工作流） | 分析工具调用序列相似度，生成包含完整流程的 Skill 定义 | P0 |
| B2 | Skill Fix 场景（边界情况遗漏） | 对比 Skill 定义与实际执行差异，生成增量修复提示词 | P0 |
| B3 | Instruction Update 场景（行为规则） | 从对话纠正中提取规则，生成指令更新提示词 | P0 |
| B4 | Tool Access 场景（绕过缺失集成） | 检测 sandbox curl / 替代方案使用模式，提议添加正确的 MCP 集成 | P1 |

### 模块 C — 审核与应用

| ID | 触发场景 | 系统行为 | 优先级 |
|----|---------|---------|--------|
| C1 | 用户打开 Reflections 页面 | 展示所有待处理提案卡片（按日期分组），显示标题、理由、状态、日期 | P0 |
| C2 | 用户点击提案卡片 | 展开完整详情——包含 Agent 获批后将执行的确切提示词 | P0 |
| C3 | 用户点击 Apply（Review Queue 模式） | Agent 启动新的自我改进交互，按提示词创建/修改 Skill 或更新 Instructions | P0 |
| C4 | Auto-Apply 模式触发 | 系统仅自动应用低风险+充分证据的建议；任何模糊建议保持待审核 | P0 |
| C5 | 用户驳回提案 | 提案被标记为 Dismissed，从待处理列表移除。后续运行可生成新版本取代 | P1 |
| C6 | 应用完成后 | Agent 对话历史中创建条目，显示编辑内容和修改原因（变更可见性） | P0 |
| C7 | 权限校验 | 仅 Owner/Editor 可应用/驳回；Viewer 尝试操作时返回权限错误 | P0 |

### 模块 D — 报告投递

| ID | 触发场景 | 系统行为 | 优先级 |
|----|---------|---------|--------|
| D1 | 用户配置 Email 报告并验证地址 | Reflection 完成后发送邮件报告到指定地址（含提案摘要和链接） | P1 |
| D2 | 用户开启 Slack DM 报告 | Reflection 完成后发送 DM 给 Agent 所有者（含提案摘要和链接） | P1 |
| D3 | 用户开启跳过通知且至少有一种投递渠道 | Reflection 因无新活动跳过时发送通知 | P2 |
| D4 | 用户未配置任何投递渠道 | Reflection 仅在应用内展示，不发送外部通知 | P0 |

### 模块 E — 配置

| ID | 触发场景 | 系统行为 | 优先级 |
|----|---------|---------|--------|
| E1 | 用户在 Agent 侧边栏点击 Reflections → Enable | 开启 Reflections，自动创建匹配所选计划的 Cron 触发器 | P0 |
| E2 | 用户配置 Extra Reflection Instructions | 保存自由文本字段内容，作为下次运行时 Agent 的分析焦点引导 | P1 |
| E3 | 用户修改 Apply Behavior | Review Queue ↔ Auto-Apply 即时切换 | P0 |
| E4 | 用户修改 Cron 调度 | 更新触发器计划，下次按新计划运行 | P1 |

---

## 4. 用户场景

### 场景 1 — 数据分析师：Agent 自动发现重复格式问题

**用户画像：**
张敏，32 岁，电商数据分析师。每天与 Agent 交互 15-20 次。三周前 Snowflake 数据源日期格式变更后，每次查询完都要手动加一句「把日期转成 YYYY-MM-DD」。她已经习惯了每次都加这句话——从未想过可以让 Agent 记住。

**用户故事：**
作为数据分析师，我希望 Agent 能在我自己都没意识到的情况下，发现「每次查 Snowflake 都要手动转日期格式」这个重复模式，并自动提议创建一个 Skill 来永久解决它——这样我就不用每次浪费 2 条消息做格式转换。

**验收标准：**
- Reflections 按每日计划运行
- Step 2 挖掘出「Snowflake 日期格式转换」为候选模式（置信度高，8 次出现）
- Step 3 通过对话记录验证——确认每次都是同一个转换需求
- Step 4 检查后发现当前 Skills 中没有覆盖
- Step 5 生成「New Skill: Snowflake 日期格式化」提案——标题明确、理由基于证据、提示词可执行
- 张敏在 Reflections 页面看到卡片，审核提示词后点击 Apply
- Agent 创建 Skill，以后查询 Snowflake 自动转换日期格式
- 对话历史中出现一条记录：「根据 Reflection 提案 #XX 创建了 Snowflake 格式化 Skill」

### 场景 2 — 客服团队 Lead：Agent 发现缺失的集成

**用户画像：**
陈立，28 岁，客服团队 Lead。Agent 在处理客户问题时经常需要在 Zendesk 工单中添加内部备注，但团队只给 Agent 配了 Zendesk 的「读工单」权限。Agent 开始用「发邮件给客服经理」来替代——这能工作但很不优雅。陈立不知道这个问题，因为 Agent 确实完成了任务（虽然方式曲折）。

**用户故事：**
作为客服团队 Lead，我希望 Reflections 能发现 Agent 在反复用「发邮件给某人」来替代「写 Zendesk 内部备注」——这说明 Agent 缺少一个正确的集成。然后 Reflections 提议添加 Zendesk 写入权限，而不是让我自己去排查 Agent 为什么老是发邮件。

**验收标准：**
- Step 2 挖掘出「sandbox curl 调用 Zendesk API」或「替代性邮件发送」模式
- Step 3 验证模式真实且一致
- Step 5 生成「Tool Access: 添加 Zendesk 内部备注 MCP 工具」提案
- 陈立审核后批准，Agent 获得正确工具

### 场景 3 — 独立开发者：从反复纠正到自动学习

**用户画像：**
王磊，35 岁，独立开发者。每次让 Agent 生成代码时都要纠正两件事：「注释用英文不要用中文」、「Python 脚本用 pathlib 不要用 os.path」。他平均每天纠正 3-4 次，已经变成肌肉记忆——他不再觉得这是「问题」，只是「必要的事前说明」。

**用户故事：**
作为开发者，我希望 Reflections 能发现我在反复纠正 Agent 的代码风格——这不是什么大问题，但加起来每天浪费 5-10 分钟。Reflections 应该自动提议将这些纠正写入 Agent 指令，让我不再需要重复说。

**验收标准：**
- Step 2 挖掘出「代码风格纠正」模式（涉及注释语言、文件路径库）
- Step 5 生成「Instruction Update: 编码规范」提案
- 王磊审核后点击 Apply，Agent 指令更新
- 后续对话中 Agent 默认使用英文注释 + pathlib
- 王磊的每日纠正次数下降 80%+

---

## 5. 竞争分析

| 竞品 | 功能/行为 | 优势 | 劣势 | 洞察/机会 |
|------|----------|------|------|----------|
| **ChatGPT Memory** | 跨对话记住用户偏好（被动存储） | 简单、自动、无需配置 | **被动存储**——只记住你说过的，不主动发现你没意识到的模式。无审查/回滚机制 | Reflections 是主动发现 + 人工审核，质量远高于被动记忆 |
| **Claude Custom Instructions + Projects** | 手动配置持久指令 + 静态知识库 | 完全可控、可审查、可版本化 | **完全手动**——用户必须自己发现并撰写所有规则。无自动学习 | Reflections 填补了「发现机会」的空白——Claude 知道指令但不知道什么时候该更新指令 |
| **LangGraph Reflexion Pattern** | 开发者框架中的反思循环（任务内自修正） | 高度可定制，开源灵活 | **需编码实现**，无产品化 UI。**单任务内**——不跨对话，不持久化学习 | 产品化是关键差异——Gumloop 的 Reflections 是开箱即用的，有完整的审核 UI 和 Cron 调度 |
| **AutoGPT 自反馈循环** | 任务内自我修正和重试 | 开源，理念先进 | **不稳定**——缺乏验证步骤，容易「学错」然后放大错误。无人工审核机制 | Reflections 的 Step 3（对话验证）是防止学错的核心壁垒——AutoGPT 没有这个 |
| **Gumloop Self-Improve Instructions** | 对话内用户纠正 → 实时更新 Prompt | 即时反馈，学习速度快 | **仅修用户明确纠正的问题**——用户没发现的永远不会改 | Reflections 是 Self-Improve 的互补——一个修已知，一个发现未知 |

### 关键洞察

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. 遥测

| 漏斗阶段 | 事件名称 | 触发条件 | 指标/KPI | 优先级 |
|---------|---------|---------|---------|--------|
| 采用 | `reflection_enabled` | 用户为 Agent 开启 Reflections | 开启率（开启 Agent 数/总 Agent 数） | P0 |
| 采用 | `reflection_apply_behavior_changed` | 用户切换 Apply Behavior | Review Queue vs Auto-Apply 分布 | P1 |
| 执行 | `reflection_run_started` | Cron 触发 Reflection 运行 | 运行次数/Agent/周 | P0 |
| 执行 | `reflection_run_skipped` | 因无新活动跳过 | 跳过率（跳过次数/计划运行次数） | P1 |
| 质量 | `reflection_pattern_mined` | Step 2 挖掘出候选模式 | 候选模式数/运行 | P0 |
| 质量 | `reflection_pattern_validated` | Step 3 验证通过 | 验证通过率（通过数/候选数） | P0 |
| 质量 | `reflection_proposal_created` | Step 5 生成提案 | 提案数/运行 | P0 |
| 质量 | `reflection_proposal_by_type` | 提案按类型分组 | New Skill / Skill Fix / Instruction / Tool Access 分布 | P1 |
| 采用 | `reflection_proposal_applied` | 用户审核后点击 Apply | 采纳率（已应用/总提案数） | P0 |
| 采用 | `reflection_proposal_dismissed` | 用户驳回提案 | 驳回率 | P1 |
| 影响 | `reflection_user_correction_rate` | 用户对 Agent 的纠正频率 | 纠正次数/对话（期望随 Reflections 下降） | P0 |
| 影响 | `reflection_auto_applied` | Auto-Apply 自动应用建议 | Auto-Apply 占比 | P1 |

---

## 7. 未来演进方向

| 阶段 | 时间线 | 里程碑 | 状态 |
|------|--------|--------|------|
| Phase 1 — 核心反思 | v9.7.0 | 五步流程 + 四种改进类型 + Review Queue + Cron 调度 + 权限模型 | ✅ 已发布 |
| Phase 2 — 增强交付 | v9.8.0+ | Email/Slack 报告投递、跳过通知、Extra Reflection Instructions | ✅ 已发布 |
| Phase 3 — 智能调度 | v10.x | 自适应 Cron（根据 Agent 活跃度自动调整频率）、提案优先级排序、长周期深度反思（月度/季度——捕获低频长期模式） | ⬜ 规划中 |
| Phase 4 — 跨 Agent 学习 | v11.x | 团队级模式发现（「5 个 Agent 都遇到了同一个 API 问题」）、最佳实践自动跨 Agent 分享、组织级 Reflections 仪表盘 | ⬜ 探索中 |
| Phase 5 — 预测式优化 | 远期 | 在问题发生前预测并提议修复（「你的 API 配额下周将达到上限，建议现在添加限流」）、外部环境变化感知（「Salesforce API v52 即将弃用，你的 3 个 Skills 需要更新」） | ⬜ 探索中 |

### 关键演进判断

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

---

*由 Claude 竞品情报系统生成 · 来源：[Gumloop Reflections 帮助文档](https://docs.gumloop.com/core-concepts/reflections.md) · 评分 13/13（战略3 护城河3 用户3 复杂度2 创新2）*