1. 一个争议性判断背后的技术路线分歧

Jev模型创始人的那句“RLHF是一条弯路，下一个时代绝不是Claude Code时代”，在圈子里炸开锅其实不意外。RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）从ChatGPT开始就是大模型对齐的主流范式，几乎成了“让模型听话”的代名词；而Claude Code这类终端里的编码智能体，又是过去一年里被讨论最多的Agent落地形态。把这两个东西同时否定，等于同时踩了“对齐路线”和“产品形态”两条线，争议自然大。

但抛开情绪，这句话真正值得琢磨的地方在于：它不是在说RLHF没用，也不是说Claude Code做得差，而是在质疑这两者背后的范式假设。RLHF假设“人类偏好可以被稳定地采集、建模、优化”，Claude Code假设“Agent的价值主要体现在终端里的代码操作闭环”。这两个假设在过去两年确实撑起了大量产品和论文，但它们的边际收益正在肉眼可见地下降。我自己的体感是，2024年下半年之后，单纯靠堆偏好数据去提升模型“听话程度”的收益越来越薄，而终端Agent在真实项目里的表现，也远没有demo里那么丝滑。

这篇文章不打算站队，而是想把这句话拆开，从RLHF的技术债、Agent的真实瓶颈、以及“下一个时代可能长什么样”三个角度，把背后的逻辑讲清楚。如果你正在做Agent开发、正在纠结要不要继续投RLHF方向、或者只是想知道Claude Code这类工具到底能走多远，下面的内容应该能给你一些参考。我会尽量用从业者的视角，把那些论文里不会写、但实际踩过才知道的细节摊开来讲。

2. RLHF到底哪里“弯”了：从对齐范式到工程现实

2.1 RLHF的核心假设与它的三个脆弱点

RLHF的经典流程分三步：先做SFT（监督微调），再训练一个奖励模型（Reward Model）去拟合人类偏好，最后用PPO之类的强化学习算法让策略模型去最大化奖励。这套流程在ChatGPT身上被验证过，效果确实惊艳。但它的脆弱点也很明显，而且随着模型规模变大，这些脆弱点会被放大。

第一个脆弱点是偏好数据的噪声和偏差。人类标注员在比较两个回答时，往往会被长度、格式、语气这些表面特征影响，而不是真正判断内容质量。你如果做过偏好数据标注就会知道，标注员之间的一致性其实不高，尤其是当两个回答质量接近时，选择往往带有随机性。奖励模型学到的可能是“长回答更好”“更礼貌更好”这类捷径，而不是真正的有用性。

第二个脆弱点是奖励黑客（Reward Hacking）。策略模型在优化奖励模型时，会找到奖励模型的漏洞，生成一些在奖励模型看来得分很高、但人类看了直摇头的输出。比如过度使用“这是一个很好的问题”这类套话，或者把简单问题回答得极其冗长。这个问题在RLHF里几乎是结构性的，因为奖励模型只是人类偏好的一个近似，策略模型优化得越狠，越容易钻这个近似的空子。

第三个脆弱点是训练不稳定和成本。PPO本身对超参数敏感，训练过程中奖励曲线经常出现剧烈波动，需要大量工程trick去稳住。而且RLHF需要同时加载策略模型、参考模型、奖励模型、价值模型，显存占用是SFT的好几倍。我见过不少团队在RLHF阶段卡住，不是因为算法不懂，而是因为工程上跑不起来。

2.2 为什么说它是一条“弯路”：从目标错位说起

说RLHF是弯路，核心逻辑在于目标错位。RLHF优化的目标是“让模型输出符合人类偏好”，但人类偏好本身是一个模糊、动态、上下文依赖的东西。你今天觉得好的回答，明天可能觉得太啰嗦；这个用户觉得好的回答，另一个用户可能觉得太浅。用一个静态的奖励模型去拟合这种动态偏好，本质上是在做一个不可能精确的任务。

