AI Agent from Zero to One: Core Principles and Five Key Modules Explained

Why Calling a Large Model API Isn't Enough

Anyone who has worked with large language models knows the basic flow: call the API, pass in some input, get a response back. It's a familiar "input → process → output" pattern. But if you want AI to genuinely handle complex tasks, having the model answer questions is only the beginning.

Imagine asking AI to complete a sophisticated piece of work. It needs to first understand the task, break it into steps, decide what to do first, execute that step, observe the results, and adjust the plan if things don't go as expected. At that point, AI is no longer just a question-answering model — it's something much closer to an autonomous agent capable of handling tasks on its own. That's the essence of what an Agent is.

A Bilibili content creator behind this tutorial series is candid about a common problem: most Agent tutorials on the market suffer from two critical flaws. First, they put the cart before the horse — opening with a barrage of jargon like "tool calling," "task planning," "memory mechanisms," and "ReAct framework" before beginners even have their footing. Second, they chase the "learn Agent in ten minutes" hook, leaving learners who can copy code but fall apart the moment the context changes. The right approach is: understand the logic first, then build the project.

The Essential Difference Between an Agent and a Plain LLM

The tutorial uses a vivid analogy to illustrate the difference: imagine you need to hammer a nail into a wall. You might know exactly how to do it, but thinking about it doesn't let you pick up the hammer or drive the nail in. Solving real-world problems usually isn't about arriving at an answer in your head — it requires "understand the problem → form a plan → use tools → execute → observe results," and adjust as needed.

This analogy highlights the key point: large models handle core understanding and reasoning, while Agents use that capability to continuously drive toward a goal and complete tasks. A plain LLM is a "thinker"; an Agent is an execution system that can actually "act" and iterate based on feedback. That distinction is the most important difference between an Agent and a simple API call.

The Five Modules That Make Up an Agent

If you think of an Agent as a complete system, it consists of more than just the large model serving as the "core engine" — it also includes a memory module, a planning module, a tools module, and an action module. Only when these components are assembled together do you get an Agent capable of handling tasks end to end.

Memory: Dividing Labor Between Short-Term and Long-Term

The memory module is intuitive. Say you're having an extended conversation with AI: in step one you pose a question, in step two you add constraints, and in step three you make a new request based on earlier results. If the AI has no awareness of what came before, the subsequent steps fall apart. So for any multi-step task, an Agent must retain the necessary context.

Memory comes in two flavors: short-term memory handles context within the current task — things like the ongoing conversation, task steps, and intermediate results stored in the runtime environment, which may disappear once that run ends. Long-term memory solves a different problem — in user-facing AI applications, the system records user interactions and retrieves that history via a user ID the next time they return. Simply put, short-term memory captures "what happened during this task," while long-term memory captures "what has happened with this user over time."

Planning: Task Decomposition and Adaptive Adjustment

Planning is where Agents diverge most sharply from ordinary Q&A systems. If your manager asks you to write an industry analysis report, you don't start typing the moment you receive the assignment — you break it down: define the industry scope, gather data, analyze it, distill key conclusions, and organize everything into a report. Agents work the same way: faced with a complex task, they first determine what steps are needed, then execute them one by one.

Agent research has produced several planning approaches, including Chain of Thought (CoT), Tree of Thought (ToT), and the ReAct framework. They don't all solve exactly the same problem, but they share a core goal: getting the model to engage in systematic reasoning and decision-making around a task, rather than just reaching for a final answer.

Critically, a plan isn't set in stone. Suppose the Agent lays out five steps, but partway through step three, the actual result diverges from expectations. Pressing on with the original plan could cascade into further errors. That's why Agents must be capable of adaptively revising and re-planning based on execution results — this is one of their most essential characteristics.

---

Chain of Thought (CoT) prompts the model to write out its intermediate reasoning before delivering a final answer — similar to how a person "shows their work" — which significantly reduces errors from skipping steps. Tree of Thought (ToT) goes further, expanding a single reasoning chain into a tree structure that lets the model explore multiple possible paths at each step and select the best branch, making it well-suited for complex problems that require backtracking. The ReAct framework (Reasoning + Acting) interleaves reasoning with tool calls: the model reasons about "what to do next," executes the corresponding action, receives real feedback, then reasons again — forming a tight "think → act → observe" loop. What all three approaches share is that they prevent the model from "guessing the answer in one shot" and instead distribute uncertainty across multiple verifiable intermediate steps, dramatically improving performance on complex tasks.

