Jingzhe Xu
7.7 KiB
title, description
| title | description |
|---|---|
| 自我进化 | 由 Skill 编排的 Benchmark 评测与优化闭环：评分、改进、Snapshot 与回滚。 |
PenguinHarness 中的自我进化由 Skill 编排普通的 Agent 机制完成：评测是普通的 Session，优化是普通的文件编辑。创建评测与优化分别运行在两个独立的顶层 Session 中，单次评测通过内置的 run_subagent 工具委托。顶层 Prompt 提供 Agent、Benchmark、能力目标、分数和轮数等本次设定；调用关系、校准、Freeze、协议、重试、回滚和报告格式由 Skill 负责。
角色与调用关系
| 角色 | 职责 |
|---|---|
| Builder | 顶层 Agent，依次直接执行 agent-creation 和 benchmark-design |
| Target Agent | 被改进的 Agent，只在自己的 Workspace 里执行评测任务 |
| Evaluator | run_subagent 创建的叶子 Worker，执行并评分一次 Benchmark Case 运行 |
| Optimizer | 新顶层 Agent，直接执行 agent-optimization |
Builder 和 Optimizer 在各自的顶层 Session 中直接遵循对应 Skill。Evaluator 通过 run_subagent 创建，遵循 agent-evaluation，并通过 Penguin CLI 在绝对路径的隔离 Workspace 中启动指定的 Target Agent。Penguin CLI 在每次请求中启动 Target Agent 完成对应的 Case Run。
两个独立步骤
第一个顶层 Session 创建 Agent 和能力评测。Builder 先使用 agent-creation，再使用 benchmark-design 构建多 Case Benchmark。初版 Cases 可以一次建好并形成完整 Pilot 1；后续每轮可以同时调整多个 Case 或难度维度。评测契约和私有标准必须明确、固定，公开 Statement 则不必唯一决定 Gold。Benchmark 可以通过公开信息不足、冲突信号和固定的私有决策标准形成信息差，只要该标准表达可复用的策略、优先级或推断边界，而且不会根据本次答案改写。
每个新增或修改后的 Case 在首次派发前都要检查 Statement 自洽、Rubric 与当前 Statement 和固定私有标准一致，并确认评分项只依赖已定义、已提供或明确属于私有标准的前提；这不要求公开材料足以复现私有标准。Freeze 前再对所有 Case 完整检查一次。大部分分数应落在目标行为与合理捷径会产生不同结果的决定或简洁产物上，避免格式、证据罗列和分析完整度形成过高的保底分。
每轮校准都要在派发前预测：当前 Trace 中的策略会产生什么结果、期望行为会产生什么不同结果，以及会影响多少分。增加一条模型可以直接执行的公开规则、例外、来源或检查项并不会自动增加难度；如果两种策略仍会得到相同的计分结果，就应选择其他改法。
每个 Pilot iteration 对每个 Case 固定只运行一次。Pilot 分数是期望目标：达到后可以提前 Freeze；未达到时完成设定数量的有效 Pilot iteration，并选择其中分数最低的有效版本 Freeze。Builder 在临时目录只保留当前最低有效版本及其完整结果。最终一致性检查通过后，直接把被选中 Pilot 的单次运行结果记录为 Formal Baseline，不再重新运行或补齐更多 Runs；记录后清理临时副本和校准脚手架。Formal 分数没有达到期望也不会使 Benchmark 作废。
用户确认第一步完成后，在新对话中启动第二个顶层 Session，并指定每个 Candidate、每个 Case 的 runs。Optimizer 先检查 Benchmark 和第一条完整 Formal Baseline，再使用 agent-optimization：
- 通过
run_subagent并行编排 Evaluator，覆盖 Case × 用户指定runs的矩阵； - 根据得分和关联 Trace 提出一个有界 Candidate；
- 编辑 Target Agent 的可编辑状态——
AGENTS.md、Skills、配置——产出版本 N+1； - Evaluation 分数严格提升才保留 Candidate，否则回滚；
- 达到期望分数时提前结束，否则完成本次设定数量的有效 Candidate round，并保留最高分 Reference。
无效评测和修复重跑不计入轮数。出现执行失败时，Optimizer 保持同一个 Candidate，只补齐失败单元；只要还能根据新诊断提出不同的安全修复，就继续尝试。Builder 和 Optimizer 都先验证 Evaluator 的完整响应是否为纯协议 YAML，再读取状态或分数；格式不合规时，由同一个 Evaluator 基于已有结果重发，不重新运行 Target Agent。
每个 Accepted Candidate 立即写入并校验 Scoreboard。Evaluation 分数严格提高决定是否接受；第一次比较允许直接用 Candidate 的多 Run 平均分比较 Formal Baseline 的单 Run 分数，不为 Baseline 补跑。假设是否在预期 Case 上得到支持单独报告，避免把单次运行中的无关波动解释为改动因果。Agent 优化要求 Scoreboard 中已有完整 Formal Baseline——没有基线，就没有可比较的提升。
Benchmark 存储
Benchmark 按 Agent 存放在 benchmarks/<id>/ 下：
benchmarks/<id>/
├── benchmark_config.toml # Benchmark 配置（Builder 的 runs 固定为 1）
├── <case-id>/
│ ├── statement/ # 交给 Target Agent 的任务描述
│ └── rubric/ # 私有评分标准，对 Target Agent 隔离
└── scoreboard.yaml # 当前格式的评测记录
rubric/ 与 statement/ 的隔离是刻意设计：Target Agent 只能看到题面，永远接触不到评分标准。
scoreboard.yaml 中的每条评测记录带时间戳，并记录：
- 本轮 Runtime：用户显式指定的
(provider, model_id)成对值优先，否则继承 Builder Session；thinking_level从 Target Agent 配置读取，不依赖 Trace 元数据； summary_title与summary（本轮结论与下一轮假设）；- 由模型写入的 Score、成本与耗时平均值——Case 级对 Runs 求平均，Evaluation 级对 Cases 求平均；单次 Run 成本保留记录中的原始精度，成本平均值忽略
null，全部未知时才为null；Score 保留两位小数，成本平均值保留六位小数，duration_ms取整； - 每个 Case 的逐次运行明细，每次运行含
score、cost、duration_ms与session_id。
每个 Run 和每个 Case 都固定满分 100，因此 Scoreboard 不再记录 max_score。服务端与 Web UI 直接信任已写入的聚合值，不重算、不交叉校验；旧 Scoreboard 不迁移、不回填。
内置的 default_agent 预置了一个示例 Benchmark（packages/core/src/state/example-benchmark.ts），评测页面开箱即有数据；整个目录可随时删除或替换。
Snapshot 与版本
每轮优化前，Agent State 被打包为 snapshots/v<version>.tar.gz（Vault 除外——密钥永不进入快照）。system_config.yaml 的 version 在优化成功后自增。Web UI 支持导出与导入快照，导入版本不高于当前版本时需要显式确认。
全程可审计
- 每次 Evaluator 运行都是一个普通的 Session，留有完整 Trace；
- scoreboard 记录通过
session_id链接回这些 Session，见 Session 与 Trace； - Web 的评测页面是这些文件的只读视图；折线图只展示 Score，明细表将模型 ID 与推理强度分列显示。见 Web App 指南。
分数不是黑盒输出：任何一个数字都可以回溯到产生它的那次运行。
相关 Skill
| Skill | 用途 |
|---|---|
agent-creation |
把需求变成可用的 Agent：撰写其 AGENTS.md、安装所需 Skill |
benchmark-design |
设计并校准多 Case 的能力 Benchmark |
agent-evaluation |
隔离执行并评分一次 Benchmark Case 运行 |
agent-optimization |
根据 Benchmark 结果改进 Agent |
Skill 的组织与安装方式见技能系统。