AI CONCEPT MAP

AI 核心概念
一口气串起来。

这些词单独看都不难,难的是它们总被拆开讲。我们从模型怎么接出下一个 Token 开始,一路跟到 Agent 怎样借助工具把事情做完。

11个核心概念
预计阅读约 30 到 35 分钟
适合谁第一次系统了解 AI 的你
THE WHOLE PICTURE

先看懂整张地图

LLM 通过 Token 接收和生成内容。这次要用的信息会进入 Context,Context Window 决定临时工作台有多大。Prompt 把任务和规则交给模型,Tool 让它取得外部信息或执行动作,MCP 负责更通用的连接。Agent 把这些能力组织成一个会继续工作的循环,Agent Skill 再把某类任务的成熟做法交给 Agent。

01

MODEL & LANGUAGE

模型怎么把话说出来

我们先不碰 Agent。把 LLM 和 Token 弄明白,后面的概念才不会像一串各说各话的缩写。
01.1

大语言模型

LLM

先记住这一句话

先把 LLM 想成一个很会续写的语言引擎。你给它开个头,它根据眼前的内容,一点点把后面接出来。

LLM 是 Large Language Model 的缩写,中文通常叫大语言模型。它从大量文本、代码和其他数据里学习语言规律。现在常见的大语言模型大多使用 Transformer 或它的变体,不过我们不需要先学懂整套架构,才能理解它怎么生成一句话。

假设你输入“第一次做网站,我应该先……”。模型不会先在某个看不见的地方写好整篇答案,再一次性交给你。它会根据已经看到的内容,判断下一个 Token 接什么更合适。接出一个以后,它把新内容也算进来,再判断下一个。

所以我们常说它像“文字接龙”。这个比喻不严谨,却很管用,因为它抓住了最基础的生成动作:看着前面,继续往后接。

一句回答是怎么慢慢长出来的

把内部细节先收起来,只看最简化的生成循环,大致是下面四步。

  1. 01
    读输入

    模型读取当前已经放进来的内容,包括你的问题和上层规则。

  2. 02
    选下一个 Token

    它为许多候选结果计算可能性,再按生成策略选出一个。

  3. 03
    把结果接回去

    刚生成的 Token 会成为新上下文的一部分,模型接着往下算。

  4. 04
    继续或停下

    循环会持续到回答结束、达到长度限制,或者流程转去调用工具。

顺着往下接:刚才为了方便,我们一直说模型在“接文字”。其实模型真正处理的单位不是字,也不是固定的词,而是 Token。

01.2

模型处理内容的基本单位

Token

先记住这一句话

Token 是 tokenizer 按自己的规则切出来的内容片段。它有时像一个词,有时只是半个词,偶尔还会细到一个符号的一部分。

模型为什么不直接读文字

模型内部做的是数字运算。我们写下“帮我做个天气助手”,它不能把这几个汉字原样塞进数学计算里。文字进入模型前,要先经过 tokenizer。你可以把 tokenizer 理解成翻译员,它负责把人能读的内容变成模型能处理的编号,模型输出以后,它再把编号还原成人能读的文字。

这里有两个很像的词。Token 是切出来的内容片段,Token ID 是这个片段在对应词表里的数字编号。它们关系很近,但不能混成同一个概念。

从一句话到模型,再回到一句话

  1. 01
    切分

    tokenizer 按自己的词表和规则,把输入拆成一串 Token。

  2. 02
    映射

    每个 Token 会对应到一个 Token ID,文字由此变成编号序列。

  3. 03
    处理

    模型根据这些编号对应的表示,计算接下来要生成的 Token。

  4. 04
    解码

    新 Token 的编号被转换回文字,多个片段连起来,就成了我们看到的回答。

顺着往下接:这次任务需要的 Token 会被放进同一张临时工作台。那张工作台,就是 Context。

02

WORKING MEMORY

模型这一次到底能看到什么

它看起来像是记得你。先别急着把这叫记忆,我们看看每次请求里到底装了什么。
02.1

上下文

Context

先记住这一句话

