AI Agent术语迷思：当“脚手架”与“引擎”成为行业黑话

起因：为什么我们需要一本Agent“术语词典”？ AI Agent的浪潮来得又快又猛，但一个尴尬的现实是：我们连描述它的语言都还没统一。Hugging Face这篇博客的起因，源于一位研究者在ICLR 2026会议后的困惑——他听到人们频繁使用“harness”和“scaffold”，却无法理解为什么大家对这些词的定义无法达成一致。这揭示了一个深层问题：当技术演进速度超过共识形成速度时，术语就会变得模糊、混用，甚至成为新人和从业者的认知障碍。这篇文章不是要颁布“唯一正确”的定义，而是试图提供一个实用的思维模型，让讨论能更有效地进行。

拆解：Harness与Scaffold到底是什么？ 让我们用一个简单的类比来理解。想象一个Agent是一个正在工作的员工。

• 模型（Model）：就是这位员工的大脑，一个纯粹的思考引擎（如GPT、Claude）。它接收指令，输出文本，但本身没有记忆，也不会主动行动。
• 脚手架（Scaffolding）：这是给员工的工作手册和环境。它定义了员工“如何看待世界和采取行动”，包括系统提示（工作指南）、工具描述（可用的设备清单）、上下文管理（如何记住之前的工作内容）。它塑造了模型的行为模式。
• 引擎（Harness）：这是让员工真正动起来的执行系统。它负责呼叫大脑（调用模型）、处理大脑发出的工具使用指令、并决定何时停止工作。它是驱动整个工作循环的“引擎”。

文章特别指出，像Claude Code这样的产品，常把整个包（脚手架+引擎）都称为“harness”。这种宽泛用法在产品层面没问题，但在需要精细分析的场景（如训练流水线）中，区分两者就至关重要。此外，“编排器（Orchestrator）”是更高层级的管理者，它协调多个Agent（每个都有自己的引擎和脚手架）协同工作。

趋势洞察：术语混乱背后是领域的快速分化与成熟 这种术语的“定义争夺战”本身，就是AI Agent领域从概念走向工程实践的标志。当大家还在争论基本组件叫什么时，说明我们正处在从“能做什么”到“如何系统化地做”的转型期。清晰的术语是构建共享知识、开发通用框架和进行有效评估的基础。可以预见，随着实践深入，这些概念会像“前端/后端”在Web开发中一样，逐渐沉淀出被广泛接受的核心定义。

实用价值：这对开发者和产品经理意味着什么？

1. 构建更清晰的心智模型：当你设计一个Agent时，可以有意识地分别思考“脚手架”（我该如何设计提示和工具来引导模型？）和“引擎”（我该如何设计执行循环和错误处理来保证稳定运行？）。这能让你的系统架构更模块化、更易维护。
2. 评估与选型更有依据：理解“评估引擎（eval harness）”的概念，能帮助你设计更科学的Agent测试方案。在选择框架时，你能分辨它提供的究竟是灵活的“脚手架”组件，还是一个完整的“引擎”闭环，从而做出更符合需求的选择。
3. 高效沟通，减少误解：在与团队或社区讨论时，使用相对精确的术语，可以避免大量“鸡同鸭讲”的沟通成本，尤其是在涉及训练与推理、单Agent与多Agent协作等复杂话题时。

反常识/意外 一个有趣的点是，文章提到许多产品（如Claude Code）在实际宣传中会将“脚手架+引擎”的整体打包称为“harness”。这提醒我们，学术/工程上的精确定义与产品营销语言之间可能存在差距。作为从业者，我们需要理解这种区别，在技术讨论中使用更精确的术语，而在理解产品功能时则可以接受其更宽泛的表述。这本身就是一种重要的行业素养。

原文地址: Harness, Scaffold, and the AI Agent Terms Worth Getting Right