近年 AI 应用技术学习路线：从 LLM、RAG 到 Agent 工程

目标读者：希望系统掌握 AI 应用技术的开发者与工程师 前置知识：掌握至少一门编程语言，了解基本的数据结构和算法 预计完成时间：3 到 6 个月，取决于每周投入时间和已有工程基础

学习目标

读完本文后，你应该能够：

• 画出 AI 应用技术栈的三层核心组成（模型层、应用层、基础设施层）并解释分层的必要性
• 对比 RAG 与 Fine-tuning 的适用边界，能为具体场景选择合适方案
• 解释 MCP 协议解决的本质问题，并说明为什么它需要成为开放标准
• 设计一个包含工具调用和记忆管理的简单 Agent 系统
• 制定一条从课程学习到生产部署的完整迁移路径

目录

• 前言
• 学习路线总览
• [§1 LLM：大语言模型基础](#1-llm 大语言模型基础-)
• [§2 Prompt Engineering：提示词工程](#2-prompt-engineering 提示词工程-)
• [§3 Fine-tuning：微调技术](#3-fine-tuning 微调技术-)
• [§4 RAG：检索增强生成](#4-rag 检索增强生成-)
• §5 Function Calling 与 MCP
• [§6 Agent：智能体架构](#6-agent 智能体架构-)
• [§7 Multi-Agent：多智能体系统](#7-multi-agent 多智能体系统-)
• [§8 Workflow Engineering：工作流编排](#8-workflow-engineering 工作流编排-)
• [§9 Context Engineering：上下文工程](#9-context-engineering 上下文工程-)
• [§10 Agent Skill：智能体技能](#10-agent-skill 智能体技能-)
• [§11 OpenClaw：开源智能体框架](#11-openclaw 开源智能体框架-)
• [§12 Harness Engineering：评估工程](#12-harness-engineering 评估工程-)
• 端到端实战：构建企业知识库问答智能体
• 学习路线总结
• 练习
• 自测题
• 常见问题 FAQ
• 推荐学习资源
• 进阶路径指引
• 核心术语表

前言

过去几年，AI 应用开发从"会调用一个聊天接口"迅速演化成一套完整工程体系：模型选择、提示词、检索、工具调用、上下文管理、工作流、智能体、评估集。任何一环薄弱，最终产品都会在稳定性、成本或可维护性上出问题。

这篇文章把近年最常见的 AI 应用技术主题串成一条学习路线。它适合两类读者：一类是想从零建立系统认知的开发者，另一类是已经做过 Prompt、RAG 或 Agent 项目，但希望补齐工程全貌的人。

读完后，至少应该能做到下面几件事：

• 建立 AI 应用技术的系统认知框架
• 理解每个技术的核心原理与适用边界
• 掌握从理论到实践的完整学习顺序
• 可直接复用的代码示例与配置方案
• 每个主题的练习题与自测检查清单

本文定位：这是一篇技术路线图，不是单点深度教程。每个主题都会交代核心概念、为什么需要它、适用边界和最小实践；真正进入生产系统时，还需要结合具体模型、数据、权限、安全和成本约束继续细化。

学习路线总览

这条路线可以拆成三种阅读深度。初学者先拿到概念地图，有经验的开发者重点看实现取舍，架构师和团队负责人则更应该关注边界、评估和治理。

建议的学习顺序：LLM 基础 → Prompt Engineering → RAG → Function Calling / MCP → Agent → Workflow / Context → Multi-Agent → Skill / Evaluation

依赖关系图：

LLM 基础 ──────→ Prompt Engineering ──────→ Fine-tuning
│                    │                      │
│                    ▼                      ▼
│              Function Calling          RAG
│                    │                      │
│                    ▼                      │
│                   MCP ────────────────────┤
│                    │                      │
▼                    ▼                      ▼
智能体 ←──────────── Context Engineering
│
▼
Multi-Agent ──→ Workflow Engineering ──→ Agent Skill
│
▼
OpenClaw ──→ Harness Engineering

§1 LLM：大语言模型基础

LLM 是整条路线的地基。理解它，重点不在背参数，而在知道它"能做什么、不能做什么"。

现代主流 LLM 几乎都基于 Transformer 的 Decoder-Only 架构——只保留自回归解码部分，输入一段文本，逐个 Token 预测下一个 Token。相比 BERT 的 Encoder-Only 和 T5 的 Encoder-Decoder，Decoder-Only 在生成式任务上表现更稳，也成为 GPT、Llama 等模型的一致选择。

Decoder-Only 的核心机制是自注意力（Self-Attention）：序列中每个 Token 都会对序列内所有其他 Token 计算相关性权重，再按权重加权求和得到自己的新表示。这正是它能"理解上下文"的根源——捕捉长距离依赖就是靠这一步。

输入序列：["我", "喜欢", "AI", "技术"]

自注意力计算（简化）：
每个 Token 都会"关注"所有其他 Token，计算相关性权重：

"我"   → 关注 [我:0.3, 喜欢:0.5, AI:0.1, 技术:0.1]  → 主要是"喜欢"的施事者
"喜欢" → 关注 [我:0.4, 喜欢:0.1, AI:0.3, 技术:0.2]  → "我"喜欢"AI"和"技术"
"AI"   → 关注 [我:0.1, 喜欢:0.3, AI:0.2, 技术:0.4]  → "AI"是一种"技术"
"技术" → 关注 [我:0.1, 喜欢:0.2, AI:0.4, 技术:0.3]  → 与"AI"强关联

→ 每个 Token 的表示 = 所有 Token 的加权求和
→ 权重越大，表示该 Token 对当前 Token 越重要

工程边界：LLM 自己是"无状态函数"——它不知道训练数据截止之后的事，也不知道你的私有数据。这让"如何把外部知识、工具、上下文喂给它"成为后续所有章节的主题。

§2 Prompt Engineering：提示词工程

提示词工程的目标是：不改模型参数，仅通过组织输入来引导正确的输出。它的杠杆来自一个事实——LLM 是从海量文本里学出来的，对输入的"模式"极其敏感。

最有效的三种手段：

1. Few-Shot 示例：给出输入输出对，让模型模仿格式。适合翻译、分类、抽取等结构化任务。
2. 思维链（CoT）：要求模型"展示推理过程"，能显著提升数学、逻辑类问题的正确率。
3. 角色设定与约束：用明确的角色、任务、约束、输出格式把任务边界说清楚。

# 示例：翻译任务

# 示例 1
用户：把"早上好"翻译成英文
AI：Good morning

# 示例 2
用户：把"晚安"翻译成英文
AI：Good night

# 正式请求
用户：把"你好"翻译成英文
AI：

# 示例：数学问题

用户：计算 245 + 178，请展示计算过程。
AI：让我一步步思考：

第 1 步：245 + 100 = 345
第 2 步：345 + 70 = 415
第 3 步：415 + 8 = 423

答案是 423

# 角色
你是一位资深的前端工程师，擅长 React 和 TypeScript。

# 任务
审查以下代码，找出潜在的性能问题。

# 约束
- 只关注性能问题，不关注代码风格
- 每个问题给出具体的修改建议
- 按严重程度排序（高 → 中 → 低）

# 输出格式
| 问题 | 严重程度 | 位置 | 修改建议 |
| ---- | ---- | ---- | ---- |

# 代码
{待审查的代码}

工程边界：提示词工程受上下文窗口限制，也无法让模型"记住"长期知识。当提示词怎么调都达不到效果、或需要模型固化某种行为时，就要考虑 §3 的微调。

§3 Fine-tuning：微调技术

微调是在特定数据集上继续训练预训练模型，让它适应特定任务。它解决的是提示词解决不了的问题：模型行为方式不对（输出风格、专业用语、固定格式）。

全参微调代价极高。现实里更常用参数高效微调（PEFT），其中 LoRA（Low-Rank Adaptation） 是最主流的一种：冻结原权重，只在旁边加一条低秩旁路，训练的参数占比常在 1% 以下。

原始更新：ΔW (100×100 = 10,000 参数)
LoRA 分解：A (100×2 = 200 参数) × B (2×100 = 200 参数)
实际训练：400 参数 = 10,000 参数的 4%

配合 Hugging Face 的 peft 库，用 LoRA 微调一个模型只需几行代码：

import torch
from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Meta-Llama-3-8B",
torch_dtype=torch.bfloat16,
device_map="auto"
)

lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM"
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 输出示例：trainable params: 6,815,744 || all params: 8,075,097,856 || trainable%: 0.084%

RAG vs 微调怎么选：模型"不知道某个知识"（内部文档、最新新闻）→ 用 RAG；模型"行为方式不对"（输出格式、语气）→ 用微调。两者常组合使用。

§4 RAG：检索增强生成

RAG 解决 LLM 的两个天然短板：知识有截止日期、无法访问私有数据。思路是把答案的来源从"模型记忆"移到"外部知识库"。

标准流程分两条流水线：

┌─────────────────────────────────────────────────────────────┐
│                      RAG 工作流程                              │
└─────────────────────────────────────────────────────────────┘

用户问题 ──→ 编码为向量 ──→ 在向量数据库中检索 ──→ 获取相关文档
│
▼
┌───────────────────────────────┐
│         LLM 生成答案            │
│  (基于检索结果 + 自身知识)        │
└───────────────────────────────┘
│
▼
最终回答

• 离线索引：把文档切块（Chunk）、编码成向量、存入向量数据库。
• 在线查询：把问题编码成向量，检索 Top-K 近似文档，可选重排序，再拼进上下文让 LLM 生成。

用 LangChain 搭一条最小 RAG 管道：

from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", "。", "！", "？", ".", " "]
)

chunks = text_splitter.split_text(your_document_text)

vectorstore = Chroma.from_texts(
texts=chunks,
embedding=OpenAIEmbeddings()
)

results = vectorstore.similarity_search("如何配置 LoRA？", k=3)
for doc in results:
print(doc.page_content)

工程要点：切片大小、重叠窗口、检索 Top-K、重排序是否必要，都直接影响回答质量，是需要反复实验的维度。

§5 Function Calling 与 MCP

LLM 只能"想"，不能"做"。Function Calling 给了它调用外部工具的能力：模型根据用户意图，输出一个结构化调用（工具名 + 参数），由你的代码真正执行。

from openai import OpenAI

client = OpenAI()

messages = [
{"role": "user", "content": "今天北京的天气怎么样？"}
]

tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气信息",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "城市名称，如'北京'、'上海'"
}
},
"required": ["location"]
}
}
}
]

response = client.chat.completions.create(
model="gpt-4.1",
messages=messages,
tools=tools
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name)    # → "get_weather"
print(tool_call.function.arguments)  # → '{"location": "北京"}'

MCP（Model Context Protocol） 在 Function Calling 之上解决一个更系统的问题：工具如何被标准化地发现、连接和复用。在 MCP 之前，每个框架有自己的一套工具格式，工具无法跨框架复用。MCP 把"模型 ↔ 工具/数据源"的连接抽成开放协议，让工具生态产生网络效应——一次开发，到处使用。

为什么需要开放标准：工具生态需要网络效应。越多框架和工具支持 MCP，开发者越能避免为每个框架重写一遍工具适配层。

§6 Agent：智能体架构

Agent 把前面所有的能力拼成一个闭环：LLM 提供大脑，工具提供手脚，记忆提供上下文，规划提供行动路线。

Agent = LLM（大脑）+ Planning（规划）+ Memory（记忆）+ Tools（工具）

最经典的执行范式是 ReAct（Reasoning + Acting）：思考 → 行动 → 观察 → 再思考，循环直到任务完成。

一个具体例子能直观看到这个循环：

┌─────────────────────────────────────────────────────────────┐
│                    ReAct 执行示例                              │
└─────────────────────────────────────────────────────────────┘

用户：北京明天的天气适合户外运动吗？

Thought 1：我需要先查北京明天的天气，再判断是否适合户外运动。
Action 1：调用 get_weather(location="北京", date="明天")
Observation 1：明天北京晴，气温 25°C，湿度 40%，风速 3 级

Thought 2：天气晴朗、温度适宜、湿度低、风速小，非常适合户外运动。
Action 2：无需更多工具调用
Answer：明天北京天气晴朗，气温 25°C，湿度适中，非常适合户外运动！
推荐活动：跑步、骑行、徒步。

§7 Multi-Agent：多智能体系统

单个 Agent 在复杂任务上常显得力不从心。Multi-Agent 的核心思路是拆：把一个大任务拆给多个各司其职的智能体。常见的协作模式有三种：

• 层级模式：一个主 Agent 调度多个子 Agent，职责清晰，适合有明确分工的场景。
• 协作模式：平级 Agent 互通消息、汇总结果，适合需要观点碰撞的场景。
• 竞争模式：多个 Agent 各自产出，由评估者挑选最佳，适合"比质量"的场景。

用 CrewAI 定义一个"研究员 + 写手"的协作团队：

from crewai import Agent, Task, Crew

researcher = Agent(
role="研究员",
goal="收集并分析最准确的信息",
backstory="你是一位专业的研究员，擅长从多个来源收集信息。"
)

writer = Agent(
role="技术写手",
goal="将复杂技术用易懂的语言解释清楚",
backstory="你是一位资深技术作家，擅长将复杂概念通俗化。"
)

research_task = Task(
description="研究 LLM 最新发展趋势",
agent=researcher
)

write_task = Task(
description="撰写一篇 LLM 科普文章",
agent=writer
)

crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task])
result = crew.kickoff()

工程边界：多 Agent 不等于更可靠。协调开销、上下文传递、错误传播都会放大。能用单 Agent 解决就先用单 Agent，拆智能体是"为了拆而拆"的反模式。

§8 Workflow Engineering：工作流编排

Agent 擅长"自主决策"，但很多任务其实是确定性流程——固定步骤、固定依赖，不需要模型每一次都重新规划。工作流工程就是把这类流程写成代码：定义步骤、状态、转换和异常处理。

# 一个确定性工作流的抽象示意：
# 输入 → 校验 → 检索 → 生成 → 校验输出 → 完成
# 每一步失败都走明确的降级或重试路径

Agent vs Workflow 怎么选：路径固定、可预期 → 用 Workflow，稳定可控、成本低；路径开放、需要临场决策 → 用 Agent。两者可以组合——把 Agent 作为工作流中的一个"节点"。

§9 Context Engineering：上下文工程

上下文工程的本质是回答一个问题：往窗口里放什么，才能让模型表现最好。它在上下文窗口有限的前提下，系统性地管理"该放的信息、不该放的信息、以什么结构放"。

一个实用做法是用结构化标签（如 XML）组织上下文，让模型能清晰区分"任务、背景、代码、约束"：

<task>
审查以下代码的安全问题
</task>

<context>
<project>Web API 服务</project>
<language>Python</language>
<framework>FastAPI</framework>
</context>

<code>
{待审查代码}
</code>

<constraints>
只关注 OWASP Top 10 安全风险
</constraints>

上下文窗口不够怎么办：优先 1）增量摘要压缩历史；2）相关性检索只取相关片段；3）结构化标签减少冗余。仍不够时，可用 Multi-Agent 把上下文分散到不同智能体。

§10 Agent Skill：智能体技能

Skill 是把"特定功能封装成可复用单元"的标准格式。它让智能体具备"可被调用、可发现、可组合"的能力，核心是一份 SKILL.md 定义文件 + 配套的工具与知识目录。

my_skill/
├── SKILL.md        # 技能定义文件（必需）
├── tools/          # 工具脚本目录
│   ├── script1.py
│   └── script2.sh
├── knowledge/      # 知识文件目录
│   └── guide.md
└── config.yaml      # 配置文件

SKILL.md 用 frontmatter 声明技能元信息（名称、版本、描述、触发器），正文描述功能、使用方式和依赖：

---
name: code-reviewer
version: 1.0.0
description: 自动代码审查技能
triggers:
- "审查代码"
- "code review"
---

# Code Reviewer Skill

## 功能
审查代码的安全性和性能问题。

## 使用方式
1. 提供待审查的代码文件
2. 智能体自动调用审查工具
3. 输出审查报告

## 依赖
- Python 3.10+
- ruff, bandit

Skill 的价值在于沉淀：一次调试好的能力封装成 Skill 后，可以被多次、跨任务复用，避免反复从零写提示词和工具。

§11 OpenClaw：开源智能体框架

从 §6 到 §10，我们都在讨论"怎么设计一个智能体"。OpenClaw 则回答"怎么把智能体跑起来接到真实消息流里"——它是一个从消息接入到智能体运行的端到端框架。

┌─────────────────────────────────────────────────────────────┐
│                     OpenClaw 系统架构                         │
└─────────────────────────────────────────────────────────────┘

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   消息平台   │     │   消息平台   │     │   消息平台   │
│ (Telegram)  │     │  (Discord)  │     │  (WhatsApp) │
└──────┬──────┘     └──────┬──────┘     └──────┬──────┘
│                   │                   │
└───────────────────┼───────────────────┘
│
┌────────▼────────┐
│    Gateway     │  ← 控制平面（WebSocket）
│  (控制中枢)     │
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
│                   │                   │
┌──────▼──────┐     ┌──────▼──────┐     ┌──────▼──────┐
│   智能体   │     │   Tools     │     │   Memory    │
│   (大脑)    │     │  (工具集)   │     │  (记忆)     │
└─────────────┘     └─────────────┘     └─────────────┘

核心是 Gateway（控制中枢）：它通过 WebSocket 连接各消息平台，把消息路由给智能体，智能体再调用工具、读写记忆。安装与启动很简单：

# 安装（官方推荐 Node.js 24，兼容 Node.js 22.14+）
npm install -g openclaw@latest

# 初始化配置
openclaw onboard --install-daemon

# 启动 Gateway
openclaw gateway --port 18789 --verbose

# 打开本地控制台
openclaw dashboard

LangChain vs OpenClaw：LangChain 是开发库，给你构建智能体的抽象；OpenClaw 是完整框架，给你从消息接入到运行的端到端方案。快速落地接 Telegram/Discord 用 OpenClaw，深度定制逻辑用 LangChain。

§12 Harness Engineering：评估工程

越复杂的 Agent 系统越需要客观度量。Harness Engineering（评估工程）的核心主张是：用评估驱动开发，而不是靠手感调参。

第一步是建立评估集——一组覆盖不同难度和场景、带期望行为的测试用例：

[
{
"id": "eval_001",
"input": "帮我查一下北京明天的天气",
"expected_tool": "get_weather",
"expected_params": {"location": "北京"},
"difficulty": "easy"
},
{
"id": "eval_002",
"input": "帮我规划一个北京三日游，预算 5000 元",
"expected_tools": ["search_attractions", "search_hotels", "calculate_budget"],
"difficulty": "hard"
}
]

然后进入"定义 → 运行 → 分析失败 → 修改配置"的循环，直到成功率达标：

┌─────────────────────────────────────────────────────────────┐
│                   评估驱动的开发循环                            │
└─────────────────────────────────────────────────────────────┘

┌──────────────┐
│ 1. 定义评估集  │ ← 包含多样化用例、边界案例、期望输出
└──────┬───────┘
│
▼
┌──────────────┐
│ 2. 运行评估   │ ← 执行所有用例，收集结果
└──────┬───────┘
│
▼
┌──────────────┐
│ 3. 分析失败   │ ← 定位失败用例，分析根因
└──────┬───────┘
│
▼
┌──────────────┐
│ 4. 修改配置   │ ← 调整提示词/智能体配置/工具定义
└──────┬───────┘
│
▼
┌─────────┐
│ 成功率？ │
└────┬────┘
╱         ╲
达标       未达标
│           │
▼           └──→ 返回步骤 2
发布

这相当于把软件工程里的 CI/CD 思想引入 AI 应用：每次改动都跑评估，用数据说话，而不是靠感觉。

端到端实战：构建企业知识库问答智能体

把前面所有技术串起来：一个企业知识库问答智能体，同时使用 RAG（查知识库）、Function Calling（查数据库、联网搜索）和 Agent 循环。

架构如下：

┌─────────────────────────────────────────────────────────────┐
│              企业知识库问答智能体架构                            │
└─────────────────────────────────────────────────────────────┘

用户提问 ──→ 智能体（LLM）
│
├──→ 工具 1：知识库检索（RAG）
│       └── 向量数据库 → 返回相关文档
│
├──→ 工具 2：数据库查询（Function Calling）
│       └── SQL 数据库 → 返回结构化数据
│
└──→ 工具 3：网络搜索（Function Calling）
└── 搜索 API → 返回最新信息

用 OpenAI Function Calling 实现一个最小可运行版本：

import json
from openai import OpenAI
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

client = OpenAI()

vectorstore = Chroma(
collection_name="company_docs",
embedding_function=OpenAIEmbeddings()
)

def execute_sql_safely(sql: str) -> str:
normalized_sql = sql.strip().lower()
if not normalized_sql.startswith("select"):
return "安全策略拒绝：只允许 SELECT 查询。"

# 真实项目中应在这里接入只读数据库连接，并加入参数化查询、超时和审计。
return "这里返回只读 SQL 查询结果。"

tools = [
{
"type": "function",
"function": {
"name": "search_knowledge_base",
"description": "在企业知识库中检索相关文档",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "检索关键词"
}
},
"required": ["query"]
}
}
},
{
"type": "function",
"function": {
"name": "query_database",
"description": "查询企业数据库获取结构化数据，如订单、客户信息等",
"parameters": {
"type": "object",
"properties": {
"sql": {
"type": "string",
"description": "SQL 查询语句"
}
},
"required": ["sql"]
}
}
}
]

