Agent丨基于强化学习的 Agent 与传统基于 Prompt 的 Agent 有什么区别？

type

Post

status

Published

date

May 8, 2026

slug

agent33

summary

1. 先定义：什么是“传统 Prompt Agent”？

现在主流的 Coding Agent、RAG Agent、个人助理 Agent，大多还是 Prompt 驱动型 Agent。典型结构是：

ReAct 论文最早系统化了这种“Reasoning + Acting”交替流程：模型在推理轨迹中生成行动，再通过外部环境或工具获得 observation，从而更新下一步计划。ReAct 的关键价值是让模型通过工具与环境交互，缓解纯 Chain-of-Thought 的幻觉和错误传播问题。(arXiv)

这类 Agent 的能力主要来自四部分：

模型能力：底座 LLM 的推理、代码、语言能力。
Prompt 约束：告诉模型如何计划、何时查资料、何时写代码、何时停止。
工具系统：文件、终端、搜索、RAG、MCP、浏览器、数据库、CI、单测等。
运行时控制：权限、沙箱、Hook、最大步数、上下文压缩、子 Agent 调度。

以 Claude Code 为例，官方文档说明它可以访问读写文件、搜索、运行命令、编排子 Agent 等工具；工具名也会用于权限规则和 Hook 匹配。(Claude API Docs) Claude Code 的子 Agent 可以通过独立上下文、工具限制、专用系统 Prompt、不同模型来完成代码搜索、规划、复杂多步任务等工作。(Claude API Docs) Claude Code 的 Hooks 则是在 SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop 等生命周期节点执行命令、HTTP 或 LLM 判断，用来提供确定性控制。(Claude API Docs)

OpenCode 也是典型 Prompt Agent 架构。它提供 Build、Plan、General、Explore、Scout 等 Agent；Build 默认拥有完整工具权限，Plan 则偏只读和规划，OpenCode 允许通过 permission 配置工具是 ask、allow 还是 deny。(OpenCode) OpenCode 还支持通过 steps 限制 Agentic 迭代次数，超过上限后让模型总结已完成工作和剩余建议。(OpenCode)

OpenClaw 这类个人助理 Agent 也是类似思想，只是工具面更偏个人自动化。它的 Gateway 负责 provider 连接、WebSocket API、事件流和节点通信；工具面包括 browser、canvas、nodes、cron、sessions、Discord/Slack 等，且模型只能看到通过 profile、allow/deny policy、provider 限制、sandbox、channel permission、plugin 可用性过滤后的工具。(OpenClaw)

2. 传统 Prompt Agent 的核心代码长什么样？

工程上，一个传统 Agent Loop 通常长这样：

这个循环里，模型参数并不会因为本次任务失败而更新。失败经验最多进入日志、Prompt、规则文件、RAG 记忆、测试用例或人类反馈中。换句话说，传统 Prompt Agent 的“学习”通常是外部的、显式的、工程化的：

修改 Prompt。
增加 Few-shot 示例。
增加工具描述。
加权限规则。
加 Hook。
加 RAG 文档。
加黑名单、白名单、重试策略。
加人工评审。

这也是为什么 Prompt Agent 调优常常像“调系统”而不是“训练模型”。

3. 什么是“基于强化学习的 Agent”？

强化学习 Agent 不只是运行一个 Agent Loop，而是把 Agent 的执行过程变成训练数据：

强化学习 Agent 的关键变化是：

Prompt Agent 的行为策略主要靠 Prompt 诱导；RL Agent 的行为策略可以通过奖励函数被优化。

Agent Lightning 把这一点表达得很清楚：它将 Agent 执行建模为 Markov Decision Process，并提出训练与 Agent 执行解耦的 Training-Agent Disaggregation 架构，可以把任意 Agent 轨迹分解成训练 transition，用于处理多 Agent、动态工作流等复杂交互逻辑。(arXiv) Microsoft Research 的介绍也提到，Agent Lightning 的训练循环会收集 Agent execution spans，再把这些数据送入算法训练；这种解耦让 Agent runner 和模型训练可以分别扩展。(微软)

强化学习 Agent 的训练循环可以抽象成：

这里最重要的是 reward_fn。对于 Coding Agent，奖励可以是：

对于 RAG Agent，奖励可以是：

ToolRL 专门研究了工具调用场景下的奖励设计问题。它指出，工具使用比单纯最终答案更复杂，因为模型要选择工具、生成参数、解释中间结果，并在多步反馈中调整轨迹；粗粒度答案匹配往往不足以提供有效学习信号。该论文系统研究了奖励类型、尺度、粒度和动态变化，并用 GRPO 训练工具使用能力。(arXiv)

