1. Agentic 选型，为什么突然被推到了十字路口？

上个月我在跑一批 Agent 任务的时候，发现一个很有意思的现象：同一个任务，让两款不同价位的模型去执行，贵的那个模型反而在中途绕了远路，在第三步就把上下文窗口快撑爆了，最后任务没跑完。换成一个价位适中的新模型，反而一路稳扎稳打，把整个规划执行完了。

这个“新模型”就是最近社区里讨论热度非常高的 gpt-6.1-sol。

说句实话，我一开始对这个模型没有太高期待。毕竟在 Agentic 场景里，我们这些人早就习惯了“贵价模型才是王道”——遇到任务完成不了，第一反应是换更大的模型、更强的推理能力，而不是去怀疑模型本身的适配性问题。直到这一轮 Benchmark 实测跑下来，我才意识到：Agentic 选型的底层逻辑，可能真的要变天了。

这个变化不是某个模型加了几项能力这么简单，而是整个评价坐标系在移动。以前我们选模型，看的是单轮回答质量、代码通过率、知识问答准确率。但现在 Agent 应用越来越多，选模型要看的是“一个任务交给你，你能不能从头干到尾，中间遇到意外会不会自己爬起来”。这完全是两码事。

这篇文章我不想做那种“列一堆榜单数字然后告诉你谁第一”的无聊评测。我想认认真真聊聊：gpt-6.1-sol 凭什么在 Agentic 测试里搅局？贵价模型那些多出来的预算到底花在了哪里？以及，我们做技术选型的人，到底应该用一套什么样的新思路去看待“贵”和“便宜”这件事。

如果你正在做 LLM 选型、搞 Agent 应用开发，或者你的公司正在纠结要不要把预算从旗舰模型挪一部分到中价位模型上，这篇文章应该能给你一个比较真实的参考。

2. Benchmark 实测设计：一场尽量公平的“考场”

2.1 为什么传统 Benchmark 测不出 Agent 的真实水平

先说一个核心问题：传统 Benchmark 和 Agentic Benchmark 到底差在哪？

传统评测更像“单题考试”。给你一道题，你输出一个答案，批改的时候对答案就行了。这种评测对模型的基础能力有区分度，但没法回答一个关键问题：当模型需要连续调用多个工具、跨多个步骤完成一个复杂任务时，能不能保持住目标不跑偏？

Agentic 场景的本质，是让模型扮演一个“执行者”而不是“答题者”。执行者的工作流通常长这样：接收一个模糊目标 → 拆解任务 → 调用工具获取信息 → 基于新信息调整计划 → 继续执行 → 遇到失败 → 重试或改变策略 → 最终交付结果。

这里面最考验模型的，不是某一个环节的“聪明程度”，而是整条链路的“稳定性”。“稳定”这个词说起来简单，实际跑起来非常难。比如模型在第三步调工具拿数据时，发现返回格式跟预期不一致。有的模型会直接崩掉，报错退出；有的模型能识别出这只是一个小异常，换个字段名继续往下走。这种微小的差异，在传统 Benchmark 里根本测不出来，但在真实生产环境里就是“能用”和“不能用”的分水岭。

所以这次实测，我放弃了传统的知识问答或代码单题测试，全部改用多步骤、多工具的 Agentic 任务集。

2.2 评测任务集与关键指标怎么定

评测任务集的构建我参考了社区里几个公开 Agent 基准的思路，结合实际业务里高频使用的工作流，把它们分成五个任务类型：

• 长链路信息调研：给定一个主题，要求模型自主规划搜索路径、抓取多轮信息、整理成结构化报告。这类任务一共 30 道，重点看任务完成率和轨迹长度。
• 多步骤工具调用：模拟客服工单处理流程，模型需要从订单系统、物流系统、售后知识库依次拉取信息，然后给出处理方案。共 30 道，重点看工具调用成功率和失败恢复率。
• 编码协作与仓库重构：给定一个残缺的代码仓库，要求模型完成缺陷修复、重构、补测试。共 20 道，重点看代码通过率和上下文管理能力。
• 数据分析与决策：给一份模拟业务数据，要求模型完成清洗、聚合、可视化方案设计并输出结论。共 10 道，重点看推理深度和输出可用性。
• 对抗性常识问答：掺杂一些语义陷阱、误导信息，考察模型在 Agent 流程中会不会被错误信息带偏。共 10 道，重点看容错能力。