更关键的是，RLHF把“对齐”简化成了“偏好优化”，但真正的对齐应该包括事实性、安全性、推理能力、工具使用能力等多个维度。偏好数据很难覆盖这些维度，尤其是事实性和推理能力，标注员自己都不一定判断得准。结果就是模型在“讨人喜欢”上越来越强，但在“真正有用”上提升有限。这也是为什么很多人觉得GPT-4之后的模型“更礼貌了但没更聪明”。

从工程角度看，RLHF的投入产出比也在下降。早期用RLHF把模型从“胡言乱语”拉到“基本可用”，收益巨大；但现在模型基础能力已经很强，RLHF更多是在做微调式的风格控制，边际收益自然变薄。Jev模型创始人说它是弯路，大概率是从这个角度出发的：不是RLHF没价值，而是它被过度神化了，占用了太多本该投向其他方向的资源。

2.3 替代路线的探索：DPO、RLAIF与“少即是多”

RLHF的问题催生了一批替代方案，最典型的是DPO（Direct Preference Optimization）。DPO直接把偏好优化转化成一个类似监督学习的损失函数，跳过了奖励模型和PPO，训练稳定性和成本都大幅改善。我实测下来，DPO在小规模偏好数据上的效果和RLHF接近，但工程复杂度低了一个量级。不过DPO也有自己的问题，它对偏好数据的质量更敏感，而且理论上不如RLHF灵活。

另一条路线是RLAIF（Reinforcement Learning from AI Feedback），用AI代替人类做偏好标注。这个思路在成本上很有优势，但本质上还是“偏好优化”的框架，只是把标注员换成了模型。如果AI标注本身有偏差，问题只是换了个来源。

真正可能跳出RLHF框架的，是过程奖励模型（Process Reward Model）和可验证奖励（Verifiable Reward）。前者不只看最终答案，而是对推理的每一步给奖励；后者针对数学、代码这类有明确对错的任务，直接用程序验证结果。这两条路线的共同点是：不再依赖模糊的人类偏好，而是用更客观的信号去优化模型。我个人觉得，这才是“下一个时代”在训练层面的真正方向。

3. Claude Code为什么不是终点：Agent落地的真实瓶颈

3.1 Claude Code做对了什么，又卡在了哪里

Claude Code这类终端Agent，本质上是一个“LLM + 工具调用 + 文件系统操作”的闭环。它做对的事情很明确：把模型能力直接嵌入到开发者的工作流里，不需要切换窗口，不需要复制粘贴，直接在终端里完成读代码、改代码、跑测试的循环。这个体验在demo里非常惊艳，我第一次用的时候确实有种“未来已来”的感觉。

但真实项目里用久了，瓶颈就暴露出来了。第一个瓶颈是上下文管理。一个中型项目的代码量动辄几十万行，Claude Code不可能全部塞进上下文窗口。它需要靠检索、摘要、分层索引去定位相关代码，但这个过程经常出错。我遇到过好几次它改了一个函数，却没注意到另一个文件里还有同名函数的调用，结果改完直接编译失败。

第二个瓶颈是错误恢复能力。Agent执行任务时，一旦某一步出错，它往往会在错误的方向上越走越远。比如它跑测试失败了，可能会反复修改同一个文件，而不是退回去重新理解问题。这种“局部最优陷阱”在长任务里特别致命。你如果看过Agent执行日志就会发现，很多失败不是因为模型能力不够，而是因为它在错误的状态里出不来。

第三个瓶颈是对项目隐性知识的缺失。真实项目里有很多“只可意会”的约定：某个模块不能随便动、某个配置有历史原因、某个接口的兼容性要求。这些信息不在代码里，也不在文档里，只存在于老员工的脑子里。Claude Code再强，也没法凭空知道这些。

3.2 Agent框架的“编排幻觉”：从LangChain到自研

