Concept Genealogy
Anthropic 没发明 harness
Harness 在软件工程里已经存在几十年（test harness）；EleutherAI 在 2021 年把它带进 ML 评测（lm-evaluation-harness）；2024–2025 年 agent 社区扩展成 agent harness；Anthropic 在 Claude Code 文档里采用了这个标签，但既没发明它，也没独占它。
从词的本义走到具体公司的具体用法
六个停靠点。前四站交代这个词在 Anthropic 之前的来路；第五站是对原问题的直接回答；最后一站收尾这个概念在 2026 年被命名为一种工程实践。
"约束 + 导向"——一个老到不能再老的工程比喻
Harness 在英语里最早指马具：套在马身上的皮带、缰绳、轭，把动物本来乱跑的力气导到犁、导到马车的轮轴上。几百年后，工程师借用了这个词。汽车里有 wire harness，把几百根本来各走各的导线捆成一束、固定路径、防止短路。航天器里有 spacecraft harness，仪表板里有 instrument harness——共同点是：它们都不创造能量，也不创造信号；它们只是约束既有能量沿着设计的路径走。
这个隐喻骨架——constrain + channel——是软件工程后来借这个词的根本原因。当一段被测代码本身就是一个会"乱跑"的对象（依赖 IO、依赖时序、依赖其他模块）时，你需要一圈装置把它套住，给它受控输入、捕获它的输出、拦截它的副作用——这圈装置就是 test harness。
认清这个骨架很重要，因为接下来你会看到，把 LLM 当成"会乱跑的能量源"再套上一圈装置——就是 agent harness 这个词存在的全部理由。词没变，被套的对象从马、从电线、从代码变成了模型而已。
| 类别 | 被套住的能量源 | 装置的作用 |
|---|---|---|
| 马具 harness | 马的肌肉力量 | 把乱蹬的力气导到犁/车上 |
| Wire harness | 导线里的电流 | 把上百根线束成一捆、固定路径、防短路 |
| Test harness | 待测代码的行为 | 提供 stub/driver、受控输入、捕获输出 |
| Eval harness | 语言模型的回复 | 统一 prompt、统一打分、跨模型可比 |
| Agent harness | LLM 的推理 | tool、context、permission、sandbox、loop control |
如果你今天看到一个新名词"X harness"，你已经能猜出它在说什么：X 是某种会"乱跑"的能量源，harness 是把它约束、导向的那一圈装置。这就是为什么 harness 能从马具一路漂移到 LLM——这是一个 骨架式 的词，不是发明出来的术语，是借出来的隐喻。
Test harness：软件圈几十年的旧词
把 harness 这个词第一次大规模搬进软件工程的，是测试社区。Test harness 在 1990 年代已经是标准术语，指的是一组围绕被测代码的基础设施：stub（替代尚未实现的依赖）、driver（驱动被测代码执行）、test execution engine（运行测试的引擎）、test script repository（测试脚本仓库）2。它的目的跟马具一样：把一段本来"乱跑"的代码套住，让它在受控条件下运行、把它的输出捕获起来、自动判定通过/失败 🟢 high。
具体一点：JUnit、TestNG、pytest 这一系列工具就是 test harness 的标准化形态。你写一个 @Test 方法，它本身只是几行代码；让它真正能跑起来、能拿到断言结果、能集成进 CI——靠的是 JUnit 这套 harness 包了一层 runner、reporter、assertion library、fixture lifecycle。被测代码本身不知道 JUnit 在那儿；它从外面被约束、被驱动。
这一点是后面所有讨论的根：harness 的视角永远是从外面看。它不是被测对象的一部分，它是包在被测对象外面的那圈东西。当你后面读到"Claude Code is the agentic harness around Claude"——这句话的句法跟"JUnit is the test harness around your code"是同一种结构。
为什么这个词对 1990 年代的程序员是 plain English
到 1990 年代后期，test harness 已经写进 IEEE 测试标准、ISTQB 词典等正式文献，不需要解释。Wikipedia 的 Test harness 条目本身也只给一个简短的、不带历史争议的定义——这恰恰说明它已经过了"需要解释"的阶段2。一个术语进入这种状态时，它不属于任何公司、任何作者——它属于工程师的工具箱。
当你写 assertEquals(2, add(1,1))，add 函数是被测对象。但要让这一行真的"算"成一次测试，你需要：一个 runner 调用这个 method、一个 assertion 实现来做比较、一个 reporter 把"通过/失败"写出来。这三件事 add 函数本身都不做。它们都在 JUnit 那一边。JUnit 就是 add 函数的 test harness。
把整段类比平移到 LLM：当 Claude 写出一行 edit_file(path, ...)——模型只是生成了一段文本。要让这段文本真的"算"成一次文件编辑，你需要：一个解析器把它认成 tool call、一个 sandbox 执行 IO、一个 permission 层判断是否允许、一个 result formatter 把结果回填给模型。这四件事模型本身都不做。它们都在 Claude Code 那一边。Claude Code 就是 Claude 的 agent harness。
"Test harness 就是 testing framework"——不准确。Framework 是一个更宽泛的词；test harness 特指 stub + driver + 执行环境这一组围绕被测代码的基础设施。一个 framework 可以包含 test harness（JUnit 就是这种），但 test harness 本身是更聚焦、更老的概念。这种区分在 LLM 圈也一模一样：harness 比 framework 更聚焦——它强调"包在模型外面那一圈"，不是"任何 LLM 相关的库"。
Eval harness：被搬进 ML 词汇表的那一刻
把 harness 从 software testing 带进机器学习的关键事件，是 EleutherAI 在 2020–2021 年开发的 lm-evaluation-harness34。EleutherAI 是 2020 年成立的开源研究组织，最初的目标是复现 GPT-3 风格的大语言模型；他们很快意识到一个问题——大家说自己的模型在 BIG-Bench、MMLU、HellaSwag 上是 X 分，但每家用的是自己写的评测代码，根本无法直接比较。
于是他们造了一套 framework，让任意 causal language model 都能在完全一致的 prompts、完全一致的 codebase下被打分。这个 framework 的名字明确叫 evaluation harness——harness 这个词是有意挑的，因为它表达的就是"把不同模型套进同一组测试装置"🟢 high。
这件事的发生时间是 2021 年前后，跟 Anthropic 没有任何关系——Anthropic 当时刚成立（2021 年），Claude 系列模型还没发布。lm-evaluation-harness 后来成了 Hugging Face Open LLM Leaderboard 的后端，被 NVIDIA、Cohere、Mosaic ML、BigScience、BigCode 等几十家机构内部使用，被几百篇论文引用4。
这是 harness 这个词第一次系统性地进入 ML 词汇表的位置。任何讨论 "harness 这个词从哪儿来" 的对话，绕不开这一步。
在 lm-evaluation-harness 里，评测一个模型在 MMLU 上的得分大致是一条命令：lm_eval --model hf --model_args pretrained=meta-llama/Llama-3-8B --tasks mmlu。这条命令背后做的事——加载模型、加载 MMLU 题库、按统一格式 prompt 模型、解析回复、按统一规则打分、汇总报告——全部是 harness 这一侧的工作。模型本身完全不知道 MMLU 长什么样。这就是"约束 + 导向"在 ML 评测里的具体形态。
Agent harness：当 LLM 从答题者变成执行者
2023 年 ChatGPT 之后的两年是"模型外面那一圈"概念缺失定名的两年。LangChain、AutoGPT、BabyAGI、ReAct loop、各家自研脚本——大家都在写"模型外面的那一圈"，但命名混乱：scaffold、framework、wrapper、orchestrator、shell、agent stack。每一个词都对一半。
真正的转折点是 LLM 从"回答问题"转向"执行任务"。当 GPT-4、Claude 3、Gemini 这一代模型开始能调用工具、读写文件、跑命令、浏览网页时，模型外面那一圈的复杂度直线上升：你需要 tool 调用解析器、context 管理（不能让模型一直把 100MB 文件塞回 prompt）、权限和沙盒（不能让模型 rm -rf /）、session 与文件系统状态、loop control（什么时候停）、observability（哪一步出了问题）。
这一圈基础设施需要一个名字。2024 年 12 月 18 日的 CMU 论文 TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks 里就明确使用 "agent harness" 这个说法7——他们用 OpenHands 作为 "stable and strong agent harness" 来测一组模型 🟢 high。这是目前能找到的、被多个二手来源引用的最早学术用法。
同一时段，METR——专门做 AI 自治能力评测的非营利——也开始用 "scaffold/harness" 来描述被评测模型外面的代码层10。"Most AI models are evaluated with a basic agent scaffold that provides the model with Python and Bash commands and some very simple context management"——这是 METR 自己的原话。Scaffold 和 harness 在这个时期是交替使用的同义词。
Agent harness 包含什么
| 组件 | 它处理什么 | 举例 |
|---|---|---|
| Tool 层 | 把模型生成的 tool call 真的执行 | read_file / bash / web_search |
| Context 管理 | 决定什么进入 prompt、什么压缩 | auto-compaction / context window 管理 |
| 权限 / 沙盒 | 限制模型能动什么、能跑什么 | permission modes / Vercel Sandbox |
| Session / 状态 | 多轮、跨工作目录、可恢复 | ~/.claude/projects/*.jsonl |
| Loop control | 什么时候继续、什么时候停 | thrashing detection / max turns |
| Observability | 每一步可见、可回放、可调试 | checkpoints / replay logs |
上面这张表，几乎一字不差地对应 Anthropic 官方 Claude Code 文档里的 "Tools / Context window / Permissions / Sessions" 几节1。这不是巧合——这就是 agent harness 这个概念社区共识的具体内容。Anthropic 实现得很好，但结构来自整个社区。
注意上表里每一行都不是"模型推理"——模型推理始终是另一回事。这就是为什么 Birgitta Böckeler 后来的那句口号"Agent = Model + Harness"5能立得住——它在结构上把"会思考的部分"和"让思考能落地的部分"清晰切开。
Anthropic 是采用者，不是发明者
现在正面回答原问题。Anthropic 官方 Claude Code 文档（code.claude.com/docs/en/how-claude-code-works）原句如下1：
"The agentic loop is powered by two components: models that reason and tools that act. Claude Code serves as the agentic harness around Claude: it provides the tools, context management, and execution environment that turn a language model into a capable coding agent."
三个观察：
第一，Anthropic 用的是已有词汇，不是新造词。"Agentic harness"是把 "agent harness" 这个社区通用说法形容词化的小变体；它套用的是 EleutherAI 2021 年 lm-evaluation-harness 已经确立的命名模式（"X harness" = "包在 X 外面的装置"）。Anthropic 没有定义这个词，它使用这个词。
第二，Anthropic 的实质贡献在概念清晰度，不在词。"Model + Harness"这种二分在 Anthropic 之前已经被很多人说过；但 Anthropic 在 Claude Code 文档里把这条边界放到入口位置——"how Claude Code works" 这一页第一段就说清楚"模型负责推理、harness 负责让推理落地"——这是有价值的产品叙述。它普及了这个区分，没有发明这个区分。
第三，Anthropic 既不是最早用的，也不是用得最多的。对比一下时间：lm-evaluation-harness（2021）→ TheAgentCompany "agent harness"（2024-12）→ Mitchell Hashimoto "Engineer the Harness"（2026-02）→ Birgitta Böckeler 长文 "Harness engineering for coding agent users"（2026-04）。Anthropic 在 Claude Code docs 里采用 "agentic harness" 的具体时间不可考（docs 没有版本历史公开），但即便假设是 2025 年，它也不是最早的🟡 med。
有人会说："但 Claude Code 是目前公众最熟悉的 agent harness 产品，Anthropic 通过自己的产品把这个词推到了大众视野——这难道不算实质性贡献吗？"
当然算——但流行不等于发明。iPhone 让"smartphone"成为家喻户晓的词，但 smartphone 不是 Apple 发明的（IBM Simon 1994、Nokia 9000 1996 都先于 iPhone）。同理，Claude Code 让 "agentic harness" 成为更多人知道的词，但 harness 这个术语在 ML、在软件工程的存在远早于 Claude Code。本讲稿的判断仍然成立：Anthropic 是采用者和普及者，不是发明者。
"Anthropic 在 Claude Code 文档里用了 'agentic harness'，所以这是 Anthropic 的术语。"——错。一个公司在自己 docs 里用一个词不意味着这个词归这家公司。Microsoft Word 里用 "table"，但 table 不是 Microsoft 发明的；GitHub 用 "repository"，repository 也不是 GitHub 发明的。术语的归属看的是历史出现序和社区共识，不是哪家公司用得最响。
"Harness engineering"——2026 年初的命名时刻
如果说 2024 年底 agent harness 作为名词已经稳定下来，那么这个概念真正变成一种工程实践（即可以教、可以雇、可以做的事情）发生在 2026 年初。两个标志性事件：
2026 年 2 月 5 日，Mitchell Hashimoto 发表《My AI Adoption Journey》6。Hashimoto 是 HashiCorp 联合创始人、Terraform 作者，技术圈份量很大。这篇博客里有一节明确叫 "Engineer the Harness"——他的论点是：每次发现 agent 犯了错，你不修这次的错，你修让 agent 永远不再犯这种错的 harness。这一步把 harness 从一个名词变成了一个可以"engineer"的对象，从一种结构变成了一种实践方法 🟢 high。
2026 年 4 月 2 日，Birgitta Böckeler（Thoughtworks Distinguished Engineer）在 martinfowler.com 发表《Harness engineering for coding agent users》5。这是这一阶段最系统的综述，确立了"Agent = Model + Harness"这条公式，把 harness engineering 摆进 Martin Fowler 这种业界权威站点。
在这两篇之间的 ~90 天里，一波二手内容跟进——LangChain、Augment Code、HumanLayer、Firecrawl、MongoDB、Parallel.ai 等公司都发了自己的"什么是 agent harness"长文891112。这一阶段属于 zeitgeist 收敛——一个本来就在社区里流转的概念找到了正式的命名。
关键观察：这一阶段的"命名功劳"同样不在 Anthropic。Anthropic 的 docs 用的仍然是更静态的 "agentic harness around Claude" 这种描述；动词性的 "harness engineering" 这个职业说法是从 Hashimoto + Böckeler + 后继社区那里来的。
假设你在用 Claude Code，发现每次让它写 Python 测试时，它总忘了用项目的 pytest.ini 配置。Hashimoto 的论点是：不要每次都纠正它。你的工作是去 harness 那一侧做改动：在 CLAUDE.md 加一行 "测试统一用 pytest.ini 的配置"，或者写一个 hook 让它每次跑 pytest 前先 cat 一下配置，或者把 pytest 调用包成一个 skill。这就是 harness engineering——你不是在调试模型，你是在改模型外面的那一圈装置。
注意 harness engineering 这种实践跟 prompt engineering 的关系。Prompt engineering 是在 prompt 这一个层面调整；harness engineering 是在整个外圈调整——tool 设计、context 策略、permission 配置、skill 编排、CLAUDE.md 内容、hook 钩子。Prompt engineering 是 harness engineering 的子集。这条 hierarchy 还在演化，2026 年是它被命名的第一年。
Harness 是几十年旧词的最新一层，不是 Anthropic 发明的
直接回答原问题。
Harness 是什么？它是一种"约束 + 导向"装置的统称——围绕一个会"乱跑"的能量源（马、电线、待测代码、被评测的模型、agent 模式下的 LLM），从外面套上一圈让它按设计行动的基础设施。在当下 LLM 语境里，agent harness 特指模型之外让 agent 能落地的全部代码层：tool 调用、context 管理、权限沙盒、session 状态、loop control、observability。Anthropic 在 Claude Code 文档里给它一个简洁的形态——"models that reason and tools that act"——这是好的产品叙述，但不是新概念。
这是 Anthropic 发明的概念吗？不是。证据有三层：(1) Harness 作为软件工程比喻在 1990 年代的 test harness 实践里已经标准化，远早于 Anthropic 存在；(2) Harness 第一次系统性进入 ML 词汇表是 EleutherAI 2021 年的 lm-evaluation-harness，那时 Anthropic 刚成立，Claude 还没发布；(3) "Agent harness" 这个具体短语 2024 年 12 月已出现在 CMU 的 TheAgentCompany 论文，"harness engineering" 这种职业说法 2026 年 2 月由 Mitchell Hashimoto 命名、4 月由 Birgitta Böckeler 系统化——这两步都不是 Anthropic 的工作。
Anthropic 的真实贡献是采用与普及：通过 Claude Code 这个被广泛使用的产品，把 "model vs harness" 这条概念边界放进文档入口位置，让更多开发者认识并使用这个词。这是产品叙述上的功劳，不是术语发明上的功劳。如果你只关心实用，可以放心用 Anthropic 那套描述；如果你关心准确性——这个词比 Anthropic 老得多。
关键不确定性
- "Agent harness" 作为短语最早的公开使用未必是 TheAgentCompany 2024-12-18——本讲稿采纳它，是因为它是被多个二手来源引用、且是学术文献的最早可查记录；但完全可能更早的 Reddit thread、个人 blog、内部 Slack 已经在用，只是没被索引到 🟡 med。
- Anthropic 内部从什么时候开始用 "harness" 描述 Claude Code 的架构，没有公开记录。docs 现在的措辞可能是 2024 年就有的，也可能是 2025 年某次改写时加进去的。本讲稿的结论"Anthropic 不是最早"不依赖具体日期，但"普及者"这个评价的强度取决于 docs 改写的时间线🔴 low。
- 把 Mitchell Hashimoto 视作 "harness engineering" 这个名词短语的命名者，主要依据是几个二手 SEO 文章和 Hashimoto 自己 blog 的段标题 "Engineer the Harness"。这两者之间的因果链可能是真的，也可能是 zeitgeist 同时出现、Hashimoto 只是声量最大的一篇 🟡 med。
- "Harness" vs "scaffold" 在 LLM agent 社区是否真的有意义区分，目前仍在演化。METR 用 "scaffold"，Anthropic 用 "harness"，部分文献交替使用——结论是当前两者是同义词，但十年后回看可能其中一个会胜出 🟡 med。
Sources
- Anthropic — How Claude Code works（含 "Claude Code serves as the agentic harness around Claude" 原句）— https://code.claude.com/docs/en/how-claude-code-works
- Wikipedia — Test harness — https://en.wikipedia.org/wiki/Test_harness
- EleutherAI — lm-evaluation-harness（GitHub 项目主页）— https://github.com/EleutherAI/lm-evaluation-harness
- EleutherAI — LM Eval Harness（项目背景与影响）— https://www.eleuther.ai/artifacts/lm-eval-harness
- Birgitta Böckeler / martinfowler.com — Harness engineering for coding agent users（2026-04-02）— https://martinfowler.com/articles/harness-engineering.html
- Mitchell Hashimoto — My AI Adoption Journey（含 "Engineer the Harness" 一节，2026-02-05）— https://mitchellh.com/writing/my-ai-adoption-journey
- Xu et al. — TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks（arxiv:2412.14161，2024-12-18，含 "agent harness" 用法）— https://arxiv.org/abs/2412.14161
- Parallel Web Systems — What is an agent harness in the context of large-language models?（2025-12）— https://parallel.ai/articles/what-is-an-agent-harness
- MongoDB — The Agent Harness: Why the LLM Is the Smallest Part of Your Agent System — https://www.mongodb.com/company/blog/technical/agent-harness-why-llm-is-smallest-part-of-your-agent-system
- METR — Resources for Measuring Autonomous AI Capabilities（含 "basic agent scaffold" 用法）— https://metr.org/measuring-autonomous-ai-capabilities/
- Firecrawl — What Is an Agent Harness? The Infrastructure That Makes AI Agents Actually Work — https://www.firecrawl.dev/blog/what-is-an-agent-harness
- Addy Osmani — Agent Harness Engineering — https://addyosmani.com/blog/agent-harness-engineering/