简介：本文从“模型只提供能力，Harness决定可用性”出发，系统拆解Harness Engineering的本质、与上下文工程的分层关系，并给出可执行环境、记忆、工具、验证闭环等核心组件的设计思路与工程实践，帮助读者把大模型能力稳定转化为可交付的智能体系统。
一个常被忽略的事实是：大模型无论表现得多“聪明”，它的本质仍然是一个函数——输入文本（或图像、音频），输出文本。它没有记忆，不能执行命令，无法感知文件系统的存在，也不知道自己刚才那次修改究竟有没有把测试跑通。
因此，当我们谈论“智能体（Agent）”时，真正让一个模型从“会说话”变成“能干活”的，不是模型本身，而是模型之外的那一整套系统。这套系统就是 Harness。
用一句话概括：你不是模型，那你就是 Harness。 这句话听起来绝对，但它精确地划分了职责边界。Harness 包含系统提示词、工具调用协议、文件系统抽象、沙箱执行环境、任务编排逻辑、钩子与中间件、反馈回路、约束与权限机制。模型是能力的来源，Harness 是把状态、工具、反馈和约束串联起来的骨架。没有 Harness，模型只是一个离线推理器；有了 Harness，它才成为一个能在真实环境中持续行动的智能体。
一个经典的类比是 CPU 与操作系统。CPU 再强，如果操作系统调度混乱、驱动缺失、频繁崩溃，用户体验依然糟糕。反过来，一颗中端芯片配上稳定的系统，日常体验往往更可靠。模型与 Harness 的关系正是如此：模型决定能力上限，Harness 决定这个上限能被兑现多少。
很多人把提示词工程、上下文工程、Harness 工程并列成三个平行的“技巧集合”，这是误解。它们实际上是嵌套关系，且每一层解决的是完全不同的问题。
| 层级 | 解决的核心问题 | 关键词 |
|---|---|---|
| 上下文工程 | 模型此刻该看到什么信息 | RAG、记忆注入、Token 预算、上下文压缩 |
| Harness 工程 | 整个系统如何不崩、可量化、可持续运转 | 沙箱、约束执行、故障恢复、熵管理、反馈回路 |
| 模型能力 | 推理与生成的原始上限 | 参数规模、训练数据、对齐水平 |
三者的适用场景也有明显差异。简单任务里，提示词写得清楚就足够；依赖外部知识的任务里，能不能把正确的事实喂进上下文成为关键；而在长链路、可执行、低容错的真实商业场景中，Harness 才是决定成败的那一环。原因很简单：长链路意味着误差会累积，可执行意味着错误会产生真实副作用，低容错意味着一次失败可能无法回滚。
理解 Harness 最好的方式，不是列举它包含哪些模块，而是看模型天生做不到什么。模型做不到的每一件事，都是 Harness 必须补上的缺口。
1. 记住多轮对话历史
模型的单次调用是无状态的。它不会自动记得上一轮用户说了什么，也不会记得自己昨天改过哪个文件。Harness 需要维护对话历史与任务状态，在每次请求时把必要的部分重新拼进上下文。这背后是记忆系统的设计问题：哪些内容进短期窗口、哪些落盘为长期记忆、如何在 Token 预算内做取舍。
# 概念示意：请求前的上下文组装def build_request(task_state, user_input, memory_store):recent = memory_store.recent_turns(limit=8)facts = memory_store.retrieve_relevant(user_input, top_k=5)return {"system": task_state.system_prompt,"history": recent,"facts": facts,"input": user_input,}
2. 执行代码与命令
模型只能“说”要执行什么，不能真的执行。Harness 必须提供受控的执行环境：命令执行、代码运行、依赖安装，并且要在隔离的沙箱中进行，避免一次错误的删除命令影响宿主环境。执行环境还要负责超时控制、资源限额和输出截断，否则一次失控的循环就可能拖垮整个任务。
3. 获取实时信息
模型的训练数据有截止时间，它不知道某个库的最新版本，也不知道某个接口是否已经变更。Harness 通过外部工具调用、检索服务、MCP 之类的工具协议，把实时信息接入进来。这里的关键不是“能不能查”，而是“什么时候查、查回来的结果如何被信任和验证”。
4. 操作文件与环境
真实的工程任务几乎都围绕文件展开：读代码、改配置、写测试、提交变更。模型没有文件系统的概念，Harness 需要提供文件抽象与版本控制能力，让每一次修改可追踪、可对比、可回滚。版本控制在这里不只是便利，而是错误恢复的基础设施。
5. 判断自己是否做对了
这是最容易被低估的一点。模型可以声称“我已经修复了问题”，但它无法真正验证。Harness 需要构建验证闭环：在沙箱中运行测试、启动服务做冒烟检查、用浏览器自动化确认页面行为、比对预期输出与实际输出。只有验证结果回流到系统里，智能体才具备“自我纠偏”的可能。
把上述缺口工程化，Harness 大致可以拆成以下几个层次。
执行层：沙箱、命令执行器、代码运行环境。设计要点是隔离性、可重复性与可观测性。隔离性保证故障不扩散，可重复性保证同样输入得到同样环境，可观测性保证每一步都有日志与产物留存。
状态层：对话历史、任务状态机、文件系统快照、长期记忆。长链路任务的最大敌人是“熵增”——上下文越来越乱、状态越来越不一致。Harness 需要主动做状态压缩与一致性检查，而不是被动地把所有历史塞进窗口。
约束层：权限控制、操作白名单、危险命令拦截、预算与步数上限。约束不是给模型“上枷锁”，而是把不可逆操作变成可逆操作，把开放式探索限制在安全边界内。
反馈层：测试结果、静态检查、运行日志、失败原因归类。反馈回路的质量直接决定智能体能走多远。一个只会执行、不会从失败中提取信号的系统，本质上只是在重复犯错。
编排层：任务分解、子任务调度、重试策略、失败降级。真实任务往往需要多步骤协作，编排层负责把大目标拆成可验证的小步骤，并在某一步失败时决定是重试、换路径还是上报。
第一，把“可验证”作为设计起点。 在为一个任务设计 Harness 时，先问：这一步做完，怎么知道它做对了？如果答不上来，就不要急着让模型执行。验证手段先于执行手段。
第二，约束优于提示。 用提示词要求模型“不要删除重要文件”，远不如在文件系统层面禁止删除来得可靠。能用机制保证的，不要交给模型的自觉。
第三，状态要显式化。 把任务进度、已完成步骤、待确认事项写成结构化状态，而不是埋在冗长的对话历史里。显式状态让系统可恢复、可审计、可交接。
第四，为失败设计。 长链路任务中失败是常态而非异常。重试要有上限，回滚要有快照，降级要有预案。一个没有失败处理路径的 Harness，在真实场景中几乎必然崩溃。
第五，度量系统而非只度量模型。 任务成功率、平均步数、失败原因分布、人工介入率，这些系统级指标比单次生成质量更能反映智能体的实际可用性。
Harness 工程不是一个新造的时髦词，而是对一件本来就在做的事的正式命名：把模型能力工程化地转化为可靠系统。它要求开发者同时具备系统设计、环境隔离、状态管理、验证机制等多方面的工程素养。
模型会持续变强，但“模型之外的一切”不会自动变好。真正决定一个智能体能否在商业场景中稳定交付的，往往是那些不显眼的部分：一个可靠的沙箱、一条清晰的反馈回路、一套严谨的约束机制。理解了这一点，也就理解了 Harness 工程的本质——它不是模型的附属品，而是让模型能力真正落地的系统工程。