一次搞懂智能体核心术语：Harness与Scaffold的架构辨析

一、对比背景：为什么这些术语让人头疼？

在构建AI智能体（Agent）时，开发者常被一系列高度抽象且相互关联的术语包围。Model、Scaffolding、Harness、Agent、Context Engineering、Policy、Tool Use、Skills、Sub-agents，以及训练侧的RL Environment、Trainer、Rollout、Reward，这些词汇频繁出现在技术文档与架构讨论中。然而，多数资料只给出孤立定义，缺乏对彼此关系的系统阐述，导致读者理解碎片化。

本文的核心对比对象是 Harness（执行框架） 与 Scaffold（脚手架/行为定义层）。二者共同构成Agent的运行支撑，却承担截然不同的职责。理解它们的分工，是理解整个Agent架构的枢纽。同时，我们将顺带厘清其他关键术语在整体框架中的位置，帮助读者建立完整的认知地图。

二、对象定义：从模型到智能体的进化链

1. Model（模型）：即大语言模型本身，如常见的各类开源或闭源LLM。其本质是一个“文本进、文本出”的函数。模型拥有海量参数和强大的模式匹配能力，但自身是无状态的——它没有跨调用记忆，无法自主循环执行任务。模型可以表达意图，例如“我建议调用天气API”，但它不具备真正发起网络请求、解析返回值并继续下一步操作的能力。

2. Scaffolding（脚手架）：这是围绕模型建立的行为定义层。它规定了模型在特定场景下“应该做什么、以什么顺序做、如何做决策”。Scaffolding包含提示词模板、上下文组装规则、决策树、输出解析逻辑等。它像施工时的外围支架，为模型的输出提供结构约束和引导，确保模型行为符合预期框架。

3. Harness（执行框架/缰绳）：这是驱动模型并控制其与外部世界交互的运行时执行环境。Harness负责真正的执行动作：管理多轮对话循环、维护状态存储、调度工具调用（Tool Use）、处理异常、控制资源分配。如果说Scaffolding是“蓝图”，Harness就是“施工队”。Harness是模型能力的放大器，它赋予模型“手脚”。

4. Agent（智能体）：Agent = Model + Harness。这是一个简洁且精确的公式。模型是“大脑”，Harness是“躯体与神经系统”。当模型被封装进Harness，它才从一个静态问答工具，变成一个能够感知环境、做出决策、采取行动并观察结果的自主实体。

核心区分要点：Scaffold是关于“行为逻辑”的静态定义；Harness是关于“执行机制”的动态运行。Scaffold是无状态的配置或代码，Harness是有状态、持续运行的系统进程。

三、相同点分析：两者协同的基础

• 共同目标：两者都是为了使基础模型能够完成更复杂的、多步骤的真实世界任务，而不仅仅是单轮问答。
• 依赖模型：二者都紧密围绕模型展开，模型是它们存在的核心前提。
• 互补关系：Scaffold定义的策略需要通过Harness来执行；Harness的执行逻辑通常由Scaffold的规则来指导。优秀的Agent系统需要二者紧密耦合。
• 共同演进：随着模型能力的提升，Scaffold的决策逻辑和Harness的执行能力都需要相应调整。

四、核心差异分析：架构、职责与运行机制

4.1 功能定位差异

维度	Scaffolding（脚手架）	Harness（执行框架）
核心职责	定义“做什么、为什么做”	解决“如何做、如何确保做完”
状态管理	无状态，侧重逻辑编排	有状态，管理会话、上下文和进度
交互对象	主要与模型交互（输入输出）	与模型、外部工具、存储、网络全面交互
故障处理	逻辑上定义容错路径	物理上执行重试、超时、回退
生命周期	随应用启动而加载	随Agent会话开始而创建，结束后销毁
代码形态	提示词模板、逻辑函数、配置JSON	独立运行的服务、进程、类实例

4.2 技术架构与资源管理

Harness处于更底层，它直接调用系统API、管理会话堆栈、控制并发。它可能需要维护一个消息队列或事件循环来处理工具调用的异步返回。而Scaffold更靠近模型，它通过精心构造的Prompt或逻辑分支来引导模型的推理路径。

4.3 性能与扩展性

在一个高性能Agent系统中，Harness的执行效率（如最小化工具调用延迟、高效的状态序列化）直接影响整体吞吐。Scaffold的复杂程度（如过长的上下文组装）则会消耗更多的Token和推理时间。二者的优化方向不同：Harness侧重并发优化，Scaffold侧重上下文压缩与信息检索。

4.4 安全与合规边界

Harness是安全策略的执行点。它应该强制实施Tool Use的权限清单、数据脱敏规则、操作审计日志。Scaffold则更关注如何通过提示词约束模型不产生有害输出。安全设计上，Harness是“护栏”，Scaffold是“引导线”。

五、从训练到推理：术语全景图

为了彻底扫清迷雾，我们需区分推理时（Inference-time）架构与训练时（Training-time）流程。

5.1 推理侧（Agent运行时）

