From Prompts to Harness Engineering: The Evolution of AI Agent Development Paradigms

Why AI Engineering Paradigms Keep Evolving

In today's world where AI-assisted development has become the norm, a core question emerges: why does our AI engineering methodology keep evolving? From the earliest prompts, to context engineering, and now to Harness engineering—each leap corresponds to a previously unsolvable engineering dilemma.

Based on the Bilibili tutorial on Harness engineering from principles to practice, this article systematically traces this evolutionary path and, combined with the real pain points of enterprise-level projects, analyzes why Harness engineering has become the infrastructure of the AI Agent era.

Starting with a User Login Requirement

Imagine this scenario: an intern joins your company, and you hand them a requirement—"develop a user login feature for a three-tier system." For the intern, they'd be instantly stumped: What's the project's tech stack? How is the user table's database structure designed? Where are the API specifications? How should the development and testing environments be connected?

This is precisely the dilemma facing today's large language models. The tutorial offers an apt analogy: a large language model is like a high-IQ intern—it can write code, understand lengthy documentation, and summarize and analyze data, but it has no understanding whatsoever of your engineering environment. No matter how capable, it has no starting point.

Prompt Engineering: Giving the Model More Information, But Not Raising Its Ceiling

When we directly throw "develop a user login feature" at an AI like Doubao, we find that it can indeed produce a runnable piece of code. But the problem is—this code often doesn't meet real requirements.

And so prompt engineering was born, rapidly gaining popularity in recent years. As a core technique for interacting with large language models, prompt engineering matured quickly during 2022–2023 alongside the widespread adoption of GPT-3/4. Role prompting, Chain of Thought (CoT), Few-shot examples... these techniques can indeed improve output quality. Among them, CoT was formally proposed by Google researchers Wei et al. in 2022, improving performance on complex tasks by guiding the model to reason step by step. Few-shot Learning draws on meta-learning ideas, embedding a small number of examples in the prompt to let the model generalize quickly. Role prompting leverages the role-related knowledge the model acquired during pretraining, activating domain-specific professional output through identity.

Worth understanding more deeply is the cognitive-science foundation of these three techniques: CoT essentially simulates the externalization of human "slow thinking" (System 2 thinking), making implicit reasoning steps explicit to reduce the accumulation of errors caused by the model skipping steps. Few-shot leverages the "In-Context Learning" capability that Transformers develop during pretraining—the model needs no gradient updates and can temporarily adjust its output distribution at inference time based solely on examples. This phenomenon has yet to be fully explained theoretically and remains one of the important research topics in the NLP field.

But there's a fact that's easily overlooked: these techniques essentially exploit the model's existing capabilities rather than expanding its capability boundaries—prompts don't actually raise the model's abilities, they merely provide the model with more relevant information. This is like collaboration between people—if you only hand a colleague a requirement without explaining the business background, technical architecture, and database structure, they'll be equally stumped. Conversely, if you clearly explain the business research chain and database structure, your colleague can locate the problem without you needing to say more.

There's only one keyword: context. Any non-trivial problem, when dealing with complex business logic, cannot avoid context.

Context Engineering: Solving the Information Problem, But Hitting Three Walls

When we provide the AI with complete context—the tech stack, database choice (MySQL or MongoDB), backend framework (FastAPI or Django), caching solution, and so on—the effectiveness of code development improves qualitatively.

However, once you enter a real enterprise-level project, context engineering hits three walls:

The First Wall: The Physical Limit of the Context Window

The context window is the maximum text length a large language model can process at once, measured in Tokens (typically an English word is about 1–2 Tokens, and a Chinese character is about 1–2 Tokens). The context windows of mainstream large models have expanded rapidly: early GPT-3 supported only 4K Tokens, early versions of DeepSeek stayed at 128K, the Claude 3 series reached 200K, and Gemini 1.5 Pro broke through to 1 million Tokens. Although windows keep growing, enterprise projects easily involve thousands of files, hundreds of thousands of lines of code, hundreds of APIs, and dozens of tables—stuffing all of it into the model still won't fit the window.

The Second Wall: Token Costs Become Unsustainable

Even if the window were large enough, repeatedly feeding massive amounts of code to the model produces Token costs that enterprises find hard to sustain. Take GPT-4o as an example: input Tokens cost about $2.5 per million, and if a large project repeatedly submits hundreds of thousands of lines of code, the daily API bill can easily exceed thousands of dollars. This is why the industry continues to explore technologies like RAG (Retrieval-Augmented Generation) to reduce redundant Token consumption.

RAG (Retrieval-Augmented Generation) is the mainstream engineering solution for the context window limit and Token cost problems. Its core idea is "retrieve on demand rather than feed everything." The RAG technical pipeline typically includes: splitting knowledge-base documents into Chunks, converting them into vectors via an embedding model, and storing them in a vector database (such as Pinecone, Chroma, or Milvus); at inference time, the user query is likewise vectorized and, through approximate nearest neighbor (ANN) search, the most relevant Chunks are retrieved and injected into the large model's context. Under the subsequent Harness engineering framework, RAG can be viewed as a special kind of Skill—it modularizes the "precise context-retrieval capability," enabling the Agent to dynamically obtain relevant fragments from massive codebases or documents without exceeding window limits. This aligns closely with the Harness core philosophy of "giving the model only the information it truly needs."

