Introduction

1. Why This Whitepaper Is Needed

1.1. A Review Written for Publication, Not Another Internal Study

Between 2025 and 2026, the discussion around large models and agents revealed a notable misalignment: vendors talk about how capable the models are, while engineering teams talk about why deployment is still so hard. Each side has produced a great deal of material, but what is missing between them is a review document that can place both sides' evidence on the same table and discuss it in the same set of terms.

This whitepaper was written to fill that gap. It is bound by three self-imposed constraints:

1. Based on existing research; no new retrieval. All material comes from the 176 research documents and retrieval reports this project has previously completed (covering the overview, eight industry groups, and seven market groups); no new data unsupported by these materials is introduced during writing.
2. It has viewpoints, but every one must be backed by evidence. This whitepaper permits judgments, but every judgment is annotated with its factual basis and source grade; where evidence is lacking, that is explicitly marked rather than masked by rhetoric.
3. It distinguishes facts from judgments. Anything that is "a fact confirmed by public sources" is given a source; anything that is "an analytical conclusion of this project" is clearly stated as a judgment, for readers to accept or refute as they see fit.

Therefore, this whitepaper is not vendor promotional material, nor does it presuppose any product stance. It is more like an evidence list plus an analytical framework: readers may disagree with the framework, but they should be able to verify the facts.

1.2. The Five Questions This Whitepaper Attempts to Answer

The five questions progress in sequence: first define the object, then examine its structure, then examine industry differences, and finally examine the two "external checks" of evaluation and regulation. If readers are short on time, it is recommended to first read Chapter 3 of 02-Definition (why it needs to stand on its own as a layer); it is the hub of the entire whitepaper's argument chain.

1.3. Expected Takeaways for Three Types of Readers

---

2. The Turning Point from "Being Able to Chat" to "Being Able to Deliver"

2.1. Three Signs That the Turning Point Has Already Happened

This project has confirmed three signs in the overview module (see 01-Overview / 02-Development History) showing that AI has moved from the stage of "being able to chat" into the stage of "being able to deliver":

Sign one: capability has crossed the usability threshold. On SWE-bench Verified, Claude Opus 4.6 achieved 80.8% on 2026-02-05, becoming the first model on that leaderboard to break 80%; on Terminal-Bench 2.0, Claude Sonnet 4.5 achieved 51.0% on 2025-09-29, becoming the first model on that leaderboard to break 50%. The question these leaderboards answer has shifted from "can it be done" to "under what constraints can it be done, and who is responsible when it goes wrong".

Sign two: adoption has crossed the diffusion threshold. The DORA 2025 report shows that more than 90% of developers already use AI at work; the Stack Overflow 2025 Developer Survey shows that 84% of respondents are using or planning to use AI tools. Adoption has saturated; it is no longer a variable.

Sign three: a systemic crack has appeared on the cognition side. At the beginning of 2026, leading labs almost simultaneously acknowledged that the bottleneck constraining system performance is no longer inside the model. OpenAI put it as "our hardest challenges are now concentrated in designing environments, feedback loops, and control systems"; Anthropic put it as "harness design is the key to frontier agent coding performance"; and Google DeepMind's Philipp Schmid gave the most concise version — "most agent failures are no longer model failures, but context failures".

The three signs together point to one conclusion: the focus of discussion should shift from "which model is stronger" to "what engineering environment the model is placed in". That engineering environment is the subject of this whitepaper — the AI Harness.

2.2. Three Generations of Evolution: Engineering Focus Keeps Moving Outward

图 2-1｜AI 工程三代演进：瓶颈持续外移

数据来源：基于本文分析绘制的示意图。

This project uniformly adopts a three-generation division (see 01-Overview / Chapter 7 of 02-Development History):

It is important to emphasize that the three generations stack on top of each other rather than replace one another: prompt engineering is still necessary today, just no longer sufficient; tool calling has not been eliminated, but has been standardized into MCP. Each generation solves the model-external problems that the previous generation exposed. This evolutionary pattern of "the bottleneck continually moving outward" is the key to understanding why the Harness was given its own name in 2026.

In the development-history module (see 01-Overview / Chapter 8 of 02-Development History), this project also distilled four evolutionary laws, which form the methodological basis for the whitepaper's subsequent judgments:

