结论先说：给 Agent 加一层「自我反思」，是用额外推理时间换输出质量的经典交易。它不适合低延迟场景，但对知识密集型任务是性价比最高的一种架构改动——不需要换模型，只需要改循环。反思的本质是让模型审视并批评自己刚才的动作，必要时结合工具返回的外部信息再修正一遍。
为什么反思有用
有个常被提到的类比：系统 1 是直觉式、应激式的思考，系统 2 是有条理、会自省的思考。单次调用的 LLM 天然更像系统 1——顺着最可能的路径一路写下去，中途错了也不会回头。反思的作用，就是强行插入一次「慢下来检查」的机会，把行为往系统 2 拉一点。
但要注意它的代价：反思会消耗时间。所有反思方案都是在拿额外计算换更好的输出，这一点在低延迟应用里是硬伤。
三种反思架构，从简到繁
1. 基础反思（Basic Reflection）
最简单的形态：两个 LLM 节点，一个生成、一个反思。生成器直接响应用户请求，反思器被要求扮演「老师」角色，对初稿提出建设性批评，然后回到生成器重写，循环固定次数后返回最终结果。
from langgraph.graph import MessageGraph
builder = MessageGraph()
builder.add_node("generate", generation_node)
builder.add_node("reflect", reflection_node)
builder.set_entry_point("generate")
def should_continue(state):
if len(state) > 6:
return END
return "reflect"
builder.add_conditional_edges("generate", should_continue)
builder.add_edge("reflect", "generate")
graph = builder.compile()这种写法有时能提效，因为模型获得了多次打磨的机会，且反思节点用了不同人格。但它的明显短板是：反思没有任何外部依据，只是模型自己评自己，最终结果未必比初稿好多少。
2. Reflexion：把批评锚定到外部数据
Reflexion 的关键改进是——批评必须 grounded 。它要求 actor 明确引用外部数据，并显式列举回答里「多余的」和「缺失的」部分。有了引用和可核查依据，反思内容才有建设性，也才能真正引导生成器改进。
典型结构是三段循环：起草（draft）→ 执行工具（execute_tools）→ 修订（revise），修订后再回到执行工具，直到达到最大迭代次数。
MAX_ITERATIONS = 5
builder.add_node("draft", first_responder.respond)
builder.add_node("execute_tools", execute_tools)
builder.add_node("revise", revisor.respond)
builder.add_edge("draft", "execute_tools")
builder.add_edge("execute_tools", "revise")
builder.add_conditional_edges("revise", event_loop)反思的内容还会以「情景记忆缓冲」的形式留在历史里，让 Agent 能从过去几轮的错误中学习——比如一次搜索失败或代码任务失败后，它能识别根因并从错误中恢复。
3. LATS：反思 + 搜索
Language Agent Tree Search 把反思/评估和蒙特卡洛树搜索结合起来，用标准强化学习框架，把 RL 的智能体、价值函数、优化器全部换成 LLM 调用。四个步骤：选择 → 扩展与模拟 → 反思并评估 → 反向传播更新分数。
它的优势是不再只追一条固定轨迹（Reflexion 的短板就是单轨迹，一步错会影响后续所有决策），代价是计算量显著上升。
三种方案怎么选
| 方案 | 额外成本 | 外部依据 | 适合场景 |
|---|---|---|---|
| 基础反思 | 低（2 节点循环） | 无 | 文案打磨、格式规范、风格一致性 |
| Reflexion | 中（带工具调用） | 有，强制引用 | 需要事实核查的知识型任务 |
| LATS | 高（树搜索） | 有 + 环境反馈 | 复杂决策、代码生成等多解空间任务 |
- 先确定评判标准：想清楚「什么叫改好了」。没有明确标准，反思就只是多花一次调用。
- 拆出独立的反思节点：用不同的系统提示词和角色，避免它只是复述生成器的思路。
- 给它可用的外部信号：检索结果、测试输出、编译日志。有据可依的反思和无据反思，质量差距很大。
- 设死循环上限：固定迭代次数（如 3–5 次），并记录每次的评分曲线。若第 2 轮后不再提升，就该收敛。
- 把失败轨迹存下来：反思产生的轨迹是最好的改进素材，可以转成评测集，也可以用于后续微调。
反思必须配合可观测性
反思不是银弹，它只是把「一次瞎猜」变成「多次有依据的尝试」。判断它到底有没有用，靠的是 trace 。完整的改进循环是：收集 trace → 用评测和人工反馈丰富它 → 找出失败模式 → 做针对性修改 → 验证后再上线。
一句很到位的话是：传统软件里代码描述应用，AI 系统里 trace 描述应用。代码只告诉你 Agent 允许做什么，trace 才告诉你在某次输入下它实际做了什么。落地做法可参考 智能体可观测性与链路追踪。
评测量化之后，反思的效果才能被客观比较，具体方法可以配合 Agent 提示词版本管理与测试 一起做。
一条好用的反思提示词结构
- 角色：你是严格的评审者，目标是挑出问题，不是鼓励。
- 检查项：事实是否有外部依据、是否遗漏用户要求、是否存在多余内容。
- 输出格式：先列出「缺失项」和「多余项」，再给出 3 条以内的具体修改建议。
- 硬约束：只针对可核查的问题批评，禁止主观评价措辞好坏。
第 4 条最关键。让反思模型评价「写得好不好」，它会开始客套；只让它找可核查的事实缺口，批评才有价值。
和 ReAct 、规划模式的关系
反思不是替代 ReAct 或规划，而是叠在它们之上的一层。 ReAct 解决「边想边做」，规划解决「先拆解再执行」，反思解决「做完之后回头看」。三者可以组合：用 ReAct 执行单步，用规划组织多步，用反思在关键节点回看。相关做法见 ReAct 模式实战 和 Agent 规划模式。
先搭好 trace 再谈反思反思会让 Agent 变慢多少？
为什么我加了反思，效果没什么变化？
循环几次合适？
反思产生的轨迹有什么用？
小结
自我反思是少数几种「不动模型、只改架构」就能提质量的手段。从基础双节点循环起步，给它外部依据，配上 trace 和评测，再决定要不要升级到 Reflexion 或 LATS 。别一上来就上树搜索。
资料来源：LangChain Blog：Reflection Agents、LangChain：Self-Reflective RAG with LangGraph、LangChain：The agent improvement loop starts with a trace。
评论 (0)