Context 是模型处理当前这一步时,实际拿到的全部信息。没有被放进来的内容,它这一次就看不到。

一次请求里的 Context 往往不只有当前问题。系统规则、开发者指令、部分聊天历史、工具说明、检索到的资料,以及模型已经生成的 Token,都可能在里面。不同产品怎么组装这些材料,没有一个完全相同的固定配方。

把 Context 想成一张临时工作台会比较好懂。应用把这次需要的材料摊在桌面上,模型看着桌面工作。资料没有拿上桌,模型就不能凭空使用;旧资料被拿走或压成摘要,模型能看到的细节也会跟着改变。

应用可能怎样整理一段长对话

  1. 01
    保留近期消息

    离当前问题最近的几轮对话通常最直接。

  2. 02
    压缩旧内容

    较早的聊天可能被总结,只留下人物、目标和关键决定。

  3. 03
    按需找回来

    应用也可以从历史、文件或数据库中检索与当前问题有关的片段。

顺着往下接:工作台不可能无限大。它一次最多能摊开多少 Token,就是 Context Window。

02.2

上下文窗口

Context Window

先记住这一句话

Context Window 是一次处理能够容纳的 Token 上限。它限制的是这次工作台的大小,不是模型一辈子的记忆。

窗口里的位置要大家一起用。系统和开发者规则要占一部分,你的问题、历史消息、文件片段和工具定义也要占一部分,通常还得给模型的回答留下空间。不同模型和接口对输入、输出怎样合计会有差别,所以实现时要看对应说明。

窗口变大当然有用,长合同、长代码和多轮任务能放进更多材料。但大不等于随便塞。把一堆不相干的内容倒进去,会增加费用和等待时间,也可能让真正重要的信息埋在中间。

顺着往下接:工作台准备好了,接下来得把任务和规则放上去。交给模型的这些输入,通常都可以放在 Prompt 这个大概念下面。

03

INSTRUCTIONS

谁在给模型下指令

Prompt 没有神秘咒语。说到底,我们是在告诉模型要做什么,也是在告诉它哪些边界不能越过。
03.1

提示与输入

Prompt

先记住这一句话

Prompt 是交给模型的输入和指令。它可以是一句话,也可以带背景、材料、例子、限制和交付要求。

一份完整 Prompt 可以包含目标、背景、参考材料、不能做的事、输出格式和验收标准。支持多模态时,图片、音频和文件也可能成为输入的一部分。所以把 Prompt 只理解成聊天框里的一行问题,会漏掉很多东西。

简单任务不用套十层模板。你问一个常识问题,正常说话往往就够了。任务越长、边界越多、出错代价越高,越需要把要求交代清楚。

顺着往下接:在一个真实产品里,指令不只来自用户。我们先看用户亲手输入的 User Prompt。

03.2

用户提示

User Prompt

先记住这一句话

User Prompt 是用户在当前任务里提出的请求、补充的信息,以及交给模型处理的材料。

它可能是一句“把这段话改得自然一点”,也可能是连续几轮修改、一个上传的文件,或者一组带数据的要求。用户每次补充“再短一点”“不要动标题”,都在继续改变当前任务。

User Prompt 很重要,但它通常不是最高层规则。应用会先遵守平台、系统和开发者设定的边界,再在这些边界内完成用户要求。

顺着往下接:如果产品要求数学老师不能直接报答案,这条规矩通常来自 System Prompt 或类似的上层指令。

03.3

系统提示

System Prompt

先记住这一句话

System Prompt 用来规定模型在这个产品里的角色、边界和做事方式,它比当前用户请求更靠上。

不同平台对指令层级的设计不完全一样。有些接口会把 developer instructions 单独分出来,让平台规则、开发者规则和用户请求各自处在不同层级。初学时不用背所有名字,先记住一条:当前用户说的话不能随便覆盖更靠上的规则。

System Prompt 适合放角色、语气、输出习惯和行为边界。它能强烈影响模型,但它仍然只是模型要遵守的信息,不是系统权限本身。

顺着往下接:到这里,模型已经知道要做什么,也知道要守什么规矩。可它要是需要今天的天气,只靠文字生成还是拿不到,得请 Tool 帮忙。

