lvlitup808-ship-it/10-agent-evals

# 给 AI 工程师的 10 个 Agent Evals **结合用法进行说明。**

灵感来自 [@hanakoxbt](https://x.com/hanakoxbt/status/2079692306337153079)。 ## 10 个 Evals ### 1. Golden Set（黄金测试集） **一组你绝不会修改的固定用例，在每次改动时都会运行。** 将其作为基准，告诉你是否有任何变动。 - 保留 20–50 个代表真实失败模式的高价值用例。 - 一旦锁定，绝不修改（或谨慎地进行版本控制）。 - 这是你的“金丝雀”。如果 Golden set 得分下降，立即停止发布。 ### 2. LLM as Judge **由第二个模型根据书面评分标准对输出进行打分。** 当答案是开放式的，且没有特定字符串可以进行匹配时使用。 - 编写清晰的评分标准（正确性、有用性、语气、安全性等）。 - 优先使用结构化 JSON 输出作为评判结果。 - 始终定期使用人工标签来校准 LLM Judge。 ### 3. Rubric Scoring（评分标准打分） **每个维度一个分数：正确性、语气、安全性、成本。** 当单一总分掩盖了究竟是哪一部分真正变差时使用。 - 将评估拆解为正交的维度。 - 随时间追踪每个维度，以便回归问题能够被诊断。 - 对于生产环境的 Agent 来说，成本是一等公民。 ### 4. Trajectory Eval（轨迹评估） **对 Agent 采取的路径进行评分，而不仅仅是它最终得出的答案。** 当“出于错误的原因得出了正确答案”会在日后给你带来麻烦时使用。 - 检查 tool call 序列、中间推理过程以及从错误中的恢复情况。 - 捕获在分布偏移下会失败的“碰巧”成功。 - 对于多步骤的 Agent（剪辑、研究、编码、运维）尤为关键。 ### 5. Tool Unit Tests（工具单元测试） **单独测试每个工具，使用 fixtures，且模型不参与其中。** 总是使用。大多数 Agent 的 Bug 都是披着伪装的工具 Bug。 - 使用 fixtures + 对输入/输出进行确定性断言。 - Mock 外部 API。 - 这应该是你的评估金字塔中最快、最便宜的层级。 ### 6. Regression Suite（回归测试套件） **使用新的 prompt 或模型重放过去的运行过程，并对比结果。** 在每次 prompt 变更前使用，因为 prompt 没有类型系统。 - 存储生产环境（或高质量）运行的完整轨迹。 - 对比最终答案 + 中间步骤。 - 立即暴露“以前能正常运行”的失败。 ### 7. A/B in Prod（生产环境 A/B 测试） **将实时流量在两个版本之间进行拆分，并比较结果，而不是凭感觉。** 当离线分数无法预测用户的实际行为时使用。 - 定义明确的成功指标（任务完成率、用户满意度、延迟、成本）。 - 统计显著性很重要。 - 迅速淘汰表现较差的版本。 ### 8. Human Review（人工审查） **抽样一部分运行记录，并让人诚实地对它们进行评分。** 用于校准你的 LLM Judge，因为无人检查的评判器会悄无声息地发生偏移。 - 如果能坚持执行，5–10% 的抽样通常就足够了。 - 用它来改进评分标准，并发现自动化评分器的盲点。 - 高风险领域需要更多的人工覆盖。 ### 9. Shadow Run（影子运行） **候选版本在真实流量上并行运行，其输出不向任何人展示。** 在存在风险的发布之前使用，此时一个糟糕的答案将导致高昂代价。 - 记录影子输出 + 并与线上生产环境进行对比。 - 非常适合用于测试新模型、新工具或重大的 prompt 重写。 - 对用户零影响，同时实现最大化学习。 ### 10. Red Team（红队测试） **故意攻击它：越狱、注入、数据窃取、工具滥用。** 在外部任何人能够接触到它之前使用，而不是之后。 - Prompt 注入、tool call 注入、数据窃取尝试、资源耗尽。 - 尽可能自动化，同时保留富有创造力的人工红队测试。 - 将安全视为评估套件的一部分，而不是一项单独的活动。 ## 推荐的评估金字塔（适用于大多数团队） 1. **Tool unit tests**（工具单元测试）（始终保持开启，应用于每个 PR） 2. **Golden set + Regression suite**（黄金测试集 + 回归测试套件）（每次改动时运行） 3. **Trajectory + Rubric / LLM-as-judge**（轨迹评估 + 评分标准 / LLM-as-judge）（每天夜间或重大变更时运行） 4. **Shadow + A/B**（影子运行 + A/B 测试）（在生产环境发布前运行） 5. **Human review + Red team**（人工审查 + 红队测试）（持续进行 + 启动前运行） 从能够捕获*你上一次故障*的那两个评估开始。在需要之前，其他所有评估都是可选的。 ## 为什么这对于多 Agent 与实时系统很重要 如果你正在构建直播剪辑工具、自主内容 Agent、NIL 情报系统，或任何链式调用工具与决策的 Agent： - Tool unit tests 能够捕获静默失败（空 JSON、错误的 schema、速率限制）。 - Trajectory evals 能够捕获“由于正确的原因剪辑了错误的时刻”这类 Bug。 - Shadow runs 允许你在真实直播流上测试新的剪辑启发式算法或模型，而不会发布糟糕的剪辑片段。 - 包含已知高价值时刻的 Golden sets 将成为你的回归安全保障。 ## 快速入门指南 ``` # 您可以采用的示例结构 evals/ golden/ cases.json # locked test cases tools/ test_tools.py # pure unit tests trajectories/ store/ # past successful + failed runs judges/ rubric.md llm_judge.py redteam/ attacks/ ``` 首先构建最便宜、最具确定性的层级。只有当昂贵的/随机性的层级能为你带来有效信号时，才添加它们。 **收藏这篇内容。使用它。** 原贴 + 可视化图文：[X 上的 hanakoxbt](https://x.com/hanakoxbt/status/2079692306337153079)

标签：AI智能体, C2, Homebrew安装, LLM评测, 人工智能, 工程实践指南, 模型评估, 用户模式Hook绕过, 逆向工具