1. The bottleneck keeps moving outward: from "the model does not know how to use tools" (first generation) to "too many tools to integrate" (second generation) to "context and governance determine success or failure" (third generation); each generation solves the model-external problems that the previous generation exposed.
2. Each generation sediments the previous one's core means into infrastructure: prompt engineering was sedimented into part of L1, and tool calling was standardized into MCP — a new generation does not replace, but turns the previous generation's manual work into default capability.
3. Standardization always follows de facto standards: MCP was released in November 2024 but not donated to the Linux Foundation until December 2025; AGENTS.md was first adopted by 60,000+ projects before becoming the donation target. Broad adoption as a de facto standard comes first, and a neutrally governed standard comes later.
4. Naming lags practice by roughly 12—18 months: the practice of context engineering began in August 2024 but was not named until June 2025; the product practice of the Harness began in early 2025 but was not named until February 2026. By the time a concept is formally named, its practice has usually already been running for at least a year.

The fourth law matters especially for this whitepaper's judgment about timing: the Harness was named in early 2026, but that does not mean it is a "something that has just appeared" — quite the opposite, it means the related practice has already accumulated for more than a year and a half, reaching the point where it must be independently named and independently governed.

2.3. The Million-Lines-of-Code Experiment: The Empirical Meaning of "Being Able to Deliver"

"Being able to deliver" is not rhetoric. The million-lines-of-code experiment disclosed by OpenAI in Harness engineering (2026-02-11) provides the fullest empirical evidence to date (a Grade A source):

Equally worth recording is the starting point of the experiment: the repository's initial scaffolding (including the original AGENTS.md) was also generated by the agent itself. This shows that what is delivered is not only the code, but also the engineering environment itself that supports the code being continuously produced — and that environment is exactly the Harness.

2.4. Three Necessary Conditions for the Harness to Be Independently Named at This Time

A natural question is: why was the Harness not formally named until early 2026? In the overview module (see 01-Overview / Chapter 7 of 01-Introduction), this project gives three necessary conditions, all of which were satisfied simultaneously between late 2025 and early 2026:

If any one of the three conditions is missing, the naming does not hold: when models are not strong enough, the bottleneck is inside the model and the importance of the engineering environment cannot be shown; when tools have no standard, the cost of building a Harness is too high for it to become common practice; when governance has no quantified benefit, "constraints are capability" is just a slogan. Therefore, the very fact that "the Harness was named in 2026" is itself evidence that the three engineering conditions matured at the same time.

---

3. Real Industry Problems: Three Engineering Capabilities That Have Not Improved in Step

3.1. Overview of the Evidence

While model capability has improved rapidly, three engineering capabilities have not improved in step. This whitepaper summarizes them as: deployment success rates are in doubt, reproducibility is insufficient, and auditability is lacking. The supporting evidence is summarized below:

The three problems are described in turn below.

3.2. Deployment Success Rate: The Divergence Between Perception and Measurement

METR's randomized controlled trial (2025-07-10, Grade A) is the most direct evidence of this divergence: after experienced open-source developers used AI tools on real open-source projects, their measured time to complete tasks actually increased by 19%, while the same developers self-rated as "20% faster". The two numbers point in opposite directions, differing by nearly 40 percentage points.

This project's analysis (judgment): the root of the divergence is that self-assessment measures the perceived speed of "the code-writing segment", while measurement captures the end-to-end throughput "from receiving the task to merging into the main branch". AI compresses the former but amplifies the latter's verification cost, review cost, and the cost of handling "looks right but is actually wrong" artifacts. In teams that lack objective measurement, this kind of divergence is long masked by perceptual narratives.

The countermeasures this project provides (judgment; see 02-Industry Enablement / Chapter 4 of the 03-Software Engineering Group):

1. Unify measurement to end-to-end: anchor on the four DORA metrics of deployment frequency, change lead time, change failure rate, and service restoration time, and forbid using "lines of code" or "completion adoption rate" as conclusions about effectiveness.
2. Make verification cost explicit: establish a "verification time / generation time" ratio metric; a ratio persistently greater than 1 means the verification stage has become the bottleneck.
3. Base conclusions on randomized controlled trials rather than before-after comparisons: before-after comparisons can be contaminated by seasonality, requirement difficulty, and staff turnover; a randomized controlled trial is the only design that yields causal conclusions.
4. Annotate the source of self-reported data: when citing self-reported numbers, they must be marked as "self-reported" and never mixed with measured numbers — this is precisely the premise that allows this section's two numbers to be presented side by side.

