The Eight-Step Method for Agent Development: A Practical Path from Pitfalls to Production

Why Do So Many Enterprises Fail at Building Agents?

More and more people are working on Agent projects lately, and the questions in my inbox and comment section are almost always the same: the demo runs fine, but the moment it hits real business, it falls apart in every way—it doesn't call tools when it should, RAG retrieval isn't accurate, there's no fallback when a tool fails, things get chaotic when the context grows long, and costs are hard to control.

Over the past six months, this Bilibili creator has participated in Agent design collaborations with multiple enterprises, and the biggest takeaway was a counterintuitive conclusion: many enterprises jump straight into building Agents, but they're actually not a good fit for it.

The root cause is often this: they hear that Agents like those from OpenAI or Manus are impressive, but when they try it themselves, they find the results are worse than just honestly writing a Workflow. Especially in many scenarios, an RPA script can be up and running in a single night—stable and cheap. Instead, they bring in LangChain, add a vector database, and pile on multi-agent architecture, and what they end up with is slow, unstable, and money-burning. In the end, people even start to wonder, "Is AI just not good enough?"

The truth isn't that AI isn't good enough—it's that they chose the wrong tool.

Commercial Deployment: Intelligence Isn't That Important; Stability Is

The creator has deployed several mainstream Agent products multiple times and has also used DeepSeek-related tools. His conclusion is very pragmatic:

• Personal use: General-purpose Agents like Claude Code and Codex are extremely handy—there's no need to reinvent the wheel;
• Commercial deployment: It's best to adopt a "partial intelligence + high automation" approach, such as combining RPA or Workflow.

In scenarios that require guaranteed execution, intelligence is actually not that important; what matters more is ensuring stable output. This judgment forms the underlying logic of the entire methodology that follows.

It's worth noting that the hybrid architecture of "RPA + LLM" is gradually becoming the mainstream choice in enterprise deployment. The core advantage of RPA (Robotic Process Automation) lies in its precise execution of deterministic processes—it doesn't rely on probabilistic sampling; every step is 100% predictable and auditable. When RPA handles the structured operational layer and the LLM handles the understanding and decision-making layer, this combination often has an order-of-magnitude advantage in both stability and cost over pure Agent solutions.

The Eight-Step Learning Method: Getting Your Starting Point Right

If you really do need to develop an AI Agent, the creator does not recommend diving straight into the source code of complex frameworks—the barrier is too high for most people. A more sensible path is to go from basics to depth, step by step.

Step 1: Spend Half a Day Building a Cognitive Foundation

Don't jump straight into writing code. First, spend half a day to a full day getting clear on the core concepts of Agents. The benchmark is this: if you can explain in your own words what LLM, Tool Use, ReAct, context window, vector retrieval, Embedding, and Agent vs. Workflow mean, you're ready to get started. Digging deeper beyond that just becomes procrastination.

What is ReAct? ReAct (Reasoning + Acting) is an Agent reasoning paradigm proposed in 2022 by researchers from Google and Princeton University. Its core idea is to interweave the language model's "thinking" and "acting" to form a thought → action → observation iterative loop. This differs from the traditional Chain-of-Thought (CoT) pure reasoning chain—CoT only has the model write out its reasoning steps before answering, but the whole process is closed, and the model cannot access external information. ReAct, on the other hand, allows the model to call external tools (such as search engines, databases, calculators) at any point during reasoning to obtain real information, then continue reasoning based on the observations returned by the tools, forming a multi-round iterative loop of "Thought → Action → Observation → Thought → ...". This design enables Agents to handle complex tasks requiring real-time information or multi-step operations, making it one of the most important underlying paradigms in modern Agent architecture. Understanding this loop structure is the cognitive foundation for hand-writing Agents later on.

What is a context window? The context window refers to the maximum number of tokens a language model can "see" in a single inference. Early GPT-3 had a context window of only 4K tokens, while today Claude 3.5 supports 200K tokens and Gemini 1.5 Pro even reaches 1M tokens. The size of the context window directly determines how much conversation history an Agent can remember and how many tool return results can be stuffed in—it's the core constraint on resource allocation in Agent design.

