Harness Engineering 从 Prompt Engineering 到 Context Engineering,再到 Harness Engineering,AI 工程的重心,正在从 “怎么把话说对 这也是 Harness Engineering 开始被频繁提起的背景。 二、Harness Engineering 到底是什么 通俗来说,Harness Engineering 就是围绕 AI Agent 搭建一整套 “可执行、可验证、可约束、可迭代” 的外层运行系统。 模型是 CPU,Harness 才是真正的操作系统。 前两者主要关注模型的输入,而 Harness 关注模型的生存环境。
* **Harness Engineering(驾驭工程)**:Harness 的本意是“马具/挽具”(比如套在马身上用来拉车的皮带),或者指“驾驭自然力量”(如 Harness the power * **Harness 作用于“基础设施与外围(Infrastructure)”**:它几乎涵盖了**除了模型自身权重以外的一切**。 * **Harness Engineering** 是为了 **AI Agent(智能体)** 诞生的。 Harness Engineering 提供的是“状态持久化”、“错误阻断”和“多步规划的脚手架”。 ### 4. 工程化成熟度的区别:手工作坊 vs. * **Harness Engineering 本质上是把 DevOps 的思想引入到了 AI 领域**。
Agent Harness 的解剖结构 原文标题: The Anatomy of an Agent Harness 作者: Vivek Trivedy 来源: LangChain Blog 原文链接 + Harness 代理(Agent)由两部分组成: 模型(Model): 包含智能和推理能力 Harness(框架/装备): 提供执行环境、工具集成和控制系统 引言 在构建 AI 代理系统时,很多人只关注模型本身的能力 ,而忽视了"harness"的重要性。 本文深入探讨了 Agent Harness 的架构设计,帮助开发者理解如何构建可靠、可扩展的代理系统。 Harness 的核心组成部分 1. Harness 决定了: 模型如何与外部世界交互 如何处理复杂任务 如何保证安全性和可靠性 如何监控和优化性能 关键要点: Harness 是代理系统的核心基础设施 模块化设计便于维护和扩展 安全性和可观测性不可或缺
这意味着:持久化保证:Session存储在Harness之外,即使编排循环崩溃,也不会丢数据完整审计:每一步都有记录,合规审查和故障排查都有依据断点恢复:Harness可以通过wake(sessionId )从任何地方恢复,继续上次中断的工作②Harness(编排循环):调用模型,路由工具Harness是Agent的大脑和中枢神经系统。 收益1:容错能力大幅提升当Harness崩溃时会发生什么?耦合设计:容器死了,一切都完了,Session丢失解耦设计:Harness进程挂掉,Session还在数据库里。 新的Harness实例启动,通过wake(sessionId)从上次中断的地方继续这就是"从宠物变牲畜"。Harness现在是可以随意替换的。 你甚至可以:升级Harness的版本,而不中断Session运行多个Harness副本,用作负载均衡(Session的单调性决定了哪个副本该接管)如果某个Harness有bug,快速回滚,无缝继续收益2
https://devops.com/harness-adds-analytics-to-cdaas-platform/ ? 简介 Harness CDaaS平台为应用程序交付提供了一种更加无缝的方法,该方法可以自动检测GitHub,Bamboo,Jenkins,Artifactory或Nexus存储库或任何Git存储库中的新版本 平台地址:https://harness.io/ ? 流水线状态 ? 新建应用 ? 新建应用-选择监控工具 ? 新建发布流水线 ? 选择制品也是根据构建id获取的 ? 流水线执行过程 ?
论文特别指出,很多 Agent 系统的性能差异并非来自模型本身,而是"harness-sensitive",取决于 Harness 层的设计质量。 在 AI Agent 工程里,核心资产是 Harness,可靠性来自 Harness 的约束加上反馈循环,控制是运行时闭环、持续动态的,失败了就改进 Harness,工程师的核心工作是设计 Agent ,进化出更好的 Harness。 Harness 是 Agent 的操作系统。 模型是 CPU,Harness 是操作系统。 在没有 Harness 的情况下,直接在模型上构建生产级 Agent 系统,这不是工程,这是赌博。
Harness 越强,执行能力越强,Spec 的质量对最终结果的影响就越大。Harness 是放大器,Spec 是被放大的内容。 ** - SDD是必须而且重要的,不是因为 Harness 不够好,而是因为 Harness 把 Spec 的重要性放大了。 他们的 Harness 是什么样的? 它不是 Harness 的附件,而是 Harness 能运转起来的前提之一。 06 结语:Harness 越强,Spec 越重要 让我们回到最初的问题:Harness 来了,SDD 还有意义吗? 有。而且是更有意义,不是更没有意义。 原因很简单:Harness 是放大器。
仔细一琢磨,好像并不全是:Harness 的出现,是为了把AI大模型的能力和系统的稳定性真正焊在一起的工程性方法论。 开发者只管定义任务和工具,每会话小时加 0.08 刀,模型升级时 Harness 还能平滑切换,不用从头再来。 so,Harness 突然爆火,还是有点东西的。 but,这跟 OpenClaw 有何关联? OpenClaw 体现的 Harness 三层架构 虽然 Harness 听着很有料,但 OpenClaw 把这些思路变成了本地就能摸到的完整工具(Hermes 如是)。 它们共同说明:模型会换代,但工程边界不会消失,Harness 就是那个能随模型平移、保持可靠的核心。
简介 这篇快速文章重点介绍 JMH(Java Microbenchmark Harness)。首先,我们熟悉 API 并了解其基础知识。然后,我们将看到在编写微基准测试时应该考虑的一些最佳实践。
一 前言Harness 是Devops的一把利剑,用过drone,gitness都知道,Y(aml)asC/P(ipeline)asC 是其核心,其利用模块化可视化的语言将CICD更加便利更加AI的供用户使用 在从Jenkins做migration到Harness过程中,难免会涉及到数据集的转换,比如input sets,还有一些pipeline stage等的转换。 但是Harness在API doc上只提供了go,python,java,curl的API:所以针对一个python用户,如何快速生成python的SDK呢? 办法是有的,一是直接api接口自己手动封装,但是这样比较耗时费力,另外一种办法是使用Swagger Codegen,利用Harness提供的swagger.json生成一个Python SDK。 三 总结本文主要是介绍了Swagger Codegen的原理和使用,通过利用Harness自带的swagger.json文件自动化生成了python的SDK,方便后期二次开发和维护,提升人工效率。
最近AI圈又流行起来一个新词:Harness Engineering,给AI套上缰绳的约束系统。
OpenAI 最近发了一篇工程文章,题目是 Harness engineering: leveraging Codex in an agent-first world。
LangChain 在 2026 年3 月关于 agent harness 的文章里,则把 harness 直接定义为模型之外那整套让 agent 真正变得可用的代码、配置和执行逻辑。 harness migration。 Meta-Harness 则把这个方向又往前推了一层:它不再把 harness 当成手工维护的外围脚手架,而是把 harness code 本身当成可搜索、可量化比较的优化对象。 Harness 不能做这个假设。 没有架构,harness 会失去边界依据;没有平台思维,harness 会退化成一堆零散脚本;而没有 harness,架构和平台在 agent 进入主线之后,也无法保证这些约束在 agent 的长链执行中持续成立并发挥应有作用
AI落地不只是算法题,更是一道工程题要理解Harness,我们需要一个更清晰的框架:大模型是发动机,Harness是线束,使用者是驾驶员。发动机能提供原始动力,但发动机本身不会开车。 模型之外的一切,包括代码、配置、执行逻辑、反馈循环、约束机制,都归入Harness的范畴。模型是能力的来源,Harness让能力变成可用的系统。我们在腾讯内部也有类似的实践感受。 Harness走到台前为什么Harness在2026年突然从幕后走到台前?根本原因是AI使用范式的转变。2025年是智能体元年。大模型的定位,从回答问题进化到执行任务。 第三个发现:Harness让大模型更安全。一个没有Harness的大模型,就像一个没有操作规程的实习生,能力不差,但你不知道他下一步会做什么。 同样的发动机,同样的Harness,不同的驾驶员产出的东西可以有天壤之别。对于大多数人来说,Harness时代是一个更乐观的未来。回到汽车的隐喻。
读完确认了一件事:秘密不在模型,在包模型的那层东西——harness。实时代码仓上下文、prompt缓存、专用工具链、context精简、结构化记忆、并行子agent。 他把方法论叫Thin Harness, Fat Skills。Harness是跑模型的程序,只管四件事:循环调模型、读写文件、管上下文、做安全检查。保持薄。 最常见的错误是反过来——harness塞了一堆东西,skill反而没什么内容。40多个工具定义吃掉半个context window,每个MCP调用2到5秒。 五个概念组成三层:顶上fat skills(90%的价值),中间thin harness(约200行代码),底下deterministic工具。 能力尽量交给skill,执行尽量交给确定性工具,harness越薄越好。模型一升级,所有skill自动变强。
本文将带你从零构建一个 **AI 测试 Harness(测试夹具)**,实现 “规则提取 → LLM 理解 → 测试生成” 的完整闭环。 一、问题:为什么 AI 不会写测试? assert.False(t, s.NeedCaptcha("13800138000")) } ✅ 精准覆盖所有规则 ✅ 命名规范,可读性强 ✅ 自动 mock 依赖 五、进阶:构建自动化测试 Harness 将上述流程封装为一个 AI 测试 Harness: 文本编辑 [源代码] ↓ (AST 规则提取) [结构化规则 JSON] ↓ (LLM Prompt) [AI 生成的测试代码] 支持多语言:Java/Kotlin/Python 的 AST 提取器 本地 LLM 部署:使用 Ollama + CodeLlama,数据不出内网 六、价值:不止于省时间 表格 传统方式 AI 测试 Harness
在java中使用JMH(Java Microbenchmark Harness)做性能测试 JMH的全称是Java Microbenchmark Harness,是一个open JDK中用来做性能测试的套件
Harness 设计如何支撑长时运行应用开发 Harness(脚手架 / 运行编排系统)是 agentic coding(智能体式编程)前沿性能的关键。 成本对比 方案 时长 成本 单智能体 Solo 20 分钟 9 美元 完整 Harness 6 小时 200 美元 虽然 harness 的成本高出 20 多倍,但结果质量差异也非常明显。 Harness 版本的提升 而完整 harness 会先由 planner 把一句简单 prompt 扩展成一个更完整的产品规格,包含: •关卡编辑器 •Sprite 编辑器 •行为系统 •测试模式 • 不过即便如此,相比“核心功能都跑不起来”的 solo 输出,完整 harness 仍然带来了巨大提升。 六、继续迭代:让 Harness 变轻 第一版 harness 虽然强,但也非常明显地: •复杂 •缓慢 •昂贵 因此下一步自然是:删减不必要的 scaffold(脚手架)。
Harness设计的质量直接决定了16个agent能否形成合力,而不是各自内卷。 Harness架构设计之前,我们还有必要先厘清MAS核心的设计选择-协调拓扑。 考虑到MAS复杂度高于单agent,在MAS中生效的Harness工程架构应用范围可以覆盖单agent,所以后文提到的harness的架构设计都以MAS为基准进行设计知识供给层:不是仓库,是主动的信息生态定位 复盘后定位到的根因是:Harness工程上缺少多层次治理的解耦设计。 这正是三阶段演化能够成立的前提-不是因为模型越来越强就可以去掉Harness,而是因为Harness在,模型才可以将其决策推理应用到容错性更低,但价值更高的场景结语当下大模型和agent技术都发展飞快,
Meta-Harness则把这个方向又往前推了一层:它不再把harness当成手工维护的外围脚手架,而是把harnesscode本身当成可搜索、可量化比较的优化对象。 [15][16]这一点和harness有很强的相似性,因为harness同样在做pavedpath,同样强调guardrails、接口、一致体验和反馈回路。 Harness不能做这个假设。 没有架构,harness会失去边界依据;没有平台思维,harness会退化成一堆零散脚本;而没有harness,架构和平台在agent进入主线之后,也无法保证这些约束在agent的长链执行中持续成立并发挥应有作用 ,Harness也不是靠零散规则一条条叠出来的。