大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



文章总结： 文章探讨了在大模型发展进入瓶颈期的背景下，HarnessEngineering（驾驭工程）如何成为提升AI生产力的核心。它指出，Harness的本质是一种工程思想和工作哲学，旨在通过为AI构建高度可观测、可自动验证的执行环境，来解决人类注意力稀缺的问题，并减少人工干预。文章以作者在IRify项目中的实践为例，详细说明了如何通过沉淀专属Skills、优化AI运行环境等方式，将Harness思维应用于日常开发，从而真正驾驭复杂系统，提升自我价值。 综合评分： 85 文章分类： AI安全,安全开发,解决方案,技术标准,实战经验

---

原创

YAK YAK

Yak Project

2026年4月17日 17:44 湖南

在小说阅读器读本章

去阅读

2026年，大模型能力被普遍认为进入了高原期：单纯依靠算力堆积的暴力美学，其边际收益已经大幅降低，同时高质量的人类训练语料也趋近枯竭。面对这一瓶颈，业界的焦点开始发生转移：大家普遍认为，单纯比拼模型的时代正在远去，比拼Harness Engineering（驾驭工程）的时代已经到来。这就好比制造汽车时，将其发动机的马力已经压榨到物理极限了，再想提升整辆车的性能，就不能只盯着发动机，而要把目光投向传动系统、方向盘等驾驭发动机的系统上。

正是在这一背景下，Harness Engineering这个词开始频繁刷屏各大媒体，被包装成又一项了不起的前沿AI技术。然而，这种宏大的叙事却让人感到十分割裂：对于绝大多数不开发底层Agent的普通开发者而言，Harness听起来更像是一个与己无关的伪概念。它除了徒增技术快速迭代带来的焦虑感，似乎并没有对日常的开发工作产生实质性影响。

如今的AI产业，正呈现出一种大厂主导前行、普通人带着焦虑被动跟随的局面。事实上，普通开发者每天赖以生存的 Claude Code、Codex 、Cursor 等优秀AI编程工具，正是Harness Engineering的**实践产物。 然而，在使用这些工具时，我们往往陷入了一种疲惫的循环：开发过程中每天花大量时间在聊天窗口里给AI提需求，看着AI一行行地写出新功能，然后自己再手动切回系统去查看和验收。在这种“AI写代码，人打下手”的模式中，我有时候不禁感慨：我应该为高效完成工作高兴，还是为这种低价值劳动奔波难过。

哭笑不得以后，我脑海里就有这么个疑问：同样是置身于Harness Engineering浪潮中，为什么行业大厂认为这是大模型能提供生产力的核心，而我们普通开发者，明明每天都在享受其**实践、生产效率大幅度提升，自我价值却在一轮轮AI对话中不断降低？

我认为要回答这个问题，我们或许可以回到OpenAI最早发布关于Harness Engineering原文中，探究Harness最开始出现要解决什么问题。原文中，有大量篇幅讲解其工程实践细节：设计环境、反馈回路和控制系统，但是是我认为其最核心的，也是文章作者开头就点出的一点：为了解决人类的时间与精力是稀缺的问题。

原文中谈到，OpenAI 内部有个百万级项目需要让AI参与开发，并在几周内进行交付。按照传统AI协作开发模式，Agent产生PR，而人则作为质量的把关者，将会面临一个极大的问题：AI产生代码的速度远远快于人们验证代码的速度。人这一环成为开发流程的瓶颈。而更要命的是，如果AI实现的某项功能不符合要求，你就不得不对其进行对话、等待其修复、再次验证其实现效果。如果AI不能一次就修复好这个问题，人就不得不陷入这种循环中，并在这种循环中把精力消耗得筋疲力尽。这种开发流程就像一个大漏斗，而人类这一环却成了最窄的那个口。为了解决这个最窄的口，OpenAI不断优化大模型的执行环境，并把这个过程叫做Harness Engineering。

所以不难发现，Harness思维解决的核心痛点，不仅是AI持续工作的稳定性，更是人在AI时代的“注意力稀缺”。回顾编程的演进路径，你会发现人类焦点的变迁。在前AI时代，人类将100%的注意力完全倾注在写代码和实现功能上。而到AI辅助写代码时代（IDE插件)，AI成为代码补全的工具，但人类的注意力依然被绑死在具体的实现步骤上。如今进入了Agent自主编程时代，模型具备了自主执行能力。此时，如果人类依然保持旧习惯，就会陷入极其消耗注意力的死循环：AI在聊天窗口执行任务，人手动切到系统里点击、编译、测试验收。

要打破这种极度消耗注意力的死循环，就必须保证AI自主可靠的运行，并减少人这一环的参与。而为AI构建高度可观测、可自动验证的执行环境，仅仅是具体的工程步骤。笔者认为Harness更本质的是提醒我们应该“反思并管理注意力”。具体的改造手段并不重要，重要的是你必须在自己的日常开发中，敏锐地识别出：到底是什么“阻塞点”在无情地占据和消耗你最多的注意力时间？一旦找到了这个阻塞点，你就要主动出击，为它立下规矩、建好环境，把这部分验证工作甩给AI。这，才是属于每一个普通开发者的Harness。

