中文内容

已翻译official company source英文原文2026-05-25

Back to Articles

Harness、Scaffold 与 AI Agent：值得准确理解的术语

发布于 2026年5月25日

Update on GitHub

Upvote

正文：98

正文：+92

正文：Sergio Paniego

正文：sergiopaniego

关注

正文：Aritra Roy Gosthipaty

正文：ariG23498

关注

目录模型支架编排框架智能体上下文工程策略工具使用技能子智能体训练强化学习环境训练器推演奖励了解更多当一个领域快速发展时，它的词汇往往比共同理解演进得更快。术语开始变得模糊，在不同语境中被重复使用，或成为一些从未被充分解释的想法的简写。我们目前正在 AI Agents 领域看到这种情况：概念被混在一起，有些被重新命名，另一些则在广泛使用几个月后悄然消失。

这对新入门者来说可能令人不知所措，即便是试图跟上最新进展的从业者也会如此。ICLR 2026 之后，我们中的一位（@ariG23498）发布了一个问题，很好地捕捉到了这种困惑：

“在智能体的语境中，你所说的 ‘harness’ 和 ‘scaffold’ 这些术语是什么意思？我在 ICLR 期间听到了很多解释，但我不明白为什么它们没有收敛到一个统一的解释。”

这份术语表是我们试图为那些不断出现、却缺乏清晰一致解释的术语奠定基础。它并不旨在成为涵盖该领域所有术语的完整词典。相反，我们聚焦于那些经常被混淆、以不同方式重复使用，或在并不显而易见时却被假定为显而易见的概念。

无论你是在构建智能体、部署智能体，还是只是在使用 Claude Code、Codex 或 Hermes Agent 等工具，这些术语中的大多数都会出现。最后一节涵盖了特定于模型训练的概念；如果你从事这方面的工作，它会更相关。

这些术语中有许多尚未有普遍接受的定义，不同框架对同一个词的用法也各不相同。这里的目标不是强制规定一套正确的词汇，而是提供一种实用的思维模型，让讨论更容易跟上。

我们开始吧。

模型

模型就是 LLM：它接收文本并输出文本（例如 Claude、Qwen、GPT、Kimi、DeepSeek……）。单独来看，它在调用之间没有记忆，也没有循环。模型可以表达调用工具的意图，但需要一个运行框架来实际执行它。它回答一个提示后就停止。将其包裹在脚手架和运行框架中，它就会成为一个智能体。

脚手架

围绕模型的、定义行为的层：系统提示词、工具描述、模型响应如何被解析、模型在各步骤之间记住什么（上下文管理）。无论是在训练期间还是推理期间，它都会塑造模型如何看待世界并在其中行动。

Claude Code、Codex 和 Antigravity CLI 等产品把这一整套东西称为 harness。Claude Code 自己的文档直接写道：“Claude Code serves as the agentic harness around Claude.” 这是广义用法：harness 指除模型之外的一切。当你需要分别推理二者时，比如在训练流水线中，scaffold/harness 这一区分就最为重要。你也会听到“scaffold”被更广泛地用于涵盖 harness 所依赖的任何基础设施：钩子、运行时配置，甚至目录结构。

一些产品（如 Claude Code 和 Codex）与其提供商的模型紧密耦合。另一些产品（如 Antigravity CLI 和 Hermes Agent）则允许你接入任何模型。

正文：Harness

智能体内部的执行层：它调用模型，处理模型的工具调用，并决定何时停止。harness 是让智能体运行起来的部分。前文定义的 scaffolding 是模型所依托的内容：它的指令、工具和格式。

Harness engineering 是一门良好设计这一层的学科：决定智能体何时应停止、如何处理错误，以及哪些护栏能让它保持在正确轨道上。它同时适用于训练和推理。Addy Osmani 的文章以及 OpenAI 关于使用 Codex 构建的介绍，都从推理侧涵盖了这一点。

在评估时，同样的模式表现为 eval harness：它不是收集训练数据，而是在某个模型检查点运行一组固定场景，并记录指标，而不是更新权重。

一些框架使用 orchestrator 来指代更高层级的控制器，用于协调多个智能体之间的工作。与通过执行循环驱动模型的 harness 不同，orchestrator 将智能体作为单元进行管理，每个智能体都运行自己的 harness（见下文 Sub-agents）。

智能体

这个术语来源于强化学习，在强化学习中，智能体只是一个接收观察并返回动作的函数。环境接收该动作并返回一个新的观察，如此循环往复。这个循环仍然是 LLM 智能体工作方式的核心。

在 LLM 领域，这个术语的含义已经扩展。智能体是一个模型加上其周围让它能够行动、而不只是响应的一切。它把原始的文本生成转变为可以在循环中行动的东西：接收信息、决定要做什么，并根据结果采取行动。

以一个编码智能体为具体例子。系统提示词、工具描述以及模型遵循的输出格式构成了脚手架。调用模型、处理其工具调用并决定何时停止的循环就是运行框架。在训练时，运行框架还会并行运行许多个这样的循环，并将结果反馈回来以更新模型。