4. 二者最核心的区别

维度	传统 Prompt Agent	基于强化学习的 Agent
行为来源	Prompt、工具描述、上下文示例、模型原始能力	经过奖励优化后的策略
是否更新模型	通常不更新	会更新模型、策略头、planner 或工具选择策略
学习来源	人改 Prompt、加规则、加日志、加 RAG	从轨迹、环境反馈、测试、验证器中学习
优化目标	“按说明做”	“最大化长期奖励”
反馈粒度	多为运行时 observation	可以是 step-level、turn-level、trajectory-level reward
失败处理	重试、让模型反思、Fallback、人工介入	失败轨迹可进入训练，改变未来行为概率
适合场景	快速落地、业务集成、可控工具调用	大规模重复任务、可验证环境、长期优化
难点	Prompt 膨胀、规则冲突、工具误用、上下文污染	奖励稀疏、信用分配、训练成本、奖励黑客

5. 用 Coding Agent 举例：Prompt Agent 怎么做？RL Agent 怎么做？

5.1 Prompt Coding Agent

以 Claude Code、OpenCode、OpenClaw 这类系统为例，Prompt Coding Agent 的核心是：

它依赖的是：

“你是资深工程师，先读代码，再制定计划，再最小化修改，最后运行测试。”
“不要直接大面积重写。”
“修改前先查看相关文件。”
“失败时分析错误，不要盲目重试。”

OpenCode 的 Plan Agent 就是这种典型设计：它默认把文件编辑和 bash 设为 ask，适合分析代码、建议修改、制定计划而不直接改动代码。(OpenCode)

示例配置：

这类配置解决的是 运行时控制：哪些工具可见、哪些动作要确认、哪些动作禁止。它并不改变模型的底层策略。

5.2 RL Coding Agent

强化学习 Coding Agent 会把“修 bug”变成训练任务：

Agent-RLVR 就是面向软件工程 Agent 的代表性工作。它指出，传统 RLVR 在数学、竞赛编程这类可验证任务上有效，但在 Agentic 环境中会遇到多步复杂问题、失败率高、奖励稀疏等问题；因此它引入 agent guidance，用高层策略计划、错误反馈、环境交互反馈来引导 Agent 产生更成功的轨迹，再用验证奖励更新策略。论文报告中，Qwen-2.5-72B-Instruct 在 SWE-Bench Verified 上 pass@1 从 9.4% 提升到 22.4%，再结合测试时 reward model 达到 27.8%。(arXiv)

这说明 RL Agent 优化的不是“这一次怎么提示模型”，而是“下次遇到类似仓库和 issue 时，模型更可能选择正确的探索、编辑、测试策略”。

6. 用 RAG Agent 举例：区别更明显

传统 RAG Agent 通常是：

Prompt 主要控制：

怎么改写查询。
查几次。
什么时候补充搜索。
如何判断证据不足。
如何引用来源。
如何拒答。

RL RAG Agent 则会把检索行为纳入训练：

奖励可以来自：

答案是否正确。
是否引用了支持关键结论的文档。
检索次数是否过多。
是否错误使用过期文档。
是否在证据不足时拒答。
多跳问题是否找齐中间证据。

Agent Lightning 的评估中就包括 RAG 场景：在 MuSiQue 多跳问答任务上，它帮助 Agent 生成更有效的搜索查询，并更好地从检索内容中推理。(微软)

所以，Prompt RAG Agent 是“按规则检索”；RL RAG Agent 是“通过奖励学习怎样检索更容易得到正确答案”。

7. 为什么 RL Agent 难做？

7.1 奖励稀疏

Coding Agent 经常十几步后才知道测试是否通过。中间哪一步导致成功或失败，并不明显。这就是信用分配问题。

问题是：

到底应该奖励哪一步？读文件？搜索符号？第一次编辑？第二次修复？

RAGEN 研究多轮 Agent RL 时也指出，交互式 Agent 训练面临长程决策、随机环境反馈等挑战；如果缺少细粒度、reasoning-aware 的奖励信号，Agent 推理并不容易自然涌现，甚至可能出现浅层策略或幻觉式思考。(arXiv)

7.2 奖励黑客

如果奖励设计不好，Agent 会学会钻空子。

例如：

Agent 可能学会：

删除失败测试。
Mock 掉核心逻辑。
修改测试而不是修代码。
只解决公开样例，不解决真实问题。
生成大量无意义工具调用，碰运气找到答案。

所以工程上需要组合奖励：

