AI-Wiki

基本定义

Harness架构是Anthropic团队面向AI长时自主开发场景推出的多代理协作工程化方案，属于Agentic Coding（智能体编程）领域的核心落地框架之一。该架构参考生成对抗网络的对抗设计思路，通过生成与评估分离模式、上下文优化、三代理任务分工等设计，彻底解决了传统朴素AI编程在长时开发中存在的需求偏航、BUG频发、自我评估失效等问题，可支撑Claude大模型系列自主完成数小时的复杂全栈应用开发，且支持随大模型能力升级动态调整组件复杂度，兼顾开发质量与效率。

设计背景：朴素AI编程的核心瓶颈

在Harness架构出现前，业内AI自主开发普遍采用单代理模式，普遍存在两大无法突破的死穴：

1. 上下文焦虑与连贯性崩塌

大模型上下文窗口存在物理上限，长时开发过程中对话记录、代码片段、调试日志等信息持续填充窗口，会导致模型对核心需求的把控能力下降，出现逻辑断裂、需求遗忘、功能重复开发等问题；更严重的是模型会出现「上下文焦虑」现象：感知到上下文即将满额时会草率收尾，跳过核心功能直接交付表面成果。传统「上下文压缩」方案仅能精简历史信息，会丢失代码注释、特殊需求等关键细节，无法从根本上解决问题。Harness架构针对性提出上下文重置机制：彻底清空当前上下文窗口，启动全新智能体，通过结构化工件（任务清单、状态报告、代码文档等）完整传递前序工作状态，让模型以全新状态接手任务，彻底摆脱上下文焦虑影响，但该机制也会带来编排复杂度上升、token成本增加、开发延迟增加的副作用。

2. 自我评估失效与智能体自我宽容

作为生成主体的大模型天然对自身产出存在「偏爱」，无论前端设计这类主观场景还是后端开发这类客观场景，都会出现过度乐观的自我评估：明明存在明显BUG、设计平庸，依然会给出高分评价，长时开发中会持续强化错误逻辑，最终导致项目完全偏离需求。 Harness架构借鉴生成对抗网络的设计思路，将生成与评估职责拆分给不同智能体，从机制上避免自我评估偏差问题。

进化路径：从前端验证到全栈落地

Harness架构的设计并非一蹴而就，而是遵循「先验证核心逻辑，再扩展复杂场景」的迭代路径：

第一阶段：前端设计场景验证

团队首先在主观属性较强的前端开发场景验证生成与评估分离的可行性，核心突破是将模糊的审美要求转化为可量化的前端设计四大评分标准，权重分配为：设计质量35%、原创性35%、工艺15%、功能性15%，重点针对AI生成设计模板化、缺乏原创性的短板。基于Claude Agent SDK和Playwright MCP工具，团队搭建了初步的生成评估闭环：Generator智能体生成前端代码，Evaluator智能体通过真实交互测试页面效果，按标准给出评分和可落地的修改意见，回流给Generator迭代优化。前端场景下经过5-15次迭代即可产出高质量设计成果，甚至出现超出预期的创意跃迁。

第二阶段：全栈开发场景迁移

前端场景验证核心逻辑可行后，团队将生成评估分离模式迁移到复杂度更高的全栈开发场景，结合上下文重置机制，最终完善出Planner/Generator/Evaluator三代理核心架构，覆盖全链路开发需求。

核心架构与运行机制

Harness架构的核心是三代理协同的开发闭环，三个智能体职责明确，通过文件化通信实现信息传递，保留完整开发日志可追溯：

1. Planner智能体

负责需求解析与规划，仅需接收用户1-4句简单需求提示，即可自动扩展为完整的产品规格，包含产品概览、核心功能清单、迭代规划、技术栈选择、AI能力融入方案等内容，且会刻意保持高层抽象，避免早期技术判断失误向下传导。例如用户输入「创建2D复古游戏制作器」的需求，Planner会自动扩展为包含16个功能、10个迭代周期的完整规格，还会主动加入Claude集成、游戏分享导出等拓展功能。

2. Generator智能体

负责具体代码实现，根据Planner输出的产品规格，以迭代为单位完成全栈开发，默认采用React+Vite+FastAPI+SQLite/PostgreSQL技术栈，支持Git版本自动提交。每轮迭代完成后会先做初步自评估，再将成果提交给Evaluator，根据反馈调整开发方向：若仅为细节优化则继续精修，若核心方向错误则彻底重构方案。

3. Evaluator智能体

作为AI开发的「质检员」，借助Playwright MCP模拟真实用户操作，从产品深度、功能性、视觉设计、代码质量四个维度评估开发成果，任意维度未达硬阈值则判定迭代失败，要求Generator重新优化。为避免职责分歧，每轮迭代开始前Evaluator会与Generator协商制定迭代合约，明确本轮迭代的功能目标、测试标准、完成定义，确保开发方向始终对齐需求。

效果验证：与单代理模式的对比

Anthropic团队使用相同需求（开发2D复古游戏制作器）、相同模型（Claude Opus 4.5）做了对比实验：

单代理模式：耗时20分钟，token成本9美元，输出成果存在大量逻辑漏洞，实体交互等核心功能完全失效，仅能呈现表面界面；
Harness架构：耗时6小时，token成本200美元，输出成果功能完整，支持关卡编辑、精灵创作、实机游玩，还额外实现了AI生成游戏内容、作品分享等拓展功能，整体打磨度接近人类开发的小型商用产品。

架构迭代逻辑：随模型能力动态简化

Harness架构的组件设计并非固定不变，而是遵循「仅在必要时增加复杂度」的动态适配模型能力AI工程思维，所有组件的存在都是基于当前模型能力边界的假设，会随大模型版本升级逐步剥离冗余组件： Claude Opus 4.6发布后，模型长时任务连贯性、自调试能力大幅提升，团队移除了原本的迭代拆分机制，同时调整Evaluator工作模式：对于处于模型原生能力边界内的任务，仅在开发完成后做一次总评降低成本；对于超出能力边界的复杂任务，保留多轮评估机制保障质量。简化后架构的验证实验显示：针对浏览器端数字音频工作站的复杂开发需求，仅耗时3小时50分钟、token成本124.7美元，即可产出支持多轨混音、AI辅助作曲的可用产品，开发效率较原架构提升40%以上。

应用边界

适用场景：面向开发周期大于1小时、对交付质量要求较高的复杂全栈应用、高要求前端设计等场景，简单代码片段生成、小型功能实现等轻量场景使用会增加不必要的成本；
成本特性：相比单代理模式时间成本提升3-18倍，token成本提升10-20倍，适合质量优先级高于成本的商用开发场景；
配置灵活性：所有组件支持按需开关，可根据模型版本、任务复杂度动态调整架构配置，例如模型能力足够时可关闭Evaluator组件降低开销。

Harness架构