3.3. Reproducibility: The Same Model, Different Scores

Terminal-Bench (Stanford + Laude Institute) explicitly states in its methodology that what the leaderboard ranks are systems, not models — every score is the combined result of "a model + an agent harness". This means the Harness has already become an explicit variable in evaluation.

Multiple controlled cases of the same model with different scores can be found in public data. The numbers below come from Grade B/C sources, and all retain the [to verify] annotation:

Even if these specific numbers need a second verification, their direction has been confirmed by Grade A sources: differences in Harness design are enough to cause performance differences of several or even a dozen-plus percentage points, a magnitude that often exceeds the difference from switching models. For enterprises, this is simultaneously a risk (leaderboard numbers cannot be taken at face value) and an opportunity (performance can be improved through engineering means without switching models).

In addition, evaluation caliber itself has a drift problem: leaderboards with different task distributions are not comparable (the 80.8% on Verified and the 55.53% on Pro reflect differences in task difficulty, not fluctuations in model capability); configuration differences such as reasoning effort, tool availability, and step limits can affect results more than model differences themselves — for example, GPT-5.2's 52.5% on ARC-AGI-2 is explicitly annotated as using the xhigh reasoning configuration, so directly comparing that number with other models under default configurations is a caliber error (Grade B, [to verify]).

Accordingly, this project established a mandatory convention in the software-engineering-group documents that "citing a number must carry four elements": model name and version, leaderboard name, evaluation date, and reasoning and tool configuration. If any one of the four is missing, the number lacks comparability. The comparability hierarchy is: same leaderboard with same configuration is comparable; same leaderboard with different configuration is questionable; cross-leaderboard is not comparable. See 05-Benchmark.

3.4. Auditability: Adoption Has Saturated, but Trust Has Not Kept Up

The Stack Overflow 2025 Survey portrays a clear contradiction: adoption at 84% is close to saturation, yet the share that does not trust output accuracy has risen from 31% (2024) to 46% (2025), with only 3.1% trusting it highly. In the same survey, the share of developers holding positive sentiment toward AI also fell from above 70% to 60%. Trust has not kept up with adoption, and what is missing is not a better model, but an engineering layer that makes model behavior constrainable, reproducible, and provable.

The regulatory response confirms this. The EU AI Act (Regulation (EU) 2024/1689) imposes obligations of log retention, technical documentation, and human oversight on high-risk systems; China's Measures for the Labeling of AI-Generated and Synthesized Content took effect on September 1, 2025, pushing labeling obligations down to the level of metadata and export scripts; and GB/Z 185—2026, the Artificial Intelligence — Agent Interconnection series of national guiding technical documents, establishes a seven-part closed loop from identity codes and identity management to external tool invocation. Compliance requirements are moving from "principles" down to "engineering details", and the place that shoulders these details is precisely the Harness's L5 evaluation & observation layer and L6 governance & security layer.

A set of evidence worth presenting side by side is: IBM's Cost of a Data Breach Report 2025 shows that 13% of organizations report a breach of their AI models or applications, of which 97% of the compromised organizations had not deployed AI access controls, and 63% had no AI governance policy or were still developing one (Grade A). The governance gap of AI systems themselves has turned from a "potential risk" into "losses already incurred".

3.5. The Trust Gap Is the Harness's Space

Putting the evidence of the three sections together, this whitepaper's core problem consciousness can be compressed into one sentence (judgment): the gap between adoption rate and trust is the market space and engineering mission of the AI Harness. A model's probabilistic output cannot be eliminated, but it can be narrowed by engineering means to an acceptable range — this is precisely the Harness's defining responsibility, and the next chapter will give the formal definition.

---

4. This Whitepaper's Method and Boundaries

4.1. Material Sources and Retrieval Pattern

Information cutoff: This whitepaper and the research library it relies on have a full-library information cutoff of 2026-09-12; events later than that date are uniformly excluded from the body text. The day's increments (2026-09-12 snapshot) are marked as "Same-Day Increment" subsections and merged into each chapter; entries not confirmed against the official original text are uniformly marked with [To be verified]. For details, see the snapshot increment details in Section 4.1 of the v1.1 release page (/spec/releases/v1.1/) and the increment subsections of each chapter.

