业界共识公式: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 来管住它。
Harness 就是这一层 OS它给模型一个结构化的运行环境,并负责模型和外部世界之间每一次交互的中介。 Claude Code 是一个 Harness。Trae 是一个 Harness。 编码 Agent Harness 的七个组件 Harness 不是一块单一的基础设施而是一层一层叠起来的能力栈。每个 AI 编码 Harness,不管包的是哪个模型,都会以某种形式提供下面这七层。 为什么 Harness 比模型有更大的杠杆 模型决定输出质量的上限。Harness 决定下限。 两者都是能力不错的 Harness,各自包着能力不错的模型。问题不在哪个 Harness 更聪明,而是是哪一层治理在指挥这个 Harness;以及换工具的时候,那一层治理能不能跟着迁移过去。 Harness 读取治理层。治理层不关心是哪一个 Harness 在读它。 这就是理解 Harness 是什么所带来的结构性结论:治理层和 Harness 是可分离的。Harness 执行,治理指挥。
服务器名称:建议使用容易识别的名称,例如DeepSeek-Harness-Test。模板灰度说明:浏览器实测时,普通购买页的公开镜像列表尚未稳定展示DeepSeekHarness。 只安装来源可信、内容可审查、与你当前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? 官方地址:https://www.deepseek.com/harness/一、Harness解决了什么问题? 2.启动Harness回到官方页面,复制当前的启动命令并执行。第一次运行时,NPX可能会询问是否安装相关软件包,确认安装即可。 七、为什么需要Harness?把这几轮测试放在一起,就能回答文章开头的问题。模型负责判断:下一步应该做什么? 模型、Harness和工具链需要共同工作。八、Agent任务到底贵不贵?
第 17 篇:Meta-Harness —— 让 Agent 自动优化自身 Harness 系列定位:面向有 3+ 年经验的后端开发者,从零构建 Agent Harness 工程能力体系 上一篇回顾:[ 本篇进入前沿探索:如果 AgentOps 是"给 Agent 建工厂",那 Meta-Harness 就是"让工厂自己升级自己"——从人工优化 Harness 到 Agent 自动优化 Harness。 2.3 五步工作流将 Meta-Harness 的工作流拆解为五个步骤:关键特征:这是一个"优化循环的优化循环"——Proposer 自身也是一个 Harness(论文因此命名为"Meta-Harness 是否值得,取决于你原本要付多少人工工程师来迭代 Harness,以及发现的 Harness 能复用多久。6.5 无限递归问题Meta-Harness 自身也是一个 Harness。 那谁来优化 Meta-Harness 的 Harness?理论上可以嵌套——用 Meta-Harness 优化 Meta-Harness 的配置。但这导致无限递归。
无论是Prompt组装、上下文管理,还是工具调用、状态保存和任务循环都由Harness统一协调。随着模型、API和产品需求的不断变化,Harness也在持续演化。 前一种方式适合已经划分清楚执行阶段,并且能够承担函数级分析成本的Harness。后一种方式则适合大型仓库,尤其是尚未理清执行阶段,或函数级整理会带来过高开销的Harness。 行为组织接下来,系统会借助大模型,判断各个代码单元分别属于Harness的哪些执行阶段。 对研发人员来说,这套结构可以降低理解复杂Harness的门槛,也能减少跨模块排查问题所需的时间。 当Harness仍在持续演化时,可读、可查、可改,已经成为Agent稳定扩展与长期维护的重要基础。
DeepSeek Harness终于发布了,官方地址在这里:https://www.deepseek.com/harness/其中它的Github仓库已经来到了62.9K星星数了,一经发布即开源。 因为人做的不是Agent产品,人做的是一个基建,是Harness系统。 再来说一下什么是Cordis,它是整个DeepSeek Harness的核心所在。 对于数据分析、代码 Review、画流程图这些场景特别有用,能明显提升 DeepSeek Harness 的交互体验。 相当于:纯文本 DeepSeek + ModLens = 给 Harness 补上了“眼睛”。写在最后目前DSH最大贡献,应该是把 Harness 这层真正做成了一个开放的平台。
今天跟大家讲讲 Deepseek Harness 怎么装、怎么用。 它主要是网页端操作,启动之后会监听一个端口,咱们直接打开浏览器访问这个端口地址就能用了。 镜像搞定后,直接用 NPX 命令安装 Deepseek Harness,官网也只给了这一条安装指令。 整体流程给大家捋一遍: 电脑装好 NodeJS; 命令行配置国内 NPM 镜像,提升下载速度; 运行 NPX 一键安装启动 Deepseek Harness; 浏览器访问监听端口进入网页端; 填入 Deepseek
Harness Engineering 从 Prompt Engineering 到 Context Engineering,再到 Harness Engineering,AI 工程的重心,正在从 “怎么把话说对 这也是 Harness Engineering 开始被频繁提起的背景。 二、Harness Engineering 到底是什么 通俗来说,Harness Engineering 就是围绕 AI Agent 搭建一整套 “可执行、可验证、可约束、可迭代” 的外层运行系统。 模型是 CPU,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 领域**。
Loop决定任务如何持续运行最基础的AgentLoop逻辑并不复杂:Harness将任务与当前上下文提交给模型,模型返回工具调用,Harness执行对应工具,再将结果放回上下文,驱动模型决定下一步。 若单次成功率为75%,连续3次全部通过的概率约为42%,因此一次成功运行很难证明Harness已经稳定。 系统级评测则面向Harness本身的长期表现:把真实失败案例持续加入回归评测集,通过一批任务和多次运行观察Harness的能力、稳定性和回归情况。 Harness的工程价值在于可控执行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 是代理系统的核心基础设施 模块化设计便于维护和扩展 安全性和可观测性不可或缺
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