Harness 工程 vs 上下文工程
理解上下文工程与 Harness 工程的区别，构建可靠的 AI 系统
微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI工具导航 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
你是否还在为 AI 智能体 20% 的失败率而挣扎？是时候重新思考你的方法了！发现上下文工程与 Harness 工程之间的关键区别，学习如何构建真正可靠的系统。不要只创建演示 —— 构建生产就绪的智能体！继续阅读，转变你的 AI 设置！
上下文工程专注于优化 AI 模型在推理时看到的内容，而 Harness 工程涵盖整个系统设计，确保在多次推理中的可靠性。上下文工程是 Harness 工程的一个子集。Harness 工程包括行为约束、反馈循环和质量关卡。有效的 Harness 设计显著提高了性能，研究表明基于 Harness 配置的性能差距巨大。这两个学科都是必不可少的，上下文工程提供必要信息，Harness 工程确保随时间一致的可靠输出。
你已经花了数周时间完善你的 RAG 管道。你的提示是完美的。你的智能体在生产环境中仍然有 20% 到 40% 的失败率。听起来熟悉吗？
以下是大多数 AI 工程师艰难学到的不舒服真相：你一直在优化错误的层次。你一直在做上下文工程而没有做 Harness 工程，然后想知道为什么你的智能体仍然不能被信任做真正的工作。
模型是 CPU。Harness 是操作系统。 而现在，大多数团队正试图在没有操作系统的裸机上运行生产工作负载。
本文清晰地阐述了这两个学科，展示它们的确切区别，并为你提供证据和实用模式来实现两者。到最后，你会知道自己是正在构建演示还是生产系统，以及弥合这一差距需要什么。
1、什么是上下文工程？
上下文工程是在推理时设计和管理 LLM 看到的所有内容。每个进入模型上下文窗口的 token 都是一个上下文工程决策：系统提示、工具定义、RAG 结果、消息历史、输出模式、先前会话的记忆。
Andrej Karpathy 帮助推广了这个术语，作为"提示工程"的继任者。这是一个重要的重新定位。"提示工程"意味着你只是在制作一个巧妙的指令。上下文工程承认你实际上是在设计一个完整的信息环境。Shopify CEO Tobi Lutke 提供了一个简洁的定义："提供所有上下文的任务，使 LLM 可以合理地解决它的艺术。"
上下文工程回答的问题是直接的：我们向智能体展示什么？
这个问题比看起来更有深度。考虑单个推理中包含的内容：
其中任何一个出错，模型就会产生幻觉、调用错误的工具，或生成结构无效的输出。上下文工程是真正的工程，有真正的后果。
2、上下文工程的局限性
但问题是：即使是完美的上下文工程也只能优化单个推理。它告诉模型现在该做什么。它不说当模型出错时会发生什么，或如何防止同样的失败在下周再次发生。
上下文工程对自己的失败也没有记忆。每个新的推理都是重新开始。如果模型在周一运行了错误的命令，你在周二修复了提示，一旦上下文转变，没有什么能阻止它在周四再次运行错误的命令。
这就是 Harness 工程发挥作用的地方。
3、什么是 Harness 工程？
Harness 工程是整个智能体环境的系统设计。它是模型之外的一切：行为约束、反馈循环、质量关卡，以及确保持续可靠性的改进周期，不仅在数千次推理中，而是在每一次推理中。
Birgitta Boeckeler 在 2026 年 2 月 Martin Fowler 网站上撰文，提出了一个正式定义，已成为行业参考。她描述 Harness 工程有三个组成部分：
- 上下文工程（是的，它是 Harness 工程的子集，就像提示工程是上下文工程的子集）：代码库中持续增强的知识库，加上来自可观测性数据的动态上下文
- 架构约束：不仅由基于 LLM 的智能体监控，还由确定性自定义检查器和结构测试监控
- 垃圾回收：定期运行的智能体，查找文档中的不一致或架构约束的违反
再读一遍第一个组成部分。上下文工程是 Harness 工程的子集，而不是一个平行的学科。这是大多数团队错过的关键洞察。
Mitchell Hashimoto 在他的文章"My AI Adoption Journey"（2026 年 2 月）中阐明了这一理念：
💡 "每当你发现智能体犯了一个错误，你就花时间设计一个解决方案，使智能体永远不会再犯那个错误的想法" —— Mitchell Hashimoto, "My AI Adoption Journey"
Hashimoto 的实现是具体且有指导意义的。对于他的 Ghostty 项目，他维护一个 AGENTS.md 文件，其中每一行对应他纠正的一个特定的智能体不良行为。"文件中的每一行都基于一个不良的智能体行为，它几乎完全解决了所有这些问题，"他写道。简单吗？是的。有效吗？非常有效。
Harness 工程回答的问题根本不同：我们防止什么、衡量什么、控制什么、修复什么？
4、Harness 工程的三大支柱
这些学科之间的嵌套关系值得明确看到：
5、关键区别
这两个学科不是竞争者。它们是同一系统的不同层次。但了解它们如何不同有助于你准确识别智能体设置缺少什么。
最后一行比看起来更重要。上下文工程帮助模型产生更好的单个输出。Harness 工程帮助团队足够信任模型，让它在没有监督的情况下做真正的工作。
这就是演示和生产系统之间的区别。
6、类比深入
为了具体说明这一点，考虑传统软件系统如何工作与 AI 智能体系统工作：
没有人运送没有操作系统的裸机代码。我们也不应该在没有 Harness 的情况下运送智能体。Harness 是智能体的操作系统。
7、证据：Harness 胜过模型本身
如果你怀疑 Harness 设计比模型能力更重要，研究是明确的。这些不是理论论证。它们是有硬数字的对照研究。
SWE-agent：仅界面设计就将解决率提高了 64%
普林斯顿大学的 SWE-agent 研究（被 NeurIPS 2024 接受）进行了一项仔细的对照研究。研究人员使用相同的模型（GPT-4 Turbo），在两种 Harness 配置中测试它：
- 基线：仅 shell 界面，没有自定义编辑工具
- SWE-agent：带有专用代码编辑工具的自定义智能体-计算机界面
结果：自定义 ACI 比仅 shell 基线将解决率相对提高了 64%。相同的模型。相同的任务集。唯一的变量是 Harness 设计。
（如果你仍然因为智能体的失败而责怪模型，你是在为内核恐慌责怪 CPU。）
SWE-Bench Mobile：相同模型，6 倍性能差距
2026 年的 SWE-Bench Mobile 评估更鲜明地说明了这一点。相同的模型，Claude Opus 4.5，得分：
- 2% 成功率在一个智能体 Harness 中（OpenCode）
- 12% 成功率在另一个智能体 Harness 中（Cursor）
这是相同基准上6 倍的性能差距，使用相同的底层模型。整个差异来自智能体设计：Harness 如何管理工具使用，如何构建编辑界面，以及如何处理故障恢复。
你无法通过调整提示来弥合 6 倍的差距。Harness 就是产品。
Stripe：每周 1,300 个 AI 编写的 Pull Request
Stripe 的 AI 智能体基础设施展示了规模化 Harness 工程。他们的系统每周生成1,300 个 AI 编写的 pull request，使用：
- 狭窄、定义明确的任务范围（不是"给我写个功能"而是"将这个特定函数迁移到新 API"）
- 沙盒运行时环境
- 具有独立上下文的并行智能体执行
- 合并前的人工审查关卡
- 精确的规范作为输入，而不是模糊的需求
每一个都是 Harness 工程决策。模型不知道它在沙盒中。模型不知道有人工审查关卡。Harness 无论模型决定做什么，都确定性地强制执行这些约束。
OpenAI 内部：100 万+ 行代码，零手动输入
Martin Fowler 的文章描述了一个 OpenAI 团队，他们构建了一个超过 100 万行生产代码的产品，而没有一行是手动输入的。他们的定义实践：他们将智能体遇到困难的每个实例都视为改进 Harness 的信号，而不是尝试更努力提示的邀请。
这就是 Harness 工程的精髓：Harness 从智能体的失败中学习，使智能体不必重复它们。
8、实用实施指南
理论够了。以下是如何在智能体设置中实施这两个学科。
第一阶段：上下文工程基础
这些是优化模型看到的组件。如果你是从零开始，从这里开始。
指令文件（CLAUDE.md, .cursorrules, AGENTS.md）
这是最简单的上下文工程形式。你通过给模型项目特定的规则来告诉它该做什么：
# CLAUDE.md -- 上下文工程实战
## 项目上下文
这是一个使用 SQLAlchemy 2.0 和异步会话的 FastAPI 应用程序。
始终使用 `async with get_session() as session` 进行数据库访问。
## 代码风格
- 使用 Pydantic v2 model_validator，不是 v1 @validator
- 对于验证错误返回 422，不是 400
- 所有端点都需要 OpenAPI 文档字符串
它的作用：在推理时将项目约定直接加载到模型的上下文中。
为什么有效：模型现在有了做出正确决策所需的项目特定规则，而不是从一般训练中猜测。
局限性：这只影响加载这些指令的推理。它不会防止违规或纠正漂移。
RAG 和检索管道
对代码库、API 文档或领域知识的语义搜索为模型提供了手头任务的相关上下文。RAG 解决了模型一般了解你的领域但不了解你特定实现细节的问题。与其将所有内容塞入系统提示中，不如在查询时检索最相关的块。
模型上下文协议（MCP）
Anthropic 的 MCP 在 2026 年成为工具和上下文互操作性的标准。它允许智能体动态发现和使用工具，带有引导工具选择的结构化模式。把它想象成 AI 工具的 JDBC；一个标准适配层，允许任何智能体与任何兼容的工具服务器一起工作。
记忆系统（Mem0, Zep, Agent Brain 和 Agent Memory）
跨会话的持久上下文意味着模型记住先前的决策、用户偏好和项目特定模式。没有记忆，每个会话都是冷启动。有了记忆，智能体随时间积累项目特定知识。
第二阶段：Harness 工程基础
一旦有了上下文工程，就添加 Harness。这些组件确保系统随时间可靠工作，而不仅仅是第一次。
AGENTS.md 作为迭代错误日志
遵循 Hashimoto 的模式，将你的 AGENTS.md 视为活文档，其中每一行防止特定的过去失败：
# AGENTS.md -- Harness 工程实战
- 永远不要在没有明确用户确认的情况下在任何目录上运行 `rm -rf`
- 总是在提交前运行测试；如果测试失败不要提交
- 使用 `uv` 进行 Python 包管理，不直接使用 pip
- 数据库迁移必须被审查；永远不要在生产环境中自动应用
- 修改 API 端点时，始终更新 OpenAPI 规范
它的作用：每一行都是在真实失败后添加的约束。智能体第一次删除了错误的目录，你就添加那条规则。它再也不会发生。
为什么这是 Harness 工程而不仅仅是上下文工程：AGENTS.md 本身也是上下文工程（它被加载到模型的上下文中），但实践将失败视为更新它的信号是 Harness 工程。你是在构建反馈循环，而不仅仅是写更好的提示。
生命周期钩子
Claude Code 提供在工具调用执行前后拦截的钩子：
{
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hook": "echo 'BLOCKED' && exit 1",
"description": "阻止危险的 shell 命令"
}]
}
}
它的作用：钩子拦截 Bash 工具调用，并在命令匹配被阻止的模式时终止它。
为什么这比提示规则更好：确定性执行。模型不需要"记住"不要运行危险命令。Harness 无论模型决定做什么都阻止它。这是实践中的架构约束。
检查器和结构测试
在每次智能体操作后运行这些，而不仅仅是在 CI 时：
# 结构测试：验证所有 API 端点都有相应的测试
find src/api -name "*.py" | while read f; do
test_file="tests/$(basename $f)"
if [ ! -f "$test_file" ]; then
echo "FAIL: $f 没有测试文件"
exit 1
fi
done
它的作用：以确定性的、非 LLM 的方式强制执行架构约束（每个 API 文件都有一个测试文件）。智能体无法绕过这个检查。要么测试文件存在，要么构建失败。
垃圾回收智能体
定期智能体在熵复合之前清理它：
- 检查引用过时 API 的陈旧文档
- 检测架构漂移（不符合既定约定的新模式）
- 删除未使用的导入、死代码和孤立的测试装置
- 验证依赖版本与锁定文件匹配
垃圾回收是 Harness 工程中最被忽视的组件。每个长期存在的代码库都积累熵：不再匹配代码的文档、引用已删除服务的配置、因错误原因通过的测试。垃圾回收智能体按计划运行，找到这些不一致，并修复它们或标记它们以供审查。
CI/CD 集成
智能体输出通过与人类代码相同的管道：linting、测试、安全扫描、审查。Harness 不信任智能体。它每次都验证智能体。
第三阶段：反馈循环
Harness 工程反馈循环：智能体失败，人类分析，配置更新，智能体重试成功。
反馈循环是将一组 Harness 组件转变为自我改进系统的原因。以下是它的工作原理：
注意每条失败路径都通向不同类型的 Harness 更新。命令错误？更新指令文件。结构错误？添加检查器。陈旧的文档？添加垃圾回收智能体。缺少上下文？改进上下文工程。每次失败都教 Harness 一些新东西。Harness 不会忘记。
入职类比
这样想。
上下文工程是给新员工一份完美的入职文档。它解释代码库、约定、工具、团队偏好。一份好的入职文档非常有价值。没人否认这一点。
Harness 工程是完整的工作环境：在代码审查前捕获风格违规的检查器、每次推送运行测试的 CI 管道、解释事情为何如此的架构决策记录、出错时警报的可观测性堆栈，以及捕获自动化工具遗漏内容的代码审查流程。
你不会把新开发者交给没有检查器、没有 CI、没有代码审查的完整代码库，然后期望生产质量的代码。为什么我们对 AI 智能体做完全相同的事？
入职文档（上下文工程）告诉他们该做什么。工作环境（Harness 工程）确保他们实际上正确地做，并在项目演变和熵积累时保持他们的一致性。
9、没有 Harness 会发生什么
以下是操作上的区别：
- 没有 Harness：唯一的反馈是"它工作了"或"它没有"。
- 有 Harness：每次失败都教系统一些东西。
这就是根本的区别。
10、两者都是必要的
让我直说：你需要两者。没有 Harness 工程的上下文工程给你一个在第一次尝试时很聪明但在第一百次时不可预测的智能体。没有上下文工程的 Harness 工程给你一个被优美约束但没有足够信息做有用工作的智能体。
关系很简单：上下文工程是 Harness 工程的一个组件，不是一个竞争的学科。如果你只做上下文工程，你是在裸机上运行。如果你在做 Harness 工程，你必然在做上下文工程加上其他一切。
11、自我审计清单
以下是对你当前智能体设置的快速审计：
如果你勾选的少于四个框，你是在一个在生产负载下会崩溃的基础上构建智能体。模型不是问题。Harness 才是。
12、从哪里开始
如果你是从零开始，按这个顺序投资：
- 首先做上下文工程。 让你的指令文件、RAG 管道和工具定义扎实。你需要在构建结构之前打好基础。
- 添加架构约束。 从每次智能体输出运行的检查器和结构测试开始。这些添加起来很便宜，能捕获很多失败。
- 构建反馈循环。 将每次智能体失败视为 Harness 工程任务。添加规则、测试或垃圾回收检查。不要只修复输出；修复系统。
- 添加 CI/CD 集成。 智能体输出应该通过与人类代码相同的管道。生产工作负载没有例外。
- 最后是熵管理。 一旦你有了失败被捕获和预防，添加定期垃圾回收智能体来处理即使单个推理正确时也会积累的漂移。
13、问答回顾
Q: 上下文工程只是有一个花哨名字的提示工程吗？
A: 不是。提示工程是上下文工程的一个组件。上下文工程涵盖模型在推理时看到的所有内容：提示、工具定义、RAG 结果、记忆、输出模式和消息历史。这就像写好电子邮件主题行与设计整个通信系统之间的区别。
Q: 我需要为简单的聊天机器人做 Harness 工程吗？
A: 可能不需要。如果你的智能体在一个上下文中做一件事且没有工具，上下文工程可能就足够了。当智能体采取行动、使用工具、跨会话操作或需要大规模保持可靠性时，Harness 工程变得关键。你的智能体有越真实世界的后果，Harness 就越重要。
Q: AGENTS.md 足够做 Harness 工程吗？
A: 这是一个很好的开始，但它只涵盖 Harness 工程的上下文工程部分。真正的 Harness 工程还需要架构约束（检查器、结构测试）、垃圾回收（熵管理）、反馈循环（CI/CD）和可观测性。AGENTS.md 解决"告诉智能体什么"。完整的 Harness 解决"无论智能体知道什么都要强制执行什么"。
Q: 我应该先投资哪一个？
A: 上下文工程。你需要在构建结构之前打好基础。让你的指令文件、RAG 管道和工具定义扎实。然后添加 Harness：添加检查智能体输出的检查器，为失败构建反馈循环，并将每个智能体错误视为 Harness 工程机会。顺序很重要。
Q: 一个优秀的 Harness 能弥补较弱的模型吗？
A: 证据表明是的，非常可以。SWE-Bench Mobile 显示使用相同模型的不同 Harness 之间有 6 倍的性能差距。Stripe 使用狭窄任务范围和沙盒执行每周运行 1,300 个 PR。对于生产可靠性，Harness 比模型层级更重要。也就是说，最好的系统将能力强的模型与精心设计的 Harness 配对。一个不能替代另一个。
Q: 谁创造了"Harness 工程"这个词，它从哪里来？
A: 它是一个分布式发明。Mitchell Hashimoto 在他的 2026 年 2 月文章中用它来描述他的基于 AGENTS.md 的迭代错误预防方法。Birgitta Boeckeler 在 Martin Fowler 网站上于同月发布了正式的三组件定义。LangChain 在他们的"智能体 Harness 解剖"文章中定义了"智能体 = 模型 + Harness"。这三个都值得阅读。这个概念从多个从业者独立得出相同结论而趋同：仅靠上下文是不够的。
原文链接：Harness Engineering vs Context Engineering: The Model is the CPU, the Harness is the OS
汇智网翻译整理，转载请标明出处