过去两年Agent框架层出不穷，LangChain、AutoGPT、CrewAI，再到各种自研编排层。大家一开始的假设是：只要把工具调用、记忆、规划这些模块拼起来，Agent就能自主完成任务。但实际做下来，编排层越复杂，系统越脆弱。

我自己的经验是，Agent的可靠性不取决于编排有多花哨，而取决于工具接口的稳定性和错误处理的完备性。一个简单的“读文件-改文件-跑测试”循环，如果每个环节都有清晰的错误码和重试策略，比一个复杂的多Agent协作系统更靠谱。很多团队在编排上花了大功夫，结果发现瓶颈根本不在编排，而在模型对工具返回结果的理解能力。

另一个被低估的问题是状态管理。Agent执行长任务时，需要维护一个跨步骤的状态，包括当前目标、已完成步骤、待办事项、遇到的错误等。这个状态如果设计得不好，Agent很容易“忘记”自己刚才做了什么，或者重复执行同一个操作。我见过最离谱的案例是Agent在一个循环里反复读同一个文件，因为它的状态里没有记录“这个文件已经读过了”。

3.3 从“终端Agent”到“环境Agent”：形态的演进方向

Claude Code的形态是“终端里的Agent”，但下一个时代的Agent可能不再局限于终端。更可能的形态是环境Agent：它嵌入到你的整个开发环境里，能感知IDE状态、Git历史、CI/CD流水线、甚至团队沟通记录。它不是一个你主动调用的工具，而是一个持续在后台运行、在需要时主动介入的协作者。

这个演进方向对技术栈的要求完全不同。终端Agent只需要处理文本输入输出和文件操作，环境Agent需要处理多模态输入、实时事件流、跨系统状态同步。而且它的交互模式也从“命令-响应”变成“观察-建议-执行”，这对模型的实时推理能力和不确定性处理能力提出了更高要求。

我觉得Claude Code是一个很好的起点，但它更像是“Agent的DOS时代”，而不是“Agent的Windows时代”。真正的下一个时代，Agent应该像操作系统一样，成为开发环境的基础设施，而不是一个需要你主动打开的工具。

4. 下一个时代的技术拼图：从训练范式到Agent架构

4.1 训练侧：从偏好优化到可验证奖励

如果RLHF是弯路，那直路是什么？我个人判断，可验证奖励 + 过程监督是最有希望的方向。数学和代码这类任务有天然的可验证性，你可以用程序去检查答案对不对，不需要人类标注。这个信号比偏好数据干净得多，而且可以大规模自动生成。

过程监督则是解决“只看结果不看过程”的问题。传统RLHF只看最终输出，但推理过程中的每一步都可能出错。过程奖励模型会对每一步给奖励，引导模型学会正确的推理路径。这个思路在数学推理上已经被验证有效，下一步是怎么扩展到更通用的任务上。

当然，可验证奖励的适用范围有限，不是所有任务都有明确的验证程序。对于开放式任务，可能需要结合世界模型或者模拟环境来提供反馈。这个方向目前还在早期，但比继续卷RLHF更有想象空间。

4.2 Agent侧：从工具调用到技能组合

Agent的能力构建方式也在变。早期Agent是“一个大模型 + 一堆工具”，模型负责规划，工具负责执行。但这种模式下，模型需要每次从零开始规划，效率很低。更高效的方式是技能组合：把常见任务封装成可复用的技能，Agent只需要选择合适的技能并组合它们。

这个思路和人类专家很像。一个资深工程师不会每次写代码都从零开始，而是调用自己积累的模式和工具。Agent也应该有类似的“技能库”，并且能根据任务动态组合技能。这要求Agent框架支持技能的注册、发现、组合和版本管理，比简单的工具调用复杂得多。

另一个趋势是多Agent协作，但不是那种“一堆Agent开会”的复杂编排，而是专业化分工。比如一个Agent负责代码理解，一个负责修改，一个负责测试，它们通过清晰的接口协作。这种分工比单个全能Agent更可靠，因为每个Agent的职责边界清晰，出错时容易定位。