It's worth noting that RAG's retrieval quality depends heavily on the Chunk-splitting strategy and the choice of embedding model. Fixed-size Chunking is simple to implement but may sever semantics; Semantic Chunking determines boundaries by detecting sudden changes in the cosine similarity of adjacent sentence embedding vectors, preserving more complete semantic units; while RAG targeting codebases usually adopts AST (Abstract Syntax Tree)-aware chunking, using functions or classes as the minimal granularity to avoid splitting the implementation code of the same function into different Chunks. These engineering details directly determine RAG's practical usability in engineering code-retrieval scenarios.

The Third Wall: Attention Decay (The Most Core Bottleneck)

This is the most fundamental problem. In 2023, Stanford University's paper "Lost in the Middle" was the first to systematically quantify this phenomenon: in multi-document question-answering tasks, when relevant information is located in the middle of the input sequence, model performance drops significantly, while performance is best when information is at the beginning or end—exhibiting a classic U-shaped curve.

Its technical root lies in the Transformer's self-attention mechanism—which establishes global dependencies by computing the relevance weights between each Token in the sequence and all other Tokens, with a computational complexity of O(n²), meaning doubling the sequence length quadruples the computation. When processing extremely long sequences, the positional bias effect intensifies, and the model's attention weight on middle Tokens gets diluted. The industry has developed two technical routes in response: one is improving attention computation efficiency (e.g., Flash Attention reduces memory complexity from O(n²) to O(n), making million-Token processing possible); the other is improving positional encoding (e.g., RoPE rotary positional encoding enhances long-range dependency capture through relative position representation, and has been widely adopted by LLaMA, DeepSeek, and others). Yet even so, current large models are fundamentally based on the Transformer architecture, and when the input file is too large, the model firmly remembers only the beginning and end content, while the middle portion is often forgotten. This "middle forgetting" phenomenon is fatal for engineering development that requires everything to be tightly interlinked, and it is precisely the fundamental reason why Harness engineering emphasizes precise context management rather than brute-force window expansion.

Understanding this bottleneck from another dimension: even if "the needle in the haystack" is theoretically within the window, whether the model can "find" that needle depends on the quality of attention allocation rather than the window size. This is highly similar to the capacity limit of human working memory—psychological research shows that the effective capacity of human working memory is about "7±2 chunks," and a larger window does not mean higher effective utilization. One essence of Harness engineering is precisely to reduce the dilution of attention by irrelevant information through structured constraints, ensuring that the model's "cognitive resources" are concentrated on the context that truly matters.

Development Is a Complete Process Chain

Taking user login as an example, traditional development is a coherent process: propose requirements → design validation approaches (email, phone number, password encryption algorithm) → develop the feature → run tests → find problems and continue fixing → submit. Each step is tightly interlinked. Neither prompts nor context engineering can stably support this kind of long-chain, high-complexity engineering task.

Harness Engineering: Taming the "Wild Horse" That Is the Large Model

It was precisely upon the bottlenecks of context engineering that Harness engineering was born.

The word "Harness" originally means "tack for a horse," extended to mean "to control, to utilize." In the AI context, this "horse" is the already-powerful large language model (such as Claude, which writes code extremely efficiently). Our goal is to use a series of constraints—prompts, guidance documents, Skills, MCP, and so on—to make the model, like a tamed horse, stably and reliably complete tasks on a predefined track.

Harness engineering did not appear out of thin air; it was gradually distilled from industry practice as AI Agent engineering practice matured. After 2023, as large models like GPT-4 and Claude 3 demonstrated capabilities in code generation surpassing junior engineers, the core contradiction in the engineering community shifted from "is the model smart enough" to "how to make the model work stably and controllably in a real engineering environment." As an engineering paradigm, Harness absorbed the DevOps idea of Infrastructure as Code, while also drawing on Constraint-Driven Design from software architecture, converting the uncertainty of AI systems into predictable engineering output through structured constraints.

