如果只看各家发布会的演示你会觉得 Opus 5 和 GPT-5.6 已经没多大差别了都能处理长文档都能调用搜索和代码执行都能在对话里完成复杂任务。但当我把评测环境里的所有工具全部禁掉——没有联网、没有代码执行、没有文件检索只留下一次单纯的文本生成机会——这两款模型之间的差距反而比任何时候都明显。原因不复杂。工具调用能力是“外挂装备”而推理和知识组织才是模型的“内功”。外挂可以靠工程能力补齐内功只能靠模型本身。当所有模型都站在同一条起跑线上裸考时装备带来的优势会被抹平剩下的才是这个模型真正的基本功。很多人选模型只看“能不能用工具”忽略了底座能力结果一换场景就翻车。这篇文章不打算复述发布会参数而是把“禁工具评测”这件事拆透它为什么比常规评测更能暴露 Opus 5 和 GPT-5.6 的差异、评测框架怎么设计、代码怎么落地、跑完结果怎么判读以及最常见的坑在哪里。读完你可以直接照着搭一套自己的模型评测环境。1. 这篇文章真正要解决的问题先说结论常规模型对比评测的价值正在快速下降。原因是模型厂商都在用工具增强来“补差”——搜索不准就接检索计算不行就加代码执行器长文本记不住就上文件读取。当每个模型都能借助外部工具把短板撑起来时你很难判断模型本身的水平到底如何。但实际开发里工具并不总是可用。比如你写了一个离线推理服务模型跑在内网环境不允许访问外部 API比如你处理的是敏感数据不能把 Prompt 发给搜索服务再比如你基于模型做代码补全模型每次只有一次短生成机会没有机会先跑 Python 再修正。这些场景下模型只能靠自己的推理和知识回答问题。“禁掉所有工具”不是刁难模型而是把真实场景中被“工具遮挡”的能力重新暴露出来。所以这篇文章要解决的核心问题有两个第一为什么“禁工具”后 Opus 5 和 GPT-5.6 的差距会放大第二如何搭建一套可复现、可扩展的“禁工具”评测环境并用它得到有参考价值的判断。读完你至少能获得三样东西一套评测方法论、一份可运行的评测代码、一组判断差异信号的解读框架。这比看别人公布的跑分更有用因为你可以用自己的业务题目去验证。2. 为什么“禁掉工具”比“加上工具”更能暴露差距很多团队做过类似实验同一个问题先让模型直接回答再给模型接上搜索或代码执行最后对比答案质量。结果是“加上工具”后模型之间的回答差距明显缩小——模型自身不知道的知识工具可以补模型算不准的数学代码解释器可以算。这给很多人的错觉是“模型底层能力已经趋同了”。但工具介入会把模型能力拆成“模型本身能力 工具增益”两个部分。工具增益取决于工程实现比如检索器质量、上下文拼接方式、代码执行环境的稳定性。如果两家模型的工具链路都很成熟最终体验差异就很小。这时候你评估的其实是工程系统不是模型。禁掉工具后链路被简化到只剩“模型 提示词”此时你会看到三个在工具评测里被忽略的差距点第一知识内化程度。允许搜索时模型可以“现查现答”禁掉搜索后模型只能依赖参见过数据中的知识。Opus 5 和 GPT-5.6 在这类问题上的差异会直接体现为“答得完整但不准确”和“答得简短但关键点齐全”两种风格。第二多步推理的稳定性。工具评测中模型可以写一段代码来辅助推理或者拆成多轮对话逐步试探。禁掉工具后模型必须在一个回答里完成从问题分解到逐步推导的全过程。这里最容易拉开差距有的模型能保持完整推导链有的模型前两步正确、第三步开始偷换逻辑。第三自我一致性。模型在缺少外部校验时是否会出现前后矛盾。搜索工具可以快速纠正错误代码执行可以验证结果但纯文本生成没有任何外部纠错机制。这个维度最能体现模型内部的“一致性约束”做得好不好。所以“禁工具评测”本质上不是让模型为难而是把评测目标从“谁能借助更多工具完成任务”转回“谁在孤立状态下更可靠”。对需要做模型选型的团队来说这个维度更接近模型底座的真实水平。3. Opus 5 与 GPT-5.6从模型定位看差异背景在展开评测方案之前有必要先搞清楚 Opus 5 和 GPT-5.6 各自的定位。模型版本更新很快具体参数和价格会随时间变化这里不堆配置只讨论定位层面的差异。Opus 5 延续了该系列的一贯定位面向复杂推理、长文本分析和深度写作场景。这类模型的设计目标不是“和用户闲聊”而是在高难度任务中保持逻辑链的完整。它的典型使用场景包括长文档语义分析、复杂业务规则抽取、代码逻辑审查。由于 OpenAI 和 Anthropic 在模型设计上的取舍不同Opus 系列在“长上下文理解”和“结构化推理”上的投入一直比较大。GPT-5.6 则更接近“通用底座模型”的定位覆盖任务广、指令跟随直接、对不同领域问题的泛化能力强。它的优势在于“能用一套能力应对多样场景”而不是在某个专项上做到极致。这类模型在日常助手、工具调用、代码辅助等场景中表现得非常灵活。如果把模型比作人Opus 5 更像一个研究型专家擅长长时间专注在一件事上做深度推导GPT-5.6 更像一个高适应性的综合型选手换了新任务能快速上手。工具加持下两者都能完成绝大多数的任务一旦把工具禁掉研究型专家和综合型选手的差异就会显现前者可能在深度推导上更完整后者可能在不同任务切换中更稳定。这里必须强调一点这属于基于公开定位的合理判断不是“某次实测跑出来的绝对结论”。真实差异需要用你自己的业务题目去验证因为模型在不同领域上的表现排位可能完全不同。4. “禁工具”评测的六维框架评测模型不能只看“答得对不对”尤其是禁掉工具之后答案的评价维度会更多元。我建议用六个维度来搭建框架这样跑出来的结果更容易横向对比。4.1 事实准确性与知识边界维度定义模型在无法联网的前提下给出的客观知识是否准确对于自己不知道的信息是否坦诚。核心观察点模型是在明确说“不确定”还是用一个自信的编造来填补知识空白。禁掉工具后幻觉率会直接上升这一维度最能拉开差距。4.2 多步推理完整性维度定义模型能否独立完成多步骤逻辑推导并且在中间步骤不出现跳步或偷换。典型题目包括数学证明、逻辑谜题、复杂条件判断。观察点不是最终答案而是过程链条是否连续。工具评测中模型可以用代码步骤校验禁掉工具后全靠推理本身。4.3 长文本信息保持维度定义给模型一段较长的背景材料要求它回答基于材料细节的问题。禁掉工具意味着模型不能主动检索材料必须把材料内容内化到这次生成中。观察点是细节保持度小数字、限定词、例外条件是否被忽略。4.4 指令跟随精度维度定义用户给出的格式约束和规则约束模型有多大概率严格遵守。例如要求“不要解释过程只输出答案”或者“用 JSON 输出且字段名严格为 specified”。禁掉工具后更接近模型指令跟随的原始水平。4.5 反事实与边界条件处理维度定义当题目假设和常识冲突时模型是否能坚持题目给定的假设而不是被常识带跑。这一维度很能反映模型在“非日常分布”下的稳定程度。有些模型在常识范围内表现不错但一旦遇到反事实设定立刻回归套路化回答。4.6 生成稳定性维度定义同一条 Prompt 重复运行 N 次答案的关键要素是否保持一致。工具评测中模型可以借助检索结果“锚定”答案禁掉工具后随机性和解码策略的影响会被放大。这一维度不要求两模型达到 100% 一致但差异过大会影响生产环境中的可靠性。5. 评测环境搭建与前置条件设计好框架后下一步是搭建可复现的评测环境。环境准备并不复杂重点是要把“变量控制”做到位否则评测结果会失真。本文使用 Python 3.10 和两个官方 SDK。模型 ID 以你实际账号可用为准不同版本命名规则可能不同。下面代码里的模型名称只是示例运行前请替换成你账号里真实存在的模型 ID。5.1 安装依赖# 创建虚拟环境推荐 python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate # 安装两个模型的官方 SDK pip install openai anthropic # 用于读取环境变量和数据处理 pip install python-dotenv环境变量文件建议放在项目根目录命名为.env# 文件路径.env OPENAI_API_KEY你的GPT模型Key ANTHROPIC_API_KEY你的Opus模型Key5.2 固定可变参数评测脚本要显式固定三个参数temperature、max_tokens、top_p。否则模型每次返回的内容随机性过大统计结果没有可比性。建议稳定参数统一设置为TEMPERATURE 0.2 MAX_TOKENS 2048 TOP_P 1.0这里把温度设成 0.2是为了保留一定多样性同时又不至于让结果跳变得太夸张。如果需要测试模型的发散能力可以单独跑一组高温度对比。6. 评测流程与完整代码示例下面给出一个最小可用的“禁工具”评测实现。这个示例强调“直接可用”没有复杂的工程化封装方便你快速跑通再扩展。6.1 统一模型调用封装为了让两个模型在同一个循环里被调用先把接口封装成统一的函数。这一步的关键是完全不调用任何工具不传联网能力不执行代码只发起一次文本生成请求。# 文件路径model_client.py import os from openai import OpenAI from anthropic import Anthropic client_gpt OpenAI(api_keyos.getenv(OPENAI_API_KEY)) client_opus Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) TEMPERATURE 0.2 MAX_TOKENS 2048 TOP_P 1.0 def ask_gpt(prompt: str) - str: # 模型 ID 请替换为你账号下真实可用的模型 ID response client_gpt.responses.create( modelgpt-5.6, inputprompt, temperatureTEMPERATURE, max_output_tokensMAX_TOKENS, top_pTOP_P, ) return response.output_text def ask_opus(prompt: str) - str: # 模型 ID 请替换为你账号下真实可用的模型 ID response client_opus.messages.create( modelclaude-opus-5, max_tokensMAX_TOKENS, temperatureTEMPERATURE, top_pTOP_P, messages[ {role: user, content: prompt} ], ) return response.content[0].text def ask(model_name: str, prompt: str) - str: if model_name gpt-5.6: return ask_gpt(prompt) if model_name opus-5: return ask_opus(prompt) raise ValueError(fUnknown model: {model_name})这段代码有几个值得注意的细节第一temperature和top_p都固定了避免因为解码策略不一致导致结果偏差。第二两个模型的接口结构不同但都被包成了同一个ask(model_name, prompt)后续评测脚本不需要关心模型差异。第三没有给模型任何“你可以先搜索一下”之类的提示词这是“禁工具”评测的前提条件。6.2 准备评测题目集评测题目集的格式使用 JSON每个元素包含三个字段id、dimension、prompt。dimension对应上文六维框架中的维度方便结果按维度分组统计。// 文件路径questions.json [ { id: fact_001, dimension: fact_accuracy, prompt: 请简述贝叶斯定理并说明它与朴素贝叶斯分类器的关系。不要搜索直接回答。 }, { id: reasoning_003, dimension: multi_step_reasoning, prompt: 一个容器里有红球、蓝球、绿球共 100 个。红球数量是蓝球的 2 倍绿球数量比红球多 10 个。请问三种球各有多少个请给出完整推导过程。 }, { id: instruction_002, dimension: instruction_following, prompt: 请你写一句介绍 Python 的话要求不超过 20 个字必须包含“语法”和“库”两个词不要输出任何其他内容。 }, { id: counterfactual_004, dimension: counterfactual, prompt: 假设地球引力突然变为原来的两倍那么人在正常行走时会先感觉到哪些变化请基于这个假设进行分析不要用常识反驳假设本身。 } ]题目集的设计有几个原则同一维度至少准备 10 题以上否则统计意义太弱题目难度不要集中于“一眼就能答”的常识题至少要包含一类需要多步推导的题目因为这是禁工具后差异最明显的场景。6.3 自动化执行评测评测脚本读取题目集逐个模型运行把结果保存到 JSON 文件。为了保证公平性建议用随机顺序交替调用两个模型避免模型受到“上一题”或“系统当前缓存状态”的偶然影响。# 文件路径run_eval.py import json import random import time from model_client import ask def load_questions(path: str) - list[dict]: with open(path, r, encodingutf-8) as f: return json.load(f) def run_eval(questions: list[dict], model_name: str) - list[dict]: results [] for idx, q in enumerate(questions): print(f[{model_name}] 运行题目 {idx 1}/{len(questions)}: {q[id]}) try: answer ask(model_name, q[prompt]) except Exception as e: answer f__ERROR__: {e} results.append({ question_id: q[id], dimension: q[dimension], model: model_name, prompt: q[prompt], answer: answer, timestamp: time.time(), }) # 避免触发接口限流 time.sleep(1) return results def main(): questions load_questions(questions.json) random.shuffle(questions) # 固定随机顺序保证两个模型面对完全相同的题目顺序 # 实际运行时建议每次运行使用不同种子并保存种子值 random.seed(42) all_results [] for model_name in [opus-5, gpt-5.6]: all_results.extend(run_eval(questions, model_name)) with open(eval_results.json, w, encodingutf-8) as f: json.dump(all_results, f, ensure_asciiFalse, indent2) print(评测完成结果已写入 eval_results.json) if __name__ __main__: main()脚本输出文件eval_results.json会保留原始答案。这些原始答案非常宝贵——规则评分只能判断“是否包含关键词”但人工复核必须回看原文才能发现“看起来答对了但推理过程是错的”这类问题。6.4 简单评分函数自动评分最稳妥的起步方式是先为每道题预置一个“关键元素列表”然后检查答案中是否出现了这些元素。这个方法不完美但足够作为第一轮筛选。# 文件路径scoring.py import json # 关键元素表需要根据题目集手工维护 KEY_ELEMENTS { reasoning_003: [红球, 蓝球, 绿球, 40, 20, 50], instruction_002: [语法, 库], } def score_answer(question_id: str, answer: str) - dict: if question_id not in KEY_ELEMENTS: return {score: None, matched: [], missing: []} matched [kw for kw in KEY_ELEMENTS[question_id] if kw in answer] missing [kw for kw in KEY_ELEMENTS[question_id] if kw not in answer] score len(matched) / len(KEY_ELEMENTS[question_id]) return { score: round(score, 2), matched: matched, missing: missing, } def main(): with open(eval_results.json, r, encodingutf-8) as f: results json.load(f) for r in results: s score_answer(r[question_id], r[answer]) r[auto_score] s with open(eval_results_scored.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(评分完成结果已写入 eval_results_scored.json) if __name__ __main__: main()这个脚本只做“关键元素覆盖度”检查。需要特别提醒规则评分不能替代人工复核。你只能把它当作过滤器真正要看的还是原始答案里的推导过程和逻辑链条。等到题目集积累到一定规模再考虑用 LLM-as-a-judge 做更细粒度的评分但那是后续工程化方向。7. 结果如何看典型的差异信号与判断方法评测脚本跑完之后最忌讳的事是只看一个“总分”。不同维度的差异比总分更能反映模型特性。从公开评测共识和模型定位来看禁掉工具后的结果通常会出现以下三类典型分信号。7.1 推理完整度差异在多步推理题目上你会经常看到一种对比一个模型完整写出了“从条件 A 推出 B再从 B 推出 C”的过程另一个模型直接给出最终答案但答案正确。直接给答案的模型并非“更强”而是跳过了可验证的中间链。在生产环境中这个差异会带来两种体验需要可解释性的场景前者更可靠追求响应速度的场景后者更高效。但如果是数学计算或逻辑判定类任务中间推导缺失会让错误更难定位。建议在评测结果中单独标注“是否有完整推导链”而不是只记录答案是否等于预期值。7.2 知识边界处理方式差异禁掉工具后那些“需要最新信息才能回答”的问题会暴露出模型的自我认知能力。有的模型会直接给出一段听起来很合理、但关键信息已经过时的内容有的模型会明确说“我的知识截止时间较早无法确认当前最新情况”。这两种表现都不是“答对”但对于生产系统来说后者的风险明显更低。建议在事实类题目中增加一类“过时信息题”把 2024 年之后才发生的事件作为问题观察模型是否会主动声明知识边界。7.3 指令格式遵守度差异在严格格式要求下模型的服从性差异明显。有的模型会严格遵守 JSON 输出要求即使内容是错的格式也是对的有的模型偶尔会在 JSON 前后添加解释性文字导致下游解析报错。对于依赖结构化输出的工程团队这个差异可能比“答得对不对”更重要。建议在评测结果中单独统计“格式合规率”例如python - EOF import json with open(eval_results_scored.json, r, encodingutf-8) as f: results json.load(f) # 统计每个模型的 JSON 格式合规率 for model in [opus-5, gpt-5.6]: subset [r for r in results if r[model] model] total len(subset) ok 0 for r in subset: try: json.loads(r[answer]) ok 1 except Exception: pass print(f{model}: 格式合规率 {ok}/{total} {ok / total:.2%}) EOF这类结论比总分更贴近工程视角——你选模型是为了能在项目里稳定解析输出而不是为了一个公开榜单上的排名。8. 常见问题与排查方法评测环境本身并不复杂但实际跑起来时会因为接口、参数、顺序等各种因素导致结果失真。这里整理几个最常见的问题和处理方法。问题现象可能原因排查方式解决方案某个模型频繁超时或返回 429接口限流查看 SDK 返回的具体错误码在请求之间增加 sleep降低并发检查账号配额所有答案都非常相似温度参数被固定为 0或题目难度太低检查脚本中 temperature 配置将温度调至 0.2~0.4提高题目难度模型 ID 不存在或报错模型版本名与代码中不一致查看官方 API 模型列表将代码中的模型名替换为真实可用 ID两个模型生成长度差异巨大max_tokens 设置不同或模型提前结束检查输出长度统一 max_tokens增加要模型“继续输出”的提示词但不要虚构工具评测结果不稳定重跑差异大随机顺序或解码随机性未控制检查 seed 和随机策略固定 seed多次运行取中位数规则评分全是 0 分或全是满分关键元素设计不合理人工抽检原始答案重新设计关键词表或改用 LLM 评测器某道题两个模型都答错题目本身存在歧义人工复盘题目表述删除或改写歧义题最容易忽略的一点是接口返回的缓存和限流策略会影响耗时但不影响内容。评测耗时只反映当时的网络状态不要把它当作模型性能指标。如果你要测耗时需在同一网络条件下、夹带多个样本交替运行多次取中位数。9. 最佳实践与工程建议评测模型和写业务代码一样要有工程约束。以下几个建议来自实际踩坑能帮你减少无效劳动。9.1 评测数据必须防污染模型训练数据可能包含公开评测集。如果你直接把网上的公开题目拿来做评测很可能测不出真实能力因为模型早就“背”过答案。更好的做法是从你自己的业务场景中生成题目或者对公开题目做改写改变具体数值和场景设定。比如“容器里有红球、蓝球、绿球”是经典题但线上可以通过随机生成数值来创建变体。每次运行前随机化数字能大幅降低记忆效应。9.2 固定版本和时间戳模型接口的 default 版本可能悄悄变化导致两周前的评测结果无法复现。工程化做法是在结果 JSON 里记录接口调用时的模型完整 ID、日期和代码版本。import datetime meta { evaluated_at: datetime.datetime.now().isoformat(), opus_model_id: claude-opus-5, gpt_model_id: gpt-5.6, prompt_version: v1.0, }这能帮你在模型更新后快速决定“是否需要重跑评测”。9.3 先人工标注再上自动评分自动评分脚本难免有漏判。第一次跑评测时建议人工逐条标注 50~100 个答案再把人工标注结果作为自动评分的校准集。有了校准集后续大规模评测才有可信度。如果直接跳到 LLM-as-a-judge评测器本身的偏好也可能成为新偏差来源。这里的规则是先确认小样本上的人工一致性再扩大规模。9.4 评测维度要有业务权重不同团队对模型能力的优先级完全不同。做客服机器人的团队更看重指令跟随和知识边界做代码助手的团队更看重多步推理和长文本保持。建议在评分统计时给每个维度加权重而不是简单求和weight { fact_accuracy: 0.2, multi_step_reasoning: 0.3, instruction_following: 0.2, counterfactual: 0.1, long_context: 0.2, }这样得出的最终排名才符合你的业务优先级而不是一个“平均分”。9.5 每一轮评测都应该有“失败记录”真正有用的评测不是只记录“谁答对了”还要记录“谁以什么方式答错了”。把失败案例单独抽出来归类是理解模型边界最快的方式。常常出现的情况是A 模型在数学题上输给 B但 A 的错误是“过程正确、最后一位计算失误”而 B 的错误是“从一开始就理解错了题意”。两种错误在生产里的代价完全不同。10. 总结与后续学习方向这篇文章围绕“禁掉所有工具”这个评测思路讲清楚了 Opus 5 和 GPT-5.6 对比评测的方法论与落地实现。核心判断是工具增益会被工程能力抹平模型底座能力不会禁掉工具后两模型在推理完整性、知识边界处理、指令跟随等维度上的真实差异会变得更加清晰。你可以从三个方向继续深入一是把题目集扩展到自己的业务场景形成长期评测集二是引入更细粒度的评测方式比如过程评分、格式合规率、错误分类三是把评测接入 CI/CD在模型版本更新时自动触发重跑。最后提醒一句不要迷信任何一篇文章给出的对比结论包括这篇。模型版本迭代太快同样的评测框架跑在不同版本上结论可能完全不同。把方法论和代码保存下来你的业务题目集才是长期有效的评测资产。
