9. 最佳实践

一句话理解：好的 Reflection 系统不是让 Agent 多跑几轮，而是让每一轮都“有的放矢”——标准清晰、Critic 聚焦、循环有界、结果可沉淀、策略可迭代。

1. Criteria-First：先定义标准，再写 Critic

在构建 Critic 之前，先把“好答案”的标准写下来。Criteria 应该：

可观测：能通过 draft 本身或外部工具判断，而不是“感觉更好”。
可分级：区分 must-have 和 nice-to-have，避免 Critic 对所有问题一视同仁。
可量化：每个标准最好对应一个可打分维度。

示例（代码生成）：

markdown

- [must] 代码可编译
- [must] 核心测试用例通过
- [should] 类型注解完整
- [nice] 注释清晰、命名规范

Critic 的 prompt 应直接引用这些 criteria，减少自由发挥。

2. 让 Critic 足够聚焦

一个什么都批判的 Critic 会让 Generator 无所适从。建议：

每轮只聚焦 1~3 个最关键问题：避免一次性抛出 10 条反馈。
按优先级排序：major 问题先修，minor 问题可以留到后续轮次。
给出具体位置：指出问题出现在 draft 的哪一段、哪一行、哪个函数。
提供修改建议：不仅说“错在哪里”，还说“可以怎么改”。
用“外部角色”承载被审对象：《The Self-Correction Illusion》（2026-06/07，arXiv:2606.05976）发现，让模型标记自己推理链中的错误极难，但把同一条主张改标为用户消息 / 工具返回 / 记忆块后，显式纠错率提升 23~93 个百分点。Critic 调用中把 draft 作为外部输入呈现，而不是让模型回头检讨自己的 <thought>，是零训练成本的可靠性提升。

示例：

text

问题 1 [major]: 第 3 行缺少错误处理，当 Redis 连接失败时会直接抛异常。
建议：使用 try/except 包装，并添加重试逻辑。

3. 严格限制循环边界

无限循环是 Reflection 最常见的生产事故之一。必须设置：

max_iterations：硬上限，建议 2~5 轮。
score_threshold：明确通过标准。
改进饱和检测：连续 N 轮 score 提升小于 delta 时终止。
重复反馈检测：本轮 critique 与上一轮高度相似时终止。
总体 timeout：覆盖整个 Reflection Loop。

python

terminate = (
    score >= threshold
    or iteration >= max_iter
    or improvement_saturated
    or critique_repeated
    or elapsed >= timeout
)

4. 保留历史最佳版本

Generator 可能会“越改越差”。Loop 应始终记录并保留历史最高分的 draft。

python

best_draft = max(all_drafts, key=lambda d: d["score"])

如果最终未通过，可以返回“最佳尝试 + 已知问题列表”，而不是半成品。

5. 人工兜底不可少

即使 Reflection 自动化程度很高，也要为以下场景预留人工入口：

连续多轮无法通过。
涉及安全、合规、伦理。
用户明确反馈不满意。
高风险领域（医疗、法律、金融）。

人工反馈要回流到系统，用于优化 criteria、Critic prompt 和 Evaluator 校准。

6. 把反思结果持久化

Reflection 的价值不仅在于当前回答更好，还在于长期经验积累：

每轮 draft、critique、score 写入 Workspace。
每个 episode 写入 Memory，包含任务类型、最终答案、关键教训。
定期聚类 critique 类型，发现系统性问题并优化训练数据或 prompt。

7. 策略版本管理

Critic 的 criteria、Evaluator 的 rubric、Generator 的 revise prompt 都是“策略”，应该版本化：

使用 Git 管理 prompt 和 rubric 的变更。
A/B 测试不同策略的效果。
记录每个 episode 使用的策略版本，便于回溯。

8. 外部验证优先

能用外部工具验证的维度，不要让 LLM 自己判断：

维度	外部工具
代码正确性	编译器、单元测试、类型检查器
事实准确性	检索、数据库、知识图谱
数值计算	Python / Wolfram / 计算器
安全合规	规则引擎、敏感词检测、审计系统
性能	基准测试、profiler

外部验证不仅更客观，还能减少 Critic 的 token 消耗。

