Qwen3 8B/27B 这类小模型能不能用来做 Agent 开发很多人心里没底。我最近搭了一套本地的 Agent 测试流程把工具调用、多轮规划、失败重试这类任务跑了一遍最后整理成一张“能力天梯”。项目标题写作 Qwen3.8-27B我按 Qwen3 系列的 8B 和 27B 两档参数规模来理解。这篇文章就把测试思路、评分维度和踩过的坑完整拆开讲适合正在评估 Qwen3 小模型、准备做本地 Agent 项目的开发者参考。先给一个结论小模型做 Agent最值得看的不是单轮对话质量而是“能不能稳定地把一个任务完整跑完”。很多模型聊起来不错一旦让它输出工具调用、读取工具返回、再决定下一步就会开始乱。8B 和 27B 的差异也主要集中在这个流程控制上而不是简单的“聪明不聪明”。下面按我实际测试的顺序来写。前面是测试设计中间是操作流程后面是排查经验和选型建议。1. 为什么要给 Qwen3 8B/27B 做 Agent 能力天梯1.1 Agent 任务里小模型真正的瓶颈是“流程稳定”Agent 任务的典型工作方式是模型拿到一个目标先规划再选择工具等待工具返回根据返回值继续决策直到任务完成。这个闭环里每一步都要求模型遵守固定格式不能跳步不能自己编造工具返回结果。大模型在 Agent 场景下的问题往往不是“不会回答”而是“不按约定执行”。明明工具返回了空列表模型还可能编一个数字出来。明明要求调用 search_web模型偏要直接输出答案。对小模型来说这个问题会更明显因为参数变小后指令跟随和格式约束能力会跟着下降。所以我在测试前先定了一条原则Agent 能力天梯不是比谁更会聊天而是比谁能在闭环流程里保持稳定。8B 模型可能适合简单问答、单次查询、固定格式输出27B 模型才有更多余力处理多轮规划、条件分支和错误修正。至于 8B 能不能担起复杂 Agent 任务要看框架怎么兜底。1.2 天梯的含义不是排名是能力边界有人把天梯理解成排行榜谁第一谁第二。我做这套测试时不是这个目的。我更想搞清楚在本地硬件、固定框架、固定任务集下8B 和 27B 各自能覆盖到什么复杂度。因此天梯等级更像一个“能力边界描述”。我把它分成五档L0无法完成工具调用频繁出错。L1只能完成单次工具调用输入输出格式需要人工修正。L2能完成多工具顺序调用但遇到异常返回容易失败。L3能处理多轮规划、条件分支和简单纠错。L4能稳定完成一批生产级任务输出可直接进入下游流程。实际测试时同一模型在不同任务上会落在不同等级。比如 8B 在“查天气并给建议”这种单工具任务上可能到 L2在“连续调用三个接口并汇总表单”上可能只有 L0。这很正常天梯的价值就是把这种差异暴露出来。2. 测试前先把环境、模型和 Agent 框架理清楚2.1 本地部署的硬件参考Agent 测试和普通聊天测试不一样。聊天只需要生成一段文字Agent 测试要反复生成、反复解析、反复调用工具。同一个问题可能来回跑五六轮每一轮都要消耗显存和推理时间。我先说常见配置不一定代表官方要求只是按社区和实测经验给一个参考范围。模型规模量化方式显存参考适合任务8B4bit 量化6GB 到 8GB单工具调用、短上下文、低频批量8B8bit 量化10GB 左右单工具调用、简单多轮27B4bit 量化16GB 到 20GB多工具、多轮规划、较长上下文27B8bit 量化24GB 以上生产测试、严格格式场景如果你的显卡只有 8GB优先跑 8B 量化模型。如果显存接近上限就不要开并发也不要设置过长上下文。先跑通再想批量。内存方面模型权重会有一部分加载到内存建议 32GB 起步。磁盘主要看模型文件本身8B 量化文件大概 5GB 到 8GB27B 量化文件大概 15GB 到 22GB。2.2 Agent 框架选型Harness、Tool、Skill 和 Subagent 先分清测试之前我会花时间把 Agent 框架里的几个基础概念理清楚。很多人把 Harness 和 Agent 混在一起实际不是一回事。Harness 是编排层负责把模型、工具、日志、重试、循环控制串起来。Agent 是决策循环负责根据当前状态决定下一步动作。Tool 是外部能力比如查数据库、调用接口、读写文件。Skill 是一段可复用的流程比如“先查询用户信息再生成报表”它比单个 Tool 更接近业务操作。这些概念直接影响测试设计。如果框架不支持清晰的 Tool 定义模型就很容易在格式上翻车。如果所有逻辑都塞进 Prompt小模型很难稳定跟随。我建议在测试前先确认三件事工具定义是否采用结构化 schema。模型输出是否需要约束格式比如 JSON Mode 或函数调用模板。失败重试、超时和日志是否内置。社区里常见的 pi coding agent、hermes agent 都是可以参考的实现。我的建议是不要直接照搬某个框架而是先用最小配置把“模型 工具 返回校验”这条链路跑通再替换或者扩展。2.3 Agent 记忆和子任务主从模式不是银弹Agent 任务一旦多轮就会遇到记忆问题。小模型的上下文窗口有限不能把每轮对话全部塞进去。常用的做法是显式记忆把需要长期保留的信息抽成结构化字段而不是让模型自己从聊天历史里找。另外还有一个常见设计主从模式。主 Agent 负责判断任务要不要拆分Subagent 负责处理子任务。很多人会把 Subagent 当作另一种 Tool 来调用这样主 Agent 的 Prompt 不用包含太多细节每次只调用一个子任务入口。这个模式对 8B 模型有好处因为子任务范围更小格式更容易稳定。但代价是延迟增加因为每多一个 Subagent就要多几次完整的推理和工具往返。测试时要单独计时不能只看最终是否成功。3. 这张“天梯”到底测哪些能力3.1 任务集设计从单工具到多轮调度天梯要能说明问题任务集必须分层。我只测两类“听起来很难”的任务因为那只能验证模型的极限不能验证日常可用性。日常 Agent 任务更多是单次查询、多次顺序调用、条件分支、异常返回处理。我用的任务集大致分四类任务类型输入示例期望输出通过标准单工具调用查询城市天气调用 weather 工具并返回结构化结果正确生成工具名和参数多工具顺序调用查询用户订单再计算总价先调用 query_order再调用 calc_total工具顺序正确条件判断库存不足时给推荐替代品根据返回结果走不同分支分支选择正确异常修正工具返回空数据模型提出重试或换关键词不编造结果能主动纠错这四类任务基本覆盖了实际 Agent 开发里最常见的场景。你不需要一开始就测 50 个任务先把每个类型准备 10 条左右跑通之后再扩。3.2 评分维度不能只看“最终结果”如果只统计“任务是否成功”会漏掉很多问题。比如某次任务虽然成功了但模型调用了两次工具才成功第一次调用生成的是错误参数。这种情况在开发阶段可以容忍在生产环境就会造成额外成本和延迟。我在测试里记录以下维度任务成功率完全完成任务的用例占比。格式合规率模型输出能被框架正确解析的比例。平均轮次完成任务需要的模型调用次数。单轮平均延迟一次模型生成的耗时。失败重试率因输出解析失败而触发重试的比例。死循环概率是否出现连续重复调用同一工具或同一参数的情况。举例来说如果 100 条任务里 90 条最终成功但格式合规率只有 70%说明模型经常输出错误格式最终是靠框架重试和修复才成功。这种结果不能算“稳定”。天梯评分应该把“成功率”和“格式合规率”加权综合起来。3.3 天梯等级划分标准我把“最终成功率”和“格式合规率”组合成等级判定。这只是我自己的规则不是官方标准但它能帮助快速判断模型到底处于哪个阶段。等级判定条件建议用途L0成功率低于 30%格式合规率不稳定不可用需要换模型或改任务L1成功率 30% 到 60%需人工干预只能做概念验证L2成功率 60% 到 80%格式合规率较高可用于内部工具不建议直接对外L3成功率 80% 到 95%格式合规率稳定可进入生产候选L4成功率 95% 以上异常修正良好可面向正式流程这里要强调等级判断标准里异常修正能力必须单列。因为一个 Agent 如果只会走“一帆风顺”的路径遇到工具返回异常就会崩那离可用还差很远。4. 实测流程从单条任务到批量跑分4.1 第一阶段先跑通最小 Agent 调用我先不用复杂框架直接验证模型能否根据系统 Prompt 输出工具调用。这个阶段的目标是确认环境没问题、模型能加载、基础输出能生成。最小流程是加载模型。定义一个最简单的工具比如 get_time。给模型一个任务“现在几点钟请调用 get_time 获取时间。”解析模型输出判断是否包含工具名和参数。这一步不要处理多轮不要加记忆也不要加复杂 Prompt。如果连单工具调用都不稳定后面的多轮规划没有测试价值。我习惯用 JSON 输出做接口约定{ thought: 需要获取当前时间, action: get_time, action_input: {} }不一定要用代码实现但模型输出最好符合这样一个固定结构。如果模型输出是自由文本后续解析会非常痛苦。建议在框架上启用 JSON Mode 或者约束解码不是所有环境都支持但支持的话一定优先用。4.2 第二阶段构造固定输入和输出校验跑通之后把任务集整理成 JSONL 文件。每一条包含id任务编号。input用户输入。tools允许使用的工具列表。expected_action期望调用的工具。expected_args期望的参数。示例{ id: task_001, input: 查询北京今天的天气, tools: [get_weather], expected_action: get_weather, expected_args: {city: 北京} }跑完单条任务后用脚本比对实际输出和期望输出。比对时不要要求 JSON 完全相等因为模型可能多输出一些字段或者参数顺序不一样。重点是校验必要字段是否存在参数类型是否正确以及是否调用了不应该调用的工具。校验逻辑按优先级写action 是否在允许的工具列表内。必要参数是否存在。参数值类型是否正确。是否出现额外工具调用。如果是多轮任务再看工具调用顺序是否与期望一致。4.3 第三阶段批量跑分和日志采集单条任务能跑通后再批量跑。这一步最容易踩的坑是日志缺失。之前跑测试时如果只记录最终成功或失败后面复盘会发现很多问题无法定位。我在批量跑分时会为每个任务记录模型名称、量化方式、采样参数。请求时间、响应时间。模型每次输出的原始内容。解析结果是否合法。工具调用是否成功。重试次数、重试原因。最终状态。把这些字段攒成 CSV 或 JSONL后面做归因非常方便。批量跑分不建议一次性跑太多任务先把数量控制在 100 条以内保证每一条日志都能回溯。如果任务集很大就分片跑每片 50 到 100 条。并发控制也要注意。8B 模型如果显存够可以开 2 个并发27B 模型建议从 1 个并发开始。不要一上来就开最大并发否则容易出现 OOM 或者单条超时。4.4 第四阶段失败用例归因批量跑完把失败用例挑出来逐个归因。我的分类方式输入问题任务描述有歧义模型无法理解。格式问题模型输出了正确意图但 JSON 格式错误。工具问题工具本身报错或者参数 schema 和模型输出不匹配。规划问题模型选错了工具或者调用顺序错误。超时问题模型推理太慢被执行器判定为超时。每一条失败都要落到其中至少一类。如果某个类别数量很多说明问题不在模型本身而是任务设计或框架配置需要调整。比如格式问题多就考虑约束解码或者优化 Prompt。工具问题多就检查工具定义是否清晰。规划问题多说明当前模型的能力不足以处理这类任务需要换更大的模型或者降低任务复杂度。5. 实测中容易踩的坑和排查顺序5.1 执行器超时the agent execution provider did not respond in time 怎么排查这是 Agent 测试中非常常见的报错。完整信息一般是“the agent execution provider did not respond in time. this may indicate the provider is slow or unavailable”。很多人看到这句话就以为模型卡死了实际上原因可能有四种。我按以下顺序排查先看 provider 服务本身是否存活。直接调用一次模型接口看能不能正常返回。再看输入长度。如果输入上下文过长模型推理时间会明显增加。然后看推理速度。有没有开启量化、显存是否足够、CPU 是否被打满。最后看执行器的超时阈值。有些框架默认超时只有 30 秒小模型在低配机器上生成几百个 token 就可能超时。不要一上来就调大超时时间。如果模型已经完全卡死调大超时只会让任务堆积更严重。正确做法是先降低单次生成的 token 上限再看是否还需要调大超时。5.2 小模型输出格式不稳定JSON 截断和中英混排8B 模型在长输出时经常出现 JSON 截断。比如最后一个括号没输出或者参数值中间被截断。这时候框架如果直接 json.loads会直接报错。我的经验是尽量限制模型只输出 JSON不要输出解释性文字。把工具调用放在独立字段里不要混在普通回复中。启用约束解码把输出限制为合法 JSON 格式。如果框架不支持约束解码就增加二次解析比如用正则提取最后一个 JSON 对象。中英混排也很常见。模型在生成 JSON 值时可能突然用中文解释导致结构破坏。解决方法是给每个字段注明语言类型并强调“回答必须严格使用给定 Json 格式”。5.3 显存和并发能跑和能批量是两回事很多人在本地把模型跑起来后就开始开并发结果大批量任务直接把显存打满。原因是每个并发请求都会额外占用一份 KV Cache不是只占一份模型权重。我建议先测单条任务的显存峰值再观察空闲时的显存占用。如果显存剩余不多就不要开并发。宁可让任务排队也不要因为 OOM 中断。批量任务还要考虑输出目录和日志写入。如果所有任务同时写一个文件可能产生写入冲突。我的做法是每个任务一个独立日志文件或者用行级 JSONL 写入避免锁竞争。5.4 结果不一致先查温度、缓存和输入顺序同一个任务跑两次结果不一样。这是正常现象因为采样有随机性。但如果你需要稳定复现就要固定采样参数。批量跑分时建议设置比较低的 temperature比如 0.2 或 0.1。如果框架支持 seed也一并固定。否则你很难判断成绩差异是模型能力变化还是随机性造成的。还有一个容易被忽略的点上下文顺序。工具定义的顺序变了模型对工具的选择可能会变。所以测试时工具列表顺序要锁定Prompt 模板也要锁定不要在测试过程中随意修改。5.5 Agent 记忆、Skill 和 Subagent 的边界小模型的 Agent 记忆不能依赖“把历史全部塞进上下文”。一方面窗口有限另一方面小模型很难在海量历史里准确提取关键信息。我建议把记忆拆成短时和长时短时记忆保留最近两三轮长时记忆用结构化字段存储比如用户意图、任务状态、已完成步骤。Skill 和 Agent 的边界要看任务是否可复用。稳定且重复的流程应该写成 Skill比如“查询订单-计算金额-生成回执”。不确定的任务不要硬塞进 Skill应该让 Agent 动态选择 Tool。Subagent 主从模式不建议一上来就用。先跑单 Agent如果发现单 Agent 经常在不同子任务之间切换导致上下文混乱再考虑把子任务拆给 Subagent。拆的时候要注意Subagent 调用也会消耗 token 和时间复杂性会显著上升。6. 怎么把天梯结果用起来6.1 选型8B 和 27B 的使用场景跑完天梯后我一般会形成一张选型建议表给不同任务推荐不同模型。场景推荐模型原因简单问答、单次工具调用8B 量化延迟低显存占用小固定流程处理8B 或 27B 取决于流程长度流程稳定时 8B 足够多工具顺序调用27B8B 在格式切换时容易出错条件分支、异常修正27B需要更强的逻辑判断能力严格生产环境27B 约束解码输出格式更可靠这里的经验是能用 8B 时不要随意上 27B。因为 27B 在延迟、显存和成本上的代价很明显。但如果是复杂 Agent 任务也不要因为成本硬撑着用 8B否则后面排查和兜底成本更高。6.2 从 Demo 到生产还需要补什么天梯测试只是第一步。真正上线前还需要补齐几个生产组件失败重试调用工具失败后自动重试但要设置最大重试次数。人工审核高风险操作要有人工确认不能让模型直接执行。安全白名单限制模型可用的工具范围不能给一个万能执行器。超时降级单次推理超时后返回降级结果而不是一直卡住。Token 预算控制每个 Agent 任务最多消耗多少 token防止死循环。这些在 Demo 阶段可以忽略但一旦进入正式流程就成了必选项。天梯结果只能证明模型“有潜力”不能证明系统“可上线”。6.3 后续迭代维护一份回归任务集天梯不应该是一次性测试。每换一次模型版本、框架版本或 Prompt 模板都应该重新跑一遍回归集。我的做法是保留一份固定的 JSONL 回归集里面包含 50 到 100 条典型任务覆盖单工具、多工具、条件分支和异常修正。每次迭代后跑一遍用脚本自动生成对比报告。如果某个任务从通过变成失败就说明改动引入了回归。长期来看这份回归集比单次跑分更有价值。因为 Agent 项目最大的风险不是某次测试分数低而是改一个参数后某些原本稳定的能力悄悄退化。天梯的意义就在于此它不是一块奖牌而是一个持续监控模型 Agent 能力的仪表盘。最后留一个我自己的判断习惯先用 8B 跑通最简单的闭环再逐步加任务复杂度。遇到瓶颈时先看是不是任务设计和框架配置的问题最后再考虑换 27B。不要一开始就追求“大模型解决一切”很多 Agent 失败案例问题并不在模型参数而是流程没有被约束清楚。