第1讲：2026 大模型应用开发全景——Prompt / RAG / 微调 / Agent 到底先用哪个

一、开篇：2026 年的选择题，不是技术题，是 ROI 题

2026 年的大模型应用开发，早已不是"能不能做"的问题，而是**"该用哪种方式做才划算"**。

你面对四个主流选项：

技术路线	一句话定位	典型场景
Prompt Engineering	不动模型，只动输入	客服问答、内容改写、简单分类
RAG（检索增强生成）	给模型装外挂知识库	企业知识库、法律/医疗问答、产品文档
Fine-tuning（微调）	让模型学会特定格式/风格	代码生成、翻译、特定角色对话
Agent（智能体）	让模型会调用工具、做决策	自动化流程、数据分析、多步任务

很多团队踩过的坑：

一上来就微调，结果发现 RAG 就能解决问题，白花了 GPU 钱
做了 RAG，但召回率只有 40%，不如直接 Prompt 加长上下文
想做 Agent，结果连基础的 Tool Call 都频繁失败

核心原则：能用 Prompt 解决的，绝不上 RAG；能用 RAG 解决的，绝不微调；Agent 是最后一道防线。

二、四选一的决策树

复制代码

用户需求
    │
    ├─ 是否需要外部知识？
    │   ├─ 否 → Prompt Engineering
    │   └─ 是 → 知识是否静态且量大？
    │       ├─ 是 → RAG
    │       └─ 否 → 是否需要模型改变行为？
    │           ├─ 否 → Prompt Engineering + Few-shot
    │           └─ 是 → 是否需要调用外部工具/多步决策？
    │               ├─ 否 → Fine-tuning
    │               └─ 是 → Agent

2.1 Prompt Engineering ------ 最便宜，但上限最低

适合条件：

任务逻辑简单，不需要大量外部知识
模型本身已经具备能力，只是需要正确的指令
对延迟敏感，不想引入额外组件

不适合：

需要精确引用大量私有文档
需要模型输出固定格式（如 JSON Schema 严格约束）

2026 年现状：

长上下文模型（128K~1M tokens）普及，很多以前必须 RAG 的场景现在可以直接塞上下文
Prompt 模板管理成为基础工程能力

2.2 RAG ------ 性价比最高，但工程复杂度不低

适合条件：

知识库频繁更新（每天/每周新增文档）
需要精确引用原文，避免幻觉
知识量远超模型上下文窗口

不适合：

任务需要模型理解深层业务逻辑（如法律推理）
查询极度依赖上下文理解（如多轮对话中的指代消解）

2026 年现状：

混合检索（BM25 + Embedding）已成标配
Rerank 模型精度大幅提升，Top-5 召回率普遍 > 90%
GraphRAG 在关系密集型场景（如企业组织架构、产品 SKU 关联）逐渐流行

2.3 Fine-tuning ------ 贵，但能改变模型行为

适合条件：

需要模型掌握特定的输出格式/风格（如代码注释规范、SQL 方言）
需要模型理解领域术语和业务逻辑
需要降低延迟（微调后的模型比 RAG 少一次检索）

不适合：

知识频繁变化（每次更新都要重新微调）
小样本场景（微调至少需要几百条高质量数据）

2026 年现状：

LoRA/QLoRA 仍是主流，全参微调只在基座模型版本迭代时做
微调数据质量 > 数量，500 条精心标注的数据好过 5000 条脏数据
模型蒸馏（Distillation）在小模型上越来越常见

2.4 Agent ------ 上限最高，但最难稳定

适合条件：

需要多步推理和决策（如"查库存→算价格→下单→发通知"）
需要调用多个外部工具/API
需要记忆和状态管理

不适合：

任务简单直接（杀鸡用牛刀）
对稳定性要求极高（Agent 的 ReAct 循环可能产生不可预测行为）

2026 年现状：

MCP（Model Context Protocol）成为 Agent 工具调用的事实标准
多 Agent 协作（Manager-Worker 模式）在企业级场景普及
Agent 的可观测性（Trace + Span + 成本追踪）成为刚需

三、Go 实现：决策引擎

下面是一个轻量级的决策引擎，接收用户需求描述，自动推荐技术路线并给出理由。

复制代码

// decision_engine.go
package main

import (
    "fmt"
    "strings"
)

type Requirement struct {
    Description          string
    NeedExternalKnowledge bool
    KnowledgeUpdateFreq  string // daily, weekly, monthly, static
    NeedFormatChange     bool
    NeedToolCall         bool
    NeedMultiStep        bool
    LatencySensitive     bool
}

