Seven-Day Agent Primer: A Zero-Background Roadmap to Building AI Agents

Transitioning into AI agent development, many people fall into a misconception: they assume they must train large models from scratch. In reality, what enterprises truly need are people who can use AI to solve business problems. This article is based on a 12-week learning roadmap shared by a Bilibili creator, breaking down how to build a complete understanding of Agent development within seven days, and extending into hands-on capabilities for multi-agent collaboration, tool calling, and project deployment.

Why Defining Scope Matters More Than Rushing to Write Code

For Agent positions targeting a 30k salary, compensation is affected by multiple factors including city, experience, and interview performance — it's not a guaranteed floor price you get just by finishing the course. Those with existing development backgrounds can follow the 12-week pace; complete beginners need to build programming fundamentals first, and shouldn't force the schedule.

This roadmap is divided into four stages: weeks 1-2 for a basic Q&A assistant, weeks 3-5 for knowledge base retrieval integration, weeks 6-9 for connecting tools to form a closed loop, and weeks 10-12 for rate limiting, evaluation, and deployment. Each step has acceptance criteria — it's not finished just because "it can chat."

Stage One: A Customer Service Assistant That Can Receive After-Sales Questions

The goal of the first week isn't to make the model answer questions, but to build a basic system that can reliably receive HTTP requests, handle timeouts, and manage rate limiting.

Specific tasks include: getting HTTP interfaces and a basic database working, using the model API to handle streaming responses, and storing keys in environment variables rather than committing them to the repository. The database should be able to query orders and store tickets.

The prompt should clearly define task boundaries, make the model output fixed fields, and then validate the format with code. The acceptance criteria are clear: when the user doesn't provide an order number, the system follows up; when the model returns an incorrectly formatted response, the program can handle it.

Start recording failure cases from day one. Later, use this list to check whether changes have broken the system. This is far more important than blindly chasing feature quantity.

Stage Two: Make It Able to Look Things Up and Answer with Evidence

The core of weeks 3-5 is RAG. Retrieve materials first, then answer based on those materials — this is the key path to reducing hallucinations.

Document parsing should split by chapters, then perform vectorization and retrieval. Precise information like product models is suited to keyword matching, while queries like "can I still return it after opening the package?" are suited to semantic retrieval. Hybrid retrieval and reranking can be compared for effectiveness, but note that reranking only moves more relevant content forward — it doesn't eliminate hallucinations.

When there are old and new versions of rules, filter by effective date. Answers must include sources; if evidence is insufficient, follow up or escalate to a human.

The acceptance method is to compile 50 test questions covering normal phrasings, vague expressions, and cases where the materials contain no answer. Separately check whether the correct evidence enters the retrieval results, and whether the answer conforms to the evidence. Finding the wrong materials and misreading the materials should be fixed separately. Then keep a set of questions that weren't involved in debugging to check generalization ability.

RAG (Retrieval-Augmented Generation) is a technical architecture that lets large models retrieve external materials before answering, then generate answers based on those materials. Its core process is: convert the user's question into a vector, retrieve the most semantically similar document fragments from a vector database, pass these fragments as context to the model, and require the model to answer only based on these fragments. RAG exists to compensate for two major shortcomings of large models — information after the knowledge cutoff date can't be covered, and private data that doesn't exist in training corpora or isn't specific enough can't be answered. Compared to fine-tuning, RAG is cheaper and more flexible to update — changing one document changes the basis for answers. But it has boundaries: if the retrieval step doesn't find the right materials, no matter how strong the model is, it can't answer correctly; if materials are retrieved but truncated due to overly long context, errors also occur. Therefore, evaluating a RAG system requires two steps — first check whether the correct evidence enters the retrieval results, then check whether the answer conforms to the evidence. This is also why the original article emphasizes "finding the wrong materials and misreading the materials should be fixed separately."

Stage Three: Connect Tools to Form a Closed Loop

In weeks 6-9, first implement three basic tools: order lookup, logistics lookup, and ticket creation. Clearly specify parameters, return values, and error messages. Then run the loop of "decide to call → execute → read result → continue processing," setting a maximum step count and cost limit.

Use workflows when the process is fixed; use Agents when tools need to be dynamically selected based on results. First use the native API to understand the process, then choose a framework. LangChain leans toward application components, while LangGraph is suited for managing state branches and human confirmation. Don't memorize framework names and assume you understand architecture.

MCP is a protocol connecting tools and data — it won't backstop permissions for you. Refund scenarios require extra caution: practice in a simulated environment first, have the backend verify identity, order ownership, and amount, and require human confirmation before execution. If the same refund request is submitted repeatedly, it should only take effect once — this is called idempotency.

