文章目录
- 前言
- [为什么普通的Prompt Engineing，Context Engineing 会失败？](#为什么普通的Prompt Engineing，Context Engineing 会失败？)
- [planner-generator-evaluator 多 agent 架构](#planner-generator-evaluator 多 agent 架构)
- 前端设计：把好看的东西变得可打分
- 全栈编码的扩展
-
-
- [Sprint 机制](#Sprint 机制)
-
- 原文链接：
前言
Anthropic在2026.3.24推出了一篇Harness design for long-running application development的文章，这篇文章主要是让 Claude 在前端设计和长期自动运行的软件工程上推动发展。让我不用AI，以最直白的方式带你理解。
为什么普通的Prompt Engineing，Context Engineing 会失败？
做事要保持好奇心，带着问题，带着疑问去思考，远比被动接受效果来得好。想想看，你觉得可能是什么原因？
Agent在执行任务时，短的简单的任务可以容易实现，但是一旦执行任务的时间变长或者任务变复杂，Agent 的表现就会随之拉跨。究其原因，有两种常见的失败模式：
- 上下文窗口填满： 当长时间运行时，模型的上下文会被填满，部分模型还会出现"上下文焦虑"------在接近他们认为的上下文极限时，会提前结束工作。
- 自我评估自信： 让模型自己去评估自己做的事情，它往往会盲目自信的认为自己做的是完全正确的，缺少显式的设计原则、评分标准等测试环节。即使将generator 和 evaluator 显式分开，由于 evaluator 仍然是 LLM，它仍倾向于对 LLM的回答给出正面评估。
如何解决呢？
planner-generator-evaluator 多 agent 架构
为了解决上述的问题，作者从两个角度出发寻求解决办法：一个是前端审美，往往由主观意愿决定；二是可用性和可验证性的定义。作者在解决这两个问题时，从 GAN 汲取灵感，设计了一套多 Agent 架构，包括generator 和 evaluator（对于后端还有一个 planner）。
- 启动一个新的 agent，完全清除上下文，并附带结构化交接（携带前一个 Agent 的状态以及后续步骤）解决了上面第一个上下文的问题；
- 让独立的evaluator变得多疑，实现generator和 evaluator 之间的交互反馈链路，解决第二个自我评估盲目自信的问题。
combined with a structured handoff that carries the previous agent's state and the next steps
But tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work, we can create a feedback loop that drives the generator toward stronger outputs.
前端设计：把好看的东西变得可打分
那为了建立这种反馈链路，变得可打分，作者在 generator 和 evaluator 中分别写下了以下 4 个相同的评分标准：
- Design quality: Does the design feel like a coherent whole rather than a collection of parts? Strong work here means the colors, typography, layout, imagery, and other details combine to create a distinct mood and identity.
- Originality: Is there evidence of custom decisions, or is this template layouts, library defaults, and AI-generated patterns? A human designer should recognize deliberate creative choices. Unmodified stock components---or telltale signs of AI generation like purple gradients over white cards---fail here.
- Craft: Technical execution: typography hierarchy, spacing consistency, color harmony, contrast ratios. This is a competence check rather than a creativity check. Most reasonable implementations do fine here by default; failing means broken fundamentals.
- Functionality: Usability independent of aesthetics. Can users understand what the interface does, find primary actions, and complete tasks without guessing?
对于evaluator 的校准，作者用小样本及具体的分数的示例来校准。
为什么要这么做？
作者说起强调质量和原创性，是因为 Claude 在功能上天然得分不错，因为其所需的技术能力对模型而言是必须的。但是对于设计和原创性方面模型可能更不愿意冒险。通过上面的标准约束了高度通用的 AI杂质模式，推动模型向设计和原创性去驱动。
全栈编码的扩展
| Agent | 职责 | 解决的问题 |
|---|---|---|
| Planner | 把 1-4 句话的用户 prompt 扩展为完整产品 spec | 之前需要用户手写详细规格。Planner 只定义 "做什么"，不定义 "怎么做"------ 因为如果 Planner 在技术细节上犯错，错误会级联到下游 |
| Generator | 按 Sprint 逐个实现功能，使用 React+Vite+FastAPI+SQLite 技术栈，内置 git 版本控制 | 一次做一个 feature，保持作用域可控 |
| Evaluator | 用 Playwright 像真实用户一样点击应用，测试 UI、API、数据库状态，按标准打分 | 解决 Agent 自评虚高的问题 |
Sprint 机制
Sprint 是 Scrum 框架中的一个固定时间盒（通常 1-4 周），核心思想是 把大项目切成小批次，每批次可交付、可验证。
每个 Sprint 开始前，Generator 和 Evaluator 先谈判：Generator 提出要做什么、怎么验证算完成；Evaluator 审核这个提案，确保方向正确。双方达成一致后才开始写代码。
这个设计的精妙之处在于：产品 spec 故意保持高层级（避免规格错误级联），Sprint 契约填补了 spec 到可测实现之间的缝隙。通信机制也刻意简单 ------ 通过文件读写，一个 Agent 写文件，另一个读取并回复。