Harness 就是这一层 OS它给模型一个结构化的运行环境,并负责模型和外部世界之间每一次交互的中介。 Claude Code 是一个 Harness。Trae 是一个 Harness。 编码 Agent Harness 的七个组件 Harness 不是一块单一的基础设施而是一层一层叠起来的能力栈。每个 AI 编码 Harness,不管包的是哪个模型,都会以某种形式提供下面这七层。 为什么 Harness 比模型有更大的杠杆 模型决定输出质量的上限。Harness 决定下限。 两者都是能力不错的 Harness,各自包着能力不错的模型。问题不在哪个 Harness 更聪明,而是是哪一层治理在指挥这个 Harness;以及换工具的时候,那一层治理能不能跟着迁移过去。 Harness 读取治理层。治理层不关心是哪一个 Harness 在读它。 这就是理解 Harness 是什么所带来的结构性结论:治理层和 Harness 是可分离的。Harness 执行,治理指挥。
AgentScope Java :Harness Framework 一套代码,从个人助手走到企业级 Agent 过去一年,OpenClaw、Hermes、Claude Code 把 Harness Engineering 分布式环境下,"本地文件系统"这个假设不成立 Multi-Agent 子任务编排,复杂度失控 上下文压缩和分层记忆,没有现成实现 AgentScope Java 1.1.0 的 Harness Framework 核心设计:两个支柱 支柱一:Workspace 作为唯一事实来源 Harness 为每个 Agent 引入 workspace——一个结构化目录,承载全部持久化内容: workspace/ ├── AGENTS.md Harness 核心架构图 支柱二:AbstractFilesystem 本地磁盘目录在分布式场景下行不通。多个 Pod 各有一块本地盘,谁的 MEMORY.md 才是真的? Harness 用 AbstractFilesystem 抽象层解决: // 上层只关心统一接口 filesystem.read(path) filesystem.write(path, content
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 领域**。
1.2 当前版本:基于 Harness Engineering 的重构直到 Harness Engineering 方法论的引入,A2UI 才真正找到了自己的"灵魂"。 2.3 阶段三:Harness 式驾驭(Harness-Driven)Harness Engineering 代表了 AICode 的第三个阶段。 Harness Engineering:从"祈祷式编程"到"驾驭式工程"3.1 什么是 Harness Engineering? Harness 五层模型:给 AI 装上"缰绳"与"仪表盘"在 A2UI 的重构中,我们设计了 Harness 五层模型:图 3:Harness 五层模型 —— 从意图理解到反馈学习的完整驾驭体系4.1 随着多模态模型、Agent 系统、AutoML 的发展,Harness 的五层模型可以自然扩展:Intent Harness → 多模态意图理解(文本 + 语音 + 草图)Strategy Harness
Agent Harness 的解剖结构 原文标题: The Anatomy of an Agent Harness 作者: Vivek Trivedy 来源: LangChain Blog 原文链接 + Harness 代理(Agent)由两部分组成: 模型(Model): 包含智能和推理能力 Harness(框架/装备): 提供执行环境、工具集成和控制系统 引言 在构建 AI 代理系统时,很多人只关注模型本身的能力 ,而忽视了"harness"的重要性。 本文深入探讨了 Agent Harness 的架构设计,帮助开发者理解如何构建可靠、可扩展的代理系统。 Harness 的核心组成部分 1. Harness 决定了: 模型如何与外部世界交互 如何处理复杂任务 如何保证安全性和可靠性 如何监控和优化性能 关键要点: Harness 是代理系统的核心基础设施 模块化设计便于维护和扩展 安全性和可观测性不可或缺
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 系统,这不是工程,这是赌博。
这意味着:持久化保证:Session存储在Harness之外,即使编排循环崩溃,也不会丢数据完整审计:每一步都有记录,合规审查和故障排查都有依据断点恢复:Harness可以通过wake(sessionId )从任何地方恢复,继续上次中断的工作②Harness(编排循环):调用模型,路由工具Harness是Agent的大脑和中枢神经系统。 收益1:容错能力大幅提升当Harness崩溃时会发生什么?耦合设计:容器死了,一切都完了,Session丢失解耦设计:Harness进程挂掉,Session还在数据库里。 新的Harness实例启动,通过wake(sessionId)从上次中断的地方继续这就是"从宠物变牲畜"。Harness现在是可以随意替换的。 你甚至可以:升级Harness的版本,而不中断Session运行多个Harness副本,用作负载均衡(Session的单调性决定了哪个副本该接管)如果某个Harness有bug,快速回滚,无缝继续收益2
Sandbox是Harness时代的服务器Harness是应用,Sandbox是服务器。理解这个关系,你就理解了AIAgent的基础设施。一个核心类比Harness是应用,Sandbox是服务器。 Harness和Sandbox的关系是一样的:Harness:负责推理、决策和工具调用Sandbox:提供隔离的执行环境两者可以独立替换,系统依然工作。 轨迹是Harness产出最有价值的资产。 轨迹和本地数据存储在哪里,决定了谁对Harness拥有实际控制权。 ││Trajectory│└─────────┘└─────────┘└─────────┘└─────────┘控制层本身也很可能是一个Harness——Harness管理Harness。
01 从 Prompt 到 Context 再到 Harness:AI 编程的三次跃迁 1.1 什么是 Harness Engineering? OpenAI 管这种工作方式叫 Harness Engineering。Harness 这个词本意是"马具、挽具"——马再好,不套上鞍具它也拉不了车。 给 AI Agent 套上合适的 Harness,它才能稳定地干活。 这就是 Harness。 03 搭建 Harness:具体做了什么 3.1 多 Agent 协作体系 为什么不能只用一个 Agent? Harness 构建得越完善,AI 的行为就越接近一个遵守团队规范的老手,而不是一个什么都不懂的新人。
工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是:将 AI 的每次输出都视为需要验证的假设,通过结构化的反馈机制逐步提升输出质量。 这种"AI 提议 → 人类决策"的模式,确保了关键创意决策始终由人类掌控——这正是 Harness Engineering 中"缰绳"的具象化。 数据飞轮(Data Flywheel)是 Harness Engineering 的核心闭环机制。 在这个进化过程中,Harness Engineering 是驾驭不确定性的缰绳,数据飞轮是持续进化的引擎,而低代码本身——作为全栈语言和全流程可视化的载体——是这一切得以发生的土壤。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
中间那条统一的执行主链路,靠的就是 Harness 层。 换句话说,没有 Harness 基础理论,OpenClaw 就只是一个“把文本丢给模型”的简单代理。 有了 Harness,它才真正变成了一个可扩展、可控制、可落地的 Agent 运行容器。 为什么 Harness 这个概念突然变重要了 要理解 OpenClaw 和 Harness 的关系,还需要理解另一个背景:模型本身已经足够强,但大家的痛点正在转移。 Harness 至少在管四类事情 从那组对比往下拆,你会发现单 Agent 和完整 Harness 之间,至少差了四类东西。 第一类:给模型看什么。 单 Agent 只有一句 Prompt。 这是 Harness 里最容易被低估的一层。很多人对 Harness 的理解停在“给模型配上工具”,但工具本身不是反馈,工具只是让模型有了手,反馈是让它有了感官。
Harness 越强,执行能力越强,Spec 的质量对最终结果的影响就越大。Harness 是放大器,Spec 是被放大的内容。 ** - SDD是必须而且重要的,不是因为 Harness 不够好,而是因为 Harness 把 Spec 的重要性放大了。 他们的 Harness 是什么样的? 它不是 Harness 的附件,而是 Harness 能运转起来的前提之一。 06 结语:Harness 越强,Spec 越重要 让我们回到最初的问题:Harness 来了,SDD 还有意义吗? 有。而且是更有意义,不是更没有意义。 原因很简单:Harness 是放大器。
简介 这篇快速文章重点介绍 JMH(Java Microbenchmark Harness)。首先,我们熟悉 API 并了解其基础知识。然后,我们将看到在编写微基准测试时应该考虑的一些最佳实践。
最近AI圈又流行起来一个新词:Harness Engineering,给AI套上缰绳的约束系统。
一 前言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,方便后期二次开发和维护,提升人工效率。
仔细一琢磨,好像并不全是:Harness 的出现,是为了把AI大模型的能力和系统的稳定性真正焊在一起的工程性方法论。 开发者只管定义任务和工具,每会话小时加 0.08 刀,模型升级时 Harness 还能平滑切换,不用从头再来。 so,Harness 突然爆火,还是有点东西的。 but,这跟 OpenClaw 有何关联? OpenClaw 体现的 Harness 三层架构 虽然 Harness 听着很有料,但 OpenClaw 把这些思路变成了本地就能摸到的完整工具(Hermes 如是)。 它们共同说明:模型会换代,但工程边界不会消失,Harness 就是那个能随模型平移、保持可靠的核心。
AI 落地真相:那些 Prompt 之外的事 Harness Engineering 全解 一个尴尬的事实 很多人以为 AI 落地就是"写好 Prompt"。 这就是 Harness Engineering——AI 应用的"驾驭工程"。今天把它的全貌讲清楚。 除了离线的评测集,线上监控同样重要: 成功率:模型调用成功/失败比例 响应延迟:P50/P99 延迟,AI 场景对延迟很敏感 Token 消耗:控制成本 错误分布:哪类问题出错最多,持续优化 七、写在最后:Harness 安全护栏 → 结果返回 ↓ 工具调用 / 记忆管理 / 评测监控 Harness 这,才是 Harness Engineering 追求的东西。
答案指向一个看似简单却蕴含深意的词——Harness。但等等,"Harness"到底指什么? Harness平台(harness.io):一个AI原生的软件交付平台,估值55亿美元,服务1000+企业客户。这两个"Harness"并非巧合的同名。 下面这个架构图展示了三层之间的关系:第三章:Harness平台——AI原生软件交付引擎说完方法论,让我们转向产品——Harness平台(harness.io)。 Harness的理念和操作方式常见失败模式失败模式案例特征教训大爆炸式上线试图一次性将所有服务迁移到Harness风险过高,一旦失败影响全业务;应渐进推进忽视文化变革只部署工具,不调整组织和流程Harness 争议与未来——Harness的终局是什么?