---

Tools: The Bridge to the Real World

Large models don't inherently have the ability to connect to the outside world. Ask one "What's the weather like in Beijing today?" and without real-time internet access, it can only answer based on its pretraining data. But give it access to live APIs — weather, stocks, flights — and it can pull real-time information through those services. That's what tools do.

The ecosystem of tools is broad: calculators, code execution environments, search engines, and APIs for all kinds of business systems. Tools are what connect the large model to the outside world — the model identifies what capability it needs and calls the corresponding tool; once the tool returns its result, the model uses that result to continue the task. In this way, a model that could previously only generate text gains the ability to work with external information and perform concrete operations.

---

Tool calling is typically implemented through the model's Function Calling capability. Developers declare a set of tools upfront — their names, descriptions, and parameter schemas — and when the model determines during inference that it needs an external capability, it outputs a structured call instruction (rather than natural language). An external program intercepts that instruction, actually executes it, and returns the result to the model. The key difference from an ordinary conversation is that the model's output is no longer just text — it's an "intent" that can be parsed and executed by a machine. Most mainstream large models (GPT-4, Claude, Gemini) natively support this mechanism, and popular open-source frameworks like LangChain and LlamaIndex provide higher-level abstractions that make registering and dispatching tools even more convenient. Understanding Function Calling is a prerequisite for making sense of most Agent code.

---

Action and the Decision Loop: The Agent's Core Mechanism

Once memory, planning, and tools are in place, one final piece remains — action. An Agent's goal isn't to create a plan; it's to complete the task. After planning out "search for information → organize data → run code → generate output," each step must actually be executed.

This is why an Agent is best understood as a loop system composed of four stages — Perceive, Plan, Act, Observe — which form the core flow of the ReAct execution framework:

• Perceive: Receive input from the external environment and pass it to the large model for understanding.
• Plan: The model assesses the current task, determines how to approach it, and decides what to do next.
• Act: Execute a specific operation — this might mean generating content, calling a tool, or hitting an API.
• Observe: Evaluate whether the execution result matches expectations.

The "Observe" step is especially important — it's the essential difference between an Agent and a simple workflow. Suppose the Agent has planned five steps, but the result of the first step turns out to be incorrect. Only when a result meets expectations does the Agent proceed to the next step; if it doesn't, the Agent must diagnose what went wrong and determine whether the remaining plan needs to change, triggering a new "Perceive → Plan → Act → Observe" cycle until the task is complete. An Agent, therefore, is not just a series of APIs strung together — it's a system that continuously adapts its execution based on environmental feedback.

The Real Challenges of Deploying an Agent

Putting it all together: the large model is the core engine, memory preserves context and history, planning handles task decomposition, tools connect external capabilities, actions carry out real execution, and the whole thing runs continuously through the "Perceive → Plan → Act → Observe" loop.

In practice, different tasks call for different planning approaches. Simple tasks with predictable, fixed processes may actually be more reliably handled by a conventional workflow. Agents are genuinely needed when the task involves dynamic decision-making, constantly changing conditions, and a requirement to continuously adjust steps based on feedback.

So when building an Agent, the first question to ask isn't "which technology should I use?" — it's "does my business use case actually need an Agent?" If the answer is yes, then you figure out what kind of planning and decision-making approach fits. That's also the foundation you need when diving into task decomposition, reflection, and re-planning later on.

Summary

The heart of an Agent isn't having a large model answer questions — it's giving the model the ability to understand a task, formulate a plan, call tools, take action, and continuously adjust based on results, all in service of a single goal. Once you understand this underlying logic, learning Agent frameworks, toolkits, and planning algorithms becomes much clearer — you can see exactly how each piece executes and what problem it solves. That understanding is the dividing line between "copying code" and "independently shipping a project."