04

TOOLS & CONNECTIONS

模型怎么碰到现实世界

Tool 给它外部能力,MCP 负责更通用的连接方式。两者经常一起出现,但不是同一个东西。
04.1

工具

Tool

先记住这一句话

Tool 是应用提供给模型的外部能力。模型可以请求使用它,真正执行动作的通常是宿主应用或运行环境。

模型只看已有 Context 时,不知道此刻上海有没有下雨,也看不到你的日历和公司数据库。Tool 给它一条通往外部系统的路。工具可以是函数或 API,也可以是搜索、浏览器、代码执行器、数据库查询和文件操作。

应用会把可用工具的名称、用途和参数格式告诉模型。模型读到用户问题后,可以选择直接回答,也可以生成一份工具调用请求。接下来的动作很容易被讲错,所以我们把完整流程走一遍。

“今天要不要带伞”背后发生了什么

  1. 01
    用户提问

    你问今天上海要不要带伞。应用把问题和天气工具说明交给模型。

  2. 02
    模型提出调用

    模型判断需要实时数据,生成调用天气工具的请求,并填好城市和日期。

  3. 03
    应用检查

    宿主环境检查工具是否存在、参数是否合规,以及当前用户有没有权限。

  4. 04
    工具执行

    运行环境真正访问天气服务,拿到温度和降雨信息。

  5. 05
    结果回到 Context

    应用把工具结果交还模型,模型据此组织最终回答。

顺着往下接:如果每个 AI 应用都用一套自己的方式接工具,开发者会重复写很多连接代码。MCP 就是为这类连接问题准备的开放标准。

04.2

模型上下文协议

MCP

先记住这一句话

MCP 像 AI 应用的 Type-C 接口。它统一的是连接和交换方式,不是把所有工具变成同一个工具。

MCP 全称 Model Context Protocol,是连接 AI 应用与外部系统的开放标准。没有统一规范时,同一个外部服务接进不同客户端,常常要分别处理发现能力、描述参数、发起调用和返回结果。MCP 给这些动作约定了一套共同语言。

Type-C 的类比好用,是因为它说明了“接口统一”带来的方便。支持 MCP 的客户端可以更容易连接符合规范的服务端。不过协议统一不代表所有设备插上就一定能用,认证、权限、网络和客户端支持仍然要分别处理。

MCP Server 不只会提供 Tool

官方规范里有三类常见能力,初学时先分清它们各自负责什么。

  1. 01
    Tools

    可执行的能力,例如搜索、计算、读取任务或更新状态。

  2. 02
    Resources

    供应用读取并放进 Context 的资料,例如文件内容、数据库记录或项目历史。

  3. 03
    Prompts

    服务端提供的可复用提示模板,通常由用户或客户端选择使用。

顺着往下接:工具和连接都有了。如果任务要连续查位置、看天气、再找店铺,系统还需要一个能根据中间结果继续工作的循环,这就是 Agent。

05

AGENTIC WORK

从回答问题,到把任务做完

Agent 的变化不在名字,而在它会看着中间结果继续行动。Skill 则把一类任务的成熟做法提前交给它。
05.1

智能体

Agent

先记住这一句话

Agent 是由模型、指令、工具和执行循环组成的系统。它能根据中间结果决定下一步,直到完成、停下或把决定交还给人。

Agent 的工作循环

  1. 01
    理解目标

    模型先判断用户最终想拿到什么结果,以及当前缺哪些信息。

  2. 02
    决定下一步

    它选择直接回答、请求补充,或者调用某个工具。

  3. 03
    执行并观察

    运行环境执行动作,把结果、错误或权限问题放回 Context。

  4. 04
    调整计划

    模型根据新信息继续行动,也可能换工具、修正参数或缩小目标。

  5. 05
    判断是否结束

    任务完成就输出结果;遇到风险、缺少权限或反复失败,就停下并交还用户。

