前言

大家好，这里是程序员阿亮！最近我在自己的项目里面实践了Harness工程，准备来跟大家讲解一下Harness工程！这是Prompt工程、Context工程之后的又一大工程规范，也是Loop 工程的基础！

在过去的一两年里，大模型（LLM）的单体推理能力经历了爆发式的增长。然而，许多尝试将 AI Agent 落地于真实业务场景（如自动化编码、智能客服、复杂数据清洗等）的一线开发者，往往会面临一个共同的困境：

模型用的是最新的旗舰版，提示词也改了上百版，可一旦上线面对真实世界的不确定性输入，Agent 依然时而聪明，时而跑偏；在长链路任务中，它甚至会反复犯同一个低级错误，直至上下文溢出、Token 爆表。

这种不确定性曾让许多工程团队感到沮丧。AI 应用工程界迎来了一个关键的范式共识：决定 Agent 表现上限与稳定性的，往往不是模型本身的权重，而是它所处的外部运行环境——Harness（驾驭/约束系统）。

LangChain 曾在其权威报告中引用过一个令人警醒的实验：在不改变底层模型任何一个参数的前提下，仅仅通过优化其运行的外壳 Harness 架构，Agent 在 Terminal Bench 上的任务通过率就直接从 52.8% 飙升至 66.5%。业内技术专家也明确指出：在 AI 真正实现自我修改模型权重的“硬递归”之前，AI 的递归自我改进（RSI）将首先从优化这层外部“脚手架”（Harness）开始。

本文将为你深度拆解 Harness Engineering（驾驭工程） 的完整图纸，厘清它与 Prompt、Context 的本质关系，并逐层剖析成熟 Harness 的六层架构体系。

一、 AI 工程化的三次重心迁移

让 AI 能够稳定干活，工程界经历了三次认知的升级，每一次升级都伴随着重心向“生产落地”的进一步靠拢。

1. 第一阶段：Prompt Engineering（提示词工程）

• 核心痛点：模型有没有听懂指令？

• 核心手段：角色设定（System Prompt）、思维链（CoT）、Few-Shot（少样本提示）、XML 标签结构化组织。

• 局限性：提示词只是一种“软约束”。由于 LLM 本质上是在概率空间中预测下一个 Token，即使你用再严厉的语气写“请绝对不要输出 Markdown 标记”，在大长文本或者高负载推理下，模型依然会有一定概率违背指令。它解决的是表达问题，而非执行问题。

2. 第二阶段：Context Engineering（上下文工程）

• 核心痛点：模型有没有拿到正确的信息？

• 核心手段：RAG（检索增强生成）、上下文压缩、动态召回与过滤、渐进式信息披露。

• 局限性：上下文工程解决了输入侧的“垃圾进，垃圾出”问题。但它无法控制 Agent 调用外部工具时的越权行为，无法处理复杂的执行分支，更无法应对工具返回报错时的逻辑回滚。

3. 第三阶段：Harness Engineering（驾驭工程）

• 核心痛点：Agent 能不能在不确定的外部世界里，持续做对事情、不跑偏、且出错后能自动修复？

• 核心手段：确定性工作流、状态机管理、外部编译/Lint 验证、沙箱隔离、自动纠错反馈环（Feedback Loop）。

二、 深度拆解：成熟 Harness 的六层架构体系

一个可用于生产环境的高可靠 Harness 体系，从内到外可以划分为六个职责分明的控制层。下面我们对每一层进行深度剖析。

L1 信息边界层（Information Boundary）

• 职责：划定大模型在当前步骤中能够感知到的“世界范围”，绝对不允许无关信息污染模型的上下文。

• 为什么要这一层：长上下文窗口虽然解决了“装得下”的问题，但无法解决“Context Rot（上下文腐烂）”与“注意力分散”。实验表明，将整个代码库或几十万字的原始文档一次性塞给模型，其关键信息检索的漏失率和幻觉率会呈指数级上升。

