在实际的 LLM 应用落地里“模型能解决多少软件工程任务”只是评估的第一层更现实的问题往往是同一批 issue用不同模型、不同 agent 配置、不同推理预算去跑成本和解决率之间存在明显冲突。这种冲突不是简单的“贵一点就强一点”而是会形成一条曲线有些配置花费高但解决率提升有限有些配置成本极低但解决率掉得厉害真正值得保留的只是少数几组折中方案。这条曲线就是 LLM DeepSWE 场景下的 Pareto Frontier也就是帕累托前沿。这篇文章会围绕“LLM 驱动的软件工程智能体如何做多目标评估”展开。先解释为什么只看通过率不够再给出帕累托前沿的定义和适用场景然后搭建一个最小实验环境用 Python 计算前沿点并画出散点图接着讨论如何用前沿做配置选型最后给出常见问题排查和生产环境落地建议。读完以后你可以把同一套方法用在 SWE-bench 类公开任务、企业内部 issue 数据、或者自建的软件工程 agent 评测集上。1. 为什么 SWE 智能体不能只用“通过率”来评估1.1 单指标评估会把问题藏起来DeepSWE 这类系统本质上是大模型驱动的软件工程智能体给它一个仓库、一段 issue 描述让它自动定位问题、修改代码、运行测试并提交补丁。评估这种系统时最常见的做法是统计“修复成功率”或“passk”。这个指标本身没有问题问题在于它只描述了一维效果没有描述成本。设想两个配置配置 A解决率 45%平均每个 issue 花费 2.8 美元 token 成本平均耗时 12 分钟。配置 B解决率 43%平均每个 issue 花费 1.2 美元 token 成本平均耗时 5 分钟。只看解决率A 更优但 B 的解决率只低 2 个百分点成本却少了接近 60%。在批量处理上千个 issue 时B 的总成本可能比 A 低出几千美元。这种权衡在单指标评估里被完全隐藏了。实际项目中还会遇到更复杂的情况。同一个模型开启多轮调试、允许 agent 反复运行测试解决率会上升但 token 消耗和延迟也会同步上升。如果不对这些维度做联合分析就很难回答“当前预算下应该选择哪个配置”“再增加多少预算才能换来一个点位的解决率提升”。1.2 多目标权衡才是真实工程问题LLM 智能体接入生产环境之前团队至少要在几个目标之间做折中解决率希望尽量高。平均成本希望尽量低。平均延迟希望尽量短。稳定性希望多次运行的结果波动尽量小。上下文占用希望显存、序列长度和中间日志量可控。这些目标并不是完全正相关的。提高解决率往往需要更多轮次、更大上下文、更强的模型而这些都会推高成本或延迟。于是评估问题变成了多目标优化问题在相互冲突的目标集合里找出哪些配置是“不可被其他配置全面击败”的这就是帕累托前沿的用途。1.3 从 DeepSWE 到通用评估流程本文说的 DeepSWE泛指“深度软件工程智能体”这一类系统也就是把大模型、工具调用、代码解释器和测试执行器组合起来完成任务的一类 agent。公开的软件工程基准集比如 SWE-bench 这类任务集合可以用来测试这类 agent。使用公开基准时要注意版本和数据划分不同模型的成绩会随测试集版本变化跨版本比较没有意义。更通用的评估流程是准备一组 issue给定若干模型和 agent 配置记录每个配置的解决率、成本、耗时然后计算帕累托前沿。这套流程不依赖某个具体产品适合在评估任何 LLM agent 时复用。2. 帕累托前沿的核心概念与目标定义2.1 支配关系的定义帕累托前沿来自多目标优化。先定义“支配”有两个解 X 和 Y如果 X 在所有目标上都不比 Y 差并且至少在一个目标上严格优于 Y那么 X 支配 Y。对应的英文表达是 X dominates Y。在 SWE 智能体评估里每个配置就是一个解每个指标就是一个目标。如果配置 X 的解决率高于 Y成本低于 Y耗时低于 Y那么 X 支配 YY 就没有保留价值因为 Y 在所有维度上都更差。帕累托最优解集是那些“不被任何其他解支配”的配置集合。把这些解在目标空间中连起来或标出来就是帕累托前沿。用最简单的方式理解单目标优化目标函数一个结果是一个最优值。多目标优化目标函数多个结果通常不是唯一一个点而是一条边界。帕累托前沿这条边界上的点之间存在真正的取舍A 在某项指标上更好B 在另一项指标上更好。评估智能体时帕累托前沿上的点意味着每个点对应的配置都值得单独考虑因为它至少在一个目标上有不可替代的优势。2.2 怎么确定目标方向和单位计算支配关系之前必须明确每个指标是“越大越好”还是“越小越好”。这一步最容易出错方向写反会导致前沿反向得出来的结论完全错误。常见的 SWE 智能体评估指标如下指标目标方向单位说明解决率最大化%在评估集上修复成功的 issue 比例解决数量最大化个固定 issue 集合中成功修复的数量平均 token 成本最小化token 数或美元单个 issue 的平均调用量平均推理成本最小化美元包含模型 API 费用和推理环境成本平均耗时最小化分钟或秒单个 issue 从开始到结束的时间上下文峰值最小化token 数agent 单次运行中最大上下文占用波动性最小化标准差多次运行同一配置的结果波动幅度还需要区分固定成本和可变成本。固定成本包括环境部署、模型权重加载、评估数据准备可变成本是每个 issue 运行过程中产生的 token 和计算费用。分析帕累托前沿时优先使用可变成本因为固定成本只影响总预算不改变配置之间的相对优劣。2.3 为什么直接选“最优点”是伪命题很多人拿到帕累托前沿后第一反应是问“那到底选哪个点”。这个问题在数学上没有唯一答案因为前沿上的每个点都不被其他点支配选择哪一个取决于业务约束。如果团队预算充足要求解决率最大化就选前沿右上角。如果团队预算紧张希望低成本处理海量 issue就选前沿左下角。如果团队想要“性价比”可以定义单位成本解决率再在前沿上找极值。帕累托前沿本身不替你做决策它的作用是缩小候选范围把几十个配置缩减到几个不可相互替代的点然后由人来根据业务约束做最终选择。3. 实验环境与最小工程结构3.1 环境准备分析帕累托前沿不需要训练模型只需要你已经获得了若干配置的评估结果。计算和绘图部分依赖的库很少。建议环境如下依赖版本建议用途Python3.10 以上数据分析主语言NumPy1.24 以上数组与矩阵计算Matplotlib3.7 以上绘制帕累托前沿散点图Pandas2.0 以上可选处理结果表更直观PyYAML6.0 以上读取实验配置文件这不是强制版本生产环境请结合自己的依赖锁定机制确认兼容性。如果原始环境没有这些库用pip install numpy matplotlib pandas pyyaml安装即可。3.2 最小实验目录建议按下面结构组织实验便于结果回溯swe_pareto/ ├── config/ │ └── experiment.yaml ├── data/ │ └── results.json ├── scripts/ │ ├── collect_results.py │ └── plot_pareto.py ├── output/ │ └── pareto_frontier.png └── README.mdconfig/experiment.yaml存放模型与 agent 配置data/results.json存放每个配置的指标汇总scripts/collect_results.py负责从评估结果中聚合指标scripts/plot_pareto.py负责计算前沿并绘图。目录结构本身很简单但能保证实验可复现。不要把所有结果都塞在一个没有版本控制的临时目录里后面对比多个模型版本时会产生大量混乱。3.3 记录实验数据收集结果时每条记录至少包含以下字段{ run_id: 20250101-001, config_name: gpt4o-temp07-retry3, model: gpt-4o, temperature: 0.7, max_retry: 3, max_iterations: 10, issue_count: 120, solved_count: 54, solve_rate: 0.45, total_tokens: 680000, avg_cost_usd: 2.8, avg_duration_min: 12.3, std_duration_min: 4.1 }字段设计时需要注意config_name必须能唯一代表一组参数solved_count与solve_rate同时记录避免混淆评估集大小total_tokens与avg_cost_usd都要存成本单价变化后可以根据 token 重新计算。3.4 成本边界和采样策略每个配置不能只运行一次。LLM 输出有随机性同一个配置跑同一个 issue 集合两次结果的解决率可能差 3 到 5 个百分点。尤其在 issue 数量较少时波动会更明显。建议issue 数量少于 80 时每个配置至少运行 3 次取中位数或均值。issue 数量多于 200 时可以运行 2 次做稳定性验证。报告中标注置信区间或标准差不只看一个点。如果使用采样策略固定随机种子确保可复现。这些做法会让实验时间变长但能避免分析前沿时把噪声当趋势。4. 用 Python 计算并绘制帕累托前沿4.1 准备模拟数据为了演示完整流程先构造一批模拟结果。实际项目中这些数据来自你的 agent 评估脚本。下面的代码生成 30 个随机配置解决率在 0.2 到 0.6 之间平均成本在 0.5 到 5 美元之间。import numpy as np import pandas as pd rng np.random.default_rng(42) n 30 solve_rate rng.uniform(0.20, 0.60, n) avg_cost rng.uniform(0.50, 5.00, n) # 让成本与解决率有一定正相关更接近真实情况 solve_rate solve_rate 0.05 * (avg_cost - avg_cost.mean()) solve_rate np.clip(solve_rate, 0.15, 0.70) df pd.DataFrame({ config_id: [fconfig_{i:02d} for i in range(n)], solve_rate: np.round(solve_rate, 4), avg_cost: np.round(avg_cost, 4), }) print(df.head())这里模拟的只是两个目标解决率最大化、平均成本最小化。你也可以加入延迟、token 用量或上下文峰值代码逻辑不变只要在支配判断里增加维度。4.2 支配关系的实现下面函数接受一个二维数组solutions和每个维度的方向maximize返回布尔掩码标记哪些点是帕累托最优。import numpy as np from typing import List def pareto_optimal_mask( solutions: np.ndarray, maximize: List[bool] ) - np.ndarray: n, m solutions.shape is_optimal np.ones(n, dtypebool) for i in range(n): for j in range(n): if i j: continue dominates True strictly_better False for k in range(m): a solutions[i, k] b solutions[j, k] if maximize[k]: better a b worse a b else: better a b worse a b if worse: dominates False break if better: strictly_better True if dominates and strictly_better: is_optimal[i] False break return is_optimal核心逻辑是遍历每一对配置判断配置j是否支配配置i。如果j在所有目标上都不差于i并且至少在一个目标上严格优于i那么i被支配i就不是帕累托最优。这里要注意“相等”的处理。如果两个配置所有指标完全相同它们互不支配都算帕累托点。工程技术上完全相同的指标通常基于相同或非常接近的配置需要检查是否产生了重复实验。调用方式如下solutions df[[solve_rate, avg_cost]].to_numpy() mask pareto_optimal_mask(solutions, maximize[True, False]) frontier df[mask] print(frontier)maximize列表中的True表示该列最大化更好False表示该列最小化更好。所以解决率是True成本是False。4.3 绘制帕累托前沿拿到前沿点后用 Matplotlib 绘制散点图。普通点用浅色帕累托前沿点用深色并加圆环标记。import matplotlib.pyplot as plt plt.figure(figsize(9, 6)) plt.scatter( df[avg_cost], df[solve_rate], c#9aa5b1, labelAll Configurations, alpha0.6 ) plt.scatter( frontier[avg_cost], frontier[solve_rate], facecolorsnone, edgecolors#d64545, s120, linewidths2, labelPareto Frontier ) # 按成本升序绘制前沿连线便于观察趋势 sorted_frontier frontier.sort_values(avg_cost) plt.plot( sorted_frontier[avg_cost], sorted_frontier[solve_rate], linestyle--, color#d64545, alpha0.4, linewidth1 ) plt.xlabel(Average Cost per Issue (USD)) plt.ylabel(Solve Rate) plt.title(LLM SWE Agent Configuration Pareto Frontier) plt.legend() plt.grid(alpha0.3) plt.tight_layout() plt.savefig(output/pareto_frontier.png, dpi150) plt.show()画图只是辅助理解真正的判断来自pareto_optimal_mask的结果。图上的前沿连线仅为视觉参考表示随着成本增加最优解决率的提升趋势并不是实际可用的连续配置。4.4 解读结果运行后你会看到类似下面的输出config_idsolve_rateavg_cost是否前沿config_050.280.62是config_120.391.10是config_180.472.05是config_230.533.40是config_270.614.80是这些前沿点的含义是当成本在 0.62 美元时最高能达到的解决率是 28%当成本提升到 1.10 美元最高解决率变成 39%再继续增加到 2.05 美元解决率是 47%。前沿给出了“每个成本档位下解决率的上限”。不在前沿上的配置要么被低成本高解决率配置支配要么被同解决率更低成本配置支配直接丢弃即可。5. 如何用前沿做配置选型5.1 常见可调参数及影响SWE 智能体配置中会影响帕累托点位置的参数主要有五类参数调大后的收益调大后的代价常见坑模型规格解决率通常上升成本和延迟明显上升高端模型在简单 issue 上浪费成本推理温度 temperature探索行为增加可能跳出局部错误输出随机性增大稳定性下降温度过高导致低效重试最大迭代次数 max_iterations解决复杂 issue 的成功率提升token 消耗和耗时非线性增长简单 issue 也被拖长最大重试次数 max_retry对偶发错误更鲁棒成本和延迟成倍增加重试不改变策略时只是重复同样错误上下文截断策略避免长上下文溢出可能丢失关键调试信息截断后 agent 无法定位问题根因工具调用集合支持的调试手段更多每轮调用开销增加失败分支变多工具过多时 agent 出现选择困难这些参数可以组合出非常多配置。实际项目中不需要穷举全部组合先用低档、中档、高档三组参数跑一轮找到大致前沿位置再在前沿附近做细粒度搜索。5.2 三种选型策略选定最终配置时有三种常见策略。第一种是成本约束优先。先设一个单 issue 成本上限比如 1.5 美元然后在该约束下选择解决率最高的前沿点。这个方法适合批量处理大量 issue 的场景能保证总预算不超。第二种是解决率优先。先设定最低解决率比如 50%然后选择满足该条件且成本最低的前沿点。这个方法适合 issue 影响大、修复失败代价高的场景。第三种是按“单位解决率成本”选点。计算公式是avg_cost / solve_rate代表提升一个百分点解决率需要多少成本。这个指标不是绝对的因为解决率和成本的关系不是线性但它能帮助你在前沿上快速找到性价比拐点。frontier frontier.copy() frontier[cost_per_solve_point] frontier[avg_cost] / (frontier[solve_rate] * 100) print(frontier.sort_values(cost_per_solve_point))输出后检查最小值的相邻点确认是否处于“再加一点成本解决率提升已经很小”的拐点位置。5.3 把前沿判断接入回归测试不要把帕累托前沿分析当成一次性工作。当模型版本升级、API 价格调整、评估数据集变化时前沿会移动。建议把分析流程做成脚本定期重跑。具体做法将pareto_optimal_mask和画图脚本放到 CI 任务中。每次新模型版本或新配置自动生成新前沿。与上一次前沿对比检查是否出现“局部倒退”即某成本区间内解决率明显下降。如果发现倒退需要定位是模型变化、提示词变化还是评估集变化。这样可以尽早发现上线新模型带来的全局效果而不是等线上事故出现后再排查。6. 常见问题与排查6.1 前沿点非常多几乎没有筛选效果现象完整配置表打印出来大部分点都是前沿点无法指导选型。可能原因指标数量过多比如同时比较解决率、成本、延迟、上下文、响应长度五个维度。离散度太小多个配置指标非常接近。数据噪声大同一个配置的不同 run 之间差异超过了配置之间的差异。检查方式打印不同配置的指标分布计算每个指标的标准差用两个核心指标先画图看散点是否集中在一条窄带内。处理建议先降到两个或三个业务核心指标。增加 epsilon 容忍允许“近似支配”也就是配置 j 比配置 i 在每个维度都差不到某个阈值时不认为 j 被支配。6.2 目标方向写反前沿变成“最差前沿”现象画出来的前沿点在右下角或左上角直观上像是成本最高、解决率最低的点。可能原因maximize参数写反。解决率被标成False成本被标成True支配关系完全颠倒。检查方式print(solutions[:3]) print(pareto_optimal_mask(solutions, maximize[True, False]))手动取两个点按定义验证支配方向。比如配置 A 解决率 0.5、成本 1 美元配置 B 解决率 0.4、成本 2 美元A 明显支配 B但函数如果返回 B 是前沿而 A 不是说明方向写反了。处理建议在脚本里加入断言用两个构造的配置做单元测试防止方向错误影响后续分析。6.3 结果波动导致前沿不稳定现象同一份代码、同一组配置隔一天重跑前沿点变化很大。可能原因LLM 输出随机、评估集大小不足、API 版本变化、缓存未清理。检查方式对每个配置多次运行计算解决率的标准差检查是否复用了上一次运行的缓存确认 API 温度参数是否一致。处理建议单配置多 run 取中位数评估集不足时增加 issue 数量或使用 bootstrap 采样获得置信区间固定随机种子并在实验记录中写入模型版本和 API 版本。6.4 成本只算了 token漏算延迟和失败重试现象帕累托前沿显示某个配置成本极低但实际生产运行中成本高得多。可能原因只统计了成功调用的 token没有统计超时重试、失败请求、工具执行时间没有包含 GPU 实例或 API 并发成本。检查方式检查成本字段是否来自最终汇总而不是单次成功调用的计费核对失败请求的日志确认是否包含最大重试次数内的所有调用。处理建议成本指标avg_cost统计单个 issue 从开始到结束的全部费用包括失败请求和重试。在结果表里同时记录success_count和failed_count便于核算。问题现象常见原因检查方式处理建议前沿点过多指标维度多或噪声大输出指标标准差降维或引入 epsilon 支配前沿画反最大化最小化方向写错构造已知点验证单测 断言前沿不稳定运行次数少或评估集小多次运行看方差取中位数增加样本量成本指标偏低漏算失败请求和重试检查计费日志统计完整生命周期费用7. 生产环境落地建议7.1 配置外置化与实验追踪分析帕累托前沿时一定要让每一行结果都能追溯到具体配置。建议把配置和结果分开记录用run_id关联。experiment.yaml示例environment: model: gpt-4o prompt_version: 20250101 api_base: internal-gateway evaluation_set: swe_bench_subset_120 agent: temperature: 0.7 max_retry: 3 max_iterations: 10 use_rag: true use_mcp_tools: true每个配置改动的参数要单独记录不要只记录一个“最终版本”。否则半个月后再看数据你无法知道前沿上的某个点到底开了哪些工具、用了哪个提示词版本。在生产环境中实验数据建议落到数据库而不是只存在 JSON 文件。每次运行插入一行字段包括run_id、config_json、result_json、created_at、git_commit。这样后续对比模型时可以直接用 SQL 聚合。7.2 避免评测集污染帕累托前沿分析结果只在“评估集可信”的前提下有效。如果 agent 已经见过评估集里的 issue前沿会整体偏高选型结果不可靠。生产环境中要注意评估集与训练集、开发集严格分离。使用公开基准时记录具体版本和日期不要混用不同版本。企业内部评估集定期更新避免 agent 从在线日志中学习到答案。如果引入 RAG 检索必须确保检索库不包含评估集答案片段。7.3 性能、日志与监控实际项目中影响帕累托点位置的因素还包括推理精度和运行资源。部分推理环境会使用半精度 FP16 或 BF16 来降低显存占用但同一模型在不同精度下的输出可能轻微不同从而影响解决率和成本评估。生产环境中建议统一记录推理精度FP16、BF16、FP32。推理框架版本和量化配置。上下文窗口上限和实际峰值。缓存命中率如果做了语义缓存成本会下降但要区分是否影响解决率。日志至少包含每个 issue 的模型输出、工具调用序列、token 统计和最终结果。没有这些日志前沿上的异常点无法回溯。7.4 发布前检查清单在把新的 agent 配置推上线之前按下面清单检查是否在固定评估集上与旧配置同步计算帕累托前沿是否多次运行并记录了离散度是否记录模型版本、提示词版本、工具版本和推理精度是否确认成本指标包含失败重试、超时和工具调用是否确认评估集没有污染是否设置了成本上限和并发限制是否配置了日志脱敏避免把敏感代码和凭据写入日志是否准备好回滚方案例如保留旧配置的入口开关是否在前沿对比中确认新配置没有在某个成本区间出现局部倒退这份清单不是形式化的流程检查而是把分析结论变成可维护的生产配置的关键步骤。帕累托前沿分析的价值不在于找到一个唯一的最优配置而在于把“解决率”和“成本”这类冲突目标显式地摆出来。日常开发中与其反复争论哪个模型更好不如把数据和前沿图画出来让业务预算和解决率要求共同决定最终选择。随着模型版本更新和 API 价格调整前沿会不断移动建议把这套评估脚本固化为团队常规工具每换一次模型、每调一次价格都重新计算一遍。这样LLM SWE 智能体的选型才能从“感觉更强”变成“数据可比较”。