基准测试还不够：RAMP——生产系统中智能体模型的运行时评估

TL;DR RAMP 以编译器构建等长周期生产任务为场景，通过运行时评估揭示智能体在真实工作流中的系统性能力退化与失效传播，推动评估从静态基准向持续、可观测的生产化度量转变。

问题

随着大语言模型（LLM）在软件开发中的自主性不断增强，其能力已从简单代码补全延伸到复杂的多阶段软件工程任务。然而，现有评估方法仍以静态、短时的孤立基准测试为主，与真实生产系统中的长周期、有状态、多工具交互的工作流严重脱节。

目前主流的代码代理评估（如 HumanEval、MBPP、SWE-bench）通常将任务封装为独立、一次性生成的场景，仅通过简单测试用例检查输出正确性。这些基准忽略了：

• 序列依赖：实际工程任务往往由多个连续步骤组成，前一步的输出是后一步的输入，错误会沿着工作流传播。
• 工具链交互：代理需要在编译、测试、版本控制等异构工具间切换，基准测试很少包含这些复杂交互。
• 执行反馈循环：代理应能根据运行时错误、测试失败等反馈进行迭代修复，而静态基准不支持闭环评估。
• 资源效率：传统指标仅关注最终结果，不衡量计算成本或过程效率，无法区分“偶尔猜对”与“稳定推理”的差异。
• 故障恢复：缺乏对部分失败下代理行为的考查，不能反映真实场景下的稳健性。 因此，基准性能高并不保证代理能在长链条生产任务中持续有效。

构建能真实反映生产级代理能力的评估体系面临多重技术挑战：

• 需要可复现的、包含长期状态和依赖的长周期工作负载；
• 必须提供统一的运行时接口，以屏蔽不同模型和扩展框架的差异，保证评估的公平与可比性；
• 指标设计需同时覆盖 结果质量 与 过程效率，并具备细粒度故障分类能力；
• 评估成本受限于大规模多阶段任务中模型调用与工具交互的开销，难以规模化部署。

随着越来越多工业级代理被用于代码生成、测试、部署等核心环节，生产环境的可靠性需求迫切要求从“静态基准”转向“生产接地运行时评估”。缺乏此类评估将导致能力误判与部署风险。

这类似于自动驾驶安全评估：仅靠封闭测试场的简单场景通过率，无法预测真实道路中复杂交通流下的行为；必须引入 长里程、有交互、含意外故障 的运行监测，才能衡量系统的真正鲁棒性。

核心洞察

• 静态基准测试严重高估了 LLM agent 在生产系统中的实际能力。RAMP 通过编译器构建这样的真实长时间跨度、串行依赖工作负载，发现模型在孤立即时任务中表现良好（初始阶段 100% 完成），但随着工作流推进，完成率崩溃至 20%，且无一模型完成整个流水线。这揭示了当前评估范式的根本缺陷：缺乏对执行链、工具交互和失败传播的动态观测，导致基准分数与实际生产可行性之间出现巨大鸿沟。
• 串行工作流中的失败传播和资源效率差异是被严重低估的评估维度。RAMP 引入的分阶段恢复机制和进程效率指标，不仅量化了单点失败如何随依赖关系放大，还发现同类模型的计算成本差距可达三个数量级。这突破了传统“只看最终结果”的评估思维，强调在持续自主开发场景下，故障韧性、资源消耗和过程质量等运行时属性是决定智能体能否落地的关键，为后续评估框架设计提供了全新的效用导向范式。

方法

输入：序列化编译器构建任务与模型智能体

RAMP 接收来自 YatCC 平台的编译器构建工作负载，将完整的软件工程生命周期拆解为 T0 到 T5 六个串行依赖的实现任务（词法分析、语法分析、语义分析、代码生成、优化等）。每个阶段的任务描述、起始代码库、测试用例以及工具链配置作为输入，交由目标 LLM 智能体（通过统一接口接入，支持 GPT、Claude、DeepSeek 等不同后端与 Agent SDK）自主完成代码修改、工具调用与测试验证。

