最近“禁掉所有工具后Opus 5和GPT-5.6的差距终于藏不住了”这张对比图在各个群里传得很凶。乍看是在比“谁更聪明”仔细看评论区会发现很多人拿出来的例子根本不是模型本体的差距而是搜索插件、代码解释器、文件解析器之类的外挂能力。工具一开环境变量把模型差异盖住了谁调用检索调得好、谁把网页摘要喂得干净谁就更像“赢了”。真正要判断两个模型的底子得把工具全部禁掉回到“纯模型对纯模型”的裸推状态。这里说的“禁工具”不是指在产品界面里关掉联网搜索开关而是指在 API 请求里不传任何 tools、functions 字段也不把系统提示词预设成“你可以调用浏览器”。只有这种情况下模型输出的每一个 token都来自它自己的参数和推理路径而不是来自外部检索到的二手信息。这篇文章不打算重复那些没有披露测试集的跑分截图而是给出一个可以自己复现的评测方法怎么配置无工具的 API 环境怎么设计覆盖推理、长上下文、多轮对话、数学、代码、防幻觉的测试集怎么控制采样参数怎么做盲评怎么把成本、延迟、批量任务一起纳入评分。这样测出来的差距才真正具有参考价值。需要先说明一点下面涉及“Opus 5”“GPT-5.6”的信息都基于公开讨论中的代际命名假设具体版本、能力和上线状态以官方正式发布为准。评测方法本身是可通用的把它用在目前已有的任何两个大模型上结论依然成立。1. 核心能力速览对比项说明比较对象Opus 5Anthropic Claude 系列的新代际名称假设、GPT-5.6OpenAI GPT 系列的新代际名称假设比较模式纯模型模式API 请求中不携带 tools、functions不启用联网检索工具不使用代码执行插件评测重点原生语言理解、复杂推理、长上下文跟随、数学与代码生成、多轮一致性、防幻觉能力评测方式固定测试集 固定采样参数 盲评打分 成本/延迟观测显存需求闭源云端 API 模型本地无需 GPU不涉及显存如果换成开源模型做对照才需要按模型体积评估显存启动方式API 调用无需部署服务需要 API Key、请求地址、网络环境是否支持 API支持评测全程走 Chat Completions 兼容接口是否支持批量任务支持通过异步并发脚本批量请求需要做并发控制和失败重试适合场景模型选型、产品接入前评估、prompt 方案对比、新版本能力回归测试从表格可以得出一个明确结论这不是一个“本地部署”类项目而是一个“模型评估流程 对比方法论”的实操指南。你想知道 Opus 5 和 GPT-5.6 谁更强不能只看厂商宣传也不能只看网友贴出来的单轮对话要自己跑一批结构化的测试样本然后用统计方式看差异。2. 适用场景与使用边界2.1 这套评测方法适合谁需要在新版本模型发布后快速判断是否值得切换服务商的研发团队。正在做 Agent 应用开发想拆清楚“模型本身的能力”和“工具调用的能力”边界的产品经理。需要向客户出具模型选型报告的技术顾问。对大模型有好奇心想建立自己判断标准的个人开发者。2.2 不适合什么场景不适合用来判断“哪个模型在实际产品里体验更好”。实际产品里工具、知识库、Agent 编排都会影响用户体验纯模型评测结果只是其中一环。不适合做代码解释器或数据分析的能力排名。这些能力依赖代码执行环境属于工具增强能力不在本文的“禁工具”范围内。2.3 合规与边界提醒测试素材不要使用未授权的私有数据、敏感个人信息或受版权保护的完整文章。建议优先使用自建样本、公开许可的开源评测集或虚构数据。大模型生成结果可能存在事实性错误任何生成内容在对外展示、商用和发布前必须经过人工复核。两家服务商的数据使用政策不同如果涉及业务敏感数据请在测试前确认 API 服务商的数据留存选项或者直接使用脱敏样本。涉及模型能力比较的公开结论最好附带完整测试条件避免用单一样本误导他人。3. 评测环境与前置条件实际测试前先把环境和材料准备好。整个评测依赖以下几个部分依赖项要求API Key两个模型服务商分别申请注意密钥保密不要提交到公开仓库Python 环境推荐 Python 3.10 以上安装 requests 或 openai 兼容 SDK测试集5 个维度每个维度 20~50 条提示词总量建议 100~200 条评测脚本批量请求脚本、结果记录脚本、盲评页面或表格采样参数固定 temperature、top_p、max_tokens最好两次模型使用完全一致的参数成本预算先估算 token 消耗避免一次性把测试集跑完才发现成本超标环境准备的关键点不是装软件而是“控制变量”。控制变量的核心是三件事同一个测试集同一个用户提示词。相同的采样参数。相同的输出长度上限。如果两个模型用不同的 temperature或者一边开了搜索一边没开最后得出的差异就无法分辨是模型能力造成的还是参数造成的。这里需要一个通用请求模板。目前很多模型服务商都提供 OpenAI 兼容的接口格式下面用api.example.com做占位实际使用时替换成对应服务商地址。# 通用 Chat Completions 请求示例按实际服务商地址替换 curl -X POST https://api.example.com/v1/chat/completions \ -H Authorization: Bearer $API_KEY \ -H Content-Type: application/json \ -d { model: model-id-placeholder, messages: [ {role: system, content: 你是一个严谨的评测助手。请直接回答用户问题不要提及你可以使用工具。}, {role: user, content: 一个盒子里有5个红球和3个蓝球随机取出2个球至少取到1个红球的概率是多少请给出计算过程。} ], temperature: 0.2, max_tokens: 2048 }上面这个请求里没有出现tools字段、functions字段也没有在 system 提示里强加工具调用说明这就是“禁工具”的基础状态。需要特别注意有些平台即使你不传 tools也会在系统层自动注入联网检索能力这种情况需要在请求里显式关闭联网参数或使用离线部署版本所以评测开始前最好用一条“今日新闻”类问题做验证确认模型明确表示“无法获取实时信息”才算真正禁掉了工具。并发测试时建议用 Python 脚本封装请求并且把每条测试样本的输入输出、token 数、延迟时间全部落盘。# 批量请求模板按实际服务商地址、模型名和密钥替换 import json import time import csv import requests API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key def chat_once(messages, model, temperature0.2, max_tokens2048): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: model, messages: messages, temperature: temperature, max_tokens: max_tokens } start time.time() resp requests.post(API_URL, headersheaders, jsonpayload, timeout180) latency_ms int((time.time() - start) * 1000) data resp.json() if resp.status_code ! 200: return { status: resp.status_code, error: data, latency_ms: latency_ms, response_text: } choice data[choices][0] usage data.get(usage, {}) return { status: resp.status_code, latency_ms: latency_ms, response_text: choice[message][content], prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0) } if __name__ __main__: # 示例读取 prompts.json写入 results.csv result chat_once( [{role: user, content: 请用不超过100字解释什么是注意力机制。}], modelmodel-id-placeholder ) print(json.dumps(result, ensure_asciiFalse, indent2)){ input_file: ./prompts.json, output_file: ./results.csv, model: model-id-placeholder, temperature: 0.2 }以上只是通用模板。真正的接口参数、模型 ID、鉴权方式以服务商文档为准不要在评测脚本里写死。4. 安装部署与启动方式从严格意义上讲闭源 API 模型没有“安装部署”这一步。但评测流程需要一个可复现的“测试环境”我用 Docker 的方式把评测脚本和环境依赖包在一起保证换一台机器也能跑。如果你本机已经装好 Python 和依赖也可以跳过 Docker直接跑脚本。# Dockerfile 示例用于构建评测环境 FROM python:3.11-slim WORKDIR /eval COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY eval_runner.py . COPY prompts.json . CMD [python, eval_runner.py, --input, prompts.json, --output, results.csv]requirements.txt 至少包含requests2.31.0 pandas2.2.0 openai1.30.0构建和启动命令# 构建评测镜像 docker build -t llm-eval . # 运行评测挂载本地目录保存结果 docker run --rm -v $(pwd)/outputs:/eval/outputs llm-eval这种做法的价值在于评测脚本一旦固定两个模型在同一条提示词上的输出差异就可以被客观记录不会因为谁的本地环境多装了一个插件而产生偏差。5. 功能测试与效果验证5.1 测试维度设计我建议按五个维度设计测试集每个维度至少 20 条提示词。维度考察目标样本示例复杂推理逻辑链条是否连贯、是否正确多步逻辑题、条件推理题、反事实推理数学计算符号运算和计算过程是否正确概率题、代数题、数列题代码生成语法正确性、边界处理、可运行性“写一个函数实现……并考虑空数组”长上下文跟随在长文中是否遗漏关键信息给一段 3000 字材料要求提取指定信息防幻觉面对知识截止日期之后的问题是否承认不确定“2026 年某公司季度财报是多少”如果条件允许可以在每个维度里再拆成“有标准答案”和“开放答案”两类。有标准答案的题用于客观打分开放答案用于盲评主观质量。5.2 复杂推理测试这一部分我会用一个三层嵌套逻辑题做示例目的是看模型在长条件链下能不能保持一致性。测试输入示例某个岛上有三类人骑士总说真话骗子总说假话普通人有时说真话有时说假话。 A 说“B是骗子。” B 说“C不是普通人。” C 说“A和B不是同类人。” 已知三个人都不是普通人。 问题A、B、C分别是什么身份请逐步推理。操作步骤将同一提示词分别发给两个模型。观察模型是否先分情况讨论。观察最终身份组合是否矛盾。记录模型是否尝试用自然语言推理而非直接猜答案。预期结果两个模型都能给出身份组合但其中一个可能会忽略某些二元可能性导致推理在某一步断裂。判断成功的标准不是“两个模型都算对了”而是“谁在推理过程中先丢失条件”。这类测试出现的典型失败模式是模型开头把“C 不是普通人”解读成“C 是普通人”后面整套推理崩塌。所以评分时不要只看结论还要看推理步骤。5.3 数学计算测试数学题适合用“过程分 结果分”双重评分。给一个示例设 f(x) 2x^3 - 9x^2 12x 1求 f(x) 在区间 [0, 3] 上的最大值与最小值并写出求导过程。预期结果模型应该求出 f(x) 6x^2 - 18x 12解出驻点 x 1 和 x 2再比较端点值。常见失败模式包括求导错误。忽略端点比较。把计算过程写得很完整但结果算错。评测时可以设定评分规则求导正确 2 分驻点正确 2 分端点比较 2 分最终结果 2 分文字说明完整 2 分。两个模型各自在同一套规则下打分最后比较总分。5.4 代码生成测试代码测试的提示词要具体到输入输出约束请用 Python 实现一个函数 find_top_k(items, k)返回出现频率最高的 k 个元素。 要求 1. items 是字符串列表。 2. 如果频率相同按字典序排序。 3. 如果 k 大于去重元素数量返回全部元素。 4. 不要依赖 collections.Counter用普通字典实现。验证方式把模型输出的代码直接复制到本地执行。用固定测试用例跑一遍。# 本地验证脚本 def run_case(func): assert func([a, b, a, c, b, a], 2) [a, b] assert func([apple, banana, apple, cherry], 10) [apple, banana, cherry] assert func([], 3) [] assert func([x, y, z], 1) [x] print(all cases passed)执行这个脚本如果模型生成的代码无法通过断言就记录为“未通过”。两个模型的代码生成能力在同一组测试用例下直接对比。可以观察到一个常见现象一个模型可能生成更简洁的代码但在边界情况上崩溃另一个模型代码更啰嗦但通过全部断言。这种差异在“禁工具”模式下特别明显因为没有代码解释器帮它运行返回结果模型完全靠静态生成能力完成需求。5.5 长上下文跟随测试长上下文测试要重点看“信息随位置变化时的召回能力”。准备一段 3000 字左右的虚构项目文档把关键数字埋在中间位置然后提问根据文档内容回答项目第二阶段的原定截止日期是哪一天预算调整后增加了多少请只引用文档原文不要猜测。操作步骤把文档作为用户消息一部分发送。这里有两个方案如果想测 8192 上下文把文档放中间如果想测更大窗口就拼接多份虚构文档到 3 万 token 左右。对两个模型发送完全相同的消息。观察模型是直接引用原文还是编造日期。记录“答案正确”“答案错误”“拒绝回答但给出了安全提示”三种状态。这里的核心区别在于“无工具模式下模型只有上下文窗口里的信息可用”。如果模型在文档里没有明确找到答案正确的做法是承认上下文不足而不是编造。这正是防幻觉能力的一部分。5.6 防幻觉测试构造一组“知识截止日期之后的事件”类问题例如要求模型给出某个 2026 年行业会议的主题。两个模型都应该承认“知识截止到训练数据无法提供实时信息”。如果某个模型编造出具体主题名、时间地点和发言人说明它的幻觉控制更弱。这一维度评分并不复杂输出表现得分明确拒绝并说明知识截止满分给出通用方法论但声明未检索较好直接编造完整信息0 分“禁掉工具”真正的价值就在这里一些模型在工具模式下不会暴露知识截止问题因为它的搜索插件会把问题解决掉。但禁掉工具后你能立刻看出它的内在知识边界在哪里也更方便判断它以后接上自有知识库时到底会不会老老实实说“不知道”。6. 接口 API 与批量任务评测 100 条以上的提示词手动一条条跑不现实。需要把接口调用脚本升级成支持批量、并发和失败重试的评测工具。6.1 批量请求设计批量任务的基本流程读取 prompts.json。按并发限制提交请求。等待响应后把结果写入 CSV。请求失败时做指数退避重试。结束后输出汇总报告。# 异步批量评测模板按服务商实际接口调整 import asyncio import json import csv import random import aiohttp API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key MODEL model-id-placeholder CONCURRENCY 4 MAX_RETRY 3 async def fetch(session, prompt, idx): payload { model: MODEL, messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 2048 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } for attempt in range(MAX_RETRY): try: async with session.post(API_URL, headersheaders, jsonpayload) as resp: data await resp.json() if resp.status 200: message data[choices][0][message][content] usage data.get(usage, {}) return { idx: idx, prompt: prompt, response: message, status: ok, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0) } elif resp.status 429: await asyncio.sleep(2 ** attempt) else: return { idx: idx, prompt: prompt, response: , status: fhttp_{resp.status}, error: str(data) } except Exception as exc: if attempt MAX_RETRY - 1: return { idx: idx, prompt: prompt, response: , status: exception, error: str(exc) } await asyncio.sleep(2 ** attempt) async def main(): with open(prompts.json, r, encodingutf-8) as f: prompts json.load(f) semaphore asyncio.Semaphore(CONCURRENCY) async def guarded(prompt, idx): async with semaphore: return await fetch(session, prompt, idx) async with aiohttp.ClientSession() as session: tasks [guarded(p, i) for i, p in enumerate(prompts)] results await asyncio.gather(*tasks) with open(results.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[idx, prompt, response, status, prompt_tokens, completion_tokens, error]) writer.writeheader() writer.writerows(results) asyncio.run(main())6.2 并发与成本评估并发度不建议一次开太高。多数模型 API 都有每分钟请求数和每分钟 token 数限制建议从 2 到 4 个并发开始观察是否有 429 限流错误再逐步调高。批量任务要记录两个关键数字总 token 消耗。每条请求的中位延迟和 p95 延迟。记录之后对比两个模型在相同测试集上的花销。有些模型单次回答质量高但 token 消耗量大折算到每个任务上的成本反而不划算。如果把“能力得分”和“成本”一起看能得出更符合业务需要的结论。6.3 盲评流程如果人工打分强烈建议做盲评。方法如下将两个模型的输出去掉来源标记混合打乱。只把“问题 回答”展示给评分者。评分者从正确性、完整性、结构化程度三个维度打分。最后再还原模型标签统计平均分。盲评不能证明绝对的“谁更强”但能减少明显的先入为主偏差。很多时候讨论群里“一边倒”的结论在盲评之后会出现反转。7. 资源占用与性能观察闭源 API 模型不需要本地显存但“资源占用”可以从三个维度观察token 消耗、推理延迟、成本。7.1 Token 消耗测试长上下文时要特别关注输入 token 的计费方式。不同服务商对长输入的计费倍率不同缓存命中和未命中的价格也可能不同。批量运行前先用 10 条样本估算每条平均 token 消耗再乘上总样本数得到预算上限。7.2 推理延迟在评测脚本里记录latency_ms。一个模型可能输出更长、更详细导致 TTFT首 token 时间相近但总完成时间更长。如果产品对响应时间敏感延迟差异就应该作为选型维度之一。对比格式观察项模型 A模型 B平均首 token 延迟以实测为准以实测为准平均总响应时间以实测为准以实测为准平均每任务 token 数以实测为准以实测为准单任务成本估算以实测为准以实测为准留空的数字不要猜跑一批测试后填真实数据。7.3 本地模型对照方案如果你想把“闭源模型”和“开源可本地部署模型”做一次横向对照可以使用 Ollama、vLLM 或 llama.cpp 加载开源模型。这时才需要关注显存。以一般经验来说7B 到 14B 量级的模型量化后需要 6G 到 12G 显存但具体数值取决于量化精度、上下文长度和并发数需要以本机实测为准不建议照搬别人的显存数字。本地模型和闭源模型的对比要注意另一个变量推理框架的优化水平。同模型用不同推理框架跑生成速度可能差 2 到 3 倍所以本地对照只能做能力层面的参考不能直接作为“XX 模型比 XX API 快”的证据。8. 常见问题与排查方法问题现象可能原因排查方式解决方案请求返回 401API Key 无效或权限不足检查密钥是否正确、是否有模型访问权限重新生成密钥确认账号已开通对应模型请求返回 429触发了限流查看响应头中的限流信息降低并发数增加指数退避重试返回内容为空模型拒绝回答或内容被安全策略拦截查看返回中的 finish_reason 和审核字段调整提示词表达方式或使用更安全的测试数据模型回答明显过时模型知识有截止日期提问时注明“不使用工具”不要问实时性问题换成逻辑推理或其他离线能力题两条 prompt 结果不稳定temperature 过高或模型本身存在随机性固定 temperature多次运行取多数结果设置 temperature0 或 0.2对同一题跑 3 次取多数投票批量任务跑一半中断网络超时或单条请求卡住查看日志和超时时间调大 timeout增加每请求的异常捕获输出长度超限被截断max_tokens 设置过小观察 completion_tokens 是否等于 max_tokens调大 max_tokens 或要求模型“只给结论不展开”盲评时没法分辨模型两模型输出风格接近增加难度更大的推理题增加对抗性样本比如包含误导条件的逻辑题最常见的坑不是模型回答质量差而是评测脚本把工具字段悄悄传了上去。建议每次请求前后打印 payload确认没有tools、function_call、search等字段。# 请求前检查 payload 是否包含工具字段 def assert_no_tools(payload): banned_keys [tools, functions, function_call, search] for key in banned_keys: if key in payload: raise ValueError(fpayload contains banned tool key: {key})这个断言函数要放在批量脚本的主循环里防止有哪条请求因为历史代码残留而意外开启工具。9. 最佳实践与使用建议9.1 先跑小样本再跑全量第一批测试只选 10 条提示词先确认两端 API 都能通、token 计费符合预期、模型没有出现格式解析问题。通过后再把 100 到 200 条测试集跑完。9.2 固定一个“基线模型”评测不一定非要在 Opus 5 和 GPT-5.6 之间二选一。你可以固定第三个模型作为基线比如某个开源模型或当前线上版本这样每次测试都能看到相对变化而不是零散的绝对分数。9.3 结果分目录管理项目目录建议按“数据集、脚本、结果、报告”四层组织eval/ ├── datasets/ │ ├── reasoning.json │ ├── math.json │ ├── code.json │ ├── long_context.json │ └── anti_hallucination.json ├── scripts/ │ ├── eval_runner.py │ ├── assert_no_tools.py │ └── blind_review.py ├── results/ │ ├── model_a_round1.csv │ ├── model_b_round1.csv │ └── round1_summary.md └── reports/ └── model_compare_2025.md模型文件、测试输入、输出结果分开存放方便后续复现和追溯。9.4 不要基于单条对话下结论大模型本身有随机性哪怕 temperature 等于 0不同批次之间也可能出现细微差异。一个模型在单条高难度逻辑题上失败不代表它在所有推理任务上都不行。建议同一道题跑 3 次取多数结果再做统计比较。9.5 评分的四个维度维度权重的建议说明正确性40%有标准答案时按答案是否正确给分完整性20%是否覆盖问题所有要求稳定性20%多次运行结果是否一致效率20%token 消耗与延迟是否合理加权分数比单纯看“对了几题”更能反映模型的工程可用性。9.6 合规使用建议不要用真实个人信息做测试样本。不要将未公开的内部业务数据发给第三方 API。不要直接复制受版权保护的代码库片段到提示词中。对外发布“哪家更强”的评测结论时务必附带测试集、参数和评分规则。所有生成内容在对外发布前必须做事实核查。10. 总结与下一步“禁掉工具”评测最有价值的一个产出是你能看清模型在没有外部检索、没有代码执行环境时的真实边界。很多人以为模型“什么都知道”实际在无工具模式下不少看似基础的问题会暴露出知识截止、推理断裂和幻觉倾向。对做 Agent 应用的人来说这个边界尤其关键你的 Agent 未来调用工具之前模型得先靠自己把用户意图和约束条件理解清楚否则外部工具越多错误也会被连带放大。如果你想动手试最先验证的功能建议放在“复杂推理 防幻觉”这两个维度。它们的答案容易被客观判断也最能体现两个模型的本体差异。最容易踩的坑则是“嘴上说禁了工具请求里却还带着工具字段”所以测试脚本里加一个工具字段断言能让后续所有对比都建立在干净的前提下。后续可以继续扩展的方向有三个一是把测试集扩大到多语言覆盖中英之外的日、法、西语场景二是加上多轮对话测试模拟真实用户连续追问三是接入开源模型做对照实验看闭源模型和开源模型之间在纯推理能力上到底有多大代差。等新的代际版本真正发布后把这套评测流程再跑一遍就能得到一份属于自己的、可复现的能力变化报告而不是只能引用别人的一张截图。