科技Bestblogs·字节跳动技术团队··AI 生成
让改进有迹可循：Storage Agent Family Eval 工程实践
字节跳动存储团队公开了其 Storage Agent Family 评测体系：用 LLM+Code 双层评估器覆盖任务、行为与安全，结合 Trace 调用链定位失分到具体 Skill/工具，并将线上真实工单脱敏回灌评测集。EBS Agent 一个版本就从综合分 88.7 提到 95.1，任务完成度从 55.4 跳到 92.2。适合做 Agent 落地的工程团队参考其评测与回归方法论。原文 ↗原文 ↗
核心观点
- ▍云存储 Agent 的质量评估必须同时覆盖任务完成度、数据真实性和操作安全边界，单看回答文本无法判断其是否选对工具与执行路径。
- ▍建立「离线回归 + Trace 归因 + 线上问题回流」的闭环，是让 Agent 每次改动可量化、可追溯、可持续进化的核心工程手段。
- 01评测集从用户意图、Skill 链路和边界条件三个维度设计，覆盖不同任务类型、工具调用路径和越权/异常操作场景。
- 02评估器分两层：LLM 评估器从任务理解、事实依据、任务完成度、能力边界与操作安全、表达清晰度五个维度打分；Code 评估器做程序化断言验证。
- 03依靠评测工作台、云端隔离沙箱和 TLS AgentLoop 协同，每次 Agent 改动都跑一遍回归，结果可对比、可存档。
- 04通过 Trace 调用链把失分定位到知识库、Skill、CLI 工具或执行框架四个层级中的具体一处，再针对性修复。
- 05EBS Agent 一轮版本迭代后综合得分从 88.7 提升到 95.1（+6.4），任务完成度从 55.4 提升到 92.2，说明瓶颈主要不在知识而在执行链路。
- 06线上真实用户会话和典型运维工单经筛选、去重、脱敏后回灌评测集，作为下一轮回归的新鲜样本。
反方 / 局限
- — 文章承认 LLM 评估器本身存在主观性与偏差，因此需与 Code 评估器结合使用，但未给出两者评分冲突时的裁决机制或一致性数据。
- — 线上问题回流的筛选标准（何为「典型」工单）与去重脱敏流程只有概述，未展开，样本偏差对评测集代表性的影响未被讨论。
- — 评测集与分数提升均来自字节自家存储业务场景，迁移到其他领域 Agent 时评估器和安全边界是否同样适用，文章未做外部验证。
概念锚点
前置背景
论证骨架
平行视角
未来推演
延伸追问