正文整理稿

按视频原讲述顺序整理的正文稿。

《Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚》

来源：YouTube [马克的技术工作坊]
时长：00:37:24
视频ID：7nCzfgDjSo8
链接：https://www.youtube.com/watch?v=7nCzfgDjSo8
说明：以下文字按视频原讲述顺序整理，口语、重复和明显噪声已做轻度收束。

---

从提示词到系统：Harness Engineering的诞生

继 Prompt Engineering 和 Context Engineering 之后，AI 圈最近又冒出一个新名词——Harness Engineering。从今年2月开始，这个词频繁出现在 AI 领域的讨论中。OpenAI 专门发布文章，讲述他们如何通过 Harness Engineering，在5个月内生成近100万行代码。Anthropic 也紧随其后，分享了他们如何借助精心设计的 Harness 架构来驱动 Agent 的开发与应用。甚至连技术大牛 Martin Fowler 创立的技术网站 martinfowler.com，也开始公开探讨这一概念。

然而，也有不少人质疑：这不过是个噱头，换汤不换药。那么，Harness Engineering 究竟是什么？它与 Prompt Engineering、Context Engineering 之间有何关联？是真正的技术突破，还是 AI 圈又一次在炒概念？本期视频，我们就来彻底搞清楚这件事。

首先是 Prompt Engineering。这里的 Prompt 可以简单理解为用户发给大模型的指令。而 Prompt Engineering，就是一门研究如何把话说清楚的技术。举个例子：如果你问大模型“帮我的猫起个名字”，这本身就是一个 Prompt。模型可能会给出“花花”“小白”之类的答案，但这些可能并不符合你的期待——比如你家的猫是橘色的，而“花花”“小白”显然与颜色不符。

为什么会出错？因为 Prompt 中缺乏足够的信息。既然问题出在输入上，解决的关键自然也在输入上。换句话说，我们需要学会更精准地表达需求。这就引出了 Prompt Engineering 的核心：如何让提示词更清晰、更具指向性。

仍以小猫为例，重新设计提示词： “帮我的橘色小猫起名，两个字，要体现它活泼爱玩的性格。” 这时，模型就能给出更贴切的答案，比如“橘宝”（代表橘色的大活宝）、“橙豆”（橙色的小豆子）。想象一下小豆子在地上蹦跳的画面，正好呼应了猫咪活泼的性格。你看，这两个名字是不是比之前的更契合？

说白了，Prompt Engineering 就是一门调整大模型提示词的技术——就这么简单。但如今，这门技术已很少被单独提及。一方面是因为门槛太低，另一方面是模型自身能力越来越强，很多时候无需反复调优提示词，也能获得不错的结果。

是 Context Engineering。我们继续用小猫举例：假设你已经得到了名字，接着问：“那它平时吃什么好呢？”这个提问就是新的 Prompt。但此时，大模型接收到的不只是这个新问题，还包括之前的对话历史——否则它根本不知道“它”指的是谁。

无论是 Prompt 还是对话历史，都是大模型所接收的信息。我们将这些信息统称为 Context。当然，Context 不仅包含这两项，还可能包括工具列表、技能清单等。但关键点在于：Context 有容量上限，不能无限制塞入内容。因此，我们必须精心设计其中的内容，这就是 Context Engineering。

具体方法有很多，比如经典的“上下文压缩”——随着对话不断进行，历史记录会越积越多，一旦超过阈值，就需对过往内容做摘要，避免信息过载影响输出质量。此外还有动态检索外部资料、渐进式披露等策略。可以看出，Context Engineering 已经发展出不少实用技巧。

但即便如此，它的效果仍存在瓶颈。为了进一步挖掘大模型的潜力，AI 圈再次推出新玩法——这正是我们今天的主角：Harness Engineering。

要理解 Harness Engineering，得先弄懂 “Harness” 这个词。这个词在日常生活中并不常见，很多人可能是第一次听说。它的本意是“马具”，即套在马身上的控制装置，如缰绳、头套等。虽然马本身力量强大，但必须借助马具才能被人类驾驭，否则就会失控。

