在做垂直领域 Agent 落地时，踩到的最大坑不是“模型不够聪明”，而是不够稳定。 同样的输入，在多轮对话和复杂上下文（RAG、多工具返回、多步骤流程）下，模型会出现:
- 该调用工具不调用
- 调用了但参数不对
- 甚至在多轮对话中直接编造工具返回结果
对于“要端到端自动跑通”的业务流程来说，这类不确定性会导致整体一次通过率很难过 50%。
最初尝试过用更大的模型（如 Qwen3 235B、DeepSeek V3.1 671B）配合 Prompt/Context Engineering 去“优化流程”，但实践中发现：
- 当上下文越做越长、链路越做越复杂时，优化很难系统化复用
- 在某条路径上变好，不保证在更多轮次、更多工具返回格式、更多输入变体上依然稳定。
因此尝试了新的思路：用参数更小、推理成本更可控的 Qwen3-8B，把关键能力（领域理解 + 工具调用契约）通过后训练固化进模型。
具体做法分两阶段：
- SFT：先把垂直领域背景知识、业务流程、字段含义注入，让模型“懂业务”；
- DPO：再专门对齐工具调用偏好（何时调用、调用哪个函数、参数怎么填、如何解读返回），让模型“守规矩”。
结果：
- SFT 后工具调用指标短期并没有变好（甚至略降），但回答开始贴近业务领域；
- 在扩大 DPO 数据覆盖（从 v1 到 v2，数据集扩大到原来的 5X）后，工具调用相关指标从约 30% 级别提升到约 97%～99% 级别；
- 在多轮对话与“think/推理能力”上做抽查回归，未发现明显损坏。
训练资源： SFT 用 1 张 A800 80G，DPO 用 2 张 A800 80G，整体投入“中小团队可承受”。
推理资源： 1 张 A800 80G，训练和导出模型为Qwen3 8B + lora合并，fp16版本，未作量化。
核心经验：在垂直 Agent 场景，与其无限加码 Prompt/Context 工程去对抗漂移，不如用小模型做可控后训练，把工具调用契约写进模型参数里，它更可回归、更可版本化，也更适合工程落地。
02 背景：开源模型更强了，为什么垂直 Agent 仍然难上线？
过去一年开源 LLM 的通用能力提升非常快，选择落地方案时，直觉是：选更大的基座模型，再加一点 Prompt Engineering、RAG 和流程编排，就能实现端到端自动化。但在垂直专业领域 + 多工具调用 + 多轮对话的 Agent 形态下，这条路经常会卡在“稳定性”上。
原因在于：垂直落地不是要做到“能聊会聊”，而是要做到“能稳定且准确执行”。系统对 LLM 的要求不是偶尔答对，而是持续满足三件事：
- 该调用工具就调用：对陌生场景不能依靠幻觉凭空猜测；
- 调用要严格正确：函数名、参数、类型、枚举值都要对，还能结构化输出方便解析；
- 返回要稳定解读：工具返回一复杂，模型很容易被格式噪声带偏，导致同一条数据多次处理结论不一致。
而单纯依赖 Prompt/Context 工程会引入一个现实困境：
- 为了“修补模型能力”，上下文会越来越长（多轮历史、RAG 片段、工具返回、流程状态……），这会带来指令衰减与注意力漂移，最终表现为“前几轮守规矩，后几轮开始乱来”。
- 当你用流程去强行兜底（重试、校验、补充提示）时，系统复杂度上升，失败模式也会变得更随机，导致流程优化很难稳定复用。
在这样的背景下，我把目标从“把流程编排得更强”转成“把行为对齐得更稳”：用 8B 小模型做后训练，把领域语义与工具调用契约显式固化下来，让模型在复杂上下文里也能更像一个可控组件，从而真正支撑端到端流程自动化。
03 现有指标表
指标含义定义：
- tool_call_accuracy：是否调用工具（与期望一致）；若调用，则函数名与参数必须完全正确才算对（严格口径）。
- tool_name_accuracy：在“模型发生工具调用”的情况下，函数名正确率。
- tool_args_accuracy：在“模型发生工具调用”的情况下，参数与预期一致的比例。
- response_quality：回答是否存在超短、结尾重复、或不匹配的
<think>标签等格式问题（值越高越好）。
表1：各训练阶段指标对比
| 阶段 | tool_call_accuracy | tool_name_accuracy | tool_args_accuracy | response_quality |
|---|---|---|---|---|
| Baseline：Qwen3-8B（未训练） | 34.8% | 44.2% | 25.7% | 100.0% |
| SFT 后 | 32.7% | 42.2% | 24.1% | 100.0% |
| DPO v1 后（失败） | 32.3% | 40.1% | 23.2% | 100.0% |
| DPO v2 后（数据集扩大 5X） | 97.3% | 99.3% | 96.4% | 100.0% |
表2：相对 Baseline 的变化
| 阶段 | tool_call_accuracy 变化 | tool_name_accuracy 变化 | tool_args_accuracy 变化 |
|---|---|---|---|
| SFT 后 vs Baseline | -2.1 % | -2.0 % | -1.6 % |
| DPO v1 后 vs Baseline | -2.5 % | -4.1 % | -2.5 % |
| DPO v2 后 vs Baseline | +62.5 % | +55.1 % | +70.7 % |
Case 1（Qwen3-235B）：多轮对话后“自我模仿”并编造工具结果，逐步形成跳过调用的习惯
- 模型：Qwen3-235B
- 现象概述：在多轮对话的初期，模型表现正常，能够准确发起工具调用并解析结果。但随着对话轮数增加，Context 中积累了多个“发起调用 -> 获得工具调用结果并解读”的历史数据后，意外的现象发生了：在后续的对话中，模型不再发起真实的工具调用请求。相反，它基于之前的历史数据格式，凭空编造了一个工具查询结果，并基于该“伪造结果”继续做分析与决策。也就是说，它跳过了本应发生的真实工具调用。一旦出现一次幻觉式的伪造返回，模型往往会在后续轮次里延续这种模式，表现出一种“既定行为惯性”：不再调用工具，而是持续编造。这时候模型掉入了一种自回归陷阱。
分析：这是大模型在长上下文中典型的**“路径捷径” (Shortcut Learning)** 现象。模型“认为”自己已经掌握了工具返回数据的规律（格式正确），为了省事或基于概率预测，它直接跳过了Action步骤，输出了Observation。
- 典型失败特征
- 格式像真的：返回结构、字段名、排版都高度模仿早期真实工具结果，让人第一眼不易察觉。
- 链路断点隐蔽：表面上 reasoning 是连续的，但在执行链路上，关键的“tool call 事件”消失了。
- 错误会被放大：后续每一步分析、分类、升级处置决策，都会建立在这份“虚构查询结果”上，导致不可控风险。
- 对业务的直接影响
- 不可审计：你无法证明“依据哪个真实查询结果做出决策”。
- 不可回放：重跑同一请求可能产生完全不同的链路。
- 不可上线：一旦进入自动化写库/处置动作，编造 tool result 的风险是硬性不可接受的。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
