先说个很常见的情形。有人拿一个 Agent 试了几轮，发现它答业务问题时经常说不到点上，于是下结论：「这模型不行，得微调一个。」然后在群里问：微调一个要多少钱，数据要准备多少条。
这个提问方向本身就有问题。绝大多数「答不准」，根因不在模型权重，而在提示词没写清楚、该给的资料没给到。微调是三条路里最贵、最慢、最难回退的一条，上来就选它，等于感冒先上化疗。
这篇不讲论文，只讲一件事：当 Agent 表现不够好时，怎么判断该动哪一层。
先把三条路摆清楚：它们改的根本不是同一个东西
提升 Agent 能力，能动手的层只有三层，顺序不能乱：
- 第一层，改提示词——改「怎么问」。通过系统指令、角色设定、输出格式约束、少量示例，把任务说清楚。它是唯一能做到「改完立刻见效、不满意随时回退」的手段，成本几乎为零。
- 第二层，外挂知识库——改「给它看什么」。把企业文档、产品资料、历史问答整理进检索系统，让 Agent 在回答前先查到证据。它解决的是「模型不知道你公司的事」，也就是知识缺口。落地方法见 知识库检索怎么做才准确，底层选型见 嵌入模型和向量库怎么选。
- 第三层，微调权重——改「它本身是什么」。用你提供的样本再训一轮，把新的行为模式写进模型参数。它改变的是模型的表达习惯和判断倾向，而不是临时读到的事实。
这三层不是替代关系，而是优先级关系。正确顺序永远是：先把第一层做到位，再补第二层，最后才考虑第三层。跳过前两层直接微调，通常的结果是花了几万块，问题还在。
每一层分别能解决什么、解决不了什么
改提示词能解决：任务边界模糊、输出格式不固定、语气风格不对、没按要求用工具、步骤顺序乱。这些都是「知道该怎么做，但没说清楚」型问题。
改提示词解决不了：模型压根不具备的知识（它没见过你公司的退货政策）；需要大量专业判断的领域推理（比如复杂条款的法律定性）；以及格式反复不听话到示例也救不回来的情况。
外挂知识库能解决：事实型问题（我们的产品保修几年、这个型号支持哪些协议）；需要引用出处的回答；以及知识更新频繁、来不及训练的场景——改文档比改模型快得多。
外挂知识库解决不了：行为的稳定性问题。你可以把正确知识喂进去，但模型可能检索到了却不用、用错了、或者把三个文档的内容混着编。检索准不准是一回事，拿到正确上下文之后能不能稳定按你要的方式作答，是另一回事。检索到的内容进上下文之后怎么排、怎么约束，属于 上下文管理 的范畴，这部分做不好，知识库再准也白搭。
微调能解决：固定的输出格式和结构（比如始终输出某种 JSON 结构、始终按特定模板写报告）；特定领域的话术与判断倾向（比如客服语气、行业术语的固定用法）；把「每次都要写一大段提示词」压缩成模型的内置能力，从而降低单次调用成本；以及需要极高一致性的分类与抽取任务。
微调解决不了：知识时效性。今天微调进去的价格，下个月变了，你得重新微调一遍——而知识库改一行文档就行。也解决不了「模型本来就不会推理」的问题：微调教的是风格与模式，不是智力。
什么时候才轮到微调：六个信号
把下面这几条当清单，满足两条以上再认真评估微调，满足三条以上基本就可以动手了：
- 提示词已经改到第三版以上，问题依旧。如果换了几种写法、加了示例、明确了格式，表现还是不稳定，说明约束力已经到顶了。
- 问题不是「不知道」，而是「知道却不照做」。知识库检索已经能返回正确内容，但模型依然不按你要的方式组织回答——这是行为问题，不是知识问题。
- 输出格式要求严格且高频。每次都要精确符合某套结构，靠提示词只能做到八成，而那两成不达标就不能进下游系统。
- 每次调用都要塞很长的提示词，成本已经压不下来。如果为了稳定表现，每次请求都要带几千字的指令和示例，那这笔钱长期烧下去很可观。微调可以把这部分固化进权重，换来更短的上下文。算成本可以借用 Token 成本怎么算怎么省 里的框架。
- 领域语言有明显特殊性。专业术语的固定表达、行业内的隐含约定，靠通用模型容易说「外行话」，且提示词难以穷举。
- 同类任务量足够大、足够重复。微调是一次性投入、长期摊薄的生意。任务量太小，投入永远摊不回来。
反过来，出现下面任一情形，就别微调：知识经常变（该做知识库）、只有几百条任务（提示词就够了）、团队没有评测能力（无法判断微调后是变好还是变坏）。最后一条尤其重要，见下。
真要微调，先分清三种做法
「微调」不是一个动作，而是一组方法，成本差几个数量级：
- 全参微调。把模型所有权重都更新一遍。效果上限最高，但对数据量、显存、训练时长要求都最高，且容易遗忘原有能力——训完可能专业任务变好了，通用能力却掉了。适合有充足高质量数据、且需要大幅改变模型行为的大规模场景。
- LoRA（低秩适配）。不动原权重，只额外训练很小一部分参数。显存需求大幅下降，训练快，产物体积小（几百 MB 级别，而不是几十 GB），可以按场景挂载不同的适配层。这是绝大多数团队该走的路，也是当前实践中的默认选项。
- QLoRA / 量化后微调。先把基座模型压缩到低精度，再在其上做 LoRA。显存门槛进一步降低，单卡也能跑动更大参数的模型，代价是速度慢一些、精度略有折损。适合硬件资源紧张但想试的团队。
一个实用的判断：除非你明确知道自己需要全参微调，否则都用 LoRA 起步。LoRA 的好处不只是省资源，更重要的是它可以独立打包和卸载——效果不好，把它摘掉就回到原样，风险可控。
数据：不是越多越好，是越像越好
关于微调数据，三个最实际的结论：
- 质量远比数量重要。几百条精心标注、覆盖真实分布、格式统一的样本，效果常常胜过几万条从日志里直接捞出来的脏数据。后者会把噪声一起训进去。
- 样本必须和你线上遇到的情况同分布。如果线上用户大量用口语化、错别字、中英混输的方式提问，而你拿的是规整的书面语样本，训出来的模型上线就会水土不服。
- 一定要留出验证集，而且要提前留。不能训完再挑好看的例子来自证。验证集要覆盖典型场景和边界场景，用它判断「到底有没有变好」，方法和 Agent 评测怎么做 是一套东西。
还有一条容易被忽略的：样本里必须包含「不该做什么」的示例。只教它怎么答，不教它什么时候该拒绝、什么时候该转人工，训出来的模型会在不该回答的问题上自信地胡说。
三个最常见的误区
误区一：「微调能让模型记住我们公司的资料。」这是最普遍也最贵的误解。用文档去微调，模型学到的不是「某条事实」，而是「这类文字的写法」。你问具体的保修年限，它可能给你编一个格式很像但数字不对的答案。事实类知识放知识库，是唯一可靠的路径。
误区二：「微调能治幻觉。」恰好相反。微调会提升模型在训练数据分布上的自信程度——包括那些它其实不确定的地方。如果数据本身有问题，微调会把幻觉从「偶尔乱说」变成「笃定乱说」，更难被发现。
误区三：「微调是一次性的，做完就完事。」模型有版本，基座会升级，业务在变化。你微调出来的适配层需要跟着基座升级重新验证——如果基座从旧版本换到新版本，之前训好的 LoRA 很可能效果打折。这件事的工程管理方式和 模型版本切换前跑回放验证 完全一致：每次换基座或换适配层，都要拿同一批固定样本跑一遍对比，而不是凭感觉说「好像差不多」。
微调的安全与合规，别漏掉
微调用的数据往往包含真实业务内容，这里有两道必须过的关：
- 数据脱敏。训练样本里的客户信息、内部编号、价格底价，进训练集之前要处理掉。训进去的模型权重是很难「删掉某条数据」的，只能整体重训。
- 产物的权限边界。适配层文件本身要有归属和访问控制，不能谁都能下载。如果多个团队共用一套推理服务，加载哪个适配层、谁能切换到哪个，需要有明确规则，思路参考 Agent 权限管理。
另外，微调前后要留痕：用了哪批数据、哪个基座、什么参数、评测结果如何。这样出了问题时能追溯，思路见 证据包怎么留。
适合人群与决策建议
现在就别碰微调：刚起步验证想法的团队；知识更新频繁的业务（客服政策、商品价格、活动规则）；日均任务量只有几十次的场景。这些情况把提示词和知识库做扎实，收益比微调高一个量级。
可以考虑微调：已经有稳定的提示词和知识库、但被格式一致性和成本卡住；同类任务每天上千次；有明确的评测集能判断好坏；有专人能维护数据。
该认真评估全参微调：模型要嵌入到自己的产品里长期运行、对领域表现有硬要求、且有能力承担训练和运维成本的团队。
如果连本地部署的可行性都还没摸清，先看 本地模型怎么接 把环境跑通，再谈微调不迟。
一句话收尾：微调是最后一层，不是第一层。它的正确用法是「把已经稳定的行为固化下来」，而不是「用来补一个还没设计好的流程」。把提示词和知识库做扎实，你会发现需要微调的场合比想象中少得多——真到需要的那天，你也已经有能力判断该微调什么了。
