AI底层逻辑详解：大语言模型、Token、上下文、工具与智能体

人工智能领域每天都会冒出大量新名词：LLM、Token、Context Window、Prompt、Tool、MCP、Agent、Agent Skill……如果你对这些概念的理解还停留在“大概知道是什么意思”的层面，那么这篇文章正是为你准备的。

我们从工程实现的角度，把每个核心概念拆解透彻。不绕弯子，不说空话，只讲真实的技术逻辑。读完你会明白大模型为什么一个字一个字地往外蹦答案，也会理解当前最热门的智能体（Agent）到底是怎么运作的。

一、大语言模型（LLM）：本质上是一个文字接龙游戏

大语言模型（Large Language Model，简称LLM）是当前所有AI应用的核心引擎。市面上几乎所有主流大模型——无论是GPT系列、Claude还是Gemini——都基于同一个底层架构：Transformer。

这个架构由Google团队在2017年提出，论文标题是《Attention Is All You Need》。但真正让大模型走进公众视野的是OpenAI：2022年底GPT-3.5发布，成为第一个真正“可用”的大模型；2023年3月GPT-4推出，又把能力天花板拉高了一大截。如今GPT家族依然是行业标杆，但Claude、Gemini等后来者也在各自擅长的领域里表现不俗。

大模型到底怎么工作的？

答案朴素得让人意外：它就是一个文字接龙游戏。

举个例子：你问它“马克的视频怎么样？”模型会做这样几步操作：

1. 预测下一个概率最高的词——“特别”
2. 把“特别”追加到输入后面，再预测下一个词——“得”
3. 继续追加，预测——“棒”
4. 最终输出完整的回答：“特别的棒”

这就是大模型逐字（更准确地说，逐token）生成答案的根本原因。它不是一次想好整句话，而是一步一步往后接。每次生成一个新词，都会把它加到已有的文本里，然后基于更长的上文继续预测下一个。

这个机制听起来简单，但理解它之后，很多看似神奇的现象就说得通了——比如模型偶尔会“跑题”或者“重复”，本质上都是接龙过程中的概率选择出了问题。

二、Token与Tokenizer：大模型的“翻译官”

大模型本质上是一个数学函数，它只认数字，不认文字。那么人类写的句子是怎么被模型处理的？这就需要Tokenizer——一个介于人类语言和模型数字世界之间的“翻译官”。

Tokenizer做两件事：

• 编码：把文字拆成最小片段（也就是Token），再把每个Token映射到一个数字ID
• 解码：把模型输出的数字ID还原成人类可读的文字

Token不等于词语

这一点很多人会搞错。Token不是按照自然语言的“词”来切分的。

具体例子：

• 中文“程序员”可能被拆成“程序”和“员”两个Token
• 英文“helpful”可能被拆成“help”和“ful”两个Token
• 某些特殊字符甚至需要3个Token才能表示

所以当你看到“模型支持100万Token”时，不能简单地把它理解为“100万个词”。

经验换算值

在实际使用中，可以参考这些大致比例：

• 1个Token ≈ 0.75个英文单词
• 1个Token ≈ 1.5到2个汉字
• 40万Token ≈ 60万到80万汉字（相当于一本厚书）

了解Token的概念很重要，因为大部分大模型的计费方式、上下文窗口限制，都是以Token为单位的。

三、上下文（Context）与上下文窗口（Context Window）

Context可以理解为：大模型每次处理任务时，能够看到的所有信息的总和。它包括：

• 用户当前提出的问题
• 之前的对话历史
• 模型正在生成的Token
• 可用的工具列表
• System Prompt（系统提示词）

而Context Window，就是这个“记忆体”能容纳的最大Token数量。

主流模型的容量

不同模型的上下文窗口大小差异明显：

模型	上下文窗口大小
GPT-4.5	105万Token
Claude 3.1 Pro	100万Token
Cloudopus 4.6	100万Token

100万Token大约能装下150万个汉字。什么概念？《哈利波特》全集的中文译本，一次就能全部塞进去。

实际场景中的挑战

但现实工作中，你可能会遇到远超这个规模的材料——比如上千页的产品技术手册。这时候不可能把所有内容都丢给模型。怎么解决？

RAG技术（检索增强生成） 是常用方案：

1. 从完整文档中抽取与当前问题最相关的片段
2. 只把这些相关片段放进Context
3. 模型基于这些片段生成回答

这样做既能突破上下文窗口的物理限制，又能控制计算成本，因为你不需要为整本手册支付Token费用。