• Harness 的解法：采用渐进式披露（Incremental Disclosure）和元数据代理（Metadata Proxy）。Harness 在输入给大模型前，会对信息进行物理上的“剪枝”和“分层结构化”。

  • 例如：在一个自动化重构任务中，L1 层绝对不会把整个代码库丢给 Agent，而是只提供被修改类的依赖抽象接口（Stub），隐藏具体的实现细节，确保大模型视野聚焦。

L2 工具系统层（Tool Execution & Gatekeeping）

• 职责：作为大模型与物理世界交互的唯一安全通道，负责工具的动态加载、权限控制、超时管理和返回结果的“去噪提纯”。

• 为什么要这一层：大模型往往无法准确评估外部工具返回的原始数据量。如果大模型调用了一个“查询数据库”的工具，而该工具直接返回了 10MB 的原始日志，大模型会被瞬间“塞爆”导致上下文崩溃。

• Harness 的解法：

  1. 输入翻译：大模型输出抽象的 Function Call 意图，由 Harness 翻译成具体的强类型系统调用。

  2. 结果提纯：工具执行后，Harness 充当过滤器，将冗余的、格式混乱的数据进行裁剪，只提炼出关键的结构化字段再塞回上下文。

  3. 安全审计：如果是 Bash 或 Code 执行工具，强制在受限的 Docker、gVisor 或 WASM 沙箱中执行，防止 Agent 意外执行高危系统指令。

L3 执行编排层（Workflow Orchestration & Track）

• 职责：将不确定性的“推理”过程，限制在确定性的“轨道”（状态机、工作流）之上。

• 为什么要这一层：纯依靠大模型自主思考（如纯 React 循环）极易陷入死循环（Loop）或陷入无效的尝试。

• Harness 的解法：确立 SOP（标准作业程序） 状态机。将任务流程拆解为诸如：拆解计划 -> 工具准备 -> 尝试执行 -> 格式校验 -> 归档 等物理节点。

  • 设计哲学：“该机械化的地方绝对不交由 AI 自由发挥（如版本控制、回退、依赖安装），该灵活推理的地方才抛给 LLM。”

L4 记忆与状态层（Durable Memory & State Management）

• 职责：在长时间、多批次的执行流中，隔离和管理不同生命周期的记忆，确保系统状态不产生混乱。

• 为什么要这一层：如果把短期对话、任务状态和长期偏好都混杂在一起，Agent 会在不断的自我否定中迷失。

• Harness 的解法：借鉴传统操作系统的设计：

  • 磁盘即状态：将 Agent 的所有中间产物直接持久化到物理文件系统（如特定的工作区文件夹）。

  • 版本控制即记忆：使用底层的 Git 分支或快照技术。Agent 的每一步修改，Harness 会在后台自动 commit 一次。一旦发现最新步骤严重走偏，Harness 能够通过 Git 强制回滚到健康的上一版本。

L5 评估与观测层（Deterministic Verifiers）

• 职责：不听信模型的“自我汇报”，使用独立于大模型的客观环境，对 Agent 的输出进行硬性验证。

• 为什么要这一层：大模型生成完一段代码或一笔订单后，如果你在提示词中问它：“你确定你的结果是正确的吗？”，它极大概率会出于幻觉自信地回答：“是的，完全正确。” 这种“自我验证”在工程上是不可靠的。

• Harness 的解法：引入确定性的编译器、测试运行器和 AST（抽象语法树）解析器。

  • 例如：在代码生成场景下，L5 层会静默启动 Maven/Gradle，运行单元测试，或者启动 Web 浏览器进行端到端渲染校验。只有测试通过，才判定步骤成功。

L6 约束、校验与恢复层（Constraints & Self-Healing Loop）