def execute_tool(tool_name: str, arguments: dict) -> str:
if tool_name == "search_knowledge_base":
results = vectorstore.similarity_search(arguments["query"], k=3)
return "\n\n".join([doc.page_content for doc in results])
elif tool_name == "query_database":
return execute_sql_safely(arguments["sql"])
return "未知工具"

def run_agent(user_message: str, max_iterations: int = 5) -> str:
messages = [{"role": "user", "content": user_message}]

for _ in range(max_iterations):
response = client.chat.completions.create(
model="gpt-4.1",
messages=messages,
tools=tools
)

msg = response.choices[0].message

if not msg.tool_calls:
return msg.content

messages.append(msg.model_dump(exclude_none=True))

for tool_call in msg.tool_calls:
result = execute_tool(
tool_call.function.name,
json.loads(tool_call.function.arguments)
)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result
})

return "达到最大迭代次数，请尝试更具体的问题。"

对应地，为这个智能体准备一组端到端评估用例：

[
{
"id": "e2e_001",
"input": "公司的年假政策是什么？",
"expected_tool": "search_knowledge_base",
"difficulty": "easy"
},
{
"id": "e2e_002",
"input": "上个月销售额最高的产品是什么？",
"expected_tool": "query_database",
"difficulty": "medium"
},
{
"id": "e2e_003",
"input": "对比我们产品和竞品的市场表现，给出分析报告",
"expected_tools": ["search_knowledge_base", "query_database"],
"difficulty": "hard"
}
]

