业界共识公式:Agent = Model(大模型)+ Harness(驾驭层) 为什么叫 Harness? 类比帮助理解 Model = CPU,Harness = 操作系统(OS)——CPU 再强没有 OS 也跑不了应用 Model = 主厨大脑(决定怎么做菜),Harness = 厨房+炉灶+帮厨( 真正点火翻面装盘) Claude Code / Cursor Agent / OpenCode 本质上就是围绕某模型构建的 Agent Harness,所以同一模型配上不同 Harness 体验差异巨大 一句话:Harness 就是把"会说话的大模型"变成"能干活的自主智能体"的工程运行时。 如果想看最小可运行的 Harness Loop 代码示例(Python 伪代码),我可以给你写一版
Harness Agent(或称 Agent Harness) 不是某个具体产品名,而是指给大模型套上"工程外壳"后形成的、可自主执行任务的完整智能体系统。 核心定义 业界共识公式: Agent = Model(大模型)+ Harness(驾驭层/运行框架)Model:负责推理、理解、生成文本(LLM 本身只会 input→output)Harness:模型之外的一切工程设施 Harness 阶段:你说"修复登录 Bug 并跑测试",Harness 自动拆任务→读代码→改文件→跑测试→看结果→再修正,直到完成或触发人工介入。 一句话理解 裸 LLM 是"会说话的引擎",Harness 是"方向盘+刹车+仪表盘+道路规则",二者结合才是能上路干活的 Harness Agent(完整智能体)。 开发重点从"调模型"变成了"设计好 Harness 让模型可靠自主地工作"。
同一模型,仅改变 Harness 设计,编码基准测试分数可从 6.7% 跃升至 68.3%。 一、核心定义:什么是 Harness Engineering? 对任务最优的 Harness 不一定是其训练时使用的那套。4.2 模型升级后 Harness 应简化Harness 中的所有组件都基于一个假设:"模型自己做不到这个"。 Harness的检验维度WebArena可独立部署的网页环境,评估自主 Agent网页面向 Harness 设计的可复现基线VisualWebArena扩展 WebArena,增加图像和截图输入Harness 为大规模评估和改进 Agent 设计的通用 Harness,随 Terminal-Bench 2.0 发布基准测试、Harness 比较SWE-agent成熟的科研编码 Agent,Harness、Prompt Harness Engineering(2026-05-21)开源资源awesome-harness-engineering(2.9k ⭐)learn-harness-engineeringAGENTS.md
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需要回答的是能更好地组织长任务状态?能让工具更容易被模型稳定调用?能更安全地放大自治能力?
我们可以把 Agent Harness 想象成一个 "微型的操作系统内核",它主要干三件事:调度、约束、兜底。 一、Harness 的核心骨架(抽象模型)不管你是做 AI Coding、AI Ops 还是 AI 客服,一个成熟 Harness 通常长这样:┌───────────────┐│ Planner 二、为什么很多团队卡在 Spec,迈不过 Harness? 因为 Harness 是工程问题,不是 Prompt 问题:难点 说明上下文爆炸 几万行代码一塞就爆 token,需要裁剪 / RAG失败恢复 Agent 改错代码怎么办? 如果你是在看技术选型 / 写方案 / 评估平台,可以用这三个问题快速判断对方是不是真的到了 Harness 阶段:有没有 Agent Loop?undefined还是"一次 Prompt 一把梭"?
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 是代理系统的核心基础设施 模块化设计便于维护和扩展 安全性和可观测性不可或缺
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 提供了一条从手工迭代迈向自动化搜索的可行路径。
二、Harness的五根支柱OpenAI把这套方法论拆成了五个可以直接落地的组件。结构化文档项目里维护一个docs目录,作为Agent的"单一事实来源"。系统架构图、执行计划、设计规格书都放在里面。 Copilot时代,AI帮你写得更快;Harness时代,AI替你写完整个模块,你负责验收。杠杆差了一个数量级。HashiCorp、Anthropic、Cursor都在2026年跟进这个方向。 四、Harness不是银弹它目前最适合的是边界清晰、规范明确的工程任务。API开发、数据处理管道、测试用例生成、文档维护,这些活儿的特点是输入输出可验证、有明确的通过标准、变更范围相对独立。 一个团队从传统模式切到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
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。
今年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约束中?