关键模块：分层运行时架构与长时程工作负载

1. 评估框架三层结构

• 智能体运行时层（Agentic Runtime Layer）：提供标准化的编排接口，屏蔽不同模型提供者与智能体框架的差异，统一发起任务、传递环境状态并收集执行轨迹。
• 环境支持层（Environment Support Layer）：基于容器技术为每个任务创建隔离、可复现的运行环境，管理编译器工具链、依赖包与文件系统。
• 执行与观察层（Execution and Observation Layer）：实时捕获智能体的 Shell 命令、代码编辑、测试输出及错误信息，形成完整的交互日志用于后续分析。

2. 长时程工作负载设计

• 串行进化（Serial Evolution）：任务 T0 至 T5 存在严格的前后依赖，前一阶段的代码产物自动成为下一阶段的起点，模型必须在不断增长的代码基上递进开发，模拟真实项目的累积复杂度。
• 复活协议（Resurrection Protocol）：当模型在某一阶段失败时，RAMP 会注入一个“专家修复”的基线版本作为后续阶段的起点，允许评估继续。这一机制同时用于分析 失败传播：观测前序错误是否在后续阶段引发级联故障，以及模型在给定正确上下文后能否恢复推进。
• 执行模式：支持全自主模式（模型从头完成所有阶段）与部分复活模式，灵活对比不同条件下的能力边界。

3. 多维指标体系

• 结果指标：各阶段任务完成率、最终通过测试比例。
• 过程指标：Token 消耗、API 调用次数、墙钟时间、工具调用频率等，量化过程效率。
• 失败分类：将错误归类为语法错误、语义错误、工具误用、无限循环等，构建细粒度画像。
• 整体效用（Overall Utility）：综合结果质量与过程成本的加权评分，用于横向对比不同模型的生产实用性。

输出：运行时评估报告与能力图谱

RAMP 最终生成每个模型的阶段完成矩阵、过程效率曲线、失败传播路径图及整体效用分数，揭示其在高保真生产环境下的真实能力退化——例如任务完成率从首阶段的 100% 逐阶段崩溃至末阶段的 20%，无模型能通关全部管线。这些结果通过 Leaderboard 公开。

与 SWE-bench 等静态、单任务基准相比，RAMP 将评估重心从隔离补丁正确性转向 连续开发过程中的可观测运行时行为，首次系统量化了串行依赖导致的失败传播与资源效率悬殊（同水平模型计算成本相差三个数量级），推动 Agent 评估走向生产接地。

实验

实验设计

RAMP 框架基于 YatCC 生产级平台，构造了 编译器构造任务序列 T0–T5 ，每个任务均有串行依赖 和复杂的工具链交互。评估涵盖 15 个主流 LLM 代理模型 ，通过标准化编排接口统一接入，工作负载设计包含分阶段恢复机制 ，可分析部分失败下的执行行为。评估指标覆盖结果质量 （任务完成率）和过程效率 （计算成本、失败类型）。

关键发现

• 任务完成率随阶段急剧下滑 ：T0 阶段完成率 100%，至 T5 骤降至仅 20% 。
• 零模型 能完成整个流水线，暴露出当前代理模型在持续多阶段开发中的实际瓶颈。
• 计算成本差异最高达 三个数量级 （千倍），表明资源效率存在严重不均衡。
• 失败传播呈系统性，多数模型在早期失败后无法有效恢复。

与静态基准的对比

传统评估基准（如 HumanEval、MBPP）通常在孤立、短视界 任务上给出高分数，但 RAMP 的运行时评估显示这些分数 与实际生产能力严重脱钩 。在引入长期依赖、真实工具链和恢复要求后，模型的“能见度”大幅下降，这揭示了持续、可观测的运行时评估 对于软件工程代理走向生产落地的必要性。

行业影响

