agent-">同一Agent框架下四模型实测对比：真实效率藏在过程里

在Agent工程的实践中，一个常见的评测误区是：把模型换掉、把任务固定，然后只看最终截图和总耗时。这种对比看似公平，实际上丢失了最有价值的信息——模型在行动轮数、工具调用、失败恢复和上下文管理上的差异，往往比最终产物更能说明问题。

本文记录了一组控制变量实验：固定同一套Agent执行框架（Harness）、同一任务、同一素材、同一上下文、同一浏览器环境与验收规则，仅替换底层模型，观察四款轻量级模型在复杂任务上的真实表现。实验的目的不是给某个模型排名，而是拆解”Agent效率”这一复合指标到底由哪些因素构成。

一、实验设计：把变量反过来

上一轮实验的思路是固定模型、替换执行框架，用来观察框架层对任务完成度的影响。这一轮把变量反过来：框架固定，模型替换。

参与对比的四款模型均属于轻量级定位（参数量在300B量级以下），分别记为模型A、模型B、模型C和模型D（其中模型D作为横向对照，上下文窗口更大）。四个模型最终都完成了任务，但过程差异显著：

模型	完成情况	总耗时	重试特征
模型A	一次通过	约17分钟	无整轮重跑
模型B	首次失败后重跑	约1小时12分	一轮重跑
模型C	一次通过	约88分钟	内部3次自动重试
模型D	扩展退避后完成	累计约1小时04分	连续失败两次后成功

这组数据的第一层结论很直观：“低成本”或”高速度”的模型定位只能描述能力的一部分。模型A的17分钟与模型C的88分钟，差距不在单次推理速度，而在执行路径的长度与曲折程度。

二、任务设计：为什么选一个”没有参考页面”的任务

实验任务是构建一个创意工作室协作系统，命名为ATELIER。这个任务的设计有几个刻意为之的特点：

输入极简，输出开放。 输入只有6张开放版权图片、项目成员、素材、版本和评论种子数据，没有任何现成页面可以照抄。模型必须自己完成五个状态的设计与实现：项目总览、灵感板（Moodboard）、素材定位评论、版本审批、发布预览。

多角色与多状态耦合。 页面内包含创意总监、设计师、客户三种身份，需要支持素材拖拽、评论定位、版本切换、批准或退回，并且刷新后状态不能丢失。这意味着模型不能只写静态页面，必须处理好状态持久化与角色权限的交叉逻辑。

双端验收。 桌面端检查1440×1000，移动端检查390×844。每组保存首版截图，只允许一轮修复，最后必须留下代码、截图、日志、评审记录和指标数据。

这类任务接近真实业务中的”从零搭建”，对模型的规划能力、工具调用纪律性和上下文保持能力要求很高。也正因如此，它能把模型之间的差异放大出来。

三、过程差异：比截图更有价值的部分

四个模型都交付了可运行的系统，但路径完全不同。

模型A采用了浅色编辑部风格，结构最轻，项目状态、素材和成员关系一眼可读。导航、项目进度、角色、交付、审批和素材画布被组织进一套完整系统，信息密度与工程完成度在四组中最高。它的优势不在于”更聪明”，而在于行动轮数少、工具调用干净——没有多余的试探性操作，上下文没有被无效信息污染。

模型D选择了美术馆档案系统风格，黑色衬线标题、米白底色、细线表格和作品缩略图构成一套克制的工作台。它的特征是默认重试策略过于激进：连续失败两次后才触发扩展退避，最终完成但累计耗时超过一小时。这说明服务稳定性与重试策略对端到端时间的影响，可能大于模型本身的推理能力。

模型B首次执行失败，算上重跑用了一小时十二分。模型C没有整轮重跑，但内部带着3次自动重试执行了88分钟。这两个案例指向同一个问题：失败恢复的成本是隐性的。整轮重跑会丢失上下文、重复工具调用；内部重试虽然保留了上下文，但会拉长单轮执行时间并增加状态不一致的风险。

四、效率拆解：Agent效率的四个构成维度

把这组实验抽象一下，Agent的端到端效率至少由四个维度共同决定：

1. 行动轮数（Action Turns）
模型从任务开始到验收通过所执行的决策轮数。轮数越多，累积的上下文越长，出错概率和token成本同步上升。规划能力强的模型倾向于用更少的轮数覆盖更多状态。

2. 工具调用质量（Tool Call Discipline）
包括调用时机、参数准确性、是否需要重复调用同一工具。工具调用不干净的模型会产生大量”试探—失败—再试探”的循环，这是耗时的主要来源之一。

3. 服务稳定性与重试策略（Stability & Retry Policy）
默认重试次数、退避策略、失败判定阈值都会直接影响总耗时。过于保守的策略导致长时间等待，过于激进的策略导致重复劳动。工程上通常需要根据任务幂等性来配置重试参数。

4. 上下文管理（Context Management）
长任务中，模型需要在不丢失关键约束的前提下压缩历史信息。上下文管理差的模型会在后期”忘记”早期设定的验收规则，导致返工。

可以用一个简化的伪代码表达这种关系：

def agent_efficiency(model, task, harness):
    turns = 0
    context = init_context(task)
    while not task.accepted:
        action = model.plan(context)          # 规划质量影响轮数
        result = harness.execute(action)       # 工具调用质量影响成功率
        if result.failed:
            if harness.retry_policy.exhausted():
                return rerun(task)             # 整轮重跑，成本最高
            continue                           # 内部重试，拉长时间
        context = compress(context, result)    # 上下文管理影响后期稳定性
        turns += 1
    return turns

这段伪代码说明：端到端时间不是模型单次推理延迟的简单累加，而是规划、执行、重试、压缩四个环节的乘积效应。

五、对工程实践的启示

基于这组实验，可以提炼几条对Agent选型与工程配置有直接参考价值的建议：

不要用单一指标选模型。 单次推理速度、单位token成本、基准测试分数都不能单独预测Agent任务表现。更合理的做法是在自己的任务集上做小规模横测，记录轮数、工具调用次数、重试次数和首次成功时间。

把重试策略当作一等配置。 默认重试参数往往是为通用场景设计的，未必适配长任务。对幂等性好的子步骤可以放宽重试，对状态变更类操作应严格限制重试并做好回滚。

控制上下文膨胀。 长任务中应有意识地做上下文压缩，保留验收规则、已确认决策和未完成项，丢弃中间调试信息。这一步做得好，可以显著降低后期返工率。

验收规则要前置且可机器判定。 实验中的截图、日志、评审和指标要求，本质上是把”完成”定义成可检查的条件。规则越明确，模型越不容易在错误方向上走远。

六、结语

这组实验最值得记住的不是”哪个模型最快”，而是：四个模型都完成了同一个复杂任务，但路径长度相差数倍。真实Agent效率是规划能力、工具调用纪律、服务稳定性和上下文管理的联合结果。在选型和工程调优时，只有把过程指标记录下来，才能定位瓶颈究竟在模型、在框架，还是在重试与上下文策略上。

对于构建生产级Agent系统的团队，建议把本文的四维拆解作为评测模板：固定框架与任务，替换模型，记录轮数、工具调用、重试与首次成功时间，用过程数据而不是最终截图来驱动决策。