9 种技术、3 个梯度、1 张选型表：NVIDIA 这篇 Agent 定制化指南到底在讲什么

原文：Mastering Agentic Techniques: AI Agent Customization · NVIDIA Technical Blog · 2026-05-20 作者：Edward Li · Vanessa Bellotti · Rebecca Kao（NVIDIA Enterprise Computing / Product Marketing）

一句话导读：把通用基模直接接到业务上的时代结束了。这篇 NVIDIA 官方导读把"如何让 Agent 真正听话"拆成了 9 种技术，但真正值钱的不是 9 种技术，而是它们背后的 3 个梯度——推理时、训练时、对齐与强化。本文按这条骨架重构原文，每一节回答同一个问题：「在我们的业务里，应该走到哪个梯度，再不要往下了？」

Agent 定制化的三梯度地图：从 Prompt 到 RLVR

引言：为什么定制化是 Agent 从 Demo 到生产的分水岭

如果你现在维护一个企业内部的 Agent 系统——客服工单分级、研发知识库问答、运维事件诊断、合规材料初审——大概率都遇到过同一类问题：

Demo 时表现惊艳，一上灰度就开始胡说八道；调一版 Prompt 解决了三个 case，又冒出来五个新的；模型一换厂商，所有"调好的话术"全得重写一遍。

NVIDIA 这篇文章给出的判断很直接：通用基础模型在垂直业务上"一定会"达到能力天花板。它的训练目标是"对所有人都还行"，但你的业务要的是"对这一类工单的判断准确率到 95%"。从前者到后者，靠的不是再写一段更长的 System Prompt，而是沿着一条定制化的梯度向下走——能在浅层解决就不要往深里挖，浅层挖不动了再换工具。

原文列了 9 种技术，但真正可操作的认知是这 3 个梯度：

推理时（Inference-time）：不动模型权重，只改 Context。Prompt、RAG、Tool / Skill 都属于这一档。
训练时（Training-time）：动权重，但只是教模型「模仿」。SFT 与 PEFT（LoRA / QLoRA）属于这一档。
对齐与强化（Alignment / RL）：动权重 + 改奖励，教模型「分辨好坏」或「逼近正确」。DPO、RLHF、RLVR、GRPO 都属于这一档。

梯度的方向就是改造深度——越往下，可塑性越高，但所需的数据、算力、评测基础设施也呈数量级增长。任何健康的 Agent 工程化，都应该自上而下走，而不是反过来。

一、定制化的三梯度地图：从推理时到强化对齐

先不展开技术细节，先看这张全景：

三梯度 · 9 种技术全景：成本、改造深度、能力上限

读这张图有三个角度：

从左到右是改造深度：Prompt 改的是模型的"任务说明书"，RAG 改的是"知识来源"，Tool / Skill 改的是"动手能力"，到 SFT 才开始动模型本身的"反射"，再到 DPO / RLVR 已经是在改"价值判断"。
从上到下是技术债：上面三档的技术债是 Prompt 蔓延、Skill 维护成本；下面四档的技术债是数据集治理、训练 pipeline、奖励函数失真。两类技术债的解法完全不同。
天花板不是叠加的：只做 Prompt + RAG，能力上限大概率卡在「输出格式不稳、复杂多步推理掉链」；只有进入 SFT / RLVR 这一层才有质变。但反过来，没有 Stage 1 沉淀下来的评测集和 Skill 边界，下面的训练就是在黑盒里打靶。

关键判断：定制化的本质是"让 Context 和权重协同生效"，而不是"用更深的技术替代浅技术"。

二、推理时三技：Prompt、RAG、Tool & Skill

2.1 Prompt & System Prompt：被低估的"任务说明书"

最便宜、收益最快的一档。一个写得好的 System Prompt 至少要回答四件事——Agent 的角色 / 可用的工具 / 输出格式 / 行为约束。NVIDIA 给的极简例子：

You are an expert CLI assistant. Translate user requests into structured JSON tool
calls. Respond with ONLY a JSON object. Set unused flags to null.

