Agent开发和算法有何区别？业务迭代全解析

一、离线评测体系的搭建与迭代

不少算法实习生的第一份正式工作，就是打磨离线Benchmark的可靠性。举个例子，审核学术论文的标准本身天然带有主观性，很难直接通过机器一步完成评估，因此通常会拆分为写作规范性、创新性、实验完整性等多个维度，再分别定义不同维度下高分、低分的具体标准，让评估尽可能可量化可执行。这一套标准就被称为Rubric，其本质是将模糊的业务目标，翻译成能够被非专业人员、大模型或程序稳定执行的评价准则。这和Agent将模糊的自然语言目标拆解为可执行的计划与动作十分相似：前者是将“我需要什么”转化为可评估的条件，后者是将“我需要什么”转化为可执行的步骤，二者都是在将模糊的业务目标转化为可落地的标准化流程。类似Codex、Claude Code这类工具，也是将模糊的自然语言目标翻译为可执行的代码。

1. 人工作为评判基准

当我们制定好Rubric后，首先需要由自己或业务专家按照标准校验少量样本，验证Rubric本身是否能够被稳定执行。通常的做法是先选取一批样本进行人工标注，查看不同标注者之间的一致性率。如果同一个案例，两名标注者按照同一套Rubric仍然经常得出不同结论，那么问题往往不是标注者的问题，而是Rubric本身还不够清晰，需要进一步拆分标准、补充边界案例。人工标注是最可靠的校验方式，但缺点是速度慢、成本相对较高，无法实现规模化。因此在确认人工标注可行后，我们就可以开始探索如何让大模型来替代人工完成标注工作。

2. 大模型作为评判基准

这一步的目标是让大模型尽可能复现已经稳定下来的人工判断逻辑。一般的流程是先用高质量的人工标注数据作为基准真值，通过手工或自动化的Prompt工程不断调整评判Prompt，同时优化温度、top-k、top-p等超参数。当人机一致率达到较高水平时，说明离线Benchmark已经初步可用，此时就需要结合线上真实业务指标进行验证。如果出现离线指标上涨但线上没有变化的情况，问题不一定出在策略本身，也可能说明Benchmark本身没有对齐真实的业务目标，需要根据线上的Bad Case和后验数据去更新样本、Rubric和评判逻辑。需要注意的是，Benchmark本身并非一次性完成的工作，而是需要随着业务一起持续迭代，由于大模型本身泛化能力较强，跟随业务迭代的成本并不高。

随着Benchmark、实验以及RL rollout的规模不断扩大，每次评测都调用大模型的成本和时延会逐渐变得难以接受，这时我们就需要考虑进一步优化评测流程。

3. 奖励模型作为评判基准

既然我们已经通过大模型作为评判完成了自动化评测，为什么还要训练奖励模型（RM）来做评判呢？因为大模型评判虽然解决了自动化的问题，但并没有解决规模化评测的问题。当评测规模线性增长时，每次调用大模型的成本和时延也会随之增加，而且很难通过缩短Prompt长度来优化这一问题。因此我们可以将已经验证过的评价标准蒸馏为一个低延迟、高吞吐的奖励模型。

大模型评判的优势是泛化能力强，而奖励模型只需要在业务对应的特定数据分布中表现足够优秀即可，因此理论上可以使用更小参数的基础模型，并用之前积累的评测数据来进行训练。当然，奖励模型也存在Reward Hacking的问题，因此不能将其视为永远正确的评判标准，还是需要定期通过人工和大模型评判来检测新的Bad Case，补充标注数据后重新训练和校准奖励模型。这整个过程也是一个规模化的迭代路径：Rubric定义什么是“好”，人工标注积累判断经验，大模型评判将人工判断自动化，奖励模型再将自动化评判进一步规模化。

二、Agent策略的分层迭代路径

开发Agent策略本质上就是在构建先验知识，再根据上线后的实际效果将后验数据转化为新的先验知识，实现数据驱动的迭代。具体的Agent策略开发流程，我认为通常都是从仔细打磨Prompt开始的。

1. Prompt策略优化

根据和多位行业从业者交流的经验，大部分业务场景下，根据专家先验知识调整好Prompt就可以先上线一个基础版本，再根据上线效果来规划后续的优化路线。一个合理的开发流程应该遵循以下步骤：

• 先用纯Prompt跑通最小的业务闭环；
• 系统性分析Prompt到Response流程中出现的Bad Case；
• 通过RAG、Few-shot、CoT等经典手法逐步逼近效果上限；
• 在进行Prompt优化的同时，同步优化离线Benchmark。

很多人低估了通过Token投入换取Prompt精准度的潜力，随着大模型能力的不断增强，很多看似难以处理的案例，其实只是Prompt没有写到位。那么如何系统评估Prompt是否还有优化空间呢？我们可以尝试进行Prompt梯度测试：在同一批样本上逐步增强Prompt的复杂度和针对性，观察效果是否持续提升。具体的迭代顺序可以参考以下步骤：

