其核心公式:Agent=Model+Harness。 1.2术语来源"Harness"原意为"马具、挽具",引申为"驾驭工具"。 ,换一套Harness后表现可能退化。 对任务最优的Harness不一定是其训练时使用的那套。4.2模型升级后Harness应简化Harness中的所有组件都基于一个假设:"模型自己做不到这个"。 、真实部署工具、真实多模态输入隔离测试与现实部署之间的Harness差距八、开源工具与运行时生态8.1Harness框架项目核心特点适用场景Harbor为大规模评估和改进Agent设计的通用Harness
Harness 就是这一层 OS它给模型一个结构化的运行环境,并负责模型和外部世界之间每一次交互的中介。 Claude Code 是一个 Harness。Trae 是一个 Harness。 编码 Agent Harness 的七个组件 Harness 不是一块单一的基础设施而是一层一层叠起来的能力栈。每个 AI 编码 Harness,不管包的是哪个模型,都会以某种形式提供下面这七层。 为什么 Harness 比模型有更大的杠杆 模型决定输出质量的上限。Harness 决定下限。 两者都是能力不错的 Harness,各自包着能力不错的模型。问题不在哪个 Harness 更聪明,而是是哪一层治理在指挥这个 Harness;以及换工具的时候,那一层治理能不能跟着迁移过去。 Harness 读取治理层。治理层不关心是哪一个 Harness 在读它。 这就是理解 Harness 是什么所带来的结构性结论:治理层和 Harness 是可分离的。Harness 执行,治理指挥。
这就是harness的价值。 harness是一套帮助Agent稳定可靠运行的闭环系统。 它就像一套让Agent自动运行的FSD,具备了全链路监控与持续优化的能力。 这就引出了什么样的agent架构需要harness,显而易见的是高度自治的agent需要,harness就是给系统套上了安全带(比如状态记录/断点恢复/避免重复等)。 在完成以上harness需求之后,harness工程已经开始变得越来越复杂了,这就回到了软件工程的问题上了,即模型推理/工具执行/运行循环/任务日志应该如何解耦。 langchain发表过一篇文章,harness可以显著提升agent的基准表现。 以上这些东西加起来,组成了需要的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 关注模型的生存环境。
Agent Harness 的解剖结构 原文标题: The Anatomy of an Agent Harness 作者: Vivek Trivedy 来源: LangChain Blog 原文链接 + Harness 代理(Agent)由两部分组成: 模型(Model): 包含智能和推理能力 Harness(框架/装备): 提供执行环境、工具集成和控制系统 引言 在构建 AI 代理系统时,很多人只关注模型本身的能力 ,而忽视了"harness"的重要性。 本文深入探讨了 Agent Harness 的架构设计,帮助开发者理解如何构建可靠、可扩展的代理系统。 Harness 的核心组成部分 1. Harness 决定了: 模型如何与外部世界交互 如何处理复杂任务 如何保证安全性和可靠性 如何监控和优化性能 关键要点: Harness 是代理系统的核心基础设施 模块化设计便于维护和扩展 安全性和可观测性不可或缺
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
* **Harness Engineering(驾驭工程)**:Harness 的本意是“马具/挽具”(比如套在马身上用来拉车的皮带),或者指“驾驭自然力量”(如 Harness the power * **Harness 作用于“基础设施与外围(Infrastructure)”**:它几乎涵盖了**除了模型自身权重以外的一切**。 * **Harness Engineering** 是为了 **AI Agent(智能体)** 诞生的。 Harness Engineering 提供的是“状态持久化”、“错误阻断”和“多步规划的脚手架”。 ### 4. 工程化成熟度的区别:手工作坊 vs. * **Harness Engineering 本质上是把 DevOps 的思想引入到了 AI 领域**。
Harness Engineering 正是在这个框架里把 AI 当作协作者,而不是让 AI 成为"绕过约束的捷径"。 03 什么是 Harness Engineering? 要理解为什么我们的框架叫 Harness Engineering,先看看 "Harness" 这个词在 AI 工程语境中的含义变化。 3.1 为什么是"Harness"?一个词的语义迁移 "Harness" 在英语里本义是马具 / 挽具:把一匹原始力量巨大但方向不定的马,通过缰绳、鞍具、辔头接入可控系统。 4.6 典型链路:一个需求如何被 Harness 接住 以一个跨服务需求为例,Harness Engineering 的运行方式不是“用户随口说一句,AI 直接改代码”,而是逐步收敛上下文: 需求进入: 仓:teams: 块让不同业务团队有各自的业务仓 + IDL 仓 Active Team 三级解析:$HARNESS_TEAM > .harness/local.yaml > default_team
最近业界对 Harness的关注异常高涨。问题是,Harness 至今基本靠手工调参——工程师盯着 bad case,改几行 Prompt,跑一遍测试,不行再改。 斯坦福、MIT 等团队给出的答案是 Meta-Harness。 今天我们重点从算法设计、搜索空间选择、执行轨迹的不可替代性三个角度,解读下 Meta-Harness 为什么能 work,以及它对 Harness 工程自动化的启示。 为什么代码空间搜索比文本空间更适合 Harness Harness 本质上是可执行程序。在代码空间中进行搜索有三个结构性的优势: 1. 修改粒度匹配问题结构。 对于 Harness 工程这一日益重要的实践领域,Meta-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
今年AI圈是非常躁动的,除了全民养龙虾,Harness也在技术圈掀起了不小的波澜。与openclaw不同的是,Harness不是一个服务大众的产品。 这个马具就是Harness! 6\.扫描当前项目,生成或更新cow\-harness/project.profile.md、cow\-harness/context\-map.md、cow\-harness/project.verification.md 7\.由你运行cow\-harness/scripts/harness\-check.sh。8\.汇总推断项、待确认项和验证结果。 \\\3\.开始执行任务重启AI终端,开启你的cow\-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 的行为就越接近一个遵守团队规范的老手,而不是一个什么都不懂的新人。
Sandbox是Harness时代的服务器Harness是应用,Sandbox是服务器。理解这个关系,你就理解了AIAgent的基础设施。一个核心类比Harness是应用,Sandbox是服务器。 Harness和Sandbox的关系是一样的:Harness:负责推理、决策和工具调用Sandbox:提供隔离的执行环境两者可以独立替换,系统依然工作。 轨迹是Harness产出最有价值的资产。 轨迹和本地数据存储在哪里,决定了谁对Harness拥有实际控制权。 ││Trajectory│└─────────┘└─────────┘└─────────┘└─────────┘控制层本身也很可能是一个Harness——Harness管理Harness。
中间那条统一的执行主链路,靠的就是 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 是放大器。
工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是:将 AI 的每次输出都视为需要验证的假设,通过结构化的反馈机制逐步提升输出质量。 这种"AI 提议 → 人类决策"的模式,确保了关键创意决策始终由人类掌控——这正是 Harness Engineering 中"缰绳"的具象化。 数据飞轮(Data Flywheel)是 Harness Engineering 的核心闭环机制。 在这个进化过程中,Harness Engineering 是驾驭不确定性的缰绳,数据飞轮是持续进化的引擎,而低代码本身——作为全栈语言和全流程可视化的载体——是这一切得以发生的土壤。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
最近AI圈又流行起来一个新词:Harness Engineering,给AI套上缰绳的约束系统。