From Prompt to Harness: Understanding the Four Leaps of AI Engineering in One Article

Recently, I've often been asked the same question: "AI technology is changing so rapidly, what on earth should I learn? Often, just as I understand one concept, a newer technology emerges; before I even get comfortable with a new tool, a replacement with more potential has already been released."

I think what truly matters has never been chasing a specific tool, but rather understanding the unchanging underlying logic behind technological evolution—what problem was solved.

This is the reason why I wrote this article, following the developmental thread 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.

In Buddhist terms, all coincidences are inevitable results of cause and effect. The only reason we perceive them as coincidences is that we haven't grasped the causes behind them and only see the effects. What this article aims to do is precisely to find the causes behind these effects.

If viewed through the framework of "Dao, Fa, Shu, Qi" (Principles, Methods, Techniques, Tools), these technologies belong to the levels of Fa (methods) and Shu (techniques). In the long river of LLM evolution, they are not fleeting flashes in the pan, but have settled into reusable, inheritable engineering methods. In my view, the true Dao is the underlying cognitive understanding, and the accumulation at the levels of Fa and Shu is precisely the confidence to respond to future changes with constancy, because they will not be easily replaced.

I divide the development of LLM applications into four stages, which do not have clear boundaries between them, and many stages overlap in time:

• Stage One: Prompt Engineering—learning to talk to AI.

• Stage Two: Tool Calling—giving AI hands and feet.

• Stage Three: Context Engineering—allowing AI to remember.

• Stage Four: Harness Engineering—taking AI from a lone soldier to army-scale combat.

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

image

Stage One: Prompt Engineering

Before the emergence of LLMs, we made computers complete tasks mainly by relying on explicit rules and code. For example, if the other party said "heavenly thunder shakes the earthly fire," the program would reply with "pagoda suppresses the river demon." LLMs 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 you need to do, what to base it on, and what format to output.

This block of text is the prompt. Prompt Engineering gradually formed around "how to write prompts so that the model can understand and execute tasks more stably."

image

Andrew Ng and OpenAI jointly launched the free course ChatGPT Prompt Engineering for Developers (https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/)

image

image

image

image

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

Early LLM applications were mainly chat-based. The user asked a question, and the model answered. Prompt engineering is about turning vague requirements into clear instructions, making the model's output more aligned with expectations.

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

Dimension

Prompt Structure

Meaning

Example

Who

System Prompt

Defines role, persona, speaking style

You are my financial advisor

What

Instructions

Specifies what needs to be done

Help me figure out a way to save more money each month

Why

Goal

Controls direction, avoids going off-track

Savings greater than 100,000 RMB

Where

Context

Explains the specific situation

Working in a first-tier city, the salary looks decent, but it's spent quite quickly

When

Constraints

Restricts time/conditions

Starting from this month

How

Method

How to execute specifically

Sort through expenses first, and cut out the unnecessary ones

How much

Evaluation

Requirements for format and accuracy

Able to save 1/3 of the salary every month

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

Giving examples is better than just explaining rules

Talk is cheap—it's better to show a concrete example, and the same goes for LLMs; give them some examples, and they will be more obedient. In 2020, Tom Brown et al. from OpenAI showed in their paper Language Models are Few-Shot Learners that simply by providing a few examples in the prompt, the LLM's smarts could be bumped up a level.

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

2. One-shot: Provide a single example to let the model mimic the reference example to generate results.

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

Complex tasks require reasoning frameworks

Early tasks were like traveling from Changsha to Beijing—a direct flight gets you there. Later, tasks became complex: from Changsha to Huangcaodian Village in Changli County, you first have to fly from Changsha to Beijing, then take a high-speed train to Changli County, then take a long-distance bus to Xinji Town, and finally take a village-entrance tricycle. If you don't plan the route in advance, you'll easily end up in a mess along the way. It's the same when LLMs handle complex tasks. Thus, reasoning frameworks emerged, which guide 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 models with examples containing intermediate reasoning steps can significantly improve LLMs' performance on complex tasks such as arithmetic, common sense, and symbolic reasoning. Chain-of-thought is like dominoes; it does not directly yield the result, but instead 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 solutions, weighing costs, assessing scenarios, and even turning back if the direction is found to be wrong midway. Just like a Didi driver choosing routes, it involves generating multiple candidate paths and then evaluating which one is more reliable. This method is called Tree of Thoughts (ToT), proposed by Shunyu Yao et al. in 2023 in the paper Tree of Thoughts: Deliberate Problem Solving with Large Language Models.

