本文总结自B站up主马克的技术工作坊《Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚》：
Harness Engineering（马具工程）是近期 AI 领域出现的一个核心概念，它旨在通过构建一套系统性的支撑架构（Harness/ˈhɑːnɪs/）来约束并引导大模型（Model）。如果说 Prompt Engineering 是解决"怎么问问题"，Context Engineering 是解决"怎么给信息"，那么 Harness Engineering 则是站在系统高度，通过任务规划、自动化验证、质量评估和技术债清理等手段，将大模型转化为稳定可靠的 Agent，使其在软件开发等复杂场景中真正发挥生产力。
OpenAI官方：harness-engineering（工程技术：在智能体优先的世界中利用 Codex）
核心概念演进：三代 AI 工程范式
Prompt Engineering（提示词工程）
研究如何精准组织、优化输入提示词，清晰表达人类需求，让大模型准确理解意图并输出符合预期结果的技术。
Context Engineering（上下文工程）
研究如何管理、优化大模型接收的全部上下文信息，在上下文容量限制下，动态筛选、压缩、补充有效信息。
核心技术有： 上下文压缩、动态外部检索、信息间接披露等。
Harness Engineering （ 驾驭工程 ）
Harness 本义为马具 ：大模型如同脱缰野马，能力极强但易发散、产生幻觉、偏离任务；Harness 就是约束、驾驭、规范大模型的整套系统框架 。 Harness Engineering 是围绕大模型搭建完整、稳定、可控 Agent 系统的工程方法论；不研究模型本身，专注模型之外所有配套体系的设计、构建、优化与运维。
三代范式层级关系
| 工程范式 | 研究层级 | 核心关注点 | 范围扩张 |
|---|---|---|---|
| Prompt Engineering | 输入层 | 怎么把问题说清楚 | 仅单条提示词 |
| Context Engineering | 信息层 | 怎么给模型喂对信息 | 全上下文信息管理 |
| Harness Engineering | 系统架构层 | 怎么搭建整套运行系统 | 权限、流程、工具、调度、校验、治理全链路 |
Harness Engineering
为方便理解，将其分类成三个点：上下文管理 、验证与反馈 、技术债清理
上下文管理
早期让 Agent 了解一个项目是把项目所有规范、文档、规则全部塞进一个巨型 agent.md，每次请求都整体喂给大模型。 这种方式有两个致命问题：
- 内容越多 ，效果越差
- 文件逐步腐化，无人愿意维护
于是，最佳做法是精简主文件，把 agent.md 压缩到仅约 100 行，只做目录索引，不存放具体业务内容。然后把规范、架构、业务文档分门别类单独存放，用到哪一块，就只给 Agent 加载哪一块内容，精准投喂、避免信息过载。
像这样：
验证与反馈
Agent 拿到充足项目信息写完代码后，要解决自我校验、自动改错的问题才能保证准确率。OpenAI是这么做的，他们给 Codex 配置完备工具能力和skills，Codex就能在任务重随机验证自己的输出。
比如接入 Chrome 开发者工具，让 Agent 能自动截图、查 DOM、模拟用户操作，自主校验 UI 效果，有问题就地修复。
Agent 写完代码后，自动触发代码检查和测试；不合规则直接抛错，错误信息回流给 Agent 自动修改，反复迭代自检，直到完全符合架构和代码规范，全程无需人工参与。
技术债清理
AI Agent 大规模批量生成代码时，容易产生代码冗余、设计不规范、架构违规、命名风格不统一等问题，长期堆积会拖垮整个代码库质量。
OpenAI 的解决思路是自动化垃圾回收式治理：
- 后台常驻 Codex 定时任务，自动全量扫描代码库，识别不规范、有隐患的代码并自动修复、提交；
- 同时增设文档巡检后台任务，定期核对文档与实际代码，自动修正过时、不符的文档内容；
- 代码、文档双向常态化维护，不让问题堆积，长期稳定保持项目质量。
Harness Engineering 核心思想
OpenAI官方《工程技术：在智能体优先的世界中利用 Codex》这篇文章重新定义了人类和AI在未来的工作边界，在文章中OpenAI抛出了一个非常关键的断言：人类掌舵。智能体执行。 他们重新定义软件工程师新职责：不用再亲自逐行手写代码、查报错、跑测试，工作重心转变为 为 Agent 搭建稳定可靠的支撑系统、规则框架与 Harness 体系 ，最大化 AI 研发效率。
可见， Harness Engineering 的核心不是让 AI 单纯写代码，而是给 AI 搭建一套能稳定干活的完整运行环境与约束体系。
Anthropic的Harness Engineering实战
Anthropic围绕长运行Agent的harness设计，发布了两篇具有延续性的技术文章，形成了从"环境配置"到"架构升级"的完整探索脉络。其核心逻辑可归纳为两大模块：任务规划 与质量评估。
任务规划：从INITIALIZER到Planner的演进之路
第一篇文章中，Anthropic让Agent克隆Claude.ai（类ChatGPT聊天产品）。实验中Agent盲目执行，效果极差：一是急于完成所有功能导致上下文溢出、任务中断；二是多Agent衔接混乱，后续Agent因信息不全误判进度，最终无法达成目标。
核心问题在于缺乏有效任务规划，而harness engineering的价值就是通过机制设计，实现Agent执行过程的可控。
- 第一版方案：INITIALIZER Agent------初始化环境与需求拆解
针对上述问题，Anthropic引入INITIALIZER Agent，核心作用是初始化执行环境，规避任务混乱。
其核心职责包括拆解需求为可执行功能列表、编写启动脚本、添加进度文件，其中需求拆解是核心，能让执行Agent按功能点稳步推进，解决上下文溢出和衔接问题。
- 第二版方案：Planner Agent------专注需求拆解的专业化升级
第二篇文章中，Anthropic将INITIALIZER的需求拆解功能剥离，打造专业化Planner Agent，实现任务规划升级。Planner Agent专注于将模糊需求转化为清晰的功能列表（含要求、优先级和验收标准），与执行Agent形成专业分工，提升效率与准确性，增强harness架构适配性。
质量评估
质量评估是harness engineering的核心，需建立闭环机制确保代码产出合格。Anthropic经三次迭代，确定了高效客观的评估方案。
人工评估效率低，Agent自评存在主观滤镜、无法发现自身bug，两者均被废弃。最终方案为引入独立第三方Evaluator Agent，专门评估Generator的代码产出，评估更客观，且可单独优化训练，强化质量管控。
至此，Planner（规划）、Generator（生成）、Evaluator（评估）三大Agent形成分工体系，构成Full Harness方案。
三大Agent协同流程清晰，保障任务可控：
- Planner拆解用户需求为功能列表，发送给Generator；
- Generator选取一个功能点，与Evaluator确认交付标准，直至达成一致；
- Generator生成代码并提交评估，不合格则修改重提，直至通过；