From Prompt to Harness: Understanding the Four Leaps of AI Engineering (10,000-Word Long Read)

Recently, I've often been asked the same question: "AI technology is changing with each passing day. What on earth should I learn? Often, just as I've finally understood a concept, an even newer technology appears; before I can get comfortable with a new tool, an alternative with even more potential has already been released."

I think what truly matters is never chasing after a specific tool, but rather understanding the unchanging underlying logic behind technological evolution—what problem does it solve?

This is why I wrote this article, tracing the developmental path of Large Language Model (LLM) applications all the way from the most primitive prompt engineering to today's Harness engineering. The technology of each stage did not appear out of thin air; they were all invented under specific conditions to conquer the most core pain points of that time.

To put it in Buddhist terms, all coincidences are inevitable results of cause and effect. We think of them as coincidences only because we haven't comprehended the underlying causes and have only seen the effects. What this article aims to do is precisely to find the causes behind these effects.

If we look at it through the framework of "Dao (Way), Fa (Method), Shu (Skill), Qi (Tool)", these technologies all belong to the levels of Fa (methods) and Shu (techniques). In the long river of LLM evolution, they are not fleeting phenomena, but have settled into reusable and inheritable engineering methods. In my view, the true Dao is the underlying cognitive understanding, while the accumulation at the Fa and Shu levels is precisely the confidence to handle ever-changing situations with constancy when facing future changes, because they will not be easily replaced.

I divide the development of LLM applications into four stages. There are no clear boundaries between their sequence, and many stages overlap in time:

• Phase 1: Prompt Engineering—Learning to converse with AI.

• Phase 2: Tool Calling—Giving AI hands and feet.

• Phase 3: Context Engineering—Enabling AI to remember.

• Phase 4: Harness Engineering—Taking AI from fighting alone to legion warfare.

I hope this article can help you see the full picture and direction of LLM application development, easing your inner anxiety.

Phase 1: Prompt Engineering

Before the emergence of LLMs, we relied mainly on explicit rules and code to get computers to complete tasks. For example, if the other party said "Sky thunder ignites ground fire" (Tian Lei Gou Di Huo), the program would reply "The pagoda subdues the river monster" (Bao Ta Zhen He Yao). LLMs have brought a new way of interaction: controlling model behavior through natural language. We no longer write rigid rules, but instead use a block of text to tell the model: who you are, what to do, what to base it on, and what format to output in.

This block of text is the prompt. Centered around "how to write prompts so that the model can understand and execute tasks more stably," prompt engineering gradually took shape.

The free course ChatGPT Prompt Engineering for Developers co-launched by Andrew Ng and OpenAI.

How should I say it so it won't misunderstand?

Early LLM applications were mainly for chatting. The user asked a question, and the model answered. Prompt engineering is about turning vague requirements into clear instructions so that the model's output better aligns with expectations.

The 5W2H framework, which we most commonly use when writing articles, is also applicable to prompts:

Dimension

Prompt Structure

Meaning

At this point, the prompt is essentially no longer just a question, but a simplified version of a task specification.

Giving examples is better than explaining theory

A thousand explanations aren't as good as a single real example. The same goes for LLMs; giving them a few examples makes them more obedient. In 2020, Tom Brown et al. from OpenAI showed in their paper Language Models are Few-Shot Learners that by simply providing a few examples in the prompt, the LLM's intelligence level can be boosted to a whole new tier.

1. Zero-shot: Directly describe the task goal through natural language instructions without providing any examples.

2. One-shot: Provide one example for the model to mimic and reference when generating results.

3. Few-shot: Provide multiple examples to guide the model to generalize patterns from them.

Complex tasks require reasoning frameworks

Early tasks were like traveling from Changsha to Beijing—a direct flight would get you there. Later, tasks became more complex: traveling from Changsha to Huangcaodian Village in Changli County. You have to fly from Changsha to Beijing first, then take a high-speed train to Changli County, then a long-distance bus to Xinji Town, and finally a three-wheeled motorcycle at the entrance of the village. Without planning the route in advance, the journey is bound to be a disaster. The same goes for LLMs doing complex tasks. Thus, reasoning frameworks emerged, guiding the model to break down steps before giving the answer.