From 5W2H to Few-shot, then to CoT and ToT, prompt engineering has evolved from getting the message across clearly, to giving standard answer references, to teaching reasoning methods. Yet regardless of the technique, all are optimizing the model's inputs to stimulate better outputs through better inputs. The next breakthrough, however, lies not on the input side, but on the model's capability side.

For example, "How is the weather in Beijing today? What does the original text of this paper say?" These questions cannot be answered solely based on the knowledge possessed by the LLM. It needs to search the internet for the paper, call a weather query API, and use other external tools. This marks that the boundary of prompt engineering has topped out; it is good at teaching the model how to think, but not good at interacting with the real world. Next, what AI needs is no longer more complex prompts, but hands and feet.

Stage Two: Tool Calling

LLMs know everything from astronomy to geography, yet when asked to "help me book a flight ticket," the model can only give a detailed text guide but cannot actually place the order.

At this point, the shortcomings of LLMs greatly hinder the progress from AI to AGI:

First, knowledge boundaries.

The model's knowledge comes from its training data, which is only as up-to-date as the time of the model's training. Therefore, it knows nothing about events after the model's release. So, when we ask the model about today's news, how does it provide the correct answer? Through tools, specifically internet search tools.

Second, capability boundaries.

The model can "explain calculation processes," but when it actually comes to reliably calculating accounts, querying databases, sending emails, or modifying files, we still must rely on programs. Some things are simply beyond the model's reach.

Third, operational boundaries.

What can and cannot be done—natural language answers are merely suggestions, and only tool calling can turn 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 arguments matching the function description. OpenAI also explicitly mentioned back then that this was a more reliable way to connect GPT capabilities to external tools and APIs. Function Calling gave LLMs hands and feet for the first time, though these hands and feet need to be installed by us and labeled, leaving it to the model itself to decide whether to use this hand or that foot under what circumstances.

MCP

Although Function Calling solved the function execution problem, if the tools to be called are GitHub, Slack, databases, file systems, browsers, or internal company systems, one needs to write a calling API for every single LLM, and every tool needs a calling API written for different platforms. Every company is reinventing the connector wheel, with inconsistent tool descriptions, permissions, and return formats. It's 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 plugs change again. You can imagine how the room would become a chaotic jungle of sockets.

Anthropic officially released MCP in November 2024 to solve the problem of inconsistent tool calling formats. MCP, which stands for Model Context Protocol, is an open protocol for connecting large language models with external tools, data sources, and application systems. It aims to provide AI models with a standardized way to obtain context information and execute actual actions, and can be understood as the USB of AI applications.

image

MCP operates based on a client-server architecture:

• Client: AI applications (such as Claude, Cursor, IDEs, or Agent systems) act 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: here are the tools, resources, and prompt templates I have.

After receiving a user task, the client determines which tool to call or which resource to read, then sends the request to the server according to the MCP protocol. The server executes operations such as queries, reading files, or calling APIs, returns the results to the client, and then the client puts them back into the model's 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 execute single tasks, but it is still at a loss when facing complex tasks, such as executing reimbursement processes according to company regulations, auditing invoice compliance, or checking product quality. For example, it can inspect or execute code, but doesn't know your Code Review standards; it can read invoices, but doesn't know the invoice compliance criteria. Even though AI has hands and feet, it does not know how to work by the rules.

What is a Skill?

A Skill packages the raw files, standards, specifications, and tool workflows required to complete a task into a resource bundle placed in a single folder (the core file is called SKILL.md). This is a Skill.

