长期跑应用开发的 Harness 系统设计

Jul 1, 2026 00:00 · 1333 words · 3 minute read AI Agent

原文 Harness design for long-running application development

长时间 autonomous coding 中有两个核心失败模式：

  1. 上下文退化

    • 随着上下文窗口被填满，模型在长任务中容易逐渐失去一致性

    • 模型感觉自己快到上下文上限时，会过早收尾，而不是继续推进任务（context anxiety）

      解决方案：

      • 启动新 agent，把前一个 agent 的状态、已完成事项和下一步计划传递过去（context reset）
      • 把旧上下文压缩成摘要，让同一个 agent 继续工作（compaction）

  2. 自我评估偏差

    • 模型自我评估过度乐观

      解决方案：

      • 把 generator 和 evaluator 拆开：generator 负责产出，evaluator 负责审查

评估的关键思路：审美不能完全量化，但可以通过评分标准把“好不好看”转化为更具体的可评价维度

维度 专业化解释
Design quality 设计是否形成一个统一整体，而不是零散组件拼接；颜色、排版、布局、图像和细节是否共同构成明确的视觉气质和品牌感。
Originality 是否有自定义设计决策，还是模板化布局、组件库默认样式、AI 常见套路。
Craft 技术执行质量，包括字体层级、间距一致性、色彩和谐、对比度等。
Functionality 可用性；用户能否理解界面意图、找到主要操作并完成任务。

工程实现上，作者基于 Claude Agent SDK 搭建循环：generator 先根据用户 prompt 生成 HTML/CSS/JS 前端；evaluator 使用 Playwright MCP 直接访问和操作页面，而非只看静态截图，然后按四个维度打分并输出详细 critique；反馈再回流给 generator 进入下一轮迭代。每次生成通常跑 5 到 15 轮，完整运行可能长达 4 小时。

3-agent 架构：

  1. Planner

    接收用户的 1 到 4 句话 prompt，并扩展成完整产品规格说明。它关注产品上下文和高层技术设计，而不是一开始就规定过细的实现细节。

  2. Generator

    Generator 按 sprint 工作，每次从 spec 中拿一个 feature 或一组功能实现。

  3. Evaluator

    Evaluator 使用 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI、API endpoint 和数据库状态。它基于产品深度、功能完整性、视觉设计、代码质量等标准评分。

定义“完成”

在每个 sprint 开始前，generator 和 evaluator 会协商一个 sprint contract。它的作用是明确这段工作做到什么程度才算 done。

  1. Generator 提出本 sprint 要构建什么。
  2. Generator 描述如何验证成功。
  3. Evaluator 审查这个计划是否符合 spec。
  4. 双方通过文件来回通信，直到达成一致。
  5. Generator 按 contract 实现。
  6. Evaluator 基于 contract 做 QA。

简化系统

harness 中的每个组件都隐含了一个假设：模型自己做不到这件事。随着模型能力提升，这些假设可能过时。

所以维护 agent harness 时，要去掉某个组件，看性能是否下降。如果不下降，说明它可能已经不是 load-bearing component。

evaluator 不是一个固定“要不要”的选择，而是取决于任务是否超过当前模型稳定单独完成的能力边界。任务在模型能力边界以内时，evaluator 可能只是 overhead；任务接近或超过边界时，evaluator 仍然能显著提升质量。

总结

长时间自主软件开发的瓶颈，不只是模型能力本身，而是如何设计围绕模型的执行系统。

一个高质量 agent harness 至少要解决四类问题：

  1. 上下文管理
  2. 任务拆解
  3. 评价隔离
  4. 动态简化

不要把 LLM 当成一次性代码生成器，而要把它放进一个可观测、可验证、可迭代、可裁剪的工程执行系统中。

对于实际团队落地，推荐优先借鉴三点：

  1. 引入独立 QA agent，并让它通过 Playwright、API test、DB state inspection 等方式验证真实运行结果。
  2. 使用 contract-first 的开发流程，先定义 done criteria，再写代码。
  3. 定期重新评估 harness 复杂度，因为模型能力提升后，昨天必要的流程，明天可能只徒增成本。