- 综合排序
- 最热优先
- 最新优先
- 来自专栏服务端技术杂谈
harness工程演进
这就是harness的价值。 harness是一套帮助Agent稳定可靠运行的闭环系统。 它就像一套让Agent自动运行的FSD，具备了全链路监控与持续优化的能力。 所以agent工程化的第一步，是需要思考的是选取什么样的agent架构驱动形式。 如果任务适合workflow，却强行采用自治agent，结果就是简单问题复杂化，效果不好。 这就引出了什么样的agent架构需要harness，显而易见的是高度自治的agent需要，harness就是给系统套上了安全带（比如状态记录/断点恢复/避免重复等）。 也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。 对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。 在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。
17910编辑于 2026-06-04 Harness 工程简史
Ryan Lopopolo（OpenAI Member of Technical Staff）详细记录了他们的内部实验：指标数据团队3 人起步 → 7 人时间跨度5 个月生成代码量~100 万行PR 数量 Harness 不是凭空设计出来的。它是从"搞砸"中长出来的工程实践。这是"AI 工程三部曲"的第三篇。 篇章回答的核心问题工程层面提示词工程怎么说优化单次交互质量上下文工程让 AI 看什么管理信息输入Harness 工程怎么防止做错构建执行、验证、约束、恢复的外层系统AI 工程三部曲：《提示词工程简史》 · 《上下文工程简史》 · 《Harness 工程简史》（本文）三者合在一起，才是完整的 AI 交互工程。 从 AutoGPT 搞砸一个登录页面，到 Harness 工程从每一次搞砸中长成一套完整的工程学科。这条路还在走。本文基于公开论文、工程博客和开发者社区记录整理。
20900编辑于 2026-06-21Harness Engineering：Agent工程新范式
OpenAI内部最近跑了一个实验：3到7个人，5个月，攒出一个接近100万行代码的beta产品。这100万行代码没有一行是人手写的，全部来自CodexAgent自动提交的1500个PR。 听起来有点理想化，但OpenAI的内部数据很实在：3到7名工程师，5个月，100万行代码，1500个PR，平均每人每天合并3到5个Agent提交的PR。不是演示，是生产交付。 二、Harness的五根支柱OpenAI把这套方法论拆成了五个可以直接落地的组件。结构化文档项目里维护一个docs目录，作为Agent的"单一事实来源"。系统架构图、执行计划、设计规格书都放在里面。 四、Harness不是银弹它目前最适合的是边界清晰、规范明确的工程任务。API开发、数据处理管道、测试用例生成、文档维护，这些活儿的特点是输入输出可验证、有明确的通过标准、变更范围相对独立。 1500个PR背后是大量的自动化测试基础设施、精细化的文档维护成本，以及工程师角色转型的时间投入。一个团队从传统模式切到Harness模式，前期需要一到两个月搭建和磨合。
26211编辑于 2026-06-08大话 Harness 设计：工程如何推进闭环
在工程语境里，Harness 的意思是包裹在 Agent 外部的那套完整控制系统，让模型的能力变成可预期的、可验证的、可迭代的工程行为。 在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 到这里，我们已经讲完了 Harness 的技术层面。 但还有一个同样重要的维度，是关于工程文化和工程哲学的。 当 Agent 的产出速度开始超越人类的处理速度，整个工程团队的运作方式必须重构。 这是整个 Harness Engineering 讨论里最具人文色彩的部分：工程师在做什么？在传统软件工程里，工程师的价值体现在写出正确、高效、优雅的代码。 模型是 CPU，Harness 是操作系统。 在没有 Harness 的情况下，直接在模型上构建生产级 Agent 系统，这不是工程，这是赌博。
76511编辑于 2026-04-10在低代码设计中践行 Harness 工程
它提供的不是"另一种编程方式"，而是一个结构化的软件工程框架：组件是标准化的积木，事件是规范化的连接器，数据流是可视化的管道。 7种核心意图覆盖了低代码平台 90% 以上的使用场景。每一步推理都有置信度标签，为可视化追踪提供了数据基础。 工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是：将 AI 的每次输出都视为需要验证的假设，通过结构化的反馈机制逐步提升输出质量。 数据飞轮（Data Flywheel）是 Harness Engineering 的核心闭环机制。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
28110编辑于 2026-05-03- 来自专栏MixLab科技+设计实验室
Harness Engineering 是什么？从上下文工程到驾驭工程
Harness Engineering 驾驭工程：通过构建受控环境，让AI在约束下高效可靠地工作。 想象AI是一匹拥有神力的独角兽，它力量强大但难以预测。 这不是魔法，这是一个正在被正式命名的工程实践：Harness Engineering。 再之后，知名工程师 Martin Fowler 在 Twitter 上为 Thoughtworks 工程师对这份报告的深度分析站台。 Harness 到底在做什么 根据 OpenAI 官方报告的描述，Harness 由三个核心类别组成： 第一层：Context Engineering（上下文工程）。 Harness 就是 AI Agent 的脚手架。 OpenAI 团队花了 5 个月时间来构建和完善他们的 Harness。 这不是某种「快速见效」的技巧，而是一个需要持续投入的系统工程。
13.6K95编辑于 2026-03-25 Harness Engineering：解锁大模型潜力的“缰绳”工程
这正是“LLM Harness Engineering”——大模型缰绳工程——诞生的背景与核心使命。它不是一个高深莫测的黑科技名词，而是一个极其务实、甚至可以说是“救火”般的工程学领域。 Harness工程通过系统化的提示工程模板和输出约束，为AI设定清晰、不可逾越的指令边界。 Harness工程的核心价值，就在于同时担任“安全阀”和“油门”的角色。 Harness工程正是实现这种深度融合的“连接器”和“赋能平台”。 首先，它实现与现有系统的无缝嵌入。 开发工程师：聚焦流程编排与工具集成 对于开发者，Harness Engineering提供了将AI能力工程化、产品化的利器。
17510编辑于 2026-06-18- 来自专栏TGLTommyAI前沿技术论文
Agent Harness ：2026年AI工程的核心范式
Martin Fowler——软件工程领域最受尊重的声音之一——在2026年2月专门撰文提出了"Harness Engineering（线束工程）"这个术语。 7. 中间件与生命周期钩子 这些是 Harness 工程师注入自定义逻辑的执行节点：工具调用前的输入验证、工具调用后的输出验证、针对任务规范的预完成检查、结构化错误格式化。 这些钩子让 Harness 工程师对 Agent 行为有精确控制，而无需修改模型或 Agent 的核心逻辑。 8. 这意味着 Harness 随时间会变得不那么重要——但就像提示工程今天依然有价值一样，Harness 工程也可能继续发挥作用。 在2026年，各大模型的基础能力已经趋于接近，真正决定 AI 产品质量的分水岭是 Harness 的设计质量——这正是从"提示工程时代"迈入"Harness 工程时代"的本质转变。
18800编辑于 2026-06-25 100倍效率的秘密不是模型，是Harness工程
全文信息密度很高，以下是核心内容：用AI coding agent的人比用Cursor聊天的人效率高10到100倍，比2005年的Google工程师高1000倍。这是真实数字。 他把方法论叫Thin Harness, Fat Skills。Harness是跑模型的程序，只管四件事：循环调模型、读写文件、管上下文、做安全检查。保持薄。 实战例子：YC 7月六千人Startup School，一个/enrich-founder skill每晚自动更新创始人档案，能发现“嘴上说做AI监控但80% commit在写计费模块”这种差距——embedding 实战层面，YC 7月Startup School期间，/enrich-founder Skill每晚自动更新创始人档案，精准识别出“宣称做AI监控却80%代码提交为计费模块”的错位情况。 这一理念正成为AI时代高绩效工程团队的崭新信条。
34010编辑于 2026-04-15Prompt升职了，多亏了 Harness 和 Loop 工程
2026年中，AI工程圈子里最热的讨论，已经从怎么写好一条Prompt变成了怎么设计一个能自己跑的Agent系统。 这个转变背后，其实是两套新范式的成熟：Harness工程和Loop工程。 Harness工程：给Agent造一个能干活的车间 先说个扎心的对比。 你写了一条Prompt：作为资深后端工程师，请review这段Python代码，遵循PEP8规范，检查潜在bug。 Prompt工程优化的是这一次，而真实生产环境需要的是每一次都一样靠谱。 Harness工程解决的就是这个问题。 Harness这个词，直译是马具——套在马身上用来传递力量和控制方向的那套装备。 Lopopolo说了一句很直接的话：当你的工程团队不再以写代码为主业，而是以设计环境、定义意图、搭建反馈回路为主业的时候，Harness就是那个核心产出。 这不是Prompt能解决的问题，这是工程问题！ 第二层是控制与验证层，这是Harness区别于普通Prompt工程的关键。 一个经典场景：你在Prompt里写请遵守代码规范。 这有用吗？
11300编辑于 2026-06-24AI工程圈大辩论：Big Model VS Big Harness？
在AI工程领域，最近也掀起了一场这样的争论。 一边是Big Model派，认为模型本身才是王道；另一边是Big Harness派，坚信框架工程才是关键。 Image Big Harness派的反击：姿势不对一切白费 但Big Harness派不同意。他们认为，Harness就是产品本身。 LlamaIndex创始人Jerry Liu说得更直接："模型框架就是一切——从AI获取价值最大的障碍，就是你自己对模型进行上下文和工作流工程的能力。工具越通用，这一点就越重要。" 随着Agent Labs的理论得到验证（Cursor估值已达500亿美元），我们不得不承认"Harness Engineering"确实有价值。 对于，AI来讲，我们也要适应AI能力提升以及环境不同，采用不一样的Harness措施，才是真正有意义的事情。
10110编辑于 2026-06-23Harness Engineering：当工程师不再亲手写代码
HarnessEngineering：当工程师不再亲手写代码OpenAI最近发了一篇工程文章，题目是Harnessengineering:leveragingCodexinanagent-firstworld 最开始是3个工程师在驱动Codex，后来团队扩到7个人，整体交付吞吐量没有下降，还继续提高了。后面主要讲的是工程师角色怎么变化：当代码不再是主要产出，工程重心会往哪一层移动。 工程师的工作被重新定义了文章里有一句很重要：人类工程师的主要工作，不再是写代码，而是设计环境、指定意图、建立反馈循环，让Codex能稳定地做可靠工作。文章后面给了很多具体细节，把这句话落了下来。 吞吐量上来以后，mergephilosophy也变了随着Codex吞吐量越来越高，他们发现很多传统工程规范开始变得不合适。 很多原本默认正确的工程哲学，本身就要跟着改。“agent-generated”到底是什么意思文章专门解释了一次，什么叫“整个代码库由Codex生成”。
51210编辑于 2026-04-10- 来自专栏111222444
Agent Harness
Agent Harness（智能体驾驭层/运行框架） 是包裹在大模型（LLM）之外、让它能真正执行任务而非只"说"不"做"的那整套工程运行时基础设施。 业界共识公式：Agent = Model（大模型）+ Harness（驾驭层） 为什么叫 Harness？ 类比帮助理解 Model = CPU，Harness = 操作系统（OS）——CPU 再强没有 OS 也跑不了应用 Model = 主厨大脑（决定怎么做菜），Harness = 厨房+炉灶+帮厨（ 真正点火翻面装盘） Claude Code / Cursor Agent / OpenCode 本质上就是围绕某模型构建的 Agent Harness，所以同一模型配上不同 Harness 体验差异巨大 一句话：Harness 就是把"会说话的大模型"变成"能干活的自主智能体"的工程运行时。
16030编辑于 2026-06-11 Agent Harness 工程！被忽视的另一半
凌晨两点，AI工程群里弹出一条消息：这个AI Coding工具又双叒叕把测试代码注释掉了，commit了一个半成品。紧接着是一连串苦笑的表情。 这种场景，对AI技术圈的朋友来说，应该不陌生。 模型是发动机，但Harness是传动系统、方向盘、刹车片。没有后者，前者再强也只是实验室里的玩具。 Harness都包含什么？ 有意思的是Viv Trivedy提出的那个等式：Agent = Model + Harness。如果你不是模型，那你就是Harness。 这句话听起来简单，但把它当真的人不多。 大多数工程师遇到agent犯蠢，第一反应是"这破模型"，然后把issue丢给供应商等下一版本。 很少有人意识到，问题可能出在自己搭的那层脚手架上。 这就是所谓的Harness Gap。 你今天让某个模型"能做到"的事情，和它在你手里实际"做成"的事情之间，隔着一个Harness。
9200编辑于 2026-06-24- 来自专栏【腾讯云开发者】
Harness Engineering如何工程化落地？
7开发导航地图（dev-map）让 AI 快速理解项目结构和既有模式。它解决的是“不要一进项目就重复造轮子”。 8任务看板让 PM 和需求分析知道项目历史和当前进展。 7测试验证负责从功能正确性、稳定性、边界和回归风险上做结果收口。 这里最重要的不是“正好七个”，而是这七个角色各自解决了一个前一个角色解决不了的问题。 7当你想把闭环继续往外推时，再考虑 MCP先把开发闭环跑通，再去接构建、签名、发布、制品这些外部工程系统。不要一开始就把整个世界都接进来。 WPF 工程、Unity 工程、后端服务、工具脚本仓库，它们需要的门禁和工作流一定不一样。 但你完全可以沉淀出每类项目的“最小可用 Harness 模板”。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。 这才是工程化。
4.7K68编辑于 2026-04-22 你的 AI Coding 到底有没有工程级 Harness？
，而是更需要 Harness。 每个任务都要写明测试和验证方式； 7. 保存至 /docs/plans 目录下。 台账最好不要只写“开发首页”“开发后台”这种粗任务。它应该细到 Agent 能拿着其中一项独立推进。 这就回到了前面那句话：没有 Harness 的长任务，本质上只是更长时间的赌博。 再立台账，把项目拆成可追踪、可验收的工程任务； 5. 写入开发规范，让 Agent 按 spec、plan、test、review 推进； 6. 每个功能完成后必须有真实验证； 7. 因为真正能改变开发效率的，往往不是一句神奇 Prompt，而是你是否把 AI 放进了一套正确的 Harness 里。
20210编辑于 2026-05-26ClaudeCode-Harness Engineering驾驭者工程的最佳实践者
今天继续跟着我和Claude学习Harness Engineering驾驭者工程。这个我在前面就谈到了是AI编程工程化的一个重点，核心是让AI软件工程更加安全，可控，可靠的运行。 在前面我就提出过一个观点，其实ClaudeCode这个编程工具就是Harness工程的最佳实践者。所以这篇文章看下Claude自身是如何进一步解释该事情。 关于本文：本文基于对 Claude Code 六大核心维度的深度研究，从 Harness Engineering（驾驭工程）哲学视角重新审视 Claude Code 的设计逻辑。 Anthropic 内部数据显示，工程师的代码产出在过去一年增长了 200%；仅 2025 年 7 月，Claude Code 就处理了来自 115,000 名开发者的 1.95 亿行代码。 Claude Code 被真正广泛采用的背后，是一套经过深思熟虑的设计哲学——Harness Engineering（驾驭工程）。
2.7K42编辑于 2026-04-13- 来自专栏Harness合集
10｜Agent Harness 的未来：从代码助手到工程协作系统
AI不再只是给建议，而是能进入仓库、读取上下文、修改文件、运行测试、连接外部工具，参与真实工程流程。下一步，它会从“代码助手”变成“工程协作系统”。 模型只负责推理，Harness要负责把任务过程保存下来。趋势二：从单Agent到多Agent协作复杂工程任务天然需要分工。 未来Harness会越来越像研发平台的一部分：谁让Agent做了什么，读了哪些文件，跑了哪些命令，改了哪些代码，调用了哪些外部系统，都要能审计。 工程师的价值会更多体现在：定义正确问题；拆分任务边界；设计验证标准；判断架构取舍；审查安全和兼容性；决定什么时候交付。AI可以写很多代码，但“该不该这么写”仍然需要工程判断。 真正可靠的方向是：展开代码语言：TXTAI代码解释AI做执行Harness做约束工具做验证人做判断这也是AI编程从个人效率工具走向团队工程系统的关键。
17900编辑于 2026-06-09 - 来自专栏前端小羊
Agent Harness
Harness Agent（或称 Agent Harness） 不是某个具体产品名，而是指给大模型套上"工程外壳"后形成的、可自主执行任务的完整智能体系统。 核心定义 业界共识公式： Agent = Model（大模型）+ Harness（驾驭层/运行框架）Model：负责推理、理解、生成文本（LLM 本身只会 input→output）Harness：模型之外的一切工程设施 Harness 阶段：你说"修复登录 Bug 并跑测试"，Harness 自动拆任务→读代码→改文件→跑测试→看结果→再修正，直到完成或触发人工介入。 一句话理解 裸 LLM 是"会说话的引擎"，Harness 是"方向盘+刹车+仪表盘+道路规则"，二者结合才是能上路干活的 Harness Agent（完整智能体）。 开发重点从"调模型"变成了"设计好 Harness 让模型可靠自主地工作"。
36810编辑于 2026-06-11 - 来自专栏大模型应用开发
一个 LLM 是大脑，套上 Harness 才是工程师
然后宣布"我们有了工程 Agent"。 一个真正的工程任务跨好几天：建 JIRA、切分支、写草稿、review、回评论、CI 过、merge。没有任何一次 LLM 调用能 hold 住这个状态。 不会反应。外部世界变了，它不知道。 大脑（模型）在这些系统之间基本可以互换——变的是套在外面的 Harness。 大脑只通过 Harness 跟世界对话。让 LLM 表现得像个系统的，几乎全是 Harness 的工程活儿。 共 7 个 gate。 外加两个抽查：EQ1 要求根因节点引用硬证据（非 INFERRED），否则接受 60% 上限。P7 对每个标记 FAIL 的对抗性维度降 7% 上限，地板 40%。 Dashboard 增加第三个需要维护的面，而且是工程师在它变陈旧后第一个停止看的东西。 MCP 健康监控 一个小服务——mcp-watchdog——每 10 分钟轮询每个 MCP 的健康端点。
10210编辑于 2026-06-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号