一文讲透 AI Agent：从 LLM 到 Skill，彻底搞懂智能体底层逻辑

AI Agent 不是一个更会聊天的大模型而是一套由 LLM、Token、Context、Prompt、Tool、MCP、Agent Loop 和 Skill 共同组成的工程系统。理解这些底层构件才能真正理解 Claude Code、Codex、Cursor、OpenCode、Hermes-Agent 这类产品为什么会出现以及它们到底在解决什么问题。过去一年AI 圈最热的词已经从“大模型”逐渐变成了“Agent”。你可能已经听过很多名词LLM、Token、Context、Prompt、RAG、Tool、MCP、Agent、Agent Skill、Claude Code、Codex、Cursor、OpenCode、Hermes-Agent。这些概念看起来分散甚至有点像营销词。但如果从工程视角拆开它们其实可以串成一条非常清晰的技术链路LLM - Token / Tokenizer - Context / Context Window - Prompt / System Prompt - RAG - Tool - MCP - Agent Loop - Agent Skill - Coding Agent / Domain Agent一句话概括LLM 负责生成Token 是计算单位Context 是工作区Prompt 是任务指令Tool 连接外部系统MCP 统一工具接入方式Agent 负责规划与执行Skill 则把可复用经验沉淀成能力包。这篇文章不讲玄学也不堆概念。我们从最底层开始一层一层往上拆把 AI Agent 的底层逻辑讲清楚。一、Agent 到底是什么如果只用一句话解释 Agent可以这样说Agent 是一个能够围绕目标进行规划、调用工具、观察结果并持续推进任务完成的系统。注意这里有三个关键词目标Agent 不是简单回答一句话而是要完成一个任务。工具Agent 需要调用外部能力比如读文件、查资料、执行命令、访问 API。循环Agent 会根据工具返回结果继续判断下一步而不是一次生成就结束。所以Agent 不是单独的模型。更准确地说Agent LLM Prompt Context Tool Runtime Memory/State PolicyLLM 是 Agent 的推理核心但 Agent 本身是一个更完整的工程系统。这也是为什么同一个模型在普通聊天框里只是 Chatbot 放到 Claude Code 、 Codex 、 Cursor 、 OpenCode 这类工具里就变成了能读代码、改文件、运行命令、观察结果并继续修复问题的 Coding Agent 。二、LLMAgent 的推理发动机LLM全称 Large Language Model也就是大语言模型。今天主流大模型大多基于 Transformer 架构。Transformer 最早由 Google 团队在 2017 年论文《Attention Is All You Need》中提出后来被 GPT、Claude、Gemini 等模型体系不断放大成为当前 AI 浪潮的底层技术基座。从工程使用角度看我们不需要一开始就陷入复杂的注意力矩阵和训练细节。你可以先把 LLM 理解为一个高维文本预测函数输入一段上下文 - 预测下一个最可能出现的 Token例如用户输入这个技术方案怎么样模型不是一次性把完整回答全部“想好”。它会先预测第一个 Token再把这个 Token 追加回上下文再预测下一个 Token如此循环直到输出结束标识。这也是为什么大模型通常会一个字、一个词、一个片段地流式输出。这里有一个关键认知LLM 本身只负责生成文本。它不会天然拥有执行能力。它不会自己读你的代码仓库不会自己访问数据库也不会自己调用接口。它能做的是根据上下文生成下一段最合理的文本。至于这段文本能否触发工具、能否执行动作取决于外层平台如何设计。这就引出了下一个概念Token。三、Token模型真正处理的基本单位人类读的是文字模型处理的是数字。在文字和数字之间需要一个翻译器这个翻译器叫Tokenizer。Tokenizer 做两件事编码把文本切分成 Token再映射成 Token ID。 解码把模型输出的 Token ID 还原成可读文本。这里最容易误解的一点是Token 不等于字也不等于词。例如中文里的一个词可能被切成多个 Token英文里的长单词也可能被切成词根、前缀、后缀等多个 Token某些符号和特殊字符甚至会被拆成多个 Token。所以更准确的理解是Token 是模型自己使用的一套文本切分单位。它不是语言学里的“词”而是模型训练和推理时处理文本的最小粒度之一。为什么工程师必须理解 Token因为它直接影响四件事成本输入和输出 Token 越多调用成本越高。速度生成 Token 越多响应时间越长。上下文容量模型一次能接收的信息量由 Context Window 决定。Agent 能力边界工具描述、系统提示词、历史记录、Skill 指令都会消耗 Token。很多 Agent 系统效果不好不是模型不够强而是上下文组织太差Token 被无效信息占满了。四、Context大模型的临时工作区我们经常觉得大模型“记得刚才聊过什么”。但严格来说大模型并没有人类意义上的记忆。它之所以能接上前文是因为应用程序在每次请求时把历史对话、当前问题、系统规则等内容重新组织后一起发给模型。这些信息的总和就是Context也就是上下文。一个真实 Agent 请求里的 Context通常包含用户当前问题历史对话System Prompt可用工具列表工具参数 schema工具调用结果RAG 检索片段当前任务状态Agent Skill 元数据和指令Context 可以理解为模型本轮推理时看到的“临时工作区”。而Context Window则表示这个工作区最多能容纳多少 Token。很多人会天然觉得 Context Window 越大越好。这个判断只对了一半。大窗口确实能放更多内容但也会带来三个问题成本更高延迟更大噪声更多如果把无关文档、冗余历史、过长工具描述全部塞进去模型反而更容易抓不住重点。所以 Agent 工程里有一个非常核心的能力不是把所有信息塞给模型而是把正确的信息在正确的时机塞给模型。RAG 和 Skill 的渐进式加载本质上都是围绕这个目标设计的。五、RAG让模型只看到相关知识假设你有一套上千页的产品手册希望模型基于手册回答用户问题。最简单粗暴的方式是把整本手册塞进 Context。但这通常不是好方案。更工程化的方式是 RAG也就是 Retrieval-Augmented Generation检索增强生成。RAG 的基本流程是把文档切成多个片段。 为片段建立向量索引、关键词索引或混合索引。 用户提问时先检索最相关的片段。 只把这些片段放入 Context。 模型基于检索结果生成回答。RAG 解决的不是“让模型变聪明”而是“让模型看到正确资料”。在 Agent 系统里RAG 往往不是一个独立产品能力而是一个可调用工具。Agent 会先判断当前任务是否需要查知识库如果需要再调用检索工具把结果带回上下文继续推理。所以 RAG 可以看成 Agent 的外部知识入口。六、Prompt给模型的任务指令Prompt 不神秘它就是给模型的输入指令。例如帮我写一篇技术文章。这是 Prompt。但这个 Prompt 太宽泛。模型不知道文章写给谁看写多深什么风格是否要代码示例是否要工程实践。更好的 Prompt 会明确四件事目标要完成什么任务背景为什么要做这件事约束不能做什么必须遵守什么输出以什么格式交付在真实系统里Prompt 通常分为两类。User Prompt是用户当前输入的问题或任务。System Prompt是系统在后台设定的角色、规则、边界和行为规范。例如做一个数学辅导助手System Prompt 可以写你是一个耐心的数学老师。学生提问时不要直接给答案而是一步步引导学生理解解题思路。当用户问“3 5 等于几”时模型就不会直接说“8”而是会尝试引导。这说明 System Prompt 对模型行为有很强的约束作用。但 Prompt 也不是万能的。随着任务变复杂单靠 Prompt 很快会遇到瓶颈信息太长容易占满上下文。规则太多容易互相冲突。任务需要外部数据模型无法凭空获取。任务需要执行动作模型本身没有执行能力。这时候就需要 Tool。七、Tool让模型连接真实世界大模型默认只能生成文本无法直接感知和影响外部世界。你问它“今天上海天气怎么样”如果没有外部工具它只能基于已有知识猜测或拒答因为实时天气不在模型参数里。Tool 就是为了解决这个问题。从工程角度看Tool 本质上就是一个函数输入参数 - 执行逻辑 - 返回结果例如天气查询工具可以抽象成get_weather(city: string, date: string) - weather_report数据库查询工具可以抽象成query_database(sql: string) - rows代码搜索工具可以抽象成search_code(keyword: string) - matched_files这里有一个非常重要的边界模型不会真正执行工具平台才会真正执行工具。完整流程通常是平台把用户问题、历史上下文和工具列表发给模型。 模型判断是否需要工具。 如果需要模型输出工具调用意图和参数。 平台解析模型输出调用真实函数、命令或 API。 平台把工具结果写回 Context。 模型基于工具结果继续推理或生成最终答案。模型负责判断要不要调用工具选择调用哪个工具生成工具参数理解工具返回结果总结为用户可读答案平台负责管理工具权限校验参数执行真实调用捕获错误回传结果记录审计日志理解这个边界就能理解为什么 Agent 工程必须重视权限、沙箱、确认机制和审计。Agent 越能干越不能让它无约束地执行。八、MCP统一工具接入协议当工具越来越多新的问题出现了。同一个工具如果要接入不同 Agent 平台可能要为每个平台分别适配一套协议。例如一个文件检索工具如果要同时接入桌面助手、命令行助手、IDE 助手、企业知识库助手可能要写多套胶水代码。MCP全称Model Context Protocol可以理解为一套面向模型上下文的标准协议。它解决的问题是工具和资源如何以统一方式暴露给 Agent。MCP 通常可以承载三类能力Tools可执行函数比如查天气、搜索代码、查询数据库、调用内部 API。Resources可读取资源比如文件、文档、配置、数据表结构。Prompts可复用提示模板比如代码审查模板、故障分析模板、需求澄清模板。如果用一个类比来理解MCP 有点像 AI Agent 世界里的统一接口标准。没有统一标准时每个平台都要自己定义工具如何描述、如何调用、如何返回。统一之后工具开发者只需要按一种方式暴露能力不同 Agent 宿主就可以按标准接入。这对企业内部尤其重要。企业里往往已经有很多系统代码仓库知识库工单系统监控平台发布平台数据查询平台内部权限系统如果这些能力都能通过统一协议暴露给 Agent那么 Agent 就不再只是聊天窗口而会变成企业软件系统的新入口。九、Agent从回答问题到完成任务有了 LLM、Prompt、Context、Tool 和 MCPAgent 的轮廓就清楚了。Agent 的核心不是“一次回答”而是“多步执行”。一个典型 Agent Loop 长这样接收目标 - 分析当前状态 - 制定下一步计划 - 选择工具 - 执行工具 - 观察结果 - 更新状态 - 继续下一轮 - 输出最终结果例如用户提出帮我分析这个项目为什么测试失败并尝试修复。普通 Chatbot 可能只能给出一些建议。Coding Agent 则会尝试读取项目结构。 查看测试脚本。 运行测试命令。 分析失败日志。 定位相关代码。 修改代码。 再次运行测试。 如果还有失败继续迭代。 最后汇总修改内容和验证结果。这就是 Agent 和 Chatbot 的关键区别Chatbot 偏回答Agent 偏完成任务。常见 Agent 架构包括ReActReason Act边推理边行动。Plan-and-Execute先规划再逐步执行。Workflow Agent把任务拆成固定流程节点。Multi-Agent多个 Agent 分工协作。不同产品会采用不同实现方式但底层逻辑大同小异。Claude Code、Codex、Cursor、OpenCode、Hermes-Agent 等产品本质上都是把这套 Agent Loop 放进不同的工程场景里。十、Agent Skill把经验沉淀成可复用能力当 Agent 能读文件、调工具、执行任务之后很快会遇到一个新问题很多任务不是一次性的而是重复出现的。例如每次写技术文章都要按固定结构组织。每次做代码审查都要检查安全、性能、可维护性、测试覆盖。每次分析故障都要先看现象、再看日志、再定位变更。每次生成接口文档都要按团队模板输出。每次做版本发布都要先检查变更、风险、回滚方案。如果每次都把这些规则塞进 Prompt效率很低也容易遗漏。这就是 Agent Skill 的价值。Skill 是写给 Agent 看的能力说明文档。它通常会描述这个 Skill 适合什么任务任务目标是什么执行步骤是什么可用工具有哪些判断规则是什么输出格式是什么有哪些示例有哪些禁止事项一个典型 Skill 可以拆成两层。第一层是元数据层。它告诉 Agentname: tech-article-writer description: Use this skill when writing a structured technical article for developer audiences.这部分相当于 Skill 的名片。Agent 可以根据名称和描述判断当前任务是否匹配。第二层是指令层。它告诉 Agent 具体怎么做# Goal Write a publishable technical article for developer audiences. # Steps 1. Identify the target reader. 2. Extract the core technical chain. 3. Explain concepts from bottom to top. 4. Add engineering examples. 5. End with a practical summary. # Output Format - Title - Lead - Main sections - Architecture summary - Final takeaway这类设计背后有一个重要机制渐进式披露。Agent 不需要一开始就加载所有 Skill 的完整内容。它可以先读取 Skill 的名称和描述只有当任务匹配时才加载完整指令。这能带来三个好处节省 Token降低上下文噪声让团队经验可版本化、可复用、可审查对企业来说Skill 不只是 Prompt 文件。它更像一种轻量级 SOP一种把组织经验转化为 Agent 可执行能力的方式。十一、Coding Agent为什么开发者会最先感受到变化Agent 最容易落地的场景之一就是软件研发。原因很简单软件工程天然具备几个特点上下文丰富代码、文档、测试、日志、提交记录都可以被读取。任务可拆解分析、修改、验证、总结可以形成闭环。反馈明确测试通过与否、编译是否成功、Lint 是否报错都能作为观察结果。工具成熟Git、Shell、包管理器、测试框架、CI 系统都可以被工具化。这就是 Coding Agent 快速爆发的原因。以常见产品为例产品典型形态更适合的场景Claude Code命令行 Coding Agent大型仓库分析、跨文件修改、复杂任务拆解CodexOpenAI 体系 Coding Agent代码生成、修复、自动化工程任务CursorIDE Agent日常开发、代码补全、重构、上下文问答OpenCode开源/可定制 Agent私有化、企业集成、可控工具链Hermes-AgentAgent 工程框架或执行载体任务编排、工具集成、领域能力封装这些产品的差异不只在模型而在于运行环境能不能读完整项目上下文能不能调用命令能不能修改文件能不能观察测试结果有没有权限控制有没有任务记忆有没有可复用 Skill所以判断一个 Coding Agent 是否好用不能只看“它用了哪个模型”还要看它的工程闭环是否完整。很多团队刚开始用 AI 时停留在 Prompt 阶段。典型方式是把需求复制给模型让模型生成结果。这当然有价值但很难规模化。因为每个人写 Prompt 的方式不同输出质量也不稳定。更重要的是团队经验没有沉淀下来。真正进入 Agent 阶段后企业要沉淀的不是一堆零散 Prompt而是一套可复用能力体系业务知识 - 文档和知识库 工程规范 - System Prompt 和 Policy 操作流程 - Skill 外部系统 - Tool / MCP 执行闭环 - Agent Runtime这也是为什么 Agent 会推动软件工程组织方式变化。过去我们把经验写进文档靠人去读、去理解、去执行。未来更可能是把经验写成 Agent 可以理解和执行的 Skill让 Agent 在任务中主动调用。例如一个代码审查 Skill可以要求 Agent先理解变更范围。 再检查潜在 bug。 再检查性能风险。 再检查安全问题。 最后给出按严重程度排序的审查意见。一个技术写作 Skill可以要求 Agent先提炼知识框架。 再补齐背景概念。 再按开发者社区风格组织文章。 最后输出可发布 Markdown。这比单次 Prompt 更稳定也更适合团队协作。到这里我们可以把整套体系压缩成一张图LLM ↓ Token / Tokenizer ↓ Context / Context Window ↓ Prompt ├─ User Prompt └─ System Prompt ↓ RAG ↓ Tool ↓ MCP ↓ Agent Loop ↓ Agent Skill ↓ Domain Agent ├─ Coding Agent ├─ Knowledge Agent ├─ Data Agent └─ Business Agent每一层解决的问题如下层级解决的问题常见误区LLM语言理解、推理、生成把 LLM 误认为 Agent 本身Token模型处理文本的基本单位以为 Token 等于字或词Context模型当前能看到的信息总和以为上下文越长越好Prompt给模型任务和规则以为 Prompt 能解决所有问题RAG给模型提供相关知识以为 RAG 等于把资料全塞进去Tool连接外部系统以为模型自己执行工具MCP统一工具和资源接入以为 MCP 只是另一个 APIAgent Loop多步规划和执行以为 Agent 只是聊天机器人Skill沉淀可复用经验以为 Skill 只是长 PromptDomain Agent面向具体领域完成任务忽略权限、审计和边界这张图的重点不是名词而是层级关系。只有把底层链路打通才能判断一个 Agent 产品到底强在哪里又弱在哪里。最后Agent 时代真正的竞争力是什么过去十年软件行业经历了几次重要变化。从单体系统走向分布式服务。从手工部署走向自动化流水线。从脚本工具走向平台化工程。从人肉协作走向标准化流程。而今天我们正在进入下一个阶段Agent 驱动的软件工程。很多人担心AI 会不会取代程序员但从工程实践来看更可能发生的是程序员开始拥有自己的数字同事。它们不会取代开发者却会逐渐承担文档整理信息检索代码生成代码审查测试执行结果验证任务总结未来的软件团队很可能会变成人类工程师 Coding Agent Knowledge Agent Business Agent真正的竞争力也将发生变化。过去我们比拼的是谁写代码更快。未来我们比拼的可能是谁能把组织经验、业务知识和工程规范更高效地沉淀为 Agent 能够理解和执行的 Skill。因为代码可以生成。流程可以自动化。但优秀团队积累多年的工程经验才是最难复制的资产。从这个角度看Agent 的本质并不是新的聊天机器人。它更像软件工程领域的一次基础设施升级。而今天讨论的 LLM、Token、Context、Prompt、RAG、Tool、MCP、Agent Loop、Skill正是这场升级背后的底层构件。理解它们也是在理解未来软件工程的运行方式。学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%免费】