• 职责：这是 Harness 的防线底线。负责拦截一切不合规输出（Hard Constraints），并在发生系统错误时，捕获异常并转化成高质量的纠错上下文，驱动 Agent 实现自愈。

• 为什么需要这一层：传统软件中，抛出 NullPointerException 会直接导致服务中断。而在 Agent 系统中，底层异常不应该直接中断程序，而是应该作为“教学反馈”转化为大模型能够理解的天然输入。

• Harness 的经典设计哲学：Ralph Wiggum 信条：
  源自由前 Anthropic、OpenAI 团队实践总结出的自主 Agent 框架，其核心信条对 L6 层设计极具启发性：

  1. 新鲜的上下文才是可靠性（Fresh Context Is Reliability）：每一轮自愈重试时，清空之前凌乱的聊天历史，只保留干净的规格书（PRD）和上一轮失败的“红字报错信息”，重新激发模型进行思考，彻底避免模型在脏记忆中原地打转。

  2. 用背压代替处方（Backpressure Over Prescription）：不要在 System Prompt 里死板地指挥模型“第一步写 if，第二步写 else”。相反，应该在 L6 设置一道严苛的门禁（如：语法校验器），一旦生成的格式错误，给模型一个强烈的背压（错误回执），逼迫它自己寻找正确的路径。

  3. 计划是随时可抛弃的（The Plan Is Disposable）：在重试阶段，允许大模型彻底推翻上一轮生成的半成品，重新生成。重新生成一个计划的成本在现代 API 下极低，不要让它试图去缝补一个已经彻底坏掉的垃圾结构。

三、 实际项目例子：高容错数据清洗 Agent 的自愈设计

为了向你演示 Harness 核心机制（尤其是 L5 验证与 L6 纠错反馈环）是如何在代码中落地的，我们来看一个简化但高度形象的 Java 生产案例。

1. 业务场景

该 Agent 负责从用户的任意无结构脏文本中，提取并结构化成符合特定 JSON Schema 的标准报销单数据（包含消费金额、商户名、日期）。

import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;

/**
 * L6 控制器：脏数据清洗 Agent 的 Harness 驭缰外壳
 */
public class DataCleanupAgentHarness {

    private final ChatModelClient chatModel;       // 底层大模型客户端 (Model)
    private final LocalFileStateStore stateStore;  // L4 组件：本地持久化状态
    private final SchemaValidator validator;       // L5 组件：确定性校验器
    private final ObjectMapper mapper = new ObjectMapper();

    public DataCleanupAgentHarness(ChatModelClient chatModel, 
                                   LocalFileStateStore stateStore, 
                                   SchemaValidator validator) {
        this.chatModel = chatModel;
        this.stateStore = stateStore;
        this.validator = validator;
    }