CoT (Chain-of-Thought):

In 2022, Jason Wei et al. proposed in their paper Chain-of-Thought Prompting Elicits Reasoning in Large Language Models that providing the model with examples that include intermediate reasoning steps can significantly improve LLMs' performance on complex tasks such as arithmetic, common sense, and symbolic reasoning. Chain-of-thought is like a line of dominoes; instead of jumping straight to the result, it guides the model to generate intermediate reasoning steps.

ToT (Tree of Thoughts)

But many real-world problems cannot be solved by a single path. They require comparing multiple options, weighing costs, evaluating scenarios, and even turning back if the direction is found to be wrong. Like a Didi (ride-hailing) driver choosing a route, it generates multiple candidate routes and then evaluates which route is more reliable. This method is called Tree of Thoughts (ToT), proposed by Shunyu Yao et al. in 2023 in their paper Tree of Thoughts: Deliberate Problem Solving with Large Language Models.

From 5W2H to Few-shot, and then to CoT and ToT, prompt engineering has evolved from getting the message across clearly, to providing standard reference answers, to teaching reasoning methods. But regardless of the technique, they all optimize the model's input to trigger better output. The next breakthrough, however, lies not on the input side, but on the model's capability side.

For example, questions like "How is the weather in Beijing today? What does the original text of this paper say?" cannot be answered purely by the knowledge the LLM has mastered. It needs external tools, such as searching the internet for the paper or calling a weather query API. This marks the boundary where prompt engineering has reached its limit; it is good at teaching the model how to think, but not at interacting with the real world. Next, what AI needs is no longer more complex prompts, but hands and feet.

Phase 2: Tool Calling

LLMs know everything from astronomy to geography. However, when asked "Help me book a flight ticket," the LLM can give a detailed text copy of the operations but cannot actually place the order.

At this point, the shortcomings of LLMs significantly hinder the journey from AI to AGI:

First, the boundary of knowledge.

The model's knowledge comes from training data, which is only up-to-date up to the time of training. Therefore, it knows nothing about events after the model's release. How does the model give correct answers when we ask about today's news? That is done via tools, specifically web search tools.

Second, the boundary of capability.

The model can "explain the calculation process," but when it comes to reliably balancing accounts, querying databases, sending emails, or modifying files, we still have to rely on programs. Some things are simply beyond the LLM's capabilities.

Third, the boundary of action.

As for what can and cannot be done, natural language answers are just suggestions; tool calling is what turns them into actions.

Function Calling

In June 2023, OpenAI released function calling. According to the official statement, developers can describe functions to the LLM, and the model will choose whether to call them and output JSON parameters that match the function description. OpenAI also explicitly mentioned at the time that this is a more reliable way to connect GPT's capabilities to external tools and APIs. Function Calling gave LLMs hands and feet for the first time. Even though we have to install these hands and feet ourselves and label them, the model decides on its own whether to use a particular hand or foot under specific circumstances.

MCP

Although Function Calling solved the problem of invoking functions, if the tools being called are GitHub, Slack, databases, file systems, browsers, or internal company systems, you need to write a calling API for each type of LLM. Every tool has to have a calling API written for different platforms, and every company ends up reinventing the wheel to build connectors. Tool descriptions, permissions, and return formats are all inconsistent. It is just like having one type of plug for the refrigerator, another for the TV, and yet another for the air conditioner—and if you switch brands, the plug is different again. You can imagine the room becoming a chaotic battlefield of sockets.

Anthropic officially released MCP in November 2024 to solve the problem of inconsistent tool invocation formats. MCP, which stands for Model Context Protocol, is an open protocol used to connect LLMs with external tools, data sources, and application systems. It aims to provide a standardized way for AI models to obtain context information and perform physical operations, and can be understood as the USB of AI applications.

