面向长时间运行应用开发的智能体脚手架（Harness）设计
发布于 • 作者: Ethan
概述
原文Harness design for long-running application development
1. 核心背景与行业挑战
在全栈软件工程与前端设计的代理化（Agentic）开发前沿，智能体（Agent）的表现在很大程度上取决于“脚手架（Harness）”的设计架构。随着大型语言模型处理复杂任务的需求日益增加，让模型在无人干预的情况下持续数小时甚至更长时间生成高质量的应用程序，成为了行业面临的核心挑战。
在探索智能体独立完成长期任务的过程中，通常会暴露出两个极其显著的失败模式：
- 上下文焦虑（Context Anxiety）与连贯性丧失：当模型在处理冗长任务时，随着上下文窗口的逐渐填满，模型往往会失去逻辑连贯性。部分模型甚至会表现出“上下文焦虑”——当它们预测即将达到上下文极限时，会过早且草率地结束工作。传统的解决方案是进行 上下文重置（Context Resets），即完全清空上下文窗口，启动一个全新的智能体，并结合结构化的状态交接。虽然这种方法提供了一张“白纸”，有效缓解了焦虑，但也大幅增加了编排的复杂性、Token 的消耗以及系统延迟。这与 上下文压缩（Compaction） 不同，后者是在原地总结历史记录以保持连续性，但无法彻底消除模型的焦虑感。
- 自我评估的宽容度偏差（Self-evaluation Leniency）：当要求智能体评估自身生成的工作成果时，它们往往会盲目自信地给出高度评价。这种偏差在缺乏二进制对错校验的主观任务（如UI/UX设计）中尤为明显。即使对于人类观察者而言质量平庸的作品，模型也会倾向于给予赞美。
为了突破这些瓶颈，借鉴生成式对抗网络（GANs）灵感的“生成器-评估器（Generator-Evaluator）”多智能体架构成为了一种极具潜力的破局方案。
2. 前端设计：将主观质量转化为可量化的评分标准
在前端设计领域，未经干预的模型通常倾向于生成安全、可预测但视觉上平庸的布局（即技术上可行但缺乏美感的默认模板）。为了打破这种局限，必须将主观的审美判断转化为客观的、可逐项评分的具体标准。
2.1 结构化的评分标准体系
在生成器和评估器智能体的提示词中，引入了以下四个维度的评分标准，以此构建反馈循环：
- 设计质量（Design Quality）：设计是否构成一个连贯的整体，而非零散部件的堆砌？优秀的标准在于色彩、排版、布局和图像等细节能否共同营造出独特的氛围和品牌形象。
- 原创性（Originality）：是否存在定制化决策的痕迹？人类设计师能够识别出刻意的创意选择。如果完全使用未修改的组件库默认设置，或带有明显的“AI生成特征”（如白色卡片上突兀的紫色渐变），则在此项评分中不合格。
- 工艺细节（Craft）：技术执行层面的基本功，例如排版的视觉层级、间距的统一性、色彩和谐度以及对比度比例。这主要考察技术胜任力，不合格意味着破坏了设计的基础原则。
- 功能性（Functionality）：独立于视觉美学之外的可用性。测试目标群体能否清晰理解界面功能、找到主要操作入口并顺利完成任务。
在实际应用中，设计质量和原创性被赋予了更高的权重，以明确惩罚平庸的“AI批量生成（AI slop）”模式，迫使生成器承担更多的美学风险。
2.2 评估循环与动态反馈
评估器不仅是静态分析代码，更是通过集成 Playwright MCP（模型上下文协议）直接在实时页面上进行交互。评估器能够自主导航、截图并仔细研究实现细节，随后生成详细的批评意见反馈给生成器。
每一次生成通常包含 5 到 15 个迭代周期。生成器需要在每次收到评估结果后做出战略决策：如果评分趋势良好则继续深化当前方向；如果效果不佳则彻底推翻重来。这种机制带来了惊人的创意飞跃，例如在为某荷兰艺术博物馆生成网页的测试中，模型在第九次迭代时仍是常规的深色着陆页，但在第十次迭代时，模型直接将界面重构为了一个 3D 空间体验（采用 CSS 透视视角的棋盘格地板和挂在墙上的艺术品）。
3. 扩展至全栈代码开发：三智能体协作架构
将前端设计的评估模式扩展至包含后端逻辑与数据库的全栈开发中，需要更为严密的工程架构。在此阶段，系统演进为包含三个独立角色的智能体网络：
3.1 智能体角色定义
- 规划者（Planner）：负责将用户简短的提示（1至4句话）自动扩展为完整的产品规格说明书（Spec）。规划者被设定为在功能范围上具有雄心壮志，但严格专注于产品上下文和高层面的系统设计，避免过早陷入底层技术细节的设定，以防止早期错误在下游实现中产生连锁反应。
- 生成器（Generator）：采用类似于敏捷开发中“冲刺（Sprint）”的模式，每次从规格说明书中提取一个功能进行实现。技术栈包含 React、Vite、FastAPI 和 PostgreSQL。生成器配备了 Git 版本控制工具，并在完成编码后进行自我评估，随后移交质量保证（QA）。
- 评估器（Evaluator/QA）：利用 Playwright MCP 像真实用户一样点击浏览运行中的应用程序，测试 UI 功能、API 端点和数据库状态。评估器依据预设标准（产品深度、功能性、视觉设计、代码质量）对每个冲刺的结果进行严格验收。若任何指标低于硬性阈值，冲刺将被判定失败，生成器必须根据详细的反馈进行修复。
3.2 冲刺契约（Sprint Contract）机制
为了弥合高层次规格说明与可测试代码之间的鸿沟，在每个冲刺编写代码之前，生成器和评估器需要进行契约谈判。生成器提出将要构建的内容以及如何验证其成功，评估器审查该提案以确保方向无误。双方通过读写文件进行通信，直到就该冲刺的“完成标准”达成一致，随后生成器才开始严格按照契约进行开发。
3.3 案例对比分析：RetroForge（2D复古游戏制作工具）
通过构建一个包含关卡编辑器、精灵图编辑器、实体行为和测试模式的 2D 游戏引擎，可以清晰地看出单智能体与三智能体架构的差异：
| 运行模式 | 运行时长 | 消耗成本 | 核心表现 |
|---|---|---|---|
| 单智能体直接生成 | 20 分钟 | $9 | 界面布局浪费空间，工作流僵化；游戏运行崩溃（实体定义与运行时的关联彻底断裂）。 |
| 三智能体架构 | 6 小时 | $200 | 扩展为16项功能（含音效、AI辅助生成）；界面规整且符合视觉规范；精灵编辑器功能完备；游戏可实际游玩并响应物理碰撞。 |
评估器在这一过程中发挥了决定性作用。它精准捕获了诸多单靠生成器无法察觉的深层逻辑漏洞，例如：
- 前端逻辑错误：矩形填充工具无法拖拽填充区域，仅能在拖拽起点和终点放置图块。
- 状态管理缺陷：用户删除实体的事件处理程序需要同时满足选中状态和特定的实体ID条件，导致点击删除无效。
- API 路由冲突：FastAPI 中重排序的
PUT路由由于定义在动态变量路由之后，导致引发 422 解析错误。
4. 架构的迭代与去繁就简（基于 Opus 4.6 的演进）
智能体脚手架并非一成不变，它必须随着底层基础模型的升级而不断演进。优秀的架构设计理念是：“寻找最简单的有效方案，仅在必要时才增加复杂性。”
随着具备更强长期任务维持能力、更优大代码库操作能力以及自带代码审查机制的新一代模型（如 Claude Opus 4.6）发布，原有脚手架中的许多“承重墙”可以被安全地移除：
- 移除冲刺（Sprint）机制：新模型不再高度依赖将任务拆解为小块来维持连贯性，生成器能够在一个连贯的长时间会话中处理整个项目。
- 重置评估时机：由于基础模型自身编码准确率的提升，评估器不再需要在每个微小功能后介入，而是转变为在运行结束时进行单次全面审查。
4.1 案例分析：构建浏览器端 DAW（数字音频工作站）
在基于新模型与精简架构的测试中，目标是利用 Web Audio API 构建一个功能齐全的在线音乐制作软件。
- 运行数据：耗时约 3 小时 50 分钟，总成本约为 $124。
- 时间分布：规划者耗时极短（4.7分钟），而第一轮无中断构建持续了超过 2 小时 7 分钟，证明了模型强大的原生长上下文处理能力。
- 评估器的边界价值：虽然模型能够独立完成混音器、排列视图等核心框架的搭建，甚至成功集成了自主驱动的 AI 编曲智能体，但评估器依然在“最后一公里”展现了不可替代的价值。它指出了应用在互动深度上的缺失（例如音频剪辑无法在时间轴上拖拽、缺乏可视化的 EQ 曲线图等）。这表明，评估器的存在与否不应一概而论，当任务难度处于当前模型能力的边缘时，它依然能够提供巨大的增益。
5. 总结
面向长时间运行应用开发的智能体脚手架设计，本质上是一场关于“补充模型能力短板”与“控制系统复杂性”的动态博弈。
- 明确评估标准至关重要：无论是主观的设计品味还是客观的系统功能，将其转化为机器可解析的刚性标准，是多智能体互相协作与监督的基础。
- 模型进步重塑架构：随着底层语言模型的迭代，旧有用来防止“上下文焦虑”的复杂机制（如会话重置、碎片化冲刺）将被淘汰，但省下的算力与架构空间应当被投入到实现更复杂的目标中。
- 分离“执行”与“审查”：无论模型变得多么强大，引入外部视角的审查智能体（配备沙盒测试和自动化工具）始终是打破模型自我评价盲区、推动应用向生产级可用性迈进的核心策略。