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

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

目录

• 前言
• 学习路线总览
• §1 LLM：大语言模型基础
• §2 Prompt Engineering：提示词工程
• §3 Fine-tuning：微调技术
• §4 RAG：检索增强生成
• §5 Function Calling 与 MCP
• §6 Agent：智能体架构
• §7 Multi-Agent：多智能体系统
• §8 Workflow Engineering：工作流编排
• §9 Context Engineering：上下文工程
• §10 Agent Skill：智能体技能
• §11 OpenClaw：开源智能体框架
• §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 的工作原理、核心架构和基本概念，能够根据场景选择合适的模型。

1.1 什么是 LLM？

LLM（大语言模型，Large Language Model） 是指参数规模达到数十亿甚至万亿级别的语言模型，通过海量文本数据进行预训练（Pre-training），能够理解和生成自然语言、代码乃至多模态内容。

为什么 LLM 如此重要？ 传统 NLP 系统需要为每个任务单独训练模型——情感分析一个模型、命名实体识别又一个模型。LLM 打破了这一范式：一个模型通过预训练获得通用语言能力，再通过提示词或微调适配到具体任务，大幅降低了开发成本。

参数规模与能力的关系：

• 小模型（1B-7B）：适合本地部署、边缘设备、即时响应场景
• 中等模型（7B-70B）：具备较强的推理能力，适合私有化部署
• 大模型（70B+）：复杂推理与长任务表现通常更强，但成本、延迟和部署难度也更高

💡 选择建议：部署成本会随参数量、上下文长度和并发需求显著上升。建议先用 7B 到 8B 小模型验证 Pipeline，仅在推理能力触顶时再考虑 70B+ 模型。

1.2 Transformer 架构详解

LLM 的基础是 Transformer 架构，由 Google 在 2017 年的论文《Attention Is All You Need》中首次提出。Transformer 的核心是自注意力机制（Self-Attention），能够并行处理序列数据并建立长距离依赖关系。

为什么 Transformer 取代了 RNN？ RNN（循环神经网络）必须按顺序处理序列，导致两个致命问题：训练无法并行（速度慢）、长距离依赖容易丢失（梯度消失）。Transformer 通过自注意力机制一次性关注所有位置，既支持并行训练，又能捕捉远距离关联。

Transformer 架构演进图：

三种架构类型的特点：

自注意力机制直觉理解：

