1. 这套Agent Skills课程到底在讲什么
先把话说在前头：这不是那种“三天速成大模型专家”的营销课。我花了半个月时间，把市面上关于Agent Skills的零散知识重新梳理成一条从零到能上手的路径，核心目标只有一个——让你学完之后，能自己搭出一个真正能干活的Agent，而不是只会背概念。
这套内容覆盖的主线很清晰：大模型基础认知 → Prompt工程 → LangChain框架 → RAG检索增强 → Agent Skills设计与编排 → 微调入门 → 部署与落地。关键词里出现的Agent Skills、LLM、LangChain、RAG，每一个我都会拆开讲透，不跳步、不默认你有基础。
适合谁看？如果你是完全零基础，连“大模型”和“API”都分不清，那从第2章开始按顺序看就行。如果你已经会调API、写过简单的LangChain链，那可以直接跳到第4章RAG和第5章Agent Skills，那里才是真正拉开差距的地方。我见过太多人卡在“会调接口但做不出产品”这个阶段，这套内容就是冲着解决这个问题去的。
有一点必须提前说清楚：学完能就业，前提是你真的动手把每个环节跑一遍。光看不动手，学十遍也没用。我在每一章都留了可复现的操作步骤和参数说明，你照着做，踩的坑会比我当年少很多。
2. 大模型与LLM基础：别急着写代码，先把底层逻辑搞明白
2.1 LLM到底是什么，用生活化的方式理解
LLM就是Large Language Model，大语言模型。你可以把它想象成一个读了海量文本的“超级接话高手”——你给它一段话，它根据训练时见过的模式，预测下一个最可能出现的词，一个词一个词往外蹦，最后拼成一段完整的回答。
这里有个关键概念叫Token。Token不是字，也不是词，而是模型处理文本的最小单位。英文里大概4个字符算1个Token，中文里差不多1到2个字算1个Token。为什么要知道这个？因为API计费按Token算，模型上下文窗口也按Token算。你写一段500字的中文提问，大概消耗300到500个Token，加上模型回复，一次对话轻松上千Token。心里有这本账，你才知道怎么控制成本。
热搜词里有个很有意思的说法：“LLM的token三个点key我是谁、query我在找什么、value我能提供什么”。这其实是在用注意力机制的Key-Query-Value来类比Token之间的关系。通俗讲，模型在处理每个Token时，会问三个问题：这个Token是什么身份（Key）、当前我在找什么信息（Query）、它能提供什么内容（Value）。理解这个，你就理解了为什么大模型能“记住”上下文——它不是真的记住了，而是每次都在重新计算Token之间的关联权重。
2.2 大模型的能力边界在哪里
很多人对大模型的期待是“无所不能”，结果一用就失望。我先把边界划清楚：
- 擅长的事：文本生成、总结归纳、翻译、代码补全、问答、格式转换。
- 不擅长的事：精确计算（尤其是大数运算）、实时信息获取（训练数据有截止日期）、事实性核查（会一本正经胡说八道）。
- 完全做不到的事：访问你本地的私有数据（除非你通过RAG或微调喂给它）。
知道边界之后，你就明白为什么需要RAG和Agent Skills了。RAG解决“私有数据”问题，Agent Skills解决“多步骤复杂任务”问题。这两个是后面章节的核心，这里先埋个伏笔。
2.3 主流模型选型：别只盯着一个
2026年的模型格局已经和两年前完全不同。我按使用场景给你分个类：
| 场景 | 推荐方向 | 理由 |
|---|---|---|
| 本地开发调试 | Ollama部署的开源模型 | 免费、数据不出本地、方便反复试 |
| 生产环境高并发 | 商业API（多家对比） | 稳定、免运维、按量付费 |
| 中文任务为主 | 国产开源模型 | 中文语料充分、社区活跃 |
| 多模态需求 | 支持视觉的模型 | 能处理图片、图表、扫描件 |
我个人的做法是：开发阶段用Ollama跑本地模型，快速迭代Prompt和逻辑；上线前切换到商业API做压力测试和效果对比。这样既省成本，又不会被单一供应商锁死。
注意：不要一上来就追求“最强模型”。很多任务用7B参数的小模型就能跑得很好，盲目上大模型只会让你的账单爆炸。
3. LangChain入门：把大模型从玩具变成工具
3.1 为什么需要LangChain
直接调大模型API，你得到的是一个“输入文本、输出文本”的黑盒。但真实业务里，你需要的是：从数据库取数据、调用外部工具、记住对话历史、按条件分支执行。这些用裸API写，代码会又长又乱。
LangChain就是干这个的——它把大模型相关的常见操作抽象成标准组件，让你像搭积木一样组合。核心组件包括：
- Model：统一不同大模型的调用接口
- Prompt Template：管理提示词模板，支持变量注入
- Chain：把多个步骤串成一条流水线
- Memory：管理对话历史
- Retriever：从知识库检索相关内容
- Agent：让模型自己决定调用哪个工具
我刚开始学的时候觉得LangChain封装太厚，不如直接调API清爽。但当我需要做一个“根据用户问题自动查数据库、再生成回答”的功能时，裸API写了200多行，用LangChain只用了30行。这就是抽象的价值。
3.2 第一个可运行的LangChain程序
别急着搞复杂的，先把最小闭环跑通。以下代码用Ollama本地模型演示：
from langchain_community.llms import Ollama from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser # 1. 初始化模型 llm = Ollama(model="qwen2.5:7b", base_url="http://localhost:11434") # 2. 定义提示词模板 prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个专业的技术助手，回答要简洁准确。"), ("user", "{question}") ]) # 3. 组装链 chain = prompt | llm | StrOutputParser() # 4. 调用 result = chain.invoke({"question": "什么是RAG？用三句话解释。"}) print(result)这段代码的关键在于|符号，这是LangChain的管道操作符，把提示词、模型、输出解析器串成一条链。数据从左往右流，每一步的输出是下一步的输入。理解这个管道模型，后面学LangGraph和Agent编排会轻松很多。
3.3 LangChain中文教程里不会告诉你的坑
坑一：版本兼容性。LangChain迭代极快，网上很多教程用的是0.1版本，你装0.3版本跑不起来。我的建议是锁定版本，在requirements.txt里写死，比如langchain==0.3.x。
坑二：Ollama连接超时。本地模型首次加载需要时间，默认超时可能不够。可以在初始化时加timeout=120参数。
坑三：输出解析器报错。如果模型返回的格式和解析器预期不一致，会直接抛异常。生产环境一定要加try-except，并准备降级方案。
实操心得：每次升级LangChain版本前，先在独立虚拟环境里跑一遍核心链路，确认没问题再更新主环境。我因为版本升级导致线上服务挂过一次，教训深刻。
4. RAG检索增强：让大模型用上你的私有数据
4.1 RAG到底解决了什么问题
大模型有两个硬伤：一是训练数据有截止日期，二是不知道你的私有文档。RAG（Retrieval-Augmented Generation，检索增强生成）的思路很直接：用户提问时，先去你的知识库里找相关内容，把找到的内容和问题一起塞给大模型，让它基于这些内容回答。
打个比方：大模型是一个博学但没看过你公司内部文档的专家。RAG就是每次提问前，先派一个助理去档案室找出相关文件，递给专家参考，专家再作答。助理找得准不准，直接决定回答质量。
4.2 RAG知识库能存储图片吗
这是热搜里很多人问的问题。答案是：可以，但需要额外处理。标准RAG流程处理的是文本，图片需要先经过多模态模型转成文字描述，或者用支持图文混合检索的方案。
具体做法有两种：
- 图片转文字：用多模态模型对图片生成描述，把描述文本存入向量库。检索时匹配到描述，再关联回原图。
- 多模态向量：用支持图文统一编码的模型，把图片和文本映射到同一向量空间，直接做跨模态检索。
第一种方案实现简单，适合大多数场景。第二种效果好但工程复杂度高，建议有经验后再尝试。
4.3 从零搭建一个本地RAG知识库
以下步骤用Ollama加Chroma向量库，零基础可复制：
第一步：准备文档。把你要入库的文件（PDF、TXT、Markdown）放到一个文件夹里。
第二步：文档加载与切分。
from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader = DirectoryLoader("./docs", glob="**/*.md") docs = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) chunks = splitter.split_documents(docs)这里chunk_size=500表示每段最多500字符，chunk_overlap=50表示相邻段重叠50字符。重叠是为了避免关键信息刚好被切断。分隔符按优先级排列，优先在段落处切，其次在句子处切。
第三步：向量化并存入向量库。
from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma embeddings = OllamaEmbeddings(model="nomic-embed-text") vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db" )第四步：检索并生成回答。
retriever = vectorstore.as_retriever(search_kwargs={"k": 3}) relevant_docs = retriever.invoke("你的问题") context = "\n\n".join([doc.page_content for doc in relevant_docs])把context和问题一起塞进Prompt，大模型就能基于你的文档回答了。
4.4 RAG瓶颈与hit rate优化
RAG最常见的瓶颈是检索命中率（hit rate）低——该找的没找到，或者找到的不相关。我踩过的坑和对应的解法：
| 问题现象 | 可能原因 | 解决方向 |
|---|---|---|
| 检索结果完全不相关 | 切分粒度太粗 | 减小chunk_size，增加overlap |
| 关键信息漏检 | 嵌入模型不适合中文 | 换用中文优化的嵌入模型 |
| 相似问题检索不到 | 用户表述和文档差异大 | 加入查询改写，先让模型扩写问题 |
| 返回太多无关内容 | k值太大 | 减小k，或加相似度阈值过滤 |
| 多跳问题答不好 | 单次检索不够 | 改用多轮检索或Agentic RAG |
实操心得：调RAG效果时，先固定生成模型，只调检索部分。每次只改一个参数（chunk_size、k值、嵌入模型），记录hit rate变化。我见过有人同时改五个参数，结果好了也不知道为什么好，坏了也不知道为什么坏。
5. Agent Skills核心：让大模型自己决定怎么干活
5.1 Agent和普通Chain的本质区别
普通Chain是你写死的流程：先做A，再做B，再做C。Agent是你给它一个目标，它自己决定先做什么、后做什么、用什么工具。
举个例子。普通Chain像流水线工人，你告诉他“先拧螺丝再喷漆”；Agent像包工头，你告诉他“把这面墙刷白”，他自己判断需要先铲灰、再刮腻子、再刷漆，缺工具还会找你要。
Agent Skills就是给这个包工头配备的“技能包”——每个Skill是一个可调用的工具或能力，Agent根据任务需要自主选择。
5.2 Agent的核心组成
一个完整的Agent包含四部分：
- 大脑（LLM）：负责推理和决策
- 工具（Tools）：可调用的外部能力，如搜索、计算、查数据库
- 记忆（Memory）：短期记忆存对话历史，长期记忆存向量库
- 规划（Planning）：把复杂任务拆成子步骤
LangChain里创建Agent的基本方式：
from langchain.agents import create_react_agent, AgentExecutor from langchain_community.tools import DuckDuckGoSearchRun tools = [DuckDuckGoSearchRun()] agent = create_react_agent(llm, tools, prompt) executor = AgentExecutor(agent=agent, tools=tools, verbose=True) executor.invoke({"input": "帮我查一下今天有什么AI新闻"})verbose=True会打印Agent的思考过程，调试时非常有用。你能看到它先想“我需要搜索”，然后调用搜索工具，再根据结果决定下一步。
5.3 Agent Skills设计原则
设计Skill时，有几个原则必须遵守：
原则一：单一职责。一个Skill只做一件事。不要设计一个“万能查询工具”，而是拆成“查用户信息”“查订单信息”“查库存信息”三个独立Skill。这样Agent更容易选对。
原则二：描述清晰。Skill的description字段是Agent选择工具的唯一依据。描述要写清楚“这个工具做什么、什么时候用、输入什么、输出什么”。我见过有人描述只写“查询工具”，结果Agent从来不调用它。
原则三：错误可恢复。Skill执行失败时，要返回明确的错误信息，而不是直接抛异常。Agent看到错误信息后可以尝试其他方案。
原则四：幂等性。同一个Skill用相同参数调用多次，结果应该一致。涉及写操作的Skill要特别小心，最好加确认机制。
5.4 多Agent协作与LangGraph
当任务复杂到单个Agent搞不定时，就需要多Agent协作。LangGraph是LangChain生态里做这个事的框架，它把Agent的执行流程建模成一张图，节点是Agent或工具，边是流转条件。
典型的多Agent模式：
- 主管模式：一个主管Agent负责拆解任务，分派给专业Agent，最后汇总结果。
- 流水线模式：Agent A的输出是Agent B的输入，依次传递。
- 辩论模式：多个Agent对同一问题给出方案，互相评审，选出最优。
LangGraph的核心概念是State（状态）和Node（节点）。State在节点之间传递，每个节点读取State、执行逻辑、写回State。这种设计让复杂流程变得可追踪、可调试。
注意：不要为了用多Agent而用多Agent。我见过一个简单问答任务硬是拆成三个Agent，结果延迟翻了三倍，效果还不如单Agent。先用单Agent，确实不够用了再考虑多Agent。
6. 大模型微调入门：什么时候该微调，什么时候不该
6.1 微调不是万能药
很多人一遇到效果不好就想微调。但微调成本高、周期长、效果不一定好。先问自己三个问题：
- 问题是模型不知道知识，还是不知道格式？不知道知识用RAG，不知道格式用Prompt。
- 有没有足够的标注数据？至少几百条高质量样本，少了没效果。
- 有没有算力？全量微调需要多卡GPU，LoRA微调单卡也能跑但需要调参。
我的经验是：80%的场景用Prompt加RAG就能解决，只有20%确实需要微调。那20%通常是：需要特定输出风格、需要模型掌握专业术语、需要极低延迟（微调后可以用小模型）。
6.2 LoRA微调实操要点
LoRA（Low-Rank Adaptation）是目前最流行的轻量微调方法。原理是在原模型旁边加一个小矩阵，只训练这个小矩阵，不动原模型参数。这样显存需求大幅降低，单张消费级显卡就能跑。
关键参数：
| 参数 | 含义 | 建议值 |
|---|---|---|
| r | 低秩矩阵的秩 | 8-64，越大容量越强但越容易过拟合 |
| lora_alpha | 缩放系数 | 通常设为r的2倍 |
| lora_dropout | 丢弃率 | 0.05-0.1 |
| learning_rate | 学习率 | 1e-4到3e-4 |
| num_epochs | 训练轮数 | 3-5，多了过拟合 |
数据格式通常是instruction-input-output三元组。数据质量比数量重要，100条精标数据胜过1000条脏数据。
6.3 微调后的评估
微调完不能只看loss曲线，要做实际评估。我通常从三个维度评：
- 格式遵循：输出是否符合预期格式
- 内容准确：事实性是否正确
- 泛化能力：换一批没见过的输入，效果是否稳定
评估集要提前留好，不能拿训练数据评估，那是自欺欺人。
7. 部署与落地：从能跑到能用
7.1 本地部署方案
Ollama是目前最省心的本地部署工具。安装后一条命令就能拉模型：
ollama pull qwen2.5:7b ollama serve默认监听11434端口，LangChain直接连就行。优点是简单，缺点是并发能力弱，适合开发和单用户场景。
需要更高性能可以用vLLM或TGI，支持连续批处理和PagedAttention，吞吐量能提升好几倍。但配置复杂一些，需要根据显卡型号调参数。
7.2 API服务封装
用FastAPI把Agent封装成HTTP服务：
from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Query(BaseModel): question: str @app.post("/ask") async def ask(query: Query): result = executor.invoke({"input": query.question}) return {"answer": result["output"]}加上流式输出、超时控制、错误重试，就是一个可用的服务了。
7.3 成本控制与性能优化
- 缓存：相同问题直接返回缓存结果，省Token
- 模型分级：简单任务用小模型，复杂任务用大模型
- Prompt压缩：精简提示词，去掉冗余说明
- 批处理：非实时任务攒一批一起处理
实操心得：上线前一定要做压力测试。我用locust模拟50并发，发现响应时间从1秒飙到15秒。后来加了请求队列和超时降级，才稳定下来。不做压测就上线，等于埋雷。
8. 常见问题与排查速查
8.1 开发阶段高频问题
问题：Ollama连接被拒绝。检查ollama serve是否在运行，端口是否被占用。Windows下有时需要设置OLLAMA_HOST=0.0.0.0。
问题：LangChain导入报错。大概率是版本不匹配。用pip show langchain看版本，对照官方文档确认API是否变更。
问题：RAG检索结果为空。检查向量库是否成功写入，嵌入模型是否和检索时用的同一个。我遇到过写入用A模型、检索用B模型，结果完全不匹配。
问题：Agent陷入循环。设置max_iterations限制最大步数，同时在Prompt里明确“如果无法完成，请直接说明”。
8.2 效果优化速查表
| 症状 | 优先排查 | 次优方案 |
|---|---|---|
| 回答不准确 | Prompt是否清晰 | 加RAG补充知识 |
| 格式不对 | 给示例（Few-shot） | 微调 |
| 响应太慢 | 换小模型 | 加缓存 |
| 成本太高 | 压缩Prompt | 模型分级 |
| 检索不准 | 调chunk_size | 换嵌入模型 |
8.3 学习路径建议
最后说说学习顺序。我见过太多人东学一点西学一点，最后什么都没学透。建议按这个顺序：
- 先跑通一个大模型API调用（1天）
- 学LangChain基础链（3天）
- 搭一个本地RAG（5天）
- 学Agent和工具调用（5天）
- 做一个完整项目（2周）
- 学微调和部署（按需）
每一步都要动手写代码，不能只看。我当年学RAG的时候，光看教程觉得懂了，自己一写发现连文档加载都报错。动手才是真的学。
这个内容后续还可以扩展的方向很多，比如多模态RAG、Agent安全与红队测试、大规模知识库的检索优化。但先把上面这些跑通，你就已经超过大多数只会调API的人了。