The operation of MCP is based on a client-server architecture:

• Client: The AI application (such as Claude, Cursor, IDE, or Agent system) acts as the MCP Client, which is the party initiating the request;

• Server: The MCP Server exposes available external tools or data resources to the client. The Server tells the Client: what tools, resources, and prompt templates are available here.

After receiving a user task, the client determines which tool to call or which resource to read, and then sends the request to the server according to the MCP protocol. The server performs operations such as queries, reading files, or calling APIs, returns the results to the client, and the client then puts them back into the model context to continue reasoning.

Therefore, the greatest value of MCP is providing a unified and standardized protocol for communication between the model and the external world.

Skill

What pain point does it solve?

Through MCP, AI can connect to tools like GitHub, databases, and mail systems to perform single tasks. However, it still gets lost when facing complex tasks, such as executing reimbursement processes according to company regulations, auditing invoice compliance, or inspecting product quality. For example, it can check or run code, but it doesn't know your Code Review standards; it can read invoices, but it doesn't know the invoice compliance standards. Although the AI has hands and feet, it doesn't know how to work according to the rules.

What is a Skill?

A Skill packages the source files, standards/specifications, tool workflows, etc., needed to complete a task into a resource bundle and puts them in a folder (the core file is called SKILL.md). This is a Skill.

Compared with prompts or MCP, a Skill can solidify tasks so you don't have to write a mountain of text like prompts every time. Skills can execute complex tasks, and tools can invoke each other—whether they are MCP tools, APIs, or plugins.

Path of Genesis

Early Exploration: The prototype was OpenAI's Plugins launched in early 2023. Later, IDEs like Cursor placed AGENTS.md files in the project root directory for the AI to read project guidelines. This was the predecessor of Skills.

Official Release: Anthropic officially launched the Skill standardization scheme in October 2025. Subsequently, mainstream AI programming tools like Cursor and Windsurf followed suit with support.

Core Design

A standard Skill is a collection of files organized in an independent directory, with the following structure:

The roles of each directory:

Skills use a three-stage information loading mechanism. By default, only the first-tier information permanently resides in the AI's context:

1. First tier (Index layer)
   The name and description of all Skills reside permanently in the AI's system prompts. The cost of this layer is extremely low, taking up only about 100 Tokens per entry, equivalent to giving the AI a skills directory so it knows what capabilities are available.

2. Second tier (Activation layer)
   When the AI determines that a user task matches the description of a certain Skill, the system loads the complete SKILL.md file of that Skill into the context window. This file contains the complete instructions, workflows, and key rules for completing the task.

3. Third tier (Execution layer)

In the specific execution process, the Skill loads reference documents under references/ as needed, or executes scripts under scripts/. This lazy-loading strategy reduces the execution time of complex skills by about 40%.

This solves the problems of Token efficiency and focus of attention, avoiding stuffing all knowledge into the model at once.

Summary in one sentence:

If MCP solves the connection problem of what tools the AI can use, then Skill solves how the AI completes complex tasks according to standards and workflows with the help of those tools. MCP equips the AI with hands and feet, while Skill gives the AI a set of standard operating procedures—telling it what to do first, what to do next, what standards to follow, and what materials to reference.

Phase 3: Context Engineering

If tool calling is equipping the AI with hands and feet, then context engineering is equipping the AI with a memory system.

For example:

User: 1+1=?
Model: 2
User: What about plus 1?
Model: Please provide more context. Plus 1 on top of what?

The model forgot the previous conversation—this phenomenon is called context rot. This is precisely the problem that context engineering aims to solve: how to keep the AI always focused on key information in complex, multi-turn, multi-tool interactions, without losing, messing up, or drifting from the target.