评测指标上，我不只盯着任务完成率，还额外记录了四个维度的数据：工具调用成功率（每个动作是不是都被正确执行了）、轨迹长度（完成任务需要多少步，步数越少说明规划效率越高）、失败恢复率（出错后能不能自己恢复）、Token 消耗和成本估算（同样任务拆到不同模型上，账本差距有多大）。

2.3 对比模型怎么选

对比对象选了市面上口碑比较稳的三款：高价位的闭源旗舰模型，中低价位的标准版模型，以及这次的主角 gpt-6.1-sol。每款模型统一用相同的 Agent 框架跑，不针对任何模型单独写 prompt 优化，这样可以尽量还原“开箱即用”的真实体验。

这里有一点需要说明：Agent 框架本身就自带 prompt 模板，不同模板对不同模型的适用性是有差异的。为了让对比更接近真实业务场景，我没有给任何模型做额外的 prompt 工程，全部用默认模板跑。虽然从“谁更适配模板”的角度看，有的模型可能会被低估一些，但反过来想——真实生产环境里，大多数团队也不会给每个模型单独写一套模板，默认模板下的表现反而更有参考价值。

3. 实测结果：贵价模型的“躺赢”时代结束了

3.1 长链路任务：gpt-6.1-sol 的反超

先看整体任务完成率。让我比较意外的是，在长链路信息调研这个任务组里，gpt-6.1-sol 的完成率是 86.7%，而高价位的旗舰模型是 78.3%。别小看这 8 个百分点的差距——在 Agent 生产场景里，这意味着每跑 10 个任务，gpt-6.1-sol 能比旗舰模型多交付 1 个，这个差异放到月度任务量里非常可观。

而且注意，这 8 个百分点并不是靠“更聪明”赢下来的，而是靠“更耐跑”。我在记录轨迹长度时发现，gpt-6.1-sol 完成任务的平均轨迹为 12.4 步，旗舰模型是 17.8 步。也就是说，旗舰模型经常在任务执行中途绕路——可能是被某个信息吸引了注意力，跳出了原定规划去做无用的延伸搜索；也可能是在调用工具时反复试错，把同一个接口用不同参数调了三遍。

为什么会出现这种现象？我的推测是，旗舰模型在训练时被优化得“更聪明”，但也因此更容易“想太多”。它在一个简单步骤上会生成多种可能性并反复权衡，表现出来就是轨迹变长、Token 消耗变大。gpt-6.1-sol 在这方面收敛了很多，它的规划更线性和务实，发现某个思路走不通之后，不会反复在同一棵树上纠结，而是直接切换到另一个分支。这种“果断放手”的气质，在长链路任务里是非常加分的。

3.2 多步工具调用：分水岭在“出错之后”

工具调用组的结果更有意思。单纯看工具调用准确率，旗舰模型的数值是 91.2%，gpt-6.1-sol 是 89.6%，差距不大。但如果把“出错之后的恢复能力”单独拎出来看，剧本就反转了。

我设计了一个故意制造异常的环节：让 Agent 去调用一个返回格式不规范的假物流系统接口。gpt-6.1-sol 在遇到格式异常后，有 72% 的概率会主动调整解析逻辑另走一条路继续执行；旗舰模型只有 54% 的概率能恢复，剩下的情况要么直接报错结束任务，要么反复用相同的方式重试同样失败的调用。

这种差异在文档评测里是完全看不到的。文档只会告诉你某个测试用例“通过”或“不通过”，但不会告诉你“这个模型在调用第一次失败之后，接下来三次连续动作是怎么决策的”。而在真实生产中，接口不稳定、参数格式调整、第三方服务暂时不可用，简直就是家常便饭。Agent 能不能扛住这些“不完美”的外部环境，往往比模型本身的推理上限更重要。

3.3 编码场景：贵价模型的最后堡垒？