This whitepaper is a product of the based on existing materials mode. All material comes from the research documents and retrieval reports this project has already completed, including:

During writing, no new data beyond the above materials is introduced. If an original material marked a certain number as [to verify], this whitepaper inherits the same annotation and does not upgrade it to an established fact.

4.2. Source Grading and Annotation Conventions

This whitepaper follows the source grading used across the whole project:

The meanings of the three annotation symbols that appear in the body text: [to verify] means the number or fact needs a second verification before it can serve as a basis for decisions; [to fill in] means data should exist in that position but has not been obtained; [in doubt] means there are contradictory accounts, and the body text presents them side by side.

4.3. What This Whitepaper Does Not Do

1. It does not rank products. The conclusions of the market-research module are used to illustrate the landscape; this whitepaper does not rank any product on that basis.
2. It does not give investment advice. There is currently no authoritative estimate of the market size of the Harness layer itself (it falls under [to fill in]); existing generative-AI market forecasts differ by nearly an order of magnitude in caliber, so this whitepaper does not use such numbers as evidence.
3. It does not engage in technical mysticism. For any question that has "no publicly available solution" (such as whether single agents or multi-agents are superior), it honestly records the question as open and gives no speculative answer.
4. It does not replace any standard text. When standards are cited, they are interpreted only from an engineering perspective; compliance judgments follow the original text of the standards and regulations.
5. It does not repeat the research-library details. The full data, item-by-item sources, and information gaps of industry cases trace back to the corresponding documents in 02-Industry Enablement and 03-Market Research; this whitepaper retains only what is needed to support its conclusions.
6. It does not avoid adverse evidence. Any evidence that runs counter to the whitepaper's position (such as METR's measured slowdown, the negative returns of long context, and the limited credibility of vendor self-reported numbers) is all presented honestly, not selectively cited.

4.4. The Distinction Between Facts and Judgments

In its wording, this whitepaper observes the following distinction conventions:

• Facts: statements from Grade A/B sources with the source given, such as "Anthropic's sandboxed permission prompts reduced them by 84% (Grade A)".
• Judgments: analytical conclusions this project has drawn based on facts, such as "constraints are capability" and "the bottleneck has already moved outward". Judgments must be traceable back to the facts that support them; readers who do not accept a judgment can verify its factual basis.
• Analogies: such as the Test Harness, horse tack, and the four-layer computer stack — used only to aid understanding, not as arguments in themselves.

4.5. The Whitepaper's Three Main-Line Judgments

With the method and boundaries clarified, the book's overall argument thread can be previewed. The three following claims are all judgments of this project, and their full arguments are developed respectively in Chapters 2, 3, and the subsequent sections:

1. The bottleneck has already moved outward: the bottleneck constraining agent-system performance has shifted from inside the model to the engineering environment outside the model — this is not rhetoric, but the shared judgment of two leading labs in early 2026.
2. The Harness has already become an evaluation variable: evaluation ranks systems rather than models, and differences in Harness design are enough to change the ranking of scores — this simultaneously explains why leaderboard numbers cannot be taken at face value, and why enterprises must build their own internal evaluation capability.
3. The trust gap is an engineering mission: the gap between adoption rate and trust is an engineering problem rather than a model problem; what responds to it is not the next generation of models, but the engineering-bearing layer that had long been missing at this level.

---

5. Terminology and Reading Conventions

1. Unified definitions: the whole text uniformly adopts the unified definition of the AI Harness (see Chapter 1 of 02-Definition); no chapter redefines or rewrites it.
2. The six-layer capability model: L1 context-engineering layer, L2 tool and execution layer, L3 orchestration and control layer, L4 memory and state layer, L5 evaluation and observation layer, and L6 governance and security layer — used uniformly throughout the text, and the layer order must not be adjusted.
3. Three-generation evolution: the Prompt-Centric era (approx. 2020—2023) → the Tool & Orchestration-Centric era (approx. 2023—2025) → the Runtime & Evaluation-Centric era (2025—present).
4. Abbreviations: proper nouns, product names, and standard numbers retain their original English; abbreviations give the full name at first appearance. The Chinese glosses and sources of all terms are in 09-Appendix-Glossary.
5. Cross-references: references within the whitepaper are written as "see 0X-Chapter Title"; references to the research library are written as "see 01-Overview / 0X-File Name" or "see 02-Industry Enablement / 0X-Group Name".
6. Date conflicts: a few events have conflicting dates across sources (for instance, the release date of GB/Z 185—2026 has three calibers); this whitepaper uses broad-caliber wording such as "the first half of 2026", and preserves the conflict note.
7. Citing regulations: standards and regulations are cited with the full name plus the number, for example the Measures for the Labeling of AI-Generated and Synthesized Content (国信办通字〔2025〕2 号) and GB/T 45654—2025; interpretations of provisions are only from an engineering perspective, and compliance judgments follow the original text.
8. Units and symbols: numeric ranges are joined with "~" (e.g., 1,000~2,000 tokens); percentage numbers have no space before "%"; spaces are added between Chinese and English, and Chinese punctuation uses full-width forms.
9. Referencing tables and figures: references to tables in the body text are always written as "as shown in the table below" or "see the table above"; the numbers in tables and in body-text statements must agree — the review stage will verify them item by item.