输入序列：["我", "喜欢", "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 越重要

💡 直觉：自注意力就像阅读理解时，你的目光在不同词语之间来回扫视——读到"它"时会回头看"它"指代的是什么。自注意力机制让模型能自动学会这种"回看"和"关联"。

延伸阅读：

• The Illustrated Transformer — Transformer 架构可视化解读（英文）
• Transformers 快速入门（中文） — 中文 Transformer 与 Hugging Face 生态教程

1.3 Decoder-Only 为什么是主流？

当前许多主流生成式语言模型，尤其是 GPT、Llama、Qwen、DeepSeek 等公开讨论较多的模型，都采用或接近 Decoder-Only 的自回归生成范式，原因如下：

深层原因：Decoder-Only 架构在训练时每个 token 的预测只依赖之前的 token，这种因果注意力（Causal Attention）与“不断续写下一个 token”的生成任务天然匹配。推理时，KV Cache 可以缓存已经计算过的 Key 和 Value，避免每一步都从头计算历史上下文。Encoder-Decoder 架构同样能做缓存优化，但 Decoder-Only 的训练目标、服务路径和扩展方式更统一，因此成为通用对话与代码生成模型的主流选择。

1.4 核心概念：Token 和上下文窗口

Token（词元） 是 LLM 处理文本的基本单位。一个 Token 可能是：

• 一个完整的单词（如 “hello”）
• 一个词的一部分（如 “token” 可能分成 “tok” 和 “en”）
• 一个标点符号
• 一个空格

上下文窗口（Context Window） 是 LLM 一次能处理的最大 Token 数量，决定了模型能够"记住"多少信息。

主流模型上下文窗口对比：

注意：上下文窗口是强版本相关参数，供应商会随模型更新调整。做架构设计时，以当前官方文档和实际 API 限额为准。

为什么上下文窗口很重要：

• 超出上下文窗口的内容需要截断或摘要，导致信息丢失
• “中间迷失（Lost in the Middle）“问题：模型对长文本中间部分的信息回忆能力较弱
• 更长的上下文意味着更高的计算成本（注意力计算的复杂度为 O(n²)）

1.5 练习

1. 理解型：用自己的话解释为什么 Decoder-Only 架构比 Encoder-Decoder 更适合文本生成任务。
2. 应用型：如果你需要构建一个客服对话系统，会选择多大参数规模的模型？为什么？
3. 分析型：假设你的应用需要处理 50 万字的文档，哪些模型可以满足需求？各自的成本如何？

1.6 自测检查

• 能解释 LLM 与传统 NLP 模型的核心区别
• 理解 Transformer 三种架构的适用场景
• 能说明 Decoder-Only 成为主流的原因
• 理解 Token 和上下文窗口对应用设计的影响

⬆️ 返回目录 | ⬇️ 下一节：Prompt Engineering

§2 Prompt Engineering：提示词工程 ⭐

学习目标：掌握核心提示词技巧，理解不同技巧的适用场景，能够编写高质量的提示词。

2.1 核心 Prompt 技巧

Prompt Engineering（提示词工程） 是通过设计高质量的输入提示词来引导 LLM 产生期望输出的技术。它是所有 AI 应用技术中投入产出比最高的一项——无需任何代码改动或模型训练，仅通过优化输入就能显著提升输出质量。

为什么提示词工程是第一优先级？ 在考虑微调或 RAG 之前，先尝试用提示词解决问题。很多看似需要复杂技术方案的问题，通过精心设计的提示词就能解决。提示词工程的成本几乎为零，而微调和 RAG 都需要额外的基础设施投入。

Few-Shot Learning（少样本学习）

通过在提示词中提供少量示例，让模型学习并复现特定的输出模式。

# 示例：翻译任务

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

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

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

Chain-of-Thought（思维链，CoT）

通过引导模型展示推理过程，提高复杂问题的解答准确率。

# 示例：数学问题

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

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

答案是 423

为什么 CoT 有效？ LLM 是自回归模型，每个 Token 的生成都依赖之前的 Token。当任务需要多步推理时，适度要求模型给出中间步骤、推理摘要或检查点，相当于为后续生成搭一层“脚手架”，减少一步跳到答案带来的错误。生产场景中不一定要暴露完整思维过程，更常见的做法是让模型输出可审计的简短理由或关键计算步骤。

Zero-Shot vs Few-Shot 对比

2.2 常见反模式

2.3 提示词工程实战：结构化提示词模板

一个高质量的结构化提示词通常包含以下要素：

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

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

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

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

# 代码
{待审查的代码}

💡 实践技巧：将提示词模板化后，可以通过 API 参数化传入不同内容，实现批量处理。这也是 Function Calling 和智能体系统的基础。

2.4 练习

1. 理解型：解释 Zero-Shot 和 Few-Shot 的核心区别，以及各自最适合的场景。
2. 应用型：为"代码审查助手"设计一个结构化提示词模板，包含角色、任务、约束和输出格式。
3. 分析型：以下提示词有什么问题？如何改进？"帮我写一篇关于 AI 的文章，要写好一点"

2.5 自测检查

• 能区分 Zero-Shot、Few-Shot 和 CoT 的适用场景
• 理解 CoT 提升推理准确率的原因
• 能识别并修复常见提示词反模式
• 能编写结构化的提示词模板

延伸阅读：

• OpenAI Prompt Guidance — OpenAI 官方提示词建议
• Claude Prompt Engineering — Claude 官方提示词指南

⬆️ 返回目录 | ⬆️ 上一节：LLM | ⬇️ 下一节：Fine-tuning

§3 Fine-tuning：微调技术 ⭐⭐⭐

学习目标：理解微调的原理和适用场景，掌握 LoRA 的核心思想，能够判断何时该用微调而非其他方案。

3.1 为什么需要微调？

虽然 LLM 在通用任务上表现出色，但在特定领域或任务上可能不够精准。Fine-tuning（微调） 通过在特定数据集上继续训练，使模型适应特定任务。

微调的典型应用场景：

• 特定行业的术语和表达方式（如医疗、法律）
• 特定的输出格式（如 JSON、代码规范）
• 特定的行为模式（如客服对话风格）

微调 vs 提示词工程 vs RAG——如何选择？ 实际工程中的决策优先级：

1. 先尝试提示词工程——成本最低，效果可能已经足够
2. 如果提示词无法解决格式或风格问题，考虑微调
3. 如果问题是知识过时或需要实时数据，选择 RAG
4. 如果同时需要特定行为和实时知识，考虑微调 + RAG组合

3.2 LoRA：低秩适配原理

LoRA（低秩适配，Low-Rank Adaptation） 是当前最流行的参数高效微调技术，核心思想是"只训练少量参数，而非整个模型”。

为什么 LoRA 能节省资源？

LoRA 的一个经验前提是：很多下游任务并不需要大幅改写基座模型的全部参数，任务适配可以被近似压缩到更低维的更新空间里。LoRA 用低秩矩阵分解来表示这个更新量：

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

直觉理解：想象你要调整一张高清照片的色调。全参数微调相当于重新绘制整张照片的每个像素；LoRA 相当于只调整"色温"和"色调"两个旋钮——虽然只有两个参数，但足以改变整张照片的感觉。这就是低秩的含义：用少量维度控制大量变化。

LoRA 矩阵分解图解：

示例推算：

• 当 d=4, r=2 时：可训练参数为 $4\times2 + 2\times4 = 16$ (占原始 $100%$)
• 当 d=4096, r=16 时：可训练参数为 $131K$ (仅占原始 $16M$ 的 $0.8%$)

70B 参数模型的微调资源对比：

💡 注意：上表只给资源量级，不是固定配置。实际显存取决于模型结构、精度、序列长度、batch size、梯度检查点、ZeRO/FSDP 等策略。7B 到 8B 模型的 LoRA / QLoRA 更适合个人或小团队做第一轮验证。

3.3 什么时候需要微调？

3.4 LoRA 实战配置示例

使用 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%

关键参数说明：

3.5 微调常见问题与排查

3.6 练习

1. 理解型：用直觉解释 LoRA 的低秩分解为什么有效。
2. 应用型：为一个"法律文书生成"任务选择合适的技术方案（提示词 vs 微调 vs RAG），并说明理由。
3. 分析型：以下 LoRA 配置可能存在什么问题？r=256, lora_alpha=32, target_modules=["q_proj"]

💡 答案提示：lora_alpha 通常设为 r 的 1~2 倍。当 r=256 时，若 alpha=32，整体缩放系数 32/256=0.125，会导致 LoRA 权重对主模型的影响过小，模型学习缓慢或停滞；同时仅作用于 q_proj 可能会错失调整重要注意力权重的机会。

3.7 自测检查

• 能解释微调与提示词工程、RAG 的选择逻辑
• 理解 LoRA 低秩分解的原理和直觉
• 能配置基本的 LoRA 训练参数
• 能排查微调过程中的常见问题

延伸阅读：

• LoRA 原始论文 — Low-Rank Adaptation 原理
• PEFT 官方文档 — Hugging Face 参数高效微调库

⬆️ 返回目录 | ⬆️ 上一节：Prompt Engineering | ⬇️ 下一节：RAG

§4 RAG：检索增强生成 ⭐⭐

学习目标：理解 RAG 的工作原理和核心组件，掌握 RAG 与其他方案的适用场景对比，能够搭建基础 RAG 系统。

4.1 RAG 核心原理

RAG（检索增强生成，Retrieval-Augmented Generation） 通过结合外部知识库来增强 LLM 的回答质量，解决模型知识过时和幻觉（Hallucination）问题。

为什么需要 RAG？ LLM 的知识来自训练数据的截止日期，无法获取实时信息。同时，LLM 可能"幻觉"出看似合理但实际错误的内容。RAG 通过在生成回答前先检索相关文档，让模型基于真实数据回答，从根本上解决这两个问题。

RAG 工作流程：

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

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

4.2 RAG vs 其他方案对比

4.3 RAG 关键技术组件

一个完整的 RAG 系统由四个核心组件构成，每个组件都有多种技术选型。选型时需权衡数据量、响应延迟与成本：

RAG 数据流详解：

🚀 进阶演进：从 Naive RAG 到架构升级

• Agentic RAG：不再是单一的“把问题转成向量并去查”，而是让 Agent 根据用户提问自主决定查哪些库、生成什么查询关键字，甚至发现信息不够时主动发起多次查询。
• GraphRAG（图 RAG）：通过知识图谱（Knowledge Graph）将文档实体和关系抽取出来，除了做局部事实检索还能回答全局性的总结（如“总结这家公司去年的核心战略变动”），常作为向量搜索的强力补充。

为什么需要重排序？ 初次检索基于向量相似度，可能返回语义相近但实际不相关的文档。重排序模型（Re-Ranker）使用更精细的交叉编码器（Cross-Encoder），对查询和每个候选文档进行深度相关性评分，显著提升检索精度。

4.4 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)

