When ChatGPT drafts a weekly report, MidJourney produces a poster, or an AI assistant plans a trip, the experience can feel like one continuous act of intelligence. Under the surface, however, several different technologies are usually working together. AIGC, RAG, Agents, Function Calling, and MCP are often discussed as separate buzzwords, but they are better understood as layers in the same evolving AI stack.

Each layer solves a limitation left by the previous one: AIGC creates content, RAG gives it fresher and more specific knowledge, Function Calling lets it use tools, Agents allow it to plan and execute multi-step tasks, and MCP standardizes how those tools connect into a broader ecosystem.

AIGC: The Starting Point of Modern AI Applications

For most users, AIGC is the first visible face of AI. It is the foundation on which many later capabilities are built.

AIGC stands for AI Generated Content. At its core, it means using AI models to automatically generate content that meets human needs, either replacing or assisting people in content-related work. The value is straightforward: it lowers the barrier to creation and improves production efficiency. A draft that might take a person an hour can be produced in a minute; an illustration that once required a designer can now be generated from a text prompt.

From single-modal tools to multimodal assistants

AIGC did not become broad and flexible overnight. Its development moved from systems that handled one type of content to systems that can understand and generate across multiple formats.

<table> <thead> <tr> <th>Stage</th> <th>Core capability</th> <th>Representative models/tools</th> <th>Typical use cases</th> </tr> </thead> <tbody> <tr> <td>Single-modal</td> <td>Handles only one content type, such as text, image, or audio</td> <td>GPT-3 for text, Stable Diffusion for images, Whisper for speech-to-text</td> <td>Writing code with GPT-3, generating product images with Stable Diffusion, transcribing meeting recordings with Whisper</td> </tr> <tr> <td>Multimodal</td> <td>Understands and generates across content types, such as text-to-image, image-to-text, or text-and-image-to-video</td> <td>GPT-4 for image-text understanding, DALL·E 3 for text-to-image, Sora for text-to-video</td> <td>Uploading a product image to GPT-4 and asking for promotional copy; describing “a café after the rain” and generating an illustration with DALL·E 3</td> </tr> </tbody> </table>

The difference is not only technical. Single-modal AIGC behaves more like a specialized tool: Stable Diffusion draws images, Whisper transcribes speech. Multimodal AIGC moves closer to a general-purpose assistant: a model such as GPT-4 can inspect an image, write text, and revise code. That shift from “tool” to “assistant” is one of the key milestones in AI application design.

The built-in weaknesses of AIGC

Even powerful multimodal models have two major limitations.

First, their knowledge can become outdated. A model’s knowledge mainly comes from its training data. Once training is complete, the model does not automatically know what happened afterward. If a model’s knowledge cutoff is July 2024 and you ask how many people Tesla laid off in July 2025, it cannot reliably provide that answer. If you ask about tomorrow’s weather in Beijing, it also cannot produce real-time data on its own.

Second, AIGC can “say” things but cannot inherently “do” things. It can generate text, images, or other content, but it cannot execute real-world operations unless connected to external systems. If you ask it to book a high-speed rail ticket to Shanghai for tomorrow, a plain AIGC model can at most tell you to visit the 12306 website. It cannot place the order by itself.

These two gaps led naturally to two important additions: RAG for up-to-date or domain-specific knowledge, and Function Calling for tool-based action.

RAG: Giving AI a Searchable Knowledge Layer

RAG emerged to address the problem of stale or incomplete model knowledge. It works like giving an AI system access to a reference library that it can search before answering.

RAG stands for Retrieval-Augmented Generation. The basic idea is simple: when a user asks a question, the system first retrieves relevant information from an external database, document store, or the internet, then passes that retrieved material to the generative model so it can produce an answer. The model is no longer relying only on what it memorized during training.

A useful analogy is a student taking an exam. AIGC without RAG is like a student answering entirely from memory. AIGC with RAG is like a student allowed to consult reference books before writing the answer.

How RAG works

RAG is not just “search the web and paste the result.” A typical system has a structured process, usually split into data preparation and query response.

In the data preparation stage, large materials are converted into a retrievable format.

