LLM, Token, Context, Prompt, RAG, MCP, Skill, Agent: How AI's Core Concepts Fit Together

1. Overview

From 2024 to 2026, the number of terms in the AI field has exploded. Everyone has heard of LLM, Token, Context, Prompt, RAG, MCP, Skill, and Agent, but the real difficulty isn't memorizing them individually—it's understanding their relationships and roles within an AI system.

If you think of an AI application as a complete production line, it can be understood as the following chain:

LLM is the core reasoning engine, responsible for "understanding" and "generating".
Token is the basic unit of measurement for the information the model processes.
Context is the temporary workbench the model can see for each task.
Prompt is the instruction language you use to assign tasks to the model.
RAG is responsible for supplementing the model with external knowledge.
MCP is responsible for standardizing the connection between the model and tools or data sources.
Skill is responsible for solidifying stable processes and reusable experience.
Agent organizes all these components into an execution system that can complete tasks.

Let's first look at the overall landscape. You don't need to memorize every detail at first glance; just establish a general impression of "who comes first, who comes after, and who depends on whom."

Next, we will connect these concepts step by step, following the order "from underlying principles to engineering practice."

2. LLM: The "Brain" of the AI System

2.1 What is the Essence of an LLM?

The essence of a Large Language Model (LLM) is a probabilistic prediction engine that has learned language patterns from massive training data. Given preceding text, it predicts the next most likely token, repeating this process to generate an entire response.

It sounds like it's just "guessing the next word," but when the model has a sufficiently large number of parameters and rich enough training data, this ability to "predict the next token" can lead to the emergence of many high-level capabilities, such as summarization, translation, Q&A, programming, reasoning, and creation.

Input Text → Tokenizer → Token IDs → Transformer Calculation → Probability Distribution → Sampling → Output Token

2.2 What Role Does the LLM Play in the Overall AI System?

The LLM is more like the reasoning hub of an AI system. It doesn't directly access the external world, nor does it inherently possess the ability to "execute actions," but it excels at understanding, planning, summarizing, and generating based on current input.

Therefore, in engineering, the LLM is often responsible for three core tasks:

Translating a user's vague natural language needs into a clear task understanding.
Performing reasoning, decision-making, and content generation based on context.
Deciding whether to leverage external knowledge, external tools, or further multi-step execution.

In other words, the LLM decides "how to think," but not necessarily "how to get real information" or "how to get things done."

2.3 The Capabilities and Limitations of LLMs

Understanding an LLM isn't just about knowing what it "can do," but also what it "cannot do."

It is not a database. Trained knowledge is not guaranteed to be perpetually accurate or updated in real-time.
It is not a search engine. Without access to external retrieval, it can only answer based on its training memory.
It is not an executor. Without a tool interface, it cannot actually query a database, send a message, modify code, or create a work order.
It is not an absolutely rational system. Even with strong reasoning abilities, it can still hallucinate, misjudge, or miss constraints.

This is why Context, RAG, MCP, and Agent are introduced later: a "brain" alone is not enough; an AI system also needs "memory," an "external brain," "hands," and an "action framework."

2.4 A List of Mainstream LLMs

The table below shows common and well-known large models and their characteristic strengths.

Model Family	Typical Characteristics
Claude	Long context, strong reasoning and coding capabilities
GPT	Complete multimodal capabilities, broad ecosystem
Gemini	Large context window, tightly integrated with Google's ecosystem
DeepSeek	Significant cost advantage, active open-source/open ecosystem

2.5 A Minimal Example of Calling an LLM

The code below retains only the core calling path: passing in a role setting, a user question, and a few key parameters to get the model's output back.

import os
import requests

response = requests.post(
    "https://api.openai.com/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}"},
    json={
        "model": "gpt-4o",
        "messages": [
            {"role": "system", "content": "You are a backend engineer."},
            {"role": "user", "content": "Explain what recursion is in one sentence."},
        ],
        "temperature": 0.7,
        "max_tokens": 100,
    },
    timeout=30,
)

reply = response.json()["choices"][0]["message"]["content"]
print(reply)

Key parameters can be initially understood as follows:

messages: Tells the model "what the current conversation is about."
temperature: Controls whether the output leans conservative or divergent.
max_tokens: Controls the length and cost of the response.

3. Token: The Basic Unit of How the Model Understands the World

3.1 What is a Token?

A Token is the smallest computational unit when a model processes text. The model doesn't directly understand raw strings; it first splits the text into tokens, maps the tokens to numerical IDs, and finally converts them into vectors for computation.

Original Text: "Hello, World! 你好世界"
    ↓ Tokenizer
