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 + Policy

LLM
是
Agent
的推理核心，但
Agent
本身是一个更完整的工程系统。

这也是为什么同一个模型，在普通聊天框里只是
Chatbot
，
放到
Claude Code
、
Codex
、
Cursor
、
OpenCode
这类工具里，就变成了能读代码、改文件、运行命令、观察结果并继续修复问题的
Coding Agent
。

---

二、LLM：Agent 的推理发动机

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 和 MCP，Agent 的轮廓就清楚了。

Agent 的核心不是“一次回答”，而是“多步执行”。

一个典型 Agent Loop 长这样：

接收目标
-> 分析当前状态
-> 制定下一步计划
-> 选择工具
-> 执行工具
-> 观察结果
-> 更新状态
-> 继续下一轮
-> 输出最终结果

例如用户提出：

帮我分析这个项目为什么测试失败，并尝试修复。

普通 Chatbot 可能只能给出一些建议。

Coding Agent 则会尝试：

读取项目结构。
查看测试脚本。
运行测试命令。
分析失败日志。
定位相关代码。
修改代码。
再次运行测试。
如果还有失败，继续迭代。
最后汇总修改内容和验证结果。

这就是 Agent 和 Chatbot 的关键区别：

Chatbot 偏回答，Agent 偏完成任务。

常见 Agent 架构包括：

• ReAct：Reason + 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 可以拆成两层。

第一层是元数据层。

它告诉 Agent：

name: 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	大型仓库分析、跨文件修改、复杂任务拆解
Codex	OpenAI 体系 Coding Agent	代码生成、修复、自动化工程任务
Cursor	IDE Agent	日常开发、代码补全、重构、上下文问答
OpenCode	开源/可定制 Agent	私有化、企业集成、可控工具链
Hermes-Agent	Agent 工程框架或执行载体	任务编排、工具集成、领域能力封装

这些产品的差异不只在模型，而在于运行环境：

• 能不能读完整项目上下文
• 能不能调用命令
• 能不能修改文件
• 能不能观察测试结果
• 有没有权限控制
• 有没有任务记忆
• 有没有可复用 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 只是另一个 API
Agent Loop	多步规划和执行	以为 Agent 只是聊天机器人
Skill	沉淀可复用经验	以为 Skill 只是长 Prompt
Domain 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%免费】