统一框架横评四款轻量模型：17分钟与85次重试

01 评测背景：这次把控制变量反过来

上一轮实验的思路是“固定模型、替换执行框架”：用同一个模型分别跑四套不同的Agent执行框架，验证框架层设计对交付效率的影响，结果其中一个一体化框架以16分55秒完成了当时最复杂的任务。这一次，我们把变量彻底反过来——四组实验全部使用同一个统一的Agent执行框架，任务、素材、上下文、浏览器操作方式与验收规则完全一致，只替换底层大模型。

被测对象是四款300B参数量级以下的轻量模型，下文统一记为模型A（具备视觉输入能力）、模型B、模型C、模型D（主打长上下文）。选择这个参数量级段是有意为之：它们都处在“低成本、高速度”的定位区间，是团队在大规模自动化任务中最可能批量选用的类型，也因此最值得放到真实链路里检验——宣传口径里的“便宜”和“快”，在端到端交付中到底意味着什么。

先给结论：四个模型最终都完成了任务，但过程差异远比最终截图更有价值。最快的17分钟一次通过；最波折的累计重试85次，到首次成功耗时超过1小时。这组数据直接回答了本文的核心问题：模型定位只能描述一部分能力，真实的Agent效率由行动轮数、工具调用成功率、服务稳定性和上下文管理共同决定。

本文适合的读者：正在做模型选型的技术负责人、搭建Agent自动化工作流的工程师、需要评估“换模型成本”的平台团队。你能从文中带走三样东西：一套可复用的控制变量评测设计、一张多维度结果解读表、一份标注了适用边界的选型建议。

02 评测目标：要回答的四个可验证问题

评测不是简单判断“哪个模型好”，而是回答四个可观察、可复核的问题：

• 一次通过率：在无人工干预的前提下，模型能否一次性满足全部验收规则。这个指标直接决定该模型能否进入无人值守的自动化流水线。
• 端到端效率：从任务下达到交付完整产物（代码、截图、日志、评审记录、指标文件）的墙钟时长。注意它不是“首token延迟”，而是包含所有轮次、重试与等待的总成本。
• 重试与容错成本：失败发生在哪一层——整轮失败、工具调用失败还是服务请求失败？重试策略如何放大时间与token消耗？
• 交付质量：在功能完整、交互可用之外，视觉风格、信息架构与跨端一致性达到了什么水平。

核心假设是：模型定位（低成本/高速度）只能描述一部分能力。两个墙钟时长相差数倍的模型，可能对应完全不同的失败层级和重试结构，而这些差异在传统的单轮问答基准测试中完全不可见。

03 评测任务与环境：把所有变量钉死

任务是一个创意工作室协作系统，难度被刻意设置在“无法照抄”的水平。

输入条件：

• 6张公开博物馆开放版权图片作为素材；
• 项目成员、素材、版本、评论四类种子数据；
• 没有任何现成页面可参考，五个状态——项目总览、情绪板、素材定位评论、版本审批、发布预览——全部由模型自行设计并实现。

功能与角色约束：

• 创意总监、设计师、客户三种身份，权限各不相同；
• 必须支持素材拖拽、评论定位到图片坐标、版本切换、批准或退回；
• 刷新页面后所有状态不能丢失。

统一执行条件（四组完全一致）：

• 同一执行框架、同一系统提示词与工具集；
• 统一262K上下文窗口、200K任务预算；
• 统一通过浏览器自动化工具完成页面操作与验证；
• 桌面端按1440×1000检查，移动端按390×844检查；
• 每组保存首版截图，只允许一轮修复；
• 最终必须交付代码、截图、日志、评审记录与指标文件五类产物。

这套设计的价值在于：当环境、任务、预算、验收全部固定后，结果差异只能归因于模型本身——包括它的规划习惯、工具调用方式、错误处理策略，以及其背后推理服务的稳定性。值得一提的是，上一轮实验中同一框架配合模型A曾以16分55秒完成该任务，本次模型A跑出17分钟，与历史记录基本吻合，侧面说明评测环境具备可复现性。

04 评测维度设计

维度	观察点	验证方式
功能完整性	五个状态、三种角色权限、四类交互、状态持久化	逐状态验收 + 刷新复测
一次通过率	是否零人工干预完成	首版截图与日志比对
端到端效率	墙钟时长、行动轮数、工具调用次数	框架统一日志统计
稳定性	重试次数、失败层级、恢复方式	服务端调用记录分析
交付质量	视觉统一性、信息架构、跨端一致性	双视口截图走查
可观测性	五类交付物是否齐备、日志能否复盘	交付物清单核验

05 结果总览：四条完全不同的路径

代号	参数量级	首次执行	重试行为	首次成功耗时
模型A（多模态）	<300B	一次通过	无	约17分钟
模型B	<300B	整轮失败	重跑1轮	约1小时12分
模型C	<300B	完成	无整轮重跑，内部自动重试3次	约88分钟
模型D（长上下文）	<300B	完成	默认重试连续失败2次后进入扩展退避，累计重试85次	约1小时04分

模型A：17分钟，一次通过。 全程无重试，交付浅色编辑部风格页面，结构最轻，项目状态、素材与成员关系一眼可读。它的路径说明：当任务描述足够清晰、验收规则机器可判时，轻量多模态模型完全有能力独立承担从设计到实现的全链路。

模型B：首跑失败，重跑后1小时12分。 失败发生在整轮层面，意味着此前所有轮次的token全部沉没。重跑后交付质量突出：黑金与米白配色、衬线标题、权限矩阵与审批状态形成统一的博物馆编辑风，横向对比中品牌感与移动端一致性最为突出。

