01 概念全景图LLM大语言模型 │ │ 厂商通过 HTTP 提供调用能力 ▼ LLM API │ │ 客户端维护对话历史数组 ▼ Context上下文 │ │ 告诉 LLM 你有哪些工具可用 ▼ Tool Calling工具调用 │ │ 加入循环思考 → 行动 → 观察 ▼ Agent Loop智能体循环 │ ├──────────────┬──────────────┐ ▼ ▼ ▼ MCP 协议 Sub-Agent Agent Skill (标准化工具对接) (分工协作) (流程复用)02 基础概念2.1 LLM大语言模型ChatGPT、Claude、Gemini、DeepSeek 等都是 LLM。本质是超大号的文字接龙机器——给一段文字按概率逐词预测下一个词。当参数量达到千亿级别它就涌现出了写代码、写文章、做数学题的能力。2.2 LLM API大模型接口LLM 跑在云端 GPU 集群上厂商通过 HTTP API 提供调用能力你的代码 → HTTP POST带上问题 → LLM 服务 → HTTP 响应返回回答2.3 Context上下文LLM 本身是无状态的——每次调用都是一次全新的请求它不会记得上一句你说了什么。所谓上下文就是你随请求一起发过去的所有信息包括对话历史之前的每一轮问答系统提示词告诉 AI 你是谁、该怎么做的指令工具结果上一步工具调用返回的数据第 1 次请求[消息1] → AI 回复1 第 2 次请求[消息1, 回复1, 消息2] → AI 回复2 第 3 次请求[消息1, 回复1, 消息2, 回复2, 消息3] → AI 回复3每次都把完整历史发过去AI 才能记住之前聊了什么。记忆不在 AI 脑子里而在你发送的数组里。每个模型有上下文窗口Context Window限制比如 128K tokens。超出这个长度最早的内容就会被截掉。2.4 Tool / Function Calling工具调用这是从聊天机器人进化到Agent的关键一步。普通 LLM 只能生成文字但如果告诉它有个get_weather工具它就能返回结构化的调用请求{ functionCall: { name: get_weather, args: { city: 深圳 } } }LLM 并没有真的查天气它只是说我想调这个工具。真正执行的是你的代码。LLM 负责动脑决策代码负责动手执行。2.5 AI Agent智能体Agent 是一种架构模式把上面三者串在一起Agent LLM大脑 Tools手脚 Loop驱动循环LLM 负责理解任务、做出决策Tools 负责执行具体操作Loop 让 AI 反复思考→行动→观察直到任务完成2.6 MCP模型上下文协议有了 Tool CallingAgent 可以调用工具。但每接一个新工具你都要写一套定义、解析、执行的代码。工具一多维护成本爆炸。MCPModel Context Protocol 定义了一套统一的协议让 Agent 能以即插即用的方式对接外部工具和数据源——相当于 AI 世界的 USB 接口标准。2.7 Sub-Agent子智能体一个 Agent 什么都干容易出错上下文也会被塞满无关信息。Sub-Agent 模式是让主 Agent 把子任务委派给专门的小 Agent。每个子 Agent 有自己独立的上下文和专属工具做完后只把结果交还给主 Agent。2.8 Agent Skill技能Tool 是单个动作比如读文件但很多任务是一套固定流程比如生成 Git commit需要查状态 → 看 diff → 写 commit message → 执行提交。Agent Skill 就是预定义好的 prompt 工具组合——把多个工具和 prompt 打包成一键触发的流程。2.9 Context Management上下文管理LLM 的上下文窗口是有限的。对话越长历史消息越多总会塞满。而且 token 越多响应越慢、费用越高。上下文管理就是在记住足够多和别超标之间找平衡常见策略包括滑动窗口、摘要压缩、RAG 检索增强。03 从零构建 Agent — 四个阶段整个构建过程分为四个递进阶段每个阶段解锁一项新能力。3.1 阶段一单次对话API 调用最简单的起点——调用 LLM API让 AI 回答一个问题。const body { messages: [ { role: system, content: 你是一个有帮助的助手。 }, { role: user, content: 你好 }, ], }; const res await fetch(apiEndpoint, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey}, }, body: JSON.stringify(body), }); const data await res.json(); console.log(data.choices[0].message.content);关键参数系统提示词system prompt告诉 AI 你是谁、该怎么做的隐藏指令用户看不到但 AI 会始终遵守。对话内容messages用户实际发送的消息每条消息带 role谁说的和 content说了什么。能力 单轮问答关掉程序就全忘。3.2 阶段二多轮对话上下文维护LLM 本身不记得上一句你说了什么——每次 API 调用都是一次全新的、独立的请求。解决方案是在客户端维护一个 history 数组每次请求时带上完整历史class Chat { private history: Message[] []; async send(text: string): Promisestring { this.history.push({ role: user, content: text }); const reply await this.client.sendMessage(this.history, this.systemPrompt); this.history.push({ role: assistant, content: reply }); return reply; } }每次调 API 都把完整对话历史发过去LLM 本身是无状态的记忆完全靠客户端的数组模拟。能力 多轮对话但只会说不会做。3.3 阶段三工具调用Function CallingAI 能记住对话了但它只能说不能做。给 AI 一双手——Tool Calling。工具注册表——用标准格式描述每个工具{ name: run_shell_command, description: Run a shell command on the users machine..., parameters: { command: { type: string, description: The shell command to execute }, }, required: [command], }工具实现execute(params: Recordstring, unknown): Promiseunknown { const command params.command as string; return new Promise((resolve) { exec(command, { timeout: timeoutMs }, (error, stdout, stderr) { resolve({ exitCode: error?.code ?? 0, stdout, stderr }); }); }); }把工具列表随请求发给 API 后AI 的回复可能从纯文本变成函数调用请求// 纯文本回复 { text: 你好有什么可以帮你的 } // 工具调用请求 { functionCall: { name: run_shell_command, args: { command: ls -la } } }AI 没有真的执行命令它只是下达指令代码负责跑腿。3.4 阶段四Agent LoopReAct 循环有了工具调用能力但 AI 只能完成单步动作。现实任务通常需要多步协作。引入 Agent Loop即自动化的驱动循环——调完工具看结果把结果喂回给 AI让它继续判断下一步。这个过程通常被称为 ReAct (Reason Act)Reasoning推理AI 思考当前状况决定下一步Acting行动AI 发出工具调用请求代码执行工具Observation观察代码将工具执行结果反馈给 AI核心循环代码async send(text: string): Promisestring { this.history.push({ role: user, content: text }); for (let i 0; i MAX_ROUNDS; i) { const result await this.client.sendMessage(this.history, options); this.history.push({ role: assistant, content: result }); if (!result.functionCall) { return result.text ?? ; } const { name, args } result.functionCall; const toolResult await this.toolRegistry.execute(name, args); this.history.push({ role: tool, content: JSON.stringify({ name, result: toolResult }), }); } throw new Error(Max tool call rounds exceeded); }实际运行示例用户帮我看看当前目录有什么文件然后统计代码行数 第 1 圈AI → 执行 ls -la → 代码返回结果 第 2 圈AI → 执行 wc -l src/*.ts → 代码返回结果 第 3 圈AI → 返回文本总结 → 循环结束 ✅MAX_ROUNDS 是安全阀防止 AI 死循环。3.5 工程化原则拥有 Agent Loop 后Agent 已经能自主运行但要真正可用还需要关注以下工程化原则。工具设计从 “万能胶” 到 “手术刀”不要只提供一个 run_shell_command 万能工具而应该设计专门的工具read_file支持分页读取避免大文件直接撑爆上下文edit_file通过 old_string → new_string 的方式修改代码比让 AI 生成 shell 命令更安全且可靠list_directory返回结构化的 JSON 列表包含文件大小和类型工具越原子化、越结构化Agent 运行的成功率就越高。上下文注入给 Agent 戴上 “扩增实境眼镜”在每轮对话启动前自动采集环境信息并注入到 Prompt 中当前工作目录 (CWD)文件列表 (File List)当前时间 (Timestamp)这样 Agent 一开始就知道自己在哪里、“手头有什么”不需要先花一轮工具调用去探索环境。显示优化让 “黑盒” 变透明Agent 在执行工具时应该给用户清晰的反馈interface ToolExecuteResult { data: unknown; // LLM 需要的结构化原始数据 displayText?: string; // 用户在终端看到的友好提示 }比如执行 shell 命令时显示 $ ls -la读取文件时显示 Read src/index.ts (lines 1-20)而不是把原始 JSON 甩给用户。指令优化从 “聊天” 到 “工作”系统提示词对 Agent 的行为影响巨大为开发者工具场景应注意强制要求禁止废话直接输出结果角色定位明确自己是一个交互式 CLI Agent思考链鼓励在调用工具前进行简短的推理04 进阶架构4.1 上下文管理上下文窗口是 Agent 的工作记忆但它有硬性限制。对话越长、工具调用越多token 消耗越快。为什么需要上下文管理问题说明Token 限制每个模型有上下文窗口上限如 128K tokens超出就截断成本Token 数量直接决定 API 费用历史越长越贵速度输入 token 越多模型响应延迟越高常见策略策略 1滑动窗口只保留最近 N 轮对话丢弃更早的消息。function slidingWindow(history: Message[], maxTurns: number): Message[] { if (history.length maxTurns * 2) { return history; } const systemPrompt history[0]; const recentMessages history.slice(-(maxTurns * 2)); return [systemPrompt, ...recentMessages]; }优点实现简单效果直接。 缺点早期信息完全丢失。策略 2摘要压缩让 LLM 把旧的对话历史压缩成一段摘要。原始历史5000 tokens 用户问了天气 → AI 查了天气 → 用户问了新闻 → AI 查了新闻 → ... 压缩后200 tokens 用户先查了深圳天气25°C 晴然后查了今日科技新闻共 3 条 接着要求将新闻翻译成英文。优点保留关键信息压缩比高。 缺点压缩本身消耗 token且可能丢失细节。策略 3RAG 检索增强不把所有信息都塞进上下文而是存到外部知识库需要时按需检索。用户提问上次讨论的数据库方案是什么 1. 把问题转成向量 → 去向量数据库检索 2. 找到相关的历史片段 → 注入当前上下文 3. LLM 基于检索结果回答优点上下文永远保持精简可以记住无限量的历史。 缺点需要额外的向量数据库基础设施。策略组合实际项目中通常组合使用┌─────────────────────────────────────────────┐ │ 1. 系统提示词 (始终保留) │ │ 2. 压缩摘要旧历史 (摘要压缩) │ │ 3. 检索到的相关知识片段 (RAG) │ │ 4. 最近 N 轮对话 (滑动窗口) │ │ 5. 当前用户输入 (始终保留) │ └─────────────────────────────────────────────┘上下文管理没有银弹需要按场景组合不同策略。4.2 MCP 协议每个工具都要写一套定义→解析→执行的胶水代码。工具一多维护成本爆炸。MCP 就是为解决这个问题而生的标准化协议。MCP 解决的问题没有 MCP 时Agent A 对接 GitHub → 写一套 GitHub 工具定义 执行逻辑 Agent A 对接 Slack → 写一套 Slack 工具定义 执行逻辑 Agent B 对接 GitHub → 再写一套跟 A 的还不一样 ...M 个 Agent × N 个工具 M × N 套集成代码。有了 MCPAgent A ─┐ ┌─ GitHub MCP Server Agent B ─┤── MCP 协议 ──────┤─ Slack MCP Server Agent C ─┘ (标准接口) └─ 数据库 MCP ServerM N 套代码就够了。MCP 的核心能力MCP 定义了三种核心原语Tools (工具)Agent 可以调用的可执行函数让模型执行操作Resources (资源)Server 暴露给 Agent 的只读数据让模型读取上下文Prompts (提示词)Server 提供的预定义 Prompt 模板复用高质量的指令MCP 架构┌─────────────────────────────────────────────────┐ │ Host │ │ (Agent 应用) │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ MCP Client │ │ MCP Client │ ... │ │ └─────┬──────┘ └─────┬──────┘ │ └─────────┼───────────────┼───────────────────────┘ │ MCP 协议 │ MCP 协议 ▼ ▼ ┌────────────┐ ┌────────────┐ │ MCP Server │ │ MCP Server │ │ (GitHub) │ │ (Database) │ └────────────┘ └────────────┘MCP 通信过程Agent(Host) MCP Client MCP Server │ │ │ │ 1. 启动时 │ ── initialize ──▶ │ │ │ ◀── 工具列表 ──── │ │ │ │ │ 2. 用户提问 │ │ │ ──查 GitHub issue─▶ │ │ │ │ │ │ 3. LLM 决定调工具 │ │ │ ── tool_call ──────▶ │ ── execute ────▶ │ │ │ ◀── result ───── │ │ ◀── tool_result ───── │ │ │ │ │ │ 4. LLM 生成回复 │ │ │ ◀── 返回给用户 │ │4.3 Sub-Agent 模式单 Agent 面临两个核心瓶颈上下文污染搜索代码的中间结果、测试日志等占满上下文和任务过杂需要在不同类型的工作间反复切换。Sub-Agent 模式通过分工协作来解决这些问题。Sub-Agent 架构用户帮我调研 React 和 Vue 的优缺点然后写一个技术选型报告 ┌──────────────┐ │ 主 Agent │ ← 理解任务、拆分、汇总 │(Orchestrator)│ └───────┬──────┘ ┌─────────┼─────────┐ ▼ ▼ ▼ ┌───────────┐ ┌──────────┐ ┌──────────┐ │调研 Agent │ │调研 Agent│ │写作 Agent│ │ (React) │ │ (Vue) │ │ (报告) │ └───────────┘ └──────────┘ └──────────┘每个子 Agent有自己独立的上下文——互不干扰有自己专属的工具集——搜索 Agent 有搜索工具写作 Agent 有文件工具做完后只返回结果——不带过程中的废料Sub-Agent 定义每个 Sub-Agent 通常由以下元素组成name: code-reviewer # 唯一标识 description: Reviews code... # 描述信息用于主 Agent 决策时选择 tools: [read_file, list_dir] # 工具白名单 model: model-name # 可覆盖默认模型 maxTurns: 15 # 限制最大工具调用轮数 prompt: | # 专属系统提示词 You are a code reviewer specialized in identifying: - Security vulnerabilities - Performance issues ...关键设计要点工具白名单限制子 Agent 只能用必要的工具降低风险独立模型可以为不同子任务选择最合适的模型轮数限制每个子 Agent 有自己的 maxTurns防止某个子任务失控执行流程主 Agent 决定委派任务 │ ▼ 1. 根据任务描述选择合适的 Sub-Agent │ ▼ 2. 构建受限的工具集只给白名单中的工具 │ ▼ 3. 创建新的 Chat 实例独立上下文 │ ▼ 4. Sub-Agent 执行任务在自己的 Agent Loop 中 │ ▼ 5. 返回结果给主 Agent只有最终结果没有中间过程4.4 Agent SkillTool 是单个动作但很多实际任务是一套固定流程需要多个 Tool 配合加上特定的 prompt 指引。Skill 就是把这套流程打包成一个可复用的快捷操作。Skill 的本质一个 Skill prompt 模板 元数据。┌─────────────────────────────────────────────────────┐ │ Agent Skill │ │ │ │ 元数据: │ │ name / description / trigger │ │ │ │ Prompt 模板: │ │ 作为 prompt 注入主对话上下文 │ │ 指导 Agent 按步骤执行任务 │ └─────────────────────────────────────────────────────┘Skill 与 Tool、Sub-Agent 的区别ToolSkillSub-Agent粒度单个动作一套完整流程独立的子任务触发LLM 自动选择用户命令 / LLM 调用LLM 调用执行方式直接执行函数prompt 注入主对话上下文派生独立 Chat 实例上下文共享主 Agent 上下文共享主 Agent 上下文独立上下文Skill 定义示例name: commit description: Generate a conventional commit message for staged changes trigger: /commit prompt: | Analyze the staged changes and generate a commit message following the Conventional Commits specification. The commit message should: 1. Start with a type: feat, fix, docs, style, refactor, test, or chore 2. Include a scope in parentheses if applicable 3. Have a concise subject line (max 50 chars) 4. Include a body if the change is complex两种触发方式方式一用户命令触发用户直接输入触发命令如 /commit系统匹配到对应 Skill将 prompt 注入对话const skillMatch skillRegistry.match(userInput); if (skillMatch) { const injectedPrompt skillLoader.load(skillMatch.skill, skillMatch.args); const reply await chat.send(injectedPrompt); }方式二LLM 自主调用将 Skill 包装成一个 ToolLLM 在 Agent Loop 中可以自主决定调用{ tool: skill, parameters: { skill_name: commit, task: 为当前暂存的更改生成提交信息 } }Skill 的价值场景不用 Skill用 Skill重复性流程用户每次手动描述每一步一条命令一键搞定领域知识用户需要知道具体步骤和参数Skill 封装了专家经验自动执行团队协作每个人的操作方式不一致统一的 Skill 定义保证流程一致性4.5 如何选择Tool vs Skill vs Sub-Agent需求来了 │ ├─ 是单个原子操作读文件、发请求、执行命令 │ └─ → 用 Tool │ ├─ 是固定流程每次步骤一样只是输入不同 │ └─ → 用 Skill │ ├─ 需要独立上下文中间过程会污染主对话 │ └─ → 用 Sub-Agent │ └─ 需要不同模型子任务适合用专门的模型 └─ → 用 Sub-Agent具体场景对照场景推荐方案理由读取一个文件Tool单个原子操作生成 Git commit messageSkill固定流程查 diff → 写 message → 提交调研某个技术方案Sub-Agent需要大量搜索中间结果会污染主上下文执行代码审查Sub-Agent需要独立上下文可能需要不同模型格式化代码Tool单个操作调用 formatter 即可生成单元测试Skill固定流程读源码 → 分析 → 生成测试同时调研 3 个竞品Sub-Agent × 3并行执行各自独立上下文组合使用实际项目中这三者经常组合使用用户输入 /review触发 Skill │ ▼ Skill prompt 指导主 Agent 拆分任务 │ ├─ Sub-Agent 1代码审查使用 read_file Tool ├─ Sub-Agent 2安全检查使用 grep、read_file Tool └─ Sub-Agent 3性能分析使用 run_command Tool │ ▼ 主 Agent 汇总三个 Sub-Agent 的结果生成报告05 总结本文覆盖了从 LLM 到 Agent 的完整知识体系基础概念LLM 是无状态的文字接龙机器通过 API 调用Context 是你发送的全部信息历史 提示词 工具结果记忆在数组里而不是 AI 脑子里Tool Calling 让 LLM 从只能说进化到能动手但 LLM 只负责决策代码负责执行构建过程四个阶段单次对话 → 调 API一问一答多轮对话 → 客户端维护 history 数组工具调用 → 注册工具LLM 决定何时调用Agent Loop → ReAct 循环自动多步执行进阶架构上下文管理滑动窗口 摘要压缩 RAG按场景组合MCP 协议标准化工具对接M × N → M NSub-Agent独立上下文的分工协作Skill可复用的流程模板选择原则原子操作用 Tool固定流程用 Skill需要独立上下文用 Sub-Agent学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】