Self-Taught AI Agent Development in Four Steps: From Zero to Landing an R&D Job Offer

A Bilibili creator shared their complete learning path from zero AI background to landing an AI Agent R&D job offer. According to their own account, just three months earlier they had no idea what a "large model" even was, and now they've successfully landed a job. This route, which they call the "four-step上岸 method," drew significant attention in the comments, with the creator stating: "As long as you can settle down and follow this path, three months of study will get you to job-ready level." This article breaks down the goals and logic of each step in this path, and adds some more actionable judgment.

Step One: Build Foundations — Understand How Large Models Actually Work

The creator summarizes this step into three things: the underlying logic of large models, prompt engineering, and API calls. This division isn't fancy, but the order is right.

Many people skip the first item and go straight to memorizing prompt templates, only to find themselves helpless when model outputs become unstable. Understanding the basic structure of Transformer, how tokens are predicted, and what the context window means—these determine whether your later prompt tuning is "guesswork" or "evidence-based parameter adjustment."

API calls are the most easily underestimated part. The gap between being able to write a client.chat.completions.create() and truly understanding streaming output, function calling, token billing, and error retry mechanisms often shows up in the follow-up questions during interviews.

Transformer and token prediction: Almost all current mainstream large models are based on the Transformer architecture, whose core is the Self-Attention mechanism, allowing the model to "see" all other words in the context and assign different weights when processing each word. The model is essentially a "next token predictor"—given the preceding text, it outputs a probability distribution over every candidate token in the vocabulary, then samples the next token according to a strategy, generating text character by character.

Context window: Refers to the maximum number of tokens a model can receive in a single inference (e.g., 8K, 128K). It determines how much conversation history, retrieved documents, and tool return values can fit in. Content exceeding the window gets truncated, which is the fundamental reason why long conversations require memory compression or retrieval.

Prompt engineering: It's not about memorizing templates, but understanding the model's sensitivity to instructions, examples, and format constraints, so you can design inputs with justification.

Step Two: Attack the Core — Use ReAct to Understand the Agent's Thinking Loop

ReAct (Reasoning + Acting) is a foundational paradigm in the Agent field that you can't avoid. The creator recommends implementing the ReAct loop by hand in code, rather than just reading papers.

The core insight here is: the difference between an Agent and a regular LLM call is not "a longer prompt," but a Thought → Action → Observation loop structure. The model first reasons about what to do, chooses to call a tool, gets the result, then re-enters the next round of reasoning. You have to write this while loop yourself, handle termination conditions, tool parsing failures, and loop count limits—these dirty tasks—before you truly understand the Agent.

If asked in an interview "What's the difference between ReAct and Chain-of-Thought," someone who's only read blogs might only say "ReAct has tool calls," while someone who's written it themselves can explain how Observation affects the next step of Reasoning—these are two levels of answers.

The deeper difference between ReAct and Chain-of-Thought: CoT just makes the model output reasoning steps before giving an answer, entirely enclosed within the model; ReAct inserts Actions interacting with the environment between reasoning steps, and writes the actual returned Observation back into the context as input for the next round of Reasoning. This means ReAct's reasoning trajectory is constantly corrected by external information, while CoT's reasoning chain is fixed once generated.