现在，我们把“马具”从马身上拆下来做个类比：左边那匹脱掉马具的马，对应 AI 领域中的大模型。像 GPT、Opus 这样的顶级模型，能力极强，能完成大量任务。但如果不加干预，任其自由发挥，就像脱缰野马，思维发散，甚至产生严重幻觉，最终无法稳定输出预期结果。

因此，我们必须对大模型加以控制，就像用马具控制马一样。这套用于控制大模型的系统，就被称为 Harness。没错，Harness 就相当于“马具”。

在 Agent 架构中，Harness 是用来控制和驾驭大模型的核心系统。由此可以推导出一个公式：Harness = Agent - Model。也就是说，一个完整的 Agent 减去其中的大模型，剩下的所有部分都属于 Harness。

需要强调的是，Harness Engineering 是一个非常新的概念，目前业界尚未形成统一定义。上述公式只是目前多数人认可的一种理解，并非严格学术定义。只要不是大模型本身，都可以视为 Harness 的一部分。

举个具体例子：以 Claude Code 为例，所有不属于 Claude 模型的部分，都属于 Harness。比如 CLAUDE.md 文件中定义的规则、可用工具、定时调度机制等，都是 Harness 的组成部分。当然，实际涵盖范围远不止这些，这里仅列举三个典型场景。总之，凡是模型之外的系统组件，均可归入 Harness。

那么，Harness Engineering 的本质也就呼之欲出了：它是一门专门研究如何构建与设计 Harness 的技术。换句话说，除了大模型本身不研究，其他什么都研究。它不再局限于优化输入提示词或上下文，而是站在更高层面，思考如何为大模型搭建一套稳定、可靠的运行系统，让大模型能够踏踏实实地为我们服务。

• Prompt Engineering 关注的是“怎么问问题”，即如何组织提示词，使模型更容易理解真实意图。- Context Engineering 关注的是“怎么给信息”，即如何在合适时机，将最合适的内容放入模型的 Context，涵盖 Prompt、对话历史、工具列表等。- 而 Harness Engineering 的研究范围则更为激进：它关注的是“如何搭建系统”，即围绕大模型构建一个完整、可靠、可持续运行的 Agent。其研究对象覆盖了除大模型外的所有内容，包括权限管控、工具管理、状态追踪、错误处理等。

相信至此，你已经对 Harness Engineering 有了基本认知。那么，它具体要做些什么？有没有实战案例？

大厂实战：OpenAI如何用Harness打造百万行代码系统

说实话，这个概念实在太新，目前业界尚无公认体系。与其我自说自话，不如直接看看大厂的实际做法。

我们从 OpenAI 开始。2025年8月，OpenAI 内部启动了一个极具挑战性的实验：用 AI 从零开始构建一个真实的软件产品，全程禁止工程师手写一行代码。没错，整个产品的所有组成部分——业务逻辑、测试用例、CI/CD 配置、文档、内部工具等——全部由 AI 生成。

最终，该项目的代码规模达到了近100万行，且并非玩具项目，而是一个真正上线运行、拥有真实用户的生产系统。整个过程耗时约5个月，初始团队仅3人，后期扩展至7人，平均开发效率约为纯人工模式的10倍。

但有趣的是，项目初期进展并不顺利。问题并非出在大模型不够聪明，而是 Harness 没有搭建好。工程师发现，Agent 经常走偏方向，甚至重复犯同样的错误。

于是他们意识到：要让 Agent 稳定工作，真正的关键在于把 Harness 设计好。为此，团队进行了大量优化，并撰写了一篇详尽的文章记录全过程。这篇文章信息量极大，涉及多个 Harness Engineering 的优化实践。因此，本期视频我们将重点解析 OpenAI 在 Harness Engineering 上的具体举措。

原文从多个具体优化点展开，信息密度极高。为便于理解，我尝试将其大致归纳为三类：上下文管理、验证与反馈、技术债清理。需要说明的是，这只是我个人的分类方式，旨在帮助大家梳理逻辑，并非官方划分。

首先来看第一类：上下文管理。其核心目标是确保 Agent 能获取足够且有效的信息。

想象一个新入职的工程师，如果对项目一无所知——不清楚模块划分、不了解代码规范、不掌握过往技术决策，他根本无法开展工作。Agent 也是如此。

