- 综合排序
- 最热优先
- 最新优先
- 来自专栏服务端技术杂谈
harness工程演进
这就是harness的价值。 harness是一套帮助Agent稳定可靠运行的闭环系统。 它就像一套让Agent自动运行的FSD，具备了全链路监控与持续优化的能力。 所以agent工程化的第一步，是需要思考的是选取什么样的agent架构驱动形式。 如果任务适合workflow，却强行采用自治agent，结果就是简单问题复杂化，效果不好。 这就引出了什么样的agent架构需要harness，显而易见的是高度自治的agent需要，harness就是给系统套上了安全带（比如状态记录/断点恢复/避免重复等）。 也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。 对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。 在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。
12310编辑于 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模式，前期需要一到两个月搭建和磨合。
6710编辑于 2026-06-08大话 Harness 设计：工程如何推进闭环
在工程语境里，Harness 的意思是包裹在 Agent 外部的那套完整控制系统，让模型的能力变成可预期的、可验证的、可迭代的工程行为。 在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 到这里，我们已经讲完了 Harness 的技术层面。 但还有一个同样重要的维度，是关于工程文化和工程哲学的。 当 Agent 的产出速度开始超越人类的处理速度，整个工程团队的运作方式必须重构。 这是整个 Harness Engineering 讨论里最具人文色彩的部分：工程师在做什么？在传统软件工程里，工程师的价值体现在写出正确、高效、优雅的代码。 模型是 CPU，Harness 是操作系统。 在没有 Harness 的情况下，直接在模型上构建生产级 Agent 系统，这不是工程，这是赌博。
69111编辑于 2026-04-10在低代码设计中践行 Harness 工程
它提供的不是"另一种编程方式"，而是一个结构化的软件工程框架：组件是标准化的积木，事件是规范化的连接器，数据流是可视化的管道。 工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是：将 AI 的每次输出都视为需要验证的假设，通过结构化的反馈机制逐步提升输出质量。 这种"AI 提议 → 人类决策"的模式，确保了关键创意决策始终由人类掌控——这正是 Harness Engineering 中"缰绳"的具象化。 数据飞轮（Data Flywheel）是 Harness Engineering 的核心闭环机制。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
25810编辑于 2026-05-03- 来自专栏MixLab科技+设计实验室
Harness Engineering 是什么？从上下文工程到驾驭工程
Harness Engineering 驾驭工程：通过构建受控环境，让AI在约束下高效可靠地工作。 想象AI是一匹拥有神力的独角兽，它力量强大但难以预测。 这不是魔法，这是一个正在被正式命名的工程实践：Harness Engineering。 再之后，知名工程师 Martin Fowler 在 Twitter 上为 Thoughtworks 工程师对这份报告的深度分析站台。 Harness 到底在做什么 根据 OpenAI 官方报告的描述，Harness 由三个核心类别组成： 第一层：Context Engineering（上下文工程）。 Harness 就是 AI Agent 的脚手架。 OpenAI 团队花了 5 个月时间来构建和完善他们的 Harness。 这不是某种「快速见效」的技巧，而是一个需要持续投入的系统工程。
13K93编辑于 2026-03-25 100倍效率的秘密不是模型，是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时代高绩效工程团队的崭新信条。
29310编辑于 2026-04-15Harness Engineering：当工程师不再亲手写代码
HarnessEngineering：当工程师不再亲手写代码OpenAI最近发了一篇工程文章，题目是Harnessengineering:leveragingCodexinanagent-firstworld 最开始是3个工程师在驱动Codex，后来团队扩到7个人，整体交付吞吐量没有下降，还继续提高了。后面主要讲的是工程师角色怎么变化：当代码不再是主要产出，工程重心会往哪一层移动。 工程师的工作被重新定义了文章里有一句很重要：人类工程师的主要工作，不再是写代码，而是设计环境、指定意图、建立反馈循环，让Codex能稳定地做可靠工作。文章后面给了很多具体细节，把这句话落了下来。 吞吐量上来以后，mergephilosophy也变了随着Codex吞吐量越来越高，他们发现很多传统工程规范开始变得不合适。 很多原本默认正确的工程哲学，本身就要跟着改。“agent-generated”到底是什么意思文章专门解释了一次，什么叫“整个代码库由Codex生成”。
46210编辑于 2026-04-10- 来自专栏【腾讯云开发者】
Harness Engineering如何工程化落地？
这一篇我就不再谈泛泛而论的“AI 很重要”“工程化很重要”。我只做一件事：拿 JK Launcher 这个真实工程做例子，把我们这一路是怎么一步一步把 Harness 搭出来的，原原本本讲清楚。 我自己现在对 Harness Engineering 的理解很简单： 它不是某一个工具，也不是某一条提示词技巧，而是一整套让 AI 在工程里稳定产出正确结果的工程系统。 如果非要打个比方，我会说： Harness Engineering 就像是在给 AI 搭一整套“工程作战系统”。 WPF 工程、Unity 工程、后端服务、工具脚本仓库，它们需要的门禁和工作流一定不一样。 但你完全可以沉淀出每类项目的“最小可用 Harness 模板”。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。 这才是工程化。
3.9K67编辑于 2026-04-22 你的 AI Coding 到底有没有工程级 Harness？
，而是更需要 Harness。 这不是洁癖，是工程问题。 这就回到了前面那句话：没有 Harness 的长任务，本质上只是更长时间的赌博。 八、写在最后：Vibe Coding 不是放弃工程，而是倒逼你更工程化 很多人对 Vibe Coding 有一个误解：好像用了 AI，就可以不懂产品、不懂架构、不懂测试、不懂工程管理。 因为真正能改变开发效率的，往往不是一句神奇 Prompt，而是你是否把 AI 放进了一套正确的 Harness 里。
15510编辑于 2026-05-26ClaudeCode-Harness Engineering驾驭者工程的最佳实践者
今天继续跟着我和Claude学习Harness Engineering驾驭者工程。这个我在前面就谈到了是AI编程工程化的一个重点，核心是让AI软件工程更加安全，可控，可靠的运行。 在前面我就提出过一个观点，其实ClaudeCode这个编程工具就是Harness工程的最佳实践者。所以这篇文章看下Claude自身是如何进一步解释该事情。 关于本文：本文基于对 Claude Code 六大核心维度的深度研究，从 Harness Engineering（驾驭工程）哲学视角重新审视 Claude Code 的设计逻辑。 Claude Code 被真正广泛采用的背后，是一套经过深思熟虑的设计哲学——Harness Engineering（驾驭工程）。 在引入 AI 工具时，抵制"把所有摩擦都去掉"的冲动，往往是更成熟的工程判断。 六、结语 软件工程的历史一再表明：真正持久的生产力提升，来自驾驭复杂性，而不是消灭复杂性。
2.3K41编辑于 2026-04-13- 来自专栏Harness合集
10｜Agent Harness 的未来：从代码助手到工程协作系统
AI不再只是给建议，而是能进入仓库、读取上下文、修改文件、运行测试、连接外部工具，参与真实工程流程。下一步，它会从“代码助手”变成“工程协作系统”。 模型只负责推理，Harness要负责把任务过程保存下来。趋势二：从单Agent到多Agent协作复杂工程任务天然需要分工。 未来Harness会越来越像研发平台的一部分：谁让Agent做了什么，读了哪些文件，跑了哪些命令，改了哪些代码，调用了哪些外部系统，都要能审计。 工程师的价值会更多体现在：定义正确问题；拆分任务边界；设计验证标准；判断架构取舍；审查安全和兼容性；决定什么时候交付。AI可以写很多代码，但“该不该这么写”仍然需要工程判断。 真正可靠的方向是：展开代码语言：TXTAI代码解释AI做执行Harness做约束工具做验证人做判断这也是AI编程从个人效率工具走向团队工程系统的关键。
3100编辑于 2026-06-09 - 来自专栏DeepHub IMBA
Prompt、Context、Harness：AI Agent 工程的三层架构解析
HumanLayer 的工程团队花了一年多时间观察编码 Agent 以各种方式失败，忽略指令、不经确认就执行危险命令、在简单任务上陷入死循环。所以得了一个结论："这不是模型问题是配置问题"。 改动包括：完成前运行预检清单的自我验证循环、启动时映射目录结构的上下文工程、识别重复文件编辑的循环检测中间件，以及一套推理预算策略——规划阶段用高推理模型，实现阶段切换到低推理模型。 同一个模型，不同的 Harness结果天差地别。 OpenAI 构建了一个超过一百万行代码的生产应用，零行人工代码。工程师的工作是设计 Harness，不是写代码。 LangChain 未换模型在编码基准上提升了 14 个百分点，OpenAI 用零行手写代码造了一个百万行的生产应用——工程师的工作是设计 Harness。 对工程师的能力要求正在重新定义。核心问题从"怎么写 Prompt"变成了"怎么设计一个让 AI 可靠做对事的环境"，这两者是截然不同的能力。
1.5K21编辑于 2026-04-15 AgentScope Java 深度解析：企业级 Harness 工程化框架
本文将深入剖析 AgentScope Java 如何通过 Harness 工程化能力，解决智能体从原型到生产的关键挑战。 工程化系统解决这些问题。 二、Harness 工程化：核心架构 ▪ 2.1 Hook 系统：可控性的保障 Hook 是 AgentScope Java 最核心的创新。 、响应式、GraalVM 七、总结 AgentScope Java 的核心价值在于： 不是简单的 Java 移植，而是为企业级生产重新设计 核心优势： Hook 系统提供可控性 Harness 工程化开箱即用 响应式架构高并发 GraalVM 支持极致性能 设计权衡： 以 JDK 17+ 换取现代特性 以响应式换取高并发 以复杂度换取工程化 适用定位： 企业级生产部署的工程化框架 如果你的场景是微服务、企业应用
23310编辑于 2026-06-04Prompt 到 Context 到 Harness：AI 工程的三层进化
第三层：Harness Engineering（2026）解决了什么模型能回答好问题了，上下文也能治理好了——但怎么让模型成为一个能自主完成任务的系统？Harness 回答了这个问题。 在 AI 语境中：模型是马，Harness 是缰绳。模型提供智能，Harness 提供控制。 ，管理循环、工具调用、状态持久化、人工介入OpenAI Codex 团队 —— 用 Harness Engineering 的理念，工程师不写代码，只设计 Harness，产出 100 万行生产级代码LangChain 能自动理解和执行一句话总结2023 年我们学会了写提示词，2024 年我们学会了管上下文，2026 年我们终于理解：真正的工程不在 prompt 里，而在那个让模型安全、可靠、可控地运行的"缰绳"里。 本文基于 2023-2026 年 AI 工程实践发展脉络编写。
6720编辑于 2026-06-08- 来自专栏WorkBuddy
Harness Engineering
Hashimoto 等一线团队实践 参考仓库：walkinglabs/awesome-harness-engineering（2.9k ⭐） 摘要Harness Engineering（驾驭工程） 是 本文系统梳理 Harness Engineering 的定义、三层工程体系、六层架构、上下文管理核心问题、一线团队实践案例、评估基准生态、开源工具全景，以及当前未解决的关键问题。 5.5 Birgitta Böckeler 的 Harness 分类Birgitta Böckeler（Thoughtworks 杰出工程师）将 Harness 组件分为三类： 类别聚焦点典型实践 7.1 编码与软件工程 基准测试核心特点对Harness的检验维度SWE-bench Verified真实 GitHub Issue 和测试，软件工程 Agent检索、补丁应用、验证Terminal-Bench 成熟度阶段判断你可以使用下表来大致判断你的 Harness 当前处于哪个阶段： 阶段特征工程师角色Level 0：无 Harness直接给 Agent 发 Prompt，无结构化约束手写代码
28110编辑于 2026-06-09 - 来自专栏Linyb极客之路
不设终局，专注当下：Harness 与 AI 工程化演进
本文始终保持一个客观认知：Harness 是当前阶段的最优解，但绝非技术终点。AI 工程化没有终局，只有持续向前的演进。 三、第三代：Harness Engineering，解决“系统可控”在 Context Engineering 的基础上，行业终于迈出质变一步：Harness Engineering（驾驭工程）。 六、重要立场：Harness 是当前最优解，不是终点Harness 是现阶段 AI 工程化最成熟、最接近工业化的方案，但绝不是最终形态。 七、结语：AI 工程化，是从追逐智能到驾驭系统回顾整条演进路径：Prompt 解决“可用”，Context 解决“有序”，Harness 解决“可靠”。 AI 工程化的本质，不是不断追求更强的模型，而是不断提升系统的可控性、稳定性、可治理性。Harness Engineering 是当下最务实、最体系化的答案。它不是终点，而是下一个时代的起点。
17410编辑于 2026-05-19 - 来自专栏架构之巅
Harness架构下的Agent研发：从SDK到工程化实践
这场变革的关键，在于一套名为 “Harness”的工程化架构及其重要的实现工具。 Harness架构：智能体的“马具”与“控制塔”“Harness”原意是驾驭马匹的“马具”，这个概念精准地隐喻了新一代AI工程化的核心：我们需要的不是一匹无法控制的野马（原始大模型），而是一套完整的缰绳 从技术视角看，Harness架构是指智能体中除核心大模型之外的所有组件的总和。它是一个系统性的工程框架，旨在约束、引导和增强大模型的能力，使其能稳定、可靠地完成现实任务。 Harness架构的兴起，标志着AI应用开发从早期的“提示词技巧”阶段，正式迈入了系统化、工程化的“智能体工程”新纪元。 结语：从模型中心到工程智能从“提示词工程”到“Harness驾驭工程”，人工智能应用的开发范式正在经历一场深刻的转向。
1.1K20编辑于 2026-04-07 什么是 Harness 工程？让大模型从“会聊天”走向“会交付”
二、什么是 Harness 工程Harness 工程，可以理解为围绕 AI Agent 或大模型应用的“执行框架”所做的一整套工程实践。 换句话说，Harness 工程是在给大模型搭一套“工作环境”。如果把大模型比作一台发动机，那么 Harness 工程就像整辆车的底盘、方向盘、刹车、仪表盘和导航系统。 三、Harness 工程如何工作Harness 工程的工作方式，通常可以拆成一条清晰的执行链路：任务进入、上下文整理、模型决策、工具执行、结果校验、持续迭代。 、评估和监控工程成本能支撑更复杂的 AI 应用比单次模型调用更难开发和维护Harness 工程最大的价值，是把模型的聪明变成系统的可靠。 Harness 工程的意义就在这里：它把智能从一次性的灵感，变成可以被反复使用、观察、优化和交付的工程能力。最后记住这句话：模型决定 AI 的上限，Harness 工程决定这个上限能不能真正落地。
1.1K10编辑于 2026-04-28Harness Engineering 被讲烂之后，Agent 工程真正难的是什么？
合起来看，它们说的是同一层东西：模型之外的工程系统。这层系统，现在常被叫作Harness。 与此同时，更强的模型会让更复杂的任务进入可做范围，这些任务会暴露新的失败模式，于是新的Harness结构又出现了。这就让Harness像是一层活的工程系统，而不是一次性配置。 也许只是某一层Harness没搭好。一个克制的判断Harness工程并不否认模型重要。更强的模型当然会减少一些脚手架，也会让某些复杂机制变得多余。 所以，Harness工程更像一种正在成形的工程语言。 工程师过去主要写代码。现在多了一项工作：设计一个能让Agent持续做对事的环境。这就是Harness工程目前最值得关注的地方。
34721编辑于 2026-05-20- 来自专栏得物技术
Claude Code Harness 工程：数仓侧落地方案｜得物技术
Harness 工程的目标，就是把"执行层"的不稳定因素系统性地消掉：把规范写进 hooks，不再靠 AI 记忆，每次写 SQL 文件后自动触发检查；把迭代约束写进持久化文件，compact 后自动重新注入 工程价值最高的步骤，PostToolUse hook 在每次 SQL 文件保存时自动触发。 ETL 开发（Step 3）是 Harness 工程价值最高的步骤，SKILL 文件内封装了：① 规范内容（写死，不靠记忆）：建表规范：分区字段必须是 partition_dt STRING（格式 YYYYMMDD 八、Harness 工程能解决的核心问题这一节是整个方案的出发点，也是对"为什么要这么做"的直接回答。数仓 AI 开发当前的本质瓶颈：语义理解在实际数仓 AI 开发中，技术能力不是瓶颈，语义理解才是。 与传统数仓 AI 开发方式的对比从"AI 帮我写代码"到"AI 嵌入研发流水线"Harness 工程的最终目标，不是让 Claude 更聪明，而是让整个研发流水线更可靠。
64210编辑于 2026-05-21
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号