Concise Summary简洁概述
An AI agent is the visible behavior; the 'harness' is the non-model software architecture — orchestration loop, tools, memory, context management, guardrails — that produces it, and it's now being named as a distinct engineering discipline.
Evidence that harness design, not model capability, often decides production performance: LangChain jumped from outside the top 30 to 5th on TerminalBench 2.0 by changing only the surrounding architecture.
AI Agent 是用户看到的行为表现，而“Harness”是产生这种行为的非模型软件架构——编排循环、工具、记忆、上下文管理、护栏——如今这已被正式命名为一门独立的工程学科。
证据表明,决定生产表现的常是 Harness 设计而非模型能力本身:LangChain 仅改变周边架构，就让 TerminalBench 2.0 排名从 30 名开外冲到第 5。
Infographic信息图
The dumb loop, smart model
笨循环，聪明模型
Anthropic explicitly calls their runtime a 'dumb loop' — all intelligence lives in the model, the harness just shuttles turns: assemble prompt, call model, parse output, execute tool, repeat. Complexity hides not in the loop's code but in the state and error handling around it.
Anthropic 直言其运行时是个“笨循环”：所有智慧都在模型里，Harness 只负责组装提示词、调用模型、解析输出、执行工具、循环往复。真正的复杂度不在循环本身，而在循环周围的状态与错误处理逻辑。
Context rot is the silent killer
上下文腐烂是隐形杀手
Stanford's 'lost in the middle' finding shows models degrade 30%+ when key info sits mid-window, even in million-token contexts. Production fixes — compaction, observation masking, just-in-time retrieval, subagent delegation — all trade completeness for a smaller, higher-signal token set.
斯坦福“迷失在中间”研究显示，关键信息处于窗口中段时模型表现会下降 30% 以上，百万级 Token 窗口也不能幸免。生产环境用压缩、观察掩码、即时检索、子 Agent 委托等手段，本质都是用完整性换取更小、信号更强的 Token 集合。
Scaffolding you're meant to tear down
注定要拆除的脚手架
The 'harness' metaphor implies impermanence: as models co-evolve with harness conventions during training, well-designed harnesses should shrink in complexity with each model upgrade rather than accumulate more scaffolding logic — the opposite of typical software growth.
“脚手架”这个词本身就暗示了临时性：模型训练时已将 Harness 的惯例内化，设计得好的 Harness 应随模型升级而变薄，而非像普通软件那样不断堆砌逻辑——这与常见的软件演化方向相反。
Same model, 20-rank swing
同一模型，排名跳 20 位
LangChain jumped from outside the top 30 to 5th on TerminalBench 2.0 by changing only the harness architecture — no model or weight changes. This is the article's strongest evidence that harness engineering, not model choice, often decides production performance.
LangChain 仅改变 Harness 架构（模型和参数完全不变），就让 TerminalBench 2.0 排名从 30 名开外冲到第 5 名。这是全文最有力的证据：决定生产环境表现的往往是 Harness 工程，而非模型本身。
Detailed Summary详细解读
The article's opening move is diagnostic: it locates the gap between demo and production not in model weaknesses but in the absence of surrounding infrastructure. This reframing matters because it shifts blame away from 'the model isn't good enough' toward 'the system around the model is missing pieces' — a more actionable and testable claim, since it points engineers toward specific fixable components rather than waiting for the next model release.
The core evidence — LangChain's TerminalBench jump from outside top 30 to 5th via harness changes alone — functions as the article's load-bearing proof point. It's cited once and not decomposed: we don't learn which specific harness changes drove the jump, only that architecture mattered more than parameters. This makes it persuasive as a headline stat but weak as a mechanism explanation.
The von-Neumann/CPU analogy (context window as RAM, external DB as disk, tools as device drivers, harness as OS) is doing real conceptual work: it explains why harnesses recur across independent teams — they're not a fad but a structural necessity once you accept the CPU-without-storage framing of a raw LLM. This is the piece's strongest theoretical contribution.
The 12-component taxonomy is comprehensive but uneven in depth: orchestration and context management get concrete mechanisms (compaction rules, masking, JIT retrieval), while guardrails and verification are described mostly by vendor feature lists (OpenAI's three guardrail tiers, Anthropic's three verification methods) without comparing their relative reliability or failure modes.
The probability-chaining argument (99% per-step success → 90.4% over 10 steps) is a clean illustration of why error handling matters, but it's a simplified independence-assumption model — real agent errors are often correlated (one bad tool call corrupts context for subsequent steps), so actual production failure rates could be worse than this multiplicative estimate suggests.
The closing 'scaffolding' and 'co-evolution' framing makes a falsifiable prediction — harnesses should thin as models improve — but the article doesn't test this against historical data (e.g., has Claude Code's harness actually simplified across model generations?), leaving the piece's most interesting long-term claim asserted rather than demonstrated.
文章开篇采取的是诊断性论证：把 Demo 与生产环境之间的落差，归因于缺失的外围基础设施，而非模型能力不足。这个重新定位很关键，因为它把责任从“模型不够强”转移到“模型周边系统缺了零件”——这是一个更具行动力、也更可验证的主张，让工程师能对症下药地修复具体组件，而不是干等下一代模型发布。
核心证据——LangChain 仅靠改动 Harness 就让 TerminalBench 排名从 30 名外冲到第 5——是全文论证的支点，但只被引用一次，没有拆解具体是哪些改动起了作用，只说明架构比参数更重要。这使它作为标题级数据很有冲击力，但作为机制解释则显得单薄。
冯·诺依曼/CPU 类比（上下文窗口=内存，外部数据库=硬盘，工具=设备驱动，Harness=操作系统）承担了真正的概念工作：它解释了为何不同团队会不约而同地收敛到相似的 Harness 结构——一旦接受“裸 LLM 就是没有存储的 CPU”这个前提，Harness 就不是流行做法，而是结构性必然。这是全文最强的理论贡献。
12 组件分类法覆盖面广，但深度不均：编排循环和上下文管理给出了具体机制（压缩规则、掩码、即时检索），而护栏与验证循环则主要停留在厂商功能罗列（OpenAI 的三级护栏、Anthropic 的三种验证方法），未比较它们各自的可靠性或失效模式。
“单步 99% 成功率→10 步流程约 90.4%”的概率连乘论证清楚说明了错误处理为何重要，但这是个假设各步独立的简化模型——实际 Agent 错误往往彼此相关（一次糟糕的工具调用会污染后续步骤的上下文），因此真实生产环境的失败率可能比这个乘法估算更糟。
结尾的“脚手架”与“协同进化”框架提出了一个可证伪的预测——Harness 应随模型进步而变薄——但文章并未用历史数据检验这一点（例如 Claude Code 的 Harness 是否真的随模型代际迭代而简化过），使全文最有意思的长期论断停留在断言层面，未被实证支撑。
FAQ常见问答
Is 'harness' just a rebrand of 'agent framework' or 'AI wrapper'?“Harness”只是“Agent 框架”或“AI Wrapper”的新说法吗？
No — the article distinguishes it explicitly: a wrapper just formats prompts, while a harness owns orchestration, state, error recovery, and guardrails — the full system that makes autonomous action possible, not a thin prompt shell.
不是。文章明确区分：Wrapper 只是格式化提示词，而 Harness 拥有编排、状态、错误恢复和护栏——是让自主行动成为可能的完整系统，而非一层薄薄的提示词外壳。
If harnesses matter this much, why do Anthropic and OpenAI call their loops 'dumb'?既然 Harness 如此重要，为什么 Anthropic、OpenAI 都说自己的循环是“笨”的？
Because the loop's control logic (call model, parse, execute, repeat) is intentionally simple — the sophistication lives in what surrounds the loop: context curation, memory design, error taxonomies, not in clever branching within the loop itself.
因为循环本身的控制逻辑（调用模型、解析、执行、重复）刻意保持简单——真正的复杂度在循环周围：上下文整理、记忆设计、错误分类，而不是循环内部的巧妙分支。
Does more tools/context always help agent performance?工具或上下文是不是越多越好？
No — the piece explicitly argues the opposite: exposing the minimal tool set needed for the current step performs best, and context management strategies exist precisely to trim, not expand, what the model sees at each turn.
不是,文章明确指出相反的结论:只暴露当前步骤所需的最小工具集效果最好,上下文管理策略的目的正是精简而非扩充模型每一步看到的内容。
Will harness engineering become unnecessary as models get smarter?随着模型越来越聪明，Harness 工程会变得不必要吗？
The article predicts harnesses will get thinner, not disappear — even the most capable model still needs something to manage context windows, execute code safely, persist state, and verify outputs; the argues necessity is structural, not a temporary crutch.
文章预测 Harness 会变薄，但不会消失——即便最强的模型也仍需要东西来管理上下文窗口、安全执行代码、保存状态、验证输出；这种必要性是结构性的，而非临时拐杖。
How should I decide between single-agent and multi-agent design?该如何决定用单 Agent 还是多 Agent 架构？
The article reports the official guidance is to exhaust single-agent potential first — multi-agent setups add coordination overhead and information loss between agents, so they should be a deliberate escalation, not a default.
文章转述的官方建议是先充分挖掘单 Agent 的潜力——多 Agent 架构会带来协调开销与 Agent 间的信息损耗，应作为审慎的升级选项,而非默认方案。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece names and formalizes something practitioners had been building ad hoc for years: the non-model software layer — the 'Harness' — that turns a stateless LLM into a working agent. It synthesizes public engineering disclosures from Anthropic, OpenAI, LangChain and others into a 12-component reference architecture.
这篇文章把从业者早已在实践、却始终没有名字的东西命名并系统化了：将“无状态”大语言模型转变为可用 Agent 的那层非模型软件——Harness。它整合了 Anthropic、OpenAI、LangChain 等公司公开披露的工程细节，归纳出一套 12 组件的参考架构。
- Concrete synthesis across vendors跨厂商的具体综合Rather than describing one framework, it compares Anthropic, OpenAI, LangGraph, CrewAI, and AutoGen's actual design choices side by side, giving readers a real comparative map instead of a single vendor's marketing framing.文章没有只描述单一框架，而是并列比较 Anthropic、OpenAI、LangGraph、CrewAI、AutoGen 的实际设计选择，为读者提供了一张真实的对比地图，而非某一厂商的营销叙事。
- Names concrete failure modes点名具体失效模式'Context rot,' 'lost in the middle,' and error-chaining through 10-step pipelines are named with mechanisms, not vague warnings — giving engineers specific things to test for in their own systems.“上下文腐烂”“迷失在中间”“十步流程中的错误累积”都给出了具体机制，而非笼统警告，让工程师知道该在自己系统里测试什么。
- Actionable decision framework可操作的决策框架The '7 key decisions' section (single vs multi-agent, ReAct vs plan-then-execute, tool scoping, etc.) converts the taxonomy into a checklist a builder can actually apply when designing a new harness.“7 个关键决策”一节（单/多 Agent、ReAct 还是先规划后执行、工具范围等）把分类法转化为构建者设计新 Harness 时能真正套用的检查清单。
- Grounds abstraction in a falsifiable claim用可证伪主张支撑抽象概念The co-evolution/thinning-scaffold thesis gives readers something to watch for over time — a prediction, not just a metaphor — which is rarer in agent-architecture writing that tends to stay purely descriptive.协同进化/脚手架变薄的论点给了读者一个可以长期观察验证的预测，而不只是一个比喻——这在通常止步于描述层面的 Agent 架构文章中相对少见。
- Single anecdotal proof point证据仅有单一案例The TerminalBench 30→5 jump is cited as the central evidence for 'harness matters more than model,' but it's one benchmark, one team, one unnamed set of changes — not a controlled study, so the magnitude may not generalize to other tasks or domains.TerminalBench 30 名到第 5 名的跳跃被当作“Harness 比模型更重要”的核心证据，但这只是一个基准测试、一支团队、一组未具体说明的改动——不是对照实验，其幅度未必能推广到其他任务或领域。
- Vendor claims taken at face value厂商说法未加审视Descriptions of Claude Code's memory architecture, OpenAI's guardrail tiers, etc. are drawn from official documentation and blog posts without independent verification or discussion of edge cases where these systems reportedly fail.关于 Claude Code 记忆架构、OpenAI 护栏分级等描述均来自官方文档和博客，未经独立验证，也未讨论这些系统实际失效的边界情况。
- No cost or latency accounting未涉及成本与延迟Compaction, subagent delegation, and verification loops all add API calls and latency, but the piece never quantifies this overhead — a harness that improves accuracy could still be impractical if it triples cost or response time.压缩、子 Agent 委托、验证循环都会增加 API 调用和延迟，但文章从未量化这些开销——一个提升准确率的 Harness，如果让成本或响应时间翻两三倍，实际上可能并不可行。
- Thinning-scaffold thesis is unverified“脚手架变薄”论断未经验证The claim that harnesses will simplify as models improve is presented as settled principle, but no historical trend data (e.g., harness complexity across GPT or Claude generations) is offered to support it — it remains a plausible but untested prediction.“Harness 会随模型进步而变薄”被当作既定原则提出，但没有给出历史趋势数据（例如 GPT 或 Claude 各代之间 Harness 复杂度的变化）支撑，目前仍只是一个看似合理但未经检验的预测。
Read this if you're building or debugging a production agent and want a vocabulary and checklist for the non-model layer that usually causes failures — the 12-component taxonomy and 7 key decisions are genuinely useful references. Treat the headline benchmark stat and the 'harnesses will thin over time' thesis as suggestive rather than proven, since neither is backed by data beyond a single cited case.
如果你正在构建或调试生产级 Agent，需要一套描述“非模型层”故障根源的词汇与检查清单，这篇文章值得一读——12 组件分类法与 7 个关键决策都是切实可用的参考。但对标题级的基准数据和“Harness 会随时间变薄”的论断，应视为启发性而非已证实的结论，因为两者都只有单一案例支撑，缺乏更广泛的数据佐证。
Excerpt原文节选
This is a short excerpt, not the full piece — the complete essay belongs to its original author; please read it in full at the link above.
以下仅为节选，并非全文——完整文章版权归原作者所有，请点击上方链接阅读全文。
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
Deep Dive: The Anatomy of an Agent Harness
Original: The Anatomy of an Agent Harness
This article takes a deep dive into what Anthropic, OpenAI, Perplexity, and LangChain are actually building. We'll talk about orchestration loops, tools, memory, context management, and the underlying mechanisms that turn a "stateless" large language model (LLM) into a fully capable Agent.
You may have already built a chatbot, or even used some tools to put together a ReAct loop (ReAct: Reason + Act, a pattern that has the model reason before it acts). It looks great in a demo, but once it goes into production, the system starts falling apart: the model forgets what it did three steps ago, tool calls fail silently, and the context window gets stuffed with meaningless junk.
The problem isn't really the model itself — it's the infrastructure surrounding it.
LangChain proved this: simply by changing the underlyi…
[…the source continues — read the rest at the link above]
[……原文更长，完整内容请点击上方链接阅读]
If you enjoyed this: Follow me → https://x.com/@akshay_pachaar ✔️ Every day I share tutorials and insights on AI, machine learning, and Vibe Coding best practices.
深度拆解：AI Agent Harness 的构造
原文： The Anatomy of an Agent Harness
本文将深入探讨 Anthropic、OpenAI、Perplexity 和 LangChain 究竟在开发什么。我们将聊聊编排循环、工具、记忆、上下文管理，以及那些将“无状态”的大语言模型（LLM）转变为全能 Agent（Agent）的底层机制。
你可能已经开发过聊天机器人，甚至可能用一些工具搭建了一个 ReAct 循环 （ReAct：Reason + Act，一种让模型在行动前先进行推理的模式） 。跑 Demo 的时候看着挺好，但一旦投入生产环境，系统就会开始掉链子：模型会忘记三步前做了什么，工具调用悄悄报错，上下文窗口（Context Window）里塞满了毫无意义的垃圾信息。
问题其实并不在模型本身，而在模型外围的基础设施。
LangChain 证明了这一点：他们仅仅通过改变包裹大语言模型的底层架构——模型没变，参数没变——就让系统在 TerminalBench 2.0 （一个衡量 AI Agent 处理命令行任务能力的权威基准测试） 上的排名从 30 名开外飙升到了第 5 名。另一项研究则通过让大语言模型自己去优化这套架构，实现了 76.4% 的通过率，甚至超过了人类精心设计的系统。
现在，这套基础设施有了一个正式的名字： AI Agent Harness 。
什么是 Agent Harness？
虽然这个术语在 2026 年初才正式确立，但其核心理念早已存在。 Harness 是包裹在大语言模型之外的完整软件架构：它包括编排循环、工具、记忆、上下文管理、状态持久化、错误处理和护栏（Guardrails）。Anthropic 在其 Claude Code 文档中直截了当地指出：SDK（软件开发工具包）就是“驱动 Claude Code 的 Agent Agent Harness”。OpenAI 的 Codex 团队也使用了同样的说法，明确将“Agent”和“Harness”等同，指代那些让大语言模型真正发挥作用的非模型架构。
[…the source continues — read the rest at the link above]
[……原文更长，完整内容请点击上方链接阅读]
如果你喜欢这些内容： 关注我 → https://x.com/@akshay_pachaar ✔️ 每天我都会分享关于 AI、机器学习和 凭感觉编程 (Vibe Coding) 最佳实践的教程与见解。