1. Chunking the data: Large documents such as company manuals, product documents, or news archives are split into smaller blocks, often around 500 to 1,000 Chinese characters per chunk in Chinese-language systems. This prevents the retrieval process from loading overly large passages.
2. Vector conversion: A vector model such as BERT or Sentence-BERT converts each text block into a vector, meaning a numerical representation of its semantic meaning. These vectors are stored in a vector database such as Milvus or Pinecone. The advantage of vector search is that it can find semantically similar content rather than relying only on exact keyword matches.

In the query response stage, the user’s question is handled in real time.

1. Semantic retrieval: The user’s question is also converted into a vector. The system searches the vector database for the most semantically similar text chunks, such as the top five most relevant passages.
2. Augmented generation: The retrieved passages and the user’s question are sent to the AIGC model together. The model generates a fluent answer grounded in the retrieved information.

This combination allows the final response to preserve the natural language quality of a generative model while incorporating current or specialized knowledge.

Where RAG is useful

RAG is often associated with real-time queries, but its larger value lies in domain-specific question answering.

• Enterprise knowledge bases: A company can store employee handbooks and product documents in a vector database. When an employee asks about the reimbursement process, RAG retrieves the relevant policy text and generates a structured set of steps.
• Academic research support: A researcher asking about recent breakthroughs in large language models in 2024 could receive a summary based on retrieved papers from top conferences such as NeurIPS or ICML.
• Customer service: An e-commerce support system can retrieve the after-sales policy for a specific product in real time, reducing errors caused by human memory or outdated scripts.

RAG solves the “I don’t know the latest or specific information” problem, but it remains an information-integration technique. It can find and summarize information, not perform operations.

If you ask it to book a train ticket, RAG can retrieve train schedules from 12306, but it cannot complete the order. If you ask it to summarize this week’s sales, it may retrieve raw sales data, but it does not automatically calculate totals unless connected to a tool. That is where Function Calling comes in.

Function Calling: Letting AI Use Tools

Function Calling is the step that turns an AI system from a content generator into a task executor. It allows the model to decide when an external function or API is needed, generate the required parameters, trigger the function, and then explain the result in natural language.

Put simply, earlier AI could only answer. With Function Calling, it can press buttons: call a weather API, query logistics, operate a spreadsheet, control smart home devices, or interact with a booking interface.

The typical execution flow

Function Calling generally follows four steps.

1. Intent recognition: The model analyzes the user’s request and decides whether a tool is needed. If the user asks for tomorrow’s weather in Shanghai, the system recognizes that real-time weather data is required and selects a function such as get_weather.
2. Parameter generation: The model extracts the parameters required by the function. If get_weather needs a city and a date, the phrase “tomorrow in Shanghai” can be converted into something like city="Shanghai" and date="tomorrow".
3. API or function execution: The system passes the parameters into the function, which calls an external interface such as a third-party weather API and receives the raw result.
4. Result formatting: The model turns the returned data, often JSON, into a natural-language response. For example: “Tomorrow in Shanghai will be 28°C with light rain, so it’s a good idea to bring an umbrella.”

Common scenarios

<table> <thead> <tr> <th>Scenario type</th> <th>Function call example</th> <th>Result</th> </tr> </thead> <tbody> <tr> <td>Daily services</td> <td>book_train_ticket(city_from="北京", city_to="上海", date="2025-10-01")</td> <td>Books a high-speed rail ticket on 12306 and returns an order number</td> </tr> <tr> <td>Office collaboration</td> <td>sum_excel_data(file_path="本周销售数据.xlsx", sheet="华东区")</td> <td>Calculates the total sales for East China in an Excel file and returns a summary such as “this week’s East China sales were 5 million yuan”</td> </tr> <tr> <td>E-commerce</td> <td>check_logistics(order_id="123456")</td> <td>Calls a logistics API and returns a shipment status such as “the package has arrived at the Beijing sorting center”</td> </tr> <tr> <td>Smart home</td> <td>control_light(room="客厅", status="on", brightness=80)</td> <td>Turns on the living room light and sets brightness to 80%</td> </tr> </tbody> </table>

Function Calling can support the full loop of query, operation, and feedback. But it is usually best at single-step actions. The user still needs to make the intent clear, and the model calls the matching tool.

For a more complex request such as “I want to drive from Jinan to Beijing during the National Day holiday; help me plan the trip,” basic Function Calling is not enough by itself. The user would have to issue separate commands: check the weather, then check highway traffic, then find service areas, then look for nearby hotels. The AI does not automatically decide the sequence, adapt based on results, or revise the plan if the weather is bad.