4.5 RAG 常见问题与排查

4.6 练习

1. 理解型：解释 RAG 为什么能缓解幻觉问题，以及它的局限性。
2. 应用型：为一个"公司内部文档问答系统"设计 RAG 架构，说明各组件的选择。
3. 分析型：如果 RAG 系统返回了正确文档但 LLM 仍然给出了错误答案，可能是什么原因？

4.7 自测检查

• 能解释 RAG 的工作流程和每个组件的作用
• 理解 RAG 与微调、纯 LLM 的适用场景区别
• 知道为什么需要重排序以及它的工作原理
• 能排查 RAG 系统的常见问题

延伸阅读：

• RAG 从原理到实践 — LlamaIndex 官方 RAG 概念指南
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — RAG 原始论文

⬆️ 返回目录 | ⬆️ 上一节：Fine-tuning | ⬇️ 下一节：Function Calling 与 MCP

§5 Function Calling 与 MCP ⭐⭐⭐

学习目标：理解 Function Calling 的工作机制，掌握 MCP 协议的核心价值，能够实现基础的工具调用功能。

5.1 Function Calling：让 LLM 调用工具

Function Calling（函数调用） 是 LLM 与外部世界交互的基础能力，允许模型根据对话上下文决定调用哪个外部工具或 API。

