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 地图，而不是给它一本 1000 页手册。

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

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

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

这说明 agent-first 开发并不是"少做工程"，而是把工程 rigor 从人工 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 这个案例证明了一个非常关键的原则：

复杂度不是资产，简化本身就是核心工程能力。

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

九、Harness Engineering 的六大核心模块

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

9.1 意图建模与规划层

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

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

9.2 上下文与记忆层

负责管理：

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

9.3 工具与执行环境层

负责定义：

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

9.4 编排与多 agent 拓扑层

决定系统是：

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

9.5 评估与反馈闭环层

负责：

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

9.6 治理、安全与运维层

负责：

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

图 7：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 正在迅速成为主流实践，但它仍处于快速试错阶段，至少存在以下八类问题。

10.1 经验外推风险

很多成功案例建立在：

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

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

10.2 Harness 过拟合风险

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

10.3 LLM 评估仍有盲点

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

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

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

一旦 agent 具备：

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

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

10.5 可观测性与调试困难

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

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

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

10.6 成本与延迟控制困难

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

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

10.7 代码熵增与 AI slop

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

10.8 组织角色重构尚未完成

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

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

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

图 8：当前主要风险版图

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

quadrantChart title Harness Engineering 风险分布 x-axis 低工程难度 --> 高工程难度 y-axis 低业务影响 --> 高业务影响 quadrant-1 重点治理 quadrant-2 高成本实验 quadrant-3 局部优化 quadrant-4 长期隐患评估偏差: [0.65, 0.82] 权限与安全: [0.87, 0.95] 可观测性不足: [0.79, 0.84] 成本失控: [0.73, 0.76] 上下文漂移: [0.58, 0.64] Harness过拟合: [0.61, 0.71] 组织协作失配: [0.66, 0.67] AIslop熵增: [0.57, 0.78]

十一、结论：2026 年正在发生的，不是"模型替代工程"，而是"工程重心上移"

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

如果说：

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

那么：

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

Anthropic 的三 agent 架构证明了"生成-评估分离"是长时任务中的关键结构；OpenAI 的百万行代码实验证明了知识库、规则系统和反馈回路可以成为新的生产力飞轮；DeepMind 的 Aletheia 证明了 verifier 循环不只是 coding 问题，而是高价值研究任务的普遍结构；Vercel 则提醒了整个行业：很多时候，最好的系统不是加更多，而是删到刚好。

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

大家开始认真地把 agent 当作一个需要操作系统、运行时、验证层与治理层的生产对象来对待。

附录：写给技术团队的落地建议

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

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

一句话概括最佳实践：

先做最简单可用的 harness，再只为真实失败模式增加复杂度。

参考来源

复制代码