最初，OpenAI 的做法是将所有项目规范和相关信息塞进一个超大的 AGENTS.md 文件，随每个问题一同发送给大模型。看似信息充足，实则问题重重。

主要问题有两个。

一是内容过多，导致模型表现下降。试想你第一天入职，HR 直接扔给你一本厚如辞典的员工手册，说“规矩都在这儿，自己看吧”。你大概率会一脸茫然，不知从何读起，也分不清重点在哪。AI 也一样，信息堆叠在一起，反而抓不住关键，只能提取碎片化内容，真正重要的信息反被淹没。

二是文件容易腐化。项目在持续演进，但文件内容却无人及时更新，久而久之变成一堆过时信息的垃圾堆。更糟糕的是，连人都懒得整理，Agent 更无从判断哪些内容仍有效。

因此，团队后来改变了策略：将 AGENTS.md 压缩至约100行，结构如下。

AGENTS.md。- 项目架构概览。- 核心流程图。- 工具使用指南。- 常见问题解答。- 重要决策记录链接。

可以看出，文件本身已无太多实质内容，只是一个目录索引。对应的文件系统则按需组织，相关文档与配置文件与 AGENTS.md 同级存放。需要时才提供给 Agent 查阅。

这种“按需加载”的方式效果显著。看来，大模型和人一样，信息必须分门别类、结构清晰，才能高效利用。

此外，OpenAI 还发现一个关键问题：许多重要信息其实不在代码仓库里。它们可能散落在 Slack 聊天记录中，藏在 Google Docs 文档里，甚至只存在于某个老员工的记忆中。这一点在中文生态中尤为常见——比如钉钉群聊、企业微信文档、本地 Word 文件等。

但对于 Agent 来说，它只能看见代码仓库里的内容，仓库之外的一切，形同虚设。

为解决这个问题，OpenAI 强制要求：所有重要决策、技术约定、设计规范，必须同步录入代码仓库，使其成为唯一的“事实来源”。这样一来，Agent 才能全面了解项目背景，做出合理判断。

这就是他们在上下文管理方面所做的核心工作。

接下来，我们进入第二部分：验证与反馈。

当上下文管理到位，Agent 获得了充分信息，便可以开始写代码。但关键问题来了：写完之后，如何验证成果是否正确？若无法验证，准确率就无从保证。

OpenAI 的解决方案是：为 Codex 配备完善的工具链和 Skill 集合。在这些能力的支持下，Codex 能在任务执行过程中随时验证自身输出。

让我们举个例子……。

OpenAI 在实现 Harness Engineering 时，采取了将所有重要决策和约定统一纳入代码仓库的策略，使仓库成为唯一的事实来源。这样一来，Agent 就能获取到完整的上下文信息，从而在执行任务时具备充分的背景支持。是验证与反馈环节——在完成上下文管理并确保信息完备后，Agent 才能真正开始写代码。若缺乏有效的验证机制，代码质量将无法保障。

为此，OpenAI 为 Codex 配备了完善的工具链和技能集，使其能够在任务执行过程中实时验证自身输出。例如，他们将 Chrome DevTools 接入 Codex 的运行环境，让 Codex 能自主截图、检查 DOM 结构，并模拟用户操作，以验证 UI 是否符合需求。一旦发现问题，Codex 可立即原地修复，整个过程无需人工干预。

此外，OpenAI 还引入了完整的可观测性工具栈，使 Codex 能读取日志、监控指标，并在必要时追踪调用链路，用于问题排查。为了保证数据准确性，每个任务都在完全隔离的环境中运行，拥有独立的日志和指标系统，任务结束后自动销毁。这种设计不仅提升了调试效率，还使得 Codex 能够对系统进行可量化的性能优化，比如确保服务启动时间不超过 800 毫秒。