Tokens: ["Hello", ",", " World", "!", "你好", "世界"]
    ↓ Map to Vocabulary
Token IDs: [9906, 11, 1917, 0, 19526, 25461]

3.2 Why is Token Important in an AI System?

Many people first encountering Token might think it's just a tokenization detail. But in engineering, Token actually determines three major things:

Cost: Most models charge based on input and output tokens.
Speed: More tokens generally mean higher processing latency.
Capacity: The context window is essentially "the maximum number of tokens you can fit in."

So, Token is not a purely theoretical concept; it directly impacts your system's throughput, response latency, and budget control. Overly verbose prompts, too many retrieved documents, and untrimmed message history will all ultimately manifest as token cost and performance issues.

3.3 How to Read the Tokenization Flowchart?

The diagram below helps you build a clear intermediate-layer understanding of the "text → token → vector" process. Its focus is not on memorizing specific numbers, but on understanding that the model doesn't see the text itself, but a sequence of discrete tokens and their vector representations.

This is also why different languages, different writing styles, and even different spacing can lead to different token consumption.

3.4 A Rough Estimation of Tokens

Unit	Approximate Equivalent
1 Token	~0.75 English words
1 Token	~1.5-2 Chinese characters
1 Token	~4 English characters
1000 Tokens	~750 English words / 1500-2000 Chinese characters

These are just empirical values; the tokenizer rules are not completely consistent across different models. If you need to accurately assess cost or context usage, it's best to use the corresponding model's tokenizer or an online token calculator.

The image below shows a typical token calculator interface. Its purpose is to help you gauge the cost and length before "writing a Prompt / stuffing in documents / assembling context."

4. Context: The Model's "Workbench"

4.1 The Essence of Context

Context is all the information a model can "see" during a single call. It is not the model's permanent memory, but a temporary workspace dynamically assembled by the system each time a request is made.

From the model's perspective, it doesn't know "which parts are history, which are retrieval results, and which are tool return values." It only knows that at this moment, it has received a string of tokens and will perform reasoning and generation based on them.

4.2 The Role and Limitations of Context in the System

Context is one of the key variables determining the upper limit of answer quality. No matter how strong the model's reasoning is, it can only work based on "the information currently visible."

It primarily serves three roles:

Carrying the user's current task objective.
Providing the background, constraints, and history needed to complete the task.
Injecting auxiliary information like external retrieval results, tool return values, and system rules.

But Context also has clear limitations:

Limited capacity: No matter how large the window, it's not infinite.
Noise sensitivity: Too much irrelevant information can dilute key instructions.
Order sensitivity: Where high-priority information is placed affects the model's focus.

So, the real engineering problem isn't "stuffing all information in," but "putting the most important information in, in the way most suitable for the model to understand."

4.3 The Core Logic of Dynamically Building Context

After understanding the role of Context, looking at the code makes it easier not to get lost in the details. The code below retains only the 4 most critical steps:

Insert system rules.
Inject retrieval results and tool results.
Trim message history within the token budget.
Append the current user question.

import tiktoken

def build_context(task, system_prompt, history, rag_docs, tool_results, max_tokens=8000):
    enc = tiktoken.encoding_for_model("gpt-4")
    messages = [{"role": "system", "content": system_prompt}]

    if rag_docs:
        refs = "\n\n".join(rag_docs[:3])
        messages.append({"role": "system", "content": f"<references>\n{refs}\n</references>"})

    for result in tool_results:
        messages.append({"role": "tool", "content": result})

    history_budget = max_tokens * 0.4
    used = sum(len(enc.encode(m["content"])) for m in messages)

    for msg in reversed(history):
        size = len(enc.encode(msg["content"]))
        if used + size > history_budget:
            break
        messages.insert(1, msg)
        used += size

    messages.append({"role": "user", "content": task})
    return messages

The core idea this code expresses can be summed up in one sentence: Context is not a fixed template, but is temporarily assembled and dynamically chosen around the task objective.

4.4 The Three-Layer Memory Model of Context

Looking at Context from a broader system perspective, "memory" can be roughly divided into three layers:

Memory Type	Storage Location	Lifecycle	Example
Working Memory	Context Window	Current Reasoning	Current task state, just-obtained tool results
Short-term Memory	Conversation History	Current Session	Previous rounds of Q&A
Long-term Memory	External Storage	Cross-session	Vector DB knowledge, user preferences, business data

After understanding Context, the next natural question is: Since the model relies on context to work, how exactly should we articulate a task? This leads us to Prompt.

5. Prompt: The Language for Conversing with the Model

5.1 What is a Prompt?