落地场景

RAMP 面向生产级长周期软件工程 Agent 的持续评估，适用于需要 Agent 自主完成跨日甚至跨周开发任务的场景，例如：

• 自动化 CI/CD 管道：针对微服务架构的全局重构、跨仓库依赖升级等长任务，评估 Agent 在多阶段串行工作流下的稳定性与任务完成率。
• SaaS 平台的智能开发助手：类似 GitHub Copilot Workspace 或 GitLab Duo 的生产环境，监控 Agent 在真实代码库中的行为退化与资源效率。
• 合规审计与自动化修复：在金融、医疗等强监管行业，验证 Agent 是否能在遗留系统改造中按顺序完成一系列代码合规任务并定位失败传播链。

商业价值

• 降低线上事故成本：RAMP 暴露模型在静态基准中不可见的能力退化（如任务完成率从 100% 骤降至 20%），帮助团队在引入 Agent 前量化真实风险，避免直接面对生产故障。
• 优化资源分配：通过多维指标（结果质量 + 过程效率）发现同类模型在计算成本上可能相差 三个数量级，企业可据此筛选出性价比最高的 Agent 后端，大幅节省 API 调用或自托管 GPU 成本。
• 提升开发体验与交付速度：对 Agent 进行运行时可观察的评估，使团队能信任 Agent 承担更多日常维护任务，研发人员转而聚焦高价值创新。

与现有产品 / 工作流的接口

RAMP 提供标准化编排与执行接口，可集成进企业现有 DevOps 工具链：

1. 作为 CI 质量门禁：在 GitHub Actions 或 Jenkins 中增加 ramp-evaluation 步骤，对 Agent 生成的代码变更运行 RAMP 的编译器构建任务与恢复协议，输出失败分类与效率分数，阻断未达标的 PR。
2. 与 Agent SDK 解耦：通过统一接口支持多种 LLM 提供商和 Agent 框架，企业可保留现有技术选型（如 LangChain、AutoGen），仅需实现 RAMP 的环境观测器即可接入评估。

具体落地 Use Case

• 全球电商平台的多仓库依赖升级：某电商平台计划让 Agent 自动将 Node.js 后端 100+ 个微服务从 Express 迁移至 Fastify。使用 RAMP 对候选模型（GPT-4o、Claude Sonnet 等）进行长阶段串行任务评估，发现仅 1 款模型在第四阶段后仍保持 60% 完成率，从而选择该模型并设定自动回滚策略，避免全量迁移中断。
• 自动驾驶软件中间件的安全补丁传播：某自动驾驶公司需要定期将底层的实时操作系统补丁应用到多个硬件抽象层，且必须按顺序编译并测试。RAMP 的串行依赖与复活协议可模拟补丁失败时的恢复过程，筛选出能处理依赖冲突与工具链错误的 Agent，确保安全关键软件的更新可靠性。

局限

• **任务覆盖面受限**：RAMP 目前仅基于编译器构建（YatCC）工作负载评估 agent，尽管该类任务具备长链、工具依赖、多阶段等生产特征，但所有评估结论均无法直接泛化到其他典型生产场景（如微服务开发、数据管道、基础设施运维），其工作负载设计能否迁移到多样性任务尚需验证。
• **平台强绑定**：框架深度集成 YatCC 统一平台，标准编排与执行接口虽支持异构 LLM 与 agent SDK，但整套评估管线（环境管理、任务定义、恢复协议）高度依赖 YatCC 内部实现，外部系统适配成本高，难以快速复用到非 YatCC 构建的生产环境中，限制了其作为通用评估标准的可推广性。
• **模型覆盖与可复现性**：15 个主流模型虽涵盖多个家族与规模，但未包含与企业内部定制、领域微调模型的对比；此外评估中的推理成本、失败案例日志未完全开放，计算资源与随机种子等影响复现的关键配置描述不足，可能导致他人重复评估时结果波动，削弱基准的长期可比性。