字数 4700，阅读大约需 19 分钟

静态智能体只是一个花哨的 API 包装器，这里有五个让智能体真正随经验改进的学习模式，以及我们可以运行的代码。

初级开发者和高级开发者都可以访问相同的文档。区别不在于知识，而在于经验。

高级开发者见过同一类问题数十次，记得什么有效什么无效，识别初级开发者还看不到的模式。

知识和经验之间的差距正是 AI 智能体现在所处的位置。

当今生产环境中的大多数智能体都是无状态的。它们接收一个 prompt，调用模型，返回响应，然后忘记一切。

每次对话都从零开始。每个错误都会重复。每个成功的策略都会丢失。

那些在实际生产中运行良好的智能体，那些团队正在扩展的智能体，做的事情不同。它们记得。它们反思。它们构建技能库。它们从反馈中学习，随时间可衡量地变得更好。

这不是科幻小说。这是五个有详细文档记录的设计模式，在 LangGraph 1.0（10 月发布）、LangMem SDK 以及 Voyager 和 Elastic 的多智能体系统等框架中有生产级实现。

基础研究可以追溯到 Reflexion（Shinn 等人）和 ReAct（Yao 等人），但大规模部署这些模式的工具直到去年才成熟。让我们逐一了解。

模式 1：反思（智能体审查自己的工作）

人类不会提交第一稿。我们写作、重读、发现漏洞并修改。

反思模式赋予智能体相同的循环： 生成、批评、改进。

Andrew Ng 将反思确定为四个基础智能体设计模式之一，并指出它能带来惊人的性能提升，而实现起来相对较快。

研究支持这一点。

一项跨越九个 LLM 的研究发现，自我反思的智能体显著提高了问题解决性能（p < 0.001），在分析推理任务上的收益最大。Shinn 等人的 Reflexion 框架在 HumanEval 编码基准上达到了 91%，相比 GPT-4 的基线有所提升，方法是存储自然语言批评并重试。

这是核心循环：

from openai import OpenAIclient = OpenAI()def reflection_loop(task: str, max_cycles: int = 3) -> str:    """Generate-critique-refine loop. The agent reviews    its own output and iteratively improves it."""    # Step 1: generate initial output    output = client.chat.completions.create(        model="gpt-5-mini",        messages=[{"role": "user", "content": task}],    ).choices[0].message.content    for cycle in range(max_cycles):        # Step 2: critique the output        critique = client.chat.completions.create(            model="gpt-5-mini",            messages=[\                {"role": "system", "content": (\                    "You are a strict reviewer. Find specific "\                    "errors, gaps, or improvements. If the "\                    "output is good, respond with ONLY: <OK>"\                )},\                {"role": "user", "content": (\                    f"Task: {task}\n\nOutput: {output}\n\n"\                    "Provide specific, actionable critique."\                )},\            ],        ).choices[0].message.content        if "<OK>" in critique:            break  # nothing left to improve        # Step 3: refine based on critique        output = client.chat.completions.create(            model="gpt-5-mini",            messages=[\                {"role": "user", "content": (\                    f"Original task: {task}\n\n"\                    f"Your previous output: {output}\n\n"\                    f"Critique: {critique}\n\n"\                    "Rewrite, addressing every point."\                )},\            ],        ).choices[0].message.content    return output

这不是玩具。

LangChain 的官方博客展示了使用 LangGraph 的反思智能体，该模式是 AutoGPT 和许多生产代码审查智能体的支柱。

权衡是延迟和成本，每次改进循环都意味着另一次 LLM 调用。实际上，2-3 个循环达到收益递减。

📎 Andrew Ng: 智能体设计模式 — 反思· Reflexion 论文（Shinn 等人）· LLM 智能体中的自我反思（Renze 等人）· LangChain 反思智能体

模式 2：记忆（智能体跨会话记住）

忘记每次之前对话的人类助手将毫无用处。智能体也是如此。记忆是将无状态函数转变为可学习内容的关键。

LangChain 的 Harrison Chase 和 DeepLearning.AI 将智能体记忆正式确定为三种类型，直接受认知科学启发。

语义记忆 存储事实。

“这个用户更喜欢 Python 而不是 TypeScript。”“公司财年在 3 月结束。”

这些从对话中提取并持久化在存储中，以便智能体可以在未来的会话中回忆它们。

情景记忆 存储经验。

“上次这个用户要求重新安排会议时，他们想移到下午而不是上午。”

这些是从真实交互中提取的 few-shot 示例，教智能体如何处理类似情况。

程序记忆 存储技能和指令。

“在分类邮件时，首先检查主题行中的紧急关键词。”

这是智能体的系统 prompt，关键的是，它可以根据反馈更新，智能体随时间实际上重写自己的指令。