If the LLM is the brain and Context is the workbench, then Prompt is the way you place tasks onto that workbench. It's not just a "question," but more like a task specification for the model: what role you want it to play, what goal to achieve, what constraints to follow, and in what format to output.

The quality of a Prompt often determines whether the model's output is "close enough" or "truly usable."

5.2 What to Focus on in This Prompt Diagram?

The focus of the diagram below is to help you upgrade from "just asking casually" to "giving structured instructions." Many poor Prompt results are not because the model is incapable, but because the input lacks a role, context, constraints, or an output format.

5.3 The Common Structure of a Complete Prompt

┌─────────────────────────────────────────┐
│  1. Persona                              │
│  2. Task                                 │
│  3. Context                              │
│  4. Output Format                        │
│  5. Constraints                          │
│  6. Examples (Optional)                  │
└─────────────────────────────────────────┘

These elements don't always need to be lengthy, but the more complex the task, the more necessary it is to articulate these parts clearly.

5.4 The Role and Limitations of Prompts

The core problem a Prompt solves is translating a vague intention into executable input for the model. It can significantly improve output quality, consistency, and controllability, but it is not a panacea.

A Prompt can improve hit rate, but cannot conjure knowledge out of thin air.
A Prompt can constrain format, but cannot completely replace validation.
A Prompt can guide reasoning, but cannot guarantee correct reasoning every time.

So, Prompt is a fundamental control method, but when a task starts to rely on external knowledge or external actions, a Prompt alone is insufficient. This is precisely why RAG and MCP come into play.

5.5 Three Common Prompting Techniques

Technique	Approach	Applicable Scenarios	Example
Zero-shot	Ask directly, no examples given	Simple tasks	"Translate to English: 你好"
Few-shot	Provide 2-5 input-output examples	Tasks with high format requirements	"Input: 苹果 → Output: apple"
Chain of Thought	Guide the model to think step-by-step	Reasoning, math, logic	"First list the conditions, then analyze step by step"

6. RAG: Giving the LLM an External Knowledge Base

6.1 Why RAG?

LLMs have two inherent shortcomings:

Knowledge cutoff date: Training data cannot be perpetually updated in real-time.
Hallucinations: The model can confidently fabricate non-existent content.

The core idea of RAG (Retrieval-Augmented Generation) is: retrieve first, then answer. It doesn't require the model to "remember everything itself," but instead first searches for relevant materials in an external knowledge base, then places those materials into the Context, allowing the model to generate an answer based on them.

6.2 How to Read the RAG Architecture Diagram?

The focus of the diagram below is not simply "adding a vector database," but that the AI's answering process is split into two stages:

The first stage is retrieval: finding the most relevant snippets from external knowledge.
The second stage is generation: organizing an answer based on those snippets.

This is the biggest difference between RAG and a "bare call to an LLM."

6.3 The Role of RAG in the System

The value of RAG is mainly reflected in three points:

Allows the model to access up-to-date or private information.
Makes answers as "evidence-based" as possible, rather than relying entirely on memory.
Transforms system knowledge updates from "retraining the model" to "updating external documents."

From an engineering perspective, RAG is more like adding a "consultable external brain" to the model.

6.4 The Limitations of RAG

RAG is important, but it is by no means a silver bullet.

If retrieval is wrong, the answer will be misled by incorrect context.
If document quality is poor, the model can only organize an answer based on low-quality materials.
Unreasonable chunking can lead to loss of key information or context fragmentation.
Too much recall will once again squeeze the Context budget.

So, what RAG solves is not "making the model smarter," but "giving the model more appropriate information when answering."

7. MCP: The "USB Standard" for AI Tools

7.1 What Problem Does MCP Solve?

When a model needs to call external capabilities like GitHub, databases, browsers, or file systems, a very real problem arises: every AI client needs to be individually adapted for every tool, causing integration costs to balloon.

This is the classic M×N problem.

Without MCP: M AI applications × N tools = M×N integrations
With MCP:    M AI applications + N tools = M+N integrations

7.2 Why is it Compared to a "USB Standard"?

MCP (Model Context Protocol) is essentially a unified protocol for connecting models with external capabilities. It doesn't directly improve a model's reasoning ability, but it drastically reduces the engineering complexity of "connecting tools."

You can think of it as an interface standard layer for the AI era:

Upwards, it serves AI clients or Agents.
Downwards, it connects various tools, resources, and templates.

So, MCP solves the problem of "how to standardize access to capabilities," not "how to make the model smarter."

7.3 How to Understand the MCP Architecture Diagram?

The most noteworthy part of the diagram below is the middle layer, the "unified protocol." It abstracts originally disparate tool capabilities into a unified access method, allowing the same tool to be reused by multiple AI clients.