学习路线总结

把全篇串成一句话：先让模型"会说话"（LLM 与提示词），再让它"有知识"（RAG 或微调），接着让它"能动手"（Function Calling / MCP），再让它"会规划"（Agent），人多力量大就拆智能体（Multi-Agent），复杂任务用流程固化（Workflow），最后用评估兜底（Harness Engineering）。

建议的产品落地顺序：最小可用 → 提示词工程 → 需要时加 RAG → 需要时加工具 → 封装成 Agent → 用评估集固化质量。每一步都先做小、做对，再谈扩展。

⬆️ 返回目录

常见问题 FAQ

Q1：我应该从哪个技术开始学？

如果你完全没有 AI 开发经验，从 Prompt Engineering 开始。它不需要复杂基础设施，只要能调用一个 LLM API 就能练习，而且能很快反馈出任务边界。掌握提示词技巧后，再按顺序学习 RAG → Function Calling → Agent。

Q2：微调和 RAG 到底该选哪个？

一个实用判断是：如果问题是“模型不知道某个知识”（如公司内部文档、最新新闻），优先选 RAG；如果问题是“模型的行为方式不对”（如输出格式、对话风格），再考虑微调。两者也可以组合使用。

Q3：学智能体开发需要什么基础？

你需要：1）熟练使用至少一门编程语言（Python 推荐）；2）理解 API 调用和异步编程；3）基本的 LLM 使用经验（至少用过 ChatGPT 或 Claude 的 API）。Function Calling 是智能体开发的前置知识，务必先掌握。

