2026-11-04 00:10:30 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

让改进有迹可循：Storage Agent Family Eval 工程实践

原创

火山引擎存储
火山引擎存储

字节跳动技术团队

2026年11月3日 18:00
北京

去阅读

我们在上一篇文章《Storage Agent Family: Agent 时代，重构云存储的“人机交互”》中，介绍了云存储智能助手家族Storage Agent Family——一组部署在云端的智能助手，可以帮助用户查询云存储资源配置、估算扩容成本、排查访问故障等。实际生产环境中，用户需要它们准确理解意图、查清真实资源状态、调用合适工具，并在安全边界内完成任务。

但问题也随之而来。为让 Agent 更好用，团队会不断修改提示词（Prompt）、技能（Skill）、命令行工具（CLI）和底层执行框架（Harness）。这些模块环环相扣，改一处往往牵动全局：今天修好 A 场景，明天可能就破坏原本正常的 B 场景。如果上线前只靠人工随意测试几句，或只看最终回答是否通顺，既难以判断改动是否产生副作用，又难以在出现问题时定位卡在哪一步。

为此，我们围绕 Storage Agent Family 建立了一套持续评测与改进机制：通过离线回归实验检验每次改动后的回答与工具调用过程，结合调用链（Trace）定位具体模块的问题，再将线上真实对话中暴露的典型问题持续沉淀至评测集。这样，每次版本改动的效果都清晰可量化，既能在发版前及时拦截场景退化，也能推动多款存储 Agent 的任务完成率与回答准确率持续提升。

01 |如何构建覆盖任务、行为和安全的评测体系

先看一个日常高频场景。用户给出目标云盘 ID，向块存储智能助手（EBS Agent）提问：“我想给指定云盘在原有大小的基础上再扩容 100 GiB 可以吗？扩容后我每个月要多花多少钱？”

要给出可靠答案，Agent 需先调用只读工具查清该云盘现有的容量、类型和计费方式，再核对扩容上限规则，并调用询价接口计算差价。

除此之外，遇到异常或高风险情况还需严格把关：例如用户未提供云盘 ID 时会先追问；工具未查到数据时不能编造价格；涉及修改配置的操作需先识别风险并请用户确认（只读场景下仅提供操作指引）；删除资源、越权访问这类高危请求则直接拒绝。

可以看到，即使是一句简单的日常提问，背后也同时考验意图理解、工具调用与安全边界。因此在准备评测集时，业务团队会先理清 Agent 的能力边界，再从两个维度设计测试题：既关注用户通常如何提问（用户意图），也关注底层会调用哪些技能和工具（Skill 链路），以覆盖完整的执行路径。

举个例子，针对“访问失败排查”这类常见问题，评测集里不仅有查网络、查权限、查流控这些正常排障流程，还会专门放进一批“难题”——如故意不提供资源 ID、模拟工具报错，或要求直接修改线上配置、越权删除资源。

这样，评测集既检查任务能否完成，也检查遇到异常或越界请求时，Agent 的响应是否符合预期。

存储 Agent 评测集结构：按用户意图、Skill 链路与边界条件组织

当评测集同时考察“任务完成”“数据真实”与“操作安全”时，只看回答是否通顺，或只给出一个笼统的总分远远不够。例如，在上述扩容询价场景中，如果 Agent 回答流畅，却忽略已知的云盘 ID、也没有查询真实云盘规格，表面看回答不错，实际上却并没有完成任务。

为此，评测采用LLM 评估器与 Code 评估器相结合的方式：前者围绕任务理解与回应聚焦、事实依据与可信度、任务完成度、能力边界与操作安全、表达清晰度与可行动性五个维度，评估语义与过程质量（涉及报表生成任务时，额外评估报告质量）；后者通过代码与正则规则，直接检查空回答、运行报错、工具调用约束等可程序化验证的行为。

当然，由大模型评估也可能出现误判。因此，团队会定期使用人工标注样本校对评估器的打分结果，对存在争议的评分进行人工复核，持续提升自动打分与实际业务判断的一致性。

