- 综合排序
- 最热优先
- 最新优先
- 来自专栏服务端技术杂谈
harness工程演进
这就是harness的价值。 harness是一套帮助Agent稳定可靠运行的闭环系统。 它就像一套让Agent自动运行的FSD，具备了全链路监控与持续优化的能力。 所以agent工程化的第一步，是需要思考的是选取什么样的agent架构驱动形式。 如果任务适合workflow，却强行采用自治agent，结果就是简单问题复杂化，效果不好。 这就引出了什么样的agent架构需要harness，显而易见的是高度自治的agent需要，harness就是给系统套上了安全带（比如状态记录/断点恢复/避免重复等）。 也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。 对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。 在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。
17310编辑于 2026-06-04 Harness 工程简史
Harness 不是凭空设计出来的。它是从"搞砸"中长出来的工程实践。这是"AI 工程三部曲"的第三篇。 篇章回答的核心问题工程层面提示词工程怎么说优化单次交互质量上下文工程让 AI 看什么管理信息输入Harness 工程怎么防止做错构建执行、验证、约束、恢复的外层系统AI 工程三部曲：《提示词工程简史》 · 《上下文工程简史》 · 《Harness 工程简史》（本文）三者合在一起，才是完整的 AI 交互工程。 这不只是 Harness 工程的定义。这是人和 AI 合作这件事，正在发生的根本转变——从依赖模型能力，到依赖系统工程能力。从"这个模型真聪明"到"这个系统真可靠"。四年。 从 AutoGPT 搞砸一个登录页面，到 Harness 工程从每一次搞砸中长成一套完整的工程学科。这条路还在走。本文基于公开论文、工程博客和开发者社区记录整理。
18600编辑于 2026-06-21大话 Harness 设计：工程如何推进闭环
在工程语境里，Harness 的意思是包裹在 Agent 外部的那套完整控制系统，让模型的能力变成可预期的、可验证的、可迭代的工程行为。 在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 到这里，我们已经讲完了 Harness 的技术层面。 但还有一个同样重要的维度，是关于工程文化和工程哲学的。 当 Agent 的产出速度开始超越人类的处理速度，整个工程团队的运作方式必须重构。 这是整个 Harness Engineering 讨论里最具人文色彩的部分：工程师在做什么？在传统软件工程里，工程师的价值体现在写出正确、高效、优雅的代码。 模型是 CPU，Harness 是操作系统。 在没有 Harness 的情况下，直接在模型上构建生产级 Agent 系统，这不是工程，这是赌博。
75111编辑于 2026-04-10Harness Engineering：Agent工程新范式
二、Harness的五根支柱OpenAI把这套方法论拆成了五个可以直接落地的组件。结构化文档项目里维护一个docs目录，作为Agent的"单一事实来源"。系统架构图、执行计划、设计规格书都放在里面。 Copilot时代，AI帮你写得更快；Harness时代，AI替你写完整个模块，你负责验收。杠杆差了一个数量级。HashiCorp、Anthropic、Cursor都在2026年跟进这个方向。 Hashimoto在2月的文章里总结得很直白：花时间去工程化一个解决方案，让Agent永不再犯同一个错误。不是什么高深理论，就是工程纪律在Agent时代的延伸。 四、Harness不是银弹它目前最适合的是边界清晰、规范明确的工程任务。API开发、数据处理管道、测试用例生成、文档维护，这些活儿的特点是输入输出可验证、有明确的通过标准、变更范围相对独立。 1500个PR背后是大量的自动化测试基础设施、精细化的文档维护成本，以及工程师角色转型的时间投入。一个团队从传统模式切到Harness模式，前期需要一到两个月搭建和磨合。
24511编辑于 2026-06-08- 来自专栏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.5K95编辑于 2026-03-25 Harness Engineering：解锁大模型潜力的“缰绳”工程
这正是“LLM Harness Engineering”——大模型缰绳工程——诞生的背景与核心使命。它不是一个高深莫测的黑科技名词，而是一个极其务实、甚至可以说是“救火”般的工程学领域。 Harness工程通过系统化的提示工程模板和输出约束，为AI设定清晰、不可逾越的指令边界。 Harness工程的核心价值，就在于同时担任“安全阀”和“油门”的角色。 Harness工程正是实现这种深度融合的“连接器”和“赋能平台”。 首先，它实现与现有系统的无缝嵌入。 开发工程师：聚焦流程编排与工具集成 对于开发者，Harness Engineering提供了将AI能力工程化、产品化的利器。
16310编辑于 2026-06-18在低代码设计中践行 Harness 工程
它提供的不是"另一种编程方式"，而是一个结构化的软件工程框架：组件是标准化的积木，事件是规范化的连接器，数据流是可视化的管道。 工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是：将 AI 的每次输出都视为需要验证的假设，通过结构化的反馈机制逐步提升输出质量。 这种"AI 提议 → 人类决策"的模式，确保了关键创意决策始终由人类掌控——这正是 Harness Engineering 中"缰绳"的具象化。 数据飞轮（Data Flywheel）是 Harness Engineering 的核心闭环机制。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
27310编辑于 2026-05-03100倍效率的秘密不是模型，是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时代高绩效工程团队的崭新信条。
33110编辑于 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里写请遵守代码规范。 这有用吗？
5100编辑于 2026-06-24- 来自专栏TGLTommyAI前沿技术论文
Agent Harness ：2026年AI工程的核心范式
Martin Fowler——软件工程领域最受尊重的声音之一——在2026年2月专门撰文提出了"Harness Engineering（线束工程）"这个术语。 这些钩子让 Harness 工程师对 Agent 行为有精确控制，而无需修改模型或 Agent 的核心逻辑。 8. 开发者必须构建允许他们随时丢弃昨天写的"聪明"逻辑的 Harness。如果过度工程化控制流，下次模型更新就会破坏你的系统。 这意味着 Harness 随时间会变得不那么重要——但就像提示工程今天依然有价值一样，Harness 工程也可能继续发挥作用。 在2026年，各大模型的基础能力已经趋于接近，真正决定 AI 产品质量的分水岭是 Harness 的设计质量——这正是从"提示工程时代"迈入"Harness 工程时代"的本质转变。
3400编辑于 2026-06-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措施，才是真正有意义的事情。
9010编辑于 2026-06-23你的 AI Coding 到底有没有工程级 Harness？
，而是更需要 Harness。 这不是洁癖，是工程问题。 这就回到了前面那句话：没有 Harness 的长任务，本质上只是更长时间的赌博。 八、写在最后：Vibe Coding 不是放弃工程，而是倒逼你更工程化 很多人对 Vibe Coding 有一个误解：好像用了 AI，就可以不懂产品、不懂架构、不懂测试、不懂工程管理。 因为真正能改变开发效率的，往往不是一句神奇 Prompt，而是你是否把 AI 放进了一套正确的 Harness 里。
19410编辑于 2026-05-26- 来自专栏【腾讯云开发者】
Harness Engineering如何工程化落地？
这一篇我就不再谈泛泛而论的“AI 很重要”“工程化很重要”。我只做一件事：拿 JK Launcher 这个真实工程做例子，把我们这一路是怎么一步一步把 Harness 搭出来的，原原本本讲清楚。 我自己现在对 Harness Engineering 的理解很简单： 它不是某一个工具，也不是某一条提示词技巧，而是一整套让 AI 在工程里稳定产出正确结果的工程系统。 如果非要打个比方，我会说： Harness Engineering 就像是在给 AI 搭一整套“工程作战系统”。 WPF 工程、Unity 工程、后端服务、工具脚本仓库，它们需要的门禁和工作流一定不一样。 但你完全可以沉淀出每类项目的“最小可用 Harness 模板”。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。 这才是工程化。
4.6K68编辑于 2026-04-22 Agent Harness 工程！被忽视的另一半
凌晨两点，AI工程群里弹出一条消息：这个AI Coding工具又双叒叕把测试代码注释掉了，commit了一个半成品。紧接着是一连串苦笑的表情。 这种场景，对AI技术圈的朋友来说，应该不陌生。 模型是发动机，但Harness是传动系统、方向盘、刹车片。没有后者，前者再强也只是实验室里的玩具。 Harness都包含什么？ 有意思的是Viv Trivedy提出的那个等式：Agent = Model + Harness。如果你不是模型，那你就是Harness。 这句话听起来简单，但把它当真的人不多。 大多数工程师遇到agent犯蠢，第一反应是"这破模型"，然后把issue丢给供应商等下一版本。 很少有人意识到，问题可能出在自己搭的那层脚手架上。 这就是所谓的Harness Gap。 你今天让某个模型"能做到"的事情，和它在你手里实际"做成"的事情之间，隔着一个Harness。
3100编辑于 2026-06-24- 来自专栏111222444
Agent Harness
Agent Harness（智能体驾驭层/运行框架） 是包裹在大模型（LLM）之外、让它能真正执行任务而非只"说"不"做"的那整套工程运行时基础设施。 业界共识公式：Agent = Model（大模型）+ Harness（驾驭层） 为什么叫 Harness？ 类比帮助理解 Model = CPU，Harness = 操作系统（OS）——CPU 再强没有 OS 也跑不了应用 Model = 主厨大脑（决定怎么做菜），Harness = 厨房+炉灶+帮厨（ 真正点火翻面装盘） Claude Code / Cursor Agent / OpenCode 本质上就是围绕某模型构建的 Agent Harness，所以同一模型配上不同 Harness 体验差异巨大 一句话：Harness 就是把"会说话的大模型"变成"能干活的自主智能体"的工程运行时。
15730编辑于 2026-06-11 Harness Engineering：当工程师不再亲手写代码
HarnessEngineering：当工程师不再亲手写代码OpenAI最近发了一篇工程文章，题目是Harnessengineering:leveragingCodexinanagent-firstworld 最开始是3个工程师在驱动Codex，后来团队扩到7个人，整体交付吞吐量没有下降，还继续提高了。后面主要讲的是工程师角色怎么变化：当代码不再是主要产出，工程重心会往哪一层移动。 工程师的工作被重新定义了文章里有一句很重要：人类工程师的主要工作，不再是写代码，而是设计环境、指定意图、建立反馈循环，让Codex能稳定地做可靠工作。文章后面给了很多具体细节，把这句话落了下来。 吞吐量上来以后，mergephilosophy也变了随着Codex吞吐量越来越高，他们发现很多传统工程规范开始变得不合适。 很多原本默认正确的工程哲学，本身就要跟着改。“agent-generated”到底是什么意思文章专门解释了一次，什么叫“整个代码库由Codex生成”。
50610编辑于 2026-04-10- 来自专栏Harness合集
10｜Agent Harness 的未来：从代码助手到工程协作系统
AI不再只是给建议，而是能进入仓库、读取上下文、修改文件、运行测试、连接外部工具，参与真实工程流程。下一步，它会从“代码助手”变成“工程协作系统”。 模型只负责推理，Harness要负责把任务过程保存下来。趋势二：从单Agent到多Agent协作复杂工程任务天然需要分工。 未来Harness会越来越像研发平台的一部分：谁让Agent做了什么，读了哪些文件，跑了哪些命令，改了哪些代码，调用了哪些外部系统，都要能审计。 工程师的价值会更多体现在：定义正确问题；拆分任务边界；设计验证标准；判断架构取舍；审查安全和兼容性；决定什么时候交付。AI可以写很多代码，但“该不该这么写”仍然需要工程判断。 真正可靠的方向是：展开代码语言：TXTAI代码解释AI做执行Harness做约束工具做验证人做判断这也是AI编程从个人效率工具走向团队工程系统的关键。
17300编辑于 2026-06-09 ClaudeCode-Harness Engineering驾驭者工程的最佳实践者
今天继续跟着我和Claude学习Harness Engineering驾驭者工程。这个我在前面就谈到了是AI编程工程化的一个重点，核心是让AI软件工程更加安全，可控，可靠的运行。 在前面我就提出过一个观点，其实ClaudeCode这个编程工具就是Harness工程的最佳实践者。所以这篇文章看下Claude自身是如何进一步解释该事情。 关于本文：本文基于对 Claude Code 六大核心维度的深度研究，从 Harness Engineering（驾驭工程）哲学视角重新审视 Claude Code 的设计逻辑。 Claude Code 被真正广泛采用的背后，是一套经过深思熟虑的设计哲学——Harness Engineering（驾驭工程）。 在引入 AI 工具时，抵制"把所有摩擦都去掉"的冲动，往往是更成熟的工程判断。 六、结语 软件工程的历史一再表明：真正持久的生产力提升，来自驾驭复杂性，而不是消灭复杂性。
2.6K42编辑于 2026-04-13- 来自专栏前端小羊
Agent Harness
Harness Agent（或称 Agent Harness） 不是某个具体产品名，而是指给大模型套上"工程外壳"后形成的、可自主执行任务的完整智能体系统。 核心定义 业界共识公式： Agent = Model（大模型）+ Harness（驾驭层/运行框架）Model：负责推理、理解、生成文本（LLM 本身只会 input→output）Harness：模型之外的一切工程设施 Harness 阶段：你说"修复登录 Bug 并跑测试"，Harness 自动拆任务→读代码→改文件→跑测试→看结果→再修正，直到完成或触发人工介入。 一句话理解 裸 LLM 是"会说话的引擎"，Harness 是"方向盘+刹车+仪表盘+道路规则"，二者结合才是能上路干活的 Harness Agent（完整智能体）。 开发重点从"调模型"变成了"设计好 Harness 让模型可靠自主地工作"。
35810编辑于 2026-06-11 AgentScope Java 深度解析：企业级 Harness 工程化框架
本文将深入剖析 AgentScope Java 如何通过 Harness 工程化能力，解决智能体从原型到生产的关键挑战。 工程化系统解决这些问题。 二、Harness 工程化：核心架构 ▪ 2.1 Hook 系统：可控性的保障 Hook 是 AgentScope Java 最核心的创新。 、响应式、GraalVM 七、总结 AgentScope Java 的核心价值在于： 不是简单的 Java 移植，而是为企业级生产重新设计 核心优势： Hook 系统提供可控性 Harness 工程化开箱即用 响应式架构高并发 GraalVM 支持极致性能 设计权衡： 以 JDK 17+ 换取现代特性 以响应式换取高并发 以复杂度换取工程化 适用定位： 企业级生产部署的工程化框架 如果你的场景是微服务、企业应用
60910编辑于 2026-06-04
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号