这条 Prompt 看起来平平无奇，但它在四个维度上都有约束：「角色 = CLI 助手」「行为 = 翻译为结构化调用」「输出格式 = 唯一 JSON」「边界 = 未用字段须为 null」。这是工业级 System Prompt 与玩具级 Prompt 的分水岭——后者只写"请帮我处理 CLI 请求"。

适用场景：业务边界清晰、可用自然语言描述完整、原型阶段需要快速迭代。

边界 / 反模式：

复杂推理链一定会掉：Prompt 越长，模型越倾向于"漏看"中间步骤。
格式稳定性差：再多的 “ONLY a JSON object” 也压不住偶发的解释性前缀。
绑定模型：换一个厂商或新版本，几乎所有效果数据要重测。

如果你的团队连 System Prompt 都还没沉淀成版本化文件，先把这个做完，再谈训练。

2.2 RAG：解决"知识"问题，不解决"推理"问题

RAG 的常见误读是把它当万能补丁——“模型不会就喂资料”。原文给的定位很冷静：RAG 加的是新信息，不是新推理能力。它解决的是基模训练截止日之后的、私有的、变化频繁的知识，不解决"模型读了资料但读不懂资料"的问题。

正在发生的演进是 Agentic RAG——让 Agent 自己决定检索什么、什么时候要重新表述查询、信息够了没有。这等于把 RAG 从"管道"升级成"小循环"，配套的代价是延迟和上下文窗口压力。

适用场景：

知识库变化快（产品手册、政策法规、内部 wiki）
需要降低幻觉、要求来源可追溯
不接受为知识更新去训练的成本

边界：检索延迟、上下文窗口约束、推理短板补不上。

2.3 Tool & Skill Injection：让 Agent 真正"动手"

到这里就开始触及 NVIDIA 这篇文章里最值得划重点的工程构件——Skill。

把一个 Skill 看作 Agent 的"领域说明书 + 配套工具包"：里面有指令、脚本、模板、范例。它和 Tool 的区别是：Tool 是函数调用，Skill 是一整套关于"什么时候、怎么、按什么顺序用工具"的领域知识。

下面这张图把 SKILL.md 的结构和一次完整调用流拆了开：

Skill 解剖：从目录结构到一次调用

原文给的事故分诊（incident-triage）Skill 长这样：

skills/
  incident-triage/
    SKILL.md            ← 入口：Purpose / When to Use / Inputs / Outputs / Workflow
    README.md
    scripts/
      collect_logs.sh
      parse_logs.py
      summarize_findings.py
    templates/
      triage_report.md
    examples/
      sample_incident.json

这种结构化的好处不在"代码组织得整齐"，而在三件事：

Skill 是上下文里的一段说明书，但实际执行落在脚本上——避免把整段日志塞进 Prompt。
Skill 可被 Agent 自己挑选——多个 Skill 共存，模型按照 SKILL.md 的「When to Use」决定调用哪个。
Skill 是可分享的对象——团队 / 公司内部能像沉淀代码库一样沉淀 Agent 能力。

bash scripts/collect_logs.sh \
  --service payments-api \
  --start "2026-03-05T10:00:00Z" \
  --end "2026-03-05T11:00:00Z" \
  --env prod \
  --out ./out/raw_logs.txt

边界：模型本身要具备 tool-calling 能力；复杂编排（多步、回滚、错误处理）只靠 Skill 描述会脆弱，往往得配合下一档的 SFT 才能稳定。

经验法则：Tool 决定能做什么，Skill 决定怎么做对。能用 Skill 解决的，先不要去训。

三、训练时双柱：SFT 与 PEFT

走到这里，才真正开始动模型本身。

3.1 SFT：教模仿，不教判断

SFT 的逻辑很朴素——给模型看一堆「输入 → 理想输出」配对，让它学会复刻这种映射。常见数据形态是「自然语言请求 → 结构化 JSON 工具调用」。

