背景：长程任务的技术挑战 🍅
OpenAI 最近在公开博客里分享过一个数字：过去五个月，团队在实验过程中没有人工写过一行代码，应用逻辑、测试、调试全部交给了 Codex，整体交付周期压到了传统流程的十分之一。这不是孤例。整个行业都在把越来越复杂、跨阶段、跨会话的工程任务交给 Agent。这类长程任务动辄包含几十上百个相互依赖的子任务，横跨多轮交互和大量工具调用；在这个尺度上，Agent 会撞上四个结构性挑战。
- 首先是规划复杂度高，根子在长程任务里大量的子任务和隐式依赖。只给一个宏观目标，Agent 往往试图一口气解决太多问题，执行流程随之断裂。
- 其次是反馈信号稀疏。一个系统能被改进到什么程度，很大程度上取决于它的输出好不好验证；而 Agent 的表现通常要等任务结束才能评估，中间没有信号，它既判断不准自己的进度，也就常常提前收工。
- 第三是长执行链上的误差累积。任何一步产生的错误都会顺着后续交互传播、叠加，最后长成难以收敛的系统性缺陷。
- 最后是长期记忆缺失。Agent 在任务后半段忘掉关键背景和约束，直接导致任务失败；任务越长，这个短板越致命。
四个问题叠在一起，Agent 在长程任务里就极容易弄丢自己的执行状态。
Harness 工程应运而生 🍅
针对这些挑战，OpenAI 等机构提出了 Harness 工程的概念。这个名字的比喻很贴切：AI Agent 像一匹动力十足但容易跑偏的马，harness 就是那套让它跑得快又不失方向的缰绳和马鞍。Harness 工程做的事，是用工程视角去设计任务环境本身：把执行环境结构化，把目标定义清楚，把反馈回路建扎实，让 Agent 在一套明确的规则框架里稳定产出可靠的代码。这里的前提值得说破：可靠性被当作环境的属性来经营，而不是模型的属性。
概念对比 🍅
要看清这次转移，可以把它和大家熟悉的提示词工程、上下文工程放在一起：
| 概念 | 时间阶段 | 本质问题 | 设计对象 | 典型组成 |
|---|
| Prompt 工程 | 2023–2024 | “怎么跟 AI 说话？” | 单次输入提示词 | 提示词文本本身（指令、示例、格式约束） |
| Context 工程 | 2025 | “给 AI 看什么信息？” | 整体信息上下文 | 系统提示词、对话历史、长期记忆、RAG 检索结果、工具调用输出 |
| Harness 工程 | 2026 | “给 AI 提供什么环境，才能保证产出可靠？” | 模型外的执行与控制环境 | 任务编排器、验证器、评估器、回溯机制、工具沙箱、流程控制逻辑 |
这条演进线讲的是同一个故事：随着对 Agent 能力的信心增强，交给它的任务从低维琐事一路升到架构级工程；与此同时，约束和引导 Agent 行为的机制反而成了真正要紧的事。
上下文工程的盲区在于把 context 当静态资源。长程任务里的 context 不可能一次给足、终身受用，它是跟着执行一起演化的。用户给出一个宏大而欠规格的目标之后，随着 Agent 尝试不同路径、切换执行方向，初始 context 的价值不断稀释，留下一堆断裂和过时的信息，恰恰在 Agent 最需要的时候拖垮检索。
Harness 工程补的就是这个缺口：在模型外面加上结构化的引导与验证机制，让 Agent 的状态在整个执行过程里可靠地延续。从这个意义上说，它补上了当前 Agent 系统设计里缺失的一层。
可观测性是 Harness 工程的核心 🍅
多步执行链上，一次错误的规划会让后面每一步都在错误前提上前进；一个没校验过的工具返回能污染全局状态；一段被误读的上下文能改写整个任务的走向。如果系统不能在每个关键节点确认假设还成立、输出还满足约束、状态还一致，不确定性就会复利式放大，链条越深越失控。
所以 Harness 工程的核心动作，是把断言、边界、回滚机制直接嵌进执行环境，让 Agent 的每一步输出都接受结构化校验，把它的工作从不可观测的黑盒变成一个完全可观测的系统。可观测性在这里不是锦上添花的诊断层，它就是压住误差复利的那个机制本身。
 |
