Understanding Agents from Scratch: Three Technical Leaps from Tool Calling to Engineering Foundations

One core question keeps coming up in enterprise-grade AI agent development: why aren't native large language models enough, and what kind of Agent do we actually need? This article is based on a live session aimed at complete beginners, distilling the essential definition of an Agent, the four core problems it solves, and the three-generation technical evolution from tool calling to engineering foundations. Setting aside the marketing hype, the analogies and analysis around technical layering are genuinely worth bookmarking for anyone just getting started.

Why Native LLMs Aren't Enough

Native large language models — whether ChatGPT or DeepSeek^Ad — are trained by major companies at enormous cost, yet they come with several nearly unavoidable fundamental limitations.

First, no memory. By the time you're a dozen turns into a conversation, the model has often forgotten the earlier context — every interaction feels like starting from scratch. Second, knowledge cutoffs: the model only knows what was in its training data up to a certain date, so ask it about anything that happened after, and it will confidently make things up. Third, no ability to browse the web or call external tools — ask it about tomorrow's weather or the latest regulatory changes, and it can't give you a real answer, nor can it read data from your local machine or your company's database.

The more practical issue is that for ordinary users, accessing a native LLM directly means writing code or calling an API — neither of which is low-friction. These limitations are precisely what gave rise to the Agent layer.

What Is an Agent, Really?

A helpful analogy: an Agent is like a translator. When a Chinese speaker and an English speaker need to communicate, they need someone in the middle to relay the message. The same goes for users and LLMs — there needs to be an intermediary layer that understands what the user actually wants, calls the right tools to get it done, and then formats the results into something useful. In a single sentence: an Agent is a proxy for the era of large language models.

From an engineering standpoint, Agents play four distinct roles in the broader LLM ecosystem:

• Translator: Converts a user's vague request into instructions the model can act on, then transforms the model's output into something the user can understand.
• Tool Expert: Helps the model call APIs, execute web searches, and query data — turning the model from something that "can talk" into something that "can do".
• Memory Manager: Keeps track of context, user preferences, and multi-turn conversation history, so interactions feel coherent and the model doesn't "forget".
• Task Manager: Breaks a complex problem into smaller steps, plans the execution flow, and proactively tries different approaches when things go wrong.

The AI assistants we use every day — Doubao, the DeepSeek client — are all Agents. The question you send doesn't go directly to the model; it first passes through an Agent, which orchestrates the model through multiple rounds of processing before returning the most accurate answer. The same applies to coding tools like Claude Code and Cursor — they remember your project structure, call tools, debug code, and repeatedly verify results. At their core, it's the "Tool Expert" and "Task Manager" capabilities of an Agent doing the heavy lifting.

Three Technical Leaps in Agent Evolution

Agent development can be broken into three generations, each progressing from "passive execution" toward "autonomous planning" and finally to "engineering foundations."

Generation One: The Tool-Calling Era (Function Calling)

The technical term for this generation is Function Calling. Think of it as giving the LLM "hands and feet" — just as humans need limbs to take action, a model needs tool-calling capabilities to actually get things done.

For example: a user asks, "Pull up our sales figures for this year." A native model can't answer that, but with Function Calling, it can invoke the right tool — call a weather API for weather questions, query an internal database for sales questions. This generation behaves like an intern: nudge it and it moves; leave it alone and it stops. It's rigid, capable only of single-step execution.

Function Calling was first introduced by OpenAI in 2023 with GPT-3.5/4, and quickly became the industry-standard interface paradigm. The core mechanism works like this: when calling an LLM API, the developer pre-declares a set of available functions (including function names, parameter formats, and capability descriptions). When the model determines it needs to call a function to generate a response, it returns a structured JSON invocation instruction in its output rather than a direct text answer. The developer's code captures this instruction and actually executes the function locally or on a server, then feeds the result back to the model as a message for it to incorporate into a final response. Throughout this process, the model itself doesn't "run" any code — it only decides "what to call." This mechanism transforms the LLM from a pure text generator into a decision-making hub capable of driving external systems, and is the foundation for all subsequent Agent capabilities.

