[KongchangAI]
· 4 min read· 2,127 words

The Truth About AI Agents: A Hundred Lines of Code + an LLM, Deconstructing the Agent's Underlying Logic

The Truth About AI Agents: A Hundred Lines of Code + an LLM, Deconstructing the Agent's Underlying Logic

An agent isn't a new model but a language model plus tools, a loop, and a goal—its power is the harness software around the model.

The article clears up a common misconception: an AI agent is not a brand-new AI species; its internal model is the same kind as a chat model and can only output text. The agent's core is the thin layer of ordinary software around the model—the harness. Through two missing parts it turns the model into an agent: tools, where the model writes a request and the harness executes it on a real computer and returns the result; and the loop with a goal, where the harness repeatedly sends all information back to the model, which chooses actions step by step until it judges the goal is met. It also distinguishes agents, workflows, and chatbots (who decides the next step), notes the harness is like the whole car and matters more than the engine, covers the loop's costs of repeated billing and error propagation, explains autonomy as a controllable dial, and lists four honest facts such as non-unified definitions and label abuse.

Title

AI智能体真相:百行代码+大模型,拆解Agent底层逻辑

Meta Description

AI agents are not a brand-new AI species, but a combination of a language model plus tools, a loop, and a goal. This article deconstructs the agent's underlying logic: how a hundred lines of Python achieve a three-quarters defect-fix rate, why the harness matters more than the model, and the truth behind the "agent washing" that Gartner points to.

Article Content

Most people have a misconception about AI agents: they think it's a brand-new, more powerful AI species. But the truth may be surprising—the model inside an agent is the same kind of model you use for everyday chat. On its own, it can't do anything: it can't open files, it can't press buttons, it can only output text.

So where do agents come from? Researchers at Princeton and Stanford once wrote an agent whose core was only about a hundred lines of Python, equipped with just one tool—the command line. On a standard test of 500 real software defects, this hundred-line program paired with a strong model reported a fix rate of about three-quarters.

The real power doesn't lie in the model itself, but in the thin layer of ordinary software surrounding the model.

The model writes a request, the program performs the real operation, then returns the result as text

What a Language Model Can and Cannot Do

A language model does only one thing: text in, next text predicted. You ask a question, it gives an answer.

Now ask it to fix a failing test in your project. It has never seen your project, can't see the files, and can't run the test. It can only do the one thing it knows—write a plausible-sounding answer based on patterns learned in training. With no verification, the answer may be wrong, and it stops after a single reply.

To keep things moving, you have to run the code yourself, copy the error, and paste it back. This is a chatbot: one question, one answer, and the human carries all the results around. The human is performing the actions and repeating the loop.

The Two Missing Parts of an Agent: Tools and a Loop

Part One: Turning "Permission" into Tools

The model can only write text, so we make an agreement with it: describe a few actions it is allowed to request—read a file, run a command, modify a file. These are called tools.

When the model wants an action, it doesn't perform it itself. Instead, it writes a short request: the tool name plus details. Another program listens alongside, reads the request, performs the real operation on the real computer, and hands the result back to the model as text. Now the model reads what actually happened, whereas before it could only guess. Note the division of labor: the model makes choices, the program does the executing. This program is called the harness (execution framework), and it is ordinary software.

Tool calling (Tool Calling / Function Calling) is the core mechanism by which language models interact with the outside world. The model does not directly perform operations; instead, it generates a structured piece of text in its output, usually containing a tool name and parameters (e.g., {"tool": "read_file", "path": "test.py"}). The harness parses this text, performs the corresponding operation in the real environment, and appends the result (successful output or error message) as new text to the conversation context. The key to this agreement is: the model only needs to learn "how to describe a request," while "how to execute" is entirely the responsibility of external software. Thus, the same model can work with different tool sets to adapt to completely different scenarios such as programming, search, and customer service. The tool descriptions themselves are also part of the prompt, and the model uses these descriptions to decide when to call which tool.

Part Two: The Loop and the Goal

A single action is rarely enough, so the harness doesn't stop after receiving one result. It sends all the information so far back to the model and asks again: what's next? The model reads the result and chooses the next action, the harness executes it, and the process repeats.

Track down the failing test, list files, read the test, run it to see the error, read the code, change one line, run the test again—this time it passes. No one wrote this sequence in advance; the model chooses at each step after seeing the result of the previous one. The model also decides when to stop: when it judges the goal is achieved, it writes a normal answer containing no request, and the loop terminates.

Developer Simon Willison offered a definition that many builders have adopted: an agent is a language model running tools in a loop. The model chooses, the tools execute, the loop repeats, and the goal determines when to stop.

This definition also corresponds to an older idea. According to the classic 1990s textbook, an agent is defined as "anything that can be viewed as perceiving its environment and acting upon it." For a language model, perceiving means reading results, and acting means writing the next request—both are text.

The classic 1990s textbook definition of an agent