image

Compared with prompts or MCP, a Skill can solidify a task so you don't have to write a pile of instructions every time like with prompts. A Skill can execute complex tasks, and the tool-to-tool invocations can be MCP tools, APIs, or plugins.

The Path of Conception

Early Exploration: The prototype was Plugins launched by OpenAI in early 2023. Later, IDEs like Cursor placed AGENTS.md files in the project root directory to show project specifications to the AI, which was the predecessor of Skills.

Official Release: Anthropic officially launched the standardized Skill solution in October 2025, and subsequently, mainstream AI programming tools like Cursor and Windsurf followed suit to support it.

Core Design

A standard Skill is a collection of files organized in an independent directory structure, as follows:

image

The role of each directory:

Directory/File

Required

Role

SKILL.md

✅

Core file, composed of YAML metadata and Markdown body text. The name and description in the metadata are used for the AI to discover the skill, and the body contains the complete operational workflow, quality standards, decision rules, etc.

scripts/

❌

Stores executable code, used in scenarios requiring complex logical processing. SKILL.md is responsible for passing parameters to the scripts and getting output results.

references/

❌

Stores in-depth reference documents (such as API specifications, company policies, compliance standards), which are loaded only when detailed information needs to be consulted during execution, preventing SKILL.md from becoming bloated.

assets/

❌

Stores static assets, such as configuration templates, diagrams, and sample files, for scripts to reference or use as output templates.

Skills adopt a three-tier information loading mechanism; by default, only the first-tier information resides permanently in the AI context:

1. First Tier (Index Layer)
   The name and description of all Skills permanently reside in the AI's system prompt. This layer is extremely low cost, with each entry taking up only about 100 Tokens, which acts like a skill directory for the AI, letting it know what capabilities are available.

2. Second Tier (Activation Layer)
   When the AI determines that the user's 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 to finish the task.

3. Third Tier (Execution Layer)

During actual execution, the Skill loads reference documents under references/ on demand, or executes scripts under scripts/. This lazy-loading strategy reduces the execution time of complex skills by about 40%.

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

In summary:

If MCP solves the connection issue of which tools AI can use, then Skill solves how AI, with the aid of tools, completes complex tasks according to specifications and workflows. MCP equips the AI with hands and feet, whereas Skill gives the AI a standard operating manual—telling it what to do first, what to do next, what standards to follow, and what materials to reference.

Stage Three: 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:

image

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

image

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 make the AI always grasp key information in multi-turn, multi-tool complex interactions without losing it, getting confused, or drifting.

Prompt engineering lets us make things clear, but in complex scenarios of multi-turn dialogues and multi-tool calling, the AI faces an ever-expanding stream of information. Early key information gets diluted by subsequent interactions, and the user's intent gradually drifts during continuous questioning. The purpose of context engineering is to maintain the strength of key signals and the sense of intent direction within a dynamic, constantly growing stream of information. In one sentence: clear goals, unwavering focus.

Memory Management

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

Short-term Memory

Short-term memory includes the complete content of the current turn of conversation (user's question + model's answer), as well as key information extracted from the last few turns of conversation. When the conversation exceeds a threshold (such as Token occupancy > 80%), it will call the LLM to generate a historical summary, replacing lengthy raw records with a few hundred words of summary. 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 explicitly asks to remember. This information will not easily change in the short term.

Information Isolation

image

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

image

If the two conversations above happen simultaneously, the model might mix the apology email into the sales data summary, causing a cross-talk/scramble.

Information isolation means physically or logically isolating different sessions. The short-term memory, long-term memory, and extracted key information of Session A are stored completely separately from those of Session B and are mutually invisible.

In Summary

Short-term memory ensures no amnesia during the current conversation; long-term memory ensures it still remembers even after the dialogue window is closed; information isolation ensures no confusion among multiple tasks. Together, these three constitute the complete landscape 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

image

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

image

