- 综合排序
- 最热优先
- 最新优先
- 来自专栏服务端技术杂谈
harness工程演进
所以agent工程化的第一步，是需要思考的是选取什么样的agent架构驱动形式。 如果任务适合workflow，却强行采用自治agent，结果就是简单问题复杂化，效果不好。 好的工具是： 1.名称清晰：模型一眼就知道它解决什么问题； 2.参数少而明确：避免让模型在大量可选参数中猜测； 3.返回结构稳定：方便模型继续推理； 4.错误反馈可行动：不只是抛出底层异常； 5.权限边界清楚 也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。 对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。 harness为了支持长任务，至少需要考虑几个点： 1.session log：记住任务全过程； 2.checkpoint：把关键阶段保存可恢复状态； 3.state summary：把冗长过程压缩成可用摘要 在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。
17610编辑于 2026-06-04 Harness 工程简史
四、2026：正名之年——从个体经验到工程学科4.1 命名与验证（1-3月）2026年2月5日。 2月11日，OpenAI 发表了《Harness Engineering: Leveraging Codex in an Agent-First World》。 用 Opus 4.6 → 76.4%（#2 overall）。 篇章回答的核心问题工程层面提示词工程怎么说优化单次交互质量上下文工程让 AI 看什么管理信息输入Harness 工程怎么防止做错构建执行、验证、约束、恢复的外层系统AI 工程三部曲：《提示词工程简史》 · 《上下文工程简史》 · 《Harness 工程简史》（本文）三者合在一起，才是完整的 AI 交互工程。
20500编辑于 2026-06-21Harness Engineering：Agent工程新范式
二、Harness的五根支柱OpenAI把这套方法论拆成了五个可以直接落地的组件。结构化文档项目里维护一个docs目录，作为Agent的"单一事实来源"。系统架构图、执行计划、设计规格书都放在里面。 Copilot时代，AI帮你写得更快；Harness时代，AI替你写完整个模块，你负责验收。杠杆差了一个数量级。HashiCorp、Anthropic、Cursor都在2026年跟进这个方向。 Hashimoto在2月的文章里总结得很直白：花时间去工程化一个解决方案，让Agent永不再犯同一个错误。不是什么高深理论，就是工程纪律在Agent时代的延伸。 四、Harness不是银弹它目前最适合的是边界清晰、规范明确的工程任务。API开发、数据处理管道、测试用例生成、文档维护，这些活儿的特点是输入输出可验证、有明确的通过标准、变更范围相对独立。 1500个PR背后是大量的自动化测试基础设施、精细化的文档维护成本，以及工程师角色转型的时间投入。一个团队从传统模式切到Harness模式，前期需要一到两个月搭建和磨合。
25911编辑于 2026-06-08大话 Harness 设计：工程如何推进闭环
在工程语境里，Harness 的意思是包裹在 Agent 外部的那套完整控制系统，让模型的能力变成可预期的、可验证的、可迭代的工程行为。 在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 到这里，我们已经讲完了 Harness 的技术层面。 但还有一个同样重要的维度，是关于工程文化和工程哲学的。 当 Agent 的产出速度开始超越人类的处理速度，整个工程团队的运作方式必须重构。 这是整个 Harness Engineering 讨论里最具人文色彩的部分：工程师在做什么？在传统软件工程里，工程师的价值体现在写出正确、高效、优雅的代码。 平均提升 5 个模型的准确率 4.7 个百分点； 在 TerminalBench-2 上，使用 Claude Opus 4.6 达到 76.4%，超过了此前最好的 74.7%。
76111编辑于 2026-04-10在低代码设计中践行 Harness 工程
它提供的不是"另一种编程方式"，而是一个结构化的软件工程框架：组件是标准化的积木，事件是规范化的连接器，数据流是可视化的管道。 图2：NLP 意图 → 组件类型 → 回调枚举 → 动作组合的四级推理链路2.2 推理验证：覆盖率驱动的置信度提升ActionFeedbackHarness 是推理验证的核心机制。 工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是：将 AI 的每次输出都视为需要验证的假设，通过结构化的反馈机制逐步提升输出质量。 意图识别 NlpIntentResult intent = nlpDesignService.recognizeIntent(content); // 2. 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
27910编辑于 2026-05-03- 来自专栏MixLab科技+设计实验室
Harness Engineering 是什么？从上下文工程到驾驭工程
Harness Engineering 驾驭工程：通过构建受控环境，让AI在约束下高效可靠地工作。 想象AI是一匹拥有神力的独角兽，它力量强大但难以预测。 这不是魔法，这是一个正在被正式命名的工程实践：Harness Engineering。 谁第一次喊出了这个名字 2026 年 2 月 5 日，HashiCorp 联合创始人在他的博客文章中首次使用了「harness engineering」这个术语。 Harness 到底在做什么 根据 OpenAI 官方报告的描述，Harness 由三个核心类别组成： 第一层：Context Engineering（上下文工程）。 Harness 就是 AI Agent 的脚手架。 OpenAI 团队花了 5 个月时间来构建和完善他们的 Harness。 这不是某种「快速见效」的技巧，而是一个需要持续投入的系统工程。
13.5K95编辑于 2026-03-25 Harness Engineering：解锁大模型潜力的“缰绳”工程
Harness工程通过系统化的提示工程模板和输出约束，为AI设定清晰、不可逾越的指令边界。 这相当于为AI配备了一位“一审助理”，过滤掉大部分低级错误，让人工可以专注于更高层次的逻辑审阅和价值创造，真正实现人机协同的“1+1>2”。 最后，是提升团队协作效率。 Harness工程的核心价值，就在于同时担任“安全阀”和“油门”的角色。 2. 必须包含“验收标准”部分，列出3-5条可验证的条目。 3. 语言简洁，避免技术黑话。 通过这样的模板，你不仅确保了AI输出的稳定性和可用性，更是在沉淀团队的知识资产。 开发工程师：聚焦流程编排与工具集成 对于开发者，Harness Engineering提供了将AI能力工程化、产品化的利器。
17110编辑于 2026-06-18- 来自专栏TGLTommyAI前沿技术论文
Agent Harness ：2026年AI工程的核心范式
Martin Fowler——软件工程领域最受尊重的声音之一——在2026年2月专门撰文提出了"Harness Engineering（线束工程）"这个术语。 2. 工具执行层 Harness 负责 Agent 与外部世界之间的每一次交互，包括 shell 命令、API 调用、数据库查询、网络搜索和文件操作。 这些钩子让 Harness 工程师对 Agent 行为有精确控制，而无需修改模型或 Agent 的核心逻辑。 8. 这意味着 Harness 随时间会变得不那么重要——但就像提示工程今天依然有价值一样，Harness 工程也可能继续发挥作用。 在2026年，各大模型的基础能力已经趋于接近，真正决定 AI 产品质量的分水岭是 Harness 的设计质量——这正是从"提示工程时代"迈入"Harness 工程时代"的本质转变。
15000编辑于 2026-06-25 100倍效率的秘密不是模型，是Harness工程
全文信息密度很高，以下是核心内容：用AI coding agent的人比用Cursor聊天的人效率高10到100倍，比2005年的Google工程师高1000倍。这是真实数字。 他把方法论叫Thin Harness, Fat Skills。Harness是跑模型的程序，只管四件事：循环调模型、读写文件、管上下文、做安全检查。保持薄。 最常见的错误是反过来——harness塞了一堆东西，skill反而没什么内容。40多个工具定义吃掉半个context window，每个MCP调用2到5秒。 这一理念正成为AI时代高绩效工程团队的崭新信条。 harness = ThinHarness() # 获取任务：比如用户说 "检查一下 A2C 这批二级域名还活着吗" # 这里就直接对应你给的那批列表 target_list
33810编辑于 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里写请遵守代码规范。 这有用吗？
11000编辑于 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生成”。
51110编辑于 2026-04-10- 来自专栏【腾讯云开发者】
Harness Engineering如何工程化落地？
我自己现在对 Harness Engineering 的理解很简单： 它不是某一个工具，也不是某一条提示词技巧，而是一整套让 AI 在工程里稳定产出正确结果的工程系统。 如果把我们当前工程里的 Harness 全貌摊开来看，它大致已经长成了下面这样： 1设计规格文档先把需求目标、边界、版本意图说透。它解决的是“AI 到底要做什么”。 2Rule把基础规矩和底线写死。 它不会百分之百按文档执行 2. 它做完以后，你很难知道它现在到底做到哪了 3. WPF 工程、Unity 工程、后端服务、工具脚本仓库，它们需要的门禁和工作流一定不一样。 但你完全可以沉淀出每类项目的“最小可用 Harness 模板”。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。 这才是工程化。
4.7K68编辑于 2026-04-22 你的 AI Coding 到底有没有工程级 Harness？
，而是更需要 Harness。 尤其现在 GPT-Image2 的文生图能力已经非常好，用它来生成初步产品原型，很划算。 这就回到了前面那句话：没有 Harness 的长任务，本质上只是更长时间的赌博。 所以我越来越相信，工程级 Vibe Coding 的路线大概是这样的： 1. 先选稳定透明的工具，不要把生产力压在黑盒渠道上； 2. 先聊清楚真实需求，不要让 AI 替你脑补产品； 3. 因为真正能改变开发效率的，往往不是一句神奇 Prompt，而是你是否把 AI 放进了一套正确的 Harness 里。
19910编辑于 2026-05-26Agent Harness 工程！被忽视的另一半
凌晨两点，AI工程群里弹出一条消息：这个AI Coding工具又双叒叕把测试代码注释掉了，commit了一个半成品。紧接着是一连串苦笑的表情。 这种场景，对AI技术圈的朋友来说，应该不陌生。 模型是发动机，但Harness是传动系统、方向盘、刹车片。没有后者，前者再强也只是实验室里的玩具。 Harness都包含什么？ 有意思的是Viv Trivedy提出的那个等式：Agent = Model + Harness。如果你不是模型，那你就是Harness。 这句话听起来简单，但把它当真的人不多。 大多数工程师遇到agent犯蠢，第一反应是"这破模型"，然后把issue丢给供应商等下一版本。 很少有人意识到，问题可能出在自己搭的那层脚手架上。 这就是所谓的Harness Gap。 你今天让某个模型"能做到"的事情，和它在你手里实际"做成"的事情之间，隔着一个Harness。
9100编辑于 2026-06-24- 来自专栏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 就是把"会说话的大模型"变成"能干活的自主智能体"的工程运行时。
15930编辑于 2026-06-11 ClaudeCode-Harness Engineering驾驭者工程的最佳实践者
今天继续跟着我和Claude学习Harness Engineering驾驭者工程。这个我在前面就谈到了是AI编程工程化的一个重点，核心是让AI软件工程更加安全，可控，可靠的运行。 在前面我就提出过一个观点，其实ClaudeCode这个编程工具就是Harness工程的最佳实践者。所以这篇文章看下Claude自身是如何进一步解释该事情。 关于本文：本文基于对 Claude Code 六大核心维度的深度研究，从 Harness Engineering（驾驭工程）哲学视角重新审视 Claude Code 的设计逻辑。 Claude Code 被真正广泛采用的背后，是一套经过深思熟虑的设计哲学——Harness Engineering（驾驭工程）。 注意在这里我有句关键提示，即： 请列出Claude Code实践了Harness Engineering的关键点。 我需要你从 1.工具集成调用 2. 上下文管理 3. 安全 4. 可控 5.
2.7K42编辑于 2026-04-13- 来自专栏Harness合集
10｜Agent Harness 的未来：从代码助手到工程协作系统
AI不再只是给建议，而是能进入仓库、读取上下文、修改文件、运行测试、连接外部工具，参与真实工程流程。下一步，它会从“代码助手”变成“工程协作系统”。 模型只负责推理，Harness要负责把任务过程保存下来。趋势二：从单Agent到多Agent协作复杂工程任务天然需要分工。 未来Harness会越来越像研发平台的一部分：谁让Agent做了什么，读了哪些文件，跑了哪些命令，改了哪些代码，调用了哪些外部系统，都要能审计。 工程师的价值会更多体现在：定义正确问题；拆分任务边界；设计验证标准；判断架构取舍；审查安全和兼容性；决定什么时候交付。AI可以写很多代码，但“该不该这么写”仍然需要工程判断。 真正可靠的方向是：展开代码语言：TXTAI代码解释AI做执行Harness做约束工具做验证人做判断这也是AI编程从个人效率工具走向团队工程系统的关键。
17700编辑于 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 让模型可靠自主地工作"。
36310编辑于 2026-06-11 - 来自专栏大模型应用开发
一个 LLM 是大脑，套上 Harness 才是工程师
然后宣布"我们有了工程 Agent"。 一个真正的工程任务跨好几天：建 JIRA、切分支、写草稿、review、回评论、CI 过、merge。没有任何一次 LLM 调用能 hold 住这个状态。 不会反应。外部世界变了，它不知道。 大脑（模型）在这些系统之间基本可以互换——变的是套在外面的 Harness。 大脑只通过 Harness 跟世界对话。让 LLM 表现得像个系统的，几乎全是 Harness 的工程活儿。 Layer 2 — Agent 编排 这是 LLM 真正运行的地方。 Dashboard 增加第三个需要维护的面，而且是工程师在它变陈旧后第一个停止看的东西。 MCP 健康监控 一个小服务——mcp-watchdog——每 10 分钟轮询每个 MCP 的健康端点。
5410编辑于 2026-06-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号