Claude-Code团队最新总结，面向长时间运行应用开发的.md40.6 KBit/ai/Claude-Code团队最新总结，面向长时间运行应用开发的.md
 在人工智能技术飞速迭代的今天，大语言模型在代码编写、简单功能实现等场景中已经展现出了惊人的能力。打开任意一款AI编程工具，输入一句简单的需求提示，就能快速生成基础的代码片段，甚至能完成小型项目的搭建工作。但当任务从简单脚本、单一功能，转向复杂的全栈应用、长时间运行的自主开发项目时，模型往往会出现各种问题：需求理解偏差、代码逻辑断裂、功能开发偏航、自我评估失效，最终产出的成果看似完整，实则漏洞百出，无法真正投入使用。 Anthropic团队在2026年3月发布的关于Harness设计的研究成果，正是为了解决这一核心痛点。该团队通过大量实验，结合生成对抗网络（GAN）的设计思路，打造了一套多代理协作的Harness架构，通过生成与评估分离、上下文优化、任务拆解与闭环迭代等一系列创新设计，让Claude模型能够自主完成数小时的复杂应用开发，彻底打破了AI编程的能力边界，让AI从“能写代码”升级为“能做好开发”。 这项研究不仅是一次技术上的突破，更重新定义了AI自主编程的实现路径，为整个Agentic Coding（智能体编程）领域提供了可复用、可迭代的工程化思路。对于互联网开发者、AI工程从业者、技术管理者，以及关注人工智能落地的相关人士而言，理解Harness架构的设计逻辑、进化过程和核心价值，不仅能看清当前大模型编程的瓶颈所在，更能预判未来AI自主开发的发展方向，为自身的技术实践和项目落地提供参考。 本文将结合Anthropic团队的实验细节、技术方案和实际案例，全面拆解Harness架构的设计思路、进化历程和应用效果，补充更多行业延伸思考和实操性解读，让大家深入理解这套架构如何解决AI长时开发的痛点，以及它为AI编程领域带来的深远影响。 ## 一、朴素AI编程失效：长时开发的两大核心死穴，你一定遇到过 在Harness架构出现之前，业内已经尝试过多种让AI自主完成开发任务的方式，比如将需求拆解为简单的任务列表，让模型逐个执行；或是通过上下文压缩技术，精简早期对话内容，维持任务的连贯性；还有一些开发者会借助脚本或钩子函数，让模型进入持续迭代循环。但这些朴素的实现方式，在面对长时间、高复杂度的应用开发时，无一例外都会失效。 Anthropic团队通过长达数月的实验，针对前端设计和全栈开发两大场景，反复测试不同模型（Claude Sonnet 4.5、Claude Opus 4.5/4.6）的表现，最终发现，所有大模型在长时自主开发中，核心问题都集中在两个方面，这也是朴素AI编程无法突破的两大死穴，相信很多尝试过AI自主开发的开发者，都有过类似的经历。 ## （一）死穴一：上下文焦虑与连贯性崩塌，模型越做越偏 大模型的上下文窗口是有限的，这是当前所有大语言模型的固有特性。在长时间的开发任务中，对话历史、代码片段、需求文档、调试记录等信息会不断填充上下文空间，随着信息量的增加，模型对整体任务的把控能力会逐步下降，出现逻辑断裂、需求遗忘、功能重复开发等问题。 更严重的是，部分模型会出现明显的“上下文焦虑”现象。Anthropic团队在测试Claude Sonnet 4.5时发现，当模型感知到上下文即将达到上限时，会产生一种“紧迫感”，提前草率收尾，放弃未完成的功能开发，甚至会忽略核心需求，只完成表面功能，导致项目烂尾。比如在一次复古游戏制作器的开发中，Sonnet 4.5在上下文即将满额时，直接跳过了“游戏实体交互”这一核心功能，只完成了界面布局，导致最终的应用无法正常游玩。 为了解决这个问题，早期的方案采用了“上下文压缩”技术，将早期的对话内容、代码片段进行总结提炼，删除冗余信息，让模型在精简的历史信息中继续工作。但这种方式只是缓解了问题，并没有彻底解决。压缩后的信息会丢失大量细节，比如代码中的注释、需求中的特殊要求，模型依然无法获得一个全新的执行起点，上下文焦虑依旧存在，连贯性崩塌的问题也会反复出现。 而Harness架构中提出的“上下文重置”方案，成为了突破这一瓶颈的关键。所谓上下文重置，就是彻底清空当前的上下文窗口，启动一个全新的智能体，再通过结构化工件（比如任务清单、状态报告、代码文档等），将前一个智能体的工作状态、已完成成果和下一步计划，完整传递给新的智能体。这种方式能让模型以全新的状态接手任务，彻底摆脱上下文焦虑的影响，重新聚焦核心需求。 但上下文重置也带来了新的挑战：编排复杂度增加，需要设计一套完善的状态传递机制；token成本上升，因为每次重置后，需要重新加载必要的信息；开发延迟增加，因为状态传递和智能体重启需要一定时间。即便如此，这种方案依然是解决上下文焦虑最有效的方式，也是Harness架构的核心设计之一。 ## （二）死穴二：自我评估失效，模型“自卖自夸”，BUG视而不见 如果说上下文问题是“能力问题”，那么自我评估失效就是“态度问题”，这也是AI在主观设计与客观开发中共同的痛点。当让模型自己评估生成的代码或设计时，几乎都会出现过度乐观的倾向，即便代码存在明显BUG、设计视觉平庸，模型也会给出高分评价，甚至会刻意回避自己的缺陷。 在前端设计这类主观场景中，没有统一的对错标准，模型的自我评估更是毫无参考价值。Anthropic团队在测试中发现，无干预的Claude模型生成的前端界面，往往都是“模板化产物”：紫色渐变背景、白色卡片、统一的按钮样式，技术上可用，但视觉上毫无新意，缺乏原创性。但模型在自我评估时，却会声称“设计美观、原创性强、符合用户需求”，完全忽略了自己的平庸。 即便是在有明确测试标准的后端开发中，模型也常常忽略逻辑漏洞、功能缺失等问题，无法对自身成果做出客观判断。比如在一次API接口开发中，模型生成的代码存在参数校验缺失的问题，导致接口可以接收非法参数，引发数据库异常，但模型自我评估时，却认为“接口功能完整、逻辑严谨、无BUG”。这种自我评估的偏差，直接导致AI开发的应用只能“看上去很美”，实际使用时问题频发，无法真正投入使用。 Anthropic团队将这种现象总结为“智能体自我宽容”，作为生成者，模型天然会对自己的产出物产生“偏爱”，无法以第三方的客观视角进行评判。而这种偏爱，在长时开发中会被无限放大：随着开发任务的推进，模型会不断强化自己的错误逻辑，即便出现偏差，也会自我说服“这不算大问题”，最终导致整个项目偏离需求，无法使用。 正是基于这两大核心问题，Anthropic团队开启了Harness架构的设计之路。他们从生成对抗网络（GAN）中获得灵感，将“生成”与“评估”分离，让不同的智能体分别负责执行任务和评判成果，同时优化上下文管理方式，最终打造出了能支撑长时自主开发的多代理系统，让AI开发从“凑合用”走向了“高质量落地”。 ## 二、从前端到全栈：Harness架构的进化之路，每一步都解决实际痛点 Harness架构的设计并非一蹴而就，而是一个逐步迭代、不断优化的过程。Anthropic团队并没有一开始就直接设计全栈开发的架构，而是先从前端设计这一主观场景切入，验证“生成与评估分离”的可行性，解决自我评估失效的问题，再将这套思路迁移到全栈开发中，结合上下文管理优化，逐步完善出Planner、Generator、Evaluator三代理架构。这一进化过程，既解决了单一场景的问题，也为复杂全栈开发奠定了坚实的基础。 ## （一）前端设计破局：把主观审美变成可量化评分，告别平庸设计 前端设计是AI编程中最容易暴露自我评估问题的场景，无干预的Claude模型往往只能生成安全、平庸的界面，缺乏视觉美感与原创性，陷入模板化、套路化的怪圈。Anthropic团队的核心突破，就是将模糊的审美判断转化为可量化、可评分的标准，同时建立生成与评估的反馈闭环，让模型在迭代中不断优化设计，摆脱平庸。 团队首先制定了四大核心评分标准，分别是设计质量、原创性、工艺和功能性，每个标准都有明确的评判细则，彻底解决了“审美无法量化”的问题： 第一，设计质量：核心评判界面的整体统一性。一个优秀的前端设计，不应是零散部件的堆积，而是配色、字体、布局、图像与细节的有机结合，能够共同营造出鲜明的视觉氛围和产品身份感。比如为艺术博物馆设计的网站，就需要体现出简约、高雅的氛围，配色不宜过于鲜艳，布局要突出展品本身；而为游戏制作器设计的界面，则需要活泼、有科技感，布局要贴合操作习惯。 第二，原创性：核心惩罚模板化、套路化设计，鼓励自定义创意。AI生成的设计最常见的问题，就是重复使用固定模板，比如紫色渐变背景、白色卡片、圆角按钮等，这些都是典型的“AI痕迹”。团队明确规定，未修改的现成组件、常见的AI套路设计，都会在原创性评分中扣分；而人类设计师能从中辨认出的刻意创意选择，会获得高分。 第三，工艺：核心考察技术执行的扎实程度，相当于“基本功检查”。这一标准不涉及创造力，只关注字阶层级是否清晰、间距是否一致、色彩是否和谐、对比度是否达标等基础技术问题。大多数合理的实现通常都能通过这一标准的考核；如果在这里失败，就说明模型的基础技术能力存在短板，需要重点优化。 第四，功能性：核心关注界面的可用性，与审美无关。评判标准是，用户能否快速看懂界面的功能、找到主要操作，并在不靠猜测的情况下完成核心任务。比如游戏制作器的界面，用户能否快速找到“创建关卡”“编辑精灵”等核心功能，能否顺畅完成操作，就是功能性的核心评判点。 在权重设置上，团队刻意提高了设计质量和原创性的权重（各占35%），而工艺和功能性各占15%。这是因为模型在工艺和功能性上本就表现优异，而平庸的设计、缺乏原创性，正是AI前端设计的最大短板。通过提高核心短板的权重，能推动模型更愿意承担审美风险，摆脱模板化的束缚。 在实现层面，团队基于Claude Agent SDK搭建了完整的循环系统，具体流程如下：首先，Generator智能体根据用户的简单提示，生成HTML/CSS/JS前端代码，完成初始设计；然后，Evaluator智能体通过Playwright MCP（一种自动化测试工具），与真实运行的页面进行交互，它会自行浏览页面、点击按钮、切换功能，甚至会截图保存关键界面，仔细观察设计的细节和功能的可用性；之后，Evaluator会根据四大评分标准，给出详细的评分和修改意见，比如“配色过于单调，建议增加辅助色”“按钮间距不一致，工艺不达标”“设计缺乏原创性，存在明显AI模板痕迹”等；最后，这些反馈会回流给Generator，作为下一轮迭代的输入，Generator根据反馈优化设计，进入下一个循环。 一轮完整的前端开发，通常会进行5到15次迭代，耗时最长可达4小时。这是因为每一轮迭代都需要真实的墙钟时间，Evaluator需要与页面交互、仔细评估，Generator需要根据反馈重新生成代码，这些过程都无法快速跳过。但正是这种慢节奏的迭代，让设计质量不断提升。 这种模式带来了意想不到的效果，模型不仅能逐步优化设计，甚至会出现“创意跃迁”。Anthropic团队在一次实验中，要求模型为一家荷兰艺术博物馆生成网站。前九轮迭代中，模型逐步优化界面，做出了一个干净、深色主题的落地页，视觉完成度不错，也大致符合预期。但在第十轮迭代中，模型完全推翻了原有的方案，将网站重构成一种空间化体验：通过CSS透视效果，构建一个带棋盘格地面的3D房间，画作以自由布局挂在墙上，房间之间通过门洞导航，而不是传统的滚动或点击切页。这种创意跃迁，是单次生成永远无法实现的成果，也证明了将主观质量量化，配合生成与评估的闭环，能让AI突破自身的平庸陷阱，产出高质量的设计成果。 此外，团队还发现，评分标准的措辞，也会以意想不到的方式影响Generator的输出。比如在标准中加入“最好的设计应该达到museum quality（博物馆级）”之类的表述，结果模型的输出逐渐收敛到一种简约、高雅的视觉气质，说明标准里的语言本身，就会直接塑造结果的风格。这也为后续的prompt设计提供了重要参考：通过精准的语言引导，能进一步优化AI的输出质量。 ## （二）全栈开发升级：三代理架构打造长时开发系统，解决偏航与BUG问题 在前端设计场景验证了“生成与评估分离”的可行性后，Anthropic团队将GAN启发的生成评估模式，迁移到了更复杂的全栈开发中。结合此前在长时开发中积累的上下文管理经验，团队打造了全新的三代理Harness架构，彻底解决了长时自主开发中的偏航、BUG频发、自我评估失效等问题。 这套三代理架构，分别由Planner（规划者）、Generator（生成者）、Evaluator（评估者）三个智能体组成，每个智能体都有明确的职责，三者协同工作，形成完整的开发闭环。同时，团队根据模型版本的升级，不断优化架构细节，让架构更贴合模型能力，提升开发效率。 ## 1\. Planner：把1句话需求，变成完整的产品规格 早期的AI自主开发，有一个很大的痛点：需要用户提供详细的需求规格，否则模型无法准确理解需求，开发出来的产品会偏离预期。但对于大多数用户而言，很难写出专业、详细的产品规格，往往只能给出1到4句简单的需求提示，比如“创建一个2D复古游戏制作器”“构建一个浏览器端的数字音频工作站”。 Planner智能体的核心作用，就是解决这个痛点。它仅需接收用户1到4句的简单提示，就能自动扩展为一份完整的产品规格，包括产品概览、核心功能、目标用户、技术栈选择、AI功能融入等内容。同时，Planner会刻意保持高层抽象，不过度细化技术细节，避免因早期技术判断失误，导致错误沿整个开发链路传播。 比如用户给出“创建一个2D复古游戏制作器”的提示，Planner会将其扩展为一份包含16个功能、分布在10个迭代中的完整规格，其中不仅包括关卡编辑器、精灵编辑器、实体行为系统、测试模式等核心功能，还会主动加入精灵动画系统、行为模板、音效和音乐、AI辅助的精灵生成器与关卡设计器，以及可分享链接的游戏导出能力等拓展功能。 此外，Planner还会主动寻找将AI功能织入产品规格的机会。比如在游戏制作器的规格中，Planner会明确要求加入Claude集成，让用户可以通过自然语言prompt，直接生成游戏的精灵、关卡、行为逻辑等，大幅加快创作流程。这种AI功能的融入，不仅提升了产品的实用性，也充分发挥了大模型的优势。 值得注意的是，Planner在扩展需求时，会对范围保持野心，同时兼顾可行性。它不会盲目增加功能，而是会结合技术栈的特点和模型的能力，制定合理的功能规划，确保生成的产品规格既能满足用户需求，又能被Generator顺利实现。 ## 2\. Generator：以迭代为单位，扎实完成全栈开发 Generator智能体的核心职责，是根据Planner制定的产品规格，完成具体的代码开发工作。团队延续了此前“任务拆分”的思路，要求Generator以“迭代”为单位工作，每次从规格说明里取一个功能块实现，避免因任务过于庞大，导致模型出现逻辑断裂、偏航等问题。 在技术栈选择上，Generator默认使用React（前端）、Vite（构建工具）、FastAPI（后端）和SQLite（数据库，后期根据需求改为PostgreSQL），这些技术栈轻量、易用，适合AI自主开发，也能满足大多数全栈应用的需求。同时，Generator还支持Git版本管理，会自动提交代码、创建分支，方便后续的调试和迭代。 在每轮迭代结束后，Generator会先进行一次自我评估，检查自己完成的功能是否符合规格要求、代码是否存在明显BUG、功能是否可用。但由于模型的自我宽容特性，这种自我评估仅作为参考，最终的评估权还是交给Evaluator。之后，Generator会将自己的开发成果（代码、文档、运行演示等）提交给Evaluator，等待评估反馈。 Generator的另一个核心优势，是能够根据Evaluator的反馈，快速调整开发方向。如果Evaluator给出的评分较高，且反馈意见主要是细节优化，Generator会继续精修当前方向；如果评分较低，且反馈意见指出核心方向错误，Generator会彻底切换到新的实现方案，避免在错误的道路上继续浪费时间。 ## 3\. Evaluator：AI开发的“质检员”，用真实交互找出所有BUG Evaluator智能体是Harness架构的“核心保障”，相当于AI开发团队中的测试工程师和代码审查员，它的核心职责是客观评估Generator的开发成果，找出BUG、功能缺失、逻辑漏洞等问题，并给出详细的修改反馈，推动Generator优化成果。 与前端设计中的Evaluator类似，全栈开发中的Evaluator也会借助Playwright MCP，像真实用户一样点开运行中的应用，进行全方位的测试。它会测试UI功能（比如按钮点击、页面切换、表单提交等）、API端点（比如接口调用、参数校验、返回结果等）、数据库状态（比如数据插入、查询、删除等），甚至会测试边缘场景（比如非法输入、异常操作等），确保应用的稳定性和可用性。 在评分标准上，Evaluator沿用了前端设计中的四大标准，但将其改造成了适用于全栈开发的版本，分别是产品深度、功能性、视觉设计和代码质量：产品深度关注功能的完整性和实用性，是否符合Planner制定的规格；功能性关注应用的可用性，是否能正常运行、无明显BUG；视觉设计关注前端界面的美观度和一致性；代码质量关注代码的可读性、规范性、安全性，是否存在冗余代码、逻辑漏洞等。 更重要的是，每条标准都有硬阈值，只要其中一条没过，整个迭代就判定失败，Generator必须根据Evaluator的反馈，重新优化开发。这种严格的评估机制，彻底解决了模型自我评估失效的问题，确保了开发成果的质量。 为了保证开发方向正确，Generator与Evaluator会在每轮迭代开始前，协商制定一份“迭代合约”。这份合约会明确本轮迭代的具体实现细节、功能目标、测试标准，以及“完成”的定义，在任何代码真正写下去之前，先约定好本轮工作的终点，避免出现“Generator认为完成了，而Evaluator认为未完成”的分歧。 比如在某一轮迭代中，合约会明确规定“关卡编辑器需支持矩形填充工具，允许用户通过点击并拖拽，用当前选中的tile填满一个矩形区域”，同时会明确测试标准“拖拽起点和终点之间，所有区域都应被tile填满，无遗漏、无重复”。Generator会按照合约的要求进行开发，Evaluator则会按照合约的测试标准进行评估，确保开发工作始终围绕规格推进。 代理之间的通信，是通过文件完成的：一个代理写文件（比如Planner写产品规格文档、Generator写代码文件、Evaluator写评估报告），另一个代理读取文件后，直接在该文件里回复，或写一个新文件再交还回去。这种通信方式简单、高效，能确保信息传递的准确性，同时也能保留完整的开发日志，方便后续追溯和优化。 ## 4\. 实际测试对比：Harness架构vs单代理模式，差距一目了然 为了验证Harness架构的效果，Anthropic团队进行了一次对比实验：使用同一批用户提示，分别跑完整Harness架构和单代理系统（即让一个模型单独完成开发任务），对比两者的运行时长、成本和输出质量。实验使用的模型是Claude Opus 4.5，需求是“创建一个2D复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为系统，以及可试玩的测试模式”。 实验结果显示，单代理模式仅用20分钟就完成了开发，token成本仅为9美元，看似高效、低成本，但输出质量却惨不忍睹。团队打开单代理生成的应用后，发现了大量问题：界面布局浪费了大量空间，固定高度的面板让视口大部分区域空着；工作流非常生硬，想往关卡里放内容时，界面会提示需要先创建精灵和实体，但UI本身并没有引导用户走这条顺序；更关键的是，游戏实际上是坏的，实体能出现在屏幕上，却完全不响应输入，无法移动、无法交互。 进一步翻查代码后发现，实体定义与游戏运行时之间的连线坏掉了，代码中存在明显的逻辑漏洞，但模型在自我评估时，却声称“功能完整、运行正常”。这种“看似能用，实则不能用”的成果，正是单代理模式的致命缺陷。 而完整Harness架构的运行时长为6小时，token成本约为200美元，虽然成本高出了20多倍，但输出质量上的差异几乎是一眼可见的。Planner将用户的一句话提示，扩展成了包含16个功能、10个迭代的完整规格，远超单代理模式尝试实现的范围。Generator按照迭代合约，逐步完成每个功能模块，Evaluator则全程严格把关，找出并督促修复了大量BUG。 Harness架构生成的应用，从一开始就比单代理版本更有打磨感、更顺滑：画布占满了整个视口，面板尺寸更合理，界面拥有一套稳定一致的视觉身份，和规格中定义的设计方向相匹配；精灵编辑器更丰富、功能更完整，工具面板更干净，颜色选择器更好用，缩放控制也更顺手；内置的Claude集成，让用户可以通过prompt直接生成游戏的精灵、关卡等内容，大幅加快了创作流程。 最大的差别出现在游玩模式里：Harness版本生成的应用，用户真的能控制实体移动，能正常游玩自己创建的关卡，核心功能完全可用。虽然物理细节还有一些粗糙之处，比如角色跳上平台后会和平台发生重叠，还有一些边缘场景没有覆盖到（比如地图中存在无法跳过的高墙），但这些都是可以通过后续迭代优化的细节问题，远比单代理版本的“核心功能失效”要好得多。 这次对比实验，清晰地证明了Harness架构的价值：虽然它增加了时间与成本，但换来的是AI开发质量的质的飞跃，让自主开发的应用真正具备使用价值，而不是中看不中用的“花瓶”。 ## 三、架构迭代：随模型进化简化Harness复杂度，兼顾质量与效率 第一版Harness架构的结果令人鼓舞，但它也存在明显的不足：架构臃肿、运行速度慢、成本高。顺理成章的下一步，就是寻找能否在不损失性能的前提下，把Harness架构简化下来。这既是一种常识判断，也符合Anthropic团队一贯的AI工程理念：“先找尽可能简单的方案，只有在必要时才增加复杂度。” 这种理念的核心，是认为Harness中的每一个组件，本质上都编码了一个关于“模型单靠自己做不到什么”的假设。而这些假设，本来就值得反复压力测试，它们可能一开始就是错的，也可能会随着模型的进步，迅速过时。比如上下文重置组件，原本是为了解决Claude Sonnet 4.5的上下文焦虑问题，但当模型升级到Claude Opus 4.6后，上下文焦虑问题大幅减轻，这个组件就可能不再需要。 团队第一次尝试简化时，曾大幅砍掉了架构中的多个组件，还尝试了一些新的创意做法，但最终并没能复现原始版本的表现。与此同时，也越来越难判断Harness设计里的哪些部分是真正“承担关键作用”的，究竟以什么方式承担作用。基于这次经验，团队改成了更系统的方法：每次只移除一个组件，再观察它对最终结果到底造成了什么影响，逐步优化，避免盲目简化导致质量下降。 就在这个迭代过程中，Anthropic发布了Claude Opus 4.6，这进一步促使团队减少Harness架构的复杂度。根据Opus 4.6的发布博客，这款模型“计划更审慎，能把智能体任务持续更久，在更大代码库里更可靠，也拥有更好的代码审查与调试能力，能捕捉自己的错误”，同时在长上下文检索上也有了大幅提升。而这些能力，恰恰正是原始Harness架构想要补足的那部分，这意味着，很多原本需要架构来辅助解决的问题，现在模型自己就能解决了。 ## （一）核心迭代：移除迭代拆分结构，优化Evaluator工作模式 团队首先做出的核心迭代，是完全移除了“迭代拆分”结构。迭代拆分机制原本的作用，是把复杂的开发任务拆成若干个小模块，帮助模型保持连贯性，避免因任务过于庞大而出现偏航。但考虑到Opus 4.6的进步，团队有充分理由相信，模型已经能天然处理这项工作，不再需要这种程度的强制分解。 但团队保留了Planner和Evaluator两个核心组件，因为它们仍然能显著提供价值。没有Planner时，Generator会明显低估开发范围：面对用户的原始提示，它会不先制定规格就直接开做，最终做出来的应用，会比Planner规划后的版本功能更少、逻辑更混乱，无法满足用户的核心需求。而没有Evaluator时，Generator的自我宽容特性会再次凸显，BUG、功能缺失等问题会大量出现，开发质量无法得到保障。 在去掉迭代拆分结构后，团队还调整了Evaluator的工作模式：从原来的“每轮迭代都评分”，改为“整轮开发结束后做一次总评”。这一调整的原因，是随着模型能力的增强，Evaluator在不同运行里的“承重程度”也发生了变化，它的价值，取决于任务相对模型原生能力的边界位置。 在Opus 4.5上，这条边界离我们很近：当时团队的构建任务，恰好处在Generator单独完成就容易失控的边缘，所以Evaluator能在整个构建过程中，抓到许多真正重要的问题，每轮迭代的评分和反馈，都是推动Generator优化的关键。而到了Opus 4.6，模型的原始能力本身上升了，这条边界也随之往外移动。以前必须依赖Evaluator才能做连贯的任务，现在很多已经落在Generator单独也能稳定完成的范围内。对于落在这条边界以内的任务，Evaluator反而会变成不必要的额外成本，增加开发时间和token消耗。 但这并不意味着Evaluator失去了价值。对于那些仍处在Generator能力边缘的复杂任务，Evaluator依旧能带来实质增益，它能找出Generator忽略的细节问题、边缘场景BUG，以及功能缺失，推动Generator完成最终的优化，确保应用的质量。这也意味着，Evaluator不是一个固定的“是/否”选择，而是要根据任务的复杂度和模型的能力，动态调整其工作模式，只有当任务超出当前模型单独可靠完成的能力边界时，它的成本才真正值得。 ## （二）迭代后的测试：数字音频工作站开发，验证简化架构的效果 为了测试这版更新后的Harness架构，Anthropic团队用了一个更复杂的需求：“在浏览器中基于Web Audio API构建一个功能完整的DAW（Digital Audio Workstation，数字音频工作站），也就是一种可以用来创作、录音和混音的音乐制作软件。” 这个需求比之前的复古游戏制作器更复杂，涉及音频处理、实时交互、多轨道混音等核心功能，对模型的开发能力要求更高。 测试结果显示，这次运行仍然很长也很贵：大约花了3小时50分钟，token成本约为124.7美元。其中，Planner仅用4.7分钟就完成了产品规格的扩展，成本0.46美元；Generator分三轮完成开发，总时长约3小时20分钟，成本113.85美元；Evaluator分三轮进行评估，总时长约25.2分钟，成本10.39美元。 从运行日志来看，即便不再依赖Opus 4.5曾经需要的迭代拆分，Generator依然能连贯地工作两个多小时，规划应用与智能体设计、把智能体接线接好，以及在交给Evaluator前自行测试等方面，都做得很好。这充分证明，Opus 4.6的长时任务处理能力，已经能满足复杂全栈开发的需求，迭代拆分结构的移除，并没有影响开发的连贯性。 但即便模型能力大幅提升，Evaluator仍然抓到了实打实的缺口。在第一轮评估反馈中，Evaluator明确指出：“这是一个相当强的应用，设计一致性很好，AI智能体也不错，后端也扎实。主要失败点在于‘功能完整度’，虽然应用看上去很出色，AI集成也能用，但几个DAW的核心功能仍然只是展示层，没有足够的交互深度：clip（音频片段）不能在时间线上拖动/移动，没有乐器面板UI（例如合成器旋钮、鼓垫），也没有图形化的效果编辑器（例如EQ曲线、压缩器表盘）。这些并不是边缘情况，而是让DAW真正可用的核心交互，并且规格里已经明确要求了它们。” 在第二轮评估反馈中，Evaluator又一次抓出了几处功能缺口：“仍然存在的缺口：音频录制仍是stub-only（按钮会切换，但没有真正采集麦克风）；还没有实现通过边缘拖拽调整clip长度，也没有实现split clip（拆分音频片段）；效果可视化仍然只是数值滑杆，而不是图形化表现（没有EQ曲线）。” 这些反馈清晰地表明，即便Opus 4.6的能力已经很强，任由Generator自己发挥，它仍然会漏细节，或者把功能做成“占位符”，无法达到产品规格的要求。而Evaluator的价值，就在于在最后一公里帮它补上这些问题，推动Generator完成三轮迭代，最终实现了可编排旋律、混音、AI辅助作曲的核心功能。 最终生成的DAW应用，虽然距离专业音乐制作软件还有很大差距，智能体在作曲方面的能力也还有提升空间，而且Claude并不能真正“听见”声音，导致Evaluator的反馈循环在音乐审美层面没那么有效，但它已经具备了一个可用音乐制作程序的核心部件：能在浏览器里运行的编排视图、混音器和传输控制。用户甚至可以通过prompt，让内置的AI智能体设定速度与调性、铺出旋律、生成鼓轨、调整混音电平，并添加混响，从头到尾完成一段简单的歌曲制作。 这次测试，不仅验证了简化后Harness架构的有效性，也进一步明确了架构迭代的核心逻辑：随着模型能力的升级，Harness架构要做的不是“加法”，而是“减法”，剥离冗余组件，聚焦核心价值，让架构始终与模型能力相适配，兼顾开发质量与效率。 ## 四、Harness架构带来的深度思考：AI自主编程的未来，人机协作是核心 Anthropic团队的Harness设计，不仅解决了当前大模型长时开发的痛点，更为AI自主编程领域带来了深刻的思考，也为行业发展指明了方向。它不仅仅是一套技术架构，更是一种AI工程化的思维方式，这种思维方式，将影响未来所有AI复杂任务的落地与实现。 ## （一）多代理协作：AI突破能力边界的核心路径 Harness架构的成功，最核心的原因就是采用了多代理协作的模式。单一模型在执行复杂任务时，必然会出现精力分散、判断偏差、能力不足等问题，一个模型既要理解需求、规划任务，又要编写代码、测试调试，还要客观评估自己的成果，很难做到面面俱到。 而将任务拆解为规划、生成、评估等环节，由专门的智能体负责，能最大化发挥每个模块的优势：Planner专注于需求理解和任务规划，确保开发方向正确；Generator专注于代码编写和功能实现，确保开发效率；Evaluator专注于质量评估和BUG检测，确保开发质量。这种分工协作的模式，模拟了人类软件开发团队的工作方式，产品经理负责规划，开发者负责编码，测试工程师负责质检，让AI从“单打独斗”转向“团队作战”，能力自然实现指数级提升。 未来，随着模型能力的进一步提升，多代理协作的模式会更加成熟。不同的智能体之间，会形成更高效的通信机制，能够自主协商、动态调整任务分工，甚至能根据任务的复杂度，自动增减智能体的数量，实现“按需配置”。这种模式，不仅会应用在AI编程领域，还会延伸到内容创作、设计策划、数据分析、企业管理等多个领域，成为AI突破能力边界的核心路径。 ## （二）量化评估与反馈闭环：AI质量提升的关键抓手 Harness架构的另一个核心亮点，是量化评估与反馈闭环的设计。无论是主观的前端设计，还是客观的代码开发，模糊的评价标准都会让AI失去优化方向，陷入“自我满足”的陷阱。而将质量要求转化为可量化的评分标准，建立持续的反馈闭环，能让AI在迭代中不断修正缺陷，逐步逼近甚至超越人类的创作与开发水平。 这种量化评估的思路，也为AI工程化提供了重要参考：对于任何AI复杂任务，都应该建立清晰、可量化的评估标准，避免“凭感觉”判断成果质量。比如在AI内容创作中，可以制定“原创性、流畅度、逻辑性”等量化标准；在AI数据分析中，可以制定“准确性、完整性、实用性”等量化标准。通过这些标准，让AI的输出有明确的优化方向，让开发者能客观判断AI的成果质量。 同时，反馈闭环的设计也至关重要。AI的学习能力很强，但需要持续的反馈来引导。Harness架构中，Evaluator的反馈不是简单的“合格/不合格”，而是详细的、可操作的修改意见，比如“代码中某行逻辑错误，应修改为XXX”“界面配色过于单调，建议增加辅助色XXX”。这种具体的反馈，能让Generator快速找到问题所在，高效完成优化。未来，反馈闭环会更加智能化，Evaluator不仅能找出问题，还能给出具体的修改方案，甚至能直接协助Generator修改代码，进一步提升开发效率。 ## （三）动态适配模型能力：AI工程的核心思维 Harness架构的迭代过程，充分体现了“动态适配模型能力”的AI工程思维。没有永恒不变的最优架构，所有组件的存在都基于模型当前的能力短板。当模型升级后，工程师需要重新审视架构，剥离冗余组件，加入新的功能模块，持续寻找适配模型的最优组合。 这种思维方式，打破了“一劳永逸”的工程理念。在AI技术飞速发展的今天，模型的能力迭代速度非常快，每一个新版本的模型，都会在上下文处理、逻辑推理、代码编写等方面有所提升，原本需要架构来辅助解决的问题，可能会被模型自身的能力解决。如果固守旧的架构，不仅会增加开发成本和复杂度，还会限制模型能力的发挥。 这也意味着，AI工程师的核心价值，不再是编写固定的提示词或架构，而是跟随模型进化，持续优化工程方案。AI工程师需要深入了解模型的能力边界，知道模型能做什么、不能做什么，然后根据任务需求，设计出最简洁、最高效的架构，让模型的优势得到最大化发挥，同时弥补模型的短板。这种“动态适配”的思维，将成为未来AI工程领域的核心竞争力。 ## （四）行业落地：AI自主开发将重构软件开发范式 从行业落地角度来看，Harness架构的成熟，将推动AI自主开发进入产业化阶段。未来，小型应用、原型系统、个性化工具的开发，完全可以由AI自主完成，大幅降低开发成本与时间成本。对于企业而言，能快速实现创意落地，缩短产品迭代周期，提升市场竞争力；对于个人开发者而言，能借助AI完成原本无法独立实现的复杂项目，降低软件开发的门槛，让更多人能参与到创意落地中来。 比如在创业公司中，往往缺乏专业的开发团队，借助Harness架构，仅需一名产品经理，输入简单的需求提示，就能让AI自主开发出产品原型，甚至是可用的MVP版本，大幅降低创业成本；在大型企业中，开发者可以借助Harness架构，让AI完成重复性、基础性的开发工作，比如代码编写、BUG修复、功能迭代等，自己则聚焦于创意设计、需求规划、技术架构等核心环节，提升开发效率。 同时，Harness架构的思路也可以迁移到其他AI应用场景。比如在内容创作领域，可以设计“策划智能体、创作智能体、编辑智能体”的多代理架构，让AI自主完成文章、视频、文案等内容的创作；在设计领域，可以设计“需求分析智能体、设计智能体、评估智能体”的架构，让AI自主完成UI设计、海报设计、产品设计等任务；在数据分析领域，可以设计“数据采集智能体、分析智能体、可视化智能体”的架构，让AI自主完成数据处理、分析和展示。 但需要注意的是，AI自主开发并不是要取代人类开发者，而是要与人类开发者形成协作。AI负责完成重复性、基础性的工作，人类则负责创意设计、需求规划、质量把控等核心环节，人机协作将开启软件开发的全新范式。未来，真正优秀的开发者，不是“不依赖AI”，而是“能高效利用AI”，借助AI的能力，突破自身的能力边界，完成更复杂、更有创意的项目。 ## 五、结语：AI自主开发的新时代，已经到来 Anthropic团队的Harness设计，是AI自主编程领域的里程碑式成果。它通过解决上下文焦虑与自我评估失效两大核心问题，打造了可支撑数小时长时开发的多代理架构，让Claude模型从能写代码，进化为能开发完整、可用、高质量的全栈应用。 从前端设计的主观审美量化，到全栈开发的三代理协作，再到随模型进化的架构迭代，Harness设计不仅展现了技术上的创新，更传递了AI工程化的核心思维：以问题为导向，动态适配模型能力，用简洁高效的方案突破能力瓶颈。这种思维方式，不仅适用于AI编程领域，更适用于所有AI复杂任务的落地与实现。 当下，大模型技术仍在飞速发展，模型的上下文处理、代码能力、自主决策能力还在持续提升。未来的Harness架构会更加简洁，成本会进一步降低，能完成的开发任务也会更加复杂，甚至可以实现大型应用、企业级系统的自主开发。随着技术的不断普及，我们即将迎来人人都能借助AI开发应用的时代，创意的实现将不再受技术能力的限制，软件开发的门槛将被彻底打破。 对于每一个身处互联网与AI行业的人来说，不必担忧AI取代开发者，而是应该借助Harness这类先进架构，让AI成为高效的协作伙伴。AI负责完成重复性、基础性的开发工作，人类则聚焦于创意设计、需求规划、质量把控等核心环节，人机协作将开启软件开发的全新范式。