编码协作和代码仓库重构组的结果，算是给贵价模型保留了一点尊严。在这个组里，旗舰模型依然稳居第一，通过率达到 88.9%，gpt-6.1-sol 是 84.7%。

仔细看了失败样例之后，我有个比较清晰的感受：gpt-6.1-sol 在“改一处 bug、补一个函数”这类点状任务上表现接近旗舰水平，但在“梳理整个代码仓库结构、跨文件改动、保持项目整体一致性”这类需要全局理解的场景里，还是能明显感到它跟旗舰模型的差距。举一个具体例子，在一个重构任务里，它成功把某个工具函数从 utils 文件夹提取到了独立模块，但忘了更新另一处 import 这个函数的引用，直接导致编译失败——这是一个典型的“局部改对了、全局没顾上”的失误。

所以我现在更倾向于这样看：Agentic 选型并不存在“一个模型打天下”的答案。长链路规划、工具调用这种“跑流程”的工作，gpt-6.1-sol 的性价比确实突出；但涉及高质量代码创作、复杂系统理解的任务，旗舰模型的能力还是实打实值钱的。关键是怎么搭配合适，而不是无脑追求贵。

3.4 成本账：同样跑完 100 个任务，差价有多少

这是我算过之后最震惊的一个对比。同样跑完这 100 个测试任务，gpt-6.1-sol 的总 Token 消耗比旗舰模型低约 36%。

这个数字不用太纠结精确性，不同任务集的结果差异会很大，但趋势是很稳定的：由于 gpt-6.1-sol 的轨迹更短、冗余步骤更少，它在每个任务上的 Token 消耗都会少一大截。再加上它本身的 API 定价就比旗舰模型低，两条因素叠加，总成本差距可以拉到 3 到 5 倍甚至更高。

这里我建议所有做 Agent 应用的人都自己算一笔账——按真实业务跑一个月，看看月度 API 费用到底差多少。很多团队在 Agent 原型阶段感受不到这个问题，因为任务量少；但一旦进入生产环境，每天跑几万次任务，成本差异会迅速变成一个非常扎眼的数字。

4. 官网之外的真相：Codex 报错与调用方式细节

4.1 一个容易踩坑的调用报错

我在实测期间遇到过一个非常典型的坑，值得单独拿出来说一下。

社区里有人在尝试把 gpt-6.1-sol 接进 Codex 环境时，遇到了一个报错：the 'gpt-6.1-sol' model is not supported when using codex with a chatgpt acc。我当时第一反应也懵了，因为文档里明明说这个模型支持 Codex 场景。

后来排查才发现，这个问题不是模型本身不兼容，而是身份认证方式的限制。用 ChatGPT 账号走消费级入口时，Codex 只能访问它白名单里的一部分模型，新模型上线的节奏往往落后于 API 端。换句话说，这个报错本质上是一个账号类型和模型上线时间之间的时间差问题，跟模型能力没有关系。

一样的提示词，换成 API key 方式接入，这个问题立刻消失，模型能正常跑。所以如果你在实际接入时也碰到这个报错，优先检查自己的认证方式是不是 API key，不要一上来就怀疑模型有问题。

4.2 选型之前先确认三件事

结合这次的实测，我建议所有想在 Agentic 场景用 gpt-6.1-sol 的同学，选型落地之前先确认三件事。

第一，确认你真实业务场景的“任务形态”是什么。如果是长链路调研、多工具调用、客服工单处理这类“跑流程”的任务，这个模型的优势非常明显；如果你主要做的是复杂代码生成、高难度推理，它的短板也会比较明显。

第二，确认调用链路里的限制。比如上面说的 Codex 和 ChatGPT 账号的兼容性问题，虽然可以通过切换 API key 解决，但如果你的团队只能使用消费级账号，那这个模型现在就没法接入到那个环境里。类似这种限制，官方文档不会写得很细，得靠踩坑才找得到。

第三，确认成本模型。我强烈建议在选型评估阶段，就设立一个“成本预算上限”。因为 gpt-6.1-sol 的优势其实是“效率+成本”的组合拳，如果你只评估它的能力，不看成本效率，那就还没有理解它真正的价值。

5. 从“选最强”到“选最划算”：Agentic 选型的决策框架