Prompt engineering lets us speak clearly, but in complex scenarios involving multi-turn dialogue and multi-tool invocation, the AI faces a constantly expanding flow of information. Early key information will be diluted by subsequent interactions, and the user's intent will gradually drift during continuous questioning. The goal of context engineering is to maintain the strength of key signals and the sense of direction of intent within a dynamic, ever-growing information stream. In a single phrase: stay clear-targeted and unwavering.

Memory Management

Remember what should be remembered, forget what should be forgotten.

Short-term Memory

Short-term memory includes the complete content of the current turn of conversation (user question + model answer), as well as key information extracted from the last few turns of dialogue. When the conversation exceeds a threshold (e.g., Token usage >80%), the LLM is called to generate a historical summary, replacing the lengthy original logs with a summary of a few hundred words. For example, Claude Code automatically triggers a summary compression mechanism when context utilization exceeds 95%.

Long-term Memory

Long-term memory includes your persona, personality, preferences, operating system, etc., as well as information the user actively asks to remember. This information will not easily change in the short term.

Information Isolation

User A: Help me write an apology email to a customer, our product delivery is delayed.
User B: Help me summarize last week's sales data.

If the two conversations above are conducted at the same time, the model might mix the apology email into the sales data summary—getting wires crossed.

Information isolation physically or logically segregates different sessions. The short-term memory, long-term memory, and extracted key information of session A are stored completely separate from those of session B, making them mutually invisible.

Summary in one sentence

Short-term memory ensures that the current conversation does not lose memory; long-term memory ensures that things are still remembered after the window is closed; information isolation ensures that multiple tasks don't get tangled up. Together, these three form the complete blueprint of memory management in context engineering.

Memory management solves how internal information is stored, while external knowledge bases solve how external information is retrieved.

External Knowledge Injection

User: Help me look up the company's latest reimbursement policy. What is the business trip accommodation allowance?
Model (without external knowledge): According to my knowledge base, the business trip accommodation standard for most enterprises is around 300-500 RMB per night. Please refer to your company's actual policy for details.

This is not a hallucination, nor is it a capability issue of the model; it's simply that the model has never learned the company's reimbursement policies.

If we compare an LLM to an examinee, even though they are well-read, they cannot memorize all the knowledge in the world—such as internal company regulations. RAG equips this examinee with a set of reference books that can be consulted at any time. When encountering an unmemorized knowledge point in the exam, they can flip through the books directly and then answer.

RAG combines external knowledge bases with LLMs, retaining the model's reasoning capabilities while compensating for defects such as insufficient or outdated training data through external knowledge.

Since Meta proposed the concept of RAG in 2020 in the paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, it has undergone a three-stage evolution:

To briefly summarize these three stages: Naive RAG is flipping through a book by keywords and stopping wherever it lands; Advanced RAG is checking the catalog and index first, then precisely flipping to the corresponding page; Agentic RAG is having a librarian provide full service—first understanding what you want, then finding the books you need, and if the search was off, picking another book and trying again until you are satisfied.

Context Compression

In February 2026, Summer Yue, Director of AI Alignment and Safety at Meta's Superintelligence Lab, experienced an email-clearing nightmare. She connected OpenClaw to her work email and explicitly issued the instruction: "Check the inbox, suggest emails that can be archived or deleted, but do not perform any actions until I explicitly authorize." A massive volume of emails flooded the context window, triggering the system's context compression mechanism. The compression mechanism forgot the instruction "do not perform any actions." Lost of constraints, the AI began bulk-deleting emails at lightning speed. What made it even more agonizing was that the AI ignored Yue's stop commands: "Do not do that." "Stop don't do anything!" "STOP OPENCLAW!!!". Reflecting on it afterward, the AI said: "Yes, I remember you said not to delete them, and I violated that. You have every right to be angry."

The root cause of this accident was not that the AI was disobedient, but that context compression compressed away the most important instruction. This is the cost of compression.

Not all information can be compressed. A good compression mechanism needs to be able to retain instructions that must absolutely not be compressed—that is, pinning key instructions.

To prevent such accidents, the industry has developed three mainstream compression mechanisms, which differ in implementation principles and applicable scenarios:

