TL;DR

Evaluator 驱动的 Harness 要分开管理任务契约、候选版本和验收证据。反馈指出可复现缺陷，修订受预算与平台期限制，并保留最佳有效候选。确定性检查优先于模型评分；留出验收用于识别迎合裁判，闭环不保证收敛，也不保证最终版本最好。

裁判打高分，应用却坏了

生成器提交无法运行的页面，裁判根据截图给出高分；下一轮改好配色，却破坏了登录。只追踪分数，就会把退化当成进步。Evaluator（评估器）需要检查运行结果，并让反馈指向具体缺陷。

Agent Harness管理待验收版本（候选）、验收证据、预算和停止条件。LLM-as-a-Judge适合评价难以用程序检查的体验问题；功能和权限优先用测试验收。

Anthropic 的 2026 年应用开发实验将生成与评估分开，用示例校准设计、原创性、完成度和功能评分，并按阶段约定组织规划、生成和验收。实验也发现改善可能停滞，中间版本可能比最终版本更好。其设计标准反映作者偏好，不宜直接照搬。

订单应用的过滤逻辑、错误提示和界面可用性应分别检查。一个“质量 8 分”既不能指导修复，也不足以解释为什么通过验收。

先定义契约，再设计评分

任务契约就是事先约定的要求、证据和验收责任。执行期间不得悄悄改变标准。

契约部分 订单应用示例 验收方式
必须成立的功能 日期过滤返回正确订单 固定测试数据与查询检查
边界行为 无权限时不泄漏订单 身份隔离测试
体验要求 加载、空结果和错误状态可辨识 浏览器操作与经人工校准的评分
执行约束 不修改正式订单，不超预算 工具权限与控制器计费
交付物 候选版本、运行说明和证据 版本与产物核对

编译、权限和数据正确性属于必须通过的检查，视觉高分不能抵消失败。错误提示、交互流畅度可以分级评分，但每档要有示例，明确“可用但粗糙”与“无法操作”的差别。

Anthropic 的 Agent 评测说明区分任务、单次运行、评分器和实际结果。裁判只看截图，就不能证明应用能运行。

新增移动端要求时，更新契约版本并重新验收。要求互相矛盾时，交由人工确认取舍。

反馈应描述可复现缺陷

反馈需要说明预期行为、实际行为、复现条件和证据，并关联具体版本。

json 
{
  "candidateId": "candidate-17",
  "contractVersion": "order-app-v3",
  "hardChecksPassed": false,
  "findings": [
    {
      "checkId": "date-filter",
      "expected": "exclude orders outside selected range",
      "observed": "one out-of-range order remains",
      "evidenceId": "browser-run-118",
      "reproduction": "fixture B, select 2026-10-01 to 2026-10-07"
    }
  ],
  "suggestedAction": "revise"
}

开发检查返回复现信息；留出集不进入修订反馈，只用于最终验收。反复查看留出错误并据此修改后，它就成了开发集，需要补充新任务。

证据缺失、环境故障和裁判输出格式错误，单列为评估失败。异步报告必须携带候选版本，防止旧结果指导新代码。

何时接受、修订或停止

通过契约就接受；缺陷可修复且预算充足就修订；要求冲突就转人工；预算耗尽或持续无进展就停止。每轮保存最佳有效候选，最后一版未必最好。

flowchart TD A[版本化任务契约] --> B[生成候选] B --> C[执行确定性检查] C --> D{硬条件通过} D -->|否| E[生成有证据的修订反馈] D -->|是| F[校准后的软评分] F --> G{达到接受条件} G -->|是| H[留出验收] H --> I{最终验收通过} I -->|是| J[接受候选] I -->|否| K[报告未接受并重新规划] G -->|否| E E --> L{预算充足且仍有进展} L -->|是| B L -->|否| M[停止并保留最佳有效候选] C --> N[评估故障或契约矛盾] N --> O[升级处理]

连续几轮没有达到约定的最小改善，就进入平台期。必过检查尚未通过时，看阻塞项是否减少；通过后才比较体验评分。平台期用于控制成本，不代表任务无法完成。

预算包含生成、评估、工具、重试和浏览器运行。调用前预留，完成后结算；并发任务共享预算。只数生成 token 会漏算成本。

Go 实践：预算、平台期和最佳候选

下面的 Go 1.23 控制器模拟已完成评估的候选序列。所有成本单位是示例账本单位，不代表模型价格；分数来自合成输入，不是实测性能。

go 
package main

import (
	"fmt"
	"math"
)

type Result struct {
	ID       string
	Valid    bool
	Score    float64
	Cost     int
	Conflict bool
}

