来源：抖音 @AI大模型学习
Harness Engineering：Agent开发新范式
近年来，AI Agent开发领域的技术栈正经历显著进化。如果说2023-2024年是Prompt Engineering的时代，强调如何优化与AI模型对话的质量；2025年转向Context Engineering，关注如何有效地管理和设计模型获取的信息环境；那么2026年，我们正步入Harness Engineering的时代，其核心在于构建一个可靠的系统架构以确保AI Agent工作的可靠性与可控性。
什么是Harness Engineering？
Harness Engineering，直译为“马具工程”或“驾驭工程”。借用马具的比喻：
- 马（Model）：指AI模型本身，它力大无比、跑得飞快，但往往不清楚跑向何方。
- 骑手（Engineer）：指工程师，负责为模型指明方向。
- 马具（Harness）：指模型运行的系统，它将模型的原始力量导向有用的工作。
因此，Harness Engineering的技术本质不是教模型如何回答，而是在设计模型如何工作。它处理的是模型外部的完整运行环境，涵盖任务拆解、上下文管理、工具编排、权限控制、状态交接、验证机制、失败恢复方案以及人机协作等复杂问题。它关注的不再是单一对话或上下文管理，而是Agent的可靠性与持续性，旨在设计一套机制确保模型能高效、准确地完成任务。
技术演进与定位关系
Agent技术的发展路径是从优化单轮对话到优化信息输入，再到优化整个Agent运行环境的演进。在架构上，Harness Engineering是最高层，它包含了Context Engineering，而Context Engineering又包含了Prompt Engineering。三者的关注点和核心问题各有侧重：
- Prompt Engineering（提示工程）：关注“怎么跟AI说话”，解决“怎么措辞”等单轮对话优化问题，技术侧重思维链、小样本示例等。
- Context Engineering（上下文工程）：关注“给AI看什么信息”，解决“让模型看懂什么”等动态上下文管理问题，技术侧重RAG、记忆注入、工具定义等。
- Harness Engineering（马具工程/驾驭工程）：关注“构建什么环境让AI工作”，解决Agent的可靠性与持续性问题，技术侧重工具编排、验证机制、状态管理等。
以汽车行驶为例：
- Prompt：一句命令“向右转”。
- Context：向模型提供一张地图，理解“右转”的含义。
- Harness：指整辆车，包括方向盘、刹车、车道边界、维护计划、警示灯等。Harness Engineering的深度理解则是确保车门不会在高速公路上脱落的所有工程设计。
Harness Engineering爆发的核心原因
当前Harness Engineering概念之所以蓬勃发展，有以下几个核心原因：
- 模型能力的“天花板效应”：模型基座能力已足够强大，单纯依赖更强的模型已无法解决业务的复杂问题。模型只是引擎，若无良好驾驭系统，其能力无法充分释放。系统设计成为模型能力放大器。
- 长时间任务的“裸模型”陷阱：即使是顶级模型，在长时间运行复杂任务时，也常因上下文耗尽或不验证而失败。这类架构级缺陷不能仅靠Prompt解决，必须依赖Harness层面的流 程控制和验证机制。
- 数学直觉：长链路的“累积误差”：假定Agent链路有20步，每步成功率95%，20步串联后总成功率仅36%。大量团队反馈Agent虽95%正常工作，但真实任务仍有33%失败率。解决此问题需要强化验证、回滚机制来打破连锁失败。
- 竞争壁垒的转移：随着GPT、Claude、Gemini等头部模型核心能力趋近，模型日益商品化，竞争壁垒已不再是模型质量本身，而是围绕模型的系统设计，即Harness的质量。
行业实践深度剖析
头部AI公司已在Harness Engineering领域取得了显著进展：
- Anthropic：2025年底，Anthropic采用双Agent架构，一个初始化Agent一个编码Agent。核心思想是将外部制品作为Agent记忆，通过持久化进度文件、Git历史、需求清单等，并在每个Session启动前加载上下文。2026年3月升级为三Agent架构：Planner（策划）、Generator（生成）、Evaluator（评估）。此举是为了解决“自评估系统性缺陷”，即模型倾向于自信表扬自己的作品，将评估器独立出来以专职挑错，已成为行业共识。
- OpenAI：其Codex Agent在生产实践中，7人团队在5个月内生成了百万行代码，合并了1500个PR，人均日吐量3.5个PR。其成功归因于三大支柱：
- Context Engineering（上下文工程）：持续增强代码库知识库，动态访问可观测性数据和浏览器。
- 架构约束：用确定性自定义Linter和结构测试执行来强制规范。
- 垃圾回收：定期扫描文档不一致或架构违规，以对抗系统熵增。 核心模式是Agent遇到困难时会反问：“我缺少什么能力？”，然后Agent自行编写修复代码，形成自我改进的闭环。
- Google DeepMind：其Aletheia数学研究Agent采用三组件Agentic Harness：Generator（生成器）、Verifier（验证器）、Reviser（修正器），思路与Anthropic不谋而合。技术创新在于“Thought Signatures”，通过加密推理状态表示来解决模型内部状态持续性问题。
- Vercel：发现给予Agent过多工具反而导致效果变差，通过移除80%工具，步骤更少、Token更省、响应更快、成功率更高。这提示我们，约束Agent的解决空间反而能提升表现。
- Stripe Minions：其Agent名为Minions，运行在预热的隔离Dev box环境中。核心理念是Agent需要与人类工程师完全相同的上下文和工具。
核心模块架构设计
一个成熟的Harness架构可拆解为六大核心模块：
- 上下文工程：
- 项目指令文件（AGENTS.md/CLAUDE.md）：Agent启动时读的说明书。
- 动态上下文注入：从日志、指标、追踪信息中获取实时信息。
- 上下文隔离：子Agent作为“上下文防火墙”，隔离独立的运行窗口，防止信息污染。
- 上下文压缩：对话窗口快满时自动丢弃或摘要无关信息，对抗熵增。
- 工具编排：
- 精选工具集：工具不是越多越好，要精心挑选。
- 移除冗余选项：Vercel的经验。
- MCP协议集成：标准化文件系统、API接口，使工具接入标准化。
- 沙箱隔离：隔离Agent与生产系统，如Stripe Devbox。
- 验证机制：
- 确定性约束：Linter、结构测试、pre-commit hooks，用程序逻辑卡死。
- 自动审查循环：多Agent审查、迭代至通过。
- 生成-评估分离：独立评估器，如Anthropic模式。
- 状态管理：
- Session开始-无状态LLM：每个新Session都从零开始。
- 进度追踪：功能清单TODO。
- Git检查点：增量提交或快照。
- 恢复：失败后从最新检查点回滚。
- 可观测性：
- 执行追踪：追踪执行过程和结果。
- 质量分级：评估产出质量。
- 异常检视：监控Agent异常行为。
- 反馈归因：失败模型反推Harness设计问题。
- 人类接管：
- 强制暂停：高风险操作需人类确认，如删数据库、扣费、发送邮件。
- 要授权：需要密码？
- 要客户邮件：需要人工审查？
- 必须要人确认：高风险操作。
新方法论贡献与风险挑战
Harness Engineering的创新价值在于：
- 约束对象的根本变化：从约束确定性代码执行到约束概率性推理系统，这是两个截然不同的领域。
- 约束以提升的反直觉原则：在Agent开发中，减少工具和限定其解决空间，反而能提升生产力，结构边界越清晰，表现越稳定。
- 生成-评估分离模式：独立评估器的设计模式，工程实践侧重的结构性结论。
- 代码库成为Harness的一部分：代码结构首先为Agent可读性优化，命名约定服务于Agent可推理性。
然而，Harness Engineering也面临一些风险和挑战：
- 风险一：概念膨胀：Harness Engineering正成为万能标签，过度概括可能稀释其精确性和实用性。
- 风险二：过度工程化：OpenAI警告Harness必须是“可撕裂的”。模型智能的快速发展可能使复杂的Harness设计在未来变得冗余。
- 风险三：证据基础局限：目前大多数成功案例来自AI工具厂商自身，缺乏独立的、定量的、可复现的学术验证。
- 风险四：可复现性缺口：例如OpenAI的百万行代码案例从空仓库开始，使用的是自家顶级工具和AI专家团队，其经验的通用性仍待验证。
- 风险五：新兴风险识别：Anthropic发现，更强的Harness可能放大内部风险。例如，多Agent配置下，非预期解法发生率反而高于单Agent配置，因为更多的Token使用和并行搜索路径会提高意外污染的概率。
未来定位展望与行动路径
关于Harness Engineering的未来定位，目前行业内存在两种主要声音：
- 成为AI时代的DevOps：随着Agent的普及，Harness Engineering将演变为一套持续积累、核心化的工程学科，像CI/CD一样成为基石，Agent系统的标准化构建和运维将成为核心能力。
- 成为过度性概念：认为Harness只是一个过渡，未来的模型将足够强大，不再需要如此复杂的驾驭，Harness可能成为历史性的技术补丁。
无论其未来如何，系统化管理AI Agent的思路是不会消失的。
对于希望立即投入实践的开发者，建议采取“三步走”策略：
- 立即能做的：在项目根目录创建
AGENTS.md文件，每次发现Agent重复犯错时，就在文件中添加一条规则。这是成本最低、见效最快的Harness实践。 - 中期投入的：构建确定性验证层，集成Linter、结构测试和pre-commit hooks。同时，建立最基本的Agent可观测性系统，了解Agent的运行步骤和状态。
- 长期要做的：设计模块化、可替换的Harness架构，支持模型升级时的平滑迁移。确保未来模型能力提升时，Harness也能灵活应对变化，而不是成为束缚。
总结与核心结论：
- Prompt Engineering解决模型“怎么说”的问题。
- Context Engineering解决模型“给模型看什么”的问题。
- Harness Engineering解决“让模型在什么运行机制里干活，并且如何确保它真的干活成”的问题。
OpenAI研究员Ryan Lopolopolo认为：“Agent不易，Harness才艰。”
模型本身好比发动机，Harness则是整车设计。再强大的发动机，也需要良好的底盘、传动和控制系统才能跑起来。当前，生成-评估分离和外部持久化记忆已是主流AI厂商实战中最有效的模式。Harness设计应根据模型能力动态调整，避免过度复杂化。当模型更聪明，一些复杂的补丁就可以拆掉。未来，Agent本身会变成一种商品，真正拉开差距的将是围绕Agent的这套Harness系统。它并不难做，只要我们持续学习，实践，就能驾驭好Agent。