Step 2: Find the One Scenario That Pains You the Most

Don't fall in love with the word "Agent" first and then go hunting for uses. Instead, first find the most annoying, most repetitive SOP in your work, then consider whether an Agent could take it over.

The judgment formula is simple:

• Fixed process → Use a Workflow (e.g., compiling daily reports into a weekly report every day);
• Path varies with input → An Agent is needed (e.g., a user makes a vague request, and it decides on its own what to look up first and then what to compute);
• No model reasoning needed at all (clicking buttons, copying fields, filling out forms) → Just honestly use an RPA script.

If RPA works, don't use Workflow; if Workflow works, don't use Agent. The simpler the tool, the lower the chance of it crashing. Forcibly wrapping everything in an Agent is the most expensive lesson for beginners.

Behind this judgment framework lies an important engineering philosophy: the reliability of a system is inversely proportional to its complexity. Every additional LLM call introduces a probabilistic node of uncertainty; every additional autonomous decision step in an Agent adds a potential point of failure. While pursuing "intelligence," you must always ask yourself: is the intelligence here really necessary?

Step 3: Hand-Write Your First ReAct—Don't Use a Framework

Many people's first move when getting started is to grab LangChain and chew through the docs. The creator's advice is exactly the opposite: never use a framework for your first Agent.

The reasoning is straightforward: LangChain/LangGraph wraps things too thickly. Beginners often get the demo running, but when something goes wrong, they have no idea where the error is. Anthropic's official guide also points out that the most successful Agents often don't rely on complex frameworks, but on simple, composable patterns.

The skeleton is really just a while loop: assemble the task and the existing "thought-action-observation" history into a prompt, let the model decide the next step, parse the action, call the tool, get the result and stuff it back into the history, and loop until the model says done. Directly call the OpenAI/Anthropic/DeepSeek SDK and hand-write it in under 100 lines of Python—it's more valuable than reading ten LangChain tutorials. The process of hand-writing ReAct is precisely about explicitly expressing the "thought → action → observation" chain in code—what the model outputs at each step, how tools are registered, how results are stitched back into the context—everything is visible and adjustable, and problems become obvious at a glance.

Hand-writing ReAct has a hidden benefit too: you'll truly understand where token consumption comes from. Every round of the loop appends content to the context, the history trajectory grows longer and longer, and costs keep rising. This intuition only sinks in deeply when you've written it yourself—frameworks hide these details.

Step 4: Lock Down the Model's Output (Structured Output)

Where do Agents crash? Eight times out of ten, it's due to incorrect model output format. Letting the model freely spit out JSON and then wrapping it in try/except is the worst code beginners are most likely to write. The professional approach is to use constrained decoding + strict validation, forcing the model to only produce valid formats from the source.

What is constrained decoding? Constrained decoding is a technique that applies grammatical or format constraints in real time as the model generates each token. Its core principle is: during the language model's sampling stage, the logit values of tokens in the vocabulary that don't conform to the current grammatical state are set to negative infinity (i.e., masked), making it physically impossible for the model to output invalid content. Typical open-source implementations include libraries like Outlines, Guidance, and LM Format Enforcer, which compile JSON Schemas into finite state machines (FSMs) and dynamically compute the set of valid tokens and apply masks at each generation step. Unlike the "generate-then-parse" post-processing approach, constrained decoding guarantees at the sampling level that output must conform to the specified format, fundamentally eliminating the possibility of format errors—this isn't about reducing the error rate, but about making errors mathematically impossible. OpenAI's Structured Outputs (launched in 2024) and Anthropic's tool-calling mode both natively support similar capabilities at the API level, greatly improving the output reliability of production-grade Agents. For self-hosted models, inference frameworks like vLLM and llama.cpp have also built in support for constrained decoding, requiring no additional development.

