跑分骗了你：我用三个真实场景，测出了开源与闭源模型的真实断层

"它在榜上排第三，但它把我的 Agent 搞崩了三次。"

这句话是我上个月在一个 AI 工程师群里看到的。发帖的人刚把公司的 AI 工作流从 GPT-4o 切换到某个跑分接近的开源模型——为了省成本。结果上线第一周，Agent 任务失败率飙升，日志里全是幻觉式的"成功"回调，但实际上什么都没做完。

他后来补了一句："跑分真的是个谎言。"

我深有同感。但"感觉差"不够，我想知道差在哪里、差多少、什么时候差得要命、什么时候差得可以接受。于是我设计了一套测试，不用 MMLU，不用 HumanEval，用的是一条最小完整工作链：写 Prompt → Agent 判断 → 异常处理。

这篇文章是测试结果。

---

第一章：为什么跑分是个美丽的谎言

宾夕法尼亚大学教授 Ethan Mollick 曾在推文中指出一个反直觉的现象：

"Benchmarks measure performance on isolated tasks. Real work is a chain. A model that scores 90% on each step doesn't give you 90% overall—it gives you 0.9^n, where n is the number of steps."

翻译过来：如果一个模型在每个单点任务上准确率是 90%，五步链式任务的整体成功率就跌到 59%，十步就跌到 35%。

这不是数学游戏，这是真实 AI 工作流的死亡方程式。

跑分测的是单点。它告诉你这匹马百米跑了 10.5 秒，但没告诉你它能不能跑完马拉松。更糟糕的是，当你把两匹马的百米成绩放在一起——10.5 秒 vs 10.8 秒——你会觉得差距微乎其微。但 42 公里之后，一匹站在终点，另一匹不知道在哪里。

这就是我为什么不信跑分，转而设计链式测试的原因。

---

第二章：测试设计——我为什么选这三个场景

真实的 AI 工作流，无论多复杂，都可以拆解成三个最小单元：

1. 意图理解与 Prompt 生成：把模糊的人类需求转化成可执行的指令

2. 多步推理与工具调用：Agent 在信息不完整的情况下做判断和行动

3. 异常处理与优雅降级：当环境出错时，模型如何应对

任何一环掉链子，整个任务就崩。这三个场景不是我随便选的——它们是 Agent 系统的最小可信单元。

• 闭源代表：GPT-4o、Claude Sonnet 4.6
• 开源代表：Llama 3.1 70B、Qwen2.5 72B、DeepSeek-V3

测试环境：统一通过 API 调用，温度参数 temperature=0.3，系统 Prompt 保持最简（只说明角色，不做额外约束），每个场景各跑 20 次取平均。

⚠️ 诚实说明：样本量 20 次偏小，结论具有参考价值但不代表统计显著性。我会在文末开放测试代码，欢迎自行扩大样本验证。

---

第三章：场景一「写 Prompt」——开源模型的第一道裂缝

测试设计

给定一个模糊需求，让模型自动生成一个可用的 Prompt：

用户输入：
"帮我写一个 Prompt，让 AI 帮我分析竞品。"

就这一句话，没有更多上下文。

测试代码（可复现）

import openai

client = openai.OpenAI(
api_key="your_api_key",
base_url="https://api.884819.xyz/v1"  # 支持本文所有模型
)

def test_prompt_generation(model_name: str, user_input: str) -> str:
response = client.chat.completions.create(
model=model_name,
temperature=0.3,
messages=[
{"role": "system", "content": "你是一个 Prompt 工程专家。"},
{"role": "user", "content": user_input}
]
)
return response.choices[0].message.content

user_request = "帮我写一个 Prompt，让 AI 帮我分析竞品。"

models = ["gpt-4o", "claude-sonnet-4-6", "llama-3.1-70b",
"qwen2.5-72b", "deepseek-v3"]

for model in models:
result = test_prompt_generation(model, user_request)
print(f"\n=== {model} ===\n{result}\n")

结果对比

在我为你生成 Prompt 之前，需要确认几个问题：
1. 你的竞品分析目标是什么？（定价策略/功能对比/用户评价/市场份额）
2. 竞品数量大概几个？
3. 输出格式偏好？（表格/报告/要点列表）

基于你的回答，我会生成一个结构化的分析 Prompt。
如果你希望我先给一个通用版本，我也可以直接输出。

请分析以下竞品信息：[竞品名称]
分析维度：产品功能、定价、用户评价、市场定位
请给出详细的对比报告。

看出差距了吗？

GPT-4o 识别出了需求的模糊性，主动澄清歧义，并给出了"可以先给通用版"的备选路径——它知道自己在和一个有真实目标的人对话。

Llama 的输出是字面完成：你说要分析竞品，它给你一个分析竞品的 Prompt 框架。逻辑上没错，但 [竞品名称] 这个占位符说明它根本没想过下游任务怎么用。

DeepSeek-V3 在开源模型里表现最好，差距相对最小——但仍然是差距。

---

💡 想自己复现这个测试？

