Laborant Skills — evaluation design for AI systems

Laborant Skills — evaluation design for AI systems

为什么值得关注

Laborant 把“怎么评估一个 AI 系统”做成 agent skill：先检查 live codebase，明确被评估边界，再设计 cases、methods、data sources、scorers、observations、metrics、limitations 和最小实现起点。它的 laborant-designer 不直接写 evaluator code，而是产出 docs/laborant/evaluation-design.md；laborant-probe 则要求用户给出精确 runner locator，并把可回放探针产物写到 .laborant/probes/。

深度判断：值得晋升，因为它补齐了 Agent-Benchmarks 与 External-Agent-Skills-Design-Patterns 之间的空白：很多团队知道“要 eval”，但缺少把 live system 边界、可观察行为、评分方法和限制写成实现前设计文档的工作流。

机制 / 一阶原理

Laborant 的一阶原理是：评测设计必须从可观察边界开始，而不是从流行指标开始。一个 AI 系统的质量 claim 只有在明确 runner、输入、输出、状态、数据、scorer 和限制时才可评估。laborant-probe 强制把证据锚定到 primary runner direct value，避免把 helper logs、judge 输出或偶然日志误当成系统行为。

这与 halu-core-claim-grounded-agent-evaluation 的方向互补：halu-core 更强调 action log 与 final claims 的一致性，Laborant 更强调 eval 设计前的边界与方法选择。对 Hermes 来说，它提示：在自动化 workflow 变复杂前，先写 evaluation design，定义要证明什么、用什么证据证明、哪些结论不能证明。

与现有 wiki 概念的关系

• 对 Agent-Benchmarks：提供从公开 benchmark 到项目本地 eval design 的迁移路径。
• 对 External-Agent-Skills-Design-Patterns：是高质量 skill 的样本，具备触发、产物、边界、限制和 host-agnostic 安装说明。
• 对 Harness-Engineering：把 verifier 从“跑测试”扩展为“设计可证明的观察与评分系统”。
• 对 AI-Self-Improvement-Lab：任何自我优化规则都应先说明评估边界，否则容易把主观反思误作改进。

对 Hermes / llm-wiki 的可执行启发

1. 为 llm-wiki radar 写轻量 eval design：最小指标包括 orient、source access、raw hash、duplicate check、deep criteria、write-record、index/log、reindex、claim receipts。
2. 区分 probe 与 design：今天的 cron 可以探测某来源是否有价值，但不应把一次探测直接变成通用结论。
3. 评测对象要锚定 runner：例如 wiki-vquery 是否检索到新页面，应以真实命令输出为证，而不是“应该可检索”。
4. 限制要写出来：arXiv 429、GitHub rate limit、只读 README 等都影响 confidence，应进入报告与页面。

失败模式 / 边界条件

• Laborant 设计 eval 但不实现 evaluator；如果团队停在设计文档，行为不会自动改善。
• 需要明确 runner locator；对多服务、异步、UI 或人机混合系统，边界定义仍需要人工判断。
• Skill 本身可能建议过多评测维度，带来实施成本；应先选最小可行动指标。
• 今天只学习其 design/probe 模式，未安装技能到 Hermes active profile。

写入记录

• 2026-07-29 09:00 CST：基于 README 深度入库，提炼其对 Hermes / llm-wiki / agentic workflow 的机制启发、边界条件和未安装原因。