为什么需要 Function Calling？ LLM 本身只能生成文本，无法执行实际操作——查不了天气、调不了 API、读不了数据库。Function Calling 让模型能够"输出意图”（我想调用哪个函数、传什么参数），由应用层负责实际执行，再将结果返回给模型继续推理。这使 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": "北京"}'

关键点：模型不会直接执行函数，它只是输出函数名和参数。你需要自己实现函数执行逻辑，并将结果通过 tool 角色消息返回给模型。

5.2 MCP：开放标准的智能体通信协议

MCP（模型上下文协议，Model Context Protocol） 是 Anthropic 提出的开放标准，旨在解决智能体与外部工具连接时的标准化问题。

为什么需要 MCP？ Function Calling 通常是模型供应商或应用框架内的工具调用格式，不同生态在工具定义、参数约束、返回格式上并不完全一致。MCP 把工具、资源和提示能力抽象成独立服务，让应用可以用更稳定的协议连接外部能力。它不能自动消除所有模型差异，但能显著降低工具接入和复用成本。

MCP vs Function Calling 对比：

5.3 Function Calling 与 MCP 常见问题与排查

5.4 练习

1. 理解型：解释 Function Calling 中"模型不直接执行函数"的设计决策有什么好处。
2. 应用型：为一个"日程管理助手"设计 Function Calling 的工具定义（至少 3 个函数）。
3. 分析型：MCP 的"动态发现"能力在什么场景下特别有价值？

5.5 自测检查

• 理解 Function Calling 的完整调用流程
• 能编写 Function Calling 的工具定义
• 理解 MCP 解决的核心痛点
• 能排查 Function Calling 的常见问题

延伸阅读：

• OpenAI Function Calling 指南 — OpenAI 官方函数调用文档
• MCP 规范文档 — Model Context Protocol 完整规范

⬆️ 返回目录 | ⬆️ 上一节：RAG | ⬇️ 下一节：Agent

§6 Agent：智能体架构 ⭐⭐⭐

学习目标：理解智能体的核心公式和执行循环，掌握主流智能体框架的特点，能够设计基础智能体系统。

6.1 智能体核心公式