This is neither a hallucination nor a problem with the model's capabilities; it is simply that the model has indeed never learned the company's reimbursement policy.

If we compare an LLM to an examinee, although they are highly educated, they cannot memorize all the world's knowledge, such as internal company regulations. RAG equips this examinee with a set of reference books that can be flipped through at any time. When encountering unmemorized knowledge points in the exam room, they can directly look them up in the book and answer after searching.

image

RAG combines external knowledge bases with LLMs, preserving the model's reasoning capabilities while compensating for deficiencies in its training data, such as lack of information or obsolescence, 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:

Stage

Core Features

Limitations

Naive RAG

Basic architecture: indexing -> retrieval -> generation, simple and direct

Low retrieval precision, easily retrieves irrelevant documents, unstable generation quality

Advanced RAG

Introduces query rewriting, reranking (Rerank), dynamic chunking, and other optimization steps

Still relies on single-turn retrieval, unable to handle multi-step reasoning questions like "What was my company's net profit last year, and what about the year before?" which require querying last year's annual report by company name and then making comparisons.

Agentic RAG

Introduces agents to autonomously plan retrieval paths, supporting multi-turn reflection and iteration

Highest system complexity, slower response speeds

To briefly summarize these three stages: Naive RAG is flipping through books by keywords, settling wherever you land; Advanced RAG is checking the table of contents and index first, and then accurately turning to the corresponding page; Agentic RAG is full-service assistance by a librarian, who first understands what you want, then finds the books you need, and if they are wrong, switches to another book and searches again until you are satisfied.

Context Compression

In February 2026, Summer Yue, Director of AI Alignment and Safety at Meta's Superintelligence Lab, experienced a mailbox-clearing nightmare. She connected OpenClaw to her work email and clearly instructed: "Check the inbox, suggest emails that can be archived or deleted, and do not perform any actions until I explicitly authorize them." A flood of emails bloated the context window, triggering the system's context compression mechanism. The compression mechanism forgot the instruction not to execute actions. Losing its constraint, the AI began bulk-deleting emails at lightning speed. Even more devastatingly, the AI ignored Yue's stop commands: "Do not do that." "Stop don't do anything!" "STOP OPENCLAW!!!". The AI reflected afterward: "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 incident was not that the AI was disobedient, but rather that the context compression compressed away the most important instruction. This is the price of compression.

Not all information can be compressed; a good compression mechanism needs to be able to retain instructions that absolutely cannot be compressed, i.e., keeping key instructions pinned.

image

To prevent such incidents, the industry has developed three mainstream compression mechanisms, each differing in implementation principles and applicable scenarios:

Compression Method

Principle

Typical Representative

Risks

Dialogue Summary Compression

Uses an LLM to compress lengthy history into a brief summary when thresholds are exceeded

Claude Code's 95% threshold automatic compression, Koog agent's HistoryCompression

Summaries may omit key information, such as Yue's "wait for authorization" instruction

Semantic Compression

Uses small models to "refine" long text, retaining key information

Microsoft's LLMLingua, Selective Context

May over-filter, losing implicit context

KV Cache Optimization

Caches computed attention key-value pairs to avoid repeated calculations

vLLM, FlashAttention

Certain instructions in multi-instruction tasks may be marginalized

The key to context compression is allowing the agent to still know where it left off and what to do next after compression, like a TV series whose plot can still be followed after we've been away for a while.

Stage Four: Harness Engineering

What is Harness Engineering?

By this point, the LLM already has a smart brain, knows how to think, can act, and can remember. Yet, when completing complex tasks, its performance is still hit-or-miss.

The I Ching (Book of Changes) states, "That which is above form is called Dao (the Way); that which is below form is called Qi (the Tool)." If the LLM is the Dao, then the Harness is the Qi (tools, processes, specifications). Having the Dao without the Qi leaves the Dao with nothing to attach to, spinning in vain; though it can run, it cannot become a vessel (cannot produce usable finished products).

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

image

Agent = Model + Harness

image

