一次搞懂AI Agent术语：模型、Scaffold与Harness

agent-model-harness">引言：Agent = Model + Harness

AI Agent（智能体）并不是一个神秘的黑盒。业界对其架构已逐渐形成共识：一个能自主完成任务的 Agent，本质上是“模型 + 运行时框架”的组合体，常用公式表达为 Agent = Model + Harness。其中，Model 是大语言模型本身，Harness 是驱动模型持续运转的执行层，而 Scaffolding（脚手架）负责为模型搭建静态支撑结构。理解这三者的边界——尤其是 Harness 与 Scaffold 的区别——是看懂整个 Agent 技术体系的第一把钥匙。

一、Model：会说话，但不会“干活”的大脑

Model 指大语言模型本身。无论参数规模大小、无论开源与否，市面上各类通用大模型本质上都属于这一层。从调用者视角看，它就是一个“文本进、文本出”的函数。

模型有三个关键特性，决定了它无法独立成为 Agent：

1. 无跨调用记忆：模型本身没有内置持久记忆，每次推理相互独立，上一次调用的上下文不会自动延续到下一次；
2. 无循环执行能力：模型对一个提示词生成一次回答后即停止，无法“自己决定继续做下去”；
3. 有调用意图，无执行能力：模型可以在输出中表达“我想调用某个工具”的结构化意图，但真正去执行工具、拿到结果、再喂回模型，必须由外部运行时组件完成。

换言之，单独的模型是静态的、无状态的，只能一问一答。它是一颗强大的大脑，但没有手、没有脚，也没有持续工作的机制。

二、Scaffolding：搭好架子，让模型站稳

Scaffolding（脚手架）是围绕模型搭建的静态支撑结构。类比建筑工程：脚手架是施工前搭好的架子，决定了工人在哪里作业、材料如何摆放。对应到 Agent 体系，Scaffolding 通常包括：

• 系统提示词（System Prompt）的设计与组织；
• 任务描述的模板化封装；
• 向上下文注入的领域知识、参考资料与行为规范；
• 预设的角色设定与流程框架。

Scaffolding 解决的核心问题是：如何让一个通用模型在特定任务上稳定发挥。它本质上是“内容层”的组织方式——决定什么样的信息、以什么结构进入模型的上下文。

三、Harness：真正的执行引擎

Harness（原意为“马具、缰绳”）是 Agent 的运行时组件，负责驱动整个执行循环。如果说 Scaffold 决定了“给模型看什么”，Harness 则决定了“模型跑起来之后发生什么”。它的典型职责包括：

1. 循环控制：判断任务是否完成，未完成则把最新上下文再次送入模型；
2. 工具执行：解析模型输出的调用意图，真正去执行工具（调用接口、运行代码、检索文档等），并把结果追加回上下文；
3. 上下文管理：维护对话历史，在上下文窗口接近上限时进行压缩、截断或摘要；
4. 状态维护：跨多次模型调用保持任务状态与中间结果；
5. 错误处理：工具执行失败时的重试、降级与恢复策略。

可用一个直观比喻理解三者关系：模型是马，Scaffolding 是搭好的赛道与路标，Harness 是套在马身上的缰绳与挽具——正是这副“马具”，把马的力量转化为实际的前进。也正因如此，业界常说：把模型装进 Harness，它才变成 Agent。

四、Harness 与 Scaffold 的区别：理解 Agent 架构的关键

这是最容易被混用、也最值得厘清的一组概念：

维度	Scaffolding（脚手架）	Harness（缰绳）
性质	静态结构	动态运行时
关注点	上下文内容的组织	工具执行与循环调度
生命周期	任务开始前已确定	随任务推进持续运转
类比	编译期产物	运行时进程

一个简单的判别方法：如果去掉它，Agent 还能“跑起来”，它多半属于 Scaffold；如果去掉它，循环停止、工具无法执行，那它就是 Harness。

五、其余核心术语速览