Making the Agent Actually "Do Things"

Step 5: Tool Use and MCP

The real value of an Agent lies in its ability to do things, not just talk. There are two things to learn here.

First, Tool Use: Writing a tool means writing a schema the model can understand—clear names, parameters, and return values. There's only one principle: actions should be idempotent and errors should be explicit, otherwise the model won't know how to recover when a call fails.

For example, a log search tool described as "searches service logs from the past N hours by keyword, returns a structured array of results" will be used correctly by the model at a glance; conversely, if it's named do_log_thing with a vague description, the model will basically just call it randomly. How well the tool description is written directly determines the Agent's success or failure.

"Idempotency" is especially critical in tool design: an idempotent operation means that calling it once and calling it multiple times produce the same result. Query operations are naturally idempotent, but operations like writes, sending messages, and transfers are not. For non-idempotent tools, they must be explicitly marked in the schema, and confirmation steps must be added to the Agent's planning logic to prevent the model from repeatedly calling them due to uncertainty and causing side effects.

Second, MCP: Anthropic's Model Context Protocol is becoming the de facto standard for Agents connecting to the external world. The officially maintained MCP Server set (GitHub, Slack, Postgres, Filesystem) all have ready-made implementations—read the code to learn the spec, then wrap one for your own business.

What is MCP? The Model Context Protocol (MCP) is a standardized protocol open-sourced by Anthropic in November 2024, aimed at solving the fragmentation of integrations between AI models and external data sources and tools. Before MCP, every Agent project needed to write separate adapter code for each tool, leading to a combinatorial explosion of "M models × N tools = M×N integrations." MCP reduces this problem to a decoupled architecture of "M model clients + N tool servers" by defining a standardized Client-Server communication protocol—analogous to how the USB-C interface unified charging standards, MCP provides a unified "socket" specification for LLMs. The protocol is based on JSON-RPC 2.0 and supports three types of capabilities: tool calls (Tools), resource access (Resources), and prompt templates (Prompts). The transport layer supports both stdio and SSE modes. This means that an MCP Server you wrap for one Agent can seamlessly connect to other models or platforms that support the protocol in the future, greatly reducing integration costs. Currently, mainstream AI products such as Claude, Cursor, Zed, and Windsurf have successively adopted MCP, and OpenAI also announced its adoption in 2025—the ecosystem is expanding rapidly.

Step 6: Add Memory (RAG Retrieval Augmentation)

Relying solely on conversation context isn't enough. For an Agent to handle real business, it must connect to external knowledge and long-term memory. RAG (Retrieval-Augmented Generation) was proposed by Meta AI in 2020. Its core idea is to retrieve relevant snippets from an external knowledge base before generating an answer, compensating for the timeliness and domain limitations of the LLM's parametric knowledge.

An LLM's parametric knowledge has two fundamental limitations: first, it has no knowledge of information after its training data cutoff date (the timeliness problem); second, internal enterprise documents, private databases, and the like never appeared in the training data (the domain limitation problem). RAG injects real-time external knowledge into the generation process through a "retrieve-augment" approach, enabling the model to answer based on the latest and most relevant information while avoiding the high cost of fine-tuning.

The RAG pipeline has four steps:

1. Chunking: Split by section and semantics—don't foolishly hard-split by 512 characters;
2. Vectorization: Convert to vectors and store in a vector database;
3. Hybrid retrieval: Overlay BM25 keyword search for hybrid retrieval;
4. Reranking: Use a Cross-Encoder to rerank and improve relevance.