然而，除了满足功能需求外，代码本身也必须符合项目架构规范。OpenAI 将其系统划分为多层结构，从上至下依次为：UI、Runtime、Service、Repo、Config、Types。每一层只能依赖其下方的层，禁止反向依赖（如 Repo 层不能依赖 UI 层）。为防止架构违规，系统通过 linter 和自动化测试来强制执行规则。当 Agent 生成代码后，这些工具会立即检测合规性。若不通过，则返回错误信息给 Agent，由其根据反馈修改代码，再重新提交检测。这一闭环流程不断重复，直到所有规则和测试全部通过，最终产出一份符合架构要求的代码。

这仅仅是验证与反馈的一部分。在大规模生成代码的过程中，难免会引入技术债，如重复代码、不符合规范的写法、命名不一致等问题，长期积累将严重破坏代码库质量。对此，OpenAI 设计了一套“垃圾回收”机制：后台持续运行一个 Codex 任务，定期扫描整个代码库，自动识别并修正偏离规范的部分，随后提交更新，从而维持代码质量的高水平。

不仅如此，文档同样面临过时与脱节的风险。因此，OpenAI 同样设置了后台任务，定期扫描文档库，发现与实际代码不符的内容后，自动提交修复。无论是代码还是文档，都有一套完整的维护方案，杜绝放任自流。

综上所述，这些实践揭示了一个核心认知：这已不再是传统意义上的“写代码”，而是在为 AI 构建一个高效、可靠的“工作环境”。人类不再亲自动手编码，而是负责定方向、搭框架、设定规则、在关键节点做判断。而具体的开发任务，则交由 Agent 在精心设计的 Harness 中自主完成。这正是 OpenAI 所倡导的核心理念——Humans steer, Agents execute（人类掌舵，Agent 执行）。

经过五个月的密集实验，OpenAI 不仅成功构建了百万行级的系统，更重新定义了人与 AI 在未来工作中的边界。他们进一步提出，软件工程师的角色并未消失，而是发生了根本转变：核心职责已从手动编码，演变为为 Agent 构建稳定、可靠的系统支撑框架，以最大化代码产出效率。

这两个观点构成了 OpenAI 文章的灵魂——Harness Engineering 并非简单的 Prompt 优化或上下文管理，而是一场对整个软件工程流程的重构。它标志着开发范式正从“人写代码”迈向“人设计系统，AI 执行任务”的新阶段。

Anthropic的三Agent架构：从单点执行到系统协同

最后需要说明的是，本文虽已对内容进行了提炼与简化，以便读者快速把握核心脉络，但原文本身信息密度极高、逻辑严密。若你对其中的技术细节感兴趣，强烈建议亲自阅读原始文章，相信必将收获深刻启发。

我们转向 Anthropic 的相关实践。他们发布了两篇与 Harness Engineering 密切相关的论文：一篇是去年 11 月发表的《Effective Harnesses for Long-Running Agents》，探讨如何配置环境以支持 Agent 长期自主运行。另一篇是今年 3 月发布的《Harness Design for Long-Running Application Development》，可视作前者的延续，在原有基础上进一步优化架构，提升对复杂任务的处理能力。

这两篇文章信息量巨大，但核心聚焦于两点：任务规划与质量评估。我们逐一来看。

首先看任务规划。在第一篇论文中，Anthropic 做了一个实验：让 Agent 直接克隆 claude.ai——即 Claude 的聊天界面。尽管表面只是一个聊天窗口，实则背后涉及大量功能模块，一次性交付几乎不可能完成。结果正如预期，Agent 接到任务后立刻投入，干劲十足，但效果极差。原因在于任务体量过大，导致 Agent 急于求成，试图一口气做完所有功能，最终上下文被撑爆，留下半成品烂摊子。

当后续 Agent 接手时，完全不清楚前序进展，只能凭猜测判断。有些功能只完成一半，却误以为已完工，草率宣布结束。这种“接力式失败”暴露了单点 Agent 在面对复杂任务时的致命缺陷。

针对此问题，Anthropic 提出解决方案：引入一个名为 Initializer 的 Agent，专门负责初始化执行环境。它的核心职责包括拆解用户需求、编写启动脚本、添加进度记录文件等。其中最关键的一环，就是将模糊的需求转化为详细的功能列表。后续的执行 Agent 只需按清单逐项完成，每完成一项就标记一次，实现稳扎稳打，极大提升流程可控性。