Agent（智能体） 是能够自主感知环境、做出决策并执行动作的 AI 系统。核心公式：

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

为什么需要智能体？ 单纯的 LLM 只能一问一答，无法处理需要多步骤、多工具协作的复杂任务。比如"帮我调研竞品并生成报告"，需要搜索信息、整理数据、撰写文档——这些步骤需要智能体自主规划和执行。

各组件职责：

6.2 智能体循环：思考-行动-观察

智能体通过不断循环"思考-行动-观察"来完成任务：

为什么是循环而不是单次调用？ 现实任务充满不确定性——工具调用可能失败、搜索结果可能不完整、用户需求可能在执行中变化。循环机制让智能体能够根据观察结果动态调整策略，而不是盲目执行预设计划。

ReAct 模式详解：

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，湿度适中，非常适合户外运动！
        推荐活动：跑步、骑行、徒步。

6.3 主流智能体框架

智能体框架的选择取决于你的应用场景和技术偏好。以下四个框架各有侧重，建议根据项目需求选择。

框架选择建议：如果你刚开始学习智能体开发，建议从 LangChain 入手——文档最全、社区最大。如果你的应用以知识检索为核心，LlamaIndex 更专业。如果需要多智能体协作，CrewAI 的抽象更直观。

6.4 Agent 常见问题与排查

6.5 练习

1. 理解型：解释智能体循环中"观察"步骤为什么不可或缺。
2. 应用型：为一个"代码审查智能体"设计 Planning 策略和所需工具列表。
3. 分析型：智能体在什么情况下应该选择 Plan-and-Execute 而非 ReAct？

6.6 自测检查

• 能解释智能体核心公式中每个组件的作用
• 理解思考-行动-观察循环的设计原因
• 能根据场景选择合适的智能体框架
• 能排查智能体的常见问题

延伸阅读：

• ReAct 论文 — Reasoning and Acting 范式的原始论文
• LangChain Agent 文档 — LangChain 智能体概念与实现

⬆️ 返回目录 | ⬆️ 上一节：Function Calling 与 MCP | ⬇️ 下一节：Multi-Agent

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

学习目标：理解多智能体系统的协作模式和适用场景，能够使用 CrewAI 搭建基础的多智能体应用。

7.1 为什么需要 Multi-Agent？

当任务复杂到单智能体无法高效处理时，Multi-Agent 系统通过多个专业智能体的协作来解决问题。

为什么不让一个智能体做所有事？ 单智能体面临三个瓶颈：上下文窗口有限（塞不下所有信息）、专业能力有限（难以同时精通编程和设计）、错误累积（一步错步步错）。Multi-Agent 让每个智能体只负责自己擅长的部分，通过分工降低单智能体的认知负担。

单智能体 vs Multi-Agent 场景分析：

7.2 Multi-Agent 协作模式

多智能体系统的协作方式决定了信息流向和决策机制。三种常见模式各有适用场景，每种模式在控制力与灵活性上各有侧重：

三种协作模式图解：

7.3 Multi-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()

代码解读：每个智能体通过 role、goal、backstory 三个维度定义其"人格"和专长。CrewAI 会根据任务描述自动将任务分配给最合适的智能体，并管理智能体之间的信息传递。

7.4 Multi-Agent 常见问题与排查

7.5 练习

1. 理解型：解释层级模式和协作模式的核心区别，以及各自最适合的任务类型。
2. 应用型：为一个"软件需求分析到代码实现"的流程设计 Multi-Agent 团队（至少 3 个智能体）。
3. 分析型：在什么情况下 Multi-Agent 的开销会超过收益？如何判断？

7.6 自测检查

• 能解释为什么需要 Multi-Agent 而非单智能体
• 理解三种协作模式的特点和适用场景
• 能使用 CrewAI 搭建基础的多智能体系统
• 能判断何时该用 Multi-Agent、何时该用单智能体

⬆️ 返回目录 | ⬆️ 上一节：Agent | ⬇️ 下一节：Workflow Engineering

§8 Workflow Engineering：工作流编排 ⭐⭐⭐

学习目标：理解为什么仅有智能体还不够，掌握编排模式（基于图、基于流水线），能够使用 LangGraph 或 Dify 等工具编排可靠的复合 AI 任务。