That kind of autonomous planning belongs to Agents.

Agents: Closing the Loop on Complex Tasks

An Agent combines the generation capability of AIGC, the retrieval capability of RAG, and the tool-use capability of Function Calling. The result is an AI system that can understand a task, break it down, plan the steps, execute them, and adjust based on feedback.

A simple comparison helps clarify the distinction:

• AIGC is like a secretary who can write copy.
• Function Calling is like an assistant who can operate tools when instructed.
• An Agent is closer to a project manager who can organize and complete a complex assignment, such as planning an event, arranging a trip, or preparing a weekly report.

What makes an Agent different

Agents are defined less by a single model capability and more by the workflow around the model. Four abilities are especially important.

1. Task decomposition: An Agent can split a complex request into executable subtasks. For a self-driving trip from Jinan to Beijing, it may break the job into checking weather, finding routes, locating service areas, searching for accommodation, and integrating recommendations.
2. Dynamic planning: It can decide the order of steps and select the tools to use. For example, checking weather first may affect later route and lodging suggestions.
3. Feedback-based adjustment: It can modify later actions according to earlier results. If it finds that Jinan will have rain during the holiday, it may add umbrella reminders, recommend hotels with covered parking, or suggest safer driving precautions.
4. Exception handling: It can respond to failures during execution. If a highway traffic API returns an error, the Agent may switch to another map API instead of simply stopping.

A concrete Agent workflow

For the request “Plan a self-driving trip from Jinan to Beijing during the National Day holiday,” an Agent might proceed as follows:

1. Understand the task: Identify that the goal is to produce an executable driving plan.
2. Decompose the task: Break it into subtasks: check weather in Jinan and Beijing during the holiday, find the best highway route and traffic conditions, locate service areas with fuel, restrooms, and dining, identify suitable accommodation near the route, and combine everything into a plan.
3. Select tools: Match each subtask with the proper resource: a weather API, a map API such as Amap, a service-area database through RAG, and a hotel booking API such as Ctrip.
4. Execute step by step: Query weather first, then route conditions, then service areas, then lodging. A possible intermediate result might be: light rain in Jinan on October 1, the Beijing–Taipei Expressway as the recommended route with no congestion, Dezhou Service Area with charging piles, and a hotel within a five-minute walk nearby.
5. Adjust based on feedback: Because of the rain, the Agent adds recommendations such as choosing a hotel with covered parking, carrying rain gear, and checking windshield wipers before departure.
6. Integrate the result: Return a structured plan including weather reminders, route details, service-area information, lodging suggestions, and safety notes.

This is the difference between a tool call and a task loop. The Agent is not merely answering one instruction; it is managing the process.

Why Agents are not yet everywhere

Despite their promise, Agents still face practical barriers.

The first is the high cost of tool integration. An Agent may need access to weather, maps, hotels, office software, internal databases, and more. Each tool may have different API formats, authentication methods, and parameter requirements. Connecting them one by one requires significant custom development.

The second is decision reliability. Agent planning depends on model judgment, which can go wrong. It may choose steps in an unreasonable order, such as searching for hotels before determining the route, or select the wrong tool, such as using a food API to query road traffic.

The third is resource consumption. Complex tasks require repeated model calls, tool calls, and retrieval operations. This increases latency and cost. Planning one trip, for example, may require more than ten API calls and nontrivial model usage fees.

Among these, tool integration cost is a particularly important bottleneck. MCP was designed to address exactly that.

MCP: A Standard Interface for the AI Tool Ecosystem

MCP, or Model Context Protocol, is infrastructure for the AI ecosystem. Its role is to standardize how Agents connect with external tools so that using tools becomes closer to installing plugins than writing custom integrations every time.

Anthropic released and open-sourced MCP in November 2024. Its core purpose is to define a standard interaction protocol between models and tools: how tools are described, how they are invoked, and how results are returned. With such a protocol, different models and Agents, such as GPT-4, Claude, or Qwen-based systems, can work with different tools, such as weather APIs, map APIs, or office software, through a shared interface.

A common analogy is USB. USB standardized how computers connect to peripherals. Whether the peripheral is a mouse, keyboard, or flash drive, the connection works as long as both sides support the protocol. MCP plays a similar role for AI and tools. If an Agent supports MCP, it can use tools that support MCP without bespoke development for each pair.