The key to context compression is enabling the agent to still know where it left off and what to do next after compression, much like a TV drama where the plot can still connect after we've stepped away for a while.

Phase 4: Harness Engineering

What is Harness Engineering?

Up to this point, the LLM has already got a smart brain, knows how to think, acts, and can remember, but its performance in completing complex tasks remains hit-or-miss.

The Book of Changes (I Ching) states, "That which is above form is called the Dao; that which is below form is called the Qi (vessel/tool)." If the LLM is the Dao, then the Harness is the Qi (tools, workflows, standards). Having the Dao without the Qi means the Dao has nothing to cling to and can only run in place; although it can run, it does not become a useful vessel (cannot produce a usable end product).

Vivek Trivedi of LangChain explicitly proposed the concept of Harness engineering, defining it with a formula:

Agent = Model + Harness

A truly usable AI agent consists of two parts: the Model (the brain) and the Harness (prompts, tools, context, sandbox, feedback loop, recovery paths). All this engineering scaffolding built around the model collectively constitutes the agent.

If we use an operating system metaphor, the LLM is equivalent to the CPU, while memory, disks, I/O, sound cards, and graphics cards all belong to the Harness. A computer's performance does not depend entirely on the CPU; likewise, an Agent does not depend entirely on the LLM. Trivedi's team once conducted an experiment: when running the same model in Claude Code's default Harness, the Terminal Bench 2.0 score was about 52.8. After optimizing the Harness, the same model scored 66.5, leaping directly from the Top 30 to the Top 5.

Clearly, the gap between models is narrowing, while the gap between Harnesses is widening. Future technological barriers will lie not in the models themselves, but in Harness engineering capabilities.

Core Capabilities of Harness

A complete Harness engineering suite is usually not a single-point feature, but a whole set of engineering systems running around the model. After a user hands a complex goal over to the AI, the Harness is responsible for deciding who breaks down the task, who calls the tools, who manages the memory, who ensures safety, who judges whether the results are good, and who actually delivers the results to the production environment. By coordinating these links in an orderly manner, the model is no longer fighting a lone battle in a chat box, but fighting cooperatively within a controllable process.

1. Prompt and Task Orchestration System.
   Complex tasks must first be broken down into multiple steps: first comprehending the goal, then formulating a plan, then selecting tools, and finally executing and verifying. This part is responsible for prompt template management, task deconstruction, and multi-step execution chain design, turning a single problem into an executable workflow.

2. Tool Calling System.
   The model itself is responsible for comprehension and judgment, but actually querying GitHub, running Shell scripts, querying SQL, calling AWS, or updating Jira requires external tools. The system needs to expose these tools to the model in a fixed format and call them at the appropriate time.

3. Context Management System.
   The context management system is responsible for short-term memory, long-term memory, context compression, information priority sorting, and multi-turn task state preservation. It lets the AI know which step it has completed, what to do next, and which rules must absolutely not be dropped.

4. Execution Sandbox System.
   Once the AI is capable of operating, risks also emerge. It might accidentally delete files, execute dangerous commands, or access resources it shouldn't. Therefore, it needs to be confined to a secure "dark room" (sandbox) for execution, limiting the AI's actions within safety boundaries: what it can read, what it can write, whether it can connect to the internet, and whether it can execute code must all be subject to permission control and isolated environments. Its essence is providing a safe operating space for the AI.

5. Feedback and Evaluation System.
   Complex tasks are rarely passed on the first try. Generated code needs to run tests, written documents need formatting checks, and execution flows need success verification. The feedback and evaluation system is responsible for scoring results, retrying failures, auto-correcting, and evaluating quality. This module represents the AI's review and iteration.

6. Release and Engineering Pipeline System.

For real business, AI writing code or generating proposals does not mean the end of the task. After that, there are builds, tests, approvals, releases, monitoring, and rollbacks. The Delivery Pipeline is responsible for connecting the results produced by the AI into engineering pipelines such as CI/CD, Jira approvals, and canary releases, allowing the AI's output to truly go live.