8.1 为什么需要 Workflow？

Workflow Engineering（工作流编排） 是将多个智能体（Agents）、提示词链（Prompt Chains）和外部工具通过确定性的有向图（Graph）或流水线组织起来的技术。

如果已经有了多智能体（Multi-Agent），为什么还需要 Workflow？ 在真实的生成式 AI 生产应用中，智能体的“自主任性”是一把双刃剑。让智能体完全自主规划（如完全的 ReAct）可能导致失控、死循环或者极度不可控的 API 成本。Workflow 引入了**“确定性控制”（Deterministic Control）**：把系统的大方向（即业务流程）写死，只在具体的节点内让 LLM 发挥灵活性。

💡 工程经验：生产环境中的智能系统通常不能只依赖“智能体自由发挥”。越接近真实业务，越需要把权限、状态、分支、重试、人工确认和退出条件写进确定性流程里。

8.2 核心编排模式

工作流不仅是“先后执行”，更包含复杂的条件流、循环流和状态管理。

8.3 Workflow 实战框架对比

8.4 Workflow 常见问题与排查

8.5 练习

1. 理解型：为什么在某些金融合规审查应用中，使用具有强约束的 Workflow 比让一个智能体完全“自主决策”更靠谱？
2. 应用型：为一个“求职简历投递助手”设计 Workflow 图，包含（信息提取 -> 职位匹配 -> 打分评价 -> 若不合格则重写 -> 投递确认）。
3. 分析型：LangGraph 这类基于有向图编排的库相比于传统的业务链代码有什么天然优势？

8.6 自测检查

• 理解为什么 Workflow 是弥补智能体不可控性的关键
• 掌握主要的四个编排模式（Chain / Routing / Parallel / State Graph）
• 了解界面级的工作流工具和代码级工具的区别

⬆️ 返回目录 | ⬆️ 上一节：Workflow Engineering | ⬇️ 下一节：Context Engineering

§9 Context Engineering：上下文工程 ⭐⭐⭐

学习目标：理解上下文管理的核心挑战，掌握上下文优化策略，能够为智能体系统设计高效的上下文管理方案。

9.1 上下文工程的挑战

随着智能体系统变得越来越复杂，如何高效管理和利用上下文成为关键挑战。Context Engineering（上下文工程） 是系统性解决这一问题的工程实践。

为什么上下文工程越来越重要？ 智能体的能力很大程度上取决于它能"看到"什么信息。上下文窗口是有限的资源——塞入太多无关信息会干扰推理，塞入太少关键信息又会导致决策失误。上下文工程就是研究如何在这个有限空间内放入最有价值的信息。

三大核心挑战：

9.2 上下文优化策略

在实际应用中，通常需要组合以下策略以达到最佳的上下文控制效果：

结构化模板示例：

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

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

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

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

💡 为什么用 XML 而非自然语言？ 结构化标记让模型能精确区分"任务描述"、“背景信息"和"约束条件”，减少歧义。Anthropic 的官方文档也推荐使用 XML 标签来组织提示词。

9.3 “中间迷失”问题

斯坦福大学 2023 年的研究论文《Lost in the Middle: How Language Models Use Long Contexts》系统性地揭示了这一现象：当关键信息位于长上下文的中间位置时，LLM 的召回率显著下降，即使模型声称支持超长上下文窗口。这被称为 “Lost in the Middle”（中间迷失） 问题。

为什么会出现中间迷失？ 目前常见解释包括注意力分布偏好和训练数据位置偏差：模型处理长序列时，开头和结尾更容易获得有效关注，而训练语料中的关键信息也常出现在文档起止位置。这不是所有模型、所有任务上的铁律，但足够影响长上下文应用的设计。

缓解方法：

• 将重要信息放在上下文的开头或结尾
• 使用"自底向上"的检索策略
• 采用重排序（Re-Ranker）确保关键信息靠前
• 将长上下文拆分为多个短上下文，分别处理后再汇总

9.4 练习

1. 理解型：解释"中间迷失"现象的可能原因，以及为什么将重要信息放在开头或结尾更有效。
2. 应用型：为一个"长对话客服智能体"设计上下文管理策略，包括何时摘要、如何保留关键信息。
3. 分析型：结构化模板（如 XML）相比自然语言描述，在什么场景下优势最明显？