9. 按任务配置反思策略

不同任务需要不同的 Reflection 策略：

任务类型	建议策略
简单问答	不开启 Reflection
文本润色	1~2 轮，Critic 关注风格与一致性
代码生成	3~5 轮，结合编译器/测试作为 Critic
复杂规划	3~5 轮，关注可行性、风险、资源约束
多 Agent 审稿	2~3 轮审稿，多 Critic 投票
高风险输出	强制人工批准

避免“一刀切”地给所有任务开启同样配置的 Reflection。

10. 监控与告警

Reflection 系统需要专门的监控指标：

指标	说明
`reflection.iterations`	每任务平均迭代次数
`reflection.pass_rate`	最终通过比例
`reflection.score_distribution`	score 分布
`reflection.latency_p99`	反思阶段 P99 延迟
`reflection.cost_per_task`	每任务 token 成本
`reflection.human_escalation_rate`	人工升级比例

当 pass_rate 下降或 human_escalation_rate 上升时，应及时检查 Critic 和 Evaluator。

11. 避免“为了反思而反思”

Reflection 是手段，不是目的。在引入 Reflection 前，先问自己：

单轮 LLM 的错误是否真的能被 Reflection 修复？
增加的延迟和成本是否值得？
是否有明确的评估标准？
是否有高质量 Critic 或验证工具？

如果答案多为否，可能更好的做法是优化 base prompt、增加 few-shot 示例，或引入 Retrieval。

12. 给反思设预算，允许提前终止

反思是稀缺资源，不是免费循环：

critique budget 控制在 1~3 轮：生产 runbook 的通行上限，超出即降级或升级人工。
token 硬顶独立于 max_iter：reasoning models 的内隐反思会消耗大量 token，必须有每任务预算。
允许跳过确认性反思：模型高置信且无外部验证信号时，不必每轮都跑 Critic（2025-10 研究显示提前截断确认性反思可省约 24.5% token、精度损失不足 2.9%）。
给 Critic 一个“停”的出口：EvoResearcher（2026-08，arXiv:2608.18884）用 "CONFIRMED" 哨兵做训练无关的提前终止，82~88% 的样本在等精度情况下提前结束（平均每题约 2.1 次生成）；与其跑满固定轮数，不如让 Critic 有权宣布收敛。
按领域配置：数学、代码多给预算；翻译、润色等收益不稳定的领域少给。

13. 反思写记忆要做“卫生管理”

Reflection 沉淀经验的同时也在制造风险：错误反思会被反复检索放大。纪律包括：

写入门槛：带外部验证信号（测试通过、人工确认）的经验才进长期 Memory。
质量分 + 版本 + 衰减：每条经验可演化（参考 A-Mem/ACE），保留版本历史，支持回滚与淘汰。
污染审计：定期抽样检查 Memory 命中效果，清理“坏经验”。

本章小结

Agent Reflection 的最佳实践可以总结为：criteria-first、Critic 聚焦、循环有界、保留最佳版本、人工兜底、结果持久化、策略版本化、外部验证优先、按任务配置、持续监控。2025-2026 年新增两条：给反思设预算（轮数、token、按领域分配、允许提前终止、给 Critic 哨兵式收敛出口），以及反思记忆的卫生管理（写入门槛、版本演化、污染审计）；同时 2026 年的机制研究表明，用“外部角色”承载被审对象本身就是免费校准。遵循这些原则，可以避免 Reflection 变成“多轮生成却不见效”的形式主义，真正发挥自我纠错的价值。

参考来源

9. 最佳实践 ​

1. Criteria-First：先定义标准，再写 Critic ​

2. 让 Critic 足够聚焦 ​

3. 严格限制循环边界 ​

4. 保留历史最佳版本 ​

5. 人工兜底不可少 ​

6. 把反思结果持久化 ​

7. 策略版本管理 ​

8. 外部验证优先 ​

9. 按任务配置反思策略 ​

10. 监控与告警 ​

11. 避免“为了反思而反思” ​

12. 给反思设预算，允许提前终止 ​

13. 反思写记忆要做“卫生管理” ​

本章小结 ​