在做垂直领域 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 的要求不是偶尔答对，而是持续满足三件事：

1. 该调用工具就调用：对陌生场景不能依靠幻觉凭空猜测；
2. 调用要严格正确：函数名、参数、类型、枚举值都要对，还能结构化输出方便解析；
3. 返回要稳定解读：工具返回一复杂，模型很容易被格式噪声带偏，导致同一条数据多次处理结论不一致。

而单纯依赖 Prompt/Context 工程会引入一个现实困境：

1. 为了“修补模型能力”，上下文会越来越长（多轮历史、RAG 片段、工具返回、流程状态……），这会带来指令衰减与注意力漂移，最终表现为“前几轮守规矩，后几轮开始乱来”。
2. 当你用流程去强行兜底（重试、校验、补充提示）时，系统复杂度上升，失败模式也会变得更随机，导致流程优化很难稳定复用。

在这样的背景下，我把目标从“把流程编排得更强”转成“把行为对齐得更稳”：用 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。

• 典型失败特征

1. 格式像真的：返回结构、字段名、排版都高度模仿早期真实工具结果，让人第一眼不易察觉。
2. 链路断点隐蔽：表面上 reasoning 是连续的，但在执行链路上，关键的“tool call 事件”消失了。
3. 错误会被放大：后续每一步分析、分类、升级处置决策，都会建立在这份“虚构查询结果”上，导致不可控风险。

• 对业务的直接影响

• 不可审计：你无法证明“依据哪个真实查询结果做出决策”。
• 不可回放：重跑同一请求可能产生完全不同的链路。
• 不可上线：一旦进入自动化写库/处置动作，编造 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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】