1. 一个争议性判断背后的技术路线分歧Jev模型创始人的那句“RLHF是一条弯路下一个时代绝不是Claude Code时代”在圈子里炸开锅其实不意外。RLHFReinforcement 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的问题催生了一批替代方案最典型的是DPODirect Preference Optimization。DPO直接把偏好优化转化成一个类似监督学习的损失函数跳过了奖励模型和PPO训练稳定性和成本都大幅改善。我实测下来DPO在小规模偏好数据上的效果和RLHF接近但工程复杂度低了一个量级。不过DPO也有自己的问题它对偏好数据的质量更敏感而且理论上不如RLHF灵活。另一条路线是RLAIFReinforcement 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反复执行同一操作状态未更新或状态丢失检查状态管理日志确保每步操作后更新状态工具调用返回解析失败返回格式不稳定检查工具接口返回格式加格式适配层或统一返回格式长任务中途停止上下文溢出查看上下文长度曲线加摘要、分层索引或分段执行模型选错工具工具描述模糊检查工具描述文本补充使用场景和限制说明任务方向跑偏指令不明确检查任务指令明确目标、格式和边界条件错误后无法恢复缺少错误处理策略检查错误处理逻辑设计重试、回退、上报策略这张表是我自己踩坑总结出来的基本覆盖了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下一步该优化的方向。技术路线会变但“站在用户角度想问题”这件事永远不会过时。
