Hugging Face 5 月 25 日发了一篇面向 AI Agent 开发者的术语梳理文章。它讨论的不是新模型，也不是新产品，而是一组容易被混用的词：model、scaffold、harness、agent、context engineering，以及训练侧的 environment、trainer、rollout、reward。

这件事有意思的地方在于，Agent 已经热了很久，社区里却连“harness”和“scaffold”该指哪一层都很难对齐。ICLR 2026 之后，这种混乱被放大了：有人在讲模型能力，有人在讲运行框架，有人在讲产品体验，还有人在讲强化学习训练管线。

我更在意的是这个判断：Agent 讨论里的很多分歧，不是观点不同，而是对象说错了。模型、执行层、行为约束和训练流程混在一起，排错会乱，评估会乱，采购也会乱。

先把四个边界定住：Model、Scaffold、Harness、Agent

Hugging Face 原文没有说自己在制定行业标准。它反而提醒，相关术语还没有统一定义，不同框架和产品会把同一个词放在不同层级。

所以这篇文章更像一张排错图。Agent 不好用时，问题未必在模型。也可能在提示、工具描述、上下文管理、执行循环、停止条件，或者训练奖励。

概念更接近什么最容易混淆的点
ModelLLM 本体，输入文本、输出文本本身没有循环、长期记忆和真实工具执行能力
Scaffold行为定义层，包括系统提示、工具描述、输出解析、上下文管理不等于完整运行时，但常被和 harness 混称
Harness执行层，负责调用模型、处理工具调用、控制循环和停止条件不是简单“外壳”，它决定任务能否跑完、何时停下
Agent通常可概括为 Model + Harness产品、模型、harness 不是同一件事

这个表最重要的一行，其实是 Model。

模型只是接收文本，再输出文本。它可以生成“我要调用某个工具”的结构化意图，但它不会自己真的去执行 API、运行代码、读取文件，也不会天然记住长期状态。

这些动作要靠系统完成。Scaffold 定义行为，Harness 负责运行。Agent 是它们组合出来的系统，而不是某个单独模型的别名。

这对开发者很实际。一个 Agent 失败了，不该只问“要不要换更强模型”。更应该拆开看：工具描述是不是含糊，输出解析是不是脆弱，循环是不是停不下来，上下文是不是被无关内容污染。

编码 Agent 的差异，常常不只来自底层模型

拿 Claude Code、OpenAI Codex、Cursor 这类编码工具看，用户感受到的是一个产品。可产品下面至少有几层东西：底层模型、系统提示、工具说明、文件系统访问、命令执行、错误恢复、上下文压缩、停止策略。

两个产品即使用相近或同一类底层模型，表现也可能差很多。差异可能来自 harness，而不是模型本身。

这也是很多 Agent 演示和真实使用之间的落差来源。演示里，系统像是在“自主完成任务”。实际落地时，工程团队要处理权限、超时、异常输出、工具返回脏数据、上下文溢出，以及循环停不下来的问题。

所谓 context engineering，也不只是写一段系统提示。它是在每一步决定模型能看到什么：历史对话、工具结果、检索内容、短期记忆，还是外部长期记忆。

这里有一个现实约束：scaffold 和 harness 不能被机械切成两块。不同产品和框架的叫法不同，有些会把提示、工具描述和运行控制放在同一个模块里。更稳妥的做法，是先问它承担什么功能，而不是先争这个词该归哪一类。

对两类人影响最大。

一类是 Agent 开发者。接下来调优时，不能只堆 prompt 或换模型。日志、轨迹记录、工具协议、错误恢复、停止条件、上下文压缩，都要进入评测范围。

另一类是企业技术选型的人。采购或迁移时，不应只看“用了哪个模型”。更要问：工具调用格式能不能接入现有系统，任务轨迹能不能审计，失败能不能回放，换模型时 harness 要不要重写。

如果这些问题回答不了，采购延后不是保守，而是正常风控。

训练侧别直接套到部署侧

Hugging Face 还把训练侧术语单独拎了出来。这个补充很关键，因为很多 Agent 文章会把强化学习训练和线上运行混着讲。

在 RL 管线里，environment 是可交互环境，trainer 负责跑 episode、打分并更新模型权重，rollout 是一次完整轨迹，reward 是训练算法用来判断好坏的分数。

这些概念和部署侧有关系，但不是一套语境。

语境常见对象主要关心什么
训练侧environment、trainer、rollout、reward怎么产生轨迹、怎么打分、怎么更新模型权重
部署侧scaffold、harness、context engineering怎么调用模型、怎么接工具、怎么控循环、怎么稳定交付任务

训练团队说 reward，可能关心测试是否通过、偏好模型怎么打分、稀疏奖励还是密集奖励。产品团队说优化 Agent，可能关心工具调用成功率、上下文污染、延迟、成本和失败回放。

两边都在说“Agent 变好”，但动的不是同一层。

这个区别会影响团队协作。研究团队不能把一次训练指标提升，直接等同于线上 Agent 体验变好。应用团队也不能把线上 harness 的补丁，误以为是在提升模型本身能力。

接下来最该看的，不是术语会不会马上统一。原文也没有给出这样的承诺。

更具体的变量有三个：工具调用格式能否更稳定，轨迹记录和评测 harness 能否复用，记忆与上下文注入方式能否减少迁移成本。

如果这些接口继续各做各的，企业从一个 Agent 框架迁到另一个框架，仍会付出很高成本。术语混乱只是表层，真正的阻力在工程边界还不够稳。