MCP's common three types of capabilities include:

Capability	Direction	Description	Example
Tools	AI → External	AI calls an external function	`create_issue`, `run_query`, `send_email`
Resources	External → AI	AI reads external data	File content, database records, API responses
Prompts	Template	Predefined Prompt templates	Code review template, document generation template

7.4 A Minimal MCP Server Example

This code snippet doesn't expand on full engineering details, only retaining the three most critical things: registering a Tool, registering a Resource, and starting the service.

import asyncio
from mcp.server import Server
from mcp.server.stdio import stdio_server

server = Server("demo-mcp-server")


@server.tool()
async def get_weather(city: str) -> str:
    return f"{city}: Sunny, 28°C"


@server.resource("config://app")
async def get_config() -> str:
    return '{"app_name": "demo", "version": "0.1.0"}'


async def main():
    async with stdio_server() as (read_stream, write_stream):
        await server.run(
            read_stream,
            write_stream,
            server.create_initialization_options(),
        )


asyncio.run(main())

7.5 The Limitations of MCP

MCP is very suitable for solving standardized access problems, but it also has boundaries:

A unified protocol doesn't mean tool design is inherently reasonable.
Poorly written Tool descriptions will still cause the model to fail when calling them.
High-risk operations still require permission control and approval.
In some very simple scenarios, direct function calling is actually lighter weight.

So, MCP is progress at the "infrastructure layer," not a universal abstraction.

8. Skill: Reusable Domain Capability Modules

8.1 What Problem Does Skill Solve?

If you rely solely on Prompts every time to get the AI to follow rules and execute processes, you'll quickly encounter several problems:

The same set of requirements has to be rewritten each time.
Details are easily missed, leading to unstable output.
It's difficult for a team to unify versions and share best practices.
It's hard to combine capabilities like building blocks across different tasks.

This is where the value of Skill lies. It solidifies a class of stable, reusable knowledge and processes into a long-term capability module.

8.2 What is the Essence of a Skill?

A Skill can essentially be understood as a package of: "Standard Operating Procedure (SOP) + Templates + Scripts + Reference Materials."

It is suitable for storing rules that are relatively stable and don't need frequent real-time updates, such as code review standards, release processes, security checklists, and document generation specifications.

In other words, a Prompt is more like "how to do it this time," while a Skill is more like "do it this way from now on."

8.3 Skill vs. Prompt

Dimension	Regular Prompt	Skill
Lifecycle	Current conversation	Persistent, reusable
Content Form	Plain text instructions	Instructions + Scripts + Templates + References
Version Control	None	Git version control
Team Sharing	Copy-paste	Unified distribution, auto-update
Suitable For	Ad-hoc tasks	Stable domain rules and processes

8.4 What Does the Skill Structure Diagram Express?

The directory structure below helps you understand why a Skill is not just "a longer Prompt." It often bundles behavioral norms, templates, scripts, and reference materials into a single capability package.

my-skill/
├── SKILL.md
├── prompts/
├── scripts/
└── references/

8.5 An Example Skill Definition

---
name: python-code-review
description: Python code review skill, checks code quality according to team standards.
---

# Python Code Review Skill

## Role
You are a senior Python code reviewer.

## Checklist
1. Public functions must have type annotations.
2. Bare `except` is not allowed.
3. Direct concatenation of dangerous commands is prohibited.
4. Pay attention to performance and testability.

8.6 The Role and Limitations of Skill

Skill is excellent for solidifying "stable processes," but not suitable for carrying frequently changing information.

A simple rule of thumb: Things that are unlikely to change for three months are better suited for Skill; things that might change weekly are better suited for RAG.

Suitable for Skill	Suitable for RAG
Code standards, naming conventions	API docs, interface definitions
Security checklists	Database Schemas
Testing requirements, coverage standards	Architecture Decision Records (ADRs)
CI/CD process steps	Product requirement documents
Team collaboration norms	Post-mortem reports

The limitations of Skill are also obvious: if the content changes too quickly and maintenance lags, a Skill will quickly become outdated; if written too heavily, it increases the barrier to entry. Therefore, the key to a Skill is not "the bigger, the better," but "stable, accurate, and executable."

9. Agent: From "Conversation" to "Delivery"

9.1 The Definition of an Agent

The LLM, RAG, MCP, and Skill discussed earlier can all be seen as components, while an Agent is the system that organizes these components into an execution loop.

Agent = LLM + Planning + Memory + Tools

A regular LLM call is more like a consultant: you ask, it answers. An Agent is more like an executor: you give a goal, and it will break down steps, call tools, observe results, and adjust its strategy until the task is completed or definitively fails.