The component system of Harness engineering can be understood at four levels: the constraint layer (AI behavior specification files such as CLAUDE.md and .cursorrules, which define the model's coding style, prohibited behaviors, and work boundaries within the project), the knowledge layer (Architecture Decision Records (ADR), API documentation, database Schema, providing the model with a structured cognitive foundation of the project), the capability layer (Skill/Tool definitions, MCP Servers, which encapsulate specific business capabilities into standard interfaces callable by the model), and the coordination layer (Agent orchestration logic, task decomposition strategies, controlling the execution flow and exception handling of multi-step tasks). These four layers together form the complete "tack" for taming the large model, and missing any one layer will cause the model to run out of control or become inefficient in real engineering scenarios.

Agent = Model + Harness: A Formula Worth Examining Deeply

The tutorial cites a widely circulated formula:

Agent = Model + Harness

In other words, a complete AI Agent, aside from the large model itself, includes everything else—whether prompts, guidance files, Skills, or MCP—all of which fall within the scope of Harness. Harness is the "reins and saddle" that control the model, making the model's potential truly match requirements and transforming it into real, tangible productivity.

Two key components deserve special mention:

MCP (Model Context Protocol) is a standardized protocol officially open-sourced by Anthropic in November 2024. Before MCP appeared, the ways different AI tools called external capabilities were highly fragmented: LangChain had its own Tool interface, AutoGen had another set of definitions, and OpenAI's Function Calling format differed from Anthropic's Tool Use format. By defining a standardized Server/Client architecture—analogous to the USB interface for the hardware ecosystem—MCP provides large models with a unified "tool-calling socket," enabling capabilities such as database queries, file read/write, and API calls to be standardized and encapsulated as Servers for the model to call—plug and play. This mirrors the logic of the World Wide Web unifying information access through the HTTP protocol: standardization itself is productivity. Currently the MCP ecosystem already covers hundreds of official and community Servers for database connections, browser automation, code execution sandboxes, cloud service APIs, and more.

From a protocol design perspective, MCP uses JSON-RPC 2.0 as its underlying communication format and supports two transport modes: stdio and HTTP+SSE. The former suits local inter-process communication (such as Cursor calling local tools), while the latter suits remote service deployment. The core capabilities of an MCP Server are abstracted into three primitives: Tools (functions the model can actively call), Resources (structured data sources the model can read), and Prompts (reusable prompt templates). This layered design allows MCP Server developers to finely control the model's capability boundaries, rather than exposing all permissions to the model at once—which deeply aligns with the Harness engineering core philosophy of "constraint is protection."

Skill, in mainstream Agent frameworks (such as LangChain, AutoGen, and Cursor), usually corresponds to Function Calling or Tool Definition, and is the core abstraction for modularizing specific business capabilities. The essence of Harness engineering is precisely to systematically orchestrate these scattered engineering components into reusable, maintainable AI infrastructure.

OpenAI's Codex Experiment: The Repository Is Everything

This concept is not mere fantasy. OpenAI Codex is a model based on the GPT series that was specifically fine-tuned for code tasks, released in 2021 and powering the early versions of GitHub Copilot. According to the tutorial, OpenAI once conducted an internal experiment with Codex, with a highly disruptive goal: humans do not hand-write a single line of code and are only responsible for the project's architectural design, while all specific coding is left entirely to the agent.

The experiment started from an empty Git repository, thereby giving rise to the most important iron rule of Harness engineering:

Repository is everything

This concept aligns closely with the "Single Source of Truth" (SSOT) principle in software engineering and shares the same lineage as the GitOps philosophy in the DevOps field. GitOps was proposed by Weaveworks in 2017, and its core principle is: the desired state of the system should be completely stored in the Git repository in a declarative way, and any change is triggered through Git operations rather than by directly manipulating the runtime system. Introducing this idea into AI Agent engineering produces a new set of engineering practices: Architecture Decision Records (ADR) document architectural decisions to avoid "knowledge silos"; AI configuration files such as CLAUDE.md and .cursor/rules version-manage the behavioral constraints on the model; and strict maintenance of the Changelog provides the Agent with temporal context of the project's evolution. From a cognitive-science perspective, the Git repository plays the role of the Agent's "externalized long-term memory," compensating for the large model's innate limitation of having no persistent state, while ensuring knowledge synchronization among human engineers and between humans and AI.

Understanding the engineering significance of "the repository is everything" further from an information-theory perspective: Git's version control mechanism not only preserves the current state of the code, but, in the form of commit history, also preserves the complete trajectory of the code's evolution. For an AI Agent, this means it can not only read "what is now," but also understand "why it was done this way" and "what it was like before" through operations like git log and git blame—this temporal context is crucial for understanding legacy code and avoiding reintroducing known bugs. This is why, in Harness engineering practice, well-formed commit messages, detailed PR descriptions, and promptly updated CHANGELOGs are not optional, but infrastructure for enabling the AI Agent to work effectively.

Why such strong emphasis? Because the large model can only read the content in the repository—it cannot read the ideas in your head, nor can it read documents you've written but not uploaded. The materials for complex projects are often scattered; some haven't been uploaded, and some still remain at the conceptual stage. Therefore, the core discipline of developing with Harness engineering is: any idea, any update, must be promptly deposited into the repository, otherwise, as far as the AI is concerned, it does not exist.

Conclusion: Engineering Is the Key to AI Implementation

From prompts to context engineering, and then to Harness engineering, this evolutionary path clearly reveals a trend: the bottleneck of AI implementation has long ceased to lie in model capability itself, but rather in how to harness the model through engineering means.

The model is that powerful wild horse, while the Harness is the tack that keeps it running on the correct track. For teams hoping to truly transform AI into productivity, understanding and building their own Harness engineering system—layered specifications, repository deposition, Skill and MCP coordination—will be the core competitiveness of the next stage.