Agent 总在重复犯错？LangChain Deep Agents 这套 RLMs 思路，比加 prompt 更治本

Prompt 工程内容创作者 2026-07-16 21 阅读

Agent 总在重复犯错？LangChain Deep Agents 这套 RLMs 思路，比加 prompt 更治本

导语

你有没有遇到过这种情况：同一个 Agent，第一次跑任务时在某个 API 调用上栽了跟头，第二次、第三次还是照样踩进去？你给它加了更严格的 prompt、补了更多示例，但下次换个人让它做类似的事，它又犯同样的错。这不是 prompt 不够好，而是当前大多数 Agent 架构缺了一个关键能力：从交互反馈里学习，而不只是从文本提示里学。

正文

1. 问题：现在的 Agent 为什么“不长记性”

过去两年，大家做 Agent 主要靠两条路：一条是堆工具，一条是堆 prompt。结果就是，Agent 能做的事越来越多，但“同样的坑踩两次”的问题始终没根治。

根子在哪？在架构层面。大多数 Agent 的决策链路是：用户输入 → prompt → 模型推理 → 工具调用 → 输出。这个链路里，模型只看到了当前的文本上下文，上一轮执行的结果再好，也没有变成下一轮的“先验经验”。

Deep Agents 已经往前走了一步：它内置了文件系统、TODO 规划和子 Agent 委派，把中间结果落盘、把长任务拆成独立上下文。这解决的是“记不住中间态”的问题。但还有一个更深层的问题没解决：Agent 执行完一轮任务后，它不知道自己哪做对了、哪做错了，下次依然靠同一套权重去猜。

2. 方案：把 RLMs 的思路接进 Deep Agents

RLMs（Reinforced Language Models，强化语言模型）的核心想法很简单：不是只给模型看正确答案，而是让模型在执行任务后拿到反馈信号，用这些信号去调整后续行为。放到 Agent 场景里，这就对应三件事：

执行反馈：Agent 跑完一次工具链后，系统自动记录结果——是成功了、超时了，还是返回了错误码。
策略更新：把这些反馈映射成可量化的奖励或惩罚，影响后续同类任务里的工具选择优先级。
子 Agent 隔离学习：Deep Agents 的 task 工具可以派生独立上下文的子 Agent。子 Agent 做完专项任务后，把经验回传给父编排器，而不是各干各的。

LangChain 官方的 Deep Agents 已经给出了这套模式的脚手架：write_todos 管规划、task 管子 Agent 委派、文件 I/O 管持久化。RLMs 要接进去，主要补的是“反馈闭环”——在工具执行层后面加一层 reward shaping，再把 shaped reward 写回记忆或文件系统，供下一轮规划时读取。

3. 代码：最小可运行的闭环示例

下面这段代码展示的是思路，不是生产级实现。核心逻辑是：子 Agent 执行任务 → 捕获结果 → 计算 reward → 写入经验文件 → 父 Agent 下一轮读取。

from deepagents import create_deep_agent
from langchain_core.tools import tool

# 1. 定义一个带反馈记录的工具
@tool
def search_and_record(query: str) -> str:
    """搜索并自动记录结果质量。"""
    result = web_search(query)  # 伪代码，替换成真实搜索工具
    score = auto_grade(result)  # 根据返回质量自动打分

    # 把经验写入 Deep Agents 的文件系统
    append_experience(f"{query}|{score}|{timestamp()}")
    return result

# 2. 创建带子 Agent 能力的 Deep Agent
agent = create_deep_agent(
    model="openai:gpt-4o",
    tools=[search_and_record],
    enable_subagents=True,
    memory_enabled=True,
)

# 3. 在每次执行后读取历史经验，调整后续决策
def load_past_rewards() -> str:
    """读取历史执行经验，注入到 system prompt。"""
    experiences = read_experience_file()
    top_lessons = sorted(experiences, key=lambda x: x["score"], reverse=True)[:5]
    return "n".join([f"- {e[query]}: score={e[score]}" for e in top_lessons])

关键设计点：不要把 reward 存在模型上下文里，而是存在文件系统或向量数据库。Deep Agents 的 read_file/write_file 就是干这个的。上下文只存“最近 5 条高 reward 经验”就够了，别把历史全塞回去，成本高且容易污染当前决策。

4. 结论：判断你的 Agent 需不需要这套思路

不是所有 Agent 都需要 RLMs。判断标准很简单：

你的任务有明确的成功/失败信号吗？ 如果 Agent 跑完你都不知道它对错，reward 就没法算。
同类任务会反复执行吗？ 一次性任务不值得加这套闭环，只有高频重复场景才有复利。
你能接受“探索成本”吗？ RLMs 前期会让 Agent 多试几次错的，如果任务容错率极低，先做规则兜底，再考虑强化学习。

如果你的答案都是“是”，那 Deep Agents + RLMs 这条路线值得试。先把反馈闭环跑起来，再考虑上更复杂的策略优化。

收尾

下一步：在现有 Deep Agents 项目里加一个 reward_logger 工具，先把你手动认为“做对了/做错了”的任务记录下来。跑两周，看经验文件里的高分模式能不能反过来帮 Agent 做更好的工具选择。

评论区

0 条评论

登录后可评论。

Agent 总在重复犯错？LangChain Deep Agents 这套 RLMs 思路，比加 prompt 更治本