Why hybrid retrieval? Pure vector retrieval (Embedding similarity matching) excels at capturing semantically similar content—even with different wording, as long as the meaning is close, it can find a match. But it's weak at hitting exact vocabulary, model codes (like "RTX 4090"), names of people and places, and proper nouns, because the semantic vectors of these words often deviate from their literal meanings. Sparse retrieval algorithms like BM25 (a classic information retrieval method based on term frequency-inverse document frequency) are exactly the opposite—extremely sensitive to precise keywords but unable to understand semantically similar synonymous expressions. Weighting and fusing the two sets of results through algorithms like RRF (Reciprocal Rank Fusion)—i.e., hybrid search—can significantly improve both the coverage and precision of recall, and it's now standard practice in production-grade RAG systems. On this basis, Cross-Encoder rerankers (such as BGE-Reranker, Cohere Rerank) further use heavier models to score each candidate snippet one by one, ranking the most relevant content at the front to be fed into the LLM, reducing the interference of invalid context on generation quality—this step typically improves RAG answer quality by another 10-20%.

When should you add long-term memory? A rough guideline: if the Agent needs to remember user preferences or historical conclusions across multiple conversations, add it; if a single task ends when it's done and the conversation context is sufficient, don't make trouble for yourself.

The Last Mile from Demo to Production

Step 7: Build an Evaluation Set

This step determines whether you're a beginner or a veteran. After changing a prompt, did it actually get better or worse? Gut feeling doesn't count. Without an evaluation set, you're tuning parameters in the dark.

The most basic approach: gather dozens of real tasks with standard answers, run them through after every change, and look at task completion rate, average number of steps, and error rate. The evaluation set doesn't need to be large, but it must be "dirty"—it must cover the tricky boundary inputs found in real scenarios.

Too many Agents perform stunningly on clean demo data, then get exposed the moment they go live and a real user phrases things differently. The root cause is that the evaluation set was too clean.

This phenomenon has a classic term in the ML field: distribution shift. The data distribution of the test set is inconsistent with the real production environment, causing offline performance to fail to reflect online results. For Agents, this problem is especially prominent—real user inputs are full of typos, omissions, ambiguities, and cross-language mixing, far removed from the carefully constructed demo data of engineers. The essence of building an evaluation set is to proactively narrow this distribution gap.

Practical tip: first, extract 30 of the most error-prone cases from online logs or real conversations, annotate what each should output—this is your first evaluation set, and afterward, just add a few new ones each week. The creator emphasizes that this is the highest-ROI thing in the entire engineering effort.

Step 8: Survive the Production Environment (Cost, Routing, Fallback)

Getting it to run is just the beginning; getting it to run stably in production still has a final stretch to go.

• Model tiering: Use cheap small models for simple classification and extraction, and only bring in large models for complex planning. Mixing two or three tiers of models within a single Agent is standard practice for both saving money and boosting efficiency;
• Fallback strategy: When a model fails N times in a row, automatically fall back to simpler logic or hand off to human processing.

Model Routing is a severely underestimated capability in production-grade Agent architecture. Taking early-2025 pricing as an example, the cost gap between GPT-4o and GPT-4o-mini is about 20x, and between Claude Opus and Claude Haiku it's about 60x. By training a lightweight "routing classifier" that automatically selects the appropriate model based on task complexity, you can often reduce overall API costs by 60-80% with almost no loss in quality. This classifier itself can be implemented with rules, small models, or embedding similarity—no need to call a large model.

These are the "unsexy but valuable" grunt work of Agent engineering. The earlier you do them, the more worry-free you'll be.

Final Words: Being Afraid of Pitfalls Is Fine, but Don't Let Fear Stop You from Acting

The creator's attitude is very clear: being afraid of pitfalls is right, but not taking action because of that fear is the biggest pitfall of all.

Models are advancing at a pace measured in "generations"—DeepSeek's Thinking capability, MiniMax's Interleaved Thinking, and Anthropic's wave after wave of Skill and MCP updates. You can't keep up just by watching. True understanding only grows in the "do-crash-fix" loop.

Treat these eight steps as a strategy map: cognitive foundation → identify the pain point → hand-write the first version → lock down output → take over tools → add memory → build evaluation → survive production. Each step corresponds to a verifiable project. Building according to the map will get you further faster than working through ten tutorials.

Key Takeaways