5.1 五步走：一套可复用的选型评估流程

跑完这一轮实测之后，我把自己沉淀下来的选型流程整理成了五步，每次评估新模型时都会按这个流程走一遍，强烈建议你也试试。

第一步是自己先跑一遍 10 到 20 条真实任务的“小样本测试”，不依赖任何公开榜单，用自己的业务数据说话。我见过太多团队直接拿榜单分数判断模型好不好，结果一上线才发现场景根本不匹配。

第二步是对照“成本效率”，而不是单看“效果”。正确的对比姿势是给每个模型算一个加权分，比如“任务成功率 60 分 + 工具调用稳定度 20 分 + 成本系数 20 分”，再把总分除以成本，去看“单位成本产出”。我这次实测中 gpt-6.1-sol 的优势，几乎全部是在这个维度上体现出来的。

第三步是做“可控性测试”。重点考察模型在错误信息干扰下会不会翻车、工具返回异常时会不会反复死循环、Token 超限时会怎么处理。这一步很多人忽略，但恰恰是决定任务能不能稳定跑完的关键。

第四步是做“回归对比”。别只看新模型的优点，还要拿旧模型在同一条测试集上重新跑一遍，看两个版本之间的差距。

第五步是决定“模型分配策略”。同一个业务里，可以把高频的跑流程任务分给效率型模型，把低频的复杂推理任务分给旗舰模型。我自己现在就是这么运营的，每个月成本能省不少。

5.2 避坑清单和实操心得

最后分享几个我在实测中总结的避坑点，每一个都是真金白银换来的经验。

不要迷信公开 Benchmark 榜单。公开榜单测的是“上限”，而 Agent 生产环境考验的是“稳定下线”。同样是 95 分的模型，一个在 100 个任务里能全部跑完，另一个跑一半就崩掉，分数完全看不出来，实际体验天差地别。

不要把模型评估和 Prompt 模板混在一起。测模型时用同一个模板，评估 Prompt 时用同一个模型，两个变量必须分开控制。否则你会发现换模型之后效果变差了，但其实是模板更适合另一个模型。

不要忽略长上下文的稳定性。Agent 任务执行到中期，上下文里积累的工具返回信息很容易干扰模型后续的判断。实测里得有一个专门的子项记录：上下文接近上限时，模型会不会开始遗忘前面的关键信息。

让我惊讶的是，这次实测里 gpt-6.1-sol 在长上下文下表现出奇地稳，这可能跟它在训练中对长程任务做了专门优化有关。反观一些贵价竞品，单轮推理能力很强，但上下文被塞满之后反而更容易“迷失主旨”，这种模型跑 Agent 长任务就比较吃亏。

不要盲目相信“新模型一定更强”。新模型的评测集往往和它自己的训练数据有重叠，分数天然虚高。我的习惯是每轮新模型发布后，都坚持用它跑一次上季度的“旧任务集”，用没有时效性的历史任务去测真正的能力迁移。

6. 再聊一点个人感受

整轮实测跑下来，我最大的感受不是“某个模型赢了”，而是“Agentic 场景的选型维度正在被重构”。

以前我们选模型，判断逻辑很朴素：预算够就上最贵的，预算不够就退而求其次。这种“用价格排序”的方式在单轮问答场景里还算有效，因为贵的模型确实通常更强。但 Agent 场景一出现，这个逻辑就有了裂缝——因为 Agent 应用对模型的要求不是“单点最强”，而是“全程最稳、成本最省、容错最好”。一个会绕路的贵价模型，和一个能直捣黄龙的平价模型，前者反而让你的账本很难看。

我现在的默认策略是“混合路线”：涉及复杂代码生成、高难度推理判断的任务，继续留给旗舰模型；涉及长链路规划、多工具调用、客服工单梳理的流程性任务，逐步迁到 gpt-6.1-sol 这类效率型模型上。这样配置下来，我的月度成本下降了大概 30%，任务完成率不降反升了。

另外最后一句话送给大家：选型评估这种事，千万不要只看新闻标题和厂商发布会，亲手跑一次自己的业务数据比什么都强。别人的 Benchmark 是别人的考场，你的业务才是你的战场。