这也解释了为什么不能把 Agent 直接等同于模型。模型负责判断和生成下一步,运行环境还要保存状态、执行工具、处理失败、限制循环次数,并在敏感操作前取得授权。少了这些部分,模型只是给建议,任务并没有真的往前走。

Agent 也不一定非要做很长的计划。简单任务可能只走两三步,复杂任务才需要反复检查。设计重点不是让它显得自主,而是让它在清楚的边界里把事情做完。

顺着往下接:Agent 会做事了,但每次都重新解释团队流程很麻烦。把稳定步骤和配套资料打包起来,就到了 Agent Skill。

05.2

智能体技能

Agent Skill

先记住这一句话

Agent Skill 是一份可复用的工作说明包。它告诉 Agent 什么时候使用某套做法、具体怎么做,以及需要哪些配套资源。

一个技能目录里通常有什么

  1. 01
    SKILL.md

    必须存在,而且文件名要大写。它用元数据说明名称和用途,再用正文写工作方法。

  2. 02
    scripts

    可选。放需要执行的脚本,让步骤能稳定重复,而不是每次临时生成。

  3. 03
    references

    可选。放详细规范、领域资料和查阅说明,任务需要时再读取。

  4. 04
    assets

    可选。放模板、示例文件和交付素材,供 Agent 在实际产出中使用。

Skill 不只是长 Prompt。它可以把说明、代码、参考资料和模板放在同一个目录里。Agent 先根据名称和描述判断是否相关,匹配以后再读取完整说明,需要时继续打开引用文件。这种渐进式加载能减少一开始塞进 Context 的内容。

不同客户端把技能安装在哪里,支持哪些可选字段,并不完全一样。目录位置是客户端的决定,不是 Agent Skills 格式唯一规定的固定路径。

顺着往下接:概念不用再往后接了。我们用一次完整的出门任务,把十一块拼图放回同一幅画里。

PUT IT ALL TOGETHER

最后,用一次“出门”把它们全串起来

这次我们不列术语清单,就跟着任务走一遍。每个概念会在它真正派上用场的时候出现。

01下午准备出门时,你对 AI 说:“帮我看看要带什么。如果会下雨,再找一家回家路上能买伞的店。”这句话是 User Prompt。你说的是眼前要完成的任务,背后还可能有一条 System Prompt,要求助手只使用完成任务所需的位置,并在任何会影响外部系统的动作前先确认。

02应用发现这是一个多步任务,于是启动 Agent 的执行循环。与“出门清单”有关的 Agent Skill 被选中,里面写着检查顺序、天气判断规则和最后的回答格式。Skill 没有自己去查天气,它只是把成熟做法交给 Agent。

03Agent 先判断自己缺少位置,于是请求位置 Tool。宿主环境检查权限并执行,再把结果放回 Context。接着模型看到新的结果,决定调用天气 Tool。这里每次真正执行工具的都是运行环境,模型负责提出请求和选择下一步。

04天气结果显示下午会下雨,任务还没结束。Agent 继续请求店铺搜索 Tool,并用当前位置和回家路线筛选卖伞的店。如果这些外部能力通过 MCP 接入,客户端就能用统一的方式发现 Tools,也可能读取 Resources 或使用服务端提供的 Prompts。

05系统规则、User Prompt、Agent Skill 的说明、工具定义和每次返回结果都在占用 Context Window。应用不会无限制地把所有历史塞进去,它只保留当前任务需要的信息,并给后面的回答留出空间。

06最底层仍然是 LLM 在工作。所有文字和工具信息都被 tokenizer 转成 Token,模型根据当前 Context 判断下一步。目标完成后,它再一个 Token 接一个 Token 地生成最后的答复:“下午有雨,带伞。回家路线上的便利店可以买到。”

现在回头看,这些词并不是十一座孤岛。模型处理 Token,Context 装下当前材料,Prompt 给出任务和规则,Tool 与 MCP 连接外部能力,Agent 负责继续行动,Skill 则把成熟做法留给下一次任务。

CHECK THE SOURCES

想核对原始资料,可以从这里看

正文故意没有塞满脚注。下面四份资料分别对应最容易讲偏的几个概念。

回到首页