原文反复强调的一点：低资源领域可以用合成数据生成（SDG, Synthetic Data Generation）启动。NVIDIA NeMo Data Designer 这类工具让团队定义 schema 后用 LLM 批量生成多样化训练对。这意味着 “我们没有标注数据"已经不是不能做 SFT 的理由——但合成数据本身也会带来分布偏移和判断偏置，必须配抽样人审。

适用场景：任务定义清晰、有可枚举的输入输出范式、追求结构化输出稳定性。

边界：

数据质量是天花板——SFT 学不到比训练数据更好的判断；
易过拟合 / 灾难性遗忘——数据多样性不够时，模型在通用能力上会反向退步；
重训练即需多卡，全参 SFT 单次成本不小。

SFT 通常是定制化流水线的第一个训练动作——它建基线，下面更精细的对齐方法在它的基础上微调。

3.2 PEFT：基模做底，外挂可换

参数高效微调（PEFT, Parameter-Efficient Fine-Tuning）是过去两年工程取舍上的最大红利。最常见的是 LoRA / QLoRA：

LoRA 在 Attention / FFN 层注入小规模可训矩阵，冻结原始权重，只训这部分。形象点说，它是给基模做了一个可插拔的外挂——同一个基模上挂不同的 LoRA 适配器，就能服务不同的客户、不同的任务、不同的领域。
QLoRA 在 LoRA 之上把基模量化到 4-bit，让原本要多张高端卡的微调缩成单卡可跑。

原文给的例子很直观：NVIDIA Nemotron 3 Nano 总参 30B、激活参数约 3.5B，在 LoRA 加持下，业务方不需要管理多份 30B 模型副本，只需要管理多份小适配器文件。

适用场景：

GPU 资源受限的中小团队
需要为多种业务 / 多种客户维护多版本模型
快速迭代实验

边界：可塑性的天花板低于全参微调——只能改一小撮权重，所以"行为变化幅度"是受限的。

实战上的判断：先用 LoRA 验证「能不能学」，再决定要不要上全参 SFT。多数业务任务上，LoRA + 高质量数据已经够好。

四、对齐与强化四件套：DPO、RLHF、RLVR、GRPO

进入这一档，意味着你的目标已经不只是"输出格式正确”，而是"在多个合法答案之间，模型挑得是不是最好的那个"或"模型的推理能不能逼近客观正确"。

4.1 DPO：用偏好对取代奖励模型

直接偏好优化（DPO, Direct Preference Optimization）的核心创新是不再训一个独立的奖励模型。它的训练数据是一组组偏好对——同一个输入下，「更好的回答」与「更差的回答」配对。损失函数是 pairwise contrastive loss，目标是最大化 preferred 相对 rejected 的对数概率。

# 伪代码示意：DPO 损失（核心）
def dpo_loss(policy, ref_policy, batch, beta=0.1):
    # batch: (prompt, chosen, rejected)
    log_pi_chosen   = log_prob(policy,     batch.prompt, batch.chosen)
    log_pi_rejected = log_prob(policy,     batch.prompt, batch.rejected)
    log_ref_chosen   = log_prob(ref_policy, batch.prompt, batch.chosen)
    log_ref_rejected = log_prob(ref_policy, batch.prompt, batch.rejected)

    # 关键：相对于参考策略的偏好优势
    chosen_advantage   = log_pi_chosen   - log_ref_chosen
    rejected_advantage = log_pi_rejected - log_ref_rejected

    return -F.logsigmoid(beta * (chosen_advantage - rejected_advantage)).mean()

为什么这样算？因为这等价于优化一个隐式奖励——只要 preferred 在策略下相对于 ref 的"得分"涨幅高于 rejected，损失就在下降。不需要显式训练一个奖励模型，省下了 RLHF 里最重的一坨基础设施。

适用场景：质量是主观的（语气、风格、helpfulness、safety）；多个合法输出但确有优劣；在 SFT 之后做风格 / 安全微调。

边界：

