先别急着定学习路线。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 显存。量化格式认准 GGUFOllama 和 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 CallingAgent 是怎么调用工具的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; charsetutf-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 框架。如果我只是在手机上做个 Demo1B 到 3B 的小模型体验还能接受7B 以上在中高端手机上勉强能跑但发热和耗电很明显。生产级 App 建议把主流程放服务端只在断网兜底或隐私计算场景用设备端小模型。5.3 常见问题排查与避坑技巧实录我把自己开发过程中遇到的典型问题整理成一张速查表每一个都花过真金白银的教训问题现象常见原因解决方法Agent 不调用工具总是自己编答案工具描述太模糊或没有在提示词里强调“先搜索再回答”把工具描述的触发条件写具体并在系统提示词中加入“不知道就查”的规则知识库回答完全不相关切片太大或检索 Top K 太高调整切片大小为 500~800Top K 设为 3~5提高分数阈值上下文一长回答开始混乱没有做历史摘要或窗口滚动为长期会话加摘要记忆或限制最大历史轮数SSE 流式输出前端收到乱码服务端被网关缓冲或 GZip 压缩关闭该路径的缓冲与压缩或使用分块编码点击停止但后台仍在计费Abort 信号没有传到上游模型请求前端 AbortController 信号穿透到后端后端取消模型请求本地模型显存溢出模型参数量超过 GPU 显存换成 Q4 量化的 GGUF或减小上下文长度模型不遵守输出格式温度过高或 Prompt 约束不够降低温度并在提示词里给出输出示例另外我还想补充一个经验很多问题不是模型不行而是链路中某个环节悄悄失败了。比如联网搜索工具返回超时Dify 日志里可能直接告警但普通用户看到的只是“模型没有调用搜索”你可能会误以为提示词写得不对。所以上线前一定要看链路日志。Dify 里可以开追踪把每个节点的输入输出都打出来自研服务就必须在中间件层加日志不然排查问题会非常痛苦。6. 最后想说的几句大实话我实际操作下来最大的体会是智能体开发没那么玄本质上是把过去人肉完成的“查资料、填表格、调接口、发通知”这些动作变成配置和代码。你不需要先把所有概念学完再动手完全可以先跑通一个最小闭环模型 一个工具 一段记忆 流式输出。先别想着搭建一个能处理所有任务的超级智能体那是大公司团队的事。你要做的是从一个具体问题开始比如“帮我写销售日报”“帮我查行业新闻”把一个场景做透。场景越具体你越能在边界条件、工具调用、错误处理这些地方积累真正的经验。关于学完能不能薪资翻倍我的看法是会调 API 的人很多能把一个智能体从设计、开发、部署到排错完整跑通的人确实少得多。你花两周时间把一个真实项目跑上线远比收藏一百个教程更有说服力。面试时对方问你“你做过什么”你直接讲一遍你是如何通过工具调用、记忆、流式输出去解决一个具体问题的就已经赢了大多数人。
