最近在看 AI Agent 相关内容时我经常看到一个新词Harness Engineering。第一次看到它我也有点疑惑。Harness 原本有“安全带、挽具、控制装置”的意思放到大模型开发里到底指什么难道只是又换了一个名字来包装 Agent 框架真正了解之后我发现这个概念其实很实用。我们以前做大模型应用注意力往往集中在模型和 Prompt 上模型够不够强、提示词写得好不好、上下文有没有补全。但当 Agent 开始连续运行几十分钟甚至几个小时会读文件、调用工具、修改代码和操作外部系统时只优化 Prompt 已经远远不够。同一个模型、同一个任务放进不同的运行系统里表现可能完全不同。真正决定 Agent 能不能长期稳定工作的往往是模型外面的那一整套工程系统。这套系统就是 Harness。先说清楚Harness 到底是什么OpenAI 在 Agent 架构文档中将 Harness 描述为负责运行模型与工具循环、维护 Agent 会话的系统在更完整的实现中它还会管理上下文、工具路由、审批、追踪、恢复和运行状态。OpenAI 的 Codex Harness 介绍也强调一个可用的 Agent 不只是“Prompt 加模型响应”还需要持续理解任务、维护上下文、调用工具、暴露进度、处理失败并在必要时请求人工确认。Anthropic 对这个概念的解释也很接近Agent 不只有模型还包括 Harness、工具和运行环境Harness 提供模型运行时遵循的指令与约束。Anthropic 关于可信 Agent 的说明特别指出即使模型本身能力很强配置不合理的 Harness、权限过大的工具或暴露的环境仍然可能让 Agent 做出危险操作。如果用一句更容易理解的话概括模型负责思考Harness 负责让它以什么方式工作、能做什么、如何知道自己做对了以及出错以后怎么办。而Harness Engineering就是设计、实现和持续改进这套 Agent 运行系统的工程工作。这个词目前更像一种正在形成中的工程实践而不是已经有统一边界的传统岗位名称。不同团队对 Harness 的范围会略有差异但关注点基本一致不要只盯着模型要把 Agent 周围的运行环境也当成产品来建设。为什么 Prompt Engineering 已经不够了假设我们给 Agent 一个任务分析这个项目中的登录故障修复问题并提交验证结果。Prompt 写得再详细Agent 仍然需要面对一连串工程问题它从哪里找到项目架构和启动方式可以读取哪些文件能不能修改生产配置应该使用哪些命令和工具修改之前是否需要建立独立工作区如何判断故障已经成功复现修改后运行哪些测试才算通过命令失败或上下文过长时怎么恢复哪些操作可以自动执行哪些必须由人审批如何保存过程让开发者能够回看它做了什么这些都不是增加一句“请认真检查”能够解决的。Prompt 主要告诉模型“这次要做什么”Harness 则决定“整个任务怎样可靠地跑完”。Prompt、Context 和 Harness Engineering 有什么区别这三个概念容易混在一起可以这样理解。Prompt Engineering把当前指令说清楚Prompt Engineering 关注的是如何表达目标、约束、输出格式和示例让模型更准确地完成当前调用。例如要求模型只返回JSON不要补充解释缺少字段时返回null。它解决的是指令表达问题。Context Engineering把正确的信息放进上下文Context Engineering 关注模型在当前时刻能够看到什么包括系统指令、对话历史、检索文档、项目规则、工具结果和状态摘要。它不是简单地塞入更多资料而是在有限窗口中选择最相关、最新且可信的信息。Harness Engineering让整个执行系统可运行、可控制、可恢复Harness Engineering 的范围更大。它会把 Prompt 和 Context 纳入其中但还要处理Agent循环和任务生命周期工具调用与参数校验沙箱、文件系统和网络权限状态持久化与上下文压缩日志、轨迹和可观测性重试、超时、中断和恢复自动评测与验收标准人工审批和安全边界。可以把三者放在一条链路上Prompt Engineering这一句话怎么说 ↓ Context Engineering这一步让模型看到什么 ↓ Harness Engineering整个任务如何稳定运行到结束它们不是互相替代而是逐层扩大的关系。一套 Harness 通常要解决哪些问题1. 给 Agent 一张可以导航的知识地图Agent 需要项目知识但不能把所有文档一次性塞进上下文。OpenAI 在一项 Agent-first 软件开发实践中发现一个巨大的AGENTS.md很快会变得臃肿、过时并难以验证。后来他们把简短的入口文件作为“目录”再指向结构化的架构文档、设计文档、执行计划和质量说明通过渐进式加载为 Agent 提供上下文。OpenAI 的 Harness Engineering 实践将这种方式概括为给 Agent 一张地图而不是一本上千页的说明书。这背后的核心不是使用哪个文件名而是让知识具备几个特点Agent能够发现内容有明确归属规则可以版本化文档过期能够被检测需要时再加载不长期占用上下文。对于普通大模型项目也可以从一个很小的结构开始AGENTS.md # 入口和工作规则 ARCHITECTURE.md # 系统架构与模块边界 docs/ ├── product/ # 产品规则 ├── decisions/ # 关键技术决策 ├── runbooks/ # 部署和故障处理 └── plans/ # 复杂任务的执行计划2. 把工具设计成 Agent 真正能用的接口给 Agent 注册十几个工具并不代表它会正确使用。一个工具至少要有清楚的名称、输入字段、返回结构、错误信息、超时策略和权限说明。危险操作最好拆成“查看计划”和“确认执行”两个阶段而不是让模型一次调用直接产生不可逆结果。例如删除资源的工具如果只返回failedAgent 很难判断是权限不足、目标不存在还是参数错误。更好的返回结构会告诉它{ status: blocked, reason: approval_required, target: resource-123, next_action: request_human_approval }Harness 要做的不只是把函数暴露给模型还要让工具的成功、失败和下一步都对模型可理解。3. 把运行环境当成能力边界很多 Agent 任务需要真实工作区读取一组文档、执行代码、生成文件、启动服务或者保存中间产物。这时只提供 Prompt 上下文会非常脆弱。Agent需要一个能够检查和修改的环境同时这个环境又不能无限制地访问宿主机。OpenAI 的 Sandbox Agents 文档将 Harness 看作控制面将沙箱视为执行面Harness负责模型调用、工具路由、审批、追踪和运行状态沙箱负责文件、命令、依赖和端口。实际设计时需要回答工作目录是否隔离哪些文件只读哪些可以修改是否允许访问网络凭据如何按最小权限注入任务结束后保留哪些产物出现破坏性命令时由谁确认Agent能力越强环境和权限设计越不能含糊。4. 管理状态而不是无限堆积对话长任务会经历很多轮模型调用、工具结果和中间决策。如果每一步都原样塞回上下文窗口很快就会被历史记录占满。Harness需要区分不同状态当前任务目标已完成和未完成步骤工具调用结果可恢复的运行快照需要长期保留的业务数据只为调试保存的完整轨迹。上下文压缩也不是简单地把历史“总结一下”。重要约束、未解决问题和关键产物必须被保留重复日志和已经失效的中间尝试才适合压缩。5. 为失败建立反馈和恢复机制Agent失败时最没有价值的处理方式通常是原样重试。真正需要判断的是失败来自模型判断、工具参数、环境缺失、权限限制还是验收标准不清楚不同原因应该进入不同路径。工具参数错误 → 返回字段级提示让Agent修正 网络临时失败 → 有上限的退避重试 权限不足 → 请求人工批准 缺少依赖 → 在沙箱中安装或明确终止 测试失败 → 读取失败信息后重新修改 目标不明确 → 暂停并向用户提问一个好的 Harness 不会承诺“永不失败”而是让失败可以分类、可见并且能够恢复。6. 记录完整轨迹并建立评测闭环只看 Agent 最后的回答通常无法判断它为什么成功或失败。需要记录的内容包括模型调用、工具选择、工具参数、工具返回、中间状态、耗时、成本、审批和最终环境结果。Anthropic 在Agent评测实践中区分了两类 HarnessAgent Harness 负责让模型作为 Agent 运行Evaluation Harness 负责批量运行任务、记录完整轨迹、执行评分并汇总结果。评测 Agent 时实际评测的是模型和 Harness 的组合而不是孤立的模型。这句话很重要。更换模型后效果变好不一定说明原来的 Prompt 有问题同样模型没有变化但工具描述、上下文压缩或重试机制调整后任务成功率也可能明显改变。因此 Harness Engineering 最终要形成闭环发现失败案例 ↓ 还原完整执行轨迹 ↓ 定位缺少的上下文、工具或约束 ↓ 修改Harness ↓ 运行评测集 ↓ 确认修复且没有引入新回归一个研究型 Agent 的最小 HarnessHarness Engineering 不只适用于编码 Agent。以前面文章里的资料研究任务为例一套最小可用 Harness 可以包含用户目标和时间范围 ↓ 任务规划与人工确认 ↓ 只读搜索工具发现候选来源 ↓ 网页读取工具获取原始内容 ↓ Evidence工具校验并保存证据 ↓ Reviewer检查来源、覆盖度和冲突 ↓ 有上限的定向补查 ↓ Writer只使用审核后的Evidence ↓ 人工确认后交付这里的 Harness 不只是流程图还包括搜索和读取工具的调用顺序证据字段与来源要求并行写入时的锁补查次数上限Writer的工具权限每个节点的日志和状态最终报告的验收规则。模型负责在局部步骤中判断Harness负责保证它不会轻易绕过整个系统的边界。Harness Engineering 不是什么它不等于换一个 Agent 框架LangGraph、Agents SDK或其他框架可以帮助实现状态和编排但安装框架不等于完成 Harness 设计。工具契约、环境隔离、知识结构、观测和评测仍然需要自己定义。它不等于写一份很长的系统提示词无法自动验证的规则最终很容易被忽略或过时。关键约束应该尽可能进入类型、权限、测试、Lint、审批和运行时检查而不是全部依赖模型记住。它不等于追求完全无人化Harness的目标是把人工判断放在最有价值的位置而不是把人彻底移除。涉及不可逆操作、业务责任和高风险决策时人工审批本身就是Harness的一部分。它也不是模型训练微调改变的是模型本身Harness Engineering改变的是模型工作的外部系统。两者可以结合但解决的问题不同。如果现在开始做可以先做哪几件事不需要一开始就搭建庞大的Agent平台。可以从下面六件事开始定义完成标准不要只写“完成任务”明确产物、测试和验收条件。收紧工具边界让工具参数结构化危险操作默认需要审批。建立知识入口用短入口指向真实架构、规范和运行文档。保存任务状态区分对话历史、运行状态和业务数据。记录执行轨迹至少保存工具调用、错误、耗时和最终结果。建立小型评测集先固定十几个真实失败案例每次修改后重复运行。如果一项改进只存在于某个人的经验里它不会稳定复用如果能把它变成文档、工具、测试或运行规则它才真正进入了 Harness。最后Harness Engineering让我重新理解了“Agent能力”这件事。我们看到的能力不完全来自模型。模型之外的上下文、工具、环境、状态、权限、反馈和评测共同决定了Agent最终能够做什么。OpenAI 在 Harness Engineering 的实践总结中提到Agent失败时与其要求它“更努力”不如追问系统缺少了什么能力以及怎样让这项能力对Agent既可见又可执行。这也是我认为这个概念最有价值的地方。未来大模型应用开发者的工作可能不只是写Prompt和调用模型接口还要设计一套让模型能够稳定工作的“工程世界”。而这套工程世界就是Harness。