The model saying "allowed" doesn't mean the backend should execute. Context management should structurally preserve the current order, actions taken, and pending confirmations. Cross-user memory must be isolated — don't endlessly stuff all conversation records into the model.

The difference between an Agent and a workflow lies in who holds control. A workflow is a pre-orchestrated fixed path — what tool to call at each step and in what order is written by the developer, and the model only makes judgments within individual nodes. An Agent hands the decision of "what to do next" to the model, which dynamically selects tools based on the current state and decides whether to continue. The basis for choosing between them is task predictability: scenarios with stable processes and limited branches are more reliable, cheaper, and easier to debug with workflows; only scenarios with uncertain steps that require repeated adjustment based on intermediate results are worth using an Agent. Hybrid architectures are common in real projects — outer workflows ensure the main process stays controllable, while inner Agents at specific nodes handle open-ended judgments. The original article's suggestion to first hand-write the loop with the native API is precisely to understand the essence of tool calling: the model outputs structured function names and parameters, while the actual execution, validation, and result backfilling are all done by code — the model doesn't directly operate the system.

Idempotency means that executing the same operation once versus multiple times produces the same effect on system state. In scenarios like refunds, orders, and transfers, network timeouts or repeated user clicks can cause the same request to be sent multiple times. If the backend lacks idempotency protection, duplicate refunds or duplicate charges may occur. Two common ways to implement idempotency: first, the client generates a unique request ID, the backend records processed IDs, and duplicate requests directly return the previous result; second, use a business unique key (such as "order number + refund number") as a database unique constraint to intercept duplicate inserts. The original article emphasizes "the model saying allowed doesn't mean the backend should execute" because the model's output is essentially probabilistically generated suggestion text — it may be manipulated by prompt injection or give incorrect judgments due to context misunderstanding. Key rules like permission verification, amount limits, and identity ownership must be enforced in server-side code, not left to prompts to constrain model behavior.

Stage Four: Add Rate Limiting, Evaluation, and Deployment

In weeks 10-12, use FastAPI to provide services, Docker for deployment, and add login, robust logging and tracing, and fault alerts.

Testing isn't just about answers — it's also about whether tickets are actually created and whether escalation to humans happens when it should. Track task completion rate, response time, and per-call cost. Specifically test interface disconnections, duplicate submissions, unauthorized access, and prompt injection where documents contain phrases like "ignore the rules." Treat external text as materials, not system instructions, and put critical permissions in the backend. Use the same batch of questions for regression testing whenever you switch models or change prompts.

If you only have one hour a day, the suggestion is half an hour for features, half an hour for testing failures, and half an hour for reading docs. Don't pile up three half-finished projects — complete one project first. Find five target positions and compare requirements to fill gaps: those with backend experience should focus on model pipelines, while complete beginners should first build programming and engineering habits.

Common Questions

Q: Can complete beginners really get started in seven days?

Building a cognitive framework in seven days is feasible, but full mastery requires following the 12-week roadmap. Complete beginners must build programming fundamentals first, otherwise later stages will be extremely difficult.

Q: How do you prevent duplicate refunds?

Rely on idempotency design and permission verification as backstops — not just prompts. Model output is only a suggestion; the backend must enforce critical rules.

Q: How should you prepare for interviews?

Prepare a real failure case and explain clearly how you located, fixed, and retested it. On your resume, state clearly what problem you solved, how you verified it, and what the metrics were — only include measured results.

This roadmap comes from a Bilibili creator's hands-on experience sharing. The core viewpoint is: the key to Agent development isn't how strong the model is, but whether engineering capabilities are solid. Back to the question from the beginning — duplicate refunds rely on idempotency and permission backstops, not just prompts.

One-line Summary

The key to Agent development is engineering capability — follow the 12-week, four-stage roadmap from Q&A assistant to deployment.

Paragraph Summary

Based on a Bilibili creator's 12-week learning roadmap, this article breaks down the complete path for transitioning into AI agent development. The core viewpoint is that enterprises don't need people who train large models — they need people who can use AI to solve business problems. The roadmap has four stages: weeks 1-2 build a customer service assistant that can receive HTTP requests and handle timeouts and rate limiting; weeks 3-5 integrate RAG so answers have evidence and traceability; weeks 6-9 connect tools to form a calling loop while distinguishing when to use workflows versus Agents; weeks 10-12 add rate limiting, evaluation, and deployment. The article repeatedly emphasizes that sensitive operations like refunds must rely on idempotency design and backend permission verification as backstops, not just prompts, and provides daily time allocation suggestions and job-seeking preparation methods.