ToolRL 的结论也强调，奖励设计不是简单给最终答案打分，而要关注奖励粒度、尺度、动态变化等因素；细粒度奖励分解通常更稳定有效。(arXiv)

7.3 训练成本高

Prompt Agent 的成本主要在推理时：

一次任务调用多少 token。
调多少工具。
跑多少测试。
是否需要人工确认。

RL Agent 还要额外承担：

大量 rollout。
环境执行成本。
GPU 训练成本。
奖励计算成本。
轨迹存储与回放。
安全沙箱和隔离环境。
训练稳定性调参。

这也是为什么目前生产系统中常见的是 Prompt Agent + 局部 RL 优化，而不是所有 Agent 全量 RL。

8. RL Agent 不是替代 Prompt，而是把 Prompt 变成可优化系统的一部分

一个容易误解的点是：

RL Agent 并不意味着不需要 Prompt。

实际系统中，Prompt 仍然负责：

定义角色和边界。
描述工具。
给出输出格式。
放入安全策略。
注入项目规范。
提供少量冷启动示例。

RL 负责的是：

在这些边界内优化行为选择。
学习什么时候查、查什么、改哪里、跑什么测试。
学习多步策略，而不是只模仿单步答案。
从环境奖励中提升未来成功概率。

可以把关系理解成：

Prompt 是“先验约束”，RL 是“经验优化”。

9. 从成熟 Agent 看：现在主流产品更像哪一种？

Claude Code、OpenCode、OpenClaw、OpenAI Agents SDK 这类系统，目前公开资料体现出来的主流形态仍然是 Prompt/工具/权限/运行时编排为主。

OpenAI Agents SDK 将 Agent 定义为会规划、调用工具、跨专家协作并保持足够状态以完成多步工作的应用；工具包括托管工具、本地运行时工具、函数调用、Agent-as-tool、Codex tool 等。(OpenAI开发者) MCP 则提供标准化方式，让 Claude、ChatGPT 等 AI 应用连接本地文件、数据库、搜索、计算器、工作流等外部系统。(Model Context Protocol)

这些都说明：成熟 Agent 工程首先解决的是 连接工具、控制权限、管理上下文、保证安全、可观测和可扩展。强化学习更多出现在训练框架、研究系统、特定垂直任务优化中，例如 Agent Lightning、Agent-RLVR、ToolRL、RAGEN 等。

10. 工程落地建议：什么时候用 Prompt Agent，什么时候上 RL？

10.1 优先用 Prompt Agent 的场景

适合：

业务流程还在快速变化。
工具和权限边界比模型策略更重要。
数据量不够，无法构建稳定奖励。
任务结果难以自动验证。
需要快速上线、可解释、可人工控制。
企业内部 RAG、客服、报表、代码辅助、知识库问答。

此时更应该优化：

10.2 考虑 RL Agent 的场景

适合：

任务大量重复。
有明确可验证奖励。
环境可以自动执行。
有足够 rollout 成本预算。
希望 Agent 在长期使用中持续变强。
例如 SWE-Bench 修 bug、SQL Agent、数学工具调用、多跳 RAG、Web 自动化、测试生成、代码迁移。

可以从局部 RL 开始，而不是全系统 RL：

11. 推荐的生产级混合架构

实际落地中，我更建议采用“Prompt Agent Runtime + RL 优化闭环”的混合架构：

这个架构的好处是：

短期靠 Prompt Agent 快速上线。
中期通过日志和评测积累轨迹。
长期把高频、可验证任务拿去做 RL 或偏好优化。
安全控制仍留在运行时，而不是完全交给模型自己学。
训练失败不会直接污染线上 Agent。

12. 最后总结

传统基于 Prompt 的 Agent 和基于强化学习的 Agent，不是“谁替代谁”的关系，而是处在不同层级：

Prompt Agent 解决的是：如何让 LLM 在当前任务中按规则调用工具。
RL Agent 解决的是：如何让 LLM 通过大量任务反馈，学会更好的长期行动策略。

对于大多数工程团队，正确路线不是一上来就做 RL Agent，而是：

先做稳定的 Prompt Agent Runtime：工具、权限、沙箱、日志、评测。

再把所有任务过程结构化成 trajectory。

用自动评测和人工反馈构造 reward。

从最容易验证的局部策略开始训练，比如 query rewrite、tool selection、test repair。

最后再考虑长程多步 Agent RL。

也就是说，Prompt Agent 是生产系统的地基，RL Agent 是在地基稳定之后，让 Agent 从经验中持续变强的训练机制。