很多人一上手就问「千问哪个版本最强」，真到做智能体时却卡在别处：模型该走官方接口还是本地部署、上下文和工具调用怎么配、任务跑不稳到底是模型问题还是流程问题。这篇不排名也不报数，只把千问的架构分层讲清，再给一条能照着走的智能体开发与排查路径，让你在动手前就知道每一步该看什么、去哪核对。
先把一个常见误区说清楚：做智能体之前纠结「千问哪个版本最强」，大概率是在解决一个不存在的问题。真到开发阶段卡住人的，往往是模型走哪种访问形态、上下文怎么管、工具描述怎么写这些具体活。所以这篇不排名也不报数，只把架构分层讲清楚，再给一条能照着走的开发与排查路径。
架构那部分，你只需要关心几件影响开发决策的事：上下文窗口有多大、是不是原生支持工具调用、能不能稳定输出结构化结果、本地机器跑不跑得动。参数规模和版本命名改动很快，动手前到站内模型库核对当时的说明就行，别拿记忆里的数字做判断。
先把千问的架构分层看清楚
把千问理解成三层：底层是基座模型，中间是指令对齐过的对话版本，最上面是视觉、长上下文、代码等专用分支。同一个名字下面常常有好几个不同尺寸、不同模态的成员，你要做的第一件事是确认自己的任务属于哪一类，别拿通用对话版去做需要读图或者塞超长文档的活。
- 上下文窗口
- 一次能塞进去多少内容，直接决定你要不要做检索和分段
- 原生工具调用
- 模型自己会按格式发起外部调用，而不是你写正则去抠文本
- 结构化输出
- 能否稳定吐 JSON 之类的格式，决定你后端要不要写兜底解析
- 可本地部署
- 有没有能在自有硬件上跑起来的尺寸和量化档位
名词容易混的时候，先去站内术语对照页把「参数量」「量化档位」「上下文长度」三个概念分开，这三个东西分别对应成本、能不能跑、和任务能不能一次做完，混在一起判断就会得出错误结论。
走官方接口还是本地部署，先定访问形态
这一步的判断顺序是固定的：数据能不能出内网、调用量稳不稳定、有没有 GPU 预算、团队有没有运维人手。前两项是否定项，先否定哪一项就往哪个方向走。数据完全不能出内网，本地是唯一选项；调用量忽高忽低又想快速验证，托管接口省事得多。
| 判断项 | 倾向官方托管 | 倾向本地部署 |
|---|---|---|
| 数据能否出内网 | 可以出，或可脱敏 | 完全不能出内网 |
| 调用量特征 | 波动大、要弹性扩容 | 平稳可预测、长期占用 |
| 硬件预算 | 不想一次性买卡 | 有稳定 GPU 资源 |
| 运维人手 | 团队没人管推理服务 | 有人能盯着部署和升级 |
混合形态其实是常态：核心数据留在本地，非敏感的高频小任务走托管。两边都跑一遍再定方案，不要一开始就把所有任务押在一种形态上，后面迁移的成本远高于前期多测一轮。
机器够不够这件事别拍脑袋。先去站内算力测算页，按你选的模型和量化档位算一遍需要的显存和并发，再决定是买还是租。租用行情去站内 GPU 租用页面看当时的报价，这里不写具体数字，变动太快。
智能体开发的最小可跑闭环
别一上来就想着自动化整条业务流程，那样第一版一定跑不通。最小闭环的做法是先把任务拆成两类：模型能直接答的，和必须查外部数据或执行动作的。只有后者才需要工具层，前者直接问就行，白白包一层只会增加失败点。
- 定边界把任务逐条拆开，标出哪些需要外部数据、哪些需要执行动作，只给这两类接工具；拆完之后你应该能一眼看出第一版需要几个工具。
- 定工具契约每个工具写清入参、出参、失败时返回什么。工具描述要短而具体，写「查订单状态，入参是订单号」比写一段业务背景强得多，描述含糊是调用失败的头号原因。
- 控上下文把历史对话、检索片段、工具返回结果分开管理，长会话定期做摘要压缩。当前模型能塞多少，去站内模型库看对应说明，别凭印象估。
- 做评测准备二三十条有标准答案的真实任务，每次改提示词或换模型都重跑一遍，看通过率的变化，而不是看某一次回答顺不顺眼。
- 设循环上限显式限制最大轮数和单步超时，否则一个工具反复报错就能把额度和时间一起烧掉，这是最常见的失控方式。
评测集不用多，二三十条能覆盖主要任务类型就够。关键是要固定下来，改一次配置跑一次，不然你根本分不清是改好了还是这次刚好运气好。评测集本身也要定期换掉过时的样例。
跑不稳时的排查顺序
线上不稳，第一件事是分锅：把同一个任务改成单轮直接问模型，如果直接问能答对，问题就在工具层或者上下文拼接上，跟模型本身没关系。这一步能省掉大量瞎调提示词的时间。
- 先查工具描述和参数定义，看模型是否有足够信息判断什么时候该调、传什么
- 再查上下文有没有被截断，检索片段和工具结果是不是把历史挤没了
- 然后看是不是触发了循环，同一个工具被反复调用通常意味着返回值不符合模型预期
- 最后看输出格式，解析失败往往不是模型答错，而是格式不符合你后端的期望
- 排查顺序别跳，跳着查通常会把原因和结果搞反
工具调用频繁失败时，最有效的一招是减少单次交给模型的工具数量。一次给三五个工具，成功率通常明显高于一次给二十个。按任务场景分组，用路由先选一组再交给模型，比堆一个大工具池稳。
需要横向对比不同接入方案或中转服务的实际表现时，用站内检测工具跑一轮，再结合价格追踪页看当时的成本口径。这些数字时刻在变，写死在文章里没意义，去页面看当时的数。
下一步先确定你的数据能不能出内网，这一步决定后面所有方案；然后去模型库核对当前模型的上下文和工具调用支持情况，再去算力测算页估一遍资源，最后拿二三十条真实任务搭一个评测集再开工。→常见问题
通义千问和别的模型比，做智能体有什么不一样？
差别主要在工具调用和长上下文的成熟度上，但这不是选型的唯一依据。更实际的做法是拿你自己的二三十条真实任务，在候选模型上各跑一遍，看完成率和轮数。哪家强还跟你的工具设计和提示词质量强相关，同一模型换个写法结果能差很多。
做智能体一定要用最大的那个版本吗？
不一定。任务拆得清楚、工具描述规范的简单智能体，中等尺寸的模型就能跑得不错，成本和延迟都更低。只有在需要多步推理、复杂规划或者长文档理解时，大尺寸才有明显优势。建议先用小尺寸把流程跑通，确认瓶颈真在模型能力上再往上换。
本地部署千问做智能体，最常踩的坑是什么？
常见的是显存估算不足导致并发一上来就排队，以及量化档位选得太激进让工具调用格式经常出错。先按实际并发和上下文长度算显存，而不是按单条请求算；量化优先保证结构化输出稳定，别只盯着能跑起来。