到了第二篇文章，Anthropic 对该思路做了进一步演化：将“需求拆解”这一核心动作独立出来，创建了一个全新的 Agent——Planner。它专门负责将用户的模糊输入扩展为一份清晰、完整、可执行的功能列表，使后续的 Generator 无需再“猜需求”，只需照单施工即可。

至此，任务规划环节得以解决，产物是 Planner。

是质量评估。仅仅生成代码远远不够，还必须对产出质量进行严格评估。如果质量不达标，应将问题反馈回 Agent，促其修改。这才是合理的闭环流程。

最初有两种评估方式：人工评估和 Agent 自评。前者效率低下，显然不适合 AI 时代。后者看似合理，实则不可靠——因为 Agent 对自己的成果天然存在“滤镜”，即使有明显 bug 也能自我美化，自评高分后草草收场。

于是 Anthropic 决定抛弃这两种方式，另辟蹊径：建立一个独立的第三方评估 Agent，称为 Evaluator。由于它是外部角色，没有利益关联，评估结果自然更加客观。更重要的是，这个评估 Agent 可以单独训练、优化，不断提升其判断能力。

因此，最终的架构是将代码生成与质量评估彻底分离：一个叫 Generator 的 Agent 负责写代码，另一个叫 Evaluator 的 Agent 负责评估输出。两者分工明确，形成协同闭环。

具体流程如下：Planner 先将用户需求拆解为功能列表，发送给 Generator。Generator 选取其中一个功能点，与 Evaluator 讨论交付标准——即“做到什么程度才算完成”。双方反复沟通，调整目标，直至 Evaluator 确认标准无误。

随后，Generator 开始编写代码，完成后提交给 Evaluator 评估。若未通过，Evaluator 返回具体问题，Generator 修改后再提交，循环往复，直到评估通过为止。一个功能点完成后，进入下一个，重复上述流程，直至所有功能点全部完成。

这个包含 Planner、Generator、Evaluator 三个 Agent 的完整体系，Anthropic 称之为 Full Harness 方案。相比之下，仅依赖单一 Generator 完成全部任务的传统模式，则被称为 Solo 方案。

为验证两者差异，Anthropic 选取了一个“游戏制作工具”的任务进行对比。结果显示，Solo 方案问题重重：布局混乱、逻辑不清、Bug 频发，基本无法使用。而 Full Harness 方案则显著改善，整体布局合理，产品逻辑清晰，已达到可用水平，尽管仍有瑕疵，但远优于 Solo 方案。

当然，这种高质量成果是有代价的。Full Harness 方案耗时约 6 小时，花费高达 200 美元。而 Solo 方案仅需 20 分钟，成本 9 美元。可见，精雕细琢必然带来更高的资源消耗。

但正如人类学习一样：考 60 分可能只需三天复习，想拿 90 分则需一个月苦功。这种投入与产出的权衡，值得深思。

最后，Anthropic 还提出一项优化：在流程图中，原本通过提示词强制要求 Generator 每次只处理一个功能点，避免其急于求成。但在 Opus 4.6 发布后，模型自身已具备更强的自律能力，此类显式约束已不再必要。

毕竟精雕细琢是有代价的。对我们人类来说也是如此：考60分可能只需要复习三天，但想拿90分，往往得花上一个月。这种感受，大家多少都体会过。

最后再提一个关键点——Anthropic 后来做的优化。让我们重新看一遍这个流程图，注意其中这一部分：它说明 Generator 每次只会选取一个功能点，做完再进入下一个，循环往复，直到完成所有任务。这个逻辑原本是 Anthropic 在提示词中强制要求 Generator 严格遵守的。因为如果不加约束，Generator 很容易急于求成，最后留下一堆烂摊子。

不过，在 Opus 4.6 发布之后，这种约束就不再必要了。Anthropic 随后直接去掉了这部分限制，流程图也简化成了现在的样子。为什么能这么做？因为基于 Opus 4.6 构建的 Generator 足够强大，它能够一次性把所有功能点全部接收过来，自主决定执行顺序，稳步推进任务，无需外部干预。在这种情况下，Evaluator 也只需评估最终产出即可，不再需要分阶段、分功能点地进行评估。