From M × N integrations to M + N integrations

Without MCP, every Agent needs to integrate separately with every tool. If three Agents need to connect to five tools, that means 3 × 5 = 15 integrations.

With MCP, each Agent and each tool only needs to implement the shared protocol. In the same example, three Agents and five tools require 3 + 5 = 8 implementations. The difference becomes more significant as the ecosystem grows.

<table> <thead> <tr> <th>Dimension</th> <th>Without MCP</th> <th>With MCP</th> </tr> </thead> <tbody> <tr> <td>Integration cost</td> <td>Each Agent connects to each tool separately; 3 Agents and 5 tools require 15 integrations</td> <td>Agents and tools follow the MCP protocol; 3 Agents and 5 tools require 8 implementations</td> </tr> <tr> <td>Coupling</td> <td>Agents and tools are tightly bound; a map tool built for GPT-4 cannot necessarily be used by Claude</td> <td>Loose coupling; any MCP-compatible Agent can call any MCP-compatible tool</td> </tr> <tr> <td>Ecosystem collaboration</td> <td>Tool libraries are fragmented by vendor and difficult to share</td> <td>An MCP tool marketplace can emerge, where tool developers upload MCP-compatible tools and Agent users install them like apps</td> </tr> <tr> <td>Maintenance cost</td> <td>If a tool API changes, all connected Agents must be modified</td> <td>Only the tool’s MCP adapter needs updating; Agents can remain unchanged</td> </tr> </tbody> </table>

The core specifications of MCP

MCP depends on standardization in three areas.

1. Tool definition: A tool must describe its metadata in a standard way, including its name, description, input parameters, parameter types, whether parameters are required, and output format.

Example MCP definition for a weather tool:

   {
    "tool_name": "get_weather",
    "description": "获取指定城市指定日期的天气数据",
    "parameters": [
      {"name": "city", "type": "string", "required": true, "description": "城市名称，如北京"},
      {"name": "date", "type": "string", "required": true, "description": "日期，格式YYYY-MM-DD"}
    ],
    "output_format": "json",
    "output_description": "包含温度、天气状况、风力的JSON数据"
   }

1. Invocation flow: MCP specifies how an Agent calls a tool, including how parameters are passed, often through HTTP/JSON, how timeouts are handled, such as a default 30-second retry, and how authentication works, such as placing an API key in the request header.
2. Result format: MCP standardizes how tools return results. A successful call might return "status":"success","data":{...}, while a failed call might return "status":"error","message":"参数错误". This lets Agents parse responses consistently.

Why MCP matters to the ecosystem

The value of MCP is less about inventing a new model capability and more about enabling ecosystem coordination.

For tool developers, one MCP adapter can make a tool available to all MCP-compatible Agents, rather than requiring separate integrations for each AI vendor. For Agent developers, it reduces the need to build every tool from scratch; they can use existing tools from an MCP-compatible marketplace. For users, it creates the possibility of installing capabilities freely: an office Agent might add Excel and enterprise messaging tools, while a lifestyle Agent might add food delivery or ride-hailing tools.

The Larger Pattern: Each Layer Solves the Previous Layer’s Limits

AIGC, RAG, Function Calling, Agents, and MCP are not isolated concepts. They form a progression:

1. AIGC is the base layer: It provides content generation and is the starting point for modern AI applications.
2. RAG and Function Calling are enhancement layers: RAG addresses timeliness and specialized knowledge; Function Calling gives the system the ability to use tools and perform actions.
3. Agents are the application layer: They combine generation, retrieval, and tool use into autonomous execution for complex tasks.
4. MCP is the ecosystem layer: It reduces the cost of connecting Agents to tools and provides a standardized foundation for wider AI application development.

The next stage is likely to move from single-Agent systems to multi-Agent collaboration. A travel Agent planning a family trip may call a child-focused service Agent for parent-child attractions, an elder-care Agent for accessible facilities, and a budget Agent to control costs. In an enterprise, a project Agent may coordinate with a development Agent for engineering progress, an operations Agent for marketing activities, and a finance Agent for cost calculations.

In that kind of environment, MCP becomes even more important. It can give different Agents a common way to share information and call one another’s capabilities, turning scattered tools and assistants into a more connected AI ecosystem.