• Context Engineering（上下文工程）：比提示词工程更宏观。提示词工程关注“如何写好一段提示词”，上下文工程则管理整个上下文窗口——系统提示、对话历史、工具返回结果、检索到的文档，如何在有限窗口内取舍、压缩与编排。随着 Agent 上下文爆炸式增长，这一能力的重要性已超过单条提示词的打磨。
• Policy（策略）：Agent 的行为准则与决策边界，规定“什么情况下可以做什么、不可以做什么”。策略既体现在提示词层的软约束，也体现在运行时的硬性检查。
• Tool Use（工具使用）：模型输出结构化的调用意图，由 Harness 执行并将结果回填。这是 Agent 突破“只会说话”的关键，使模型能操作真实的外部系统。
• Skills（技能）：可复用的能力模块，封装“某类场景下该怎么做”的知识与流程，可被 Agent 按需加载，让能力像插件一样扩展。
• Sub-agents（子智能体）：将复杂任务拆分给多个专职 Agent 的架构模式。主 Agent 负责规划与分派，子 Agent 拥有独立上下文与工具集，完成后汇总。这能突破单一上下文窗口的限制，也便于隔离与并行。

六、训练侧术语：Agent 的能力从哪里来

上述术语都发生在推理与运行阶段，而 Agent 相关的模型能力，很大程度来自训练侧的强化学习体系：

• RL Environment（强化学习环境）：模拟真实使用场景的交互环境，模型在其中练习多步推理与工具调用；
• Trainer（训练器）：执行训练循环的组件，负责根据反馈更新模型参数；
• Rollout（推演/采样）：模型在环境中完整执行一遍任务的过程，产生的轨迹用于评估与学习；
• Reward（奖励）：对模型行为的量化反馈信号，决定模型学到什么样的行为模式。

理解这组术语的意义在于：Agent“会用工具、会多步推理”并非运行时凭空赋予，而是训练阶段通过环境、推演与奖励反复打磨出来的；运行时的 Harness 只是把已有能力组织起来释放。

七、一个 Agent 的完整工作循环

以通用伪代码示意（不含任何专有工具）：

context = scaffold.build(system_prompt, task, knowledge)
while True:
    response = model.infer(context)
    if response.has_tool_call():
        result = harness.execute(response.tool_call)  # 真正执行工具
        context.append(response, result)              # 结果回填上下文
    else:
        return response.final_answer                  # 任务完成

这个循环揭示了 Agent 与单次问答的本质差异：模型只承担“生成下一步”的角色，而循环的维持、工具的执行、上下文的流转，全部由 Harness 承担。主流云厂商（如百度智能云）提供的模型服务平台，通常也已将函数调用、编排等通用能力产品化，可降低自建 Harness 的工程成本。

八、典型应用场景

• 编码智能体：读取代码库、执行命令、运行测试、提交修改，需要长循环与多工具协作；
• 自动化客服与运营：按策略调用业务系统接口，完成查询、办理与工单流转；
• 数据分析与运维：跨数据库查询、日志检索、告警分析，多步推理后给出结论；
• 信息研究与收集：采用 Sub-agent 架构并行检索、汇总、去重，突破单上下文限制。

九、落地注意事项

1. 上下文管理是第一工程问题：任务越长上下文膨胀越快，压缩与截断策略直接决定 Agent 的稳定性；
2. 工具权限最小化：Agent 能执行工具意味着能操作真实系统，权限边界、沙箱隔离与人工确认节点必须前置设计；
3. 成本与延迟可控：循环式架构意味着多次模型调用，需在任务拆分粒度与调用次数之间寻找平衡；
4. 可观测性不可或缺：完整的轨迹日志（模型输出、工具调用、上下文变化）是调试与评估的基础；
5. 评估面向端到端任务：Agent 的优劣看任务完成率，而非单轮回复质量。

十、总结

回到核心公式：Agent = Model + Harness。模型是静态、无状态的大脑；Scaffolding 为它搭建静态的知识与流程结构；Harness 为它提供动态的执行循环与工具能力。Context Engineering 决定模型“看到什么”，Policy 决定它“被允许做什么”，Skills 与 Sub-agents 决定它“如何扩展与分治”，而训练侧的 Environment、Trainer、Rollout 与 Reward 解释了这些能力“从何而来”。把这组术语放进同一张架构图，Agent 技术体系就不再让人头疼——它是一个分层清晰、职责明确的工程系统，而理解它的起点，正是分清那副“缰绳”与那座“脚手架”。