What is the difference between Harness and Vibe Coding?

What is the fundamental difference from Copilot?

Copilot is responsible for helping us rapidly develop code; Harness is responsible for delivering high-quality products—namely all the links after code generation, such as build, test, deployment, security, and optimization, solving the real bottleneck of software delivery. Simply put, Copilot accelerates code creation, while Harness ensures code reaches the production environment safely and quickly.

What core problem does it solve?

It is committed to ending the tedious manual labor of developers, security vulnerabilities caused by fragmented toolchains, uncontrollable cloud costs, deployment bottlenecks, and manual troubleshooting of production failures.

Will it replace my team and tools?

No. Harness aims to enhance the existing ecosystem rather than replace it. It can integrate with more than 300 tools (such as GitHub, Jenkins, AWS) and empower team members by automating repetitive tasks, predicting failures, and providing intelligent suggestions, allowing them to focus on higher-value creative work.

Looking at it this way, Harness engineering doesn't seem to be a brand-new technology, but rather organizes existing capabilities like prompts, tools, contexts, sandboxes, and feedback into a complete system. Prompts solve how to say, tools solve how to do, contexts solve how to remember, sandboxes solve how to do safely, feedback solves how to do better and better, and release pipelines solve how to truly deliver. Together, these six things form the watershed of an Agent heading into production.

Final Thoughts

Looking back at these four stages, it is not difficult to see that the capability line of AI applications is shifting from conversation to action, and then from action to systems. At the beginning, we cared about whether the model was smart; later, we cared about whether it could use tools; even later, we discovered that just knowing how to use tools wasn't enough—it also had to remember, reflect, and correct errors. The evolution of technology is essentially about continuously completing the various capabilities of AI, letting its eyes, ears, nose, tongue, body, and mind grow out one by one.

The root cause of our anxiety is that the unit of evaluation has shifted from the individual to the organization. When engineering teams like Harness begin to be reconstructed by AI, our worry is no longer the disappearance of jobs, but rather the generational dimension-reduction strike on collaboration models. Future scarce capabilities will inevitably shift from prompt engineering to workflow design—the capacity to design human-machine collaborative system architectures.

Thus, the ultimate question emerges: when AI is deeply embedded in processes, becoming an execution node, a collaborative partner, and even a decision-making consultant, how should we reconstruct the power structure and operating interfaces of organizations? This is no longer a simple tool iteration, but a shift in management paradigms. The real answer sheet for the next wave of AI will be written by those who dare to redefine work itself.

References:

1. Andrew Ng's "ChatGPT Prompt Engineering for Developers" Course: https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/

2. GPT-3 Paper Language Models are Few-Shot Learners: https://arxiv.org/abs/2005.14165
   Chain-of-Thought Paper: https://arxiv.org/abs/2201.11903
   Tree of Thoughts Paper: https://arxiv.org/abs/2305.10601

3. OpenAI Prompt Best Practices: https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
   ReAct Paper: https://arxiv.org/abs/2210.03629

4. Tencent Cloud MCP Introduction: https://cloud.tencent.com/developer/article/2665432; Anthropic MCP Announcement: https://www.anthropic.com/news/model-context-protocol; MCP

5. MCP Official Documentation: https://modelcontextprotocol.io/docs/getting-started/intro

6. RAG Concept Proposal Paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: https://arxiv.org/abs/2005.11401

7. Anthropic Skill Official Documentation: https://docs.anthropic.com/en/docs/agents-and-tools/skills

8. OpenAI Function Calling Release Announcement: https://openai.com/index/function-calling-and-other-api-updates/

9. Harness Engineering Review From Prompt Engineering to Harness Engineering: A Survey of Agent Infrastructure: https://hub-assets-cache.baai.ac.cn/view/55145

10. LangChain's Practice and Definition of Harness Engineering: https://hub-assets-cache.baai.ac.cn/view/55145