三大流派三种架构——以及Opus 4.7刚刚证明的一切2026年2月OpenAI发了一篇博客悄悄重新定义了软件工程师的日常工作。标题只有两个词“Harness Engineering”。文章描述了一个小团队如何在没有手写一行代码的情况下上线了一百万行生产代码。他们做的事情不是写代码而是设计AI Agent工作的环境——约束条件、反馈循环、文档结构、依赖规则。Agent负责写代码人负责设计让Agent可靠运转的系统。几周之内Anthropic发表了三篇关于同一概念的工程论文有效harness、harness设计、managed agents。ThoughtWorks搭建了一套正式框架Red Hat写出了落地指南Hugging Face的Philipp Schmid称其为2026年最重要的工程学科。一个新的工程学科在90天内横空出世。而且它的演进速度快得超乎所有人的预期。就在昨天Anthropic发布了Opus 4.7——不到一年内的第三代模型。每一代不只是模型更强而是harness变得更简单。三月份还是承重墙的组件四月份就成了多余的摆设。这门学科诞生才90天就已经在改写自己的规则。“参考链接https://ai.gopubby.com/harness-engineering-what-every-ai-engineer-needs-to-know-in-2026-0ab649e5686a数字能说明问题有多紧迫。LangChain用同一个模型在Terminal Bench 2.0上跑了两次一次用老harness一次用新harness。模型没变harness换了得分从52.8%跳到了66.5%。Vercel走了另一条路直接删掉了80%的Agent工具结果反而性能更好。工具越少约束越紧输出越强。如果说2025年是AI Agent证明自己能写代码的一年2026年就是我们发现Agent从来不是难点的一年。难的是harness。但真正让这个时刻有意思的是三大流派对harness该做什么产生了根本性的分歧。他们认同问题所在但对架构的看法截然不同。而这个选择绝不是学术讨论——它直接决定了成本、所需人手以及Agent产出的是可用的软件还是昂贵的幻觉。Harness到底是什么ThoughtWorks的Sunit Parekh在《Beyond Vibe Coding》里给出了最简洁的定义“Agent 模型 HarnessHarness就是除了模型本身之外的一切。是让Agent保持方向的约束是捕捉错误的反馈循环是告诉Agent当前位置和已完成工作的文档以及它被允许使用的工具。把harness拆掉剩下的就是一个在代码库里瞎猜的裸模型。配上合适的harness就是一个能上线生产代码的系统。OpenAI团队在给它命名时用了一个更古老的比喻。Harness是马具缰绳、马鞍、嚼口把一匹强壮但难以预测的动物引向有用的方向。不是让马更聪明而是设计出让它的力量变得可用的装备。Philipp Schmid用了一个更技术性的类比值得好好琢磨把它想象成一台电脑——模型是CPU原始算力上下文窗口是内存有限的、易失的工作记忆harness是操作系统管理CPU看到什么、什么时候看到而Agent则是运行在这一切之上的应用程序。如果有金融或风控背景还有一个更直接的理解方式harness就是控制框架。就是那套确保自主系统在可接受边界内运行的策略、检查点和审计链。合规团队做这件事已经做了几十年只是AI世界给它起了个新名字。那些零件长什么样大多数文章把harness定义得很抽象然后就结束了这远远不够。如果真要自己动手搭一个就得看清楚每个零件长什么样。以下是各大主流实现中反复出现的关键文件。AGENT.md / CLAUDE.md 文件通用模式名字不同这是分散在整个代码库里的markdown文件Agent每次开始会话都会读一遍。OpenAI的Codex叫它AGENT.mdAnthropic的Claude Code叫它CLAUDE.mdCursor用的是.cursorrules。名字不同原理一样里面写的是项目上下文、编码规范、架构决策以及我们这里怎么做事的指导方针。OpenAI的Sora Android团队在整个代码库里都维护着这些文件。Agent读它们就像新加入团队的工程师在冲刺中途读入职文档一样——每个主要模块一个文件随着项目演进不断更新。# AGENT.md - 认证模块## 架构- OAuth2流程配合PKCE令牌存储在加密的SharedPreferences中- 禁止以明文存储令牌禁止在日志中记录令牌值## 规范- 所有认证错误统一通过AuthErrorHandler处理- 重试逻辑指数退避最多3次## 当前状态- v1到v2令牌格式的迁移正在进行中见issue #247JSON功能列表Anthropic模式当一个Agent需要在多个会话里构建完整应用时每次新会话都从空白上下文开始。Agent怎么知道哪些已经做完、该做什么Anthropic的答案是一个JSON文件同时充当项目规格说明和进度追踪器。每个条目定义一个功能、验证步骤和通过/失败状态。在他们的claude.ai克隆演示中这个列表有200多个独立功能全部从failing开始。Agent每次会话开始时读取这个文件挑出优先级最高的未完成功能实现它根据测试步骤验证标记为passing然后提交。这东西既是测试套件又是项目看板人和Agent都能读。{ category: authentication,feature: 通过邮件重置密码,verification: [ 在登录页点击忘记密码, 输入已注册的邮箱地址, 验证30秒内收到重置邮件, 点击重置链接输入新密码, 确认用新密码登录成功 ],status: failing}为什么用JSON而不是markdownAnthropic发现模型比起Markdown文件不太会不恰当地修改或覆盖JSON文件。细节但在Agent自主运行几个小时的时候很关键。会话初始化流程Anthropic模式每次编码会话都遵循同样的7步启动序列确认工作目录、读取git日志和进度文件、查阅功能列表找出优先级最高的未完成功能、启动开发服务器、运行基本端到端验证、实现单个功能、然后提交并附上描述性信息和进度更新。这不是可选项。没有这套流程每次新会话都从头开始Agent要浪费前20分钟弄清楚已经做了什么。结构化任务模板Red Hat模式在任何编码开始之前harness使用语言服务器和代码分析工具分析真实代码库生成有据可查的影响图。然后生成包含真实文件路径、真实符号名、已有模式参考和具体验收标准的任务模板。不靠猜不产生幻觉。冲刺契约Anthropic模式在生成器Agent开始写代码之前它会和评估器Agent协商。生成器提出要构建什么以及如何验证成功评估器审查提案的完整性。双方达成一致后才开始实现。这是优秀工程团队早就在做的设计评审的轻量级版本只不过两个参与者都是AI。把这些文件放在一起看一个规律就出现了每一个都是为了回答同一个问题——在写第一行代码之前Agent需要知道什么答案是很多。它在代码库的哪个位置、已经完成了什么、好长什么样、什么不能碰、怎么验证自己的工作。这不是智能这是上下文。而上下文事实证明才是harness工程真正在生产的东西。三大流派Harness Engineering这个词不是从委员会或者大会主题演讲里冒出来的。三个团队各自独立撞上了同一堵墙然后每个人搭了一把不同的梯子爬过去。OpenAI「一百万行没人写的代码」OpenAI的Codex团队面对的问题荒诞得几乎难以置信——他们在构建一个生产应用而Agent写了所有的代码。不是部分是全部。一百万行人类一行没写。在这种规模下传统的逐行代码审查完全行不通。一百万行没法审。能做的是把环境设计得足够完善让Agent从一开始就产出可审查的输出。他们最核心的教训是用血和汗换来的给Codex一张地图而不是一本1000页的使用手册。他们建立了严格的依赖流类型 → 配置 → 仓库 → 服务 → 运行时 → UI并用结构测试强制执行。他们在代码库各处嵌入AGENT.md文件作为分布式文档把Agent直接接入CI/CD管道让每次变更都自动被测试。核心理念是设计好环境然后放Agent进去。人的角色是架构师不是程序员。证明这套方法有效的是Sora Android的构建。四名工程师28天消耗约50亿token应用上线后登顶Play Store崩溃率99.9%免疫。Codex每周处理70%的内部PR工程师把时间花在高层架构、规划和验证上其余的交给Agent。Anthropic「Agent一直在夸自己烂掉的作品」Anthropic的问题更微妙某种程度上更难解决。他们在构建需要在数小时自主工作中产出完整应用的长运行Agent模型能力是够的问题出在质量控制上。当他们让Agent评估自己的输出时它会自信地夸赞那些工作即使在人类观察者看来质量明显很差。自我评估行不通Agent既是学生又是老师给自己打了满分。解决方案的灵感来自生成对抗网络GAN把做事的和评判的分开。由此诞生了三Agent架构**规划器Planner**把简短的提示扩展成全面的产品规格**生成器Generator**逐冲刺实现功能**评估器Evaluator**用Playwright浏览器自动化像真实用户一样与运行中的应用交互按照明确标准给每个冲刺打分。关键洞察是把一个独立的评估器调教得足够挑剔远比让生成器对自己的工作保持批判性思维更可行。架构继续演进从两个Agent初始化器加编码器到三个Agent规划器、生成器、评估器再到完全解耦的managed agents系统——大脑、执行环境和会话日志都是独立的、可替换的组件。这种解耦让P50首token时间缩短了60%P95缩短超过90%。核心理念把执行者和评判者分开让评判者很难被打动。ThoughtWorks「在50个客户团队里看到了同样的失败模式」ThoughtWorks从完全不同的起点走到了harness工程。他们不是在构建产品而是在观察各行各业几十个工程团队尝试采用AI Agent然后反复看到同样的失败模式。资深工程师Birgitta Böckeler在2026年4月发布了三者中最完整的框架。OpenAI构建了一个系统Anthropic构建了一种架构ThoughtWorks构建了一套分类学。他们的框架沿两个维度对harness控制进行分类。第一个维度前馈在Agent行动之前引导行为的指导vs反馈观察结果并启用自我纠正的传感器。两者缺一不可——只有反馈意味着错误反复发生只有前馈意味着永远不知道指导是否真的有效。第二个维度计算型确定性检查如linter、类型检查器、测试套件毫秒级运行vs推断型另一个LLM的语义分析更慢更贵但能捕捉代码分析发现不了的问题。核心理念分类、系统化给团队一套共同词汇来描述他们在构建什么。三种架构的横向对比OpenAI/Codex环境优先的HarnessCodex harness在能够大量前期投入设计环境时效果最好。下游的自主性收益巨大但前期成本是真实存在的。工作原理harness就是代码库本身。AGENT.md提供上下文结构测试机械地执行架构规则依赖流防止Agent以错误顺序构建东西CI/CD管道自动验证每次变更。Agent以高度自主的方式运作开PR、响应审查反馈、运行测试、迭代失败、达标后合并。人类不审查每一行而是审查让每一行可审查的约束。最擅长大型代码库。几十万行的项目环境优先的方法能扩展因为约束嵌在仓库结构里。加新模块加AGENT.mdAgent就能进去工作不需要重新训练或配置。OpenAI估计他们以原本手写代码约1/10的时间完成了交付。薄弱之处这种方法假设能在Agent开始工作之前全面定义环境。对于架构还没想清楚的全新项目这很难。它也严重依赖结构测试和CI管道能检查代码是否正确但检查不了是否写得好。一个函数可以通过所有测试同时仍然是个糟糕的设计。Anthropic多Agent HarnessAnthropic的方法每次运行成本更高但能捕捉到环境优先方法漏掉的问题。权衡在质量vs速度之间——对于输出质量比输出速度更重要的应用值得认真考虑。工作原理三个有明确角色的专职Agent。规划器把1~4句话的用户提示扩展成全面的产品规格聚焦于可交付成果和高层设计刻意避免可能级联出错误的细粒度实现细节。生成器使用标准技术栈React、Vite、FastAPI、SQLite/PostgreSQL逐功能实现交付前先自评。评估器用Playwright浏览器自动化像真实用户一样与运行中的应用交互按照明确的评分标准测试UI功能、API端点和数据库状态。每个冲刺开始前生成器和评估器会协商一份冲刺契约定义要构建什么以及如何衡量成功。这是一次轻量级设计评审只不过两个参与者都是AI Agent。最擅长需要高质量和正确性的应用。评估器能捕捉测试单独发现不了的问题能渲染但不可用的UI元素、技术上可用但工作流不直观的功能、返回正确数据但格式错误的API端点。Anthropic的测试显示单独Agent9美元20分钟产出了功能残缺的应用完整harness200美元6小时产出了界面精致、功能正确的可用软件。薄弱之处成本和时间。三Agent系统明显比单Agent贵评估器需要大量的提示调优。不经调校的话它能识别真实问题然后又找理由接受它们。让它真正挑剔花了Anthropic好几轮开发迭代。好消息是随着模型改进harness变得更简单。Anthropic从Opus 4.5升级到Opus 4.6时整个冲刺分解步骤被移除改为单次评估成本从Opus 4.5版本明显下降。Opus 4.72026年4月16日发布让这一趋势进一步加速模型现在会在上报结果之前自行验证输出产出更干净的代码工具错误只有以前的三分之一。每一代模型都在啃掉评估器的工作职责。ThoughtWorks分类学HarnessThoughtWorks没有构建一个可以直接部署的系统而是构建了一种思考harness的方式帮助用户自己设计。如果不打算采用Codex或Claude的特定工具这是最有用的方法但需要最多的自主工作来落地。工作原理每个harness控制沿两个维度分类。第一它是指导前馈在Agent行动前应用还是传感器反馈在行动后观察结果第二它是计算型确定性类似linter毫秒级还是推断型使用LLM秒级但能捕捉代码分析发现不了的问题这给出了一个2×2的控制类型矩阵计算型指导前馈类型系统、linter、架构决策记录计算型传感器反馈测试套件、覆盖率分析、变异测试、结构复杂度检查推断型指导前馈规格文档、设计提示、约束描述推断型传感器反馈基于LLM的代码审查、语义质量评估、行为验证器最擅长拥有成熟代码库的现有团队。如果已经有linter、测试套件和CI管道ThoughtWorks框架能帮你意识到harness已经搭了一半了。分类学告诉你缺什么、在哪里投入。他们还提出了一个很有价值的概念“可harnessability”——强类型语言、清晰的模块边界和结构良好的框架天然让Agent工作更成功。选新项目技术栈的时候这一点值得考虑。薄弱之处它是描述性的不是规定性的。框架告诉你存在哪些类型的控制但不告诉你用哪些具体工具或如何把它们连接起来。想要一站式解决方案的团队会失望——这是蓝图不是建筑。他们独立发现的五个共同原则剥掉实现的差异一个出乎意料的事情浮现出来三个从不同起点出发、从未协调过的团队得出了同样的五条原则。这种独立收敛通常意味着发现了真实存在的东西。① 上下文比指令更重要OpenAI总结出给一张地图而不是一本手册。Anthropic构建了JSON功能列表和进度文件让Agent随时知道自己在哪里。Red Hat的整个工作流建立在分析真实代码库之后才生成任务的基础上。ThoughtWorks称之为前馈。标签不同发现一样把Agent锚定在真实状态真实文件路径、真实代码模式、真实进度产出一致优于用抽象术语告诉它该做什么。在真实代码库中接地气的Agent写出来的代码是合适的基于模糊描述工作的Agent会幻觉出不存在的文件路径和API。② 规划和执行必须分开OpenAI把环境设计人类和代码生成Agent分开。Anthropic在Generator碰任何代码之前先运行专属的Planner Agent。ThoughtWorks规定在规划和实现之间有人工审查检查点。Red Hat分为阶段1影响图和阶段2实现中间有硬性关卡。每个流派都独立发现让Agent在同一个过程中既规划又执行会产出不可靠的结果。规划步骤不必由人类或独立Agent完成但必须是独立的步骤其输出在实现开始之前经过审查。③ 反馈循环不可或缺OpenAI把Agent接入CI/CD管道和可观测性系统。Anthropic构建了专用的评估器Agent用浏览器测试运行中的应用。ThoughtWorks把这正式化为传感器并警告说仅有前馈的方法有指导但无验证永远无法确认指导是否真的有效。分歧不在于是否需要反馈而在于由谁提供。OpenAI用自动化测试和CIAnthropic用另一个LLMThoughtWorks说两者都用、分层叠加先计算型反馈快、便宜、确定性再推断型反馈慢、贵、语义级。三者都认同没有反馈机制的harness不过是加了多余步骤的提示词。④ 一次只做一件事OpenAI把目标拆成更小的构建块深度优先推进。Anthropic强制每次冲刺只实现一个功能实现后即提交。ThoughtWorks描述了分阶段生命周期预集成、后集成、持续监控。Agent试图同时做太多事情就会耗尽上下文、失去连贯性或悄悄丢掉需求。强制增量主义——Agent完成一个工作单元后再开始下一个——在每个成功的harness实现中都是普遍原则。Anthropic使用的会话初始化流程读取进度、选一个功能、实现、提交、循环是最清晰的表达但每个流派都以各自的方式强制执行。⑤ 代码库就是文档OpenAI在仓库中嵌入AGENT.md文件。Anthropic将功能列表、进度文件和git历史作为Agent的连续性机制。ThoughtWorks衡量可harnessability即代码库本身对Agent的可读程度。Red Hat说把所有规范都纳入版本控制。没有人为Agent维护独立的知识库。仓库就是单一事实来源。如果一个规范、约束或架构决策不在代码库里Agent就不知道它的存在。这有一个实际影响在代码组织、清晰模块边界和嵌入式文档上投入的团队免费获得了更好的Agent性能。把它做对要花多少钱Harness工程不免费。每种方法都涉及前期投入、每次运行成本和持续维护之间的权衡。Anthropic的A/B测试数据Anthropic发布了迄今为止最清晰的成本对比用同一个应用提示分别跑单Agent和完整多Agent harness。单Agent无harness9美元20分钟。输出有可用的UI但核心功能残缺实体对用户输入没有响应看起来像应用但用起来不像。完整harnessOpus 4.5200美元6小时。输出有真正可玩的游戏界面精致视觉风格一致物理效果正确。22倍的成本差异换来的是功能产品vs只在截图里好看的演示。这到底算贵还是便宜完全取决于一次残缺发布对团队意味着什么代价。模型改进带来的红利从Opus 4.5升级到Opus 4.6后Anthropic大幅简化了harness移除了冲刺分解改为单次评估取消了上下文重置。结果一个完整的数字音频工作站应用124.70美元3小时50分钟。比Opus 4.5版本成本降低38%时间缩短36%完全由模型改进驱动。Opus 4.7延续了这条趋势线。CursorBench得分从58%跳到70%Rakuten-SWE-Bench上解决的生产任务是原来的3倍在更少token的情况下比Opus 4.6提升了14%。三代模型三轮harness简化这是趋势不是偶然。但这并不意味着harness的需求消失了。Opus 4.6的评估器仍然发现了明显的缺口缺失的交互时间线控件、不存在的乐器UI面板、不完整的音频录制功能。没有评估器这些功能就会以残缺或损坏的状态上线。Harness随每代模型收缩但还没有消失。隐性成本维护没人大声说出口的数字是维护成本。Harness不是一次性构建而是持续的工程承诺。Manus六个月内重构了五次harnessLangChain一年内重构了三次。这不是糟糕工程的标志而是在快速改进的模型之上构建的自然结果。每次模型变好harness的某个部分就成了多余的开销而找出是哪个部分需要主动测试。Philipp Schmid的建议“build to delete”为删除而构建。把每个harness组件设计成可移除的定期关掉每个组件测试输出质量是否变化如果不变就删掉它。带着无用的harness组件每次运行都要多花token增加维护负担但什么好处都得不到。最大的悖论为删除而构建有一个令人不舒服的真相藏在Anthropic的数据里三个流派都没大声说出来。升级到Opus 4.6时他们不只是得到了更好的结果还得到了更简单的结果。冲刺分解——对Opus 4.5在长时间编码会话中保持连贯性至关重要的功能——变得不必要了。模型改进了规划和长上下文处理能力把这个组件变成了多余的东西。三月份的承重墙四月份就成了死重。然后Opus 4.7在4月16日上线把这个模式推得更远。模型现在在上报结果之前会自行验证输出——正是那个曾经证明需要独立评估器Agent的能力缺口。它产出更干净的代码减少了包装函数和不必要的脚手架工具错误只有以前的三分之一。轨迹很清晰4.5需要完整的冲刺分解和逐冲刺评估4.6取消了冲刺分解改为单次评估4.7正在开始将评估本身内化。Anthropic称之为“harness衰减”。harness里的每个组件都编码了一个关于模型不能做什么的假设。随着模型改进这些假设会过期而那个曾经在补偿限制的组件就变成了开销。这方面的证据无处不在。Manus六个月内重构了五次harnessLangChain一年内重构了三次Vercel删掉80%的工具反而性能更好。每个案例都是同一个故事上个月有用的东西这个月成了负担。Philipp Schmid把这和Rich Sutton的机器学习苦涩教训联系起来随计算规模扩展的简单方法始终优于复杂的手工设计方案。应用到harness上含义很清晰不要构建复杂的、紧耦合的控制系统而要构建模块化的、可以逐块删除的系统。这给工程团队制造了一个真实的悖论。现在需要harness才能从AI Agent那里得到可靠的输出但今天构建的harness明天就需要部分拆除。而在模型已经超越之后还死抱harness架构的团队会在每次运行中缴税多花token、多花延迟、多花维护零额外质量。实际建议很简单即使感觉反直觉给每个harness组件设计一个开关定期关掉它测量输出质量质量不变就删掉。更深的问题还没有人给出答案随着模型持续改进harness是否会收敛到一个薄薄的、标准化的层类似几乎不变的操作系统内核还是会永远处于变动中每代模型都要从头重建三大流派没有达成共识。OpenAI的环境优先方法倾向于收敛代码库结构、CI管道和AGENT.md文件是稳定的基础设施跨模型升级保持不变。Anthropic的数据倾向于持续变动对Opus 4.5最优的多Agent架构对Opus 4.6已经过重而Opus 4.7的自验证能力正在让简化后的评估器看起来也借日无多。ThoughtWorks的分类学刻意保持中立无论这个领域往哪个方向走都能存活。有一点是明确的2026年及以后构建最可靠AI系统的工程师不是写出最好代码的那些人而是设计出最好约束的那些人。然后愿意在这些约束不再值回票价的瞬间把它们扔掉。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Harness Engineering全面解析：OpenAI、Anthropic、ThoughtWorks的三种答案
三大流派三种架构——以及Opus 4.7刚刚证明的一切2026年2月OpenAI发了一篇博客悄悄重新定义了软件工程师的日常工作。标题只有两个词“Harness Engineering”。文章描述了一个小团队如何在没有手写一行代码的情况下上线了一百万行生产代码。他们做的事情不是写代码而是设计AI Agent工作的环境——约束条件、反馈循环、文档结构、依赖规则。Agent负责写代码人负责设计让Agent可靠运转的系统。几周之内Anthropic发表了三篇关于同一概念的工程论文有效harness、harness设计、managed agents。ThoughtWorks搭建了一套正式框架Red Hat写出了落地指南Hugging Face的Philipp Schmid称其为2026年最重要的工程学科。一个新的工程学科在90天内横空出世。而且它的演进速度快得超乎所有人的预期。就在昨天Anthropic发布了Opus 4.7——不到一年内的第三代模型。每一代不只是模型更强而是harness变得更简单。三月份还是承重墙的组件四月份就成了多余的摆设。这门学科诞生才90天就已经在改写自己的规则。“参考链接https://ai.gopubby.com/harness-engineering-what-every-ai-engineer-needs-to-know-in-2026-0ab649e5686a数字能说明问题有多紧迫。LangChain用同一个模型在Terminal Bench 2.0上跑了两次一次用老harness一次用新harness。模型没变harness换了得分从52.8%跳到了66.5%。Vercel走了另一条路直接删掉了80%的Agent工具结果反而性能更好。工具越少约束越紧输出越强。如果说2025年是AI Agent证明自己能写代码的一年2026年就是我们发现Agent从来不是难点的一年。难的是harness。但真正让这个时刻有意思的是三大流派对harness该做什么产生了根本性的分歧。他们认同问题所在但对架构的看法截然不同。而这个选择绝不是学术讨论——它直接决定了成本、所需人手以及Agent产出的是可用的软件还是昂贵的幻觉。Harness到底是什么ThoughtWorks的Sunit Parekh在《Beyond Vibe Coding》里给出了最简洁的定义“Agent 模型 HarnessHarness就是除了模型本身之外的一切。是让Agent保持方向的约束是捕捉错误的反馈循环是告诉Agent当前位置和已完成工作的文档以及它被允许使用的工具。把harness拆掉剩下的就是一个在代码库里瞎猜的裸模型。配上合适的harness就是一个能上线生产代码的系统。OpenAI团队在给它命名时用了一个更古老的比喻。Harness是马具缰绳、马鞍、嚼口把一匹强壮但难以预测的动物引向有用的方向。不是让马更聪明而是设计出让它的力量变得可用的装备。Philipp Schmid用了一个更技术性的类比值得好好琢磨把它想象成一台电脑——模型是CPU原始算力上下文窗口是内存有限的、易失的工作记忆harness是操作系统管理CPU看到什么、什么时候看到而Agent则是运行在这一切之上的应用程序。如果有金融或风控背景还有一个更直接的理解方式harness就是控制框架。就是那套确保自主系统在可接受边界内运行的策略、检查点和审计链。合规团队做这件事已经做了几十年只是AI世界给它起了个新名字。那些零件长什么样大多数文章把harness定义得很抽象然后就结束了这远远不够。如果真要自己动手搭一个就得看清楚每个零件长什么样。以下是各大主流实现中反复出现的关键文件。AGENT.md / CLAUDE.md 文件通用模式名字不同这是分散在整个代码库里的markdown文件Agent每次开始会话都会读一遍。OpenAI的Codex叫它AGENT.mdAnthropic的Claude Code叫它CLAUDE.mdCursor用的是.cursorrules。名字不同原理一样里面写的是项目上下文、编码规范、架构决策以及我们这里怎么做事的指导方针。OpenAI的Sora Android团队在整个代码库里都维护着这些文件。Agent读它们就像新加入团队的工程师在冲刺中途读入职文档一样——每个主要模块一个文件随着项目演进不断更新。# AGENT.md - 认证模块## 架构- OAuth2流程配合PKCE令牌存储在加密的SharedPreferences中- 禁止以明文存储令牌禁止在日志中记录令牌值## 规范- 所有认证错误统一通过AuthErrorHandler处理- 重试逻辑指数退避最多3次## 当前状态- v1到v2令牌格式的迁移正在进行中见issue #247JSON功能列表Anthropic模式当一个Agent需要在多个会话里构建完整应用时每次新会话都从空白上下文开始。Agent怎么知道哪些已经做完、该做什么Anthropic的答案是一个JSON文件同时充当项目规格说明和进度追踪器。每个条目定义一个功能、验证步骤和通过/失败状态。在他们的claude.ai克隆演示中这个列表有200多个独立功能全部从failing开始。Agent每次会话开始时读取这个文件挑出优先级最高的未完成功能实现它根据测试步骤验证标记为passing然后提交。这东西既是测试套件又是项目看板人和Agent都能读。{ category: authentication,feature: 通过邮件重置密码,verification: [ 在登录页点击忘记密码, 输入已注册的邮箱地址, 验证30秒内收到重置邮件, 点击重置链接输入新密码, 确认用新密码登录成功 ],status: failing}为什么用JSON而不是markdownAnthropic发现模型比起Markdown文件不太会不恰当地修改或覆盖JSON文件。细节但在Agent自主运行几个小时的时候很关键。会话初始化流程Anthropic模式每次编码会话都遵循同样的7步启动序列确认工作目录、读取git日志和进度文件、查阅功能列表找出优先级最高的未完成功能、启动开发服务器、运行基本端到端验证、实现单个功能、然后提交并附上描述性信息和进度更新。这不是可选项。没有这套流程每次新会话都从头开始Agent要浪费前20分钟弄清楚已经做了什么。结构化任务模板Red Hat模式在任何编码开始之前harness使用语言服务器和代码分析工具分析真实代码库生成有据可查的影响图。然后生成包含真实文件路径、真实符号名、已有模式参考和具体验收标准的任务模板。不靠猜不产生幻觉。冲刺契约Anthropic模式在生成器Agent开始写代码之前它会和评估器Agent协商。生成器提出要构建什么以及如何验证成功评估器审查提案的完整性。双方达成一致后才开始实现。这是优秀工程团队早就在做的设计评审的轻量级版本只不过两个参与者都是AI。把这些文件放在一起看一个规律就出现了每一个都是为了回答同一个问题——在写第一行代码之前Agent需要知道什么答案是很多。它在代码库的哪个位置、已经完成了什么、好长什么样、什么不能碰、怎么验证自己的工作。这不是智能这是上下文。而上下文事实证明才是harness工程真正在生产的东西。三大流派Harness Engineering这个词不是从委员会或者大会主题演讲里冒出来的。三个团队各自独立撞上了同一堵墙然后每个人搭了一把不同的梯子爬过去。OpenAI「一百万行没人写的代码」OpenAI的Codex团队面对的问题荒诞得几乎难以置信——他们在构建一个生产应用而Agent写了所有的代码。不是部分是全部。一百万行人类一行没写。在这种规模下传统的逐行代码审查完全行不通。一百万行没法审。能做的是把环境设计得足够完善让Agent从一开始就产出可审查的输出。他们最核心的教训是用血和汗换来的给Codex一张地图而不是一本1000页的使用手册。他们建立了严格的依赖流类型 → 配置 → 仓库 → 服务 → 运行时 → UI并用结构测试强制执行。他们在代码库各处嵌入AGENT.md文件作为分布式文档把Agent直接接入CI/CD管道让每次变更都自动被测试。核心理念是设计好环境然后放Agent进去。人的角色是架构师不是程序员。证明这套方法有效的是Sora Android的构建。四名工程师28天消耗约50亿token应用上线后登顶Play Store崩溃率99.9%免疫。Codex每周处理70%的内部PR工程师把时间花在高层架构、规划和验证上其余的交给Agent。Anthropic「Agent一直在夸自己烂掉的作品」Anthropic的问题更微妙某种程度上更难解决。他们在构建需要在数小时自主工作中产出完整应用的长运行Agent模型能力是够的问题出在质量控制上。当他们让Agent评估自己的输出时它会自信地夸赞那些工作即使在人类观察者看来质量明显很差。自我评估行不通Agent既是学生又是老师给自己打了满分。解决方案的灵感来自生成对抗网络GAN把做事的和评判的分开。由此诞生了三Agent架构**规划器Planner**把简短的提示扩展成全面的产品规格**生成器Generator**逐冲刺实现功能**评估器Evaluator**用Playwright浏览器自动化像真实用户一样与运行中的应用交互按照明确标准给每个冲刺打分。关键洞察是把一个独立的评估器调教得足够挑剔远比让生成器对自己的工作保持批判性思维更可行。架构继续演进从两个Agent初始化器加编码器到三个Agent规划器、生成器、评估器再到完全解耦的managed agents系统——大脑、执行环境和会话日志都是独立的、可替换的组件。这种解耦让P50首token时间缩短了60%P95缩短超过90%。核心理念把执行者和评判者分开让评判者很难被打动。ThoughtWorks「在50个客户团队里看到了同样的失败模式」ThoughtWorks从完全不同的起点走到了harness工程。他们不是在构建产品而是在观察各行各业几十个工程团队尝试采用AI Agent然后反复看到同样的失败模式。资深工程师Birgitta Böckeler在2026年4月发布了三者中最完整的框架。OpenAI构建了一个系统Anthropic构建了一种架构ThoughtWorks构建了一套分类学。他们的框架沿两个维度对harness控制进行分类。第一个维度前馈在Agent行动之前引导行为的指导vs反馈观察结果并启用自我纠正的传感器。两者缺一不可——只有反馈意味着错误反复发生只有前馈意味着永远不知道指导是否真的有效。第二个维度计算型确定性检查如linter、类型检查器、测试套件毫秒级运行vs推断型另一个LLM的语义分析更慢更贵但能捕捉代码分析发现不了的问题。核心理念分类、系统化给团队一套共同词汇来描述他们在构建什么。三种架构的横向对比OpenAI/Codex环境优先的HarnessCodex harness在能够大量前期投入设计环境时效果最好。下游的自主性收益巨大但前期成本是真实存在的。工作原理harness就是代码库本身。AGENT.md提供上下文结构测试机械地执行架构规则依赖流防止Agent以错误顺序构建东西CI/CD管道自动验证每次变更。Agent以高度自主的方式运作开PR、响应审查反馈、运行测试、迭代失败、达标后合并。人类不审查每一行而是审查让每一行可审查的约束。最擅长大型代码库。几十万行的项目环境优先的方法能扩展因为约束嵌在仓库结构里。加新模块加AGENT.mdAgent就能进去工作不需要重新训练或配置。OpenAI估计他们以原本手写代码约1/10的时间完成了交付。薄弱之处这种方法假设能在Agent开始工作之前全面定义环境。对于架构还没想清楚的全新项目这很难。它也严重依赖结构测试和CI管道能检查代码是否正确但检查不了是否写得好。一个函数可以通过所有测试同时仍然是个糟糕的设计。Anthropic多Agent HarnessAnthropic的方法每次运行成本更高但能捕捉到环境优先方法漏掉的问题。权衡在质量vs速度之间——对于输出质量比输出速度更重要的应用值得认真考虑。工作原理三个有明确角色的专职Agent。规划器把1~4句话的用户提示扩展成全面的产品规格聚焦于可交付成果和高层设计刻意避免可能级联出错误的细粒度实现细节。生成器使用标准技术栈React、Vite、FastAPI、SQLite/PostgreSQL逐功能实现交付前先自评。评估器用Playwright浏览器自动化像真实用户一样与运行中的应用交互按照明确的评分标准测试UI功能、API端点和数据库状态。每个冲刺开始前生成器和评估器会协商一份冲刺契约定义要构建什么以及如何衡量成功。这是一次轻量级设计评审只不过两个参与者都是AI Agent。最擅长需要高质量和正确性的应用。评估器能捕捉测试单独发现不了的问题能渲染但不可用的UI元素、技术上可用但工作流不直观的功能、返回正确数据但格式错误的API端点。Anthropic的测试显示单独Agent9美元20分钟产出了功能残缺的应用完整harness200美元6小时产出了界面精致、功能正确的可用软件。薄弱之处成本和时间。三Agent系统明显比单Agent贵评估器需要大量的提示调优。不经调校的话它能识别真实问题然后又找理由接受它们。让它真正挑剔花了Anthropic好几轮开发迭代。好消息是随着模型改进harness变得更简单。Anthropic从Opus 4.5升级到Opus 4.6时整个冲刺分解步骤被移除改为单次评估成本从Opus 4.5版本明显下降。Opus 4.72026年4月16日发布让这一趋势进一步加速模型现在会在上报结果之前自行验证输出产出更干净的代码工具错误只有以前的三分之一。每一代模型都在啃掉评估器的工作职责。ThoughtWorks分类学HarnessThoughtWorks没有构建一个可以直接部署的系统而是构建了一种思考harness的方式帮助用户自己设计。如果不打算采用Codex或Claude的特定工具这是最有用的方法但需要最多的自主工作来落地。工作原理每个harness控制沿两个维度分类。第一它是指导前馈在Agent行动前应用还是传感器反馈在行动后观察结果第二它是计算型确定性类似linter毫秒级还是推断型使用LLM秒级但能捕捉代码分析发现不了的问题这给出了一个2×2的控制类型矩阵计算型指导前馈类型系统、linter、架构决策记录计算型传感器反馈测试套件、覆盖率分析、变异测试、结构复杂度检查推断型指导前馈规格文档、设计提示、约束描述推断型传感器反馈基于LLM的代码审查、语义质量评估、行为验证器最擅长拥有成熟代码库的现有团队。如果已经有linter、测试套件和CI管道ThoughtWorks框架能帮你意识到harness已经搭了一半了。分类学告诉你缺什么、在哪里投入。他们还提出了一个很有价值的概念“可harnessability”——强类型语言、清晰的模块边界和结构良好的框架天然让Agent工作更成功。选新项目技术栈的时候这一点值得考虑。薄弱之处它是描述性的不是规定性的。框架告诉你存在哪些类型的控制但不告诉你用哪些具体工具或如何把它们连接起来。想要一站式解决方案的团队会失望——这是蓝图不是建筑。他们独立发现的五个共同原则剥掉实现的差异一个出乎意料的事情浮现出来三个从不同起点出发、从未协调过的团队得出了同样的五条原则。这种独立收敛通常意味着发现了真实存在的东西。① 上下文比指令更重要OpenAI总结出给一张地图而不是一本手册。Anthropic构建了JSON功能列表和进度文件让Agent随时知道自己在哪里。Red Hat的整个工作流建立在分析真实代码库之后才生成任务的基础上。ThoughtWorks称之为前馈。标签不同发现一样把Agent锚定在真实状态真实文件路径、真实代码模式、真实进度产出一致优于用抽象术语告诉它该做什么。在真实代码库中接地气的Agent写出来的代码是合适的基于模糊描述工作的Agent会幻觉出不存在的文件路径和API。② 规划和执行必须分开OpenAI把环境设计人类和代码生成Agent分开。Anthropic在Generator碰任何代码之前先运行专属的Planner Agent。ThoughtWorks规定在规划和实现之间有人工审查检查点。Red Hat分为阶段1影响图和阶段2实现中间有硬性关卡。每个流派都独立发现让Agent在同一个过程中既规划又执行会产出不可靠的结果。规划步骤不必由人类或独立Agent完成但必须是独立的步骤其输出在实现开始之前经过审查。③ 反馈循环不可或缺OpenAI把Agent接入CI/CD管道和可观测性系统。Anthropic构建了专用的评估器Agent用浏览器测试运行中的应用。ThoughtWorks把这正式化为传感器并警告说仅有前馈的方法有指导但无验证永远无法确认指导是否真的有效。分歧不在于是否需要反馈而在于由谁提供。OpenAI用自动化测试和CIAnthropic用另一个LLMThoughtWorks说两者都用、分层叠加先计算型反馈快、便宜、确定性再推断型反馈慢、贵、语义级。三者都认同没有反馈机制的harness不过是加了多余步骤的提示词。④ 一次只做一件事OpenAI把目标拆成更小的构建块深度优先推进。Anthropic强制每次冲刺只实现一个功能实现后即提交。ThoughtWorks描述了分阶段生命周期预集成、后集成、持续监控。Agent试图同时做太多事情就会耗尽上下文、失去连贯性或悄悄丢掉需求。强制增量主义——Agent完成一个工作单元后再开始下一个——在每个成功的harness实现中都是普遍原则。Anthropic使用的会话初始化流程读取进度、选一个功能、实现、提交、循环是最清晰的表达但每个流派都以各自的方式强制执行。⑤ 代码库就是文档OpenAI在仓库中嵌入AGENT.md文件。Anthropic将功能列表、进度文件和git历史作为Agent的连续性机制。ThoughtWorks衡量可harnessability即代码库本身对Agent的可读程度。Red Hat说把所有规范都纳入版本控制。没有人为Agent维护独立的知识库。仓库就是单一事实来源。如果一个规范、约束或架构决策不在代码库里Agent就不知道它的存在。这有一个实际影响在代码组织、清晰模块边界和嵌入式文档上投入的团队免费获得了更好的Agent性能。把它做对要花多少钱Harness工程不免费。每种方法都涉及前期投入、每次运行成本和持续维护之间的权衡。Anthropic的A/B测试数据Anthropic发布了迄今为止最清晰的成本对比用同一个应用提示分别跑单Agent和完整多Agent harness。单Agent无harness9美元20分钟。输出有可用的UI但核心功能残缺实体对用户输入没有响应看起来像应用但用起来不像。完整harnessOpus 4.5200美元6小时。输出有真正可玩的游戏界面精致视觉风格一致物理效果正确。22倍的成本差异换来的是功能产品vs只在截图里好看的演示。这到底算贵还是便宜完全取决于一次残缺发布对团队意味着什么代价。模型改进带来的红利从Opus 4.5升级到Opus 4.6后Anthropic大幅简化了harness移除了冲刺分解改为单次评估取消了上下文重置。结果一个完整的数字音频工作站应用124.70美元3小时50分钟。比Opus 4.5版本成本降低38%时间缩短36%完全由模型改进驱动。Opus 4.7延续了这条趋势线。CursorBench得分从58%跳到70%Rakuten-SWE-Bench上解决的生产任务是原来的3倍在更少token的情况下比Opus 4.6提升了14%。三代模型三轮harness简化这是趋势不是偶然。但这并不意味着harness的需求消失了。Opus 4.6的评估器仍然发现了明显的缺口缺失的交互时间线控件、不存在的乐器UI面板、不完整的音频录制功能。没有评估器这些功能就会以残缺或损坏的状态上线。Harness随每代模型收缩但还没有消失。隐性成本维护没人大声说出口的数字是维护成本。Harness不是一次性构建而是持续的工程承诺。Manus六个月内重构了五次harnessLangChain一年内重构了三次。这不是糟糕工程的标志而是在快速改进的模型之上构建的自然结果。每次模型变好harness的某个部分就成了多余的开销而找出是哪个部分需要主动测试。Philipp Schmid的建议“build to delete”为删除而构建。把每个harness组件设计成可移除的定期关掉每个组件测试输出质量是否变化如果不变就删掉它。带着无用的harness组件每次运行都要多花token增加维护负担但什么好处都得不到。最大的悖论为删除而构建有一个令人不舒服的真相藏在Anthropic的数据里三个流派都没大声说出来。升级到Opus 4.6时他们不只是得到了更好的结果还得到了更简单的结果。冲刺分解——对Opus 4.5在长时间编码会话中保持连贯性至关重要的功能——变得不必要了。模型改进了规划和长上下文处理能力把这个组件变成了多余的东西。三月份的承重墙四月份就成了死重。然后Opus 4.7在4月16日上线把这个模式推得更远。模型现在在上报结果之前会自行验证输出——正是那个曾经证明需要独立评估器Agent的能力缺口。它产出更干净的代码减少了包装函数和不必要的脚手架工具错误只有以前的三分之一。轨迹很清晰4.5需要完整的冲刺分解和逐冲刺评估4.6取消了冲刺分解改为单次评估4.7正在开始将评估本身内化。Anthropic称之为“harness衰减”。harness里的每个组件都编码了一个关于模型不能做什么的假设。随着模型改进这些假设会过期而那个曾经在补偿限制的组件就变成了开销。这方面的证据无处不在。Manus六个月内重构了五次harnessLangChain一年内重构了三次Vercel删掉80%的工具反而性能更好。每个案例都是同一个故事上个月有用的东西这个月成了负担。Philipp Schmid把这和Rich Sutton的机器学习苦涩教训联系起来随计算规模扩展的简单方法始终优于复杂的手工设计方案。应用到harness上含义很清晰不要构建复杂的、紧耦合的控制系统而要构建模块化的、可以逐块删除的系统。这给工程团队制造了一个真实的悖论。现在需要harness才能从AI Agent那里得到可靠的输出但今天构建的harness明天就需要部分拆除。而在模型已经超越之后还死抱harness架构的团队会在每次运行中缴税多花token、多花延迟、多花维护零额外质量。实际建议很简单即使感觉反直觉给每个harness组件设计一个开关定期关掉它测量输出质量质量不变就删掉。更深的问题还没有人给出答案随着模型持续改进harness是否会收敛到一个薄薄的、标准化的层类似几乎不变的操作系统内核还是会永远处于变动中每代模型都要从头重建三大流派没有达成共识。OpenAI的环境优先方法倾向于收敛代码库结构、CI管道和AGENT.md文件是稳定的基础设施跨模型升级保持不变。Anthropic的数据倾向于持续变动对Opus 4.5最优的多Agent架构对Opus 4.6已经过重而Opus 4.7的自验证能力正在让简化后的评估器看起来也借日无多。ThoughtWorks的分类学刻意保持中立无论这个领域往哪个方向走都能存活。有一点是明确的2026年及以后构建最可靠AI系统的工程师不是写出最好代码的那些人而是设计出最好约束的那些人。然后愿意在这些约束不再值回票价的瞬间把它们扔掉。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