偏好对的质量决定了一切——LLM-as-judge 生成的偏好数据容易把 judge 的偏置直接焊进模型；
对"客观正确性"任务（比如 JSON schema、代码执行）效果不如下面的 RLVR。

4.2 RLHF：经典但越来越重

RLHF 是上一代的"准答案"——人类标注偏好 → 训奖励模型 → 用 RL 让策略最大化奖励，同时通过 KL 项防止偏离原行为。

原文给的态度很务实：复杂、训练不稳、奖励黑客风险高、人工标注昂贵。在多数业务场景里，DPO 已经能拿到 70% 的效果，把剩下的 30% 交给 RLHF 通常不划算。

一线判断：默认不要碰 RLHF。除非你有大公司级别的标注预算 + 训练稳定性团队。

4.3 RLVR：给 Agent 装"单元测试"

可验证奖励的强化学习（RLVR, Reinforcement Learning with Verifiable Rewards）这个名字写得朴实，但理念是这一代 Agent RL 里最关键的一跳——当任务的正确性可以用代码判定时，奖励信号就不再需要从模型里学，而可以直接由验证函数确定性地给出。

最典型的例子：把自然语言翻成 CLI 命令。原文给的验证函数大致是这种结构：

def cli_verify(model_output: str, ground_truth: dict) -> float:
    try:
        pred = json.loads(model_output)
    except json.JSONDecodeError:
        return -1.0                               # 非法 JSON：直接惩罚

    if pred.get("command") != ground_truth["command"]:
        return -1.0                               # 命令不对：直接惩罚

    # 命令对了，按 flag 命中比例给部分分
    expected = ground_truth["flags"]
    matched  = sum(1 for k, v in expected.items()
                     if pred.get("flags", {}).get(k) == v)
    if matched == len(expected):
        return 1.0                                # 完全匹配
    return matched / max(len(expected), 1) * 0.8  # 部分匹配

为什么 RLVR 是质变而不是量变？因为它把"评测"和"训练"合二为一了——同一个 Verifier，离线时算指标，在线时给奖励。模型不再靠"模仿好回答"提升，而是被持续推向"通过验证"。这正是 DeepSeek-R1 在数学和代码推理上拿到突破的核心机制——有些时候甚至不需要 SFT 起步，直接用 RLVR 就能从零教出思维链。

NVIDIA 这边对应的工具栈是 NeMo Gym（提供验证端点）+ NeMo RL（大规模 RL 训练），把"写 Verifier→挂端点→训练"这条链路做成了能跑大模型的基础设施。

适用场景：输出客观可验证（JSON schema、CLI、代码、数学题、tool-calling）；需要可审计、可重复的奖励信号；想让推理深度跨越式提升。

边界：

任务必须有确定性的对错——不适合开放式生成、内容创作；
验证函数本身设计得不好，模型会找到"看起来对但实际错"的捷径（reward hacking 的另一种形态）；
验证基础设施本身的工程量不小。

反常识结论之一：对一个垂直业务来说，“能不能写出 Verifier"几乎等价于"能不能从 RLVR 里拿到红利”。先评估这个，再决定要不要走 RL 路线。

4.4 GRPO：用"组内归一化"取代 critic 网络

群体相对策略优化（GRPO, Group Relative Policy Optimization）和 RLVR 是天作之合。它的核心创新是把 PPO 里的 critic 网络扔了，用一种更朴素的方式计算 advantage——对同一个 prompt 采 N 个回答（典型 4–64 个），把每个回答的奖励减去组内均值，再除以组内标准差。高于平均的拉上去，低于平均的压下来。

GRPO：用"组内归一化"取代 Critic 网络

为什么这样算？

PPO 的 critic 自身要学，本身是不稳定来源——critic 估错，advantage 就估错，整个训练就漂。GRPO 用同一个 prompt 下其它样本的实际奖励作为 baseline，baseline 不再来自一个学习中的模型，而来自当前 batch 的统计量，稳。
离散 / 稀疏奖励下 critic 难学——RLVR 给的是 +1 / 部分分 / -1 这种离散信号，本来就不适合让 critic 拟合。组内归一化天然避开了这个问题。
天然的 variance reduction——减均值除标准差，本身就是经典的方差缩减技巧。

