1. 多模型混战时代为什么要在 pi-agent 里做横向对比过去半年我一直在用 pi-agent 这个轻量级智能体框架做日常的自动化任务编排。选它的原因很简单接口抽象干净模型切换成本极低同一个工作流里可以同时挂载多个推理后端跑对比测试的时候不用来回改代码。最近 Opus 5.5 和 GPT-6 陆续开放了新的推理档位加上 DeepSeek、GLM、Qwen 这几家国产模型在 agent 场景下的表现越来越能打我就花了两周时间在 pi-agent 里搭了一套完整的横向评测流水线把 reasoning efforts 这个维度单独拎出来做了系统性对比。这篇文章不聊跑分榜单那些数字网上到处都是。我想聊的是在真实 agent 工作流里不同模型的 reasoning effort 设置到底怎么影响任务完成质量、token 消耗和响应延迟以及 DeepSeek、GLM、Qwen 这些模型在 pi-agent 里接入时有哪些坑。如果你正在做多模型路由、成本优化或者单纯想知道什么任务该用哪个模型、开几档推理这篇应该能帮你省不少试错时间。先说结论方向Opus 5.5 在复杂推理链上依然稳但 GPT-6 的 reasoning effort 调节粒度更细适合做精细化成本控制DeepSeek 在代码类 agent 任务里性价比突出GLM 的中文指令遵循在 pi-agent 的工具调用场景下表现意外地好Qwen 则在长上下文任务里更从容。下面我把整套评测方法、参数配置、踩过的坑全部拆开讲。2. pi-agent 的模型接入架构与 reasoning effort 机制2.1 pi-agent 为什么适合做多模型对比pi-agent 的核心设计是把推理后端和工具执行层彻底解耦。每个模型通过一个 provider adapter 接入adapter 负责把 pi-agent 内部的统一消息格式转换成各家 API 的原生格式同时把 reasoning effort、temperature、max_tokens 这些参数映射到对应模型的参数体系里。这个设计的好处是我只需要在配置文件里改一行 provider 名称整个 agent 的工具链、记忆管理、任务分解逻辑全部复用。对比测试的时候变量控制得非常干净——唯一的差异就是模型本身和它的推理档位。pi-agent 的配置文件结构大致是这样的providers: opus55: type: anthropic model: opus-5.5 reasoning_effort: high max_tokens: 8192 gpt6: type: openai model: gpt-6 reasoning_effort: medium max_tokens: 8192 deepseek: type: openai-compatible base_url: https://api.deepseek.com/v1 model: deepseek-chat reasoning_effort: high glm: type: openai-compatible base_url: https://open.bigmodel.cn/api/paas/v4 model: glm-5.3-flash thinking_budget: 4096 qwen: type: openai-compatible base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 model: qwen-max reasoning_effort: medium注意这里有个关键差异Opus 5.5 和 GPT-6 用的是reasoning_effort这个枚举参数而 GLM 用的是thinking_budget这种 token 预算式的控制。DeepSeek 和 Qwen 虽然走 OpenAI 兼容接口但 reasoning 相关的参数支持程度各不相同。这个差异直接影响了我在 pi-agent 里做统一抽象的方式。2.2 reasoning effort 到底是什么为什么它比 temperature 更重要很多人调模型只关注 temperature觉得随机性调低一点就更准了。但在 agent 场景下temperature 影响的是输出的多样性而 reasoning effort 影响的是模型在给出答案之前愿意花多少思考预算。打个比方temperature 像是让一个人用不同的语气说话而 reasoning effort 像是决定这个人遇到问题是想三秒就答还是拿张草稿纸推演五分钟再答。对于需要多步推理、工具调用链、错误回溯的 agent 任务后者才是决定成败的关键。在 pi-agent 里reasoning effort 的设置会直接影响三个指标任务完成率复杂任务比如多文件代码重构、跨 API 数据聚合在低推理档位下容易漏步骤或产生幻觉调用。Token 消耗高推理档位会产生大量内部思考 token虽然不全部计入输出但计费上通常按输入输出总量算。首 token 延迟推理档位越高模型想的时间越长流式输出的首 token 到达时间明显推后。我实测下来同一个任务在 Opus 5.5 上从 low 切到 high完成率从 71% 提升到 94%但 token 消耗翻了 2.3 倍首 token 延迟从 1.2 秒涨到 4.8 秒。这个 trade-off 必须根据任务类型来定不能一刀切。2.3 各家模型的 reasoning 参数映射关系在 pi-agent 里做统一抽象时我整理了一张参数映射表这是整个评测的基础模型原生参数可选档位映射到 pi-agent 内部Opus 5.5reasoning_effortlow/medium/high直接透传GPT-6reasoning_effortminimal/low/medium/high直接透传多一档 minimalDeepSeek无显式参数靠 prompt 引导通过系统提示词注入逐步推理指令GLMthinking_budget1024/2048/4096/8192映射为 low/medium/high/ultraQwenenable_thinkingtrue/false二值无法细粒度控制这张表解释了一个很重要的问题不是所有模型都支持细粒度的 reasoning effort 控制。DeepSeek 和 Qwen 在这方面的原生支持较弱需要靠 prompt engineering 来模拟。这也是为什么我在 pi-agent 里给它们单独写了 adapter 逻辑。3. 评测任务设计与参数配置实操3.1 三类典型 agent 任务的选取为了让对比结果有参考价值我设计了三类任务覆盖 agent 最常见的应用场景第一类多步工具调用任务。给 agent 一个自然语言指令比如查一下北京、上海、广州未来三天的天气对比温差生成一份出行建议表格。这个任务需要 agent 依次调用天气 API、做数据对比、生成结构化输出。考察的是推理链的完整性和工具调用的准确性。第二类代码理解与重构任务。给 agent 一个约 800 行的 Python 项目要求它找出其中的性能瓶颈并给出重构方案。这个任务需要深度代码理解、跨文件推理、方案权衡。考察的是高推理档位下的深度思考能力。第三类长上下文信息聚合任务。给 agent 一份 5 万字的会议记录要求提取所有待办事项、责任人、截止时间并生成结构化清单。考察的是长上下文下的信息保持和提取精度。每类任务我跑了 20 次取平均值同时记录完成率、token 消耗、首 token 延迟、总耗时四个指标。3.2 pi-agent 工作流配置的关键参数在 pi-agent 里跑这些任务有几个配置项直接决定了评测的公平性agent: max_iterations: 15 tool_timeout: 30s retry_on_failure: true max_retries: 2 memory_window: 10 system_prompt: | 你是一个严谨的任务执行助手。在执行多步任务时 请先规划步骤再逐步执行每步执行后确认结果。 遇到不确定的信息优先调用工具验证不要臆测。max_iterations设成 15 是因为我测试的任务最多需要 12 步工具调用留一点余量。retry_on_failure开启后工具调用失败会自动重试避免因为网络抖动影响评测结果。memory_window设成 10 意味着 agent 能记住最近 10 轮对话这对多步任务很关键。注意如果你也在做类似评测务必把retry_on_failure和max_retries固定住。我第一轮测试时忘了统一这个参数结果 Opus 5.5 因为重试次数多完成率虚高后来修正后数据才可比。3.3 reasoning effort 档位的具体设置针对三类任务我给每个模型设置了不同的 reasoning 档位组合任务类型Opus 5.5GPT-6DeepSeekGLMQwen多步工具调用mediummediumprompt引导2048enable_thinking代码重构highhighprompt引导4096enable_thinking长上下文聚合mediumlowprompt引导2048enable_thinking这里有个细节GPT-6 在长上下文聚合任务上我用了 low因为这类任务主要是信息提取不需要深度推理开高推理档位反而容易过度思考导致输出冗余。实测 GPT-6 在 low 档位下完成率 96%high 档位下 97%但 token 消耗差了 1.8 倍明显不划算。DeepSeek 因为没有原生 reasoning 参数我在系统提示词里注入了这样的引导在执行任务前请先在内部逐步推理 1. 这个任务需要哪些步骤 2. 每步需要调用什么工具 3. 可能出现的错误和应对方案 然后再开始执行。这个 prompt 引导的效果有限后面会详细说。4. 实测数据与各模型表现深度拆解4.1 多步工具调用任务GLM 意外领先这类任务的结果最让我意外。按直觉Opus 5.5 和 GPT-6 应该碾压国产模型但实际数据是模型完成率平均 token首 token 延迟总耗时Opus 5.5 (medium)92%42002.1s18sGPT-6 (medium)90%38001.8s16sDeepSeek85%31001.1s12sGLM (2048)94%29000.9s11sQwen82%34001.3s14sGLM 完成率最高而且 token 消耗和延迟都是最低的。我分析原因是这类任务的核心是工具调用的格式遵循和步骤顺序GLM 在中文指令下的工具调用格式输出非常稳定很少出现参数格式错误。而 Opus 5.5 和 GPT-6 偶尔会想太多在简单任务上过度推理反而增加了出错概率。DeepSeek 表现中规中矩85% 的完成率主要失分在工具调用参数格式上有几次把日期格式写错导致 API 返回错误。Qwen 的 82% 完成率则是因为它在多步任务中偶尔会跳步直接给出最终答案而省略中间工具调用。实操心得如果你的 agent 任务以工具调用为主且指令是中文GLM 在 2048 thinking budget 下是性价比最高的选择。别盲目迷信大模型任务类型匹配比模型大小更重要。4.2 代码重构任务Opus 5.5 的深度推理优势显现到了代码重构这类需要深度推理的任务格局完全变了模型完成率方案质量评分平均 token总耗时Opus 5.5 (high)94%8.7/10980042sGPT-6 (high)91%8.4/10860038sDeepSeek78%7.2/10620028sGLM (4096)81%7.5/10680031sQwen74%6.9/10710033sOpus 5.5 在 high 档位下的方案质量明显领先它找出的性能瓶颈更准确重构方案也更考虑边界情况。我印象很深的一个案例在一个涉及数据库批量操作的代码里Opus 5.5 不仅指出了 N1 查询问题还主动分析了事务边界和连接池配置的影响这是其他模型都没做到的。GPT-6 紧随其后方案质量差距不大但 token 消耗更低说明它的推理效率更高。DeepSeek 在这个任务上掉到了 78%主要问题是它对大型代码库的跨文件理解能力偏弱经常只看到局部而忽略全局。GLM 在 4096 thinking budget 下拿到了 81%对于国产模型来说已经很不错了。它的优势在于代码注释和文档理解但在纯逻辑推理上还是差一档。4.3 长上下文聚合任务Qwen 的长上下文优势第三类任务的结果又不一样模型提取准确率遗漏率平均 token总耗时Opus 5.5 (medium)96%3%1200052sGPT-6 (low)97%2%950041sDeepSeek89%9%880038sGLM (2048)91%7%820035sQwen95%4%1020045sQwen 在这类任务上表现突出95% 的准确率接近 Opus 5.5而且它对中文长文本的处理更自然提取出的待办事项表述更符合中文习惯。这跟 Qwen 本身的长上下文训练数据有关。GPT-6 在 low 档位下拿到 97% 准确率说明这类任务确实不需要高推理档位。Opus 5.5 虽然准确率也高但 token 消耗最大性价比不如 GPT-6。DeepSeek 的 89% 准确率暴露了它在长上下文信息保持上的短板有几次把不同会议的待办事项混淆了。4.4 综合成本效益分析把三类任务的 token 消耗和完成率综合起来我算了一个有效任务成本指标——用总 token 消耗除以完成率得到每完成一个任务的平均成本模型工具调用成本代码重构成本长上下文成本Opus 5.545651042612500GPT-6422294519794DeepSeek364779499888GLM308583959011Qwen4146959510737GLM 在工具调用和长上下文任务上成本最低DeepSeek 在代码任务上成本最低但完成率也最低。GPT-6 的综合成本效益最均衡。5. 接入实操中的坑与排查技巧5.1 DeepSeek 在 pi-agent 里的 prompt 引导失效问题前面提到 DeepSeek 没有原生 reasoning 参数我靠 prompt 引导来模拟。但实测发现这个引导在复杂任务里经常失效——模型会在前几轮遵循逐步推理的指令但到了后面几轮就忘了直接给答案。我的解决方案是在 pi-agent 的 adapter 里做了一个推理提醒注入每 3 轮对话自动在系统消息里追加一次推理引导。代码大致是这样def inject_reasoning_reminder(messages, interval3): if len(messages) % interval 0: messages.append({ role: system, content: 提醒请继续逐步推理不要跳步。 }) return messages这个改动让 DeepSeek 在代码重构任务上的完成率从 78% 提升到了 83%虽然还是不如原生支持 reasoning 参数的模型但差距缩小了。注意这种注入方式会增加 token 消耗每 3 轮多一次系统消息。如果你的任务轮次很多要算一下成本是否划算。5.2 GLM thinking_budget 设置过高的反效果GLM 的 thinking_budget 我一开始设了 8192想着思考预算给足总没错。结果发现在简单任务上高 budget 反而导致模型过度思考输出一堆无关的分析完成率从 94% 掉到了 87%。后来我把 budget 按任务复杂度分档简单工具调用 2048中等任务 4096复杂推理才用 8192。这样调整后整体完成率回到了 93% 以上token 消耗还降了 15%。这个经验说明reasoning effort 不是越高越好要跟任务复杂度匹配。我现在的原则是够用就好多给浪费。5.3 Qwen 的 enable_thinking 二值困境Qwen 只支持 enable_thinking 开或关没有中间档位。这在 pi-agent 里做精细控制很麻烦。我的做法是在 adapter 层做任务分类如果任务被判定为简单就关闭 thinking如果判定为复杂就开启。判定逻辑用一个轻量规则引擎实现def should_enable_thinking(task): complex_keywords [重构, 分析, 对比, 推理, 优化] if any(kw in task for kw in complex_keywords): return True if len(task) 500: return True return False这个规则引擎的准确率大概 85%会有误判但比一刀切好很多。5.4 常见问题速查表问题现象可能原因排查方法解决方案工具调用参数格式错误模型对工具 schema 理解不足检查工具定义是否清晰在系统提示词里加工具调用示例任务中途跳步reasoning effort 过低提高推理档位重试切换到 high 档位或增加 prompt 引导首 token 延迟过高推理档位过高对比不同档位延迟降低档位或改用流式输出token 消耗异常推理链过长或重复检查是否有循环调用设置 max_iterations 上限长上下文信息丢失模型上下文窗口不足检查输入 token 数分段处理或换长上下文模型中文指令理解偏差模型中文训练数据不足用中英文混合指令测试优先选中文能力强的模型5.5 多模型路由的实用策略跑完这一轮评测我在 pi-agent 里配了一套动态路由策略根据任务类型自动选模型和推理档位工具调用类任务且指令为中文GLMthinking_budget 2048代码理解与重构Opus 5.5 或 GPT-6reasoning_effort high长上下文信息聚合GPT-6 low 或 Qwen成本敏感型批量任务DeepSeek配合推理提醒注入需要最高质量的单次任务Opus 5.5 high这套策略跑了一个月整体任务完成率 91%比之前固定用 Opus 5.5 的方案成本降低了约 40%。6. 推理档位调优的进阶经验6.1 用 A/B 测试确定最优档位不要凭感觉设 reasoning effort。我的做法是对每个高频任务类型用不同档位各跑 10 次记录完成率和 token 消耗画一条边际收益曲线。当提高档位带来的完成率提升小于 token 成本增加时那个档位就是最优解。以 Opus 5.5 的代码重构任务为例档位完成率平均 token边际完成率/千tokenlow76%5200-medium88%74005.5%high94%98002.5%从 medium 到 high每千 token 只换来 2.5% 的完成率提升而 low 到 medium 是 5.5%。所以 medium 是性价比拐点除非任务对质量要求极高否则 medium 就够了。6.2 推理档位与 temperature 的联动reasoning effort 和 temperature 不是独立的。我实测发现高推理档位下temperature 的影响会被削弱——因为模型想得更多输出的确定性本身就提高了。反过来低推理档位下temperature 的影响更明显。所以我的建议是高推理档位配 temperature 0.3-0.5低推理档位配 temperature 0.1-0.3。这样能在保证推理质量的同时避免输出过于死板。6.3 监控推理 token 的隐藏成本很多模型的 reasoning token 是单独计费的或者在账单里不显式展示。我在 pi-agent 里加了一个 token 审计模块把每次调用的输入 token、输出 token、推理 token 分开记录。跑了一个月后发现推理 token 平均占总 token 的 35%高推理档位下能到 55%。这部分成本如果不监控很容易超预算。def audit_tokens(response): return { input: response.usage.prompt_tokens, output: response.usage.completion_tokens, reasoning: getattr(response.usage, reasoning_tokens, 0), total: response.usage.total_tokens }这个审计模块帮我发现了一个问题GLM 在 thinking_budget 4096 时实际推理 token 经常只用了 2000 左右说明 budget 设高了但模型没用到。后来我把 budget 降到 3072效果一样但预算更准。6.4 模型切换时的上下文兼容处理在 pi-agent 里做多模型路由时最大的坑是上下文格式不兼容。不同模型对 system message、tool call 格式、多轮对话的处理方式有差异。我的做法是在 adapter 层做标准化所有模型统一用 pi-agent 内部格式adapter 负责转换。但有个细节要注意Opus 5.5 和 GPT-6 对 system message 的位置敏感必须放在最前面GLM 和 Qwen 则允许 system message 出现在对话中间。切换模型时如果不做处理会导致指令遵循度下降。我在 adapter 里加了一个normalize_messages函数根据目标模型的要求重排消息顺序。这个改动让跨模型切换的任务完成率提升了约 8%。7. 一些个人体会这套评测跑下来最大的感受是没有最好的模型只有最适合当前任务的模型加推理档位组合。Opus 5.5 在深度推理上确实强但用它跑简单工具调用就是浪费GLM 在中文工具调用场景下性价比极高但代码重构能力还有差距DeepSeek 需要额外的 prompt 工程才能发挥推理能力Qwen 的长上下文是优势但推理档位控制太粗。如果你也在 pi-agent 或类似框架里做多模型编排我的建议是先把任务分类做清楚再针对每类任务做小规模 A/B 测试确定最优档位最后用动态路由把流量分配到最合适的模型上。这个过程前期投入大概两三天但长期看能省下大量 token 成本和调试时间。另外提醒一句各家模型的 API 参数和计费方式变化很快我这套配置跑了一个月就遇到两次参数调整。建议把模型配置做成可热更新的别硬编码在代码里不然每次调整都要重新部署。 
长河君 · 2026/11/2 5:40:00 · 阅读 1.2k pi-agent 多模型横向评测：Opus 5.5、GPT-6、DeepSeek、GLM、Qwen 的 reasoning effort 实战对比
1. 多模型混战时代为什么要在 pi-agent 里做横向对比过去半年我一直在用 pi-agent 这个轻量级智能体框架做日常的自动化任务编排。选它的原因很简单接口抽象干净模型切换成本极低同一个工作流里可以同时挂载多个推理后端跑对比测试的时候不用来回改代码。最近 Opus 5.5 和 GPT-6 陆续开放了新的推理档位加上 DeepSeek、GLM、Qwen 这几家国产模型在 agent 场景下的表现越来越能打我就花了两周时间在 pi-agent 里搭了一套完整的横向评测流水线把 reasoning efforts 这个维度单独拎出来做了系统性对比。这篇文章不聊跑分榜单那些数字网上到处都是。我想聊的是在真实 agent 工作流里不同模型的 reasoning effort 设置到底怎么影响任务完成质量、token 消耗和响应延迟以及 DeepSeek、GLM、Qwen 这些模型在 pi-agent 里接入时有哪些坑。如果你正在做多模型路由、成本优化或者单纯想知道什么任务该用哪个模型、开几档推理这篇应该能帮你省不少试错时间。先说结论方向Opus 5.5 在复杂推理链上依然稳但 GPT-6 的 reasoning effort 调节粒度更细适合做精细化成本控制DeepSeek 在代码类 agent 任务里性价比突出GLM 的中文指令遵循在 pi-agent 的工具调用场景下表现意外地好Qwen 则在长上下文任务里更从容。下面我把整套评测方法、参数配置、踩过的坑全部拆开讲。2. pi-agent 的模型接入架构与 reasoning effort 机制2.1 pi-agent 为什么适合做多模型对比pi-agent 的核心设计是把推理后端和工具执行层彻底解耦。每个模型通过一个 provider adapter 接入adapter 负责把 pi-agent 内部的统一消息格式转换成各家 API 的原生格式同时把 reasoning effort、temperature、max_tokens 这些参数映射到对应模型的参数体系里。这个设计的好处是我只需要在配置文件里改一行 provider 名称整个 agent 的工具链、记忆管理、任务分解逻辑全部复用。对比测试的时候变量控制得非常干净——唯一的差异就是模型本身和它的推理档位。pi-agent 的配置文件结构大致是这样的providers: opus55: type: anthropic model: opus-5.5 reasoning_effort: high max_tokens: 8192 gpt6: type: openai model: gpt-6 reasoning_effort: medium max_tokens: 8192 deepseek: type: openai-compatible base_url: https://api.deepseek.com/v1 model: deepseek-chat reasoning_effort: high glm: type: openai-compatible base_url: https://open.bigmodel.cn/api/paas/v4 model: glm-5.3-flash thinking_budget: 4096 qwen: type: openai-compatible base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 model: qwen-max reasoning_effort: medium注意这里有个关键差异Opus 5.5 和 GPT-6 用的是reasoning_effort这个枚举参数而 GLM 用的是thinking_budget这种 token 预算式的控制。DeepSeek 和 Qwen 虽然走 OpenAI 兼容接口但 reasoning 相关的参数支持程度各不相同。这个差异直接影响了我在 pi-agent 里做统一抽象的方式。2.2 reasoning effort 到底是什么为什么它比 temperature 更重要很多人调模型只关注 temperature觉得随机性调低一点就更准了。但在 agent 场景下temperature 影响的是输出的多样性而 reasoning effort 影响的是模型在给出答案之前愿意花多少思考预算。打个比方temperature 像是让一个人用不同的语气说话而 reasoning effort 像是决定这个人遇到问题是想三秒就答还是拿张草稿纸推演五分钟再答。对于需要多步推理、工具调用链、错误回溯的 agent 任务后者才是决定成败的关键。在 pi-agent 里reasoning effort 的设置会直接影响三个指标任务完成率复杂任务比如多文件代码重构、跨 API 数据聚合在低推理档位下容易漏步骤或产生幻觉调用。Token 消耗高推理档位会产生大量内部思考 token虽然不全部计入输出但计费上通常按输入输出总量算。首 token 延迟推理档位越高模型想的时间越长流式输出的首 token 到达时间明显推后。我实测下来同一个任务在 Opus 5.5 上从 low 切到 high完成率从 71% 提升到 94%但 token 消耗翻了 2.3 倍首 token 延迟从 1.2 秒涨到 4.8 秒。这个 trade-off 必须根据任务类型来定不能一刀切。2.3 各家模型的 reasoning 参数映射关系在 pi-agent 里做统一抽象时我整理了一张参数映射表这是整个评测的基础模型原生参数可选档位映射到 pi-agent 内部Opus 5.5reasoning_effortlow/medium/high直接透传GPT-6reasoning_effortminimal/low/medium/high直接透传多一档 minimalDeepSeek无显式参数靠 prompt 引导通过系统提示词注入逐步推理指令GLMthinking_budget1024/2048/4096/8192映射为 low/medium/high/ultraQwenenable_thinkingtrue/false二值无法细粒度控制这张表解释了一个很重要的问题不是所有模型都支持细粒度的 reasoning effort 控制。DeepSeek 和 Qwen 在这方面的原生支持较弱需要靠 prompt engineering 来模拟。这也是为什么我在 pi-agent 里给它们单独写了 adapter 逻辑。3. 评测任务设计与参数配置实操3.1 三类典型 agent 任务的选取为了让对比结果有参考价值我设计了三类任务覆盖 agent 最常见的应用场景第一类多步工具调用任务。给 agent 一个自然语言指令比如查一下北京、上海、广州未来三天的天气对比温差生成一份出行建议表格。这个任务需要 agent 依次调用天气 API、做数据对比、生成结构化输出。考察的是推理链的完整性和工具调用的准确性。第二类代码理解与重构任务。给 agent 一个约 800 行的 Python 项目要求它找出其中的性能瓶颈并给出重构方案。这个任务需要深度代码理解、跨文件推理、方案权衡。考察的是高推理档位下的深度思考能力。第三类长上下文信息聚合任务。给 agent 一份 5 万字的会议记录要求提取所有待办事项、责任人、截止时间并生成结构化清单。考察的是长上下文下的信息保持和提取精度。每类任务我跑了 20 次取平均值同时记录完成率、token 消耗、首 token 延迟、总耗时四个指标。3.2 pi-agent 工作流配置的关键参数在 pi-agent 里跑这些任务有几个配置项直接决定了评测的公平性agent: max_iterations: 15 tool_timeout: 30s retry_on_failure: true max_retries: 2 memory_window: 10 system_prompt: | 你是一个严谨的任务执行助手。在执行多步任务时 请先规划步骤再逐步执行每步执行后确认结果。 遇到不确定的信息优先调用工具验证不要臆测。max_iterations设成 15 是因为我测试的任务最多需要 12 步工具调用留一点余量。retry_on_failure开启后工具调用失败会自动重试避免因为网络抖动影响评测结果。memory_window设成 10 意味着 agent 能记住最近 10 轮对话这对多步任务很关键。注意如果你也在做类似评测务必把retry_on_failure和max_retries固定住。我第一轮测试时忘了统一这个参数结果 Opus 5.5 因为重试次数多完成率虚高后来修正后数据才可比。3.3 reasoning effort 档位的具体设置针对三类任务我给每个模型设置了不同的 reasoning 档位组合任务类型Opus 5.5GPT-6DeepSeekGLMQwen多步工具调用mediummediumprompt引导2048enable_thinking代码重构highhighprompt引导4096enable_thinking长上下文聚合mediumlowprompt引导2048enable_thinking这里有个细节GPT-6 在长上下文聚合任务上我用了 low因为这类任务主要是信息提取不需要深度推理开高推理档位反而容易过度思考导致输出冗余。实测 GPT-6 在 low 档位下完成率 96%high 档位下 97%但 token 消耗差了 1.8 倍明显不划算。DeepSeek 因为没有原生 reasoning 参数我在系统提示词里注入了这样的引导在执行任务前请先在内部逐步推理 1. 这个任务需要哪些步骤 2. 每步需要调用什么工具 3. 可能出现的错误和应对方案 然后再开始执行。这个 prompt 引导的效果有限后面会详细说。4. 实测数据与各模型表现深度拆解4.1 多步工具调用任务GLM 意外领先这类任务的结果最让我意外。按直觉Opus 5.5 和 GPT-6 应该碾压国产模型但实际数据是模型完成率平均 token首 token 延迟总耗时Opus 5.5 (medium)92%42002.1s18sGPT-6 (medium)90%38001.8s16sDeepSeek85%31001.1s12sGLM (2048)94%29000.9s11sQwen82%34001.3s14sGLM 完成率最高而且 token 消耗和延迟都是最低的。我分析原因是这类任务的核心是工具调用的格式遵循和步骤顺序GLM 在中文指令下的工具调用格式输出非常稳定很少出现参数格式错误。而 Opus 5.5 和 GPT-6 偶尔会想太多在简单任务上过度推理反而增加了出错概率。DeepSeek 表现中规中矩85% 的完成率主要失分在工具调用参数格式上有几次把日期格式写错导致 API 返回错误。Qwen 的 82% 完成率则是因为它在多步任务中偶尔会跳步直接给出最终答案而省略中间工具调用。实操心得如果你的 agent 任务以工具调用为主且指令是中文GLM 在 2048 thinking budget 下是性价比最高的选择。别盲目迷信大模型任务类型匹配比模型大小更重要。4.2 代码重构任务Opus 5.5 的深度推理优势显现到了代码重构这类需要深度推理的任务格局完全变了模型完成率方案质量评分平均 token总耗时Opus 5.5 (high)94%8.7/10980042sGPT-6 (high)91%8.4/10860038sDeepSeek78%7.2/10620028sGLM (4096)81%7.5/10680031sQwen74%6.9/10710033sOpus 5.5 在 high 档位下的方案质量明显领先它找出的性能瓶颈更准确重构方案也更考虑边界情况。我印象很深的一个案例在一个涉及数据库批量操作的代码里Opus 5.5 不仅指出了 N1 查询问题还主动分析了事务边界和连接池配置的影响这是其他模型都没做到的。GPT-6 紧随其后方案质量差距不大但 token 消耗更低说明它的推理效率更高。DeepSeek 在这个任务上掉到了 78%主要问题是它对大型代码库的跨文件理解能力偏弱经常只看到局部而忽略全局。GLM 在 4096 thinking budget 下拿到了 81%对于国产模型来说已经很不错了。它的优势在于代码注释和文档理解但在纯逻辑推理上还是差一档。4.3 长上下文聚合任务Qwen 的长上下文优势第三类任务的结果又不一样模型提取准确率遗漏率平均 token总耗时Opus 5.5 (medium)96%3%1200052sGPT-6 (low)97%2%950041sDeepSeek89%9%880038sGLM (2048)91%7%820035sQwen95%4%1020045sQwen 在这类任务上表现突出95% 的准确率接近 Opus 5.5而且它对中文长文本的处理更自然提取出的待办事项表述更符合中文习惯。这跟 Qwen 本身的长上下文训练数据有关。GPT-6 在 low 档位下拿到 97% 准确率说明这类任务确实不需要高推理档位。Opus 5.5 虽然准确率也高但 token 消耗最大性价比不如 GPT-6。DeepSeek 的 89% 准确率暴露了它在长上下文信息保持上的短板有几次把不同会议的待办事项混淆了。4.4 综合成本效益分析把三类任务的 token 消耗和完成率综合起来我算了一个有效任务成本指标——用总 token 消耗除以完成率得到每完成一个任务的平均成本模型工具调用成本代码重构成本长上下文成本Opus 5.545651042612500GPT-6422294519794DeepSeek364779499888GLM308583959011Qwen4146959510737GLM 在工具调用和长上下文任务上成本最低DeepSeek 在代码任务上成本最低但完成率也最低。GPT-6 的综合成本效益最均衡。5. 接入实操中的坑与排查技巧5.1 DeepSeek 在 pi-agent 里的 prompt 引导失效问题前面提到 DeepSeek 没有原生 reasoning 参数我靠 prompt 引导来模拟。但实测发现这个引导在复杂任务里经常失效——模型会在前几轮遵循逐步推理的指令但到了后面几轮就忘了直接给答案。我的解决方案是在 pi-agent 的 adapter 里做了一个推理提醒注入每 3 轮对话自动在系统消息里追加一次推理引导。代码大致是这样def inject_reasoning_reminder(messages, interval3): if len(messages) % interval 0: messages.append({ role: system, content: 提醒请继续逐步推理不要跳步。 }) return messages这个改动让 DeepSeek 在代码重构任务上的完成率从 78% 提升到了 83%虽然还是不如原生支持 reasoning 参数的模型但差距缩小了。注意这种注入方式会增加 token 消耗每 3 轮多一次系统消息。如果你的任务轮次很多要算一下成本是否划算。5.2 GLM thinking_budget 设置过高的反效果GLM 的 thinking_budget 我一开始设了 8192想着思考预算给足总没错。结果发现在简单任务上高 budget 反而导致模型过度思考输出一堆无关的分析完成率从 94% 掉到了 87%。后来我把 budget 按任务复杂度分档简单工具调用 2048中等任务 4096复杂推理才用 8192。这样调整后整体完成率回到了 93% 以上token 消耗还降了 15%。这个经验说明reasoning effort 不是越高越好要跟任务复杂度匹配。我现在的原则是够用就好多给浪费。5.3 Qwen 的 enable_thinking 二值困境Qwen 只支持 enable_thinking 开或关没有中间档位。这在 pi-agent 里做精细控制很麻烦。我的做法是在 adapter 层做任务分类如果任务被判定为简单就关闭 thinking如果判定为复杂就开启。判定逻辑用一个轻量规则引擎实现def should_enable_thinking(task): complex_keywords [重构, 分析, 对比, 推理, 优化] if any(kw in task for kw in complex_keywords): return True if len(task) 500: return True return False这个规则引擎的准确率大概 85%会有误判但比一刀切好很多。5.4 常见问题速查表问题现象可能原因排查方法解决方案工具调用参数格式错误模型对工具 schema 理解不足检查工具定义是否清晰在系统提示词里加工具调用示例任务中途跳步reasoning effort 过低提高推理档位重试切换到 high 档位或增加 prompt 引导首 token 延迟过高推理档位过高对比不同档位延迟降低档位或改用流式输出token 消耗异常推理链过长或重复检查是否有循环调用设置 max_iterations 上限长上下文信息丢失模型上下文窗口不足检查输入 token 数分段处理或换长上下文模型中文指令理解偏差模型中文训练数据不足用中英文混合指令测试优先选中文能力强的模型5.5 多模型路由的实用策略跑完这一轮评测我在 pi-agent 里配了一套动态路由策略根据任务类型自动选模型和推理档位工具调用类任务且指令为中文GLMthinking_budget 2048代码理解与重构Opus 5.5 或 GPT-6reasoning_effort high长上下文信息聚合GPT-6 low 或 Qwen成本敏感型批量任务DeepSeek配合推理提醒注入需要最高质量的单次任务Opus 5.5 high这套策略跑了一个月整体任务完成率 91%比之前固定用 Opus 5.5 的方案成本降低了约 40%。6. 推理档位调优的进阶经验6.1 用 A/B 测试确定最优档位不要凭感觉设 reasoning effort。我的做法是对每个高频任务类型用不同档位各跑 10 次记录完成率和 token 消耗画一条边际收益曲线。当提高档位带来的完成率提升小于 token 成本增加时那个档位就是最优解。以 Opus 5.5 的代码重构任务为例档位完成率平均 token边际完成率/千tokenlow76%5200-medium88%74005.5%high94%98002.5%从 medium 到 high每千 token 只换来 2.5% 的完成率提升而 low 到 medium 是 5.5%。所以 medium 是性价比拐点除非任务对质量要求极高否则 medium 就够了。6.2 推理档位与 temperature 的联动reasoning effort 和 temperature 不是独立的。我实测发现高推理档位下temperature 的影响会被削弱——因为模型想得更多输出的确定性本身就提高了。反过来低推理档位下temperature 的影响更明显。所以我的建议是高推理档位配 temperature 0.3-0.5低推理档位配 temperature 0.1-0.3。这样能在保证推理质量的同时避免输出过于死板。6.3 监控推理 token 的隐藏成本很多模型的 reasoning token 是单独计费的或者在账单里不显式展示。我在 pi-agent 里加了一个 token 审计模块把每次调用的输入 token、输出 token、推理 token 分开记录。跑了一个月后发现推理 token 平均占总 token 的 35%高推理档位下能到 55%。这部分成本如果不监控很容易超预算。def audit_tokens(response): return { input: response.usage.prompt_tokens, output: response.usage.completion_tokens, reasoning: getattr(response.usage, reasoning_tokens, 0), total: response.usage.total_tokens }这个审计模块帮我发现了一个问题GLM 在 thinking_budget 4096 时实际推理 token 经常只用了 2000 左右说明 budget 设高了但模型没用到。后来我把 budget 降到 3072效果一样但预算更准。6.4 模型切换时的上下文兼容处理在 pi-agent 里做多模型路由时最大的坑是上下文格式不兼容。不同模型对 system message、tool call 格式、多轮对话的处理方式有差异。我的做法是在 adapter 层做标准化所有模型统一用 pi-agent 内部格式adapter 负责转换。但有个细节要注意Opus 5.5 和 GPT-6 对 system message 的位置敏感必须放在最前面GLM 和 Qwen 则允许 system message 出现在对话中间。切换模型时如果不做处理会导致指令遵循度下降。我在 adapter 里加了一个normalize_messages函数根据目标模型的要求重排消息顺序。这个改动让跨模型切换的任务完成率提升了约 8%。7. 一些个人体会这套评测跑下来最大的感受是没有最好的模型只有最适合当前任务的模型加推理档位组合。Opus 5.5 在深度推理上确实强但用它跑简单工具调用就是浪费GLM 在中文工具调用场景下性价比极高但代码重构能力还有差距DeepSeek 需要额外的 prompt 工程才能发挥推理能力Qwen 的长上下文是优势但推理档位控制太粗。如果你也在 pi-agent 或类似框架里做多模型编排我的建议是先把任务分类做清楚再针对每类任务做小规模 A/B 测试确定最优档位最后用动态路由把流量分配到最合适的模型上。这个过程前期投入大概两三天但长期看能省下大量 token 成本和调试时间。另外提醒一句各家模型的 API 参数和计费方式变化很快我这套配置跑了一个月就遇到两次参数调整。建议把模型配置做成可热更新的别硬编码在代码里不然每次调整都要重新部署。