LangGraph 用其 Store API 实现所有三种：

from langgraph.store.memory import InMemoryStorestore = InMemoryStore()# Semantic memory: store a user factstore.put(    ("user_preferences", "user_123"),    "language",    {"value": "prefers concise answers, no jargon"})# Episodic memory: store a successful interactionstore.put(    ("episodes", "user_123"),    "meeting_reschedule_001",    {        "situation": "user asked to move standup",        "action": "moved to 2pm, added buffer",        "outcome": "user confirmed, positive feedback",    })# Retrieval: pull memories into the agent's contextuser_prefs = store.search(("user_preferences", "user_123"))past_episodes = store.search(("episodes", "user_123"))

MongoDB 推出了生产就绪的 LangGraph store 集成，添加了跨线程持久化、语义搜索记忆和水平扩展。

这是让智能体记忆超越演示的基础设施。

LangChain 发布的 LangMem SDK 进一步推进了这一点，它自动从对话中提取记忆，基于反馈更新智能体的 prompt，并管理事实、情景和程序的生命周期。

📎 LangGraph 长期记忆文档· LangMem SDK 发布· MongoDB + LangGraph Store· DeepLearning.AI: 长期智能体记忆

模式 3：技能库（智能体构建工具箱）

这是智能体学习真正接近人类发展专业知识的方式。

NVIDIA 的 Voyager 是最清晰的演示。它是 Minecraft 中由 LLM 驱动的智能体，持续探索、发现新技能，并将它们存储为可重用代码，形成不断增长的库。

当它遇到新挑战时，它在技能库中搜索相关的过去解决方案，将它们组合成更复杂的行为，并在成功时添加新技能。

结果是惊人的。

Voyager 获得了 3.3 倍更多的独特物品，旅行了 2.3 倍更远的距离，并以高达 15.3 倍的速度解锁关键里程碑，超越了之前的方法。

更重要的是，它将其学到的技能库转移到全新的 Minecraft 世界中，从头开始解决新任务，这是之前任何智能体都无法做到的。

该架构有三个任何生产智能体都可以采用的组件：

┌──────────────────────────────────────────┐│         AUTOMATIC CURRICULUM             ││  "What should I learn next, given what   ││   I already know and what I see?"        │└────────────────┬─────────────────────────┘                 │                 ▼┌──────────────────────────────────────────┐│         ITERATIVE PROMPTING              ││  Generate code → Execute → Get feedback  ││  → Fix errors → Self-verify → Retry      │└────────────────┬─────────────────────────┘                 │  on success                 ▼┌──────────────────────────────────────────┐│           SKILL LIBRARY                  ││  Store skill as code + description       ││  Index by embedding for retrieval        ││  Compose simple skills into complex ones │└──────────────────────────────────────────┘

NeurIPS 上提出的自我优化器（STO）进一步推进了这一点。它从一个基本的代码改进程序开始，用它来改进其他代码，然后将改进器应用到它自己的代码上，递归地重写自己。

它在没有人类指导的情况下独立发现了束搜索和模拟退火等经典算法。

这个模式不限于游戏。

相同的架构适用于任何构建可重用工作流的智能体： 存储成功解决方案脚本的客户支持智能体、保留有效 SQL 查询的数据分析智能体，或积累测试过的部署脚本的 DevOps 智能体。

📎 Voyager GitHub (NVIDIA/MineDojo)· Voyager 论文· Yohei Nakajima: 自我改进智能体

模式 4：反馈循环（环境教导智能体）

反思是智能体与自己对话。反馈循环是世界与智能体对话。

区别很重要。

当智能体生成 SQL 查询时，反思会让它重读查询并寻找明显错误。反馈循环会针对数据库执行查询，观察结果（或错误），并使用那个具体信号来改进。

这是使智能体学习扎根于现实而不是自我强化的幻觉的模式。

ReAct 框架（Reason + Act）将其正式化为一个循环： 智能体思考、行动、观察，并在再次行动之前对观察进行推理。

在交互式基准测试中，ReAct 相比仅使用行动或仅使用思维链推理的智能体将成功率提高了 34%。

# Simplified feedback loop for a SQL agentdef sql_agent_with_feedback(question: str, db, max_retries=3):    """Agent generates SQL, executes it, learns from    errors, and retries with concrete feedback."""  messages = [\        {"role": "system", "content": (\            "You are a SQL expert. Generate a query to "\            "answer the user's question. If you receive "\            "an error, fix the query based on the error."\        )},\        {"role": "user", "content": question},\    ]    for attempt in range(max_retries):        # Generate SQL        response = client.chat.completions.create(            model="gpt-4.1-mini", messages=messages        ).choices[0].message.content        sql = extract_sql(response)        try:            result = db.execute(sql)            return result  # success        except Exception as e:            # Feed the real error back to the agent            messages.append(                {"role": "assistant", "content": response}            )            messages.append(                {"role": "user", "content": (                    f"That query failed with: {e}\n"                    "Fix it and try again."                )}            )    return "Could not generate a valid query."