    /**
     * 带 Harness 约束的核心执行逻辑
     */
    public ProcessResult cleanAndStoreData(String rawDirtyInput, String requiredSchema, int maxRetries) {
        // L1: 信息边界层 —— 给模型明确的“世界观”和“成功标准”，绝对不传入历史杂音
        String systemInstruction = "你是一个专门的数据结构化清洗 Agent。\n" +
                "目标：从脏数据中提取信息，并直接输出符合 Schema 的标准 JSON 字符串。\n" +
                "红线约束：只输出 JSON 实体。绝对不能带有 markdown 包裹标记 (```json)，绝对不带有任何解释。";

        // L4: 记录初始状态
        stateStore.saveState("raw_input", rawDirtyInput);

        // 初始化第一次尝试的输入
        String currentInputPrompt = String.format("脏数据: \n%s\n\nSchema约束: \n%s", rawDirtyInput, requiredSchema);
        int attempts = 0;

        while (attempts < maxRetries) {
            attempts++;
            try {
                // 1. 驱动模型生成 (Model推理阶段)
                String rawModelOutput = chatModel.callLLM(systemInstruction, currentInputPrompt).trim();
                
                // 2. L5: 评估校验阶段 (硬性格式验证)
                // 先尝试用 Jackson 强行解析，验证它是不是一个合法的 JSON
                JsonNode parsedJson = mapper.readTree(rawModelOutput);
                
                // 进而进行 JSON Schema 规范验证
                ValidationResult validationResult = validator.validate(parsedJson, requiredSchema);

                if (validationResult.isSuccess()) {
                    // 3. 校验通过，写入状态归档
                    stateStore.saveState("cleaned_output", parsedJson.toString());
                    return new ProcessResult(true, "清洗并校验成功！", parsedJson.toString());
                } else {
                    // 4. L6: 发生格式违规，启动自愈反馈回路 (Self-Healing Loop)
                    // 遵循 Fresh Context 信条：组装一个精简、明确的报错回执
                    String errorFeedback = String.format(
                            "校验失败通知：你刚才生成的 JSON 不符合 Schema 规则，系统已拦截该次写入！\n" +
                            "具体 Schema 报错如下：\n%s\n" +
                            "请针对错误点重新提取，直接输出纠错后的标准 JSON 字符串。",
                            validationResult.getErrorDetails()
                    );
                    
                    // 将错误回执注入到下一次的输入中，但不累积漫无边际的历史对话
                    currentInputPrompt = String.format("脏数据: \n%s\n\n纠错指令：\n%s", rawDirtyInput, errorFeedback);
                }

            } catch (com.fasterxml.jackson.core.JsonProcessingException e) {
                // L6: 拦截模型常见的 Markdown 标记错误、语法残缺错误
                String syntaxFeedback = String.format(
                        "语法错误通知：解析器无法读取你的输出，你输出的不是合法的 JSON 结构。\n" +
                        "底层解析错误：\n%s\n" +
                        "请注意：不要包裹任何 markdown 标记，必须以 '{' 开始，以 '}' 结束。请重新生成。",
                        e.getMessage()
                );
                currentInputPrompt = String.format("脏数据: \n%s\n\n纠错指令：\n%s", rawDirtyInput, syntaxFeedback);
            } catch (Exception e) {
                // 拦截非大模型导致的其他底座未知系统级故障，防止系统雪崩
                return new ProcessResult(false, "系统级未知错误中断: " + e.getMessage(), null);
            }
        }

        // 达到最大重试限制，安全门控强制熔断，防止无限重试造成 Token 暴涨 (Backpressure Limit)
        return new ProcessResult(false, "已达到最大自愈次数，清洗失败，已冻结状态转人工排查。", null);
    }
}

代码机制的深度讲解

• Jackson 解析与验证器分离（L5）：我们不让大模型来判断“输出对不对”，而是通过后端的 mapper.readTree() 进行物理校验。这是非确定性 AI系统与确定性工程系统的交接点。

• 精准上下文反馈（L6）：当遇到失败时，我们并没有无脑地把 “上一轮的 JSON + 用户的聊天记录 + 完整的系统报错” 一起打包堆叠回去（这样会迅速撑爆上下文窗口）。而是根据 Fresh Context 信条，重新组合出只有 原始脏数据 + 精确报错提示 的极简重试提示词，这能极大提高大模型在第二轮自我修正的成功率。

---

总结

大模型本身的能力正在逐渐被各家厂商“抹平”，而各大应用研发团队的核心技术壁垒，正在发生深刻的升维：

只擅长写 System Prompt 的工程师，生存空间正在被不断压缩；而懂得如何为 AI 设计“操作规程”（SOP 工作流）、“物理沙箱边界（L2）”和“自愈反馈监控门槛（L5/L6）”的 Harness 架构师，正在成为行业争抢的核心人才。

在构建你的下一个 Agent 之前，请牢记：
不要试图通过无休止地乞求大模型“要听话”来获得稳定性。
人类掌舵，Agent 执行。把规矩写在坚固的代码底座（Harness）里，把自由留给马力全开的模型。