如何让你的Agent自动打分？launch-your-agent的Outcome评分循环完全实战指南

为什么你的 Agent 需要"自动打分"？

很多新手在搭 Agent 时都有一个痛点：Agent 干完活，到底算不算"做好了"？如果每次都要人肉盯着、逐条检查，那 Agent 就只是一个"更贵的聊天框"，而不是一个可以托付的自动 worker。

launch-your-agent正是为解决这个问题而生的一个 Claude Code skill：它跑在Claude Managed Agents（CMA）上，带你从想法一路做到上线——访谈需求、划定 v0 范围、在你自己的账号里发布 Agent、按你定义的"完成标准"自动打分（Outcome 评分循环）、迭代改进，最后把合格的任务挂上定时部署。

其中最值得新手重点学会的，就是Outcome 评分循环：任务 + 评分标准（rubric）+ 迭代上限（max_iterations）三件套，交给 CMA 托管的独立评分器（grader），Agent 做完 → 打分 → 不通过自动重做，全程不用你手动打分。

Outcome 评分循环：Agent、评委和迭代上限

把 Outcome 循环想象成"学生写作业、老师批改"的闭环：

三个关键设计值得新手记住：

1. 评委是独立上下文的。grader 由系统自动配置，运行在与 Agent 隔离的上下文窗口里，不受 Agent"自我感觉良好"的影响——这就是它敢自动停下来的底气。
2. 评分结论会驱动下一轮。grader 返回的"不通过 + 解释"会直接反馈给 Agent，作为新一轮迭代的输入。
3. 每个 Session 同时只跑一个 Outcome，但可以串接：上一个 Outcome 结束后再下发新的。

这个循环在 cma-primitives.md 的 "Outcomes" 一节有完整机制说明，是理解自动打分的"原理手册"。

三步搭出你的自动打分 Agent

完整流程由 skill 的四个阶段驱动（访谈 → 搭建发布 → 评分迭代 → 无人值守运行），自动打分发生在第三阶段"Grade, iterate, eval"，见 SKILL.md：

第 1 步：定义任务 + 写好评分细则（rubric）

访谈阶段（见 interview.md）会追问一句很关键的话："什么叫'做好了'？具体一点，你会检查什么？"

答案会被收敛成 3–6 条二元评分项，例如：

• 输出是一个 markdown 文件
• 恰好列出 5 条最重要信息
• 每条都带来源链接
• 每条附一句"为什么重要"的说明
• 无臆造事实

好 rubric 的三个要点：

• 每条都能独立判定通过或不通过。模糊的条目（"写得不错"）会导致评分结果不稳定；
• 从过往的优秀案例反推——如果你有历史上的"好答案"，官方文档明确建议从它身上提炼评分标准；
• rubric 放在任务开场（kickoff）里，而不是系统提示词里。这个位置的小差别，换来的是：以后想调严标准，改一下 rubric 重跑即可，不用给 Agent 升版本，迭代成本几乎为零。

第 2 步：一键下发 Outcome，Agent 自动开工

skill 创建 Session 后，会用一个user.define_outcome事件把任务描述 + rubric +max_iterations一次性下发（命令形态可参考 cma-api.md 的 "Kickoff events" 一节）。

Agent 收到后立即开工，产出文件统一写到会话输出目录；每轮结束后 grader 自动评分，结论以outcome_evaluations[]的形式记录在 Session 上，随时可查、可审计。

第 3 步：看结论，按规则迭代

运行结束后，skill 会先读评分器的结论（result + explanation），再把 Agent 的产出和 rubric 逐条对照成一张"标准 | 结论 | 证据"的评分表，然后一次只改一处：

记住一句话：第一次跑不完美是预期结果——"评分 → 迭代 → 再评分"本身就是这个 skill 想教给你的核心能力。

读懂 5 种评分结论（verdict）

每次评分结束后，系统会给出一个结论，含义各不相同：

想实时盯盘，可以流式监听span.outcome_evaluation_start / _ongoing / _end事件，或者直接轮询 Session 接口读取outcome_evaluations[].result；在 Console（platform.claude.com → Managed Agents）里也能直接看到会话时间线和评分历史。

黄金测试集：让 Agent 稳定下来

单次跑通只是开始。skill 的做法是把你的真实历史案例变成回归测试集：

• 你有 2–5 个"已知正确答案"的旧案例 → 留 1 个作为 v0 的启动输入，其余扣住（held back），等 Agent 版本跑通 rubric 后，逐案例各开一个 Session、固定同一 Agent 版本重跑，收集结论与成本；
• 只有 1 个优秀成品 → 从它反推 rubric，拿它当首次评分的参照物；
• 有真实输入但没有标准答案 → 你本人就是评分器：首轮人工逐条判分，把判断沉淀成更锐利的 rubric 条目，喂给第二轮；
• 完全没有历史数据 → 关闭会话时，把当天验证通过的输出保存为evals/case-01的期望结果——它就是未来所有新版本的回归基线。

这一步的价值在于防回归：每次升级 Agent（v2、v3…）之前重跑黄金测试集、对比新旧版本的结论，就能抓出"修好了一个案例，却弄坏了另一个"的情况。这也是为什么 skill 会要求：把新版本 Agent 部署上线前，先重跑一遍 evals。

新手最常踩的 6 个坑

1. max_iterations开太大。默认 3 就够了，只有任务确实难啃、且单次运行成本（美分级）可接受时，才往 5–10 调，上限 20。
2. 把 rubric 写进系统提示词。后面想调标准就得给 Agent 升版本，白白增加成本。
3. 一次改多处。改完不知道是哪处生效，调试直接乱套——坚持"一次只改一处"。
4. 评分项含糊。"写得清晰"无法判定；改成"每条不超过 200 字"才可靠。
5. 跳过保留测试案例。只有一个案例跑通就宣布完成，换一批输入可能立刻翻车。
6. 上线前不重跑黄金集。部署到定时任务（scheduled deployment）之前，先重跑 evals，别让"修 A 坏 B"的版本静默运行。

收尾：从"会打分"到"无人值守"

当某个 Agent 版本稳定通过评分循环后，skill 的第四阶段就接上了：重复性任务直接创建定时部署（cron + 时区 +initial_events原样重放每次运行），先手动触发一次验证，再放心交给 cron。

到这里，你的 Agent 就真正具备了 worker 的形态：自己干活、自己接受打分、不达标自己返工、按钟表定期运行。

关键文件速查

上手方式：克隆仓库后进入目录启动 Claude Code，输入/launch-your-agent触发整个流程；完成后输入/wrap-up做收尾复盘。你的第一个"会自己接受打分"的 Agent，就是从这里开始的。