|---|
| OpenAI 对可观测性工具的改进 |
Harness 工程要求清晰的需求、明确的约束、持续的反馈 🍅
Harness 工程的核心范式可以概括成三件事：清晰的需求、明确的约束、持续的反馈。
需求必须结构化表达：目标、边界条件、成功标准。比如给 Agent 一份定义清楚的 markdown 规格，让它全程有据可查，而不是从一句含糊的 prompt 里自行脑补。
约束要长在执行环境里，忘不掉，也绕不开。比如强制的单步执行规则、必须通过的约束检查。
反馈必须可观测、可验证，靠测试、日志、版本控制形成闭环。比如在任务中段强制进入验证循环，而不是只在最后验一次。
底层的赌注是：Harness 工程不指望模型变得更聪明，而是用工程结构，让一个智能水平固定的模型在明确目标和受控边界内稳定产出可靠结果。业界如今各式各样的差异化打法，归根到底都是在这三个维度上做加固。
下表是几种代表性探索的结构化梳理：
| 公司 | 典型场景 | 核心问题 | Harness 策略 | 关键机制 | 本质思想 |
|---|
| OpenAI | 维护 100 万行代码的 Agent 系统 | 信息量远超 context window，导致注意力涣散 | 渐进式披露（Progressive Disclosure） | 仅提供 AGENTS.md（~100 行）作为稳定入口；按需通过工具检索详细代码；避免一次性加载整个 codebase | 不压缩信息，而是控制披露 |
| Anthropic | Claude 连续数天构建完整 Web 应用 | 多会话任务导致“失忆”，状态断裂 | 外部化状态管理 | 两阶段系统：Initializer Agent 构建记忆基础设施（init.sh、功能需求文件、progress 文件、初始 git 提交）；Coding Agent 每轮严格流程：读取状态→做一件事→端到端验证→git 记录 | 将记忆外置为文件系统与版本控制，而非依赖模型内部记忆 |
| LangChain | Terminal Bench 2.0 代码任务 | Agent 不会主动验证自己 | 强制验证循环（Forced Verification Loop） | 写代码后必须运行测试；失败则回溯修复 | 将验证从可选行为变为强制结构 |
| Hightouch | 通用营销 Agent 分析 1000 客户行为 | 单 Agent context 无法容纳复杂中间过程 | 动态子 Agent（Dynamic Sub-Agents） | 规划与执行分离（make_plan / update_plan）；文件缓冲（write_file）；生成独立子 Agent 并行处理；扇出模式调用小模型 | 不压缩 context，而是分层隔离 context |
一个数据点能把这件事说得很实。同样是 GPT-5.2-Codex，LangChain 的 deepagent-cli 只靠 harness 策略，就把 Terminal Bench 2.0 的分数从 52.8% 拉到 66.5%。模型没换，变的只是包在它外面的结构。这个差距说明，Agent 的性能瓶颈未必在模型能力上，它完全可能出在执行结构的设计上；而后者是便宜得多的下手处。
对 Agent 平台的启发 🍅
技术启示一：构建任务级 Execution Harness，让 Agent 在结构里执行
引入任务状态机作为执行骨架。 把多步任务定义成显式的状态流（规划 → 执行 → 校验 → 修正 → 汇总），每个状态绑定专属的工具集合和上下文范围。按状态圈定上下文，能挡住跨阶段的信息污染；每次状态转移都有明确的输入、输出和验收条件。
为工具调用结果建一层验证。 给关键工具的输出定义结构化断言，校验失败自动触发重试或回退，并在执行链里立一条 fail-fast 的硬约束。要点是让中间结果始终可验证、可回滚：错误在产生它的那一步就被摁住，而不是等它在任务末端连环爆炸。
技术启示二：建立全链路可观测与反馈闭环，让 Agent 行为可诊断
构建 Agent 执行轨迹系统。 记录每一步的上下文摘要、模型决策理由和工具输出，拼成一张可回放的执行图。没有回放，每次故障排查都从零开始；有了它，系统优化和策略改进才有立足之地。
引入自动化的失败归因。 把任务失败按执行阶段分类，建一座缺陷模式库（规划失误、信息缺失、校验失败、工具异常）。改进从此变成数据驱动的闭环：开发者从可度量的信号里找系统瓶颈，而不是靠轶事和玄学。
结语 🍅
AI Agent 的势头还在涨。它们像一匹匹动力惊人的马，能力越大，越容易跑偏。Harness 工程给的是那副结构化的缰绳：不是为了让马慢下来，而是让它的速度都积累在同一个方向上，跑得快，同时始终对准目标。
Background: Technical Challenges of Long-Horizon Tasks 🍅
In a recent public blog post, OpenAI shared that over the past five months their team did not manually write a single line of code during experimentation; logic configuration, testing, and debugging were delegated entirely to Codex, cutting overall product delivery time to roughly one-tenth of the traditional workflow. This is not an isolated case. Across the industry, increasingly complex engineering work spanning multiple stages and sessions is being handed to AI agents. These long-horizon tasks often involve dozens or hundreds of interdependent subtasks across many rounds of interaction and tool invocations, and at that scale, agents run into four structural challenges.
- High planning complexity comes first, and it stems from the sheer number of subtasks and the implicit dependencies among them. Given only a high-level objective, agents tend to attack too many problems at once, and the execution flow fractures.
- The second challenge is sparse feedback signals. The ability to improve a system is proportional to how easily you can verify its output, but an agent’s performance is typically evaluated only after the task completes. With no intermediate signal, the agent cannot accurately judge its own progress, and premature termination becomes a common failure mode.
- The third is error accumulation in long execution chains. An error introduced at any step propagates and compounds through subsequent interactions, eventually producing systemic defects that are hard to converge away from.
- Finally, the lack of long-term memory undermines the whole enterprise: agents forget background information and constraints in later stages, and the problem grows strictly worse as the task horizon lengthens.
Compounded together, these four make agents highly prone to losing track of their own execution state in long-horizon tasks.
Harness Engineering Emerges for the Need 🍅
To address these challenges, organizations such as OpenAI have proposed the concept of Harness Engineering. The name earns its metaphor: an AI agent resembles a powerful but easily wayward horse, and the harness supplies the reins and saddle that let it run fast without losing direction. Harness engineering means designing the task environment itself from an engineering perspective: structuring the execution environment, defining clear objectives, and establishing robust feedback loops so that agents operate inside a well-defined framework of rules and consistently produce reliable code. The premise is worth stating plainly: reliability is treated as a property of the environment, not of the model.
Concept Comparison 🍅
To see what shifted, it helps to place harness engineering next to the two paradigms the community already knows: Prompt Engineering and Context Engineering.
| Concept | Time Period | Core Question | Design Target | Typical Components |
|---|
| Prompt Engineering | 2023–2024 | “How should we talk to the AI?” | Single prompt input | Prompt text itself (instructions, examples, formatting constraints) |
| Context Engineering | 2025 | “What information should the AI see?” | The overall information context | System prompts, conversation history, long-term memory, RAG retrieval results, tool outputs |
| Harness Engineering | 2026 | “What environment should we provide so that AI outputs remain reliable?” | Execution and control environment outside the model | Task orchestrators, validators, evaluators, rollback mechanisms, tool sandboxes, workflow control logic |
The progression tells a consistent story. As confidence in agent capability has grown, the tasks delegated to agents have climbed from low-dimensional routine operations to architectural and engineering work, and in parallel, the mechanisms for constraining and guiding agent behavior have become the binding concern.
Context engineering’s blind spot is that it treats context as a static resource. In long-horizon tasks, context cannot be provided once and remain sufficient; it evolves alongside execution. When a user supplies a high-level but underspecified objective, the initial context loses relevance as the agent explores approaches and shifts execution paths, leaving behind fragmented or outdated information that degrades retrieval exactly when the agent needs it most.
Harness engineering fills this gap by adding structured guidance and verification mechanisms around the model, so that agent state persists reliably through the entire execution process. In that sense it supplies a layer that current agent system design has been missing.
Observability as the Core of Harness Engineering 🍅
In a multi-step execution chain, a single incorrect plan sends every subsequent step forward under false assumptions. One unchecked tool response can contaminate global state; one misread piece of context can redirect the entire task. Unless the system can verify, at each critical point, that assumptions still hold, outputs satisfy constraints, and state remains consistent, uncertainty compounds, not linearly, but with the depth of the chain.
This is why the central move of harness engineering is to embed assertions, boundaries, and rollback mechanisms directly into the execution environment. Every step of the agent’s output becomes subject to structured validation, converting the agent’s work from an opaque black box into a fully observable system. Observability is not a nice-to-have diagnostic layer here; it is the mechanism that keeps compounding error in check.
|
|---|
| Improvements to observability tools introduced by OpenAI |
Harness Engineering Calls for Clear Requirements, Explicit Constraints, and Continuous Feedback 🍅
The core paradigm of harness engineering can be summarized in three commitments: clear requirements, explicit constraints, and continuous feedback.
Requirements must be expressed in a structured form (objectives, boundary conditions, and success criteria), for example well-defined markdown specifications the agent can reference throughout the task rather than reconstruct from a vague prompt.
Constraints should live in the execution environment itself, where they cannot be forgotten or reasoned around, for example enforced step-by-step execution rules or mandatory constraint checks.
Feedback must be observable and verifiable, closing the loop through testing, logging, and version control, for example validation cycles enforced at intermediate stages instead of a single check at the end.
The essential bet is that harness engineering does not rely on the model getting smarter. It uses engineering structure to make a fixed level of model intelligence produce reliable output within clearly defined goals and controlled boundaries. Most of the differentiated strategies now emerging across the industry are, at bottom, different ways of strengthening these same three dimensions.
The following table gives a structured overview of several representative industry explorations.
| Company | Representative Scenario | Core Problem | Harness Strategy | Key Mechanism | Underlying Idea |
|---|
| OpenAI | Agent systems maintaining million-line codebases | Information far exceeds the context window, leading to diluted attention | Progressive Disclosure | Provide only an AGENTS.md (~100 lines) as a stable entry point; retrieve detailed code through tools on demand instead of loading the entire codebase at once | Do not compress information, but control its disclosure |
| Anthropic | Claude building a complete web application over multiple days | Multi-session tasks cause “memory loss” and state fragmentation | Externalized State Management | Two-stage system: an Initializer Agent builds the memory infrastructure (init.sh, feature requirement files, progress files, initial git commit); a Coding Agent follows a strict loop each round: read state → perform one task → end-to-end validation → record in git | Externalize memory into the filesystem and version control rather than relying on the model’s internal memory |
| LangChain | Terminal Bench 2.0 code tasks | Agents do not naturally verify their own work | Forced Verification Loop | After writing code, the agent must run tests; failures trigger rollback and repair | Turn verification from an optional behavior into a mandatory structure |
| Hightouch | Marketing agents analyzing behavior of 1000 customers | A single agent’s context cannot hold complex intermediate processes | Dynamic Sub-Agents | Separation of planning and execution (make_plan / update_plan); file buffers (write_file); generation of independent sub-agents for parallel processing; fan-out calls to smaller models | Do not compress context, but separate it hierarchically |
One data point makes the case concrete. Under the same model setting (GPT-5.2-Codex), LangChain’s deepagent-cli lifts its Terminal Bench 2.0 score from 52.8% to 66.5% through harness strategies alone. The model did not change; the structure around it did. That gap suggests the performance bottleneck of agents does not necessarily sit in model capability; it can sit in the design of the execution structure, which is a far cheaper place to fix it.
The harness engineering paradigm offers concrete guidance for improving the long-horizon execution capability and reliability of the agent platform.
Technical Insight 1: Build a Task-Level Execution Harness to Structure Agent Execution
Introduce a task state machine as the execution backbone. Define multi-step tasks as explicit state flows (e.g., plan → execute → verify → refine → summarize), with each state binding a specific tool set and context scope. Scoping context per state prevents cross-stage information pollution, and each transition carries clear inputs, outputs, and acceptance criteria.
Introduce a validation layer for tool invocation results. Define structured assertions for critical tool outputs so that failed checks automatically trigger retries or rollbacks, with a fail-fast constraint in the execution chain. The point is to keep intermediate results verifiable and reversible, catching an error at the step that produced it, before it propagates across the task.
Technical Insight 2: Establish End-to-End Observability and Feedback Loops to Enable Diagnosable Agent Behavior
Build an agent execution trace system. Record context summaries, model decision rationales, and tool outputs at each step to form a replayable execution graph. Without replayability, every failure investigation starts from zero; with it, system optimization and strategy improvement have something to stand on.
Introduce automated failure attribution. Classify task failures by execution stage to build a defect pattern library (planning errors, missing information, validation failures, tool exceptions). This turns improvement into a data-driven loop: developers identify system bottlenecks from measurable signals instead of anecdotes.
Conclusion 🍅
The momentum behind AI agents keeps building. Like powerful but wayward horses, they carry immense capability and drift off course just as easily. Harness engineering supplies the structural reins, not to slow the horse down, but to make sure its speed accumulates in one direction, keeping agents fast and aligned with the objective at the same time.
