- 综合排序
- 最热优先
- 最新优先
Harness 工程简史
Harness 不是凭空设计出来的。它是从"搞砸"中长出来的工程实践。这是"AI 工程三部曲"的第三篇。 篇章回答的核心问题工程层面提示词工程怎么说优化单次交互质量上下文工程让 AI 看什么管理信息输入Harness 工程怎么防止做错构建执行、验证、约束、恢复的外层系统AI 工程三部曲：《提示词工程简史》 · 《上下文工程简史》 · 《Harness 工程简史》（本文）三者合在一起，才是完整的 AI 交互工程。 这不只是 Harness 工程的定义。这是人和 AI 合作这件事，正在发生的根本转变——从依赖模型能力，到依赖系统工程能力。从"这个模型真聪明"到"这个系统真可靠"。四年。 从 AutoGPT 搞砸一个登录页面，到 Harness 工程从每一次搞砸中长成一套完整的工程学科。这条路还在走。本文基于公开论文、工程博客和开发者社区记录整理。
23000编辑于 2026-06-21- 来自专栏服务端技术杂谈
harness工程演进
这就是harness的价值。 harness是一套帮助Agent稳定可靠运行的闭环系统。 它就像一套让Agent自动运行的FSD，具备了全链路监控与持续优化的能力。 所以agent工程化的第一步，是需要思考的是选取什么样的agent架构驱动形式。 如果任务适合workflow，却强行采用自治agent，结果就是简单问题复杂化，效果不好。 这就引出了什么样的agent架构需要harness，显而易见的是高度自治的agent需要，harness就是给系统套上了安全带（比如状态记录/断点恢复/避免重复等）。 也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。 对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。 在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。
18810编辑于 2026-06-04 Harness Engineering：Agent工程新范式
二、Harness的五根支柱OpenAI把这套方法论拆成了五个可以直接落地的组件。结构化文档项目里维护一个docs目录，作为Agent的"单一事实来源"。系统架构图、执行计划、设计规格书都放在里面。 Copilot时代，AI帮你写得更快；Harness时代，AI替你写完整个模块，你负责验收。杠杆差了一个数量级。HashiCorp、Anthropic、Cursor都在2026年跟进这个方向。 Hashimoto在2月的文章里总结得很直白：花时间去工程化一个解决方案，让Agent永不再犯同一个错误。不是什么高深理论，就是工程纪律在Agent时代的延伸。 四、Harness不是银弹它目前最适合的是边界清晰、规范明确的工程任务。API开发、数据处理管道、测试用例生成、文档维护，这些活儿的特点是输入输出可验证、有明确的通过标准、变更范围相对独立。 1500个PR背后是大量的自动化测试基础设施、精细化的文档维护成本，以及工程师角色转型的时间投入。一个团队从传统模式切到Harness模式，前期需要一到两个月搭建和磨合。
27211编辑于 2026-06-08大话 Harness 设计：工程如何推进闭环
在工程语境里，Harness 的意思是包裹在 Agent 外部的那套完整控制系统，让模型的能力变成可预期的、可验证的、可迭代的工程行为。 在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 到这里，我们已经讲完了 Harness 的技术层面。 但还有一个同样重要的维度，是关于工程文化和工程哲学的。 当 Agent 的产出速度开始超越人类的处理速度，整个工程团队的运作方式必须重构。 这是整个 Harness Engineering 讨论里最具人文色彩的部分：工程师在做什么？在传统软件工程里，工程师的价值体现在写出正确、高效、优雅的代码。 模型是 CPU，Harness 是操作系统。 在没有 Harness 的情况下，直接在模型上构建生产级 Agent 系统，这不是工程，这是赌博。
77011编辑于 2026-04-10在低代码设计中践行 Harness 工程
它提供的不是"另一种编程方式"，而是一个结构化的软件工程框架：组件是标准化的积木，事件是规范化的连接器，数据流是可视化的管道。 工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是：将 AI 的每次输出都视为需要验证的假设，通过结构化的反馈机制逐步提升输出质量。 这种"AI 提议 → 人类决策"的模式，确保了关键创意决策始终由人类掌控——这正是 Harness Engineering 中"缰绳"的具象化。 数据飞轮（Data Flywheel）是 Harness Engineering 的核心闭环机制。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
28710编辑于 2026-05-03Harness Engineering：解锁大模型潜力的“缰绳”工程
这正是“LLM Harness Engineering”——大模型缰绳工程——诞生的背景与核心使命。它不是一个高深莫测的黑科技名词，而是一个极其务实、甚至可以说是“救火”般的工程学领域。 Harness工程通过系统化的提示工程模板和输出约束，为AI设定清晰、不可逾越的指令边界。 Harness工程的核心价值，就在于同时担任“安全阀”和“油门”的角色。 Harness工程正是实现这种深度融合的“连接器”和“赋能平台”。 首先，它实现与现有系统的无缝嵌入。 开发工程师：聚焦流程编排与工具集成 对于开发者，Harness Engineering提供了将AI能力工程化、产品化的利器。
18310编辑于 2026-06-18- 来自专栏MixLab科技+设计实验室
Harness Engineering 是什么？从上下文工程到驾驭工程
Harness Engineering 驾驭工程：通过构建受控环境，让AI在约束下高效可靠地工作。 想象AI是一匹拥有神力的独角兽，它力量强大但难以预测。 这不是魔法，这是一个正在被正式命名的工程实践：Harness Engineering。 再之后，知名工程师 Martin Fowler 在 Twitter 上为 Thoughtworks 工程师对这份报告的深度分析站台。 Harness 到底在做什么 根据 OpenAI 官方报告的描述，Harness 由三个核心类别组成： 第一层：Context Engineering（上下文工程）。 Harness 就是 AI Agent 的脚手架。 OpenAI 团队花了 5 个月时间来构建和完善他们的 Harness。 这不是某种「快速见效」的技巧，而是一个需要持续投入的系统工程。
13.6K95编辑于 2026-03-25 - 来自专栏TGLTommyAI前沿技术论文
Agent Harness ：2026年AI工程的核心范式
Martin Fowler——软件工程领域最受尊重的声音之一——在2026年2月专门撰文提出了"Harness Engineering（线束工程）"这个术语。 这些钩子让 Harness 工程师对 Agent 行为有精确控制，而无需修改模型或 Agent 的核心逻辑。 8. 开发者必须构建允许他们随时丢弃昨天写的"聪明"逻辑的 Harness。如果过度工程化控制流，下次模型更新就会破坏你的系统。 这意味着 Harness 随时间会变得不那么重要——但就像提示工程今天依然有价值一样，Harness 工程也可能继续发挥作用。 在2026年，各大模型的基础能力已经趋于接近，真正决定 AI 产品质量的分水岭是 Harness 的设计质量——这正是从"提示工程时代"迈入"Harness 工程时代"的本质转变。
21800编辑于 2026-06-25 技术圈爆火新词：Harness 工程，OpenAI 和 Anthropic 都在卷这个！
这两个月，AI 圈子里“Harness Engineering（Harness 工程）”突然刷屏。 很多人第一反应是：这是 Harness 那家 DevOps 公司的新概念？ 一句话讲透： Harness 工程 = 把“大模型的能力”驯化成“稳定生产力”的工程体系。 OpenAI 内部实验：3-7 人团队用 Codex Agent，从空仓库起步，零人工写代码，5 个月生成 100 万行生产代码、1500 个 PR，日均 3.5 PR/人。 Harness 工程到底在搭什么“AI 工作底座”？ 它本质上是给 Agent 建一套完整的管理体系： 1. • Harness Engineering = DevOps + 平台工程 + AI Agent 运行控制。
1K10编辑于 2026-04-15技术圈爆火新词：Harness 工程，OpenAI 和 Anthropic 都在卷这个！
大家好我是舒一笑不秃头，喜欢写作和分享，更多精彩内容～这两个月，AI圈子里“HarnessEngineering（Harness工程）”突然刷屏。 一句话讲透：Harness工程=把“大模型的能力”驯化成“稳定生产力”的工程体系。Agent=Model+Harness模型负责“会不会”，Harness负责“能不能稳定、安全、可控地上生产”。 OpenAI内部实验：3-7人团队用CodexAgent，从空仓库起步，零人工写代码，5个月生成100万行生产代码、1500个PR，日均3.5PR/人。 以前卷“模型够不够聪明”，现在卷“你能不能让模型在真实工程里持续产出价值”。Harness工程≠PromptEngineering升级版PromptEngineering优化的是“单轮回答质量”。 Harness工程到底在搭什么“AI工作底座”？
48810编辑于 2026-04-12100倍效率的秘密不是模型，是Harness工程
全文信息密度很高，以下是核心内容：用AI coding agent的人比用Cursor聊天的人效率高10到100倍，比2005年的Google工程师高1000倍。这是真实数字。 他把方法论叫Thin Harness, Fat Skills。Harness是跑模型的程序，只管四件事：循环调模型、读写文件、管上下文、做安全检查。保持薄。 五个概念组成三层：顶上fat skills（90%的价值），中间thin harness（约200行代码），底下deterministic工具。 能力尽量交给skill，执行尽量交给确定性工具，harness越薄越好。模型一升级，所有skill自动变强。 这一理念正成为AI时代高绩效工程团队的崭新信条。
34110编辑于 2026-04-15Prompt升职了，多亏了 Harness 和 Loop 工程
2026年中，AI工程圈子里最热的讨论，已经从怎么写好一条Prompt变成了怎么设计一个能自己跑的Agent系统。 这个转变背后，其实是两套新范式的成熟：Harness工程和Loop工程。 Harness工程：给Agent造一个能干活的车间 先说个扎心的对比。 你写了一条Prompt：作为资深后端工程师，请review这段Python代码，遵循PEP8规范，检查潜在bug。 Prompt工程优化的是这一次，而真实生产环境需要的是每一次都一样靠谱。 Harness工程解决的就是这个问题。 Harness这个词，直译是马具——套在马身上用来传递力量和控制方向的那套装备。 Lopopolo说了一句很直接的话：当你的工程团队不再以写代码为主业，而是以设计环境、定义意图、搭建反馈回路为主业的时候，Harness就是那个核心产出。 这不是Prompt能解决的问题，这是工程问题！ 第二层是控制与验证层，这是Harness区别于普通Prompt工程的关键。 一个经典场景：你在Prompt里写请遵守代码规范。 这有用吗？
13100编辑于 2026-06-24- 来自专栏ypw
算法3-7：银行排队
题意：就是多个窗口服务，每次来的人选择一个等待时间最短的窗口。问所有人的平均等待时间
1.2K20发布于 2021-04-25 AI工程圈大辩论：Big Model VS Big Harness？
在AI工程领域，最近也掀起了一场这样的争论。 一边是Big Model派，认为模型本身才是王道；另一边是Big Harness派，坚信框架工程才是关键。 Image Big Harness派的反击：姿势不对一切白费 但Big Harness派不同意。他们认为，Harness就是产品本身。 LlamaIndex创始人Jerry Liu说得更直接："模型框架就是一切——从AI获取价值最大的障碍，就是你自己对模型进行上下文和工作流工程的能力。工具越通用，这一点就越重要。" 随着Agent Labs的理论得到验证（Cursor估值已达500亿美元），我们不得不承认"Harness Engineering"确实有价值。 对于，AI来讲，我们也要适应AI能力提升以及环境不同，采用不一样的Harness措施，才是真正有意义的事情。
10910编辑于 2026-06-23Harness Engineering：当工程师不再亲手写代码
HarnessEngineering：当工程师不再亲手写代码OpenAI最近发了一篇工程文章，题目是Harnessengineering:leveragingCodexinanagent-firstworld 最开始是3个工程师在驱动Codex，后来团队扩到7个人，整体交付吞吐量没有下降，还继续提高了。后面主要讲的是工程师角色怎么变化：当代码不再是主要产出，工程重心会往哪一层移动。 工程师的工作被重新定义了文章里有一句很重要：人类工程师的主要工作，不再是写代码，而是设计环境、指定意图、建立反馈循环，让Codex能稳定地做可靠工作。文章后面给了很多具体细节，把这句话落了下来。 吞吐量上来以后，mergephilosophy也变了随着Codex吞吐量越来越高，他们发现很多传统工程规范开始变得不合适。 很多原本默认正确的工程哲学，本身就要跟着改。“agent-generated”到底是什么意思文章专门解释了一次，什么叫“整个代码库由Codex生成”。
51610编辑于 2026-04-10- 来自专栏后端agent harness学习路径
后端学agent harness系列：从 Prompt 到 Harness，2026 为什么是后端工程师的主场
AI 工程范式演进（一）：从 Prompt 到 Harness，2026 为什么是后端工程师的主场系列第 1 篇。 赛道三：Harness 工程。 Harness 工程打破了这个模型。在 harness 范式中，人不再逐次给输入，而是设计一个让 agent 自主运行的赛道。 五、为什么后端工程师是 Harness 工程的天然人选最后，让我们面对一个现实问题：谁应该做 Harness Engineering？不是 AI 研究员——他们的注意力在模型本身。 欢迎来到 Harness 工程元年。
11710编辑于 2026-06-30 - 来自专栏【腾讯云开发者】
Harness Engineering如何工程化落地？
这一篇我就不再谈泛泛而论的“AI 很重要”“工程化很重要”。我只做一件事：拿 JK Launcher 这个真实工程做例子，把我们这一路是怎么一步一步把 Harness 搭出来的，原原本本讲清楚。 我自己现在对 Harness Engineering 的理解很简单： 它不是某一个工具，也不是某一条提示词技巧，而是一整套让 AI 在工程里稳定产出正确结果的工程系统。 如果非要打个比方，我会说： Harness Engineering 就像是在给 AI 搭一整套“工程作战系统”。 WPF 工程、Unity 工程、后端服务、工具脚本仓库，它们需要的门禁和工作流一定不一样。 但你完全可以沉淀出每类项目的“最小可用 Harness 模板”。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。 这才是工程化。
4.8K68编辑于 2026-04-22 你的 AI Coding 到底有没有工程级 Harness？
，而是更需要 Harness。 这不是洁癖，是工程问题。 这就回到了前面那句话：没有 Harness 的长任务，本质上只是更长时间的赌博。 八、写在最后：Vibe Coding 不是放弃工程，而是倒逼你更工程化 很多人对 Vibe Coding 有一个误解：好像用了 AI，就可以不懂产品、不懂架构、不懂测试、不懂工程管理。 因为真正能改变开发效率的，往往不是一句神奇 Prompt，而是你是否把 AI 放进了一套正确的 Harness 里。
20610编辑于 2026-05-26Agent Harness 工程！被忽视的另一半
凌晨两点，AI工程群里弹出一条消息：这个AI Coding工具又双叒叕把测试代码注释掉了，commit了一个半成品。紧接着是一连串苦笑的表情。 这种场景，对AI技术圈的朋友来说，应该不陌生。 模型是发动机，但Harness是传动系统、方向盘、刹车片。没有后者，前者再强也只是实验室里的玩具。 Harness都包含什么？ 有意思的是Viv Trivedy提出的那个等式：Agent = Model + Harness。如果你不是模型，那你就是Harness。 这句话听起来简单，但把它当真的人不多。 大多数工程师遇到agent犯蠢，第一反应是"这破模型"，然后把issue丢给供应商等下一版本。 很少有人意识到，问题可能出在自己搭的那层脚手架上。 这就是所谓的Harness Gap。 你今天让某个模型"能做到"的事情，和它在你手里实际"做成"的事情之间，隔着一个Harness。
9600编辑于 2026-06-24- 来自专栏python3
3-7 run vs cmd vsent
docker build -t xiaopeng163/centos-entrypoint-shell .
44020发布于 2020-01-14
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号