关于这一点，我们下一章节还会深入讨论，这里你只需有个大致概念就好。

在本章中，我们来探讨目前争议最大的一个问题：Harness Engineering 到底是不是一个噱头？

要回答这个问题，不妨先追溯这个词是怎么火起来的。首先，“Harness”这个词本身并不是什么新概念。通常它指为支持某个功能而构建的一套框架。比如在传统软件测试领域，就有“Test Harness”的说法，指的是为了运行测试代码而搭建的环境框架，包含测试运行器、测试环境等组件。

而在 AI 领域，开发者其实早已在默默使用这个概念。例如，有一个开源项目叫 lm-evaluation-harness，就是为支持大模型效果评估而设计的一整套框架。此外，我们之前重点讲过的 Anthropic 去年11月发布的文章《Effective Harnesses for Long-Running Agents》，其中的 “Harness” 就是指为支持 Agent 长时间运行而构建的系统框架。

争议与本质：它是噱头还是系统性思维？

由此可见，“Harness”这个概念一直存在，大家也在实际工作中使用，没人觉得这是个需要大肆宣传的新名词。真正引发关注的，是“Harness Engineering”这个组合词。

目前公认的起点，是今年2月5日发表的一篇博客《My AI Adoption Journey》，作者是 Mitchell Hashimoto。这位人物在海外技术圈可谓如雷贯耳，许多大公司的底层工具都出自他手。在这篇文章里，他写道：“我也不确定业界有没有公认的说法，姑且就叫它 Harness Engineering 吧。核心理念是：只要 Agent 犯了错，就去改造系统，让它永远不再犯同样的错误。如果将来有更好的词，我随时改。” 这番话显得非常坦诚，可见这个词的起源其实相当朴素，甚至带点随意。

从传播来看，这篇文章最初热度并不高。真正引爆这个概念的，是几天后——2月11日，OpenAI 发布的那篇题为《Harness Engineering》的文章。这篇文章信息量极大，迅速在业内掀起波澜。

紧接着，整个 AI 圈仿佛触发了连锁反应。仅六天后，也就是2月17日，软件工程领域的权威博客 Martin Fowler 官网发布了一篇题为《Harness Engineering - First Thoughts》的文章，作者是 Thoughtworks 的一位资深工程师。作为顶级技术博客，这篇文章一经发布便引发广泛讨论。

但抛开技术观点不谈，她在文中指出一个耐人寻味的细节：虽然 OpenAI 文章标题用了“Harness Engineering”，但正文里实际上只提了一次“Harness”。因此她推测，OpenAI 很可能是受到 Mitchell Hashimoto 的启发，事后才临时将这个词加到标题中。

这个猜测虽无确凿证据，却带来了巨大的联想空间。

随后在3月10日，LangChain 发布《The Anatomy of an Agent Harness》，首次明确提出关于 Harness 的公式：Agent = Model + Harness。这其实是此前我们提到的“Harness = Agent - Model”公式的另一种表达形式，本质一致。

公式一出，概念正式定调。紧接着在3月24日，Anthropic 发布其关于 Harness 的文章，提出了 Planner、Generator、Evaluator 的经典三 Agent 架构。尽管他们自己仍保持克制，全文只使用“Harness”一词，未刻意强调“Harness Engineering”，但在当时的语境下，整个 AI 圈已心照不宣——这套架构被视作 Harness Engineering 的教科书级范例。

于是，一传十，十传百，Harness Engineering 从一个人的私人说法，变成了全行业通用的术语。

但如果你复盘这段发展史，仔细琢磨，就会发现一件微妙的事：Harness Engineering 所依赖的所有技术，其实都不是全新的。我们前面讲过的 Linter 代码检查、任务拆解与规划、质量评估机制……这些技术早已存在。相信很多观众在日常工作中已经在使用类似方案。

Harness Engineering 真正做的，只是将这些已有技术重新组织起来，统一纳入一个新框架之下。换句话说，它提供的是一套新的系统思维框架，而非发明颠覆性新技术。

正因为如此，才会有人质疑：这不就是“新瓶装旧酒”吗？特意造个新词到处宣传，难道不是噱头？

