先给出几个关键判断。吴恩达教授近期多次强调一个观点：AI Agent 工作流将在今年推动人工智能实现重大突破，其影响力甚至可能超越下一代基础模型本身。这一论断分量十足。对从事AI相关工作的从业者而言，这意味着必须将关注重点从单纯的模型能力，转移到如何借助更精细的流程来“调度”这些模型。

具体而言，AI Agent工作流的核心不再是大模型一次性生成最终结果，而是通过反复交互、迭代与反思，让模型有机会逐步逼近更优质输出。这好比一名学生，直接从“读题”跳到“交卷”与经历“读题—初稿—修改—定稿”之间的差异。

在吴恩达提出的四种设计模式——反思（Reflection）、工具使用（Tool use）、规划（Planning）和多智能体协作（Multi-agent collaboration）中，我们今天重点剖析“反思”这一环节。它看似基础，却是整个Agent能否突破“一次性生成”局限的关键所在。

所谓反思（Reflection），本质上是一种提示策略。它通过引导大模型审视并批评自身的过往输出，甚至结合外部工具反馈，来提升最终结果的质量。这类似于我们常说的“系统1”与“系统2”思维——系统1依靠直觉快速反应，系统2则深思熟虑、有条理地推理。反思机制正是帮助模型从单纯的“系统1”模式，向更接近“系统2”的行为模式跨越。

当然，天下没有免费的午餐。反思机制牺牲了额外的计算资源（即更长的推理时间），换取了更高的输出质量。对于知识密集型、对响应质量要求极高的任务来说，这笔交易相当划算。但对于低延迟场景，比如实时客服对话，它可能并非最优解。

具体到“反思”的技术实现，业界已演化出几种较为成熟的架构，我们逐一来看。

Basic Reflection: 基础反射

最简单的情况由两个核心模型节点构成：一个生成器，一个反思器。生成器负责针对用户请求给出第一版回复；反思器被设定为“教师”角色，专门对初始回复提出建设性的批评意见。该过程按固定次数循环，最终从生成器输出优化后的结果。

在LangGraph中，这段逻辑可以这样定义：

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: List[BaseMessage]):
    if len(state) > 6:
        return END
    return "reflect"

builder.add_conditional_edges("generate", should_continue)
builder.add_edge("reflect", "generate")
graph = builder.compile()

这里的`MessageGraph`，状态就是一系列消息。每次调用生成器或反思器节点，都会在末尾追加一条新消息，最终结果从生成器节点返回。

这种方式的优势在于，它能通过多次迭代让模型自我改进。不过，由于反思步骤不依赖任何外部信息或程序，最终的改进效果可能会比较有限——这相当于学生自己改自己的卷子，缺乏外部参考答案。

Reflexion: 有据可查的反思

有人觉得基本反思不够用，于是出现了更进阶的架构——Reflexion。它的核心在于，让Actor Agent明确批评每个响应，并且这种批评必须建立在外部数据或工具反馈之上。它强制要求生成引用，明确列举输出中“多余”和“缺失”的部分，这让反思变得更有建设性，也能更精准地指引生成器往正确的方向调整。

Reflexion框架包含三个模块：

• Actor（行动者）：基于LLM，通过特定的Prompt生成所需的文本和动作，这些Prompt是基于状态观察条件来设计的。
• Evaluator（评估器）：负责评估Actor输出质量，通过计算奖励分数来反馈性能。不同的任务需要设计不同的价值函数和奖励机制。
• Self-reflection（自我反思）：这个模块是核心，它生成口头化的自我反思，为下一次尝试提供有价值的反馈。

Agent循环的逻辑在LangGraph中大致如下：

from langgraph.graph import END, MessageGraph

MAX_ITERATIONS = 5
builder = MessageGraph()
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")

def event_loop(state: List[BaseMessage]) -> str:
    num_iterations = _get_num_iterations(state)
    if num_iterations > MAX_ITERATIONS:
        return END
    return "execute_tools"

builder.add_conditional_edges("revise", event_loop)
builder.set_entry_point("draft")
graph = builder.compile()

这个架构能有效利用明确的反思和外部工具反馈来提升最终质量。但潜在问题是，它只沿着一条固定的轨迹执行——如果第一步就犯错了，这个错误可能会一直影响后续决策，缺乏纠偏机制。

LATS（Language Agent Tree Search）：树搜索式的反思

既然单一轨迹容易出问题，那么能不能像下棋一样，多考虑几步？LATS正是这一思路的产物。它结合了反思/评估和搜索（特别是蒙特卡罗树搜索），与ReAct、Reflexion甚至“思维树”（Tree of Thoughts）等技术相比，在复杂任务上表现更优。

搜索过程包含四个主要步骤：

1. 选择：根据总奖励，选出当前状态下的最优下一步行动。如果找到解决方案或达到最大搜索深度，则输出结果；否则继续搜索。
2. 扩展与模拟：生成多个（例如5个）潜在操作，并行执行。
3. 反思与评估：观察这些行动的结果，并根据反思（以及外部反馈）对决策进行评分。
4. 反向传播：根据执行结果，更新整条路径的得分。

简单来说，如果有高质量的环境奖励或可靠的反思分数，搜索过程就能准确区分不同路径的优劣，并选择最优路径。最终的轨迹还可以被保存下来，用于模型微调，让模型避免在未来重复同样的错误。

在LangGraph中，其实现利用了一些关键的数据结构：

from langgraph.graph import END, StateGraph

class Node:
    def __init__(
        self,
        messages: List[BaseMessage],
        reflection: Reflection,
        parent: Optional[Node] = None,
    ):
        self.messages = messages
        self.parent = parent
        self.children = []
        self.value = 0
        self.visits = 0

class TreeState(TypedDict):
    root: Node
    input: str

def should_loop(state: TreeState):
    root = state["root"]
    if root.is_solved:
        return END
    if root.height > 5:
        return END
    return "expand"

builder = StateGraph(TreeState)
builder.add_node("start", generate_initial_response)
builder.add_node("expand", expand)
builder.set_entry_point("start")
builder.add_conditional_edges("start", should_loop)
builder.add_conditional_edges("expand", should_loop)
graph = builder.compile()

LATS将推理、规划和反思统一在一个框架下，通过树搜索和反向传播来优化决策过程。它固然对奖励函数比较敏感，但其通用性决定了它可以灵活应用到多种任务中。这才是当前Agent架构里，真正可操作、有纵深感的那个方向。

总结

不论是基础反射、Reflexion还是LATS，它们本质上都是通过增加额外的推理计算，来换取更高的输出质量。在速度与质量之间做权衡——这在很多领域都不是新鲜事。关键在于，如果你手头的任务对答案的正确性、完整性要求极高，那这个时间投入就非常值得。更何况，如果将每次优化的轨迹保存下来作为训练数据，模型就能持续进化，从根源上减少重复犯错的可能。

参考资料：