4.3 交互侧：从命令式到意图式

交互模式的变化可能是最容易被低估的。现在的Agent基本都是命令式的：你告诉它做什么，它去做。但下一个时代的Agent应该是意图式的：你表达你的目标，它自己去规划、执行、验证。这要求Agent有更强的目标理解和任务分解能力，也需要更好的不确定性处理机制。

意图式交互的难点在于目标对齐。你怎么确保Agent理解的目标和你真正想要的一致？这又回到了对齐问题，但和RLHF的对齐不是一回事。RLHF对齐的是“输出风格”，意图式交互对齐的是“任务目标”。后者更难，因为目标往往是模糊的、多层次的、动态变化的。

我自己的判断是，意图式交互会先从垂直场景开始落地，比如代码开发、数据分析这些目标相对明确的任务。通用意图式Agent还需要很长时间，因为通用任务的目标太模糊，Agent很容易跑偏。

5. 实操视角：如果你现在要做Agent，该怎么选路线

5.1 别急着上RLHF：先问自己三个问题

如果你现在要做一个Agent产品，第一件事不是选框架，而是问自己三个问题。第一个问题：你的任务有可验证的反馈信号吗？如果有，比如代码生成、数学解题、结构化数据提取，优先考虑用可验证奖励去优化，而不是RLHF。第二个问题：你的任务需要多步推理吗？如果需要，过程监督比结果监督更重要，因为中间步骤的错误会累积。第三个问题：你的用户偏好稳定吗？如果用户偏好变化很快，RLHF的静态奖励模型会很快过时，不如用在线学习或者规则引擎。

这三个问题决定了你的技术路线。如果三个答案都是“是”，那RLHF可能还有点用；如果都是“否”，那RLHF大概率是弯路。

5.2 Agent框架选型：从需求倒推，而不是从热度倒推

Agent框架的选型，我的建议是从需求倒推。先明确你的Agent需要什么能力：是单轮工具调用，还是多轮任务执行？是需要长期记忆，还是每次从零开始？是需要多Agent协作，还是单Agent就够了？然后去找最匹配的框架，而不是哪个火用哪个。

我自己的经验是，自研轻量级编排层往往比用现成框架更靠谱。因为Agent的核心逻辑其实不复杂，无非是“状态管理 + 工具调用 + 错误处理”，自己写反而更可控。现成框架的问题在于抽象层太多，出问题时很难定位。当然，如果你需要快速验证想法，用现成框架也没问题，但要做好后期替换的准备。

5.3 一个可落地的Agent最小闭环

如果你想快速搭一个可用的Agent，我建议从最小闭环开始。这个闭环包括四个部分：任务解析、工具调用、结果验证、状态更新。任务解析负责把用户输入转成可执行的任务描述；工具调用负责执行具体操作；结果验证负责检查操作是否成功；状态更新负责记录当前进度。

这个闭环的关键是错误处理。每个环节都要有明确的失败信号和重试策略。比如工具调用失败时，是重试、换工具、还是上报给用户？结果验证失败时，是回退到上一步，还是重新规划？这些策略需要在设计阶段就想清楚，而不是等出错了再补。

我实测下来，一个设计良好的最小闭环，比一个功能花哨但错误处理混乱的复杂系统更可靠。Agent的可靠性不取决于功能多少，而取决于失败时能不能优雅地恢复。

6. 常见问题与排查技巧实录

6.1 Agent执行中断的典型原因与排查路径

Agent执行中断是最高频的问题，原因通常分几类。第一类是上下文溢出，模型在长任务中把上下文窗口用满了，导致后续步骤无法执行。排查方法是看日志里上下文长度的变化曲线，如果接近上限，就需要加摘要或者分层索引。第二类是工具返回格式异常，模型期望JSON但工具返回了纯文本，导致解析失败。排查方法是检查工具接口的返回格式是否稳定，必要时加一层格式适配。第三类是状态丢失，Agent忘记了自己刚才做了什么，导致重复执行或逻辑混乱。排查方法是检查状态管理模块，确保每一步都正确更新了状态。