仔细听这些怀疑者的观点，你会发现他们的攻击点主要有两个。

一方面，确实没有新技术，全是旧方法的整合。在这种情况下，强行包装成“革命性概念”，难免让人觉得有炒作之嫌。

另一方面，更扎心的观点是：所有的 Harness Engineering 最终都会被淘汰。他们认为，随着大模型自身能力持续进化，今天看似不可或缺的这些 Harness 设计，未来很可能会被模型自身逐步吸收，最终变得不再需要。

这种担忧，连 Anthropic 自己的文章中也有迹可循。

我们之前讲过 Anthropic 的核心方案，但文章中还有不少细节值得深挖。下面我们分析两个具体问题，看看他们是如何用 Harness Engineering 解决问题，以及当模型更强后，又如何用模型自身解决。

第一个问题是“上下文焦虑”。这是 Sonnet 4.5 存在的一个典型问题：当上下文过长时，模型会急于结束任务，以更少的 token 完成交付，从而影响输出质量。Anthropic 当初采用的解决方案是“上下文重置”技术，属于 Harness Engineering 的一种实现方式。

但到了 Opus 4.5 版本，这种现象大幅缓解，因为该模型不再表现出明显的上下文焦虑。因此，这类 Harness 工程设计也就不再必要。

第二个问题是长任务执行效果差。我们之前也提到过，Anthropic 的链路包含 Planner、Generator 和 Evaluator 三个 Agent。最初的设计是逐个功能点执行——即在提示词中强制要求 Generator 每次只处理一个功能点，做完再进入下一个，确保流程稳步推进。

你看，这恰恰印证了一个现实趋势：模型越强，所需的 Harness 就越少。大模型自身的进化，正在一点一点“吃掉” Harness Engineering 的生存空间。

当然，为了严谨起见，必须补充一点：Anthropic 官方在文章中并未如此悲观。他们认为，随着模型变强，Harness 的形态也会随之演化，去应对更复杂的任务。也就是说，Harness 不会消失，只会变形。

但我们不妨大胆推演一下：如果未来的模型真的强到离谱，会发生什么？这并非意味着模型连读写文件、联网搜索这些基础操作都不需要了，而是说——也许只需配置最基础的 Harness，模型就能自行解决剩下的99%问题。

真到那一天，Harness Engineering 就不再是需要专门研究的技术，而退化为一个单纯的环境接口或底层基础设施。

仔细想想，这种情况发生的概率恐怕并不低。

回到最初的问题：Harness Engineering 到底是不是噱头？

这是我个人的看法，仅供参考。

我的观点是：它不是噱头，但大概率也不是终局。

说它不是噱头，是因为它已经实实在在带来了效果。无论是 OpenAI 还是 Anthropic，都通过 Harness Engineering 显著提升了 Agent 的稳定性、自动化程度和生产力，这些都是可验证的工程成果，而非空谈。

当然，也有人会说：不过是“新瓶装旧酒”，用的都是老技术。但问题在于，工程领域的真正进步，往往不在于发明了什么新技术，而在于有没有一套统一的框架，能把零散的能力组织起来，变成可系统设计、可持续优化的工程方法。Harness Engineering 的意义，恰恰就在这里。

但我也不得不承认：Harness Engineering 大概率不会是终点。随着模型能力持续增强，今天用来约束、纠正、兜底模型的这些系统设计，很可能被模型自身逐步吸收。届时，许多 Harness 可能真的不再必要，这个词也可能慢慢淡出视野。

因此，我更愿意把它看作一个过渡期的关键技术。它可能不是未来的终极答案，却是当下最现实的选择。

因为回到今天，模型依然会犯错，依然会有幻觉，依然会在复杂任务中偏离轨道。在这样的现实面前，Harness Engineering 的重要性不容忽视。谁能把 Harness 搭得更稳，谁就能更早将 AI 的能力转化为真正的生产力，从而获得优势。

好了，今天的视频就到这里。我是马克，用最通俗的语言讲最硬核的技术。我们下期再见，拜拜。

---

本文由 AI 基于转写整理，仅供复查参考。