A truly usable AI Agent consists of two parts: the Model (the brain) and the Harness (prompts, tools, context, sandboxes, feedback loops, recovery paths). All of these engineering scaffolds built around the model together constitute the Agent.

image

Using an operating system as an analogy, the LLM is equivalent to the CPU, while memory, disk, I/O, sound card, and graphics card all belong to the Harness. The performance of a computer 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 the same model ran in Claude Code's default Harness, it scored about 52.8 on Terminal Bench 2.0; after optimizing the Harness, the same model scored 66.5, leaping directly from the Top 30 to the Top 5.

Evidently, 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 a Harness

A complete Harness 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 to the AI, the Harness is responsible for deciding who breaks down the task, who calls the tools, who manages the memory, who ensures security, who judges whether the results are good, and who actually delivers the results to the production environment. By coordinating these phases in an orderly manner, the model is no longer fighting a lone battle in a chat box, but fighting cooperatively within a controllable process.

image

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

2. Tool Calling System.
   The model itself is responsible for understanding and judgment, but actually querying GitHub, running Shells, querying SQL, calling AWS, or updating Jira still 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 prioritization, and multi-turn task state preservation, letting the AI know what step it has reached, what to do next, and which rules absolutely cannot be lost.

4. Execution Sandbox System.
   After enabling the AI to perform operations, risks naturally emerge. It might accidentally delete files, execute dangerous commands, or access resources it shouldn't. Therefore, it needs to be confined to a secure little dark room (sandbox) for execution, limiting the AI's actions to safety boundaries: what it can read, what it can write, whether it can connect to the internet, and whether it can execute code—all must have 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 attempt; generated code needs tests run, documents need format checks, and execution flows need success evaluations. The feedback and evaluation system is responsible for scoring results, retrying on failures, automatic corrections, and quality assessments. This module is the AI's debriefing and iteration.

6. Delivery and Engineering Pipeline System.

For real-world businesses, writing code or generating a solution does not equal the end of the task. Beyond that lie builds, testing, approvals, delivery, monitoring, and rollbacks. The Delivery Pipeline is responsible for connecting the results produced by the AI into engineering pipelines like CI/CD, Jira approvals, and canary releases, so that the AI outputs can truly go live.

What is the difference between Harness and Vibe Coding?

What is the essential difference from Copilot?

Copilot is responsible for helping us quickly develop code, whereas the Harness is responsible for delivering high-quality products—that is, all steps after code generation: building, testing, deployment, security, and optimization, solving the true bottleneck of software delivery. Simply put, Copilot accelerates code creation, while Harness ensures that the code arrives in the production environment safely and quickly.

What core problems does it solve?

It is committed to ending manual tedious work for developers, security vulnerabilities brought 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 over 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 innovative work.

Looking at this, Harness Engineering doesn't seem like 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 it, tools solve how to do it, contexts solve how to remember, sandboxes solve how to do it safely, feedback solves how to do it better and better, and delivery pipelines solve how to truly deliver. These six things put together are the watershed for an Agent going into production.

In Closing

Looking back at these four stages, it is not hard to see that the capability curve of AI applications is moving from dialogue to action, and then from action to systems. In the beginning, we cared about whether the model was smart; later, we cared about whether it could use tools; and later still, we found that just being able to use tools was not enough—it also had to remember, reflect, and correct errors. The evolution of technology, in essence, is continuously filling out the various capabilities of AI, letting its eyes, ears, nose, tongue, body, and mind grow out one by one.

The root of our anxiety lies in the fact that the unit of evaluation has shifted from the individual to the organization. When engineering workflows like Harness begin to be restructured by AI, our concern is no longer about jobs disappearing, but rather the generational dimensional reduction blow of collaborative modes. Future scarce capabilities will inevitably shift from prompt engineering to workflow design—namely, the ability to design system architectures for human-computer collaboration.

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 restructure the power structures and operational interfaces of organizations? This is no longer a simple tool iteration, but a shift in management paradigms. The true answer sheet of 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 Engineering 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. The paper proposing the RAG concept 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