• 先用最简单的指令横向对比多个基础模型，选择最适配业务的模型；
• 根据专家先验知识添加System Prompt，对齐业务的具体要求；
• 拆分工作流来强化Prompt工程，比如手动或自动添加上下文信息，让模型获得更多参考依据。

如果随着Prompt的逐步优化，效果始终没有明显提升，说明针对当前业务场景，Agent策略的Prompt优化已经到达瓶颈，此时就可以进入下一步的大模型策略优化。

2. 大模型策略优化

大模型策略并非为了替代Agent策略，而是将Agent策略中已经验证有效的非参数化先验知识，训练为模型的参数化行为。Agent阶段是通过Prompt、上下文、工作流来明确告诉模型应该如何执行任务；而大模型策略阶段则是让模型自主学会应该如何执行任务，既可以减少每次都需要传递Prompt的成本，同时还能进一步提升效果和稳定性。

当我们在Agent开发过程中遇到效果、稳定性或成本瓶颈时，就可以考虑进入大模型策略阶段，将Agent策略已经验证有效的60分基础方案，优化得更稳定、更低成本、更具备规模化能力。

(1) 监督微调（SFT）

监督微调的核心是将Agent策略中已经验证有效的先验知识，固化为模型稳定的行为模式。比如在Agent开发过程中，我们可能已经验证了以下几点：有效的任务理解方式、能够明显提升效果的Few-shot示例、更稳定的工具调用逻辑、更符合下游要求的输出格式、更符合业务预期的拒答边界。

这些内容一开始都可以写在Prompt和工作流中，但如果它们已经经过Benchmark验证，且属于高频、稳定、长期不会频繁变化的规则，就可以考虑通过SFT将其固化到模型参数中。因此在进行SFT之前，最重要的问题就是：哪些Agent阶段学到的经验，真正值得被固化进模型？

一个可以参考的原则是：高频变化的信息继续保留在上下文中，而长期稳定的行为模式才值得固化到模型参数中。比如实时库存、活动规则、最新政策这类高频变化的内容，即使非常重要，也不适合固化到模型中；而固定的输出习惯、稳定的业务SOP、工具调用方式、任务拆解范式，则适合进行参数化固化。

因此SFT的难点在于数据质量。其本质是告诉模型“遇到这种情况，就应该这么做”，如果同一种业务场景下，一部分数据要求拒答、一部分要求正常回答，一部分要求严格的JSON格式、一部分允许自由文本，一部分要求先调用工具、一部分直接依靠模型内部知识回答，那么模型学到的不是灵活的处理能力，而是行为的不确定性。因此我认为SFT的数据清洗并非单纯清洗低质量答案，而是在整理模型最终的行为分布。这也是为什么SFT的数据并非越多越好，更重要的是数据的质量和行为的一致性。未经过Benchmark验证的Prompt优化技巧，不能因为看起来有效就直接扩充到训练数据中，否则只是将一个尚未想清楚的策略永久写入了模型参数。

(2) 强化学习（RL）

监督微调是教模型参考标准答案来获取好的结果，而强化学习则是放大好的结果，让模型自主探索最优的解决方案。

前面提到SFT的难点在于数据质量，而RL的难点则在于反馈信号的准确性。这也是为什么我们之前花费大量时间搭建Benchmark体系：到了RL阶段，Benchmark不仅仅是测试工具，更是重要的反馈来源。Rubric定义了什么是“好”的结果，评判模型判断结果的好坏，这一判断可以直接转化为RL阶段的Reward信号，直接影响模型的优化方向。

RL的难点也正在于此：如果我们的Reward信号没有对齐业务的真实需求，比如Rubric没有对齐业务目标、评判模型没有准确复现人工判断、Reward只是离线指标的近似值，那么在RL阶段，模型无论学好还是学坏都是在学习，离线Reward指标的上涨并不一定等同于线上业务指标的提升。因此最终还是需要回到线上业务指标：上线获取新的用户后验数据，再用这些数据更新Benchmark、收集Bad Case、修正Rubric、调整训练数据和Reward信号，从而进入下一轮的迭代循环。

总结来说，Agent阶段积累专家先验知识，SFT将稳定的先验固化到模型参数中，RL则将业务的评价标准转化为Reward信号，让模型朝着业务目标持续优化。Reward设计得合理，模型会更稳定地朝着业务目标优化；如果Reward设计错误，模型会更极致地学习到错误的行为模式。

三、行业讨论与思考

最后分享一些关于大模型策略的有争议但或许有价值的讨论观点：

• 关于过拟合的争议：有人认为模型存在过拟合的风险，也有人认为只要训练数据覆盖了真实的业务场景，过拟合反而正是我们想要的目标；
• 关于灾难性遗忘的讨论：有人担心微调会导致模型出现灾难性遗忘的问题，也有人认为遗忘的过程其实是一种数据提纯的过程；
• 关于工作流与微调的争论：从事Agent开发的从业者认为，工作流才是通往AGI的正确道路，而参数微调只是无意义的参数内卷，无法带来真正的突破；
• 关于模型能力边界的观点：从事AIGC相关工作的从业者则认为，真正决定应用效果上限的，始终还是大模型自身的能力边界。