在AI代理中，Harness（线束）是指连接模型以使用工具并持续执行任务的执行结构，而Guardrail（护栏）是指检查并限制输入、输出和行为以确保其遵循既定策略的控制机制。Harness侧重于任务如何进行，而Guardrail则侧重于在何种条件下允许任务进行。
这两个术语在实际产品中经常重叠。Harness内部可能包含工具审批功能，而Guardrail工具甚至可能控制对话流程。因此，如果仅仅将其视为在两种产品系列中选择其一的问题，就很容易忽视组件的职责。
本文以AI代理的上下文为基础，整理了这两个概念的特点、协同工作方式以及容易混淆的术语。产品功能以2026年10月1日确认的官方资料为准，客户报告案例和架构图是为说明目的而设计的示例。
1. 即使是同一个模型，执行任务的方式也会不同
考虑一个请求：“分析上个月的客户咨询，生成报告并发送给相关负责人。”语言模型能够撰写报告文本，并不意味着整个任务会立即完成。它需要确定从何处读取咨询数据、调用哪些工具、将中间结果存储在哪里以及确认发送是否成功等过程。
当模型建议调用“查询搜索”工具时，实际程序会执行该工具。程序将搜索结果再次传递给模型，模型根据结果生成下一步行动或最终响应。这种重复被称为代理循环（agent loop）。Claude Agent SDK的官方文档也描述了一种同时提供工具、代理循环和上下文管理的结构。Claude Agent SDK 概述
此时，上下文是模型当前判断所参考的信息。这包括原始请求、对话历史、工具使用说明和搜索结果。由于模型一次性可参考的信息量有限，因此在长时间任务中，决定保留什么和总结什么也成为执行结构的一部分。
Harness这个词用于描述围绕模型的这种任务结构。然而，并非所有文档都指代相同的范围。有些文档侧重于连接模型调用和工具执行的迭代结构，而有些产品则指代一个包含文件管理、记忆、审批和子代理的执行环境。
因此，当听到“引入了Harness”的说法时，最好一并确认其包含的功能。实际的运营范围会因其仅提供工具执行，还是也提供任务中断后的恢复而异。
2. Harness的职责：连接、记忆、持续
Harness的核心在于将模型的单次响应连接成多步骤任务。以下是检查实现时有用的功能分类。并非所有Harness都必须提供以下所有项目。
工具执行与下一步连接
Harness告知模型可用的工具，并将模型请求的工具名称和参数连接到实际的执行代码。它还负责将执行结果和错误传递给下一个模型调用。任务是否完成、是否需要额外调用、是否中断循环，都由应用程序和Harness的设计决定。
在报告案例中，如果搜索结果不足，可以根据不同条件再次搜索；如果足够，则可以进入摘要阶段。反之，如果工具错误持续发生，可以配置为在预设的重试次数后停止。如果没有这样的终止条件，相同的请求可能会重复执行，浪费时间和成本。
任务状态与上下文管理
保存报告草稿、已完成的步骤、剩余的步骤和工具结果，可以更容易地继续任务。然而，保存的事实与在下一次模型调用中准确读取所需内容的事实是不同的。存储位置、加载时机以及摘要中要保留的内容需要一并设计。
Anthropic的长时间任务案例中，将初始环境配置阶段与后续逐步工作阶段分开，并利用进度记录、Git历史和功能列表。这是一个具体的Harness设计案例，它使得即使上下文发生变化，下一个会话也能了解当前状态。这并不意味着所有任务都必须采用相同的文件配置。Effective harnesses for long-running agents
提供执行环境和观察点
文件系统、代码执行环境、用户审批、子代理连接也可以包含在Harness中。例如，Deep Agents将文件系统、上下文管理、子代理和人工干预描述为主要功能。Deep Agents 官方概述
在运营中，还需要记录来追踪这个流程。需要知道哪个模型调用导致了哪个工具执行，以及哪个步骤失败了。然而，记录执行历史的功能和实际阻止危险行为的功能需要单独确认。仅仅在日志中留下“尝试发送”并不能判断发送受到了控制。
图1. 执行结构和策略检查点并置的参考设计。基于Deep Agents、NeMo Guardrails和Claude Agent SDK 权限控制的官方文档重新构建。此图不代表任何特定产品的确切内部结构。
3. Guardrail的职责：检查、决定、执行
Guardrail并非仅指一种检查方式或产品名称。在本文中，它广义地指将应用程序策略应用于执行流程的控制。根据产品不同，它可能仅指内容检查，也可能包括工具执行或对话流程控制。
例如，它可以修改包含个人信息的输入，阻止将搜索到的部分文档传递给模型，或阻止未经授权的工具调用。验证结果是否为指定JSON格式的质量检查有时也归入Guardrail的范畴。因此，“安全Guardrail”和“输出格式Guardrail”不能被视为处理相同风险。
NeMo Guardrails描述了五种类型：输入、对话、检索、执行和输出。特别是执行Guardrail应用于自定义工具的输入和输出，对话Guardrail影响下一步行动或响应流程。如果仅将Guardrail理解为最终答案的禁用词过滤器，就会忽略其范围。NeMo Guardrails的类型
检测结果必须反映在实际执行中
在报告中发现敏感信息是检测。决定该报告是否可以发送到外部是策略判断。不执行发送工具或将其更改为“待审批”是执行（enforcement）。这三个角色可以由一个模块执行，也可以由多个服务分担。
例如，如果个人信息检测器返回“存在敏感信息”，但发送代码忽略了该结果，那么检查已执行，但数据泄露防护策略并未应用。反之，如果接收检测结果进行脱敏，然后再次检查，并仅发送通过检查的结果，那么检测和执行就联系起来了。
规则和模型判断具有不同特性
工具名称是否允许、请求金额是否在限额内、是否存在必填字段等可以通过代码规则进行检查。请求在上下文中是否敏感、是否超出特定业务范围等可以使用分类模型或LLM。也可以设计将两者结合。
规则检查对已编写的条件一致地运行，但不能解决条件缺失的情况。使用模型的检查可以处理上下文，但需要测量误报和漏报。误报是错误地阻止了正常请求，漏报是允许了本应阻止的请求。无论哪种方式，都不能仅凭名称判断保护级别，而应确认检查对象和失败时的行为。
4. 两者的区别体现在“任务进展”和“策略应用”上
下表是理解各种实现的角色中心比较。单个产品可能同时提供这两种功能。
| 比较标准 | Harness | Guardrail |
| — | — | — |
| 核心问题 | 任务应按什么顺序继续？ | 此输入、输出或行为是否应被允许？ |
| 主要对象 | 模型调用、工具执行、状态、任务生命周期 | 内容、工具参数和结果、策略违反条件 |
| 代表功能 | 重复执行、上下文配置、状态保存、重试/终止 | 检查、脱敏、阻止、限制、审批请求连接 |
| 适用范围 | 整个任务的执行结构 | 输入、搜索、工具、输出等必要节点 |
| 关注指标 | 任务成功率、恢复成功率、延迟、成本 | 误报/漏报、绕过可能性、检查范围、阻止延迟 |
| 相互关系 | 可调用Guardrail并将结果反映到执行中 | 策略可在Harness内部或由外部服务应用 |
要具体了解差异，我们可以再次回顾客户报告案例。以下过程是为说明目的而设计的示例，并非特定SDK的默认行为。
- 请求接收：应用程序确认用户和业务范围，接收输入检查结果后开始任务。
- 资料检索：Harness执行搜索工具。搜索服务仅返回用户有权查看的资料，并在必要时对返回内容应用检查。
- 报告撰写：Harness将允许的资料传递给模型。对生成的草稿进行敏感信息和所需输出条件的检查。
- 发送请求审查：在实际发送之前，验证模型建议的接收对象和附件内容。如果策略要求，提示用户审批具体的发送内容。
- 执行与完成确认：仅允许的请求执行发送工具，并记录工具结果。如果执行失败，则不响应成功。
在这里，Harness连接了五个步骤。Guardrail负责其间的检查和限制。发送服务的访问权限检查是该服务应负责的独立控制。
图2. 外部发送前应用检查结果的设计示例。基于NeMo Guardrails和Claude Agent SDK 权限控制的官方文档重新构建。审批状态和故障处理方式应根据业务策略确定。
阻止最终答案与阻止工具执行不同
如果报告已经发送，即使只阻止“已发送”的回复，外部发送也无法撤回。数据更改或消息发送等改变实际系统状态的行为，需要在行为执行之前完成必要的判断。
如果设计是为了性能而同时执行检查和生成，则需要确认在检查完成之前可以进行哪些任务。临时生成文本与确认外部API的更改操作具有不同的影响。对于流式响应，在检查完成之前传递给用户的内容，后续无法通过阻止来撤回。
在实际应用中，调用顺序比钩子或回调的名称更重要。Claude Agent SDK的权限文档解释了在工具执行之前评估钩子和权限规则等的顺序，并表明在早期阶段决定的调用可能无法到达特定的回调。需要查阅已安装版本的文档，确认哪些路径会经过检查。权限评估顺序
5. 术语混淆的五个点
Harness并非总是指代理执行器
在软件中，Harness也可以指为执行或测试某个对象而连接起来的周边结构。例如，评估Harness（evaluation harness）是连接数据集、模型执行和分数计算的评估工具。EleutherAI的lm-evaluation-harness也是一个语言模型评估框架。不能仅仅因为名称中包含“harness”就将其归类为业务代理执行产品。EleutherAI 官方仓库
框架、运行时、Harness的边界重叠
可以方便地理解为：框架强调用于开发的组件和抽象，运行时强调维护状态并执行的基础，Harness强调具备任务所需工具和执行方式的配置。然而，这只是为了阅读文档而进行的区分，并非适用于所有产品的固定层次结构图。
LangChain在其文档中将LangChain区分为框架，LangGraph为运行时，Deep Agents为Harness。同时，它也将Harness描述为内置多种功能的框架。因此，一个产品可以属于更广泛的其他类别。Runtimes, frameworks, and harnesses
Guardrail既可指安全装置的目的，也可指特定功能
仅仅说“有Guardrail”很难解释为个人信息保护、幻觉减少、工具权限、输出格式都受到了控制。通过JSON格式检查的响应也可能包含错误事实，没有有害表达的工具请求也可能访问未经授权的数据。
在文档中，如果可能，使用带有对象和条件的表达会更清晰，例如“输出的个人信息检查”、“发送工具的接收对象限制”。这样可以揭示在“Guardrail”这个上位名称下实际实现了什么。
Harness的审批功能也可以充当Guardrail的角色
如果Harness提供在工具调用前获取用户审批的功能，那么执行结构中的一个功能也承担了策略控制的角色。将其称为Harness功能和描述为Guardrail可以同时成立。
反之，像NeMo Guardrails这样的工具也处理对话流程和动作选择。因此，与其严格划定Harness只执行，Guardrail只进行字符串过滤，不如确认哪个组件负责哪个阶段的决策更为准确。
沙盒和权限系统应分开看待
沙盒是一种隔离手段，限制执行代码可以访问的文件或网络等环境范围。Guardrail可以负责检查请求或结果是否符合策略。虽然同时使用这两种功能可以处理不同的边界，但不应仅仅因为其中一个存在就推断出其他功能也存在。
例如，即使报告撰写代码在隔离环境中执行，如果发送API被授予了过多的权限，仍然会存在单独的问题。反之，即使检查发送文本，执行进程的文件访问范围也不会自动缩小。
| 文档中看到的表达 | 首先要确认的内容 |
| — | — |
| Agent harness | 它提供了工具执行、状态、上下文、恢复中的哪些功能？ |
| Evaluation / test harness | 它执行实际业务任务，还是评估模型/代码结果？ |
| Guardrail | 它检查什么，失败时哪个动作会实际停止？ |
| Runtime / framework | 它指的是执行基础，还是开发组件？ |
| Sandbox / permissions | 在哪个层级限制了哪些资源和行为？ |
6. 在实际设计中，记录职责而非产品名称
绘制架构图时，仅仅使用“Harness + Guardrail”这两个框不足以传达足够的信息。对于报告案例，可以像下面这样一并记录检查对象和执行职责：
- 资料访问：搜索API仅返回用户有权限的文档。返回后不通过脱敏来替代访问权限检查。
- 生成内容：检查草稿，并根据策略发送进行修改、拒绝或待审查。修改后的结果也需再次确认所需条件。
- 工具执行：在发送前立即验证实际接收对象和附件。如果审批内容与将要执行的内容不符，则重新评估审批。
- 任务管理：设定时间、成本、重复次数的上限，对于发送等重复执行会产生问题的任务，在重试时确认是否重复处理。
- 运营记录：关联并记录应用的策略版本、检查结果和实际执行情况。日志中不必要地记录个人信息和秘密信息。
此列表并非主张特定产品的功能，而是可用于划分职责的设计项。在团队系统中，可以标明哪些项由Harness负责，哪些项由API服务器或策略服务负责。
验证也可以分为两个方向以明确。Harness检查任务是否可以完成、中断后是否正确继续、是否处理工具失败。Guardrail检查正常请求是否通过、禁止请求是否在实际执行前停止、以及检查服务无响应时会发生什么。
对于外部发送等重要操作，可以在未获得检查结果的情况下设计为等待或中断。而对于影响较小的功能，可以选择不同的故障策略。必须按服务明确这些选择，才能在发生故障时预测是放行还是阻止。
7. 总结：Harness是进展结构，Guardrail是策略控制
Harness连接模型、工具、上下文和任务状态，使代理能够持续工作。Guardrail在必要节点检查输入、输出和行为并应用策略。在实际系统中，Harness可能包含Guardrail，或者独立的策略服务或API可能负责部分控制。
当术语模糊时，可以确认三点：什么是执行结构？什么是检查控制？谁将检查结果反映到实际行动中？回答这三个问题，即使功能重叠的产品也可以根据职责和边界进行比较。
好的设计文档不会止步于Harness或Guardrail的名称。它会同时展示任务的进展路径和阻止未经授权行为的节点。只有展示了这种结构，才能在同一张图上判断功能、运营稳定性以及保护范围。
发表回复