---

6. Summary

This chapter answers "why this whitepaper is needed". Three conclusions:

1. The turning point has already happened: the three signs on the capability, adoption, and cognition sides show that AI has moved from "being able to chat" into "being able to deliver", and what constrains delivery quality is the engineering environment outside the model.
2. There are three real problems: deployment success rate is in doubt (self-assessment diverges from measurement), reproducibility is insufficient (the Harness has become an evaluation variable, and caliber drifts), and auditability is lacking (84% adoption vs. 46% distrust). Together these three constitute the trust gap.
3. This whitepaper's position: the trust gap will not close on its own just because models become stronger; it is an engineering problem that needs engineering means to respond — and the set of those means is the AI Harness.

---

7. Information-Gap Statement

1. The claim that OpenAI has dropped SWE-bench Verified as its primary evaluation benchmark: no first-hand source confirming this was found in this project's corpus; it was only mentioned during task assignment. This whitepaper does not use it as evidence; if it is to be cited, it must be separately verified, and it is annotated [to verify].
2. All of Section 3.3's comparison numbers of the same model with different scores (77.3% vs. 75.1%, 52.8% vs. 66.5%, Vercel 80% vs. 100%): they inherit the Grade B/C source attributes of the original materials, annotated [to verify].
3. The DORA 2025 conclusion that "AI adoption is negatively correlated with delivery stability": it comes from a second-hand paraphrase, annotated [to verify].
4. The market size of the Harness layer itself: there is no authoritative estimate, so it falls under [to fill in], and this whitepaper gives no number.
5. The release date of GB/Z 185—2026: there are three calibers — 2026-05-22 / 2026-06-26 / 2026-07-09 — and this whitepaper uses "the first half of 2026".
6. The original source that coined the term "Agent Harness": no first-hand origin literature has been found; this whitepaper claims no attribution to any originator.

---

8. References

1. Harness engineering: leveraging Codex in an agent-first world — OpenAI, 2026-02-11. https://openai.com/index/harness-engineering/
2. Harness design for long-running application development — Anthropic, 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps
3. Effective context engineering for AI agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
4. Effective harnesses for long-running agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
5. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (randomized controlled trial) — METR, 2025-07-10. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
6. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-29. https://survey.stackoverflow.co/2025/
7. DORA 2025 State of AI-assisted Software Development — Google Cloud / DORA, 2025-11-12. https://dora.dev/research/2025/dora-report/
8. Terminal-Bench official site — Stanford / Laude Institute. https://www.tbench.ai/
9. SWE-bench official site — Princeton NLP et al. https://www.swebench.com/
10. Linux Foundation Announces the Formation of the AAIF — Linux Foundation / AAIF, 2025-12-09. https://aaif.io/
11. Artificial Intelligence — Agent Interconnection: interpretation of the series of national standards — China Industrial Economic Information Network, 2026. https://cinic.org.cn/xw/zcdt/1643418.html
12. Measures for the Labeling of AI-Generated and Synthesized Content — Cyberspace Administration of China and three other departments, 2025. https://www.cac.gov.cn/2025-03/14/c_1743654684782215.htm
13. Harness engineering for coding agent users — Birgitta Böckeler, martinfowler.com, 2026. https://martinfowler.com/articles/harness-engineering.html
14. My AI Adoption Journey — Mitchell Hashimoto, 2026-02-05. https://mitchellh.com/writing/my-ai-adoption-journey