在生产中，反馈循环无处不在。

Salesforce 的 Agentforce 3.0 使用自我修复工作流，检测损坏的 CRM 触发器，诊断失败，并在没有人工干预的情况下修复它们。

Elastic 的多智能体系统使用 LangGraph 实现反思模式，以 Elasticsearch 作为长期记忆，智能体分析 IT 事件，生成根本原因分析，并自我纠正直到达到质量阈值，通过引用过去的解决方案将反复发生的事件在 1 次迭代中解决，而不是 3 次。

人在环反馈同样强大。LangGraph 的运行时可以暂停执行、保存状态并等待人工批准，然后在暂停处精确恢复。

人类的纠正成为智能体程序记忆的训练信号。

📎 ReAct 论文（Yao 等人）· Elastic: 使用 LangGraph 的多智能体反思· LangGraph 1.0（人在环）

模式 5：多智能体协作（智能体相互教导）

人类不会孤立学习。我们从导师、同伴和团队反馈中学习。相同的原则适用于智能体。

在多智能体系统中，每个智能体专门从事一个狭窄领域并与他人分享其知识。研究智能体查找信息，批评智能体评估质量，写作智能体综合输出。

每个智能体的反馈成为其他智能体的学习信号。

LangGraph 的反思智能体具体展示了这一点。

创建了两个智能体： 一个被提示生成高质量输出，另一个被提示提供建设性批评。两人之间的讨论产生了比任何单一智能体都更好的结果。

语言智能体树搜索（LATS）通过将反思与蒙特卡洛树搜索相结合进一步推进，让智能体探索多个解决方案路径并从结果的反向传播中学习。

企业部署正在扩展这个模式。

采用领先的行业具有启发性。

金融服务智能体从交易模式中学习，不断收紧欺诈检测。

制造智能体预测设备故障，从维护结果中学习，并改进其预测，企业报告预测性维护智能体节省了 20% 的成本。

客户支持智能体学习哪些解决路径对哪些客户群有效，Salesforce 报告 85% 的一级支持查询实现自动化。

📎 LangChain: 智能体工程状态调查

这些模式如何组合

没有生产智能体只使用这些模式之一。它们是分层的。

客户支持智能体可能使用记忆来回想用户历史，使用反思来验证其起草的响应是否准确，使用反馈循环对照知识库文章检查响应，并使用技能库检索来拉取对类似工单有效的解决方案脚本。

LangGraph 生态系统已成为组合这些模式的标准编排层。

LangGraph 1.0 于 10 月发布，具有四个使这成为现实的生产功能： 持久执行（经受崩溃的智能体）、流式传输（用户看到进度）、人在环（智能体暂停等待批准）和持久记忆（短期和长期）。

学习基础设施存在；现在的挑战是构建让智能体真正改进的反馈循环。

从哪里开始

如果我们的智能体现在是无状态的： 首先添加记忆。

LangGraph 的 Store API 与数据库支持的检查点一起提供跨会话持久化，只需几行代码。这是最高影响、最低努力的改进。

如果我们的智能体犯重复错误： 添加反馈循环。

通过验证器（测试套件、数据库执行、规则引擎）路由智能体的输出，并将具体错误反馈。

这将学习扎根于现实。

如果我们的智能体产生不一致的质量： 添加反思。

一个批评-改进循环可衡量地改进输出，无需架构更改。

如果我们的智能体重复解决类似问题： 添加技能库。

将成功的策略存储为可检索的 artifact。Voyager 模式，将代码作为可重用技能，通过嵌入索引，组合成复杂行为，直接转移到企业智能体。

如果我们的工作流涉及多个专门步骤： 添加多智能体协作。

分担责任，让专门的智能体相互批评，并存储学到的教训。

将在生产中占主导地位的智能体不是拥有最好基础模型的智能体。它们是拥有最好学习循环的智能体。

结语

我们使用人类学习类比是有原因的。它不是隐喻；它是实际的设计原则。

语义、情景和程序记忆来自认知科学。

反思反映元认知。

技能库反映专家如何构建可重用的心智模型。

反馈循环反映我们如何从后果中学习。

协作反映团队如何复合个人知识。

研究经过同行评审。框架是开源的。行业正在大规模采用，57% 的组织在生产中有智能体，看到最多价值的正是那些投资于学习基础设施的组织。

演示智能体和生产智能体之间的差距不是计算或模型质量。是智能体是否每次运行都变得更好。