在社区里，通常会把它表述为 Agent = Model + Harness（可参考 @Vtrivedy10 和 Will Brown 的推文）。如果你不是模型，那你就是 harness。上面两个部分所讨论的，正是 harness 与 scaffold 之间造成大多数困惑的细微区别。

当人们谈论 Claude Code、Codex 或 Cursor 这类产品时，他们指的是构建在特定模型之上的特定 harness，并且二者是一起设计和优化的。两个使用相同底层模型的产品，体验可能完全不同，因为它们的 harness 做出了不同选择。而将同一个 harness 中的模型替换为更好的模型，也会改变体验。模型、harness 和产品是三种不同的东西。

上下文工程

设计进入 agent 上下文窗口的内容：模型在每一步看到什么、系统提示词、工具描述、对话历史、检索到的知识。这不是一次性的决策：随着模型运行，先前的轮次会影响未来调用中包含的内容，而 harness 会在整个运行过程中主动管理这一点。它同时适用于训练和推理，但出错的代价非常不同。在训练时，模型看到的内容会塑造其学习到的内容。弄错了就要重新训练。在推理时，它只是文本：修改提示词并重新部署即可。HF Context Engineering Course 对此进行了深入讲解。

记忆是这一图景的一部分。短期记忆是在单次运行期间保留在上下文窗口中的内容：对话历史、工具结果、先前推理。长期记忆则跨会话持续存在，存储在外部并按需检索，然后在相关时重新注入上下文。

策略

策略是代理所遵循的行为：给定任何情境，它定义了采取每种可能行动的概率。在 LLM 系统中，该策略的一部分是在模型权重中学习到的，但行为也取决于周围的脚手架和运行框架。同一个模型可能会因其提示、工具、记忆和执行循环的不同而表现得截然不同。

策略并不是代理。策略定义行为；代理是在环境中采取行动的完整系统。将一个检查点封装在脚手架和运行框架中并部署它，你就会得到一个其行为由该策略决定的代理。

工具使用

智能体如何触达自身之外的资源：API、代码解释器、数据库、网络搜索、文件系统。模型以结构化格式表达使用工具的意图。现代推理 API 将其作为一等对象呈现：运行框架直接接收调用，并将其路由到正确的函数。结果会被送回上下文，循环继续。

技能

可复用、结构化的知识包，用于支持多步骤任务。工具是一种动作（“运行这条命令”），而技能则捆绑完成某个目标所需的一切（“调查这个 bug，形成假设，编写修复方案”）。它们可在智能体之间移植，并按需加载。工具、技能和子智能体之间的界限会随不同框架而变化。HF Context Engineering Course 对技能进行了深入讲解。

子代理

由另一个代理调用以处理特定子任务的代理。它有自己的模型和脚手架，能够独立推理并返回结果。调用它的代理不需要知道其内部如何工作。这正是子代理与工具（函数调用）或技能（封装的知识）的区别所在：子代理本身可以进行推理、使用工具，并调用更多子代理。发起调用的代理有时被称为编排器。

训练

无论是在训练还是部署中，上述术语都适用。以下四个术语专门用于训练阶段，在该阶段，代理会执行任务、获得评分，其模型权重会被更新。每个面向 LLM 的 RL 训练系统都围绕同一条流水线构建：

RL 环境

环境是你可以与之交互的任何事物：一个有状态对象，它以动作为输入，更新其内部状态，并返回一个观察结果。在 LLM 语境中，动作通常是工具调用。文件系统是一个简单示例：动作 touch foo.txt 通过创建文件来更新状态，而观察结果可能是更新后的文件列表。不同框架中的定义各不相同。

我们最近发布了一篇关于这一主题的专门指南，因此这里不再压缩概述；如需完整了解类型、框架和示例，请参阅 The Ultimate Guide to RL Environments。

训练器

训练器是让智能体变得更好的关键：它运行多个智能体回合，对结果进行评分，并利用这些结果更新内部模型的权重。TRL 的 GRPOTrainer 就是一个具体示例：它是一个单一类，负责处理回合生成、奖励评分和权重更新。

正文：Rollout

一次 rollout 指的是智能体从开始到结束的一次完整运行：智能体看到了什么、做了什么，以及在每一步获得了什么奖励。根据上下文，它也被称为轨迹（trajectory）或跟踪（trace）。这是强化学习算法用于学习的原始数据。

奖励

用于告知训练算法模型是否在变好的分数。它可以是可验证的（测试通过/失败、答案匹配），也可以是学习得到的（人类偏好、LLM-as-judge）；可以是稀疏的（在一次 episode 结束时给出一个分数），也可以是密集的（每一步给出一个分数）。这就是训练器实际用于更新内部模型权重的内容。关于每种类型的详尽拆解，请参阅 Adithya 指南中的 Reward Architecture 部分。

Rubrics 将奖励拆分为带有权重的显式维度，而不是单一数字。OpenEnv 和 Verifiers 将 rubrics 实现为可组合的对象（WeightedSum、Sequential、Gate）。