AI Agent或者LLM Agent深度讲解— (English)

Generated: 2026-06-21 22:24:51

---

Bro, you still think ChatGPT is the endgame of AI?

I thought the same way last year. It can write code, draft copy, and chat with you until three in the morning—I pointed at my screen and told my friend, “Who’s gonna hire anyone after this thing?”

Then that friend of mine, the one running a SaaS company, casually showed me something.

An automated customer service system. A user says, “Check my last month’s orders,” and guess what? It itself calls the CRM API, itself searches the database, itself generates a table—no human intervention the whole way. Like an invisible person doing the work.

I said, “Isn’t this just RPA? You know, those robots with hard-coded scripts?”

He laughed. He said, bro, this thing decides for itself how to search, what tools to use, and even double-checks the results afterward.

My head went bzzz.

Everyone thinks the big model is the finish line, but it’s just the tip of the iceberg. What’s really going to change business processes is an Agent that’s grown “hands and feet.”

From that day on, I threw all my spare time into it. Burned through several API accounts, and the pitfalls I fell into could fill a swimming pool. Three hundred-odd days later—no fluff today. I’m going to honestly pour out to you the traps I fell into, the bloody lessons I learned, and how I finally made my choice.

---

Let’s make it crystal clear: what does an Agent actually add?

A lot of people think an Agent is just ChatGPT with a shell that lets it call an API.

That’s a huge misunderstanding.

See, a regular AI chat is what? It’s a Q&A encyclopedia. No matter how you ask, it digs through its training data and tosses back the answer that fits best. But an Agent? It’s more like a new intern—you give it a goal, and it figures out how to break it down, what to do first, what to do next, and how to handle problems on its own.

Let me give you an example.

I asked ordinary ChatGPT to “research the latest developments in AI Agent frameworks over the past three months.” It wrote me a beautiful overview that looked spot-on. But when I asked for specific version numbers or which framework supports multimodality, it started making stuff up, fabricating on the spot.

Switch to an Agent instead. It first writes a search script, calls the search engine, scrapes the results, reads the LangChain 0.3 release notes, cross-references AutoGen’s changelog, and finally compiles everything into a markdown file on my desktop.

What’s the difference? One uses memorized knowledge (stale after a certain point), the other uses real-time information and tools.

That’s the core leap of an Agent: from “knowledge that’s remembered” to “things that can be done.”

Think about it—how massive is that difference?

---

Open it up: those four components of an Agent, not a single one can be missing

When I first started learning, I looked at all those architecture diagrams. An Agent system drawn like a spaceship control panel—memory module, planning module, tool-calling module… it made my scalp crawl.

Later, after building two systems myself, I realized the core is just four things, nothing mysterious at all:

The Brain — LLM

Without this, nothing works. I’ve used GPT-4, Claude 3.5 Sonnet, and a local Qwen2-72B.

Let me be honest with you: for complex tool calls and logical reasoning, Claude Sonnet is the most stable. GPT-4 sometimes goes in circles with its logic, and local models tend to lose track in large contexts. Imagine your Agent flaking at a critical moment—wouldn’t that drive you nuts?

Memory — Short-term and long-term

Short-term is the context window. The biggest I’ve seen is Claude’s 200K, but a big window doesn’t mean it handles it well. It’s like handing you a 200-page book—can you really remember what it said at the end?

I stepped in a huge pothole with long-term memory. At first, I naively stuffed the entire chat history into a vector database. The result? The Agent got sidetracked by history noise. It kept thinking something you said three hours ago was important, even though you’d moved on.

How did I solve it? I limited storage to “action–result” pairs only. What it did, and what happened—that’s all I saved. Recall rate jumped from 50% to over 80%.

Tools — What the hands and feet look like

Tool calling sounds simple, but the real trap is in the description.

I wrote a lousy function description once, and the Agent confused deleteuser with queryuser. Almost caused an incident in the test environment. Cold sweat. Imagine if that had gone live…

Now my requirement for descriptions is just one thing: clearly state when to call it, what format it returns, any side effects, and even add warnings. This isn’t just for the model; it’s for my future debugging self too. Treat it like an operations manual for an intern—the newer the person, the clearer you need to be.

Planning — Can break down steps on its own

This is the hardest, really.

ReAct is the most basic “think–act–observe” loop, but in production, you need to combine Plan-and-Execute or Reflection.

Let me tell you a true story. I tried to have an Agent write its own Python code for data cleaning—a simple task: parse ten CSV files and calculate the mean of each field.

So what happened?

First step: it wrote a loop to read files. Okay. Second step: defined a function but forgot to call it. Third step—guess what it did? It ran os.system('rm -rf /')!

Thank god I had set up a sandbox environment, or my computer would have been toast.

After that, I enforced an absolute sandbox and manual confirmation for all Agent code execution. This thing is clever, no doubt, but it’s also reckless when it wants to be.

---

Those fancy-sounding work modes—I tried them one by one, all tears

“Agent Loop,” “Plan-and-Execute,” “Multi-Agent,” “Agentic Workflows”… Names get cooler and cooler, but each has its own pain.

ReAct (Reason + Act) — The most basic, but also the easiest to go off track

Give the LLM a system prompt telling it what tools it can use, then let it output thoughts, actions, and observations at every step until the task is done.

I set one up in LangChain. Simple tasks ran smoothly. But when things got a little complex—like needing three consecutive tool calls before summarizing—the Agent started going in circles. As the context lengthened, it forgot the goal. And the token consumption was insane: one task could burn tokens equal to a whole day’s chat.

Plan-and-Execute — Champion of armchair strategy

I tried it first with early ChatDev code: let the Agent write a complete step-by-step plan, then execute it step by step.

The upside: it doesn’t lose its way halfway. The downside: the plan looks beautiful, but when execution hits step three and finds step three is impossible, everything deadlocks.

Later I added a “re-planning” module, but that doubled the cost. An Agent that can self-correct but burns money is still worth more than one that saves money but is brain-dead.

Reflection — The enhancement layer I use most often now

I don’t use it alone, but after every execution round, I add a “check if the result is correct; if not, redo” step.

For example, ask the Agent to write an SQL query, then have it run that query itself. Finds a syntax error? Rewrites it automatically.

Guess what? This works particularly well on smaller models. Mixtral 8x22b’s regular success rate was under 70%; after adding Reflection, it jumped to 85%. It’s basically making the Agent act as its own referee.

Multi-Agent — The time I got fooled the worst

I watched Google’s A2A protocol demos and AutoGen’s multi-agent showcases. So impressive. One writes code, one reviews, one tests—isn’t this the dream team?

I set up three Agents (search, analyze, write report). Half the time was spent making them wait for each other and