type Recommendation struct {
    Primary   string
    Secondary string
    Reason    string
}

func Recommend( req Requirement ) Recommendation {
    // 决策逻辑：从最简单到最复杂
    switch {
    case !req.NeedExternalKnowledge && !req.NeedFormatChange && !req.NeedToolCall:
        return Recommendation{
            Primary: "Prompt Engineering",
            Reason:  "任务简单，无需外部知识和格式变更，直接用 Prompt 即可",
        }
    case req.NeedExternalKnowledge && !req.NeedFormatChange && !req.NeedToolCall:
        if req.KnowledgeUpdateFreq == "static" || req.KnowledgeUpdateFreq == "monthly" {
            // 知识静态或低频更新，可以考虑塞上下文
            return Recommendation{
                Primary:   "RAG",
                Secondary: "Prompt Engineering（长上下文）",
                Reason:    "需要外部知识，优先 RAG；若知识量小于 200K tokens，可直接塞 Prompt",
            }
        }
        return Recommendation{
            Primary: "RAG",
            Reason:  "知识频繁更新，RAG 是最优解，无需重新部署模型",
        }
    case req.NeedFormatChange && !req.NeedExternalKnowledge:
        return Recommendation{
            Primary:   "Fine-tuning",
            Secondary: "Prompt Engineering（Few-shot）",
            Reason:    "需要改变输出格式/风格，微调效果最好；少量样本可先试 Few-shot",
        }
    case req.NeedFormatChange && req.NeedExternalKnowledge:
        return Recommendation{
            Primary:   "RAG + Fine-tuning",
            Secondary: "Agent",
            Reason:    "既需要外部知识又需要格式控制，RAG 负责知识，微调负责格式",
        }
    case req.NeedToolCall || req.NeedMultiStep:
        return Recommendation{
            Primary: "Agent",
            Reason:  "需要调用工具或多步决策，Agent 是唯一选择",
        }
    default:
        return Recommendation{
            Primary: "Prompt Engineering",
            Reason:  "未识别到特殊需求，从最简单的 Prompt 开始",
        }
    }
}

func main() {
    testCases := []Requirement{
        {
            Description:          "客服机器人，回答产品 FAQ",
            NeedExternalKnowledge: true,
            KnowledgeUpdateFreq:  "daily",
            NeedFormatChange:     false,
            NeedToolCall:         false,
            NeedMultiStep:        false,
            LatencySensitive:     true,
        },
        {
            Description:          "代码生成助手，输出指定语言的代码",
            NeedExternalKnowledge: false,
            NeedFormatChange:     true,
            NeedToolCall:         false,
            NeedMultiStep:        false,
            LatencySensitive:     false,
        },
        {
            Description:          "自动化运维，查日志->定位故障->发通知",
            NeedExternalKnowledge: true,
            KnowledgeUpdateFreq:  "weekly",
            NeedFormatChange:     false,
            NeedToolCall:         true,
            NeedMultiStep:        true,
            LatencySensitive:     false,
        },
        {
            Description:          "文本润色，不改格式，不查资料",
            NeedExternalKnowledge: false,
            NeedFormatChange:     false,
            NeedToolCall:         false,
            NeedMultiStep:        false,
            LatencySensitive:     true,
        },
    }

    for i, tc := range testCases {
        rec := Recommend(tc)
        fmt.Printf("案例 %d: %s\n", i+1, tc.Description)
        fmt.Printf("  → 推荐: %s\n", rec.Primary)
        if rec.Secondary != "" {
            fmt.Printf("  → 备选: %s\n", rec.Secondary)
        }
        fmt.Printf("  → 理由: %s\n\n", rec.Reason)
    }
}

运行输出：

复制代码

案例 1: 客服机器人，回答产品 FAQ
  → 推荐: RAG
  → 理由: 知识频繁更新，RAG 是最优解，无需重新部署模型

案例 2: 代码生成助手，输出指定语言的代码
  → 推荐: Fine-tuning
  → 备选: Prompt Engineering（Few-shot）
  → 理由: 需要改变输出格式/风格，微调效果最好；少量样本可先试 Few-shot

案例 3: 自动化运维，查日志->定位故障->发通知
  → 推荐: Agent
  → 理由: 需要调用工具或多步决策，Agent 是唯一选择

案例 4: 文本润色，不改格式，不查资料
  → 推荐: Prompt Engineering
  → 理由: 任务简单，无需外部知识和格式变更，直接用 Prompt 即可

