Harness Engineering：从 Prompt、Context 到 Agent 系统工程什么是 `Harnes

Harness Engineering：从 Prompt、Context 到 Agent 系统工程

一篇面向技术团队、产品负责人和 AI 工程实践者的分析文档

摘要

2025 年底到 2026 年初，AI 工程领域出现了一个明显的叙事转向：讨论重心开始从 Prompt Engineering 迁移到 Context Engineering，并进一步升级到 Harness Engineering。这不是术语包装，而是工程重心的真实迁移。随着模型持续工作时长、工具使用能力、长任务完成度与代码生成吞吐量大幅提升，团队逐渐发现：决定 agent 上限的，不再只是模型质量，也不只是提示词质量，而是包裹模型的整套执行系统。

Harness Engineering 关心的是如何为模型搭建一层“可执行、可验证、可恢复、可治理”的工作环境。它包括上下文组织、工具暴露、任务编排、评估机制、错误恢复、权限隔离、可观测性与持续优化。Anthropic、OpenAI、Google DeepMind 与 Vercel 在 2025-2026 年间分别给出了代表性案例，说明这一方向正在从技巧升级为方法论。

本文将系统解释：

什么是 Harness Engineering
为什么用“马具”作为核心隐喻
Prompt -> Context -> Harness 三层能力如何逐步演进
为什么该概念会在 2025 年底到 2026 年初快速爆发
Anthropic、OpenAI、Google DeepMind、Vercel 的关键实践分别说明了什么
Harness Engineering 的六大核心模块是什么
这一方向当前面临的风险、争议与工程挑战有哪些

一、什么是 Harness Engineering

如果用一句话定义：

可以把 Harness Engineering 理解为：围绕大模型构建一整套可执行、可验证、可恢复、可扩展的任务系统，让模型从“会回答”进一步走向“能可靠做事”。

它关注的不只是提示词，也不只是上下文，而是更外层的一整套工程系统：

任务如何被拆解和规划
上下文如何被组织和裁剪
工具如何被暴露给模型
模型如何在多轮循环中持续工作
结果如何被独立评估和打回修改
失败时如何恢复
权限如何隔离
系统如何随着模型升级而持续简化或重构

换句话说，Harness Engineering 关注的重点不是单纯提升模型本身，而是把模型能力稳定地接入真实工作流。

图 1：从回答问题到执行任务

flowchart LR
    A[Prompt Engineering\n优化一句话怎么说] --> B[Context Engineering\n优化给模型什么信息]
    B --> C[Harness Engineering\n优化整个任务执行系统]
    C --> D[可靠 Agent\n可规划 可执行 可验证 可恢复]

二、为什么用“马具”做隐喻

“Harness”原义是马具、挽具。这个隐喻之所以贴切，是因为它强调的不是动物本身有多强，而是如何把原始力量转化为可控、可复用、可输出的工程能力。

在 AI 语境中，这个隐喻有四层意思：

1. 模型有能力，但默认状态并不适合长流程生产

一匹马再强，如果没有马具，就很难稳定拉动车辆。一个模型再强，如果没有外层系统，往往也只能做单轮生成，而难以完成跨多轮、多工具、长时段的任务。

2. Harness 既是放大器，也是约束器

马具不是只让马“更快”，它还负责引导方向、控制节奏、连接载荷。对应到 AI 系统里，harness 既放大模型能力，也限制模型乱跑。

3. 真正的产出来自“能力接入系统”而不是“能力孤立存在”

工程世界里，真正有价值的不是模型会不会写一段代码，而是模型能不能在真实仓库、真实工具链、真实 QA、真实部署条件下完成任务。

4. 马更强时，马具也要重配

Anthropic 在 2026 年关于 Managed Agents 的文章里强调过：harness 本质上编码了“模型目前做不到什么”的假设，而这些假设会随着模型变强快速过时。也就是说，模型升级往往不只是替换引擎，也会连带要求重构外层控制系统。

三、Prompt、Context、Harness 三层能力如何一步步演进

这三层能力不是彼此替代，而是逐层外扩。

3.1 Prompt Engineering：优化“怎么说”

最早的重点是写好提示词，目标是让模型在单轮任务里输出更好的结果。核心关注点是：

指令是否清晰
示例是否充分
输出格式是否被约束
提示顺序是否影响结果

这一阶段适用于：

分类
摘要
改写
单轮问答
简单代码生成

但一旦任务进入多轮循环，单一 prompt 开始显得脆弱。

3.2 Context Engineering：优化“给它什么信息”

到了 2025 年，行业发现问题不只是“怎么说”，而是“给模型哪些信息”。Anthropic 将 Context Engineering 定义为：

在推理过程中持续策划和维护最优 token 集合，以最大化目标行为出现的概率。

这时重点变成：

系统提示、工具描述、消息历史如何组合
什么时候检索，什么时候压缩
什么信息进入上下文，什么进入外部记忆
如何避免 context rot
如何做 just-in-time retrieval
如何使用 note-taking、compaction、多 agent 绕开上下文极限

这是一种从“写句子”到“管工作记忆”的迁移。

3.3 Harness Engineering：优化“给它什么系统”

再往外一层，团队又发现：就算上下文组织得不错，agent 仍然会失败。失败原因包括：

自评偏乐观
工具选择混乱
长任务逐步失焦
出错后不能恢复
状态与权限难以隔离
验证环节不够独立

于是工程问题继续上移：重点不再只是优化一段 prompt 或一份上下文，而是开始设计完整的任务执行系统。

图 2：三层能力的演进关系

flowchart TB
    subgraph L1[Prompt Engineering]
        P1[写出更好的指令]
        P2[优化单轮输出]
    end

    subgraph L2[Context Engineering]
        C1[管理系统提示]
        C2[管理工具定义]
        C3[管理检索 记忆 历史消息]
    end

    subgraph L3[Harness Engineering]
        H1[规划与编排]
        H2[多 Agent 拓扑]
        H3[独立评估]
        H4[恢复与治理]
        H5[权限与安全]
    end

    P1 --> C1
    P2 --> C2
    C1 --> H1
    C2 --> H2
    C3 --> H3

如果再压缩一点，这三层差别可以概括为：

Prompt：优化一次回答
Context：优化一段会话
Harness：优化整个代理生命周期

四、为什么这个概念会在 2025 年底到 2026 年初快速爆发

这一轮爆发，本质上是供给、基础设施与工程认知三者同时成熟。

4.1 模型能力跨过了“值得搭系统”的门槛

当 2025-2026 年的新一代模型开始支持更长时间的自主工作、更复杂的工具调用和更强的代码与研究能力时，团队第一次系统性地面对“长时自治”问题。模型已经强到值得投入额外工程去包裹它，但又还没强到可以脱离外层系统稳定运行，因此 harness 成为关键中间层。

4.2 工具基础设施成熟了

2025 年之后，MCP、browser automation、sandbox、文件系统代理、可恢复 session、structured memory、多 agent orchestration 等基础设施快速成熟。此前很多设计只是 demo，如今已经能进入生产试验。

4.3 瓶颈从生成能力转移到了可靠性能力

团队逐渐意识到，系统上线时真正的瓶颈常常不是“生成不出来”，而是：

评估不稳定
工具误用
长流程漂移
安全边界薄弱
出错后无法恢复

也就是说，真正拖后腿的不是智能本身，而是工程系统。

4.4 一线案例形成了强示范效应

几个公开案例让这个概念快速被行业理解：

Anthropic 公开了三 agent 长时应用构建 harness
OpenAI 公开了“0 手写代码”的百万行代码产品实验
DeepMind 公开了 Aletheia 的 generate-verify-revise 研究循环
Vercel 公开了“砍掉 80% 工具反而更强”的经验

这些案例共同说明，模型外层系统的设计，已经开始成为一线性能差异的重要来源。

图 3：2025-2026 爆发的四个驱动因素

mindmap
  root((Harness Engineering 爆发))
    模型跨门槛
      长时任务可行
      工具调用更稳
      代码与研究能力增强
    基础设施成熟
      MCP
      Sandbox
      Browser Automation
      Durable Session
    可靠性成主瓶颈
      自评偏乐观
      上下文漂移
      权限与恢复问题
    头部案例验证
      Anthropic
      OpenAI
      DeepMind
      Vercel

五、Anthropic 的三 Agent 架构与“生成-评估分离”

Anthropic 在 2026 年的长时应用构建实践中提出了一个非常有代表性的三 agent 架构：

Planner
Generator
Evaluator

5.1 Planner：把模糊输入扩写成产品规格

用户只需要给出 1-4 句需求，Planner 就把它扩展成完整产品规格。Anthropic 特别强调：规划阶段应聚焦交付目标、产品上下文与高层技术方向，而不要过早写死所有细节实现，否则错误会级联传导到后续步骤。

5.2 Generator：负责按阶段构建应用

Generator 更像一个持续推进任务的开发执行者，负责逐步实现功能、维护仓库状态，并通过工具操作应用与代码库。

5.3 Evaluator：独立测试、质疑、打回

Evaluator 使用 Playwright 等工具，像用户一样点击、检查、验证应用的 UI、API 与数据库状态，并根据预先定义的评分标准评估产出。

5.4 核心思想：生成-评估分离

Anthropic 这篇文章中最重要的思想，不是“三个 agent”这个数字，而是：

让执行者和评估者分离。

原因很简单：模型在自评时会系统性偏乐观。它可以发现问题，却又倾向于说服自己“问题不大”。尤其在设计、美学、交互、完整性这类非纯二元任务中，这个问题更严重。

Anthropic 借鉴 GAN 的思路，把：

Generator 视为创作端
Evaluator 视为怀疑端

通过评分标准、详细反馈与多轮迭代把系统往更高质量推进。

图 4：Anthropic 的 Planner-Generator-Evaluator 闭环

flowchart LR
    U[用户简短需求] --> P[Planner\n扩写成产品规格]
    P --> G[Generator\n实现功能与修改代码]
    G --> E[Evaluator\n通过工具独立验证]
    E -- 通过 --> R[输出结果]
    E -- 不通过 --> G

5.5 这一实践给行业的启发

Anthropic 的实践至少说明了三件事：

多 agent 不是为了“听起来高级”，而是为了分离职责
评价标准必须显式化，否则 evaluator 也会变成“凭感觉”
harness 不是固定结构，模型升级后要持续删减旧 scaffold

六、OpenAI 百万行代码任务背后的三大核心支柱

OpenAI 在 2026 年公开了一项颇具代表性的实验：在一个内部 beta 产品中，代码、测试、CI、文档、内部工具以及可观测性配置几乎都由 Codex 生成。他们估计，这一产品以约手写代码十分之一的时间完成，并逐步形成了约百万行规模的代码库。

这里有一个容易被误读的点需要校准：

原文最早阶段是 3 名工程师驱动 Codex
随着实践成熟，团队增长到 7 人
所以更准确的描述应是：一个起初由 3 人驱动、随后扩展到 7 人的团队，在 agent-first 流程中完成了一个百万行规模的产品实验

6.1 第一根支柱：把仓库变成 agent 的系统事实源

OpenAI 最重要的实践不是“让 agent 多写代码”，而是把仓库做成 agent 可读、可用、可持续更新的知识地图。

他们明确反对“一份超大的 AGENTS.md”，而采用：

短 AGENTS 作为目录入口
docs/ 作为系统事实源
设计文档、规格文档、执行计划、技术债跟踪共同版本化

换一种说法，这种做法更像是在给 agent 一张可更新的地图，而不是塞给它一本冗长而静态的手册。

6.2 第二根支柱：把架构与品味编码成机械约束

OpenAI 强调，agent 高吞吐量下最怕的是熵增。为了避免代码库快速退化，他们把大量规范编码进：

自定义 lint
结构测试
依赖方向约束
类型与 schema 约束
命名规则
质量文档与垃圾回收流程

这说明 agent-first 开发并不是“少做工程”，而是把原本依赖人工 review 的工程约束，进一步转写为可执行的机械规则。

6.3 第三根支柱：把反馈循环工程化

OpenAI 对人和 agent 的分工非常明确：

人负责目标、优先级、验收标准
agent 负责生成、测试、提 PR、改反馈、再提交
review 尽量 agent-to-agent
人类判断通过文档与工具沉淀为下一轮系统能力

换句话说，真正形成飞轮的并不是“自动生成代码”这一件事，而是自动生成、自动验证、自动吸收反馈，再把经验持续沉淀为规则。

图 5：OpenAI 式 agent-first 开发飞轮

flowchart TB
    A[人类给出目标与验收标准] --> B[Agent 生成实现]
    B --> C[Agent 本地测试与验证]
    C --> D[Agent 发起 PR]
    D --> E[Agent Review / Human Review]
    E --> F[反馈沉淀为文档 规则 工具]
    F --> G[下次 Agent 获得更强环境]
    G --> B

七、Google DeepMind Aletheia 的 Generator-Verifier-Reviser 循环

相比 coding harness，DeepMind 的 Aletheia 更偏向 research harness，但两者在核心思路上是一致的：重点不只是生成答案，而是建立生成、验证、修订的迭代系统。

7.1 Aletheia 的核心循环

DeepMind 对外公开的表述中，Aletheia 是一个数学研究 agent，核心包含：

候选解法生成
自然语言 verifier 检查缺陷
根据 verifier 反馈继续修订

也就是一个典型的：

Generator -> Verifier -> Reviser

循环。

7.2 为什么 verifier 特别重要

在研究级任务里，单次输出错一点就可能全盘无效。Aletheia 的 verifier 不只是“帮忙挑错”，而是在流程层面确保系统不会轻易把有漏洞的论证包装成结果。

7.3 一个重要的工程特征：允许承认失败

DeepMind 特别强调，Aletheia 可以承认“没有找到解”。这一点很关键。一个可靠系统不应被迫在任何情况下都输出一个貌似完整的答案。对于高价值任务，诚实地暴露失败，往往比高置信地给出错误结果更有价值。

图 6：Aletheia 的研究级推理闭环

flowchart LR
    Q[研究问题] --> G[Generator\n提出候选思路]
    G --> V[Verifier\n检查逻辑漏洞与引用问题]
    V -- 发现问题 --> R[Reviser\n修补或重写方案]
    R --> V
    V -- 通过 --> O[可提交结果]
    V -- 无法通过且达到上限 --> N[承认失败 / 暂无解]

八、Vercel 为什么提出“砍掉 80% 工具反而更好”

Vercel 在其内部 text-to-SQL agent d0 上给出了一个很有代表性的反直觉案例。

他们最初构建了一个复杂工具栈：

schema lookup
query validation
error recovery
多种专用分析工具
重提示和重上下文管理

后来他们把大部分工具删除，只保留极小集合，核心变成：

让模型直接读文件系统中的语义层
用 bash 和通用文件工具自行探索

结果反而变好：

成功率从 80% 提升到 100%
平均执行时间从 274.8s 降到 77.4s
token 使用下降 37%
步数下降 42%

8.1 这不是“反工具”，而是“反过度替模型思考”

Vercel 的核心结论不是“工具越少越神”，而是：

过多工具会制造选择分歧
过多中间抽象会掩盖原始信息
过多 guardrail 可能把模型困在错误的工作方式里

如果底层语义层本身已经清晰、结构化、命名良好，那么让模型直接读取原始材料，往往会比额外包一层人工摘要更有效。

8.2 对 Harness Engineering 的启发

Vercel 这个案例说明，harness 设计的重点不在于不断叠加工具和约束，而在于围绕真实失败模式控制复杂度。很多时候，能否主动删减不再必要的 scaffold，本身就是系统设计能力的一部分。

随着模型能力增强，很多旧时代为“保护模型”而建立的 scaffolding，可能会在新模型面前变成阻碍。

九、从案例到方法论：Harness 设计的八条核心经验

前面的 Anthropic、OpenAI、DeepMind 与 Vercel 案例，虽然场景不同，但在 harness 设计上其实逐渐收敛出一组共同原则。相比把 harness 理解成某种固定架构，更准确的方式是把它理解为一套持续演化的设计经验。

图 7：Harness 设计八大核心经验

flowchart TB
    H((Harness\n核心经验))

    A[分离关注点\n生成与评估分离\n不同智能体承担]
    B[迭代优于完美\n从 V1 到 V2\n持续简化架构]
    C[可控随机性\n允许模型探索\n涌现创造性方案]
    D[评估器校准\n人工标定评分错点\n防止评分通胀]
    E[模型即基础设施\n模型进化时\n简化 Harness]
    F[上下文管理\n定期重置 / 压缩\n避免窗口耗尽]
    G[Sprint 合约\n预设验收标准\n约束生成边界]
    I[对抗性评估\nGAN 式生成-评估\n消除自我偏差]

    H --- A
    H --- B
    H --- C
    H --- D
    H --- E
    H --- F
    H --- G
    H --- I

这张图概括了当前较有代表性的八条经验：

9.1 分离关注点

生成、评估、路由、治理不应混成一个 agent 的单一职责。不同智能体或不同环节分别承担不同任务，往往比“一个超级 agent 包办一切”更稳定。

9.2 对抗性评估

GAN 式“生成-评估”分离的价值，在于尽量消除模型自评偏乐观的问题。尤其在设计、交互、研究与复杂业务流程中，独立 evaluator 往往是质量明显提升的重要条件。

9.3 Sprint 合约

在执行前先约定验收标准，可以显著减少“边做边漂移”。它本质上是在执行前显式收缩目标边界，让 generator、evaluator 与人类对“什么叫完成”达成一致。

9.4 上下文管理

长时任务不只是“上下文越长越好”。定期重置、压缩、外置状态和结构化交接，通常比把所有历史一直塞进窗口更可靠。

9.5 模型即基础设施

harness 不应被视为与模型无关的固定外壳。模型能力升级后，很多原本必要的 scaffold 会迅速过时，因此 harness 本身也必须跟着模型一起重构。

9.6 迭代优于完美

现实中的 harness 往往不是一次设计完成，而是从 v1 到 v2 逐步收敛。最有效的方法通常不是一开始就做复杂，而是在运行中根据真实失败模式逐步加减结构。

9.7 可控随机性

允许模型探索，并不等于放任系统失控。好的 harness 会在“允许创造性搜索”与“防止结果失真”之间找到平衡，既不过度钳制，也不过度放任。

9.8 评估器校准

评估器本身也会漂移和膨胀，因此需要用人工标注、显式 rubric 与回归校准来约束 evaluator。否则系统只是在把不可靠判断从 generator 转移到 judge。

这八条经验最终都指向同一个判断：harness 的价值不在于不断增加包裹层，而在于把复杂任务拆成更可验证、更可治理、也更便于迭代的系统。

如果说这八条经验回答的是“harness 设计时应遵循哪些原则”，那么接下来六大核心模块回答的就是“这些原则在系统里分别落到哪些层”。前者更偏方法论，后者更偏架构抽象；两者不是重复关系，而是“设计原则”与“系统分层”的对应关系。

十、Harness Engineering 的六大核心模块

综合 Anthropic、OpenAI、DeepMind 和 Vercel 的实践，可以把 Harness Engineering 抽象为六个核心模块。

10.1 意图建模与规划层

负责把人类的模糊需求转化成：

产品规格
分阶段目标
验收标准
执行计划

10.2 上下文与记忆层

负责管理：

系统提示
工具说明
历史消息
外部记忆
文档索引
just-in-time retrieval

10.3 工具与执行环境层

负责定义：

agent 能用哪些工具
工具边界是否清晰
sandbox 如何隔离
文件系统、浏览器、数据库如何暴露

10.4 编排与多 agent 拓扑层

决定系统是：

单 agent
orchestrator-worker
planner-generator-evaluator
many brains / many hands

10.5 评估与反馈闭环层

负责：

端到端验证
LLM-as-judge
独立 critic agent
regression eval
bug 打回与修复

10.6 治理、安全与运维层

负责：

权限隔离
凭证保护
durable session
失败恢复
tracing 与 observability
成本与延迟控制

图 8：Harness Engineering 六层模块

flowchart TB
    M1[1. 意图建模与规划]
    M2[2. 上下文与记忆]
    M3[3. 工具与执行环境]
    M4[4. 编排与 Agent 拓扑]
    M5[5. 评估与反馈闭环]
    M6[6. 治理 安全 运维]

    M1 --> M4
    M2 --> M4
    M3 --> M4
    M4 --> M5
    M5 --> M2
    M6 --> M3
    M6 --> M4
    M6 --> M5

十一、这一方向当前面临的风险、争议与工程挑战

Harness Engineering 正在迅速成为主流实践，但它仍处于快速试错阶段，至少存在以下八类问题。

11.1 经验外推风险

很多成功案例建立在：

特定模型
特定任务
特定工具链
特定组织流程

之上。一个在内部 coding task 有效的 harness，不一定能迁移到 research、customer ops 或 business workflows。

11.2 Harness 过拟合风险

团队可能不是提升了真实能力，而是对某一类 eval、某一个模型版本、某一种仓库结构做了过拟合。模型一升级，旧 harness 可能就迅速失效。

11.3 LLM 评估仍有盲点

“让 LLM 评估 LLM”比自评更好，但不等于可靠。judge 仍可能：

偏乐观
忽视边界条件
被错误 rubric 带偏
对复杂状态变化理解不足

11.4 安全与权限边界复杂度激增

一旦 agent 具备：

shell
文件系统
浏览器
Git
外部 API

就必须严肃处理 prompt injection、凭证泄漏、越权调用、环境污染与恶意代码执行。

11.5 可观测性与调试困难

agent 系统具有非确定性、长链路和强状态性。一个失败结果背后可能是：

prompt 问题
tool 问题
memory 问题
orchestration 问题
环境问题

定位成本显著高于传统软件。

11.6 成本与延迟控制困难

多 agent、长时任务、复杂验证环节都会显著增加：

token 消耗
wall-clock time
基础设施成本
调试成本

11.7 代码熵增与 AI slop

高吞吐量带来的不是免费生产力，而是更快的熵增速度。没有垃圾回收、质量守恒和规则沉淀，系统会快速退化。

11.8 组织角色重构尚未完成

当工程师不再主要写代码，而转向：

设计环境
设计规则
设计 eval
设计反馈回路

很多传统岗位边界、责任归属与绩效衡量体系都需要重写。

图 9：当前主要风险版图

flowchart TB
    A["重点治理<br/>- 权限与安全<br/>- 可观测性不足<br/>- 评估偏差"]
    B["高成本实验<br/>- 成本失控<br/>- 组织协作失配"]
    C["局部优化<br/>- 上下文漂移"]
    D["长期隐患<br/>- Harness过拟合<br/>- AI slop 熵增"]

    A --- B
    C --- D
    A --- C
    B --- D

十二、结论与落地建议：2026 年正在发生的，不是“模型替代工程”，而是“工程重心上移”

Harness Engineering 的兴起，标志着 AI 工程进入了一个新的阶段。

如果说：

Prompt Engineering 解决的是“怎么让模型更会回答”
Context Engineering 解决的是“怎么让模型在多轮任务里不迷路”

那么：

Harness Engineering 解决的，是怎么让模型在真实世界里更可靠地工作。

Anthropic 的三 agent 架构表明，“生成-评估分离”适合用来处理长时任务中的质量控制问题；OpenAI 的百万行代码实验说明，知识库、规则系统和反馈回路可以构成新的生产力飞轮；DeepMind 的 Aletheia 进一步说明，verifier 循环并不只属于 coding 场景，而是一种更普遍的高价值任务结构；Vercel 则提醒整个行业，系统设计很多时候不是不断叠加，而是删到刚好。

因此，2026 年最重要的工程变化，并不是“大家终于学会写更厉害的 prompt”，而是：

大家开始更认真地把 agent 当作一种需要运行时、验证层和治理层共同支撑的生产对象来对待。

12.1 写给技术团队的落地建议

如果一个团队准备进入 Harness Engineering 阶段，最务实的起点通常不是“立刻做多 agent”，而是按以下顺序推进：

先把知识与约束沉淀进仓库或可检索系统
先把工具集缩到最小可行集合
先建立独立的 end-state evaluation
再考虑是否需要 planner、critic、verifier 等专用 agent
每次模型升级后，都重新审查哪些 scaffold 已变成负担

一句话概括最佳实践：

先做最简单可用的 harness，再只针对真实暴露出来的失败模式增加复杂度。

参考来源

OpenAI. Harness engineering: leveraging Codex in an agent-first world, Feb 11, 2026.
Anthropic. Effective context engineering for AI agents, Sep 29, 2025.
Anthropic. How we built our multi-agent research system, Jun 13, 2025.
Anthropic. Harness design for long-running application development, Mar 24, 2026.
Anthropic. Scaling Managed Agents: Decoupling the brain from the hands, 2026.
Vercel. We removed 80% of our agent’s tools, Dec 22, 2025.
Google DeepMind. Accelerating Mathematical and Scientific Discovery with Gemini Deep Think, Feb 11, 2026.