模型C：88分钟，失败在内部被消化。 没有整轮重跑，3次失败全部通过框架内的自动重试在单步内解决。交付深色专业工作台，导航、项目进度、角色、交付、审批与素材画布纳入同一套系统，信息密度与工程完成度在四组中最高。

模型D：1小时04分，重试85次。 默认重试策略连续失败两次后进入扩展退避，全程累计重试达85次。最终交付美术馆档案系统风格：黑色衬线标题、米白底色、细线表格与作品缩略图，呈现档案化的排版气质。85次重试是本次最有信息量的数据——它揭示的往往不是“不会做题”，而是链路层的稳定性问题。

06 差异归因：效率差距从哪里来

• 行动轮数：Agent任务的墙钟时长约等于“轮数 × 单轮时延”。有的模型倾向一次性输出大块实现，有的拆成大量小步反复验证。轮数越多，累计时延与token消耗越大，出错面也随之扩大。
• 工具调用成功率：浏览器自动化对选择器定位、元素等待、坐标点击的精度高度敏感。调用失败触发重试，重试又消耗轮次。模型D的85次重试大概率集中在这一层——可能是输出格式与工具协议契合度不足，也可能是高频调用下的服务抖动。
• 服务稳定性：轻量模型通常共享推理资源，高峰期的限流、超时、长上下文下的解码不稳定，都会转嫁为Agent层的重试。模型B的整轮失败与模型D的连续失败，更可能指向服务层而非能力层。
• 重试策略设计：框架级整轮重跑最昂贵（一切重来）；工具级自动重试把失败消化在单步内（模型C的方式）；指数退避适合服务端压力场景但显著拉长墙钟（模型D）。三种策略无绝对优劣，但模型行为特征必须与框架重试策略匹配。
• 上下文管理：88分钟以上的任务意味着上下文中累积了大量工具输出。历史压缩策略、错误信息是否保留、关键状态是否被摘要掉，直接影响后续决策质量，也是长任务“越跑越偏”的常见根因。

07 结果解读与适用场景

• 快速原型与演示：优先看一次通过率与墙钟时长。模型A路径证明轻量模型可以胜任“从零到可演示”的完整交付。
• 高完成度交付：优先看信息密度、工程完成度与跨端一致性。愿意用时长换质量时，模型B、C路径的成品感更高，1小时量级的耗时是可接受的对价。
• 规模化自动化流水线：85次重试在单任务里只是故事，在批量任务里会被放大为显著的调用成本与队列积压。此类场景必须把重试率、失败分布作为一等指标压测验证，并将退避策略纳入SLO与容量规划。
• 成本核算：除token计费外，重试、重跑、退避等待都是隐性成本。建议同时记录“有效token与总消耗token的比值”——比值越低，链路浪费越大。

08 风险与评测边界

• 单任务样本：一个创意协作系统代表不了全部任务形态，本结论不可外推为模型综合排名；
• 评价主观性：视觉风格判断含主观成分，可靠的做法是只记录可核验的结构性观察（状态覆盖、刷新持久、跨端一致）；
• 时段波动：服务稳定性随时段变化，建议同一任务至少跨三个时段重复并取中位数；
• 框架耦合：结论绑定当前框架的提示词、工具集与重试策略，更换框架后排序可能反转——这正是上一轮“固定模型换框架”实验的结论；
• 泛化验证：应再选一类结构不同的任务（如数据管道、接口联调类）做交叉验证后再下选型结论。

09 可复用的评测清单与记录结构

执行清单：

1. 固定框架版本、系统提示词、工具集与验收规则；
2. 固定上下文窗口与任务预算；
3. 记录首版结果，禁止中途人工修正；
4. 只允许一轮修复，修复前后各留截图；
5. 归档代码、截图、日志、评审记录、metrics五类交付物；
6. 同一任务多时段重复，取中位数；
7. 交叉第二类任务验证泛化性。

评测记录结构（示意）：

{
  "eval_id": "agent-model-swap-001",
  "harness": "unified-agent-framework@fixed",
  "model_alias": "model-a",
  "constraints": {
    "context_window": 262144,
    "task_budget": 200000,
    "viewport_desktop": "1440x1000",
    "viewport_mobile": "390x844",
    "fix_rounds_allowed": 1
  },
  "metrics": {
    "first_pass": true,
    "wall_clock_min": 17,
    "action_rounds": "<由日志统计>",
    "tool_call_count": "<由日志统计>",
    "retry_count": 0,
    "retry_level": "none"
  },
  "artifacts": ["code", "screenshots", "logs", "review", "metrics"]
}

工程落地层面，若你在百度智能云这类同时提供模型服务与监控体系的云平台上开展同类评测，可以直接复用平台侧的调用日志与指标导出能力，把重试次数、失败分布、token消耗沉淀为可复查的评测档案，显著减少手工统计带来的误差。

10 总结

本次评测把执行框架、任务与验收全部固定，只替换四款300B参数量级以下的轻量模型，得到四条截然不同的交付路径：17分钟一次通过、重跑后1小时12分、内部消化3次失败的88分钟、累计重试85次的1小时04分。核心结论有三条：

1. 模型定位只描述一部分能力，“轻量、高速”的卡片参数无法预测端到端Agent表现；
2. 真实Agent效率取决于链路工程质量——行动轮数、工具调用成功率、服务稳定性与上下文管理，共同决定了17分钟与1小时之间的差距，这本质上不是“聪明程度”的差距；
3. 选型必须在自有任务上实测，用固定变量的横评方法记录重试结构与失败层级，同时明确结论的适用边界：单任务、单框架、特定时段的观察，只能作为决策输入之一，而非终局答案。