存储 Agent 评估器职责分工：LLM 评估器与 Code 评估器

评测集与评估器就绪后，每当研发团队为优化某类场景修改提示词、技能、工具或执行框架时，需让待测版本跑一遍这些任务，来检验这次改动是带来正向提升，还是引发退化。

02 |如何让每次 Agent 改动都有据可查

日常迭代中，团队依托自研评测工作台开展离线回归实验，持续验证每次改动的效果。

整体架构上，回归实验由三个角色协同完成：评测工作台负责版本与基线管理、实验分片调度、Code 评估器规则校验、红线判定与版本对比；云端隔离沙箱负责并发运行完整的待测 Agent，产出真实回答、报表与结构化调用记录；火山引擎日志服务 TLS AgentLoop 负责 Trace 调用链与 Session 会话分析、LLM 多维评估打分及线上会话质量分析，并将得分与调用链证据回传至评测工作台。

评测工作台、云端隔离沙箱与 TLS AgentLoop 协同关系

2.1 准备可追溯实验并在隔离沙箱中运行

团队先将代码、提示词、技能和工具打包为一个待测版本，再选择评测集与运行环境。任务会自动保留对应的评测集快照、评估器版本和评分配置，使实验结果可追溯到具体条件。

评测集与运行环境确定后，评测工作台将核心任务与边界用例分配到云端隔离沙箱，并发运行完整的 Agent 流程——让它实际走完“理解问题、选择技能、调用 CLI 工具、处理返回结果并生成回答或报告”的全过程。

如需对比新旧两个版本，平台会自动核对双方的题库版本、评估器版本、评分配置和运行环境，确保二者在同一基准下进行对比。

2.2 采集运行轨迹并结合双层规则评分

沙箱运行结束后，系统收集每道题的实际回答、原始 Trace 和生成的报告；同时，将问题、预期结果与行为约束、实际回答，以及从 Trace 中提取的结构化工具调用记录写入 TLS AgentLoop 评测集进行打分。完整的原始 Trace 则单独归档保存，供后续排查细节时随时调取。由于“沙箱运行”与“评估打分”相互独立，后续调整评分规则时，直接基于已保存的运行结果重评即可，无需重跑沙箱。

评分时，许多云存储任务依赖实时的云资源状态，因此评估器会结合测试环境当时的真实资源数据、工具调用记录与最终结论来综合评分。

不同业务可按需配置 LLM 评估器与 Code 评估器的权重及通过门槛；其中安全红线与核心完成度均实行一票否决制，任意一项不达标即直接判为“未通过”。

TLS AgentLoop 评测集数据项（上）与 LLM 评估器按维度打分（下）

2.3 查看评测报告与版本对比

以块存储 EBS Agent 的一轮版本迭代为例，在包含 124 道用例的回归实验中，综合得分由 88.7 分提升至 95.1 分（+6.4），通过用例数由 104 道增加到 122 道。

与综合得分变化相比，更值得关注的是任务完成度，由 55.4 分提升至 92.2 分。逐题对比显示，多道此前未通过的题目，在新版中都能主动调用工具查清配置并给出完整结论。

版本对比总览：综合得分由 88.7 提升至 95.1，任务完成度由 55.4 提升至 92.2

03 |如何从一次失分定位到具体的 Skill 问题

评测报告和对比总览能够直观指出哪些任务表现不足、哪些维度发生变化。但要将分数差异转化为有效的研发改进，团队还需沿着未通过的题目回溯实际执行过程：当时 Agent 在沙箱中执行了什么？问题究竟来自知识库、Skill、CLI 工具，还是执行框架？

3.1 下钻到单题评分、版本对比与 Trace 调用链

回到前文提到的EBS Agent云盘扩容与计费咨询题（“我想给指定云盘在原有大小的基础上再扩容 100 GiB 可以吗？扩容后我每个月要多花多少钱？”）。在该测试场景中，用户已在上下文中提供目标云盘 ID，且 Agent 具备查询云盘配置和调用询价接口的只读权限。