代价也很直白：每个训练 step 都要采 N 个样本，单步计算量比 SFT 之类高一个数量级；组太小（N=2/3）时 baseline 会很噪。GRPO 的组大小不是默认参数，是要调的——这是不少团队第一次跑 GRPO 时踩的最大的坑。

反常识结论之二：SFT → DPO → RLVR 这条经典管线，并不是固定配方。原文明确说「ordering is a design choice, not a fixed recipe」。如果你的任务一开始就高度可验证（比如代码生成 + 单元测试反馈），完全可以跳过 SFT，直接 RLVR + GRPO，DeepSeek-R1 就是这样做的。

五、多阶段流水线：SFT → DPO → RLVR 的真实组合拳

把上面的所有技术按时间线串起来，就是 NVIDIA 推荐的 5 阶段流水线：

多阶段流水线：从 Prompt 起步，按需爬到 RLVR

每一阶段都有自己的"投入 / 产出 / 风险"三联表。这里挑几条容易被忽略的工程经验：

Stage 1 是评测集的产出阶段，不是只产出"能跑通的 Agent"。如果 Stage 1 走完没沉淀出版本化的 Prompt、Skill 库和评测集，后面所有训练都在盲打。
Stage 2 的 SDG 不是免费午餐。LLM 生成的训练对会带 judge 偏置和分布偏移，抽样 5%–10% 做人工审核几乎是必选项；预算不允许就别上 SDG，老老实实用真实数据 + 主动学习。
Stage 3 的 SFT 优先用 LoRA。除非你真的要教模型一种全新的输出范式（比如新的 DSL），全参 SFT 在性价比上往往不如 LoRA + 数据扩增。
Stage 4 的 DPO 与 RLVR 不是二选一。常见模式是「DPO 先把风格 / 安全 / 格式稳住，RLVR 再去啃硬推理」；但也常见到反着做的——先 RLVR 让模型学会"做对"，再 DPO 让模型学会"做得人看着舒服"。顺序看你的瓶颈在哪。
Stage 5 不是"做完才做"。评测集应当从 Stage 1 就开始攒，每个阶段都跑完整套指标——否则你不知道是 SFT 提升了还是 DPO 提升了，进而不知道下次该加深哪一步。

NVIDIA 给的指导原则一句话总结：“Start lightweight, measure rigorously, add complexity only where data shows it’s needed.” 翻译成工程语言——没有评测就不要训，能用 Prompt 解决就不要做 SFT，能用 SFT 解决就不要做 RLVR。

六、三轴选型决策：任务、资源、成熟度

到这里，我们终于可以回答开头那个问题：“在我的业务里，应该走到哪个梯度，再不要往下了？”

NVIDIA 给了三个判断轴——任务可验证性、可用资源、项目成熟度。把它们交叉成 4 个象限，每个象限给出推荐技术组合：

三轴选型决策矩阵

读这张图的方法：

象限 A（早期 + 主观）：你正在做一个内容生成 / 客户沟通类 Agent，没几张 GPU、还没沉淀评测。别想着搞 DPO——先把 Prompt + Skill + RAG 搞稳，把评测集和 Trajectory 日志先建起来。这一阶段做训练就是在赌，赌赢了也不知道为什么。
象限 B（早期 + 可验证）：业务任务是结构化输出（JSON、CLI、代码、SQL），首要动作是写 Verifier——不管你最终走不走 RLVR，Verifier 本身就是最好的离线评测器，是未来一切训练的入场券。
象限 C（成熟 + 主观）：评测稳了、有偏好对（来自人审或 LLM judge + 抽样），就走 LoRA-SFT → DPO 这条线。重点不是技术选型，而是偏好对的质量治理——judge 提示词、抽样比例、对抗样本比例都要管。
象限 D（成熟 + 可验证）：可以走完整管线 LoRA-SFT → DPO → RLVR + GRPO，配 NeMo Gym 类的验证基础设施。这个象限里最大的风险不是技术不会用，而是 GRPO 组大小、KL 系数、奖励函数设计这些"小细节"调不对——同一份代码，组大小从 8 调到 32，效果可能差一倍。