四、Prompt工程：怎么给大模型下指令

Prompt就是给大模型的具体问题或指令。它分为两种：

• User Prompt：用户直接输入的问题，比如“帮我写一首诗”
• System Prompt：开发者预先设定的人设和规则，用户看不到

好坏Prompt的差别有多大？

看两个例子就明白了。

模糊的Prompt：“帮我写一首诗”

→ 模型可能生成现代诗、打油诗、甚至是歌词，风格和格式完全不可控。

精准的Prompt：“请帮我写一首五言绝句，主题是秋天的落叶，风格要明亮一点”

→ 生成的内容会严格符合五言绝句的格律，主题明确，风格一致。

System Prompt的实战价值

配置一个System Prompt：“你是一个耐心的数学老师，不要直接给出答案，要引导学生思考。”

当学生问“3+5等于几？”时，模型不会直接说“8”，而是回答：

“可以这样想：你手里有3个苹果，又拿了5个，现在一共有多少个？你可以自己数一数。”

这种能力让大模型可以扮演不同的角色——客服、导师、编剧、代码审查员……只需要换一段System Prompt。

行业现状：Prompt Engineering为什么没那么火了？

前两年“Prompt工程师”还是一个热门岗位，但现在提的人越来越少。原因其实很实在：

• 门槛太低：本质上就是“把话说清楚”，不需要特殊技能
• 模型变强了：现在的大模型即使你指令有点模糊，它也能猜出你的真实意图

所以与其花时间学习各种“提示词技巧”，不如踏踏实实把自己的需求描述清楚。

五、工具（Tool）与MCP：让大模型感知外部世界

大模型有一个致命弱点：它无法主动感知外界。

你问它“今天上海的天气怎么样？”它会老实回答：“抱歉，我无法获取实时天气信息。”因为它从来没有联网，也没有内置温度计。

工具（Tool）怎么解决这个问题？

一个Tool本质上就是一个函数：给它输入参数，它执行操作，然后返回结果。

以天气查询工具为例：

• 输入：城市名称 + 日期
• 执行：调用气象服务的API接口
• 返回：天气数据（温度、湿度、降雨概率等）

完整的工具调用流程

整个流程涉及三个角色：大模型、工具、平台。

具体步骤如下：

1. 用户把问题发给平台
2. 平台把问题 + 可用的工具列表一起发给大模型
3. 大模型分析后，决定调用哪个工具，并生成调用指令
4. 平台根据指令去调用对应的工具
5. 工具执行完毕，把结果返回给平台
6. 平台把结果再发给大模型
7. 大模型把工具返回的数据整理成自然语言，回答用户

角色分工很清晰：

• 大模型：负责“动脑子”——选择用哪个工具、怎么把结果说清楚
• 工具：负责“动手”——执行具体的操作
• 平台：负责“传话”——把整个流程串联起来

痛点：各家平台的工具规范不统一

不同的大模型平台，要求工具按各自的规范接入：

• ChatGPT需要用OpenAI的规范
• Claude需要Anthropic的规范
• Gemini需要Google的规范

同一个工具，如果要在三个平台上都能用，代码得写三遍。这显然不高效。

MCP：统一的工具接入标准

MCP全称是“模型上下文协议”（Model Context Protocol）。它的作用可以类比成Type-C接口——无论什么设备，只要符合这个接口标准，就能通用。

对于工具开发者来说，只需要按MCP规范写一次代码，这个工具就能在所有支持MCP的平台上使用。不再需要为每个平台单独适配。

六、智能体（Agent）与智能体技能（Agent Skill）

Agent（智能体）是一个比普通对话模型更复杂的系统。它能够：

• 自主规划：自己判断需要分几步完成任务
• 调用工具：主动使用各种外部工具
• 持续工作：不达目的不停止

一个典型任务

假设你给Agent的任务是：“今天我这里天气怎么样？帮我查附近有没有卖雨伞的店。”

Agent的工作流程大致如下：

1. 先调用定位工具，获取当前经纬度
2. 再调用天气工具，查询实时天气
3. 发现天气结果是“下雨”，于是调用店铺搜索工具，查找附近的雨伞店
4. 把定位信息、天气信息、店铺信息综合起来，给你一个完整的回答

整个过程不需要你一步步指导——Agent自己会规划先做什么、后做什么。

另一个痛点：每次都要重复说明个人规则

还是用出门助手的场景举例。你希望Agent帮你判断出门要带什么，规则如下：