对于如何“主动管理注意力”，我在近期推进IRify规模化时有着切身体会。在这个项目中，我经历了一次从“越用AI越累”到“为其建立Harness工作流”的真实转变。

这几个月，我的任务是将IRify从客户端代码扫描升级为分布式扫描。这不仅涉及复杂的并发方案和状态流转，还包含大量SaaS系统业务功能的脏活累活(Dirty Work)。为了抢进度，我开了多个AI Agent终端并行开发。AI写代码确实快，但麻烦也随之而来：代码冲突频发；而且作为带有前端交互的SaaS系统，很难单纯靠单元测试保障功能可用。结果就是，AI每吐一个功能，我就得手动启动页面、登录、点击、查错。缺乏规矩的AI跑得越快，我作为人肉测试员的注意力就被消耗得越严重。

为了改变这种被动局面，我开始尝试为AI构建Harness执行环境。首先，我给AI全局提示词加了约束：强制它使用独立的 worktree 进行开发，从物理上隔离代码冲突；其次，要求AI每次实现一个功能以后必须有测试落地，对于比较难测的功能点可以编写E2E测试脚本，甚至进行日志插桩进行测试；最后，为了方便前端功能的验收，我让他加了个Chrome DevTool，以便完成任务后可以进行前端功能截图。

如果你读过OpenAI的原文，或许会发现这些举措极为眼熟。没错，我其实就是把Harness的原文直接喂给了AI，让它参照这套**实践来进行自我改造。回顾这个过程我发现，普通人实践Harness并没有多么高深，它的本质就是“有意识地让AI的运行环境变得更好、阻力更小”。我所做的，只不过是主动把业界的**实践投喂给它，顺水推舟地让AI自己去蹚平道路，改造出它专属的执行环境而已。这一番改造后，我终于可以一次性下发大量任务：AI写完代码会自动验证，发现错误就回炉重造，而我只需安稳地留在“最终验收”的环节。

然而，随着AI自动跑通的流程越来越多，我发现了影响我注意力的一个新阻塞点：验收的时候需要花费大量时间查看AI的总结文本与截图。由于运行在终端的AI无法直接展示图片，每天面对它扔过来的一大堆零散文本和截图路径，我必须手动挨个去文件夹里点击查看。特别是在多任务并行时，光是“把截图和任务对上号”就要耗费我极大的脑力。为了彻底回收我的注意力，我意识到：Harness不仅要让AI自动干活，还要让它以“认知负荷最低”的方式来汇报。于是，我扣动了最后一块Harness拼图：强制AI在每次完成任务后，将所有验证结果和截图严格按照“报纸排版”的格式输出。因为报纸的图文混排，是数百年来沉淀下的、最契合人类视觉检索和吸收信息的媒介。如今，我只需像读晨报一样扫一眼这些图文并茂的总结，就能一键验收所有的功能，俗称“赛博看报”~

“赛博看报”示意图

AI自动截图示意图

事实上，有意识地为AI扫清运行阻力，我们可以借助很多工具。你可以编写 Python 或 Shell 脚本让AI固定执行某项操作，也可以固化提示词让它精准理解任务意图。当“脚本”与“提示词”相结合，就产生了一个这两年极火的概念：Skills 。我们会去寻找热门好用的Skills，给我们Agent插上翅膀。但笔者认为，真正的Harness思维要求我们：不要只做Skills的消费者，而要主动在复杂的业务中“沉淀”出自己的专属Skills。

这种“沉淀”在处理长链条复杂任务时，能爆发出惊人的威力。以笔者近期对IRify做BenchMark（基准测试）验证为例：我需要让AI扫描具体项目、找出漏报误报、修复规则，最后再补充测试将内容固化下来。如果在传统的AI对话模式下，这个过程存在三大“注意力黑洞”：一是任务链条极长，需要反复横跳；二是AI不懂特定的规则语法（SyntaxFlow），每次都要花大量时间参考旧规则；三是项目内测试套件繁多，AI经常像无头苍蝇一样找不到添加测试的正确位置。如果按照以前对话式让AI执行任务，AI效率低不说，如果出错我还得继续对话提醒它，会把我折磨得够呛。但现在，当我耐着性子，在一次对话中把这套包含环境配置、背景知识和执行逻辑的工作流彻底跑通后，我直接将它“沉淀”为了专属Skill。后续面对同样的需求，我只需一键触发，AI就能在最小阻力下自动执行，彻底免去了反复对话和调教的煎熬。

IRify业务沉淀的Skill

经历了这些实战，我越发确信：Harness 绝不仅仅是几行脚本或几组提示词，它本质上是一种工程思想，更是一种工作哲学/方法论。 其实更进一步讲，这也不是新的东西，不过是新瓶装旧酒，其核心就是DevOps、流程工程、自动化这些工程思维，只是因为AI语境加持下像新的革命。但是也应该承认，它确实提醒我们应该转变工作思维。诚然，业界已经有了 Claude Code 这样优秀的**实践产品，但它们绝不是一招打遍天下的“万能解药”。在千差万别、充满各种“脏活累活”的真实日常项目中，没有哪个现成的工具能完美契合所有人的工作流。这就要求我们每一个普通开发者，必须在日常工作中时刻保持这种 Harness 意识。

