以Benchmark为轴，串联Prompt、SFT、RL与线上反馈。
冷月清谈：
怜星夜思：
2、离线Benchmark和线上业务指标打架时，应该先信谁，又该怎么排查？
3、怎样防止LLM Judge或Reward Model被模型钻空子，尤其是RL把漏洞越放越大？
原文标题：重磅！从 Agent 开发到 Agent 算法，进阶指南来了
原文作者：数据派THU
原文内容
本文约3500字，建议阅读5分钟从一个 make sense 的方案，到真正 work，再到足够 solid，中间还有很多方法论。
前几天，和朋友讨论了一个有争议的问题：agent开发和agent算法有什么区别？这应该也是很多人找工作关心的点。
我理解是，把一个agent从0快速做到60是开发，做到80并不断追高就是算法。
在这个迭代过程中，不能只靠自己视角下定义的过程指标来判断效果，最终还是要接受上线后的真实业务指标检验。但上线验证周期长、成本高，不可能每次迭代都等线上反馈。所以需要构建离线 Benchmark，尽可能对齐线上效果，用快速的离线评估来指导先验策略迭代。最后再上线获取真实后验，反过来修正和补充新的先验策略。
所以我认为，一套相对完整的Agent业务迭代方法论是：Benchmark → 策略 → 上线。
从一个 make sense 的方案，到真正 work，再到足够 solid，中间还有很多方法论，后面慢慢展开。
01 Benchmark：很多算法实习生的第一份工作
很多算法实习生的第一份工作，就是把 Benchmark 做 solid。比如审今年ICLR的论文，这个判断标准天然主观很模糊，只能专家评，很难机器一步评估，所以可以拆成写作、创新性、实验等多个维度，再分别定义什么情况下应该得到高分或低分，来做的尽量可评。
这个就叫Rubric，把模糊的业务目标，翻译成能够被没那么专业的人、和LLM、程序可以稳定执行的评价标准。这和 Agent 把一个模糊的自然语言目标逐步拆解成可执行的 plan / action 有点像。前者把我要什么转成可评估条件，后者把我要什么转成可执行步骤。本质上是在把模糊的业务目标，翻译成一个可以离线执行的评价标准。类似codex、claude code是把模糊的目标，翻译为可执行代码。
human as a judge
有了Rubric后，自己的事情自己做，先由自己或者业务专家按照Rubric去看几条case，验证 Rubric 本身到底能不能被稳定执行。所以通常会先找一批样本做人标，看人人一致率。
如果同一个 case，两个人按照同一套 Rubric 仍然经常得出不同结论，那很多时候不是 Judge 不行，而是 Rubric 本身还不够清楚，需要继续拆标准、补边界 case。Human Judge是最可靠办法，但又慢又相对贵不能 scaling。
所以发现人可以标后，可以开始研究如何让LLM来标。
llm as a judge
这一步目标是让llm尽可能复现已经稳定下来的人工判断。一般会先用高质量的人标数据作为ground truth，通过手工 PE / AutoPE 不断调整 Judge Prompt，还有一些超参数（比如温度、top k、top p）。如果人\-机一致率很高，说明离线benchmark初步可用了，然后看线上的真实业务指标。
如果发现：离线涨了，线上没涨。那问题就不一定在策略，也可能说明 Benchmark 本身没有对齐真实业务目标，需要继续根据线上 bad case 和后验数据去更新 Cases、Rubric 和 Judge。所以 Benchmark 本身也不是一次性做完的，而是在跟着业务一起迭代（llm泛化性很强，一起迭代问题不大）。
这时候你会发现，每次评测都要跑一次大模型，随着Benchmark、RL rollout规模越来越大，成本和时延可能不能接受。
reward model as a judge
既然做了那么久LLM\-as\-Judge，已经能比较好地复现人工判断，为什么还要再训RM来做judge呢？因为LLM Judge解决了自动化评测，但没有解决规模化评测。
当 Benchmark、实验和 RL rollout 的规模继续扩大时，每次都调用一个大模型做 Judge，成本和时延会随着评测量线性增长（对这个成本没概念可以看看最近mimo的直播RL），而且这个很难通过缩减prompt长度来优化，所以可以把已经验证过的评价标准蒸馏成一个低延迟、高吞吐的rm。
LLM Judge 的优势是泛化能力强，Reward Model只需要在业务对应的数据分布里更强，所以原理上可以用更小的基模，然后用前面已有的评测数据来训。当然也会有Reward Hacking问题，所以RM也不能被当成永远正确，还是需要定期人工、LLM Judge检测新的 bad case 后补充数据，再重新训练和校准RM。
这也是一个 scaling 的过程：Rubric 定义什么叫好，Human 积累人工判断的经验，LLM Judge 把人工判断自动化，Reward Model 再把自动化判断规模化。
02 策略：从跑通 Agent 到持续提升效果
agent策略
做agent策略就是做先验，然后根据上线效果将后验转化为先验（数据驱动），具体的agent策略开发流程我觉得一定是从老实琢磨prompt开始。
prompt策略
根据和多位优秀的小同行讨论经验，大部分业务，根据专家先验知识调好Prompt就可以先上一版，根据上线效果来觉得后续路线，所以一个合理的开发流程应该是：
1. 先用纯Prompt跑通最小闭环；
2. 系统性分析prompt→response这条pipeline上的bad cases；
3. 再通过一些经典手法（RAG、few\-shot、CoT）逐步逼近效果上限；
4. 一边做这个，一边优化benchmark。
很多人低估了prompt用token换精准度的潜力，大模型的能力越来越强，这意味着很多你以为很难的case，其实只是prompt没写好。那么如何系统评估 prompt 是否还有优化空间呢？可以尝试做 Prompt 梯度测试，在同一批样本上逐步增强prompt，看效果是否持续提升。可以按下面的顺序迭代开发：
1. 最简单指令横向对比多个基模，pick最合适的；
2. 根据专家先验知识加system prompt，对应上业务要求；
3. 拆一些workflow来强化PE，比如手动/自动加上下文，让模型有参考信息；
如果随着agent里面流动的prompt逐步增强，效果仍然几乎不变，说明对当前业务，agent策略已经燃尽了，进入下一步llm策略。
llm策略
LLM 策略不是为了替代 Agent 策略，而是把 Agent策略中已经验证有效的非参数化先验，训为模型的参数化行为。Agent 阶段是在 Prompt、Context、Workflow 里告诉模型应该怎么做；LLM 阶段则是让模型自己学会应该怎么做，减少每次都给prompt的成本，同时继续提高效果和稳定性。
做agent开发过程中，如果遇到了效果、稳定性、成本瓶颈，就可以考虑进入llm策略，把 Agent 策略已经验证有效的 60 分方案，做得更稳定、更便宜、更 scalable。
SFT
把 Agent 策略已经验证有效的先验，固化成模型稳定的行为模式。比如在 Agent 开发过程中，我们可能已经验证：1、某种任务理解方式是有效的；2、某类 Few\-shot 能明显提升效果；3、某种 Tool Routing 更稳定；4、某种输出格式更符合下游要求；5、某种拒答边界更符合业务预期。
这些东西一开始都可以写在 Prompt 和 Workflow 里，但如果它们已经经过 Benchmark验证，而且高频、稳定、长期不会频繁变化，就可以进一步考虑通过 SFT 训进参数。
所以我觉得，SFT 前最重要的问题是：哪些 Agent 阶段学到的经验，真的值得被固化进模型？
一个可以参考的原则是：高频变化的信息继续留在 Context，长期稳定的行为才值得训进model。
比如实时库存、活动规则、最新政策这种东西，即使很重要，也不适合训进模型；但固定输出习惯、稳定业务 SOP、Tool 调用方式、任务拆解范式，是适合参数化的。
因此SFT难点是数据。因为本质上就是告诉模型：遇到这种情况，以后就应该这么做。如果同一种业务场景下，一部分数据要求拒答，一部分要求正常回答；一部分要求严格 JSON，一部分允许自由文本；一部分要求先调用工具，一部分直接凭模型知识回答，那么模型学到的不是灵活，而是不确定性。
所以我把 SFT 的数据清洗理解为不是在清洗低质量答案，是在整理模型最终的行为分布。这也是为什么 SFT 数据不是越多越好，更重要的是数据质量、行为一致性。未经Benchmark 验证的 Prompt Hack，不能因为看起来有效就直接扩数据训进去，否则只是把一个还没想明白的策略永久写进参数。
RL
SFT是教模型抄版本答案拿到好结果（codex、簿肌、自媒体、孙学、早C晚A护肤、低糖高蛋白饮食、伪素颜、雅思7\.0、拿实体黄金）。
RL是放大好结果为大结果，让模型自己想办法拿到（来读研 or 去实习）。
前面说 SFT 难在数据质量，那么 RL难在反馈信号。
这也是为什么前面说要花了那么多时间做 Benchmark，因为到了 RL 阶段，Benchmark不只是测试，是反馈。Rubric定义什么叫好，Judge判断好不好，这个判断转化成RL阶段的Reward，直接影响模型往哪个方向优化。
RL难也在这里了，因为你的reward可能不是业务真正需要优化的东西。如果Rubric没对齐业务，Judge没对齐人工（不稳定），Reward又只是离线指标的近似。那么RL阶段，模型学好学坏都是学，所以离线 Reward 涨了，并不等于线上业务指标一定会涨。
最后还是要回到Online Metric：上线拿到新的用户后验，再去更新 Benchmark、拉bad case、修 Rubric、调整数据和 Reward，然后进入下一轮迭代。
Agent 阶段积累专家先验，SFT 把稳定先验写进参数，RL再把业务评价标准变成reward，让模型朝目标继续优化。
reward 设计得好，模型会更稳定地朝业务目标优化。reward 设计错了，模型会更极致地学错。
03 写在最后
分享一些llm策略有争议maybe有价值的讨论：
-
有人说有过拟合的风险，也有人认为只要训练集cover业务场景，过拟合反而是我们的目标...
-
有人说有灾难性遗忘的风险，也有人认为遗忘是一种数据提纯...
-
做agent开发的朋友说workflow才是通往AGI的道路，微调只是参数内卷、原地踏步...
-
做aigc的朋友认为，真正决定应用效果上限的，始终还是模型自身的能力边界...
编辑：文婧