• 下雨带伞
• 光照强戴帽子
• 空气差戴口罩
• 回答格式必须是“先总结，再逐条列出物品并附原因”

如果没有Agent Skill，你每次提问都要把这些规则重新说一遍，非常繁琐。

Agent Skill：提前写好的说明书

Agent Skill的本质是一个Markdown格式的说明文档，专门写给Agent看的。它包含两部分：

• 元数据层：技能名称 + 简短描述（方便Agent判断什么时候该用这个技能）
• 指令层：目标、执行步骤、判断规则、输出格式、具体示例

如何创建一个Agent Skill

步骤非常简单：

1. 在当前目录下新建一个.cloudskills文件夹
2. 在这个文件夹里新建一个子文件夹，文件夹名称就是技能的名字
3. 在子文件夹里创建一个SKILL.md文件（注意：文件名必须全部大写）
4. 把完整的指令内容写进这个文件
5. Agent在遇到匹配的场景时，会自动加载并执行这个技能

配置好之后，你只需要输入“我要出门了，告诉我要带什么”，Agent就会自动：

• 调用定位工具
• 调用天气工具
• 按照预设规则判断需要带的物品
• 按照你指定的格式输出结果

七、核心概念关系一览

为了帮助你更好地理解和记忆，这里把所有概念的关系整理成一张清晰的对照：

概念	一句话解释
LLM（大语言模型）	整个AI系统的核心引擎，负责文字接龙式生成
Token	数据处理的最小单元，Tokenizer负责文字和数字之间的翻译
Context（上下文）	模型每次处理任务时能看到的全部信息
Context Window（上下文窗口）	Context能容纳的最大Token数量
Prompt（提示词）	给模型的具体指令，分User Prompt和System Prompt
Tool（工具）	让模型感知外部世界并执行操作的函数
MCP（模型上下文协议）	统一的工具接入标准，解决不同平台不兼容的问题
Agent（智能体）	能自主规划、调用工具、持续工作的系统
Agent Skill（智能体技能）	提前写给Agent看的说明书，告诉它怎么完成特定任务

八、常见问题（FAQ）

问：大模型每次生成回答的时候，是真的“理解”了问题吗？

答：从底层机制来看，它并没有人类意义上的“理解”。它只是在做一个接龙游戏：根据已有的文本，预测下一个最可能出现的Token。但因为训练数据极其庞大，这种预测在很多场景下表现出惊人的准确性，看起来像是理解了。

问：上下文窗口是不是越大越好？

答：理论上越大越好，因为你可以一次性塞进更多信息。但更大的上下文窗口意味着更高的计算成本和更长的处理时间。实际使用时，根据任务需求选择合适的模型即可，不一定每次都要用超大窗口。

问：RAG和更大的上下文窗口是什么关系？

答：它们是两种不同的思路。更大的上下文窗口允许你把更多原始材料直接塞进去；RAG则是先检索相关片段，只把有用的部分放进去。两者可以结合使用：即使窗口足够大，RAG也能帮你降低成本、提高响应速度。

问：Prompt Engineering真的不值得学了吗？

答：不是完全不值得，而是它的门槛已经低到大部分人都能自然掌握。核心就一条：把你的需求说清楚、说具体。不需要学习复杂的“咒语”或“模板”。

问：Tool和MCP的区别是什么？

答：Tool是具体干活的那个函数，比如“查询天气”这个功能。MCP是一个标准协议，规定了Tool应该怎么写、怎么被调用。有了MCP，你不用为每个平台重新写一遍Tool。

问：Agent和普通的对话模型有什么区别？

答：普通对话模型只能做“你说一句，它接一句”的单轮或连续对话。Agent能够自己规划步骤、主动调用多个工具、并且持续执行直到任务完成。它更像一个能自主工作的助手，而不是一个只会接话的聊天对象。

问：创建Agent Skill需要会编程吗？

答：不需要。Skill本质上是一份Markdown格式的说明文档，用自然语言写清楚目标、步骤、规则和输出格式就行。Agent会读取这份文档并按它说的去做。

结语

当你真正理解了LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill这些底层概念之后，再看AI领域层出不穷的新产品和新名词，就不会觉得神秘了。

无论是智能编程助手、自动化客服，还是各类AI代理框架，它们都运行在同一套底层逻辑之上。技术迭代的速度确实很快，但核心原理是稳定的。理解了这套框架，你就拥有了看懂未来AI技术的基本能力。