一句话决策启发：任务能不能写 Verifier，比"团队有几张卡"更能决定你的技术路线。

七、给一线工程师的两周行动清单

这一节是给"明天就要开始干"的人准备的。五个动作，每一个都能在两周内启动，且彼此独立——做完任意一个都能拿到信号，不用等到全做完才看效果。

建一份 100 条规模的 Trajectory 评测集（Day 1–3）
不是问答对，是「用户输入 + 期望工具调用序列 + 期望最终输出」三元组。100 条的体量足够你做 A/B，太多反而拖慢迭代。来源：线上日志抽样 + 人工补全 + 反例挖掘。
挑一个"可写 Verifier 的"小任务做 LoRA 试点（Day 4–8）
优先选输出是 JSON / CLI / SQL 的任务。先写 Verifier（哪怕只有 30 行 Python），跑一遍当前模型的离线得分；再用 Verifier 自动构造训练对（接受 = 高分样本，拒绝 = 低分样本），上 LoRA 跑一轮 SFT，看离线得分能不能涨 10 分以上。涨不了就回去检查 Verifier。
沉淀 1–2 个 Skill 模板（Day 5–10）
选你团队里复用频率最高的 Agent 任务（事件分诊、需求拆解、代码 review、合规初审都可以），按 NVIDIA 给的 SKILL.md 结构（Purpose / When to Use / Inputs / Outputs / Workflow + scripts / templates / examples）整理成一份目录。关键不是模板长什么样，而是把"这类任务怎么做对"的隐性知识显性化。
跑一次 SFT vs DPO 对照实验（Day 8–12）
同一个 LoRA 基线，用同一份训练数据：一份 SFT，一份 DPO（用 Verifier 或 LLM judge 生成偏好对）。在你 Day 1–3 建的评测集上对比。如果 DPO 没有显著优势，说明你的偏好对质量有问题；如果差距很大，说明业务任务确实是"主观质量"型，下一步就该投资 judge 治理。
把上面 4 步的产物挂到 CI（Day 13–14）
评测集、Verifier、Skill 模板都进版本库；每次 Prompt / 模型 / Skill 更新，CI 自动跑一遍评测；指标回退就阻断合入。这是把"AI 工程"变成"软件工程"的关键一步——没有这一步，前面所有努力都会被下一次紧急上线吞噬掉。

结语：你无法改进无法度量的东西

这篇 NVIDIA 的导读最大的克制之处，是它没有把 9 种技术包装成"必走的一条路"，而是反复强调一句话：

“You can’t improve what you can’t measure.”

定制化是一段梯度，不是一道选择题。绝大多数业务团队的现实约束不是"该选 DPO 还是 RLVR"，而是"我的 Agent 现在到底好不好，我都说不清"。所以最贵、最容易被低估的那个动作，从来都是同一个——把评测做对。

剩下的 9 种技术，都是评测体系起来之后的工程选型。Prompt 和 Skill 是地基，SFT 和 LoRA 是承重墙，DPO 和 RLVR 是装修。地基没打就上承重墙，再昂贵的装修也救不回来。

如果你只能从这篇文章里带走一句话，那就是：先建评测，再选技术；从最浅的梯度开始，让数据告诉你下一步该往哪走。

延伸阅读：

配套博文：Mastering Agentic Techniques: AI Agent Evaluation 把这里跳过的"评测"那一半补上。

NVIDIA NeMo 开源工具链（NeMo Data Designer / NeMo RL / NeMo Gym / NeMo Agent Toolkit）是落地这条管线的现成工具。

DeepSeek-R1 的论文是理解 RLVR + GRPO 不可绕过的一篇。

「真诚赞赏，手留余香」