• Context Engineering（上下文工程）：这不是单一组件，而是一套方法论，属于Scaffold的高级形态。它涉及如何选取、排序、压缩信息放入模型上下文窗口。有效的Context Engineering是提升Agent推理质量的关键。
• Policy（策略）：在强化学习或复杂Agent中，Policy是决定“下一步采取哪个动作”的规则或模型。在Scaffold中，Policy可以是一段If-Else逻辑，也可以是一个小的分类器，决定调用哪个工具，或是将任务委派给Sub-agent。
• Tool Use（工具调用）：模型生成特定结构的输出（如JSON），Harness解析该结构并执行对应的函数。工具是Agent连接外部世界的桥梁。
• Skills（技能）：这是对工具和提示词流程的更高层封装。一个Skill可能是一套完整的、针对特定任务（如“市场分析报告生成”）的Scaffolding配置加上对应的工具集合。
• Sub-agents（子代理）：一个Agent可以向其他Agent（Sub-agent）发起任务请求。主Agent的Harness负责管理子Agent的生命周期，收集其返回结果。

5.2 训练侧（RL训练流程）

• RL Environment（强化学习环境）：提供给Agent（在这里是策略模型）进行试错模拟的沙盒。它定义了状态空间、动作空间和状态转移函数。
• Trainer（训练器）：负责更新模型参数的算法进程，如基于梯度策略的优化器。
• Rollout（轨迹采样）：Agent在RL Environment中执行一系列动作，直到终止状态，这个序列就是Rollout。它是训练数据的来源。
• Reward（奖励）：环境反馈给Agent的标量数值，用于衡量动作的好坏，是模型优化的信号。

关键区别：推理时的Harness生产“服务”，训练时的RL Environment生产“数据”。两者虽然都涉及“环境交互”，但目的截然不同。

六、典型场景选择：Harness与Scaffold的侧重

• 当业务逻辑变复杂时：如果你的Agent需要处理多步骤、依赖外部系统状态变动的任务（如“调研对手产品→生成对比表→自动发送邮件”），那么你需要一个健壮的Harness来管理状态机和事务。Scaffold的提示词写不好，尚可通过调整措辞优化；Harness如果崩溃，任务直接中断。
• 当模型需要强约束时：如果你的场景对输出格式、遵循固定流程要求极高（如生成合规财务报告），那么Scaffold的核心逻辑必须足够强硬，甚至需要写死逻辑而非仅靠提示词。

七、选型建议：如何审视你的Agent架构

从“新项目启动”角度：

1. 明确区分：首先在思维上分离“静态规则”与“动态执行”。在文档和代码中，将Scaffold层配置与Harness层逻辑分目录管理。
2. 评估你的Harness：一个成熟的Harness应支持断点续跑、超时控制、工具调用的并发限制以及完整的日志回溯。如果你的Harness无法做到，建议先补强这一层。
3. 简化你的Scaffold：不要在Prompt中堆砌无尽的历史消息。善用Context Engineering，只将当前步骤相关的关键信息填入。

从“迁移和改造”角度：

• 如果你正将一套单体脚本改造成Agent服务，切忌把所有逻辑都塞进Prompt。尝试将工具执行封装独立模块，交由Harness调度，这能显著提升调试效率。
• 迁移至云原生环境时（如使用某云厂商的容器托管服务），需注意Harness的弹性伸缩配置。无状态计算节点与有状态会话存储需要分离，建议使用外部会话存储服务。

八、使用注意事项：避坑指南

1. 不要混淆训练与推理：不要在调试Agent推理逻辑时，试图用RL算法去反向优化Model行为，除非你的Harness已经非常稳定。
2. 警惕“伪Harness”：许多自研Agent框架只是简单地在循环中调用API，这仅仅是一个“循环”，不是严格意义上的Harness。它缺少状态持久化、复杂错误处理等机制，难以支撑生产级任务。
3. Scaffold的脆弱性：基于Prompt的Scaffold非常脆弱，模型一升级可能行为就漂移。建议将关键判定逻辑用代码实现，而非依赖模型的理解力。
4. 关于Policy的边界：Policy决定了Agent的决策。如果Policy完全由代码写死，那么Agent的泛化能力弱；如果完全由模型自由发挥，则不可控。最佳实践是“代码控制主干，模型控制分支参数”。

九、总结：核心差异与决策思路

对比维度	Scaffolding	Harness
本质	行为契约、智能策略	物理执行、系统控制
故障表现	模型输出不合理、逻辑跑偏	程序崩溃、接口超时、状态丢失
调试方式	调整提示词、优化示例、修改逻辑树	查看日志、断点调试、检查资源水位
扩展重点	增加上下文压缩策略、改进决策分支	增加工具适配器、提升并发处理能力

最终决策思路：先用优秀工程手段强化Harness（稳），再用精妙逻辑设计简化Scaffold（准）。二者不是竞争关系，而是不同层面的必备设施。理解它们的差异，意味着你已经掌握了构建复杂AI应用最关键的架构判断力——这是从“调用API”到“设计系统”的分水岭。在规划下一阶段Agent能力升级时，建议优先审视你的Harness是否足够“结实”，再去追求Scaffold的“巧妙”。