type Controller struct {
	Budget      int
	Spent       int
	Patience    int
	Stale       int
	MinGain     float64
	Target      float64
	Best        *Result
	ProgressRef float64
}

func (c *Controller) observe(r Result) (string, error) {
	if r.ID == "" || r.Cost <= 0 || math.IsNaN(r.Score) ||
		math.IsInf(r.Score, 0) || r.Score < 0 || r.Score > 1 {
		return "", fmt.Errorf("invalid evaluation result")
	}
	if c.Spent+r.Cost > c.Budget {
		return "stop:budget", nil
	}
	c.Spent += r.Cost
	if r.Conflict {
		return "escalate:contract", nil
	}
	progress := false
	if r.Valid {
		if c.Best == nil || r.Score > c.Best.Score {
			copy := r
			c.Best = &copy
		}
		if r.Score >= c.ProgressRef+c.MinGain {
			c.ProgressRef = r.Score
			progress = true
		}
		if r.Score >= c.Target {
			return "candidate:heldout", nil
		}
	}
	if progress {
		c.Stale = 0
	} else {
		c.Stale++
	}
	if c.Spent == c.Budget {
		return "stop:budget", nil
	}
	if c.Stale >= c.Patience {
		return "stop:plateau", nil
	}
	return "revise", nil
}

func main() {
	c := Controller{
		Budget: 12, Patience: 2, MinGain: 0.02, Target: 0.9,
	}
	results := []Result{
		{ID: "a", Valid: true, Score: 0.70, Cost: 3},
		{ID: "b", Valid: true, Score: 0.71, Cost: 3},
		{ID: "c", Valid: false, Score: 0.95, Cost: 3},
	}
	for _, r := range results {
		action, err := c.observe(r)
		if err != nil {
			panic(err)
		}
		fmt.Println(r.ID, action)
		if action != "revise" {
			break
		}
	}
	if c.Best != nil {
		fmt.Printf("retained=%s score=%.2f spent=%d\n",
			c.Best.ID, c.Best.Score, c.Spent)
	}
}

运行 go run main.go 得到：

text 
a revise
b revise
c stop:plateau
retained=b score=0.71 spent=9

候选 c 未通过硬检查，不能替换 b。b 改善幅度小，未重置平台期，但仍应保留。进展参考值独立记录，让多次小改善可以累计。

示例处理事后结果。生产调用前还要预留费用，异常、取消和超时后结算。candidate:heldout 只是申请最终验收；停止时保留候选，仍须报告未完成项。

怎样证明反馈有帮助

用独立验收衡量改善，并给无反馈组相同预算，分清缺陷信息与额外推理的作用。

实验组 生成器获得什么 要回答的问题
单次生成 任务契约 起始能力
等预算重采样 契约，无评估反馈 多花预算本身的收益
总分反馈 契约与总分 评分信号是否足够
结构化缺陷反馈 契约与复现证据 定位信息的边际价值
完整闭环 结构化反馈与候选保留 终止和保留策略的作用

在每轮记录开发评分、硬条件通过率、留出通过率、累计成本和回退次数。如果开发评分持续上升而留出质量下降，应检查反馈过拟合、裁判漂移或候选选择偏差。保留最佳版本也需要独立确认，不能在同一套噪声评分上反复选最大值。

Anthropic 的案例中，单 Agent 与完整 Harness 的某些应用示例耗时、费用差别很大，因此不能用截图对比推出等成本提升。受控对照与消融进一步说明如何分离预算、模型与 Harness 的贡献。

人工抽查同时覆盖通过与拒绝，检查误判。实验内固定评分器版本，升级后重新校准。

常见问题

生成器和裁判可以使用同一个模型吗？

可以，但两个角色不自动产生独立错误。相同偏好可能让它们共同忽略问题。使用确定性检查、校准样例和人工分层抽查建立外部证据，而不是把不同系统提示当作独立事实来源。

达到平台期就应该丢弃任务吗？

不应。保存最佳有效候选、未满足条件和成本记录，再决定缩小范围、改变工具或交给人工。平台期说明当前策略没有足够进展，不说明其他策略也无法完成。

裁判应该直接给修复代码吗？

通常先返回缺陷与证据。如果裁判也编写修复，它就同时参与生成，角色边界和实验归因会改变。可以设置独立修复阶段，但最终验收仍应保持分离。

跨会话如何保留闭环状态？

持久保存契约、候选和验收证据，恢复时核对实际产物。具体协议见长任务交接与断点续跑，不能只保存最后一段裁判意见。

参考资料