9.2 What Role Does an Agent Play in the System?

The core value of an Agent is not "being able to chat," but "being able to persistently advance towards a goal." It is typically responsible for:

Understanding the goal and breaking down the task.
Deciding whether the next step is to think, retrieve, or call a tool.
Updating its state based on tool results.
Continuing to iterate as necessary until completion or termination.

Precisely because of this, the Agent is the layer of abstraction closest to "turning AI into a productivity system."

9.3 What is the Key Point of the ReAct Diagram?

ReAct (Reasoning + Acting) is a very classic Agent approach. The core idea the diagram below wants to express is not the complexity of the process, but a minimal loop:

First, think about what to do next.
Then, execute an action.
Then, observe the result.
Then, decide the next step based on the result.

9.4 A Minimal ReAct Agent

The code below retains only the core skeleton of ReAct: Decision → Call Tool → Record Observation → Continue or End. This makes it easier for the reader to grasp the essence of an Agent, rather than getting bogged down in numerous auxiliary details.

class SimpleAgent:
    def __init__(self, llm, tools, max_steps=5):
        self.llm = llm
        self.tools = tools
        self.max_steps = max_steps
        self.history = []

    def run(self, task: str):
        for _ in range(self.max_steps):
            action = self.llm(task=task, history=self.history)

            if action["type"] == "finish":
                return action["answer"]

            result = self.tools[action["tool"]](action["input"])
            self.history.append(
                {
                    "thought": action["thought"],
                    "action": action["tool"],
                    "observation": result,
                }
            )

        return "Maximum steps reached, task not completed."


def search(query: str) -> str:
    return f"Search results for: {query}"

To summarize this code in one sentence, it expresses that: An Agent doesn't generate an answer in one shot, but gradually approaches the goal through multiple rounds of "Think-Act-Observe."

9.5 The Engineering Challenges of Agents

An Agent looks the most like an "automated employee," but it is also the layer most prone to problems.

Challenge	Description	Common Mitigation Strategies
Reliability	Can go off-track, loop, or misjudge	`max_steps`, timeouts, human approval checkpoints
Cost Control	Multi-turn calls can quickly consume tokens	Small model for planning, large model for execution, result caching
Tool Design	Unclear tool descriptions can lead to misuse	Clear schemas, structured error returns
Safety Boundary	Potentially dangerous actions can be executed	Permission isolation, approval mechanisms, read-only mode

So, the real difficulty with Agents is not "getting it to run," but "getting it to run stably, controllably, and traceably in a real environment."

10. Synergy: A Diagram to Understand How All Concepts Work Together

Each concept individually isn't too hard to understand; the real value lies in putting them into the same scenario.

Suppose you say to an AI coding Agent: "Please implement a new feature based on this GitHub Issue."

The following things typically happen in this process:

Prompt expresses your goal to the system.
The system assembles the task description, history, rules, retrieval results, etc., into Context.
The LLM performs understanding and planning based on the current Context.
If business materials are missing, it retrieves relevant documents via RAG.
If access to GitHub, the file system, or a database is needed, it calls tools via MCP.
If the team has stable processes, like code review standards, commit conventions, or release processes, they are reused via Skill.
The entire multi-step execution loop is driven by the Agent until the task is complete.

The overview diagram below puts these links back into the same real task flow.

11. Summary

If the entire text were to be compressed into one sentence, it could be remembered like this:

The LLM is responsible for thinking, the Token for measurement, the Context for carrying,
the Prompt for issuing instructions, RAG for supplementing knowledge,
MCP for connecting tools, Skill for solidifying experience,
and the Agent for organizing all of this into a system that can truly complete tasks.

Finally, let's re-emphasize a few common misconceptions:

Misconception	Truth
"A larger context window is always better"	A larger window doesn't guarantee better results; noise, latency, and cost also rise.
"RAG can solve all knowledge problems"	RAG's effectiveness highly depends on retrieval quality, chunking strategy, and document quality.
"A well-written Prompt is enough"	A Prompt is important, but it cannot replace external knowledge, tool access, and result validation.
"MCP will make the model smarter"	MCP solves the problem of standardizing tool connections, not improving the model's own intelligence.
"Every task needs an Agent"	Simple Q&A doesn't need an Agent; Agents are more suitable for multi-step reasoning, tool use, and goal execution.

When you truly understand the division of labor and boundaries of these concepts, you will find that the essence of an AI application is not "betting on the single strongest model," but organizing the model, context, knowledge, tools, and processes into a synergistic system. This is also the key step from "being able to use AI" to "being able to build an AI system."