Q4：OpenClaw 和 LangChain 有什么区别？

LangChain 是一个开发库，提供构建智能体的工具和抽象；OpenClaw 是一个完整框架，提供从消息接入到智能体运行的端到端解决方案。如果你要快速搭建一个能接入 Telegram/Discord 的智能体，OpenClaw 更方便；如果你要深度定制智能体逻辑，LangChain 更灵活。

Q5：如何评估我的 AI 应用是否足够好？

建立评估集（Evaluation Set），包含 20 到 50 个覆盖不同场景的测试用例。每个用例定义输入、期望行为和评分规则，运行后统计成功率。成功率低于 80% 的场景需要重点优化。参考 §12 Harness Engineering 了解详细方法。

Q6：上下文窗口不够用怎么办？

优先尝试：1）增量摘要——对历史对话进行压缩；2）相关性检索——只检索与当前问题相关的上下文；3）结构化模板——用 XML/JSON 减少冗余描述。如果仍然不够，考虑 Multi-Agent 架构将上下文分散到不同智能体。

推荐学习资源

官方文档与论文

在线学习平台

开源项目推荐

练习

下面三个练习用来检验你对 AI 应用技术栈的理解，建议动手实现后再对照行为：

1. 搭建本地 LLM 环境并跑通一个 Q&A 任务：用 Ollama 安装 Llama 3（8B），用 Python 写一个调用本地 LLM 的简单 Q&A 脚本。要求：能接收用户输入，发给本地 LLM，打印回答。完成后试试：如果用户输入的问题需要外部知识（例如"今天天气怎么样"），你的脚本能否处理？

