Hugging Face 澄清 AI Agent 相关核心术语定义,帮助开发者建立准确的概念模型。
这对新手来说可能会让人不知所措,对想要跟上最新发展的从业者也是如此。ICLR 2026 大会之后,我们其中一位(@ariG23498)发了一个问题,很好地反映了这种困惑:
"在 Agent 的背景下,你所说的 'harness' 和 'scaffold' 是什么意思?我在 ICLR 期间听到了很多解释,但就是搞不明白为什么它们没有汇聚成一个统一的解释。"
这份术语表是我们的尝试,目的是为那些一直出现但缺乏清晰、一致解释的术语奠定基础。它并不是要成为该领域每一个术语的全面词典。相反,我们关注的是那些经常被混淆、被以不同方式重复使用或被假定为显而易见但实际并非如此的概念。
无论你是在构建 Agent、部署 Agent,还是仅仅使用 Claude Code、Codex 或 Hermes Agent 等工具,这些术语中的大多数都会出现。最后一部分涵盖了特定于训练模型的概念,如果你在该领域工作则更为相关。
其中许多术语还没有被普遍接受的定义,不同的框架使用同一个词时有不同的含义。这里的目的不是强制执行一套正确的词汇表,而是提供一个实用的心智模型,使讨论更容易跟进。
Model 是 LLM:它接受文本输入并产生文本输出(例如,Claude、Qwen、GPT、Kimi、DeepSeek…)。单独使用时,调用之间没有内存,也没有循环。Model 可以表达调用工具的意图,但需要一个 harness 才能真正执行它。它回答一个提示并停止。用 scaffolding 和 harness 包装它就成了一个 Agent。
围绕模型的行为定义层:系统提示、工具描述、模型响应的解析方式、它在各步骤间记住什么(上下文管理)。它塑造了模型如何看待世界和如何在其中行动,无论是在训练期间还是推理时。
Claude Code、Codex 和 Antigravity CLI 等产品把整个东西称为 harness。Claude Code 的文档直接说了这一点:"Claude Code 充当围绕 Claude 的 agentic harness。" 这是广义的使用:harness 意味着 model 以外的一切。scaffold/harness 的区别在你需要分别推理它们时最重要,比如在训练管道中。你也会听到"scaffold"被更广泛地使用来涵盖 harness 依赖的任何基础设施:hooks、运行时配置,甚至目录结构。
有些产品如 Claude Code 和 Codex 与其提供商的模型紧密耦合。而 Antigravity CLI 和 Hermes Agent 等产品让你可以接入任何模型。
Agent 内部的执行层:它调用模型,处理其工具调用,决定何时停止。Harness 是使 Agent 运行的东西。Scaffolding(定义如上)是模型工作的基础:其指令、其工具、其格式。
Harness 工程是设计好这一层的学科:决定 Agent 何时应停止、错误如何处理,以及什么样的护栏保持它的轨道。它适用于训练和推理。Addy Osmani 的文章和 OpenAI 关于用 Codex 构建的阐述都从推理的角度涵盖了这一点。
在评估时间,同样的模式显示为 eval harness:不是收集训练数据,而是在模型检查点运行一组固定场景并记录指标而不是更新权重。
有些框架使用 orchestrator 作为更高级别的控制器,可以协调多个 Agent 之间的工作。与驱动模型通过其执行循环的 harness 不同,orchestrator 管理 Agent 作为单元,每个都运行自己的 harness(见下文的 Sub-agents)。
这个术语来自强化学习,其中 Agent 只是一个函数,它获取观察值并返回一个动作。环境获取该动作并返回新的观察值,循环重复。这个循环仍然是 LLM Agent 工作方式的核心。
在 LLM 世界中,这个术语已经扩展了。Agent 是一个 Model 加上围绕它的所有东西,使其能够行动,而不仅仅是回应。它将原始文本生成转变为可以循环中行动的东西:获取信息、决定做什么以及对结果进行处理。
以编码 Agent 为具体例子。系统提示、工具描述和模型遵循的输出格式形成了 scaffolding。调用模型、处理其工具调用并决定何时停止的循环是 harness。在训练时间,harness 也并行运行许多这样的循环并将结果反馈给更新模型。
在社区中,通常表述为 Agent = Model + Harness(参见 @Vtrivedy10 和 Will Brown 的推文)。如果你不是 model,你就是 harness。harness 和 scaffold 之间的细微区别是造成大部分混淆的原因,上面的两部分解决了这个问题。
当人们谈论 Claude Code、Codex 或 Cursor 等产品时,他们指的是建立在特定 Model 之上的特定 harness,并一起设计和优化。使用相同底层 Model 的两个产品可能感觉完全不同,因为它们的 harness 做出了不同的选择。并且将更好的 model 交换到同一个 harness 也会改变体验。Model、harness 和产品是三个不同的东西。
设计进入 Agent 上下文窗口的内容:Model 在每一步看到什么、系统提示、工具描述、对话历史、检索到的知识。这不是一个一次性的决定:当 Model 运行时,之前的轮次塑造了进入未来调用的内容,harness 在整个运行过程中积极管理这一点。它适用于训练和推理,但错误的成本非常不同。在训练时,模型看到的形成了什么被学习。错了就要重新训练。在推理时,它只是文本:改变一个提示并重新部署。HF Context Engineering Course 深入涵盖了这一点。
Memory 是这个图景的一部分。Short-term memory 是在单次运行期间保持在上下文窗口中的内容:对话历史、工具结果、之前的推理。Long-term memory 跨越会话持久化,存储在外部并根据需要检索,然后在相关时注入回上下文中。
策略是 Agent 遵循的行为:给定任何情况,它定义了采取每种可能行动的概率。在 LLM 系统中,该策略的一部分在 model 权重中学习,但行为也取决于周围的 scaffolding 和 harness。相同的 model 可以根据其提示、工具、内存和执行循环的不同而表现出非常不同的行为。
Policy 不是 Agent。Policy 定义行为;Agent 是在环境中行动的完整系统。用 scaffolding 和 harness 包装一个检查点并部署它,你就得到了一个行为是该 policy 的 Agent。
Agent 如何到达自身之外:API、代码解释器、数据库、网络搜索、文件系统。Model 以结构化格式表达使用工具的意图。现代推理 API 将其作为一流对象呈现:harness 直接接收调用并将其路由到正确的函数。结果被反馈到上下文中,循环继续。
可重用的、结构化的知识包,能够完成多步任务。当 Tool 是一个动作("运行此命令")时,Skill 捆绑了完成目标所需的一切("调查这个错误、形成假设、编写修复")。它们是可以跨 Agent 携带的,并按需加载。Tool、Skill 和 Sub-agent 之间的界线在各个框架中移动。HF Context Engineering Course 深入涵盖了 Skill。
由另一个 Agent 调用以处理特定子任务的 Agent。它有自己的 model 和 scaffold,独立推理,并返回结果。调用 Agent 不需要知道它在内部如何工作。这是将 Sub-agent 与工具(函数调用)或 Skill(打包知识)区分开来的原因:Sub-agent 本身可以推理、使用工具,并调用进一步的 Sub-agent。调用 Agent 有时被称为 orchestrator。
上面的术语是否适用于训练或部署。下面四个是特定于训练的,其中 Agent 通过任务运行、获得评分,其 Model 的权重得到更新。每个 LLM RL 训练系统都围绕同一个管道构建:
你可以与之交互的任何东西:一个有状态的对象,它将一个动作作为输入,更新其内部状态,并返回一个观察值。在 LLM 背景下,动作通常是工具调用。文件系统是一个简单的例子:动作 touch foo.txt 通过创建文件来更新状态,观察值可能是更新的文件列表。定义在框架间有所不同。
我们最近发布了一个专门的指南,所以与其在这里压缩它,请查看《RL Environments 的终极指南》以获取类型、框架和示例的完整分解。
使 Agent 变得更好的东西:它运行许多 Agent 剧集、评分结果并使用它们来更新内部 Model 的权重。TRL 的 GRPOTrainer 是一个具体的例子:一个单独的类,处理剧集生成、奖励评分和权重更新。
从开始到结束的一个完整 Agent 运行:Agent 看到了什么、做了什么以及在每个步骤获得了什么奖励。它也被称为轨迹或跟踪,取决于背景。这是 RL 算法学习的原始数据。
告诉训练算法 Model 是否在改进的分数。它可以是可验证的(测试通过/失败、答案匹配),或学习的(人类偏好、LLM-as-judge)、稀疏的(剧集末尾的一个分数)或密集的(每一步的一个分数)。这是训练器用来实际更新内部 Model 权重的东西。对于每种类型的彻底分解,请查看 Adithya 指南中的奖励架构部分。
Rubrics 将奖励分解为具有权重的显式维度,而不是单个数字。OpenEnv 和 Verifiers 将 Rubrics 实现为可以组合的对象(WeightedSum、Sequential、Gate)。
@Vtrivedy10: The Anatomy of an Agent Harness: harness 组件及其存在原因的详细分解
Agent Harness Engineering: Agent = Model + Harness 的收敛框架,包含编码 Agent 示例
Harness Engineering: leveraging Codex in an agent-first world: 关于完全使用 Codex Agent 构建产品的真实账户,涵盖推理中的 scaffolding、反馈循环和上下文管理
Tool Schema Rendering Atlas (evalstate): 工具模式如何跨模型变成提示文本,显示每个模型在应用提供商模板后实际看到的内容
Simon Willison's How coding agents work blog: 编码 Agent 如何作为 harness 工作
AI Engineer talks like Harnesses in AI: A Deep Dive: harness 是什么以及如何构建一个。
The Ultimate Guide to RL Environments: 框架与框架的比较和词汇翻译
Continually improving our agent harness: Cursor 如何迭代其 harness 作为产品。
lm-evaluation-harness: 规范的 eval harness
如果任何定义感觉不精确,或者你遇到了我们遗漏的术语,我们很想听到你的意见。
感谢 Pedro Cuenca、Quentin Gallouédec、Shaun Smith 和 Adithya S Kolavi 审查本文。
The Open Source Community is backing OpenEnv for Agentic RL
Adding MCP Tools to Reachy Mini
流行使用中 Agent 的定义每年都在变化 :)
我们在去年的这篇文章中真的强调了自主性,但今年似乎都是关于 model + harness:https://huggingface.co/blog/ethics-soc-7
总的来说,术语越精确、在技术上越具体,就越好!
Coding Agent 或 Agent CLI – 一个命令行应用程序,用于启动和管理 Agent 实例(例如 Opencode、Claude Code、Copilot CLI、Gemini CLI 等)
Agent Definition – 一个文件(Markdown/JSON),描述 Agent 如何行为;充当实例创建的蓝图(如 Java 中的类)
Agent Instance – 从 Agent Definition 创建的运行进程(如从 Java 中的类实例化的对象)。
Agent / AI Agent – 避免使用;根据含义使用具体术语(CLI、Definition 或 Instance);不要忘记"Agent"也可以指 CI 管道代理或人类代理
MCP 在这一切中适应在哪里?
它是一个标准化协议,使 Tool Use → Harness 连接变得更清晰和更可互操作。术语表描述 Agent 做什么;MCP 是关于它们如何跨不同供应商和实现可靠地执行工具调用部分的规范。
感谢这份很好的写作。我们能否添加 a) 排行榜,b) 基准?
https://github.com/IBM/AssetOpsBench
非常有用的术语表,我特别感谢试图将 model、harness、scaffold、tool、context 和训练循环分开。
我对标准化术语"scaffolding"作为围绕 Model 的行为定义层有一个顾虑。对我来说,"scaffolding"在软件项目中已经感觉相当超载。它在代码生成中广泛使用,框架生成器使用得更狭隘地创建路由、控制器、模型、迁移、组件、测试和其他样板结构。
我想知道"rigging"是否可能是更好的候选者。它自然地与 harness 的隐喻相关,但在相邻的软件和 AI 背景下的标准化程度较低。在马/车的意义上,rigging 是将 harness 附加到被拉东西的安排,使整个设置可用。这似乎接近这一层对 Agent 的作用:系统提示、工具描述、响应格式、内存/上下文规则以及连接 Model 到特定方式的操作环境的其他配置。