你是否还在为 AI 智能体 20% 的失败率而挣扎是时候重新思考你的方法了发现上下文工程与 Harness 工程之间的关键区别学习如何构建真正可靠的系统。不要只创建演示 —— 构建生产就绪的智能体继续阅读转变你的 AI 设置上下文工程专注于优化 AI 模型在推理时看到的内容而 Harness 工程涵盖整个系统设计确保在多次推理中的可靠性。上下文工程是 Harness 工程的一个子集。Harness 工程包括行为约束、反馈循环和质量关卡。有效的 Harness 设计显著提高了性能研究表明基于 Harness 配置的性能差距巨大。这两个学科都是必不可少的上下文工程提供必要信息Harness 工程确保随时间一致的可靠输出。Harness 工程 vs 上下文工程你已经花了数周时间完善你的 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 Journey2026 年 2 月中阐明了这一理念 “每当你发现智能体犯了一个错误你就花时间设计一个解决方案使智能体永远不会再犯那个错误的想法” —— Mitchell Hashimoto, “My AI Adoption Journey”Hashimoto 的实现是具体且有指导意义的。对于他的 Ghostty 项目他维护一个 AGENTS.md 文件其中每一行对应他纠正的一个特定的智能体不良行为。文件中的每一行都基于一个不良的智能体行为它几乎完全解决了所有这些问题他写道。简单吗是的。有效吗非常有效。Harness 工程回答的问题根本不同我们防止什么、衡量什么、控制什么、修复什么4、Harness 工程的三大支柱这些学科之间的嵌套关系值得明确看到上下文工程存在于 Harness 内部。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 中OpenCode12%成功率在另一个智能体 Harness 中Cursor这是相同基准上6 倍的性能差距使用相同的底层模型。整个差异来自智能体设计Harness 如何管理工具使用如何构建编辑界面以及如何处理故障恢复。你无法通过调整提示来弥合 6 倍的差距。Harness 就是产品。Stripe每周 1,300 个 AI 编写的 Pull RequestStripe 的 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 解决了模型一般了解你的领域但不了解你特定实现细节的问题。与其将所有内容塞入系统提示中不如在查询时检索最相关的块。模型上下文协议MCPAnthropic 的 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_filetests/$(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 工程 vs 上下文工程 - 汇智网