在线与离线两条腿

Online Eval 是告警信号不是验收判据，Offline Eval 才是「改动是否真的改进了」的证据，两者靠 ADLC 飞轮咬合。

Online Eval 是告警信号，不是验收判据。把生产 trace 的评分当成「这次改动有没有变好」的证据，是 Agent 团队最常犯的误判：它能告诉你分数跌了，但回答不了改动是否真的改进了。要回答后者只有 Offline Eval。两套都必须建，中间靠飞轮咬合。

两类 Eval 回答两个不同的问题

只建一套的后果是确定的：只有 Online，分数跌了你无法在受控条件下验证修复；只有 Offline，数据集会慢慢与生产分布脱节，评测全绿而线上在退化。

ADLC 飞轮

生产 trace + 负面用户反馈 + reviewer 在标注队列里改写过的响应 → 下一版测试集 → Offline Eval 验证改动 → 部署 → 产生新 trace。其中人工 reviewer 改写过的响应是最值得沉淀的 golden 数据行。

飞轮有一条硬约束：不能只用合成数据跑 Eval。合成场景极少与真实复杂场景一致，只用合成数据，Agent 只会处理「想象的问题」。飞轮要转起来，真实失败必须先进入测试集。

LLM-as-judge 只做分诊，不做裁判

人的注意力是瓶颈，任何规模的团队都撑不住大量人工 review；但 LLM judge 不校准则不可信。可行分工是分诊：清晰、低风险的 case 自动处理；低置信、judge 之间冲突、高影响的 case 路由给人审。同时要定期抽样高置信 case 查系统性错误——全交给模型只看通过率，等于放弃校准的机会。追踪 judge 与人的分歧率，judge prompt 本身也要版本化并接受评估。

原则一句话：人类帮设计和校准自动 evaluator，而不是手动 review 大量输出。langchain-human-judgment

在线还要测 Keep Rate 和用户语义反应

延迟、Token 效率、工具调用次数、缓存命中率只测趋势，回答不了「agent 真把事做好了吗」。Cursor 补了两个在线指标：cursor-agent-harness

• Keep Rate：agent 提出的代码变更在固定时间后仍留在用户代码库里的比例。保留率低说明用户手动改了或继续让 agent 修，初始质量低。
• 用户语义反应：用 LLM 读用户对 agent 初始输出的回应判断是否满意——进入下一个功能请求是完成的强信号，粘一段堆栈跟踪是没完成。

这两个指标的价值落在一个具体决策上：Cursor 据此搁置了「用更贵模型做上下文摘要」的想法，对质量改善微乎其微，不值这个成本。公开基准只能近似真实使用，全依赖它会漏掉这类信号。

自进化的纪律

当飞轮推进到自动修改规则文件（SKILL.md / agent.md / 规则集），适用前提只有一条：任务输出能被客观判定对错。在此前提下有几条不可省：

• 只有「结果错误 × 流程异常」的交集才触发修改，同一根因覆盖足够比例（如 ≥30%）失败 case 才动手。结果正确但流程有瑕疵的不改。
• 四层 Gate：Target（目标 case 至少 1 个变好）→ Guardrail（原通过 case 零回归，回归的惩罚权重数倍于「未改善」）→ Holdout（隔离集周期抽查，F1 劣化超阈值即拒）→ Verify（规则文件本身的文本质量）。
• 数据三分割：Selection 参与诊断 / Holdout 只做泛化监控 / Golden 人工审定且永不参与进化。修改方看得到测试答案就是背答案。
• taboo 黑名单：被拒修改的签名（根因 + diff hash）跨版本、跨分支共享，回滚不清空，生成新修改时注入作负面约束；单次 diff 限行数，便于定位回归。
• 进化收益必须在等 Token 预算下度量：Best-of-N、重试取优带来的提升只是多花钱，不是进化。

阿里自进化 SKILL.md 的实测印证了这套纪律：诊断全部用确定性规则（如「声称执行了步骤但 session 无证据」「同参数重复调用 ≥3 次」），LLM 只把诊断结论转写成候选 diff——实测让 LLM 直接判断 skill 质量接近随机水平。三个模型在 63 个 case 上的通过率：Kimi 77.8%→84.1%、GLM 77.8%→88.9%、DeepSeek 82.5%→87.3%。同一项目还记下一个数字：判定词从「漏洞」换成「风险」，准确率 89.3%→62.1%。alibaba-skill-evol