9.5 自测检查

• 能解释上下文工程的三大核心挑战
• 理解各优化策略的适用场景
• 知道如何使用结构化模板组织上下文
• 理解"中间迷失"问题及其缓解方法

延伸阅读：

• Lost in the Middle 论文 — 斯坦福大学关于长上下文信息检索的研究
• Claude Prompt Engineering Best Practices — Claude 提示词最佳实践

⬆️ 返回目录 | ⬆️ 上一节：Workflow Engineering | ⬇️ 下一节：Agent Skill

§10 Agent Skill：智能体技能 ⭐⭐⭐

学习目标：理解 Skill 的标准结构和核心优势，掌握 Skill 的设计原则，能够开发基础的可复用技能。

10.1 Skill 是什么？

Agent Skill（智能体技能） 是将特定功能封装为可复用单元的标准格式，使得智能体能够快速获取新能力。

为什么需要 Skill？ 没有 Skill 机制时，给智能体添加新功能意味着修改智能体核心代码——每个新工具都要硬编码到系统中。Skill 将功能封装为独立模块，智能体可以像安装插件一样动态获取新能力，无需修改核心逻辑。

Skill 的标准结构：

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

SKILL.md 核心要素：

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

# Code Reviewer Skill

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

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

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

10.2 Skill 的核心优势

10.3 OpenClaw Skill 生态

OpenClaw 是当前活跃的开源智能体框架之一。它支持通过 workspace skills 扩展能力，并在文档中把 ClawHub 作为 Skill registry 入口。Skill 生态通常覆盖下面几类能力：

⚠️ 事实性声明：Skill 市场的数量、分类和可用性变化很快。写自动化方案时，应以 OpenClaw 文档、仓库 README 和 ClawHub 当前页面为准。

• 生产力工具（邮件、日历、文档）
• 编程辅助（代码审查、自动化测试）
• 数据分析（数据库查询、可视化）
• 消息平台集成（Telegram、Discord、Slack）

10.4 练习

1. 理解型：解释 Skill 机制相比硬编码工具的核心优势。
2. 应用型：为一个"数据库查询助手"设计 Skill 结构，包括 SKILL.md 和工具脚本。
3. 分析型：Skill 的版本管理在团队协作中可能遇到什么问题？如何解决？

10.5 自测检查

• 理解 Skill 的标准结构和各文件的作用
• 能编写基本的 SKILL.md 定义文件
• 理解 Skill 相比传统方式的核心优势
• 了解 Skill 生态和分发方式

延伸阅读：

• OpenClaw Skills 仓库 — 社区 Skill 集合
• ClawHub — OpenClaw Skill registry

⬆️ 返回目录 | ⬆️ 上一节：Context Engineering | ⬇️ 下一节：OpenClaw

§11 OpenClaw：开源智能体框架 ⭐⭐⭐⭐

学习目标：了解 OpenClaw 的核心架构和特点，能够完成 OpenClaw 的安装和基础配置。

11.1 OpenClaw 简介

OpenClaw 是一个开源的个人 AI 助手与自托管 Gateway，目标是把 Telegram、Discord、Slack、WhatsApp、iMessage 等消息入口连接到本地或自托管的 AI Agent。它更像一个“多渠道入口 + Gateway 控制平面 + Agent 工作区”的组合，而不是单纯的 LLM SDK。

⚠️ 事实性声明：OpenClaw 的渠道支持、Skill registry、CLI 命令和推荐 Node.js 版本都在快速变化。本文只保留架构层面的学习价值，具体安装参数请以 OpenClaw 文档 和 GitHub README 为准。

OpenClaw 核心特点：

OpenClaw 的设计理念可以概括为“自托管 Gateway、多渠道入口、Agent-native”。与只提供云端对话窗口的服务不同，它强调用户自己运行 Gateway，把常用消息平台、工具、会话、Skill 和 Agent 路由纳入同一套控制平面。

为什么要学习 OpenClaw？ 它适合作为“Agent 如何进入真实消息入口”的案例：消息入口、Gateway、会话隔离、权限、安全策略和 Skill 分发会同时出现。如果只是写一个后端 Agent 服务，LangChain、LangGraph 或 LlamaIndex 往往更直接；如果要把 Agent 接进用户每天使用的聊天渠道，OpenClaw 这类框架更能暴露生产环境里的复杂度。