笔者认为日常开发中可以从两方面使用这种工作哲学。对于我们自己，要敏锐地识别出自己宝贵的“注意力”到底流失在了哪里，主动把它们抢夺回来；对于AI，我们则要转换身份，作为“辅助者”去观察它在执行任务时的“阻塞点”在哪里，并主动为它修桥铺路、优化运行环境。

当然仅仅从“Agent使用者”这个角度要有Harness工作哲学，我认为“Agent开发”更需要这种哲学。 我时常听到做Agent开发的朋友，认为他们自己在造的是和Claude Code、Codex一样的轮子。但是我认为他们更像是把各种轮子组装起来，以适合具体行业的垂直业务。世上并不存在能完美适配所有场景的“通用Agent”，有时候我们认为某些Agent如此强大，是因为大模型本身能力强占据很大一部分功劳。但是当模型能力发展达到一定瓶颈，识别模型在具体场景运行的阻塞点，并将其运行环境改造，我认为还是十分有价值的。

最近发布的新产品Memfit，我觉得就能够很好地阐述这种哲学。Memfit是为网络安全领域设计的Agent，它能够胜任渗透测试等非确定任务。与需求明确的编程任务不同，渗透测试是高度“发散”和非确定性的：AI只能边收集信息边摸索测试路径，且随时会被新发现的情报改变走向。这种不确定性，注定了 MemFit 无法照搬 Claude Code 的设计哲学。以最核心的“Plan（规划）模式”为例：常规编程Agent会严格、刻板地执行既定Plan；而 Memfit 的Plan则是实时“生长”的——它会根据执行中收集到的新信息，动态修正和重写后续的测试计划。

不迷信通用的刻板流程，为不确定性定制能自我纠偏的运行环境，我认为这才是Harness。无论是面对 IRify 这样需求明确的常规开发，还是 Memfit 这种充满未知的渗透测试，Harness 的内核其实从未改变。它要求我们跳出“被动执行”的框架，去洞察具体业务场景下的真实阻力，进而为 AI 量身定制最合适的运行规则。真正实用的生产力，并不单纯依赖一个万能的大模型，而是依赖契合具体业务的Harness 执行环境。

我深感这两年AI发展对编程方式变化非常大。回想两年前，还需要整日整日看底层SSA的代码，不断调整某个具体函数怎么写；一年前则是不断与Cursor对话，去完善具体某个功能的细节；而现在，则需要去构建属于你自己的自动化执行环境，告诉它要去哪里，然后让它自己找路。当我们不再被动地当一个疲于奔命的“代码审查机”，而是亲手为 AI 扫清障碍时，我们便蜕变成了真正驾驭复杂系统的主人。到那时，那种久违的、自我价值实现的快乐，才算真正回到了我们手中。

参考文献：

OpenAI. (2026). 工程技术：在智能体优先的世界中利用 Codex (Harness Engineering). 检索自: https://openai.com/index/harness-engineering/

汤道生. (2026). 人工智能正式进入 Harness 时代. 腾讯云与智慧产业事业群.

黄佳. (2026). 从GoF到Agent，设计模式30年演进与Harness革命.

V1ll4n. (2026). MemfitAI: 连续渗透测试N小时不迷路的生产级AI Agent. Yak Project.

The Architect ofConnectivity: A Comprehensive Technical Analysis of Modern Harness Engineering. (2026).

Datawhale.(2026).最新！万字综述Harness革命！

END

更新记录

Yakit  v1.4.6-0417

1. MIMT规则正则支持多次
2. MITM高级配置缩小窗口点击不了关闭按钮
3. History MITM发送到webfuzzer http开头的不带强制HTTPS 国密国密 随机TLS配置
4. WebFuzzer 共用热加载配置放到热加载tab里
5. 数据写入慢提示可在全局配置中关闭提醒
6. 修复中英文切换部分展示问题

Memfit AI v1.0.1-0417

1. 工具卡片增加显示参数
2. 任务优化为展示当前任务和历史未完成任务，并可从任意节点继续未完成任务
3. 数据统计增加上下文大小分类变化趋势，以及上下文详情
4. 修复文件系统数据过多展示错误的问题
5. 技能和工具优先展示中文，没有中文显示英文
6. 修复配置里“禁用工具运行时AI审查”未保存的问题

YAK官方资源

Yak 语言官方教程： https://yaklang.com/docs/intro/ Yakit 视频教程： https://space.bilibili.com/ Github下载地址： https://github.com/yaklang/yakit Yakit官网下载地址： https://yaklang.com/ Yakit安装文档： https://yaklang.com/products/download_and_install Yakit使用文档： https://yaklang.com/products/intro/ 常见问题速查： https://yaklang.com/products/FAQ

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Yak Project YAK

 YAK《Harness 到底是什么？揭秘 IRify 规模化背后的“注意力保卫战”》