先别急着定学习路线。AI Agent 这个关键词，最近两年已经被讲烂了，但真正能把一个智能体从 0 跑到能用的教程，确实不多见。我自己在把第一个智能体项目落地之前，也踩过不少坑：Dify 试过、Coze 试过、LangGraph 也啃过，最后发现很多教程要么停在“你好，我是你的智能助手”这种 Demo，要么一上来就甩出一堆 Agent、LLM、RAG、Function Calling 的抽象名词，直接把新手劝退。
所以这篇内容我按自己实际调试的顺序来写，尽量做到最全、最细。目标不是让你背概念，而是让你看完之后，能用 Dify 或 LangGraph 搭出一个能联网搜索、能调用工具、能记住上下文的专属智能体，并且知道上线部署时那些坑都在哪。至于“学完薪资翻倍”这种话，我不太爱说，但说实话，把智能体开发这条链路完整走一遍之后，你对 AI 大模型应用的理解会跟只调 API 的人完全拉开差距，这会直接体现在你谈薪资的底气上。
几个热搜词我先统一解释：AI Agent 是主体，智能体就是它；AI 大模型是底座；DeepSeek 就是能当底座的大模型之一。下面从概念开始，一路走到部署排错。
1. 别急着敲代码，先搞清楚 AI Agent 到底是什么
1.1 LLM、AI 大模型、智能体到底有什么区别
这三个词被混着用太久了，但搞混的代价很大，因为你可能抱着“学 Agent”的心态，结果学了一周 Prompt，发现自己连 Agent 的门都没摸到。
我打个比方：LLM 就像刚毕业的高材生，知识面很广，能说会道，但你让他“把桌上那本合同找出来，提炼关键条款并发给对接人”，他做不到。AI Agent 就不一样，它像一个给高材生配齐了电脑、通讯录、日历和执行流程的职业助理，遇到任务会先拆解，然后调用搜索、数据库、邮件这些工具，把事真正办完。
所以它们的区别不是量级，而是结构。一张表说清楚：
| 名词 | 一句话理解 | 典型存在形式 |
|---|---|---|
| LLM / 大语言模型 | 只负责文本理解与生成的模型 | DeepSeek、Qwen、GPT、Claude 这类模型本体 |
| AI 大模型 | 泛指大规模预训练模型，含文本、多模态 | 上面这些模型的 API、开源权重、量化文件 |
| AI Agent / 智能体 | 以 LLM 为大脑，配合工具、记忆、流程编排做事的系统 | Dify 应用、Coze Bot、LangGraph 服务、自研智能体服务 |
你问“DeepSeek 属于哪个”，答案很明确：它属于 LLM / AI 大模型这一层。你单纯跟 DeepSeek 网页聊天，那只是用大模型；你把 DeepSeek 接口接上搜索、数据库、企业微信机器人，给它配好任务拆解逻辑，那才是在开发智能体。
1.2 一个 Agent 系统到底由哪几块组成
在 2026 年再谈智能体，如果还停留在“Prompt 调优”层面，就太可惜了。一个能上生产的智能体，至少包含五块内容：
- 大模型底座：负责推理与决策，决定智能体“聪不聪明”。
- 系统提示词：决定角色、边界和做事风格。
- 记忆：短期记忆负责当前会话，长期记忆负责跨会话经验。
- 技能 / 工具：搜索、代码执行、数据库查询、HTTP 请求，这是 Agent 的“手和脚”。
- 编排逻辑：决定什么时候调工具、调哪个工具、怎么处理结果，这是 Agent 的“工作流”。
很多人把重点放在 2 上，以为写个牛逼 Prompt 就是 Agent，但真正决定系统上限的往往是 4 和 5。你给 Agent 的工具越强、编排逻辑越清晰，它就越像一个能干活的员工，而不是聊天机器人。这也是为什么现在招聘岗位里，会写“Agent 应用开发”“AI 大模型应用开发”的薪资普遍高于普通 Prompt 工程师。
2. 选型和准备：工具链没选对，后面全是坑
2.1 主流智能体框架怎么选：Dify、Coze、LangGraph
我见过太多人一上来就啃 LangChain，结果被各种抽象类绕晕。其实先选对工具比先学代码重要得多。
| 框架 | 适合谁 | 最大优点 | 容易踩的坑 |
|---|---|---|---|
| Dify | 想做应用原型、企业内部工具、知识库问答 | 可视化编排，开源可私有部署，RAG 和插件生态齐全 | 深度定制需要写 Python 或插件 |
| Coze | 想快速做 Bot、内容类助手 | 免部署，插件市场丰富，适合非技术 | 自定义自由度有限，复杂流程受限 |
| LangGraph | 开发团队、复杂多智能体场景 | 状态机编排，可测试、可控性强 | 学习曲线陡，前期开发成本高 |
| 自研 | 有特殊协议、强数据隔离要求 | 完全可控 | 模型、记忆、工具、监控全都要自己搭 |
我自己的建议非常直接：第一个智能体项目用 Dify 起步，把对话、知识库、工具调用跑通，看看智能体到底是怎么“思考”的；等项目复杂到需要在多个智能体之间做状态流转和权限控制时，再迁到 LangGraph。
顺带说一下 LangChain 和 LangGraph 的关系。LangChain 是工具库，负责把大模型、Embedding、向量库这些东西包成好用的接口；LangGraph 是编排引擎，负责把各个节点串成一张有状态的图。两者经常搭配出现，业内叫 Harness 架构，本质上就是把“模型的能力”和“流程的控制权”分开管理。你只要理解“LangChain 给零件，LangGraph 上流水线”就够了。
2.2 模型选型和本地部署配置，别只看参数大小
模型选型是很多人纠结的地方。我的原则是：先看场景，再选模型。
- 如果做中文客服、知识库问答，DeepSeek、通义千问、智谱 GLM 都是很稳的选择，接口国内直接能调，成本也低。
- 如果做代码生成、复杂逻辑推理，可以选参数更大或擅长工具调用的模型。
- 如果业务有数据隐私要求，那就考虑本地部署开源模型，比如 Qwen2.5 系列、DeepSeek 开源版本，或者 Llama 系列。
本地部署配置很多人会卡住。这里我直接给一套基于常见实践的参考值：如果你的显卡是 24GB 显存，跑 14B 模型做 Demo 很舒服；如果只有 8GB 显存，建议跑 7B 模型的 Q4 量化版本；32B 以上模型，建议至少有 24GB 到 48GB 显存。量化格式认准 GGUF，Ollama 和 llama.cpp 都直接支持，省内存效果明显。
还要提醒一句：本地部署不是越大的模型越好。显存只够 7B，硬跑 14B 只会换来极慢的速度和频繁的显存溢出。先跑通流程，再考虑升级模型参数量，这个顺序很重要。
3. 从零搭一个能联网搜索的专属智能体：Dify 实战
3.1 第一步：创建应用和接入模型
如果你不想管服务器，直接用 Dify 的在线版或云服务，注册之后进控制台就能创建应用。如果你想私有化部署，也有 Docker Compose 方案，一条命令拉起全部组件，这里不展开，因为不同版本命令有差异，网上太多，照着官方的来就行。
进入 Dify 后，我的建议是不要一上来就用“空白应用”，而是先看一遍模板。模板里通常已经接好了模型、提示词和基础工具，你只需要把它改造成自己的业务即可。
然后在“设置-模型供应商”里填 API Key。以 DeepSeek 为例，你现在拿到 Key 后填入，选好模型名称（比如 deepseek-chat），测试连通。这里有个小技巧：把“温度”调到 0.3 到 0.5 之间，做客服或知识库问答时输出更稳；做创意文案可以调到 0.7 以上。别什么都用默认 1.0，那会让知识库回答变得太飘。
3.2 写系统提示词的实战模板
系统提示词是智能体的“人设和行为准则”，不能只写“你是一个助手”。我给你一套我用的模板：
你是「XX团队」的智能助理。 职责： 1. 回答用户关于业务、产品、技术文档的问题。 2. 当用户需要查询实时信息（新闻、天气、股票、物流等）时，先调用联网工具，不要凭记忆编造。 3. 回答必须基于知识库或搜索结果，并给出引用来源。 行为规则： 1. 如果信息不完整，明确告诉用户“我无法确认”。 2. 回答尽量用分点或表格，控制在500字以内。 3. 用户问题不明确时，最多追问一次，不要反复啰嗦。这套写法的重点不是“角色扮演”，而是把决策规则写清楚：什么时候调工具、什么时候拒绝回答、输出格式怎么控制。大模型很强，但它不知道怎么做事，全靠提示词给它划边界。
3.3 配置联网搜索和知识库，让 Agent 真的“知道”
光有模型，Agent 只能靠训练时的知识回答，没法知道最新信息。所以我们要做两件事：接工具、建知识库。
Dify 里接入联网搜索很简单，选一个搜索引擎工具，填上对应的 API Key，然后在 Agent 或 Chatflow 里打开这个工具。关键点在于工具的描述要写清楚，例如“当用户询问最新新闻、天气、实时价格、物流状态时，调用该工具获取最新数据”。工具描述越具体，模型越容易在正确的场景调用它。
知识库则用来沉淀业务私有知识。上传文档后，Dify 会做切片和向量化。参数层面，我建议先用 500 到 800 字的切片大小，重叠 50 到 100 字。这不是玄学，太短会丢失上下文，太长会导致召回不精准。检索参数上，Top K 先设 3 到 5，召回分数阈值大概 0.4 到 0.5，准确率不够就提高阈值，召回不够就降低阈值。
3.4 用 Chatflow 把搜索、知识库、LLM 串成一条流水线
Dify 里有两种应用类型：普通 Chat 和 Chatflow / Workflow。普通 Chat 适合快速验证，但生产级智能体我更推荐 Chatflow，因为它能把“问题分类→工具调用→知识库检索→模型回答”做成清晰的节点。
我在实际项目里常用的一条链路是：
- 开始节点：接收用户问题。
- 问题分类节点：用 LLM 判断是“实时信息类”还是“内部知识类”。
- 工具节点：如果分类是实时信息，调用联网搜索。
- 知识库检索节点：如果分类是内部知识，检索向量库。
- LLM 节点：把搜索结果或知识库片段和用户问题一起交给模型。
- 结束节点：输出最终答案。
这套结构的最大好处是可控。你想换搜索源、换知识库、改回答规则，都只需要改对应节点，而不是在一大段 Prompt 里反复试。核心心法一句话：把决策写进 LLM 节点，把脏活交给工具节点，不要在提示词里塞大段逻辑。
4. 进阶：记忆、技能、MCP，以及流式输出
4.1 记忆和上下文管理：别让 Agent 变成金鱼
很多人在 Demo 阶段没感觉，一旦做真实业务就会发现：用户多问几轮，Agent 就忘了前面说了什么。这是记忆没做好。
短期记忆最简单，就是给每次对话分配一个 Thread ID。你只需要把会话 ID 传入服务端，Dify 或 LangGraph 都会自动把历史消息拼到大模型上下文里。但这里有成本问题：历史消息越多，Token 费用越高，响应越慢。所以要做摘要压缩，常见做法是当历史消息超过 N 轮，先让模型把之前内容提炼成摘要，再继续对话。
长期记忆则要配合向量库使用。比如一个销售智能体，它应该记住用户偏好、上次沟通进展、客户所在行业。做法是把这些信息结构化后写入向量库，下次对话时根据用户 ID 召回相关内容，再注入到提示词里。这样才叫“智能体”，不然只是一个有记忆接口的聊天框。
4.2 技能和 Function Calling：Agent 是怎么调用工具的
Agent 调用工具的核心机制叫 Function Calling，也叫工具调用。你可以把它理解成：模型本身不动手，只负责“说我要用什么工具、传什么参数”，真正执行 API 的是你的后端代码。
比如你给智能体提供一个 get_weather 工具，工具描述是：
{ "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的实时天气", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名" } }, "required": ["city"] } } }当你问“北京明天冷吗”，模型不会直接回答，而是输出类似于“调用 get_weather，参数 city=北京”的结构化结果。你的代码收到这个结果后去请求天气 API，再把结果返回给模型，模型才能组织成自然语言回答。
这里踩坑最多的就是工具描述写得不清楚。记住：工具描述是给模型看的，不是给人看的。写得越具体，模型越知道什么时候用它。
4.3 MCP 协议：2026 年接入工具的标准答案
以前每接一个工具，都要单独写一套调用逻辑，非常痛苦。后来大家发现，不如把工具统一成一种协议：Model Context Protocol，也就是 MCP。
MCP 的核心思路是，让工具提供方写一个 MCP Server，把自己的能力按 tools、resources、prompts 三种形式暴露出来；Agent 客户端发现这些能力后，动态加载并调用。你接入一个新工具时，不再需要改主流程，只需要多挂一个 MCP Server。
目前在智能体开发里，文件系统、数据库、网页抓取、办公软件、定期任务这类常用能力都有现成的 MCP Server 实现。你说“Agent skill memory mcp 开发”，本质上就是：把技能做成 MCP 工具，把记忆做成可检索资源，再通过 MCP 协议对外统一暴露。这套组合在 2026 年已经是比较主流的工程范式了。
4.4 SSE 流式输出与大模型回答实时渲染
大模型生成答案需要时间，如果等全部生成完再返回，用户体感就是“卡了十来秒”。所以线上智能体几乎都是流式输出。前端最常用的手段是 SSE，配合 AbortController 可以实现“停止生成”按钮。
前端关键代码大致是这样的：
const controller = new AbortController(); const resp = await fetch('/api/agent/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ message: '你好，介绍一下你们的产品' }), signal: controller.signal }); const reader = resp.body.getReader(); const decoder = new TextDecoder('utf-8'); let buffer = ''; while (true) { const { value, done } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop() || ''; for (const line of lines) { if (line.startsWith('data: ')) { const payload = JSON.parse(line.slice(6)); renderChunk(payload.answer); } } } cancelBtn.onclick = () => controller.abort();对应的服务端，在 Node.js 里只需要设置响应头为 text/event-stream，然后不断写入数据：
app.post('/api/agent/chat', async (req, res) => { res.setHeader('Content-Type', 'text/event-stream; charset=utf-8'); res.setHeader('Cache-Control', 'no-cache'); const stream = await agent.stream({ messages: req.body.messages }); for await (const chunk of stream) { res.write(`data: ${JSON.stringify({ answer: chunk })}\n\n`); } res.end(); });这里我要特别强调一下 Abort 的正确姿势：前端点击“停止生成”后，不只是停掉页面加载，最好把取消信号传到后端，后端再去取消上游大模型的请求。否则模型还在后台默默把答案生成完，Token 照扣，费用照花。用 OpenAI SDK 或 DeepSeek SDK 时，一般都可以传 signal 或使用底层的 AbortController 来取消请求。
5. 部署、上线和常见问题排错
5.1 本地部署大模型 vs 云端 API，成本差多少
本地部署和云端 API 不是二选一的关系，而是两个场景。我列一张实际对比表：
| 对比项 | 本地私有化部署 | 云端 API |
|---|---|---|
| 单次问答成本 | 固定硬件成本，边际成本低 | 按 Token 计费，量大了成本明显 |
| 数据隐私 | 数据不出内网 | 需要评估数据脱敏和合规要求 |
| 延迟 | 取决于 GPU 性能 | 取决于网络和供应商 |
| 运维复杂度 | 自己管升级、监控、容灾 | 供应商负责 |
| 模型迭代 | 要自己更新权重 | 平台更新较及时 |
比较常见的折中方案是：敏感业务放本地小模型，通用对话和需要更强推理的场景走云端大模型。比如企业内部合同问答用本地 Qwen，而面向客户的营销文案生成用云端 DeepSeek。不要追求所有场景都用同一个模型，那样又贵又慢。
5.2 移动端和边缘设备接入 AI 大模型的思路
现在不少需求是把 AI 大模型接入 Android App，尤其是离线场景。做法通常有两种：一种是让手机 App 请求你的服务端，由服务端转发到本地或云端大模型；另一种是在设备端直接跑小模型。
设备端跑模型主要依赖 GGUF 这类量化权重格式，配合 llama.cpp、Ollama 或 Google 的 LiteRT-LM 框架。如果我只是在手机上做个 Demo，1B 到 3B 的小模型体验还能接受；7B 以上在中高端手机上勉强能跑，但发热和耗电很明显。生产级 App 建议把主流程放服务端，只在断网兜底或隐私计算场景用设备端小模型。
5.3 常见问题排查与避坑技巧实录
我把自己开发过程中遇到的典型问题整理成一张速查表，每一个都花过真金白银的教训：
| 问题现象 | 常见原因 | 解决方法 |
|---|---|---|
| Agent 不调用工具，总是自己编答案 | 工具描述太模糊，或没有在提示词里强调“先搜索再回答” | 把工具描述的触发条件写具体，并在系统提示词中加入“不知道就查”的规则 |
| 知识库回答完全不相关 | 切片太大或检索 Top K 太高 | 调整切片大小为 500~800，Top K 设为 3~5，提高分数阈值 |
| 上下文一长，回答开始混乱 | 没有做历史摘要或窗口滚动 | 为长期会话加摘要记忆，或限制最大历史轮数 |
| SSE 流式输出前端收到乱码 | 服务端被网关缓冲或 GZip 压缩 | 关闭该路径的缓冲与压缩，或使用分块编码 |
| 点击停止但后台仍在计费 | Abort 信号没有传到上游模型请求 | 前端 AbortController 信号穿透到后端，后端取消模型请求 |
| 本地模型显存溢出 | 模型参数量超过 GPU 显存 | 换成 Q4 量化的 GGUF，或减小上下文长度 |
| 模型不遵守输出格式 | 温度过高或 Prompt 约束不够 | 降低温度，并在提示词里给出输出示例 |
另外我还想补充一个经验：很多问题不是模型不行，而是链路中某个环节悄悄失败了。比如联网搜索工具返回超时，Dify 日志里可能直接告警，但普通用户看到的只是“模型没有调用搜索”，你可能会误以为提示词写得不对。所以上线前一定要看链路日志。Dify 里可以开追踪，把每个节点的输入输出都打出来；自研服务就必须在中间件层加日志，不然排查问题会非常痛苦。
6. 最后想说的几句大实话
我实际操作下来最大的体会是：智能体开发没那么玄，本质上是把过去人肉完成的“查资料、填表格、调接口、发通知”这些动作，变成配置和代码。你不需要先把所有概念学完再动手，完全可以先跑通一个最小闭环：模型 + 一个工具 + 一段记忆 + 流式输出。
先别想着搭建一个能处理所有任务的超级智能体，那是大公司团队的事。你要做的，是从一个具体问题开始，比如“帮我写销售日报”“帮我查行业新闻”，把一个场景做透。场景越具体，你越能在边界条件、工具调用、错误处理这些地方积累真正的经验。
关于学完能不能薪资翻倍，我的看法是：会调 API 的人很多，能把一个智能体从设计、开发、部署到排错完整跑通的人，确实少得多。你花两周时间把一个真实项目跑上线，远比收藏一百个教程更有说服力。面试时，对方问你“你做过什么”，你直接讲一遍你是如何通过工具调用、记忆、流式输出去解决一个具体问题的，就已经赢了大多数人。