2. 用 LlamaIndex 搭建一个简单 RAG 管道：选一个你熟悉的文档集（例如公司技术文档、个人笔记），用 LlamaIndex 搭建一个 RAG 管道。要求：能接收用户问题，从文档集检索相关片段，拼成上下文发给 LLM，返回回答。观察：检索返回的片段是否真的相关？需不需要调整 chunk 大小和 overlap？

3. 用 LangGraph 实现一个简单 Agent：用 LangGraph 写一个只调用一个工具（例如 get_weather(city: str)）的 ReAct 循环。要求：处理 Observation → Reasoning → Action 三步，设置终止条件（循环次数上限或任务完成标记）。完成后对比：和直接用 OpenAI API function calling 实现同样功能，哪边代码更清晰？

自测题

下面 5 道题用来检验你对全文核心概念的掌握程度。点击参考答案前的三角展开查看解析。

1. AI 应用技术栈的三层核心组成是什么？为什么需要分这三层？

2. RAG（检索增强生成）解决的本质问题是什么？它的两个核心步骤是什么？

3. Prompt Engineering 和 Fine-tuning 的区别是什么？什么场景用哪个？

4. MCP（模型上下文协议）解决的本质问题是什么？为什么它需要成为开放标准？

5. 从课程学习到生产部署，需要补哪些工程能力？