11.2 OpenClaw 架构

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

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

11.3 快速开始 OpenClaw

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

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

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

# 打开本地控制台
openclaw dashboard

11.4 OpenClaw 常见问题与排查

11.5 练习

1. 理解型：解释 OpenClaw 的 Gateway 架构为什么适合多平台接入。
2. 应用型：在本地安装 OpenClaw 并配置一个聊天平台接入（如 Telegram）。
3. 分析型：OpenClaw 的"本地优先"设计在什么场景下是关键优势？什么场景下可能是劣势？

11.6 自测检查

• 了解 OpenClaw 的核心特点和架构
• 能完成 OpenClaw 的安装和基础配置
• 理解 Gateway 在架构中的作用
• 能排查 OpenClaw 的常见安装和配置问题

延伸阅读：

• OpenClaw 官方文档 — 安装、配置和使用指南
• OpenClaw GitHub — 源码和 Issue 追踪

⬆️ 返回目录 | ⬆️ 上一节：Agent Skill | ⬇️ 下一节：Harness Engineering

§12 Harness Engineering：评估工程 ⭐⭐⭐⭐

学习目标：理解评估工程的核心思想，掌握评估集设计原则，能够为智能体系统建立系统化评估流程。

12.1 什么是 Harness Engineering？

Harness Engineering（评估工程） 是一种构建可靠 AI 智能体的工程实践，核心思想是"通过系统化评估来驱动智能体开发"。

为什么评估工程是必需的？ 传统软件有单元测试和集成测试来保证质量，但 AI 智能体的输出是非确定性的——同样的输入可能产生不同结果。你很难用传统的“断言匹配”来测试非确定性的模型输出。评估工程提供了一套适合 AI 系统的测试方法论：用评估集定义期望行为，用评分标准量化输出质量，用迭代评估驱动持续改进。

传统软件工程与评估工程的对比：

12.2 评估集设计原则

评估集是评估工程的核心资产。评估集是对“系统底线行为”的量化定义。设计时需兼顾覆盖面与边界深度：

一个好的评估集应该包含：

评估集示例：

[
  {
    "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"
  }
]

12.3 主流评估框架

目前市面上有多种评估框架，各有侧重。选择时需要考虑你的技术栈（是否使用 LangChain）、评估对象（RAG 系统还是通用智能体）以及团队规模。

评估驱动的开发流程：

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

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

💡 最佳实践：在修改任何提示词或智能体配置之前，先确保评估集能反映当前系统的表现。修改后立即运行评估，量化改进效果。没有评估集的优化，就像没有指南针的航行。

12.4 练习

1. 理解型：解释为什么传统单元测试不适合 AI 智能体，评估工程如何解决这一问题。
2. 应用型：为一个"客服智能体"设计包含 5 个用例的评估集，覆盖不同难度。
3. 分析型：评估集的"多样性"和"边界案例"有什么区别？为什么两者都需要？

12.5 自测检查

• 理解评估工程的核心思想和与传统测试的区别
• 能设计包含多样性、边界案例和难度标签的评估集
• 了解主流评估框架的特点和适用场景
• 理解评估驱动的开发流程

延伸阅读：

• OpenAI Evals 框架 — OpenAI 官方评估工具
• RAGAS 文档 — RAG 系统评估方法论

⬆️ 返回目录 | ⬆️ 上一节：OpenClaw

学习路线总结

入门阶段（第 1-2 个月）

进阶阶段（第 3-4 个月）

专家阶段（第 5-6 个月）

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

最后，用一个企业知识库问答智能体把 RAG、Function Calling 与 Agent 循环串起来。这个示例重点展示控制流和安全边界，真实项目还需要补充鉴权、审计、限流、数据权限和监控。

系统架构

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

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

核心代码实现

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"
  }
]

⬆️ 返回目录

常见问题 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 架构将上下文分散到不同智能体。

推荐学习资源

官方文档与论文

在线学习平台

开源项目推荐

进阶路径指引

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

路径 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 等自主智能体架构

核心术语表

⬆️ 返回目录

文档元信息：

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