Generation Two: Autonomous Task Decomposition (Orchestrated Workflows)

Generation two achieved a leap from single-step execution to multi-step planning, enabling models to decompose tasks and think proactively.

Take "generate a sales report" as an example: the model first performs intent recognition, then runs two parallel tracks — one to extract internal sales data, one to define the analytical framework (since every company has different metrics and dimensions). The model then synthesizes a summary table and detailed reports, which are passed to a human reviewer before the final result is returned to the user.

Most mainstream Agent architectures on the market today — including ReAct — as well as low-code tools like Coze, are largely built on this generation's orchestration approach. But in real enterprise projects, this generation starts to reveal significant issues, which is what drove the emergence of generation three.

ReAct (Reasoning + Acting) is the most representative architectural paradigm of the second generation, jointly proposed by Princeton University and Google Research in 2022. Its core idea is to have the model alternate between three steps — "Thought → Action → Observation" — looping until the task is complete. Compared to pure Function Calling, ReAct requires the model to output an explicit reasoning chain before each action, making the execution process interpretable and debuggable. In practice, ReAct has also spawned variants like Plan-and-Execute (plan holistically first, then execute step by step) to handle complex tasks with long-range dependencies. The workflow engines in low-code platforms like Coze and Dify essentially solidify this kind of multi-step reasoning logic into visual nodes, lowering the barrier to entry — but at the cost of some dynamic planning flexibility.

Generation Three: The Engineering Foundation Era (DeepSeek Harness)

Generation three is called the "engineering foundation" era. A "four cars" analogy was used to distinguish between different technical forms — this is arguably the most valuable part of the whole discussion.

Car One — The Enclosed Freight Truck: Represents closed-source AI coding tools (like certain commercial Code tools). Strong cargo capacity, ready out of the box, just register and go. It also supports faster performance through Skills and MCP integrations — but the cargo hold and chassis can't be modified. Controllability and extensibility are clearly limited in enterprise scenarios; it typically only fits specific use cases (like AI coding), and switching contexts is a struggle.

Car Two — The Sedan: Represents closed-source paid products like ChatGPT. A polished, complete driving experience — but the platform controls the core. You can tweak the "bodywork and paint" through official plugins, but the architecture and the "engine" are off-limits.

Car Three — Traditional Open-Source Agent: The countless Agent projects that bloggers have open-sourced on GitHub. The upside: swappable and modifiable — developers with the right skills can plug in their own UI, adjust the framework, swap the "engine." The downside: everything is deeply coupled. Change one UI component and you might need to rework a large chunk of the codebase. Iteration costs are high, and the technical demands are steep. On top of that, 98% of these open-source projects are just demos — they're rarely ready to support a real revenue-generating enterprise project.

The engineering foundation (DeepSeek Harness) is positioned to strike a balance between out-of-the-box usability and deep controllability, providing a more engineering-grade, iterable base framework for enterprise-level Agent development.

"Harness" in engineering originally refers to a wiring harness or rigging — a framework that neatly bundles multiple cables or tools together for unified management. In the context of Agent development, the name DeepSeek Harness implies a positioning as "an engineering framework that systematically bundles together model capabilities, tool calling, memory management, task orchestration, and other components" — rather than a single-function module. This shares design philosophy with major Western frameworks like LangChain and LlamaIndex, though the latter often encounter excessive adaptation costs when deployed in Chinese enterprise scenarios due to overly abstract layers and steep learning curves. The core value of an engineering foundation lies in providing standardized module boundaries so that swapping out the UI layer, model layer, or tool layer doesn't trigger cascading changes — genuinely supporting a sustainable, iteratable commercial product rather than just a demo.

Closing Thoughts

For beginners, the greatest value of this framework is breaking down an abstract concept into the clear structure of "four roles + three generations." The most important thing to absorb is the thinking, not the code: once you understand the limitations of native models, the four functions of an Agent, and the trade-offs between controllability and extensibility across different technical forms, you'll be equipped to judge which approach fits your actual project. As for the specific engineering advantages of DeepSeek Harness over traditional Agent frameworks, those still need to be validated against real project source code.