四、架构图：四种路线的系统拓扑

复制代码

┌─────────────────────────────────────────────────────────────────────┐
│                    大模型应用技术路线架构图                          │
│                                                                     │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐           │
│  │ Prompt Eng.  │   │     RAG      │   │  Fine-tuning │           │
│  │              │   │              │   │              │           │
│  │ User Input   │   │ User Query   │   │ User Input   │           │
│  │      ↓       │   │      ↓       │   │      ↓       │           │
│  │ Prompt Temp. │   │ Retriever    │   │ Fine-tuned   │           │
│  │      ↓       │   │   ↓   ↑      │   │    Model     │           │
│  │    LLM       │   │ Vector DB    │   │      ↓       │           │
│  │      ↓       │   │   ↓   ↑      │   │   Response   │           │
│  │   Response   │   │ Reranker     │   │              │           │
│  │              │   │      ↓       │   │              │           │
│  │  ★ 最简单    │   │ Augmented    │   │  ★ 最可控    │           │
│  │  ★ 最便宜    │   │   Prompt     │   │  ★ 最贵      │           │
│  └──────────────┘   │      ↓       │   └──────────────┘           │
│                      │    LLM       │                              │
│                      │      ↓       │                              │
│                      │   Response   │                              │
│                      │              │                              │
│                      │  ★ 性价比最高│                              │
│                      └──────────────┘                              │
│                                                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                        Agent                                │   │
│  │                                                             │   │
│  │  User Input → Orchestrator → ReAct Loop                    │   │
│  │                                   │                         │   │
│  │                     ┌─────────────┼─────────────┐           │   │
│  │                     ▼             ▼             ▼           │   │
│  │                 Tool A        Tool B        Tool C          │   │
│  │              (数据库查询)   (API调用)    (文件操作)         │   │
│  │                     │             │             │           │   │
│  │                     └─────────────┴─────────────┘           │   │
│  │                                   │                         │   │
│  │                              Response                       │   │
│  │                                                             │   │
│  │  ★ 上限最高  ★ 最难稳定  ★ 最适合复杂任务                  │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

五、2026 年趋势速览

趋势	说明	影响
长上下文普惠化	Gemini 2M、Claude 200K、DeepSeek 128K 成为标配	RAG 门槛降低，但成本仍需关注
RAG → GraphRAG	微软 GraphRAG 开源后，社区涌现大量变体	关系型知识场景（企业架构、产品目录）效果显著提升
Agent 框架收敛	LangChain / CrewAI / AutoGen 三分天下，MCP 成协议标准	工具调用互操作性大幅改善
微调轻量化	LoRA + 量化 + 蒸馏，单卡 A100 可微调 70B 模型	中小团队也能做领域微调
可观测性成标配	Trace / Span / Token 成本 / 幻觉率纳入 SLA	没有观测数据的 AI 应用不允许上线
FinOps 兴起	模型路由（小模型处理简单请求）、缓存、KV Cache 复用	成本下降 30%~70%

六、实战建议

永远从 Prompt 开始 --- 花一周时间调 Prompt，确定问题边界，再决定是否升级路线
RAG 先做最小可行版 --- 一个 Embedding 模型 + BM25 混合检索，不要一开始就上 GraphRAG
微调前先问自己 --- "这 500 条数据能让模型学会什么？用 Few-shot 行不行？"
Agent 从小做起 --- 先做一个单工具 Agent（如"查天气"），再扩展到多工具
留好观测接口 --- 无论选哪条路，从一开始就埋点：Token 计数、延迟、召回率、成功率

七、预告

第 2 讲预告：《企业级 RAG 实战：文档解析、语义分块、混合检索、Rerank、上下文压缩》

你将学到：

PDF/Word/HTML 文档解析的坑与最佳实践

语义分块的三种策略（Fixed-size / Recursive / Semantic Chunking）

BM25 + Embedding 混合检索的 Go 实现

Rerank 模型如何把召回率从 60% 拉到 95%

上下文压缩技术，省 50% Token 成本

🧰 开发之余的小工具推荐

处理 Base64、JSON 格式化、JWT 解析、Crontab 计算、PDF 合并压缩这些碎片需求，我常用一个纯前端本地工具箱：zz365.top。所有计算在浏览器完成，文件不上服务器，关页即清。免费、无登录、无广告，适合开发者当常驻标签页。

下一讲：企业级 RAG 实战。