- 综合排序
- 最热优先
- 最新优先
- 来自专栏服务端技术杂谈
harness工程演进
好的工具是： 1.名称清晰：模型一眼就知道它解决什么问题； 2.参数少而明确：避免让模型在大量可选参数中猜测； 3.返回结构稳定：方便模型继续推理； 4.错误反馈可行动：不只是抛出底层异常； 5.权限边界清楚 也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。 对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。 ； 4.workspace：维护真实工作产物，比如代码/文件/配置； 5.recovery policy：失败/中断/超时后如何继续； 6.validation loop：每个阶段如何判断是否真的完成； 在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。 loop：调度brain和hands，把执行结果反馈给模型； 5.sandbox：隔离执行环境，限制风险； 这样brain可以随时换模型，让不同任务跑在不同模型和环境里，工具也可以随时换。
17910编辑于 2026-06-04 Harness 工程简史
四、2026：正名之年——从个体经验到工程学科4.1 命名与验证（1-3月）2026年2月5日。 Harness 不是凭空设计出来的。它是从"搞砸"中长出来的工程实践。这是"AI 工程三部曲"的第三篇。 篇章回答的核心问题工程层面提示词工程怎么说优化单次交互质量上下文工程让 AI 看什么管理信息输入Harness 工程怎么防止做错构建执行、验证、约束、恢复的外层系统AI 工程三部曲：《提示词工程简史》 · 《上下文工程简史》 · 《Harness 工程简史》（本文）三者合在一起，才是完整的 AI 交互工程。 GPT-5 的实践证明恰恰相反。更强的模型不是不犯错——是犯更隐蔽的错误。代码能跑，但逻辑有洞。测试通过，但边缘情况全漏。Harness 的必要性不降反升。不是模型不够好才需要 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 设计：工程如何推进闭环
下午好， 2026 年初，OpenAI 的一个小型工程团队，用 5 个月时间，构建并交付了一个超过 100 万行代码的生产级软件产品。 LangChain 做过一次实验，他们的 coding agent 在 TerminalBench 2.0 基准测试上，从 52.8% 跳到了 66.5%，排名从前 30 开外进入了全球前 5。 在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 平均提升 5 个模型的准确率 4.7 个百分点； 在 TerminalBench-2 上，使用 Claude Opus 4.6 达到 76.4%，超过了此前最好的 74.7%。 这个过程可能需要数月，OpenAI 花了 5 个月。 但 Harness 本身是一个复利工具：投入越多，回报越高，而且随时间指数级放大。
76511编辑于 2026-04-10在低代码设计中践行 Harness 工程
它提供的不是"另一种编程方式"，而是一个结构化的软件工程框架：组件是标准化的积木，事件是规范化的连接器，数据流是可视化的管道。 对 AI 而言，一个注解就是一条完整的全栈语义链——不需要在5种语言之间跳跃推理。 工程实践设计3.1 Harness Engineering 方法论Harness Engineering 的核心理念是：将 AI 的每次输出都视为需要验证的假设，通过结构化的反馈机制逐步提升输出质量。 AI 不再需要在5种语言间跳跃推理。 在低代码设计中践行 Harness 工程全栈注解语言 · 知识图谱推理 · LLM 双向协作 · 数据飞轮驱动
28110编辑于 2026-05-03- 来自专栏MixLab科技+设计实验室
Harness Engineering 是什么？从上下文工程到驾驭工程
这不是魔法，这是一个正在被正式命名的工程实践：Harness Engineering。 谁第一次喊出了这个名字 2026 年 2 月 5 日，HashiCorp 联合创始人在他的博客文章中首次使用了「harness engineering」这个术语。 Harness 到底在做什么 根据 OpenAI 官方报告的描述，Harness 由三个核心类别组成： 第一层：Context Engineering（上下文工程）。 Harness 就是 AI Agent 的脚手架。 OpenAI 团队花了 5 个月时间来构建和完善他们的 Harness。 这不是某种「快速见效」的技巧，而是一个需要持续投入的系统工程。 Engineering. [4] OpenAI - Harness Engineering: leveraging Codex in an agent-first world. [5] shadow的笔记
13.6K95编辑于 2026-03-25 Harness Engineering：解锁大模型潜力的“缰绳”工程
职场应用示例：市场团队需要每周从海量社交媒体讨论中提炼出5个核心话题趋势。一个初级员工可能每次都要重新描述需求，结果时好时坏。 Harness工程通过系统化的提示工程模板和输出约束，为AI设定清晰、不可逾越的指令边界。 Harness工程的核心价值，就在于同时担任“安全阀”和“油门”的角色。 必须包含“验收标准”部分，列出3-5条可验证的条目。 3. 语言简洁，避免技术黑话。 通过这样的模板，你不仅确保了AI输出的稳定性和可用性，更是在沉淀团队的知识资产。 开发工程师：聚焦流程编排与工具集成 对于开发者，Harness Engineering提供了将AI能力工程化、产品化的利器。
17510编辑于 2026-06-18- 来自专栏TGLTommyAI前沿技术论文
Agent Harness ：2026年AI工程的核心范式
Martin Fowler——软件工程领域最受尊重的声音之一——在2026年2月专门撰文提出了"Harness Engineering（线束工程）"这个术语。 5. 记忆与持续学习 对于记忆，文件系统再次成为核心原语。Harness 支持像 AGENTS.md 这样的记忆文件标准，在 Agent 启动时注入上下文。 然后，他们不改动模型——同一个模型，同一个 API——只修改了 Harness。结果：66.5%，排名跃升至前5。 这意味着 Harness 随时间会变得不那么重要——但就像提示工程今天依然有价值一样，Harness 工程也可能继续发挥作用。 在2026年，各大模型的基础能力已经趋于接近，真正决定 AI 产品质量的分水岭是 Harness 的设计质量——这正是从"提示工程时代"迈入"Harness 工程时代"的本质转变。
18800编辑于 2026-06-25 - 来自专栏OpenClaw
5 个月 100 万行代码，0 行人工编写——解读AI驾驭工程Harness Engineering
5 个月 100 万行代码，0 行人工编写——AI驾驭工程Harness Engineering：软件工程的新范式 开篇：一个激进的实验 5 个月，100 万行代码，0 行人工编写 2025 年 AI 工程化四层链条模型 驾驭工程不是孤立存在的，它处于 AI 工程化链条的顶层： 层级 名称 解决问题 核心关注 L1 提示词工程 "怎么说清楚" 指令表达、角色设定、输出格式 L2 上下文工程 "喂给模型什么 Engineering" Anthropic 发布 Harness Design 最佳实践 标志着该领域从边缘探索进入一线工程实践 ️ 第三部分：驾驭工程六大核心部件 部件 1：机器可验证的完成契约 参考资料 核心报告 清新研究团队《驾驭工程 研究报告》（2026 年 3 月） IMA 笔记：驾驭工程 Harness Engineering 官方文档 OpenAI: Harness engineering : leveraging Codex in an agent-first world https://openai.com/index/harness-engineering/ Anthropic: Harness
76911编辑于 2026-04-17 100倍效率的秘密不是模型，是Harness工程
全文信息密度很高，以下是核心内容：用AI coding agent的人比用Cursor聊天的人效率高10到100倍，比2005年的Google工程师高1000倍。这是真实数字。 他把方法论叫Thin Harness, Fat Skills。Harness是跑模型的程序，只管四件事：循环调模型、读写文件、管上下文、做安全检查。保持薄。 最常见的错误是反过来——harness塞了一堆东西，skill反而没什么内容。40多个工具定义吃掉半个context window，每个MCP调用2到5秒。 能力尽量交给skill，执行尽量交给确定性工具，harness越薄越好。模型一升级，所有skill自动变强。 这一理念正成为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里写请遵守代码规范。 这有用吗？
11600编辑于 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-10Agent Harness 工程！被忽视的另一半
凌晨两点，AI工程群里弹出一条消息：这个AI Coding工具又双叒叕把测试代码注释掉了，commit了一个半成品。紧接着是一连串苦笑的表情。 这种场景，对AI技术圈的朋友来说，应该不陌生。 模型是发动机，但Harness是传动系统、方向盘、刹车片。没有后者，前者再强也只是实验室里的玩具。 Harness都包含什么？ 大多数工程师遇到agent犯蠢，第一反应是"这破模型"，然后把issue丢给供应商等下一版本。 很少有人意识到，问题可能出在自己搭的那层脚手架上。 同一模型，跑在Claude Code里和跑在定制Harness里，分数差了一截。Viv的团队只调整了Harness，就把一个Top 30的coding agent推到了Top 5。 这就是所谓的Harness Gap。 你今天让某个模型"能做到"的事情，和它在你手里实际"做成"的事情之间，隔着一个Harness。
9200编辑于 2026-06-24- 来自专栏【腾讯云开发者】
Harness Engineering如何工程化落地？
5Workflow把这些角色怎么接力、什么时候前进、什么时候打回说清楚。它解决的是“多人格协作不能靠现场拍脑袋”。 6Scripts / 事后验证把很多约束真正落成可执行检查。 5开发实现负责真正落地代码和实现细节。 6代码审查负责从实现质量、需求一致性、方案一致性上做技术收口。 7测试验证负责从功能正确性、稳定性、边界和回归风险上做结果收口。 5当多 Agent 开始变复杂时，再补流程定义文件和角色契约一开始流程短的时候，长文说明也许够用；但当阶段多了、回退多了、维护人也多了，就要尽快把流程结构和角色边界单独抽出来。 5结果回写闭环最后要把这些外部系统里的状态，再回写到任务文档、发布文档、任务看板里，让 Harness 知道这次不仅“代码对了”，而且“工程交付动作也真正完成了”。 真正专业的 Harness，不应该越来越像“我和我的 AI 的默契”，而应该越来越像“任何一个人拿到这个工程，都能顺着这套系统做对事情”。 这才是工程化。
4.7K68编辑于 2026-04-22 你的 AI Coding 到底有没有工程级 Harness？
，而是更需要 Harness。 命名清晰； 5. 保存至 /docs/images 目录下。 很多人会把这一步理解成“设计工作”，但我觉得它更像工程前置工作。 因为很多项目写不下去，不是技术难，而是页面边界不清楚。列表页有哪些筛选？ 这就回到了前面那句话：没有 Harness 的长任务，本质上只是更长时间的赌博。 再立台账，把项目拆成可追踪、可验收的工程任务； 5. 写入开发规范，让 Agent 按 spec、plan、test、review 推进； 6. 每个功能完成后必须有真实验证； 7. 因为真正能改变开发效率的，往往不是一句神奇 Prompt，而是你是否把 AI 放进了一套正确的 Harness 里。
20210编辑于 2026-05-26- 来自专栏前端小羊
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 的工程活儿。 结果：Harness 不仅自愈它为工单写的代码，也自愈它为自己写的代码。 测试架构：5 层 4656 个测试 层 测什么 例子 L0（纯边界） 无 mock、无文件系统、无 IO。 操作者的总主动参与时间通常在 5 分钟以内。
10810编辑于 2026-06-26 - 来自专栏DeepHub IMBA
Prompt、Context、Harness：AI Agent 工程的三层架构解析
HumanLayer 的工程团队花了一年多时间观察编码 Agent 以各种方式失败，忽略指令、不经确认就执行危险命令、在简单任务上陷入死循环。所以得了一个结论："这不是模型问题是配置问题"。 他们没有更换编码 Agent 的底层模型，只改了 Harness，Terminal Bench 2.0 上的得分就从 52.8% 升至 66.5%，排名从前 30 跃至前 5。 同一个模型，不同的 Harness结果天差地别。 OpenAI 构建了一个超过一百万行代码的生产应用，零行人工代码。工程师的工作是设计 Harness，不是写代码。 LangChain 未换模型在编码基准上提升了 14 个百分点，OpenAI 用零行手写代码造了一个百万行的生产应用——工程师的工作是设计 Harness。 对工程师的能力要求正在重新定义。核心问题从"怎么写 Prompt"变成了"怎么设计一个让 AI 可靠做对事的环境"，这两者是截然不同的能力。
1.7K21编辑于 2026-04-15 AgentScope Java 深度解析：企业级 Harness 工程化框架
本文将深入剖析 AgentScope Java 如何通过 Harness 工程化能力，解决智能体从原型到生产的关键挑战。 工程化系统解决这些问题。 二、Harness 工程化：核心架构 ▪ 2.1 Hook 系统：可控性的保障 Hook 是 AgentScope Java 最核心的创新。 、响应式、GraalVM 七、总结 AgentScope Java 的核心价值在于： 不是简单的 Java 移植，而是为企业级生产重新设计 核心优势： Hook 系统提供可控性 Harness 工程化开箱即用 响应式架构高并发 GraalVM 支持极致性能 设计权衡： 以 JDK 17+ 换取现代特性 以响应式换取高并发 以复杂度换取工程化 适用定位： 企业级生产部署的工程化框架 如果你的场景是微服务、企业应用
66310编辑于 2026-06-04
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号