但在旧版本的回归实验中，此题被判为“未通过”，任务完成度为 0 分。查看单题评分详情与 Trace 调用链发现：旧版 Agent 忽略已有的云盘 ID，未主动调用工具查询目标云盘的现有配置，而是直接把问题抛回用户，要求用户手动提供本可通过只读工具查到的云盘容量、类型和计费方式。

通过对该题 Bad Case 的评分理由与 Trace 记录进行归因分析，团队定位到问题是源于 Skill 拆解指引缺失，随即在对应 Skill 中补齐调用链路要求：先通过只读工具核查目标云盘现有配置，再结合扩容规则与询价接口测算费用。

修改完成后重新发起回归实验，通过单题并排对比视图与“查看 Trace”中可以清晰看到变化：新版 Agent 依次完成边界判断、提交执行计划、激活技能、读取目标云盘对应的扩容规则并核验容量上限，随后在沙箱中通过 ebs-cli 实查该云盘的现有配置（1024 GiB ESSD\_FlexPL），再根据该云盘的按量计费模式调用 CalculatePriceV2 获取扩容前后的小时单价并估算月度费用差额，在不触发任何写操作的前提下给出完整结论。

该题由此从“未通过”转为“通过”，任务完成度由 0 分提升至 100 分（任务理解 95 分、事实依据 95 分、能力边界 100 分、表达清晰度 95 分，Code 评估器各项检查全部通过），并与同批修复的其他题目一起使整轮实验的任务完成度由 55.4 分提升至 92.2 分。

EBS 云盘扩容题前后版本变化摘要、任务完成度对比与关联 Trace 调用链详情

3.2 用可观测链路定位知识、Skill、CLI 与 Harness 问题

无论是在回归实验中排查失分原因，还是在日常运行中分析异常会话，TLS AgentLoop 的观测看板、会话分析（Session）和调用链视图（Trace & Span，用于记录一次请求中各次模型推理与工具调用的层级、参数与耗时）都提供完整的执行记录。研发人员可逐层核对输入消息、检索结果、工具调用参数及返回信息，定位具体原因后，再针对性修复对应模块：

知识或检索问题：知识文档缺失或未检索到产品规格、错误码与排障步骤，导致回答缺依据 → 由业务团队补充知识文档或调整检索策略。
Skill 或 CLI 工具问题：任务拆解指引不清，或 CLI 工具返回信息不完整、报错提示难定位 → 调整 Skill 提示词或优化 CLI 工具的参数与返回格式。
执行框架（Harness）问题：上下文管理、会话状态传递或安全围栏拦截异常 → 在公共执行底座统一修复。

另外，如果只盯着固定的测试题修改代码，很容易变成“背题应试”。因此团队修复 Bad Case 时有一条硬性要求：必须修改通用的 Skill 逻辑、工具接口或补充知识库，不能专门针对某道题写死提示词，同时还会用不同问法的变体题和线上真实对话进行交叉验证。

04 |如何让真实用户问题持续推动 Agent 进化

离线回归评测能帮助团队在上线前守住基本盘，但固定的评测集很难穷尽千变万化的真实提问。Agent 进入实际使用后，还需结合真实用户会话持续评估任务质量。

围绕线上真实数据，评估重点覆盖四个方面：用户的任务是否完成、结论是否有依据、多轮交互是否有效、是否出现不必要的拒答或越界行为。运行耗时和工具报错提供基础监控信息，人工抽检与自动评估则进一步判断任务质量。

在线上评估中，我们采用“人工标注校准、LLM 评估扩面”的方式推进：先由业务与 QA 抽样复核真实会话、校准评估器标准，再通过 LLM 评估器扩大线上质量检查的覆盖范围。

线上评估不仅直接检验真实使用场景的质量，也让团队能够持续积累日常暴露的真实问题。结合当前实践与持续建设机制，经确认的线上异常会话与典型运维工单，在指导知识、Skill、CLI 和 Harness 修复的同时，再经筛选、去重、隐私脱敏和业务复核（补充预期结果与测试条件）后，作为新增样本回流至评测集，进入下一轮回归实验。