Engineering details: Implementing the ReAct loop requires handling several dirty tasks—parsing tool calls (the model's Action output needs to be parsed into executable calls), failure retries, loop termination conditions (the model gives a Final Answer or hits the step limit), and preventing the model from getting stuck repeatedly calling the same tool. These are exactly the key points that distinguish "read blogs" from "wrote code" when interviewers probe.

Step Three: Build Skills — Add Memory and Tools to the Agent

Step three is about making the Agent go from "runnable" to "useful." The specific exercise the creator gives is: build a customer service Agent with memory.

This topic choice is smart in its coverage. Building a customer service Agent forces you to handle several real problems: short-term memory (how to manage the current conversation context), long-term memory (how to store and retrieve user historical preferences), tool calls (how to integrate order lookup and return/exchange interfaces). Memory solutions range from the simplest conversation history concatenation, to vector database retrieval, to layered memory architectures—there's a lot of engineering trade-offs in between.

Tool integration is the same. Defining a tool's schema isn't hard; the hard part is making the model choose the right tool at the right time, handle tool return exceptions, and avoid meaningless repeated calls. These only surface when you actually build it.

Vector databases and retrieval: A common implementation of long-term memory is converting user historical information into embeddings and storing them in a vector database (such as Milvus, Chroma, pgvector), then retrieving relevant fragments by semantic similarity and concatenating them into the prompt. You need to understand that embeddings are semantic representations of text in high-dimensional space, and similarity is usually measured by cosine distance.

Layered memory architecture: In practice, it's often divided into three layers—working memory (current conversation window), short-term memory (summaries of recent rounds), and long-term memory (user profiles and historical facts in the vector database). Each layer has its own write and recall strategies, with trade-offs in cost, latency, and recall accuracy.

Tool call schema: This uses JSON Schema to describe tool names, parameters, types, and descriptions, based on which the model decides which tool to call and what parameters to pass. The difficulty isn't in defining it, but in making the model choose the right tool at the right time and properly handling tool return exceptions and empty results.

Step Four: Push for Projects — Multi-Agent Collaboration and Real-World Portfolio

The creator's final step suggests getting into multi-agent collaboration frameworks and completing two to three real-world projects.

Multi-agent is one of the most active branches in the Agent field right now, but frankly it's also the area most prone to "looking lively but producing hollow results." The recommended approach is to first make single-Agent solid, then try multi-Agent—otherwise it's hard to judge whether a multi-Agent system's failure is due to choosing the wrong collaboration framework or the single Agent itself not being well-built.

For the two to three projects, rather than piling up quantity, it's better to have each project solve a different layer of the problem: one focused on tool integration, one on memory and state management, one on multi-Agent orchestration. This way, in your resume and interviews, you're talking about coverage across capability dimensions, not repetitive work.

Multi-agent frameworks: Common options include AutoGen, CrewAI, LangGraph, etc. The core idea is letting multiple Agents with different roles (such as planner, executor, reviewer) collaborate through message passing to complete tasks. Typical collaboration patterns include sequential pipelines, debate-style, and hierarchical orchestration with a supervisor.

Why make single-Agent solid first: Multi-Agent system failures can often be attributed to a single Agent's reasoning or tool usage being inadequate, rather than the collaboration framework itself. Without single-Agent debugging experience, you can't pinpoint which link the problem is in. Therefore, it's recommended to first use tools like LangGraph to get a single Agent's state machine, memory, and tool chain working, then introduce multi-Agent orchestration—this way every failure can be attributed to a specific layer.

A Rational View of "Landing in Three Months"

At the end of the video, the creator specifically mentions the term "53 minutes of passion," clearly reminding viewers of the importance of persistence.

It should be objectively pointed out that going from zero to landing an offer in three months depends on several preconditions: effective daily study time, prior programming background, and the specific requirements of the target position. If you already have a backend or algorithm background, three months is reasonable; if you have zero programming experience, this timeline might be optimistic. But the logic of this path itself holds—foundations, core paradigm, engineering skills, project portfolio, four steps progressing layer by layer, no jumps, no fluff.

What truly determines whether you can land the offer may not be the path itself, but that one casually mentioned phrase: "settle down."

One-line Summary

Breaking down a Bilibili creator's four-step learning path from zero to landing an AI Agent R&D job, and its feasibility preconditions.

Paragraph Summary

The article breaks down a Bilibili creator's "four-step landing method" from zero AI background to landing an AI Agent R&D job offer. Step one: build foundations—understand Transformer's underlying logic, token prediction, context window, and master prompt engineering and API calls; step two: attack the core—implement ReAct's Thought→Action→Observation loop by hand in code, understanding the essential difference between Agent and regular LLM calls; step three: build skills—practice short/long-term memory and tool integration through a customer service Agent with memory; step four: push for projects—on the basis of solid single-Agent work, get into multi-agent collaboration and complete two to three real-world projects covering different capability dimensions. The article also rationally points out that landing in three months depends on daily study time and existing programming background; for those with zero background, the timeline may be more optimistic than realistic, and what truly determines success is "settling down."