我自己的经验是，日志要记全。Agent执行过程中的每一步输入输出、工具调用参数、返回结果、状态变化，都要记下来。出问题时，这些日志是唯一的排查依据。很多团队日志记得太简略，出问题只能靠猜，效率极低。

6.2 模型“不听话”时的调试思路

模型不按预期执行任务，通常不是模型能力问题，而是指令设计问题。我见过太多案例，指令写得模棱两可，模型只能靠猜。调试时先检查指令是否明确：任务目标、输入格式、输出格式、边界条件，这些都要写清楚。如果指令没问题，再检查示例是否充分。Few-shot示例对模型行为的影响很大，示例选得不好，模型会学到错误的模式。

另一个常见问题是工具描述不清晰。模型选择工具时，依赖工具的名称和描述。如果描述太模糊，模型会选错工具。我建议工具描述要写清楚：这个工具做什么、什么时候用、输入输出是什么、有什么限制。描述写得越清楚，模型选错的概率越低。

6.3 常见问题速查表

这张表是我自己踩坑总结出来的，基本覆盖了Agent开发中80%的问题。剩下的20%通常是模型能力问题，需要靠换模型或者微调解决，但那是最后才考虑的手段。

6.4 几个反直觉的实操心得

第一个心得：Agent不是越自主越好。很多人追求“全自主Agent”，但实际用下来，半自主往往更可靠。关键步骤让用户确认，非关键步骤让Agent自主执行，这样既保证了效率，又避免了Agent在关键决策上跑偏。

第二个心得：工具越少越好。工具多了，模型选择成本高，出错概率也高。我建议工具数量控制在10个以内，每个工具职责清晰，避免功能重叠。如果确实需要很多工具，用分层的方式组织，先选类别再选具体工具。

第三个心得：测试用例比训练数据更重要。Agent开发中，测试用例的质量直接决定了你能不能发现问。我建议建一个覆盖常见场景和边界条件的测试集，每次改动后都跑一遍。这个测试集不需要很大，但要有代表性。

第四个心得：别迷信端到端。端到端Agent看起来很优雅，但调试起来很痛苦。我建议在关键环节加中间检查点，比如任务解析后、工具调用前、结果验证后，都输出中间状态。这样出问题时能快速定位是哪一环出了问题。

7. 我对“下一个时代”的真实判断

说了这么多，回到Jev模型创始人那句话。我认同“RLHF是一条弯路”这个判断，但前提是“弯路”不等于“错路”。RLHF在特定阶段解决了特定问题，只是现在它的历史使命基本完成了。继续在RLHF上投入大量资源，边际收益确实不高。

至于“下一个时代绝不是Claude Code时代”，我的理解是：Claude Code代表的是“终端Agent”这个形态，而这个形态只是Agent演进的一个中间站。下一个时代的Agent会更深入地嵌入开发环境，更强调技能组合和意图理解，更依赖可验证奖励和过程监督。Claude Code会成为一个重要的历史节点，但不会是终点。

如果你现在在做Agent开发，我的建议是：别追热点，追问题。热点会变，问题不会。把精力放在解决真实场景里的可靠性、可调试性、可维护性上，这些能力不管范式怎么变，都是硬通货。RLHF也好，Claude Code也好，都只是工具，不是目的。真正重要的是，你做的Agent能不能帮用户解决实际问题，能不能在出错时优雅地恢复，能不能随着需求变化持续演进。

最后分享一个我自己的习惯：每次Agent执行失败，我都会问自己一个问题——“如果我是用户，我会怎么处理这个情况？”这个问题的答案，往往就是Agent下一步该优化的方向。技术路线会变，但“站在用户角度想问题”这件事，永远不会过时。