业界共识公式: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的价值。 harness是一套帮助Agent稳定可靠运行的闭环系统。 它就像一套让Agent自动运行的FSD,具备了全链路监控与持续优化的能力。 这就引出了什么样的agent架构需要harness,显而易见的是高度自治的agent需要,harness就是给系统套上了安全带(比如状态记录/断点恢复/避免重复等)。 在完成以上harness需求之后,harness工程已经开始变得越来越复杂了,这就回到了软件工程的问题上了,即模型推理/工具执行/运行循环/任务日志应该如何解耦。 langchain发表过一篇文章,harness可以显著提升agent的基准表现。 以上这些东西加起来,组成了需要的harness架构,大概是这样: Harness需要回答的是能更好地组织长任务状态?能让工具更容易被模型稳定调用?能更安全地放大自治能力?
Harness Engineering 不是在造更强的 AI——是在造一个让 AI 无论如何也做不坏事的系统。四年间,每一次 Agent 搞砸的方式,都变成了 Harness 的一个组件。 这是 Harness 价值的第一次量化证明——虽然 Harness Engineering 这个名字还要再等两年才会出现。 这是 Harness 的价值被严格量化——同一模型,不同 Harness,差距 13.7 个百分点。 AHE(Agentic Harness Engineering,2026年4月)把这个方向推到极致:自动化闭环 Harness 进化达到 77.0% pass@1,超越了人类设计的 Harness。 Harness 的必要性不降反升。不是模型不够好才需要 Harness。是模型越强,越需要 Harness 来管住它。
我们可以把 Agent Harness 想象成一个 "微型的操作系统内核",它主要干三件事:调度、约束、兜底。 一、Harness 的核心骨架(抽象模型) 不管你是做 AI Coding、AI Ops 还是 AI 客服,一个成熟 Harness 通常长这样: ┌───────────────┐ │ Planner 二、为什么很多团队卡在 Spec,迈不过 Harness? 因为 Harness 是工程问题,不是 Prompt 问题: 难点 说明 上下文爆炸 几万行代码一塞就爆 token,需要裁剪 / RAG 失败恢复 Agent 改错代码怎么办? 如果你是在看技术选型 / 写方案 / 评估平台,可以用这三个问题快速判断对方是不是真的到了 Harness 阶段: 有没有 Agent Loop?
Harness 就是这一层 OS它给模型一个结构化的运行环境,并负责模型和外部世界之间每一次交互的中介。 Claude Code 是一个 Harness。Trae 是一个 Harness。 编码 Agent Harness 的七个组件 Harness 不是一块单一的基础设施而是一层一层叠起来的能力栈。每个 AI 编码 Harness,不管包的是哪个模型,都会以某种形式提供下面这七层。 为什么 Harness 比模型有更大的杠杆 模型决定输出质量的上限。Harness 决定下限。 两者都是能力不错的 Harness,各自包着能力不错的模型。问题不在哪个 Harness 更聪明,而是是哪一层治理在指挥这个 Harness;以及换工具的时候,那一层治理能不能跟着迁移过去。 Harness 读取治理层。治理层不关心是哪一个 Harness 在读它。 这就是理解 Harness 是什么所带来的结构性结论:治理层和 Harness 是可分离的。Harness 执行,治理指挥。
Harness Engineering 从 Prompt Engineering 到 Context Engineering,再到 Harness Engineering,AI 工程的重心,正在从 “怎么把话说对 这也是 Harness Engineering 开始被频繁提起的背景。 二、Harness Engineering 到底是什么 通俗来说,Harness Engineering 就是围绕 AI Agent 搭建一整套 “可执行、可验证、可约束、可迭代” 的外层运行系统。 模型是 CPU,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
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落地这么难?先看一个典型场景。某电商公司想上Harness自动化订单处理流程——从下单、扣库存、扣款到通知物流,全程自动化。 这个鸿沟,就是Harness落地的真正挑战。二、落地第一步:理解你的现有系统(不是理解Harness)80%的团队错在:一上来就研究Harness怎么配置,而不是先搞清楚自己的系统长什么样。 因为Harness的本质是编排已有能力,不是凭空创造能力。如果你连"现在有哪些能力、怎么调用"都说不清,Harness也帮不了你。 ❌坑4:指望Harness解决所有问题错在哪:业务逻辑本身就有bug(库存扣多了、优惠算错了),指望Harness自动修复。后果:Harness只是忠实执行bug逻辑,问题依然存在。 正解:Harness是编排工具,不是业务逻辑本身。先把业务逻辑理清楚。❌坑5:团队没人懂现有系统也没人懂Harness错在哪:找外包写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 提供了一条从手工迭代迈向自动化搜索的可行路径。
引言:为什么要谈 harness / loop / hook当我们谈论一个 Agent 系统的设计,三个角度几乎绕不开:Agent Harness(智能体骨架):宿主进程如何承载 Agent,从输入捕获 这篇文章会从 harness、loop、hook 三个角度逐层拆解这套设计。 第一视角 · Agent Harness:分层骨架Ooder 的 Harness 不是单一的进程外壳,而是一个由三层结构组成的承载体系:图 1 · Ooder Agent Harness 的三层结构:宿主层 整套设计有四类 Hook,分布在 Harness 的不同层次。 Trae Hooks 不直接进入编排核,而是在 Harness 之外把 Agent 的输入/输出引导回闭环测试管线(参见 .trae/skills/ooder-nlp-harness/SKILL.md)
2026年上半年,大模型应用层最具统治力的热词,绝对是「Harness」。 顺着这十五个月的血泪文献,看清这套「约束工程」(Harness engeniering)的每一张真实图纸。 01、Harness第一层:从记事本到管理制度 讲明白Harness其实不难。 这就是Harness 1.0。 02、Harness 第二层:终结无政府状态,走向并发与效率 当单个汽车终于能稳稳地跑长途了,应用层立刻迎来了下一种贪婪。 但它们指向同一个认知,harness 组件的价值不是绝对的,是相对于模型能力的。 Harness 里每个方块存在的理由都不是「它能做什么」,而是「模型做不到什么」。 所以,Harness到底是不是护城河? Anthropic 证明了模型已经开始吞掉Harness。所以也许不是?
于是Harness Engineering登场了, 给AI套上脚手架,约束它能做什么不能做什么。 你刚把Harness的文档看完, 觉得自己终于跟上节奏了。 Loop来了。 Harness到底是个什么东西 在聊Loop之前, 我们得先把Harness说清楚, 因为很多人连这个概念都还是一知半解。 Harness,中文有人翻译成驾驭框架,有人叫智能体线束。 LangChain的Vivek Trivedy有个很干脆的定义,如果你不是模型本身,那你就是Harness。 说白了, Harness就是套在大语言模型外面的一整套运行环境。 Harness和Loop的关系, 不是谁取代谁, 是层级关系。 Harness是基础设施, 解决单次行动的可靠性。Loop是控制面, 解决持续推进的可靠性。 没有Harness的Loop是空中楼阁, 没有Loop的Harness是静态雕塑。 中文社区有篇文章说得好, Loop不是新楼层, 是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获取的 ? 流水线执行过程 ?