agent-scaffold-harness-">深度解析AI Agent架构：Scaffold与Harness核心差异对比
在当前的AI应用开发浪潮中，大语言模型（LLM）的能力边界不断拓展，但仅靠孤立的模型无法直接解决复杂的业务问题。开发者往往需要在模型基础之上构建复杂的系统工程。在这个系统工程的语境中，“Scaffold（脚手架）”与“Harness（缰绳）”是两个极易混淆但至关重要的核心概念。理解这两者的差异，是理清整个AI Agent架构、进行技术选型与方案评估的关键前提。
一、 对比对象定义与背景
要理解Scaffold与Harness的区别，首先需要明确“模型”在其中的定位。业界有一个通用的架构共识：Agent = Model + Harness。
- Model（模型）：即LLM本身。它是一个静态的、无状态的神经网络。其核心行为是“吃进文本，吐出文本”。模型自身没有跨调用的记忆，也没有循环执行的能力。虽然现代模型可以通过特定格式表达调用外部工具的意图，但真正执行这些意图并返回结果，需要外部系统的驱动。
- Harness（缰绳）：是围绕模型的驱动与运行控制层。它负责实现模型的循环执行、状态保持、工具实际调用、异常处理以及与外部环境的交互。如果把模型比作引擎，Harness就是底盘、传动系统和方向盘。它赋予了静态模型动态执行的能力。
- Scaffold（脚手架）：是围绕模型的行为定义层与提示词结构层。它定义了模型在面对特定任务时“应该怎么做”，包括任务拆解逻辑、思维链路引导、上下文窗口的组装结构以及工具调用的规范格式。Scaffold是Harness的先导蓝图。
简而言之，模型回答一个提示词就停了，必须通过Scaffold定义行为逻辑，并由Harness驱动循环执行，才能将其转变为一个真正的Agent。
二、 相同点分析
尽管Scaffold与Harness在架构职责上侧重点不同，但它们在AI Agent系统中存在紧密的联系与共同目标：
- 目标一致性：两者的终极目标都是为了突破基础模型的静态限制，使其能够处理多步骤、需要外部信息输入的复杂任务。
- 技术逻辑依赖：它们都围绕“上下文工程”展开。Scaffold负责组装和结构化上下文，而Harness负责将上一轮的执行结果注入到新的上下文中并传回模型。
- 不可分割性：在实际的工程落地中，Scaffold和Harness往往交织在一起。一个健壮的Agent系统，既需要清晰的Scaffold来保证逻辑正确，也需要稳定的Harness来保证执行可靠性。
三、 核心差异分析
理解Scaffold与Harness的核心差异，需要从多个技术维度进行深度拆解：
职责边界：定义层 vs 控制层
- Scaffold 关注的是“逻辑与认知”。它是一组提示词模板、思维链指令和输出格式约束。它告诉模型：“你是一个解决问题专家，请先分析问题，再调用工具，最后给出答案。”
- Harness 关注的是“执行与物理控制”。它是负责循环、拦截、分发和状态管理的程序代码。它监听模型的输出，如果发现工具调用意图，它会暂停模型，去真实世界中调用对应的API，拿到结果后再拼接进提示词并重新唤醒模型。
状态管理与持久化
- Scaffold 是无状态的结构定义，它规定了每一轮交互中上下文应该以什么顺序排列（如：System Prompt + History + Tool Definition），但不负责存储。
- Harness 承担了状态管理的重任。它负责维护跨调用的短期记忆（对话历史截断与压缩）、长期记忆的向量检索注入，以及执行过程中的挂起与恢复。
扩展性与灵活性
- Scaffold的扩展性主要体现在提示词工程的迭代和思维链路设计的优化。扩展Scaffold通常意味着增加新的指令规则或调整输出格式。
- Harness的扩展性体现在对“技能”和“子代理”的编排能力。扩展Harness意味着接入新的API工具、增加并发执行的Worker、或者配置新的子代理来处理特定领域的子任务。
安全与异常处理
- Scaffold 通过“策略”在认知层面约束模型，例如在提示词中加入“不要执行危险操作”“必须经过确认才能执行”的软性约束。
- Harness 在物理层面提供硬性约束。它通过权限控制拦截不合法的工具调用，处理API超时重试，并在模型陷入死循环时强制熔断退出。
四、 关键维度对比总结表
| 维度 |
Scaffold（脚手架） |
Harness（缰绳） |
| 核心定位 |
行为定义与逻辑引导层 |
驱动控制与运行时管理层 |
| 主要形态 |
提示词模板、思维链策略、输出规范 |
控制循环、状态存储、调度器、工具执行器 |
| 状态管理 |
无状态，侧重结构定义 |
有状态，管理记忆、历史与执行上下文 |
| 工具处理 |
定义工具的描述与调用意图规范 |
拦截意图，执行真实工具调用并返回结果 |
| 扩展方式 |
调整策略规则、优化上下文组装结构 |
接入新技能API、增加子代理、提升并发处理能力 |
| 异常控制 |
软性约束（如提示词限制危险行为） |
硬性熔断（重试机制、超时控制、权限拦截） |
| 对应训练侧概念 |
类似于Policy（策略指导） |
类似于RL Environment（提供执行反馈与环境交互） |
五、 训练侧视角的映射理解
为了更深刻地理解这两个概念，可以将其与模型训练侧（强化学习阶段）的术语进行映射对比。
在训练侧，Trainer（训练器）负责更新模型权重，Rollout（采样执行）是模型在环境中生成动作序列的过程，Reward（奖励）是对动作序列的反馈，而RL Environment（强化学习环境）则是模型交互的沙盒。
在这个视角下，Harness 的角色极度类似于一个微缩版的“RL Environment”。在生产环境中，Harness接住模型的输出（动作），在真实或模拟环境中执行，并将环境反馈拼装回上下文（类似提供Reward和Next State）。而 Scaffold 的作用则类似于 Policy（策略）的显性化表达，它指导模型在当前状态下应该采取什么样的行为逻辑。理解了这种同源关系，就能明白为什么在生产环境中Harness的稳定性直接决定了Agent的可用性。
六、 典型场景选择与方案建议
在实际的技术选型与架构设计中，开发者往往面临如何平衡Scaffold与Harness投入的问题。
轻量级单轮问答场景
- 如果业务仅仅是简单的信息抽取、文案生成或单步代码解释，不需要复杂的跨工具调用和长期记忆。
- 选型建议：在此场景下，重点应放在Scaffold的精细化打磨上，设计高质量的提示词即可。不需要引入复杂的Harness系统，采用简单的无状态请求/响应模式即可，以降低系统复杂度和延迟。
多步推理与外部工具调用场景
- 业务需要根据用户问题查询数据库、调用计算器并综合给出答案。
- 选型建议：此时Scaffold需要定义ReAct（Reasoning and Acting）的思维链框架，而Harness则成为核心。需要重点构建能够稳定进行循环调用、工具API鉴权执行、以及上下文截断管理的Harness系统。
复杂企业级自动化任务场景
- 涉及多部门系统联动、需要高并发处理、包含主从任务分发（Sub-agents）的复杂工作流。
- 选型建议：需要Scaffold与Harness的深度融合。Scaffold负责任务拆解和子代理的能力边界定义，Harness需要具备高可用性、完善的日志监控、严格的权限隔离（避免越权操作企业关键数据）以及子代理间的消息总线通信能力。对于团队运维能力有限的企业，可优先考虑采用云厂商提供的标准化容器平台与大模型服务托管能力，以降低自建Harness的运维成本。
七、 迁移与使用注意事项
当企业需要进行Agent架构的升级或不同模型底座的迁移时，Scaffold与Harness的迁移成本和注意事项存在显著差异：
- 模型底座迁移带来的Scaffold适配
不同厂商的模型对同一提示词的响应逻辑可能不同。迁移底座模型时，Scaffold层面临极高的适配成本。原本设计的思维链格式、工具调用意图识别标记可能在新模型上失效。需要重新进行提示词调优和边界测试。 - Harness架构的稳定性与工具生态
Harness由于是标准化的工程代码，其核心循环逻辑和状态管理通常可以复用。但需要注意的是，不同模型提供的工具调用接口格式可能存在差异。在迁移时，Harness中的“工具调用解析器”模块需要针对新模型的接口协议进行适配改造。 - 安全与权限的迁移风险
在切换Harness系统或重构Scaffold逻辑时，极易出现权限控制漏洞。必须确保原有的“硬性熔断机制”和“软性策略约束”在新架构中完整映射。建议在迁移初期采用影子模式运行，对比新老架构的输出与执行路径，确保没有危险的工具调用被意外放行。
八、 总结
在AI Agent的架构体系中，Scaffold与Harness并非对立关系，而是共同支撑模型能力落地的两大支柱。Scaffold是认知与逻辑的蓝图，决定了Agent“有多聪明”；Harness是执行与控制的骨架，决定了Agent“有多靠谱”。
对于开发者和架构师而言，在进行技术选型时，不能只关注模型参数量或提示词的精妙，而必须将Harness的架构设计、状态管理能力、异常处理机制放在同等甚至更高的优先级上。只有将清晰的Scaffold定义与稳健的Harness控制相结合，才能构建出真正可用、可靠的智能体系统。