进阶路径指引

掌握基础路线后，可选择以下三大进阶方向：

路径 A：AI 基础设施方向

深入理解模型训练和部署的工程实践：

1. 模型量化与推理优化：学习 GPTQ、AWQ、vLLM 等推理加速技术
2. 分布式训练：学习 DeepSpeed、FSDP 等大规模训练框架
3. 模型服务化：学习 Triton Inference Server、BentoML 等部署方案

路径 B：AI 应用产品方向

深入理解 AI 产品的设计和用户体验：

1. AI 产品设计：学习人机交互设计、AI UX 实践建议
2. 多模态应用：学习视觉、语音等多模态 AI 应用开发
3. AI 安全与对齐：学习 RLHF、Constitutional AI 等对齐技术

路径 C：AI 智能体深度方向

深入理解智能体系统的高级架构：

1. 智能体评估与优化：深入学习 Harness Engineering，建立 CI/CD for AI 流程
2. 复杂 Multi-Agent 系统：学习 LangGraph 等图编排框架
3. 自主智能体：探索 AutoGPT、BabyAGI 等自主智能体架构

核心术语表

⬆️ 返回目录

资料口径说明

本文基于多个 AI 应用技术课程和开源项目撰写。需要说明的边界：

1. 课程和资源版本时效性：本文提到的课程（微软 AI Agents for Beginners、LangChain for Beginners、DeepLearning.AI 等）和开源项目（LlamaIndex、LangGraph、Dify、CrewAI）都在快速迭代，章节结构、代码示例、API 接口可能随版本变化，请以各项目 GitHub 仓库的最新 commit 为准。
2. 代码示例的语言和框架依赖：本文提到的代码示例主要基于 Python 生态（LlamaIndex、LangGraph、CrewAI 均为 Python 框架），如果团队用其它语言（TypeScript/Java/C#），需要自己翻译示例。
3. MCP 协议生态成熟度：文中讲到的 MCP 协议在 2024 年 11 月才推出，生态仍在早期。工具数量、稳定性、兼容性都在快速变化，本文提到的 MCP 工具示例以 2026 年 4 月的状态为准。
4. 基准数据和性能对比：文中可能提到的性能数据（例如 Token 消耗、延迟、并发能力）来自特定测试环境，实际表现会因任务特征、模型选择、硬件条件而变化。
5. 生产部署能力缺口：学习路径覆盖了从概念到生产的关键知识点，但生产部署还需要自己补日志、监控、容错、成本控制等工程能力。
6. 多语言支持：部分资源（例如 DeepLearning.AI 课程、Hugging Face 课程）以英文为主，中文翻译可能不完整或滞后。请以各项目官方文档的语言版本为准。

文档元信息：

• 难度等级：⭐⭐⭐
• 类型：技术笔记
• 更新日期：2026-04-26
• 预计阅读时间：90 分钟