The typical structure of the agent loop is: Observation → Thought → Action → Observation… and so on, repeatedly. In each round, the harness re-sends the complete conversation history (including system instructions, the user's goal, and all prior tool requests and returned results) to the model, which then decides the next step. This approach of "re-sending the full context" stems from the stateless nature of most current language models—they don't retain memory between calls, and each call is independent. The loop's termination condition is usually judged by the model itself: when it believes the goal is achieved, it outputs a normal text reply containing no tool request, and the harness detects that there is no tool request and stops the loop. In addition, the harness usually sets a maximum step limit to prevent the model from falling into an ineffective loop or incurring excessive costs.

The Key Difference Between Agents, Workflows, and Chatbots

Many products are called agents. One question can tell them apart: who decides the next step?

  • Chatbot: the human decides.
  • Workflow: the developer decides; the steps are hard-coded in advance, and the model only fills in each step.
  • Agent: the model decides; it directs its own flow, and two runs can be completely different.

This distinction comes from Anthropic's building guide. Workflows are predictable, agents are flexible, and neither is absolutely better. When you already know the steps, a fixed path is the right choice; when you can't foresee the steps, that's where agents come in.

The Harness Matters More Than You Think: The Engine and the Whole Car

The harness doesn't just execute tools. It also writes the instructions the model starts with, lists the available tools, and decides what is allowed. One author likens the model to an engine; then the harness is the rest of the car: steering, brakes, dashboard.

This is why the same model feels completely different in two products: in a chat window it answers questions, in a coding tool it completes entire tasks. The engine hasn't changed. This is also why a small harness with a strong model can go so far—the hundred-line agent at the start is exactly this: a loop, a tool, a conversation record. So when people compare agents, they are often comparing harnesses.

A sandbox is an isolated runtime environment used to limit the scope of an agent's operations. In a sandbox, the agent can freely read and write files and execute commands, but these operations are confined to a virtualized, closed space and cannot touch the host's important files, network, or system configuration. Common sandbox implementations include containers (such as Docker), virtual machines, or dedicated permission-isolation mechanisms. The value of a sandbox is that it allows the agent to work in "far-end" autonomy mode: even if the model makes a mistake (such as deleting a file by accident or executing a dangerous command), the damage is contained within the sandbox and does not affect the real production environment. Therefore, the sandbox is key infrastructure for balancing agent autonomy and safety, and a standard component of many serious harnesses.

The Cost of the Loop: Repeated Billing and Error Propagation

The loop is powerful, but it has a cost. The model retains no memory between calls, so each round the harness must re-send the entire conversation—instructions, every request, every result. This record grows with each step. A thirty-step task makes the model read the early steps thirty times. This is why agents are more expensive and slower than single answers.

Errors propagate too. An early wrong step enters the record, and subsequent steps build on it.

A wrong step enters the record and is inherited by later steps

Builders' advice is straightforward: use the simplest solution that works. When possible, prompts beat workflows, and workflows beat agents. An agent trades time and money for the ability to handle tasks no one can script in advance.

Autonomy Is a Dial, Not a Switch

Another point that distinguishes agents is their degree of freedom. It's a dial, controlled by the harness.

  • One end: read-only. It can view files and search, but can't change anything.
  • Middle: it can modify things, but must ask the human before risky operations like deleting files or sending messages.
  • Far end: it works alone inside a closed space called a sandbox, where mistakes can't reach anything important.

Every serious harness limits the number of steps so that a chaotic agent can't run indefinitely. So an agent is never simply "autonomous"—the goal, the tools, and the limits are all chosen by someone.

The Honest Part: Four Facts to Face

First, the definition is not unified. Before proposing his own definition, Simon Willison collected 211 different ones. The one in this video is the most common among builders, but it's still only one of several.

Second, the label is abused. Research firm Gartner estimates that of the thousands of companies selling agents, only about 130 offer the real thing; the rest are called "agent washing."

Gartner estimates that of thousands of vendors, only about 130 offer true agents

Third, the benchmark number comes from the team that built the program. It belongs to both the program and the model. Those hundred lines are the agent itself; the full package around it is much larger.

Fourth, a loop doesn't equal reliability. Agents still take wrong steps and still state false things. Humans remain responsible for their behavior.

Down to the Bottom: The Model Provides Judgment, the Software Provides Hands and Patience

On its own, a language model is text in, text out—it can't act, and it stops after one reply. Give it tools, and it can request actions executed by a program. Put it in a loop, and it can advance step by step, each step based on the previous result. Give it a goal, and it knows what to strive for and when to stop.

Model, tools, loop, goal—that is an agent. The model provides judgment, and ordinary software provides hands and patience. Without any one of these, it's not an agent.

One question to leave you with: an agent chooses its own steps, but the goal, tools, and limits are chosen by humans. So how much of its behavior is truly its own decision?

One-line Summary

An agent is not a new model, but a combination of a language model plus the four elements of tools, loop, and goal—the power lies in the harness software outside the model.

Paragraph Summary

The article clears up a common misconception: an AI agent is not a brand-new AI species; its internal model is the same kind as a chat model and can only output text. The core of an agent lies in the layer of ordinary software around the model—the harness. It turns the model into an agent through two missing parts: first, tools, where the model writes a request and the harness executes it on a real computer and returns the result; second, the loop and goal, where the harness repeatedly sends all information back to the model, which gradually chooses actions until it judges the goal is achieved. The article also distinguishes agents, workflows, and chatbots (who decides the next step), points out that the harness is like the whole car and matters more than the engine, notes that the loop brings the costs of repeated billing and error propagation, explains that autonomy is a controllable dial, and lists four honest facts including non-unified definitions and label abuse.

#AI agent#language model#harness#tool calling#agent loop#agent washing#workflow vs agent
Share:

Related articles