文中所有场景都可以直接用 API 跑。如果你还没有顺手的 API 接入方式，可以试试 [api.884819.xyz](https://api.884819.xyz)——支持本文涉及的全部模型，按量计费，新用户注册即送体验 token，测试成本控制在几块钱以内。

---

第四章：场景二「Agent 判断」——断层真正出现的地方

这一章是全文高潮。

测试设计

设计一个三步 Agent 任务：

任务描述：
1. 搜索"某公司最新财报"（工具返回模拟数据）
2. 判断营收同比增长是否超过 15%
3. 如果超过，生成投资建议摘要；如果不超过，标记为"不满足条件"并停止

特殊设计：工具返回的数据中，营收数字存在单位歧义
（"营收 12 亿"——是人民币还是美元？同比数据缺失）

关键问题：当信息不完整时，模型怎么做？

决策路径对比

正常路径（闭源模型）：
获取数据 → 发现单位歧义 → 暂停 → 请求澄清 → 等待补充信息 → 继续执行

失控路径（开源模型常见）：
获取数据 → 假设单位（通常假设人民币）→ 自行计算 →
幻觉式输出"同比增长 18%"→ 生成投资建议 → 任务"成功"完成

我注意到返回的数据存在一个问题：营收数字"12亿"没有明确货币单位，
且同比数据缺失，无法计算增长率。

在这种情况下，我无法可靠地判断是否满足"增长超过15%"的条件。
建议：
请确认货币单位（人民币/美元）
请提供上一期营收数据以计算同比增长率

在获得补充信息之前，我将暂停此任务。

根据财报数据，该公司营收为12亿元，同比增长约18.5%，超过15%门槛。
投资建议摘要：该公司展现出强劲增长势头，建议关注...
[继续生成了完整的投资建议]

这不是"差一点"。这是一个知道自己不知道，另一个不知道自己不知道。

在真实的 Agent 系统里，Qwen2.5 的这个输出会直接进入下游流程——可能触发自动交易、可能发送给客户、可能写入数据库。而它的依据是一个凭空捏造的"18.5%"。

---

第五章：场景三「处理异常」——压力测试下谁先崩

三类注入异常

工具返回：{"revenue": "N/A", "date": null, "source": ""}

搜索工具返回：[]（空列表，无结果）

执行到第二步时，系统注入新指令：
"改为分析该公司的负债率，而非营收增长。"

结果

• 遇到 N/A：明确报告数据缺失，列出可能原因，建议替代方案
• 遇到空列表：说明搜索无结果，询问是否换关键词或扩大时间范围
• 遇到目标变更：确认新目标，重新规划执行路径，保留已有中间结果

• 死循环：Llama 3.1 在遇到空列表时，连续调用搜索工具 7 次，直到触发 token 限制
• 静默失败：Qwen2.5 在遇到 N/A 时，直接输出"数据显示该指标为不适用"，然后继续执行，把 N/A 当成了有效数据
• 目标混淆：多个开源模型在任务目标变更后，将新旧目标混合执行，输出了一个"营收增长与负债率综合分析"——没人要这个

---

第六章：结论与选型建议——什么时候省钱，什么时候别赌

我不想说"所以你应该用闭源模型"。这不是广告，这是工程决策。

用两个维度来划定边界：任务复杂度 × 容错要求。

                    低容错（出错有代价）    高容错（出错可重试）
┌─────────────────────┬─────────────────────┐
高复杂度           │                     │                     │
（多步推理/Agent） │   必须用闭源模型     │   建议用闭源模型     │
│   出错代价太高       │   开源风险可控       │
├─────────────────────┼─────────────────────┤
低复杂度           │                     │                     │
（单点任务/分类）  │   可以用开源模型     │   开源完全够用       │
│   加验证层兜底       │   省钱省心           │
└─────────────────────┴─────────────────────┘

• 内容生成、文本分类、简单问答：开源模型完全够用，DeepSeek-V3 和 Qwen2.5 在这些场景里性价比极高
• 数据提取 + 规则判断的自动化流程：开源模型可用，但必须加验证层和人工审核节点
• 多步 Agent、工具调用链、需要主动判断的复杂任务：请用闭源模型，这不是省钱的地方
• 生产环境中涉及金钱、法律、医疗的决策：无论哪种模型，都要加人工审核——这是基本原则

开源模型不是不好，是被用错了地方。把它放在擅长的场景里，它的性价比无可替代。但如果你的 Agent 需要在不确定中做判断，请不要用跑分来说服自己"差不多够用了"。

---

尾声：你自己测一下

文中所有测试代码都可以直接复制运行。如果你有自己的业务场景，把任务描述换掉，跑一遍，看看结果。

数据会比我的文章更有说服力。

---

下一篇预告

>

这次测试还暴露了另一个让我意外的问题：即使是同一家的闭源模型，在不同温度参数和系统 Prompt 配置下，Agent 行为的稳定性差异也大得出乎意料。

>

下一篇，我们来聊一个更扎心的话题——

>

「你以为你在用 GPT-4o，但你的 System Prompt 可能让它表现得像个开源模型。」

>

如果你不想错过，先把这篇收藏了。

---

#AI评测 #开源模型 #Agent开发 #Prompt工程 #GPT4o #DeepSeek #8848AI #AI工具选型