Reflexion / Self-Refine：Agent Feedback Loops
Reflexion 和 Self-Refine 的重点不是“模型会自我反思所以更聪明”，而是把失败、反馈、修订、重试和记忆组织成受控的推理时改进机制。它们说明 agent 可以在不更新模型权重的情况下，通过 verbal feedback、critic、memory 和 refinement policy 改善下一次尝试。
Reflexion / Self-Refine / Agent Feedback Loops 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Reflexion: Language Agents with Verbal Reinforcement Learning | https://arxiv.org/abs/2303.11366 | 理解 verbal feedback、episodic memory、trial-level improvement |
| Self-Refine: Iterative Refinement with Self-Feedback | https://arxiv.org/abs/2303.17651 | 理解 generate -> feedback -> refine 的迭代结构 |
| ReAct | https://arxiv.org/abs/2210.03629 | 连接 reasoning、action、observation loop |
| Tree of Thoughts | https://arxiv.org/abs/2305.10601 | 对比 search-based planning 和 iterative refinement |
核心导读
Reflexion 和 Self-Refine 的重点不是“模型会自我反思所以更聪明”，而是把失败、反馈、修订、重试和记忆组织成受控的推理时改进机制。它们说明 agent 可以在不更新模型权重的情况下，通过 verbal feedback、critic、memory 和 refinement policy 改善下一次尝试。
反馈循环的价值来自外部信号、失败分类和修复边界，而不是模型自评本身。生产架构必须定义证据边界、停止条件、人工复核、记忆治理和成本控制，否则自我修正可能变成自我强化错误。
1. 核心问题：Agent 失败后如何改进
Agent 常见失败不是“完全不会”，而是在相似场景中反复犯同类错误：第一次检索没找到关键证据，工具参数填错，输出格式不合规，漏掉政策例外，过早得出结论，或者没有利用用户和系统反馈。
Reflexion 和 Self-Refine 关注的是推理时改进：模型权重不变，但系统把失败转成文字反馈、修订指令或下一次尝试的记忆。
生产系统需要的不是“让模型再想想”，而是：
Failure observed
-> feedback generated
-> feedback classified
-> repair boundary decided
-> output refined or task retried
-> trace recorded
-> memory updated only when safe
金融零售任务中，修正本身也可能造成风险。模型把错误改得更流畅、把不确定事实写得更确定、把安全拒答改成迎合用户，都比原始错误更难发现。
2. 技术贡献：推理时反馈循环
2.1 Reflexion
Reflexion 让 agent 在一次任务尝试后，根据成功或失败反馈生成 verbal reflection，并将其放入 episodic memory，影响下一次尝试。
Task
-> attempt
-> feedback / score
-> reflection
-> episodic memory
-> next attempt
它类似任务复盘：我刚才哪里错了，下次应该先查什么，哪个策略不该用。重要的是，模型并没有被重新训练，改变的是下一次推理时可见的上下文。
2.2 Self-Refine
Self-Refine 的结构是：
Initial output
-> self-feedback
-> refined output
-> optional repeat
它适合草稿改写、摘要补全、结构化字段修复、代码修正、引用补齐和低风险质量提升。但它不天然适合高风险自动决策，因为自我反馈不等于外部事实校验。
2.3 与 ReAct / Tree of Thoughts 的关系
ReAct 强调 reasoning、action、observation 的交替；Tree of Thoughts 强调生成多条路径并搜索；Reflexion 和 Self-Refine 更关注失败后的反馈、修订和经验保留。
它们可以组合，但必须明确每种机制负责什么：工具观察提供外部事实，多路径搜索探索方案，反馈循环修复错误，记忆只能保存经过治理的经验。
3. 机制原理：反馈循环的组成
一个生产级 feedback loop 至少包含五个部分：
Output or action trace
-> critic
-> feedback object
-> refinement policy
-> repair / retry / escalation
-> trace and memory governance
Critic 可以是规则检查、schema validator、citation verifier、retrieval grounding checker、LLM judge、工具错误、人工 reviewer 或用户反馈。字段缺失用 schema 检查，引用真实性用 verifier，语义质量可以用 LLM judge 和人工抽检，高风险合规问题不能只靠模型自评。
Feedback 应结构化，而不是一段随意自然语言：
| 字段 | 示例 |
|---|---|
| failure_type | missing_evidence, unsupported_claim, policy_violation, format_error |
| severity | low, medium, high, critical |
| evidence | source ids, tool errors, reviewer notes |
| recommended_fix | retrieve_more, remove_claim, add_citation, escalate |
| allowed_auto_refine | true / false |
| memory_update_allowed | true / false |
Refinement policy 决定下一步。格式错误可以自动修；缺少低风险字段可以基于证据补齐；引用不支持结论时要删除结论、重新检索或人工复核；触及受监管建议、权限错误或关键政策冲突时必须停止或升级。
Stop rules 也必须明确：最大修订轮数、无新证据、同一错误重复、critical policy violation、成本或延迟超限、输出冲突增加、需要人工审批。
4. 为什么反馈循环有效
第一，它把失败原因显性化。单次坏输出只说明“结果不好”，结构化反馈能说明是检索漏了、引用错了、格式坏了、政策冲突还是输出越界。
第二，它用推理时计算换质量。对于高价值任务，多一轮检查和修订可能比直接把低质量草稿交给人工更划算。
第三，它分离生成和审查。生成器负责产出草稿，规则检查器负责硬约束，检索验证器负责证据，LLM judge 负责语义质量，人工 reviewer 负责高风险判断。
第四，它能把错误转成改进资产。常见 feedback 可以进入 eval backlog、prompt 改进、workflow checklist、数据质量修复、工具接口改进和培训材料。
5. 局限和误用
| 风险 | 说明 | 控制 |
|---|---|---|
| Same-model bias | 模型评审自己，共享盲点 | 引入规则、工具、不同 judge 和人工抽检 |
| No new evidence | 没有外部证据，只是重写 | 要求 retrieve_more 或 stop |
| Error amplification | 错误被改得更像真的 | citation verifier 和 factual checks |
| Infinite loop | 不断修订不收敛 | max rounds、budget、stop rules |
| Safety erosion | 为满足用户弱化拒答边界 | 安全约束不可被 refinement 改写 |
| Memory contamination | 错误 reflection 进入长期记忆 | memory approval 和 retention controls |
| Privacy leakage | 敏感客户信息写入全局 memory | PII filter、aggregation、purpose limitation |
自我反馈尤其不能替代事实校验。模型可以说“缺少引用”，但没有新证据时，它无法凭空知道正确事实。金融任务中的事实修订必须绑定来源文档、交易记录、政策版本、工具结果或人工 note。
6. 记忆治理：什么可以被保存
Reflexion 最容易被误用在 memory 上。不是所有 reflection 都应该进入长期记忆。
| Memory 类型 | 示例 | 治理 |
|---|---|---|
| Session reflection | 本轮对话内避免重复错误 | 会话结束清除 |
| Workflow reflection | 某类任务常漏检查 SLA | SME 审核后进入 checklist |
| User preference | 用户偏好短答案 | 同意、可查看、可删除 |
| System learning | 生产错误模式统计 | 去标识化、聚合保存 |
| Unsafe reflection | “下次绕过限制” | 阻断并记录安全事件 |
一个 case 中形成的经验可能只适用于该 case。把它直接写入全局 memory，可能造成偏置。例如 AML 系统不能因为一批 false positive 就学到“类似 alert 通常可以关闭”。正确做法是把 pattern 交给 SME 审核，转成可测试规则或 eval case。
7. 架构和产品价值：受控 Feedback Loop
反馈循环的价值是提升任务质量、降低人工返工、形成持续改进，而不是让 agent 自由重试。
Task execution
-> output / action trace
-> critic layer
-> schema checks
-> policy checks
-> citation checks
-> LLM judge
-> human review sample
-> feedback object
-> refinement policy
-> repair
-> retrieve more
-> ask user
-> escalate
-> stop
-> final output
-> trace / metrics / eval backlog
-> controlled memory update
可运营指标包括 refinement success rate、regression introduction rate、evidence preservation rate、safety preservation rate、average refinement rounds、cost per accepted output 和 human acceptance rate。
这些指标必须一起看。只看修订成功率会忽视成本，只看人工接受率会忽视安全，只看成本会压低必要复核。
8. 金融零售系统案例
8.1 Payment Dispute Assistant
支付争议助手可以自动修复缺交易时间、金额、商户、工单 schema 不合规、补证请求不清晰等问题。但承诺退款、把网络规则解释成最终裁决、忽略商户证据冲突、漏掉 SLA 风险，都必须阻断或升级。
适合的 feedback taxonomy 包括 missing_transaction_fact、unsupported_rule_claim、refund_promise、evidence_gap_ignored 和 deadline_risk。每类错误对应不同修复策略，而不是统一“再生成一次”。
8.2 KYC Document Checker
KYC 检查器可以在本轮对话中记住“刚才漏看地址证明”，也可以把去标识化失败模式交给 SME 审核后加入 checklist。但个人客户材料不能进入全局 memory，系统也不能因为历史类似案例而跳过当前证据检查。
8.3 AML Alert Triage
AML 场景中，反馈循环适合修复漏掉 prior alert、未区分事实和推断、narrative 缺少交易证据、typology 判断不完整等问题。必须停止或升级的情况包括自动决定 SAR、证据不足却建议关闭 alert、忽略高风险地区和生成无法溯源的事实陈述。
8.4 Contact Center Agent Assist
客服辅助可以通过 Self-Refine 改善语气、清晰度、引用格式和必要披露。但 refinement 不能绕过 approved language、投资建议边界、费用豁免权限和投诉升级规则。
9. Trace 和审计
每次 refinement 都应记录原始输入、检索来源、原输出、critic 类型、feedback object、修订动作、修订后输出、模型和 prompt 版本、是否触发人工、成本、耗时和最终接受状态。
这些 trace 支持三件事：事故复盘时定位错误来源，eval 改进时把 feedback 转成 regression cases，治理审查时证明系统不是无限自我循环，而是在明确边界内修复。
10. 可交付资产
| 资产 | 内容 |
|---|---|
| Feedback Taxonomy | 业务失败类型、严重程度、证据和修复动作 |
| Refinement Policy | 哪些错误可自动修、哪些要检索、哪些必须人工 |
| Reflection Memory ADR | 什么 reflection 可保存、保存多久、谁批准 |
| Stop Rule Spec | 最大轮数、critical failure、成本和无新证据停止条件 |
| Eval Report | refinement 前后质量、安全、成本和人工接受率 |
11. 学习验证
读完后应能回答：
- Reflexion 和 Self-Refine 的差异是什么？
- 为什么 self-feedback 不等于事实校验？
- Verbal reflection 为什么能在不更新权重的情况下影响下一次尝试？
- Critic、feedback object、refinement policy 和 stop rule 各负责什么？
- 什么 reflection 可以进入长期 memory，什么必须阻断？
- 如何为 AML alert triage 设计 feedback taxonomy？
- 如果修订后答案更流畅但引用仍错误，应如何计分？
真正掌握这组方法的标志，是能把“反思”设计成可审计的反馈控制系统，而不是把它当作模型自我提升的魔法。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。