#Harness Engineering 是什么

模型提供 Agent 所需的推理能力，Harness 决定这些能力如何进入真实执行过程。理解 Harness，关键要看它解决了哪些问题、如何组织 Agent 运行，以及怎样控制执行边界。

#核心概念

这里的“运行时基础设施”采用广义定义，覆盖任务编排、上下文与状态管理、工具执行、安全控制、观测与验证。LLM 负责理解任务和生成决策，Harness 负责组织执行并控制边界。

从每轮模型调用的角度看，Harness 的任务就是：在正确的时间为给定的任务提供正确的上下文。这里的“上下文”不只是对话历史，还包括任务目标、系统指令、当前状态、可用工具、权限边界和工具执行结果。Harness 根据任务进展更新这些信息，并在每次模型调用前选择当前需要的部分。

#为什么需要 Harness

一次模型调用只能基于当前输入生成结果，真实任务却往往需要持续行动：读取数据、调用外部系统、处理失败，并根据执行结果调整下一步。工具由谁执行、上下文如何更新、危险操作是否允许、结果是否满足目标，都需要模型之外的系统负责。

这些问题可以归纳为五类：

简单问答或步骤固定的工作流不一定需要完整的 Harness。只有当任务需要根据中间结果动态决策，并持续调用工具时，这些能力才会逐渐成为必要条件。

#Harness 如何驱动 Agent

Harness 把一次任务组织成持续运行的闭环：模型负责生成响应，Harness 负责组装上下文、分流响应、执行工具并更新状态，再根据验证结果和停止条件决定继续还是结束。

这条链路不要求每一步都由模型判断。权限、超时、预算和结果校验通常更适合由确定性规则控制；只有需要理解语义或权衡方案时，才交给模型处理。

#Harness 的五类核心能力

Harness 没有统一的组件清单。按照任务执行链路，可以把它的职责概括为五类：

#任务编排与生命周期

Agentic Loop 是 Harness 的核心运行机制：模型生成决策，Harness 执行工具并回注结果，模型再根据新信息决定下一步。循环让 Agent 能够处理无法通过一次模型调用完成的任务。

循环必须同时定义退出条件。任务完成、达到最大轮次、超时、预算耗尽、连续失败或用户取消，都可能终止执行。对于复杂任务，Harness 还需要拆分任务、记录进度，并在暂停或失败后恢复到可继续的位置。

“模型决定停止”与“任务已经完成”不是一回事。是否完成可以由模型判断，也可以由测试结果、业务规则、外部评估器或人工审批决定。

#工具与执行环境

工具把模型的决策转换成外部动作。一个完整的工具通常包含名称、用途、输入结构、执行逻辑和标准化结果。模型生成工具调用请求，Harness 负责实际执行、错误处理和结果返回。

工具设计适合从少量、边界清晰的原子能力开始，再按任务组合。工具数量过多会增加选择成本；能力过于宽泛，又会放大误操作的影响。

工具能否完成任务还取决于执行环境。文件范围、网络访问、凭据、超时、资源配额和隔离方式共同决定了工具真正拥有的能力。对具有副作用的操作，还要处理重试和幂等性，避免重复执行放大影响。

#上下文与状态管理

上下文窗口有限，工具结果和对话历史却会持续增长。Harness 需要选择当前真正有用的信息，而不是把所有历史都塞给模型。

Context、State 和 Memory 解决的是不同问题：

常见策略包括裁剪无关内容、压缩早期历史、检索相关信息，以及把进度写入外部存储。压缩会损失细节，因此 Harness 只能尽量保留关键约束，不能保证所有重要信息始终留在上下文中。

#权限与安全边界

工具让 Agent 能够行动，也让错误决策产生真实副作用。Harness 需要在执行前判断操作是自动允许、需要人工审批，还是直接拒绝。

权限控制只解决“能不能执行”，不能单独保证安全。执行环境还需要限制文件、网络、凭据和系统资源的访问范围，并保留审计记录。即使模型或权限判断出错，沙箱和资源隔离也应限制操作的最大影响范围。

模型输入和输出也需要经过校验，以降低提示词注入、敏感信息泄露和越权请求等风险。Harness 还应遵循最小权限原则：默认只开放完成当前任务所需的能力，风险越高的操作，审批和隔离越严格。

#观测与结果验证

Agent 的执行过程是动态的，只看最终回答很难定位失败发生在哪一轮。Harness 需要记录模型请求、工具调用、错误、重试、延迟和 token 消耗，形成可追踪的执行轨迹。

观测说明“发生了什么”，验证判断“结果是否正确”。验证方式可以是测试、规则检查、模型评审或人工审核，应根据任务风险选择。执行结束只是生命周期状态，只有通过验收条件，任务才算完成。

对于不需要模型判断但必须执行的步骤，可以使用事件钩子在工具执行前后触发校验、格式化、审计或通知。钩子是确定性自动化的一种实现方式，不是 Harness 必须具备的固定组件。

#Harness 的设计原则

• 上下文不是越多越好，只提供当前决策需要的信息；
• 工具从边界清晰的原子能力开始，明确输入、输出和副作用；
• 关键约束尽量由权限、沙箱和验证器执行，不只依赖提示词；
• 停止条件与验收条件分开设计，不能把 Agent 停止当作任务完成；
• 从满足任务的最小 Harness 开始，只在出现明确需求或风险时增加复杂度。

#总结

Harness Engineering 将模型的推理能力组织成一条可持续执行的工程链路。模型负责处理不确定的理解与决策，Harness 负责提供上下文和工具，并用确定性机制控制执行边界、维护状态和验证结果。