29B 意图模型 Xing4.0-29B-Intent决策和填空@中国电信开源本地29B模型@袋鼠帝

中国电信悄悄开源本地29B模型，不仅会决策，还能填空，实测夯！

吐槽解读

这篇文章真正的信息量不在「又开源一个模型」，而在评测口径：同一批题、零示例冷启动，把「答案一个不多一个不少」和「该不选时能不选」拆开算分。后者才是生产环境里最贵的事故源——用户随口一句跟业务无关的话，系统非要匹配一个意图然后真的去执行。

对想在自己产品里用小模型做意图路由的读者，可以直接抄两样东西：一是 5606 道意图分类题的冷启动对比表，二是 2000 条电商评论的双模型对测方案——固定随机种子、按品类占比分层抽样、隐藏原标签、每条独立判断，准确率和耗时都按可复现的口径跑。

维度	文章做法	我们的判断
能力定位	选择题 + 填空题一起做	意图路由和参数填充合一，能省掉一层后处理
开源与成本	Apache-2.0，29B 本地可部署	隐私和成本敏感的场景值得试，别只看榜单
免费额度	天翼 API 3 个月 1 亿 tokens	先小流量灰度，把「漏抽参数」当核心指标盯
与 Jev 关系	补齐 Jev 只能做选择的短板	已有 Jev 的系统不必推倒，抽取层补在路由后即可

Jev 爆火带火赛道：不会说话的模型，24 小时接入 13% 付费团队

大家好，我是袋鼠帝。上个月，硅谷开发者圈最火的一个模型，是一个不会说话的模型，叫Jev，是前OpenAI研究员Diogo Almeida发布的模型。它不写文章，也不陪你聊天。你给它一段话和几个选项，它只回你选哪个、有几成把握。就这么一个”哑巴”模型，上线Vercel的AI网关24小时，将近13%的付费团队就接进去用了。一周之内，网上冒出来20来个仿品，Kev、Laya、TinyJev……光Laya一个，开源5天就破了1.9万Star。

说实话，我第一眼看到Jev的时候，心想：我半年前给MobileClaw也干过这事。老粉应该记得，4月我爆肝两天搓了个语音唤醒的Agent App。当时为了省钱，也为了快，我在前面塞了个速度很快的免费模型GLM-4.7-Flash，专门做意图识别：你说”看一眼、这是什么”，它就把摄像头抽的几帧图一起传给后面的大模型；你说帮我设个闹钟，它就只传文字。这其实跟Jev在干的事类似– 做选择题。

但选完之后呢？闹钟设几点，明早7点还是7点半，周末响不响？最后还是得交给后面那个又慢又贵的大模型去执行。再比如你对家里音箱说，把卧室的灯调成暖黄。系统要搞清楚的不止你想开灯，还有哪个房间、亮度调多少、色温调多少。Jev能告诉你，用户想控制灯光。剩下这几个空它管不了，因为它只做选择。关于Jev 这个不会说话的模型的架构细节，可以回看我们此前的解析。我原本以为Jev是个开源模型，结果一搜，发现还是闭源的。。。

星辰实验室开源 Xing4.0-29B-Intent：29B 可本地部署，还送 1 亿 tokens

不过，前两天，我刷到中电信人工智能科技有限公司星辰通用人工智能实验室（下文简称星辰实验室）开源了一个意图理解专用模型，叫 Xing4.0-29B-Intent，名字太长了，就叫它Xing（行）吧，行模型😄，看完感觉它刚好补齐了Jev的短板。关键是开源！！！ 29B完全可以本地部署了～ github.com/XingChen-AGI/Xing4.0-29B-Intent huggingface.co/XingChen-AGI/Xing4.0-29B-Intent

最爽的是，现在天翼AI开放平台，可以免费体验API，有3个月和1亿tokens的免费试用额度。这里直接领取即可。

模型卡（Hugging Face 页面）显示的关键信息：模型大小 31B 参数，张量类型 F32/BF16，8 个 Safetensors 分片，许可证 Apache-2.0，任务标签覆盖文本生成、Transformer、中文与英文，以及意图识别、槽位填充、信息抽取、schema 引导、命名实体识别、关系抽取、事件抽取等方向，关联论文 arxiv:2512.24157 与 arxiv:2507.18013，发布方为 XingChen-AGI，模型卡注明「上月下载量 702」。

天翼 AI 开放平台的产品导览页列出的产品线包括智能语音、智能视觉、星辰大模型、民族语言大模型、多模态大模型、语义大模型、大模型开发平台、星河标训评平台、星海·云智服与城市综合治理解决方案等。在服务列表里，Xing4.0-29B-Intent 与星辰慧笔-35B、表格理解服务、大文件上传监控、智能体版大模型、对话大模型-115B 等服务并列，计费方式为按量计费：输入 0.0015 元/千 tokens，输出 0.006 元/千 tokens，并发限制 5 QPS，资源包可领取 100 百万 tokens。免费额度领取页显示：免费额度 100 百万 tokens，有效期 3 个月，并发 5 QPS，点击「同意并领取」即表示同意天翼 AI 开放平台产品服务协议。

选择题变填空题：一句「改地址」在 Jev 和 Xing 下的完整处理流程

Xing4.0-29B-Intent除了能选择，还能告诉你怎么干、参数是什么。也就是它除了能做选择题，还能做填空题。我刚看到“既能做选择题，又能做填空题”时，其实也有点懵逼：这两件事，放到一个 AI 产品里，到底有啥差异？后来我实际放到程序里面跑了一下，就懂了：

就拿找客服改收货信息这个场景来举例说明一下。比如我说：“这个包裹还没发货，把地址改成杭州市西湖区文三路 88 号，收件人改成林晓。”系统先要判断，我想退款、查物流，还是修改收货信息。这一步就是做选择题：业务类型已经列好，模型根据用户的意思选中其中一个。但选对业务类型，还不足以处理这件事。系统还要把新地址、新收件人分别记下来。这一步像填表（填空）：“地址”和“收件人”两个变量是提前设置好的，模型从原话里提取具体内容赋值即可。

Jev 主要围绕给定选项做判断，也支持是非判断和评分；Xing4.0-29B-Intent 则可以把意图识别与参数抽取一起干了，既判断要办什么业务，也提取后续程序需要的信息。当然，如果地址本来就有几条备选，Jev 也可以选。Xing4.0-29B-Intent更省心的地方，是不必先把所有可能的字段值列成菜单。对系统来说，这一步的价值，是把一句用户要求整理成程序可以继续处理的工单。可能有点抽象，这块还是需要写过代码的人更容易看懂。原作者用一张长流程图把这句话的完整处理过程拆成了 7 步，本文将其转录如下（示例订单编号 ORDER-DEMO-1021，状态待发货，原收货地址北京市朝阳区望京街10号，原收件人陈晨）：

第 1 步，用户发消息，订单先不动。用户在订单页面提出要求，此时只是发消息，订单尚未修改。原订单信息包括：订单编号 ORDER-DEMO-1021、当前状态待发货、原收货地址北京市朝阳区望京街10号、原收件人陈晨。

第 2 步，前端把原话和订单编号发给后台，后台补齐上下文。订单编号来自当前页面，订单状态和旧地址由后台查询，模型不需要猜“用户正在说哪一单”，后台还要验证用户有权操作这笔订单。前端参数包括 message（用户完整原话）、order_id（ORDER-DEMO-1021）、request_id（REQ-DEMO-001，同一操作的重试沿用它，避免重复修改）；后台带上的上下文包括 status（待发货）、current_address（北京市朝阳区望京街10号）、current_recipient（陈晨）、saved_addresses（北京地址、成都地址，本例地址簿里还没有杭州）、recipient_candidates（陈晨、林晓，后台为本例提供的姓名候选）。到这里，两条路径一样，接下来后台交给模型的“题目形式”开始不同。

第 3 步，出题方式分叉：Jev 给选择题，Xing 给填空题。两者都先判断”要办什么事”。Jev 的这次 Choice 请求给出候选：问题1「用户要办什么事？」候选为修改收货信息、查询物流、其他；问题2「用户要求的新地址，是哪一个？」候选为北京市朝阳区望京街10号、成都市高新区天府大道66号、都不匹配/未提及（none）；问题3「新的收件人，是哪一个？」候选为陈晨、不匹配/未提及。后台先列出可以选的值，本例没有把杭州新地址列进选项。Xing 的抽取请求则定义字段：messages 的 content 为任务说明+字段定义+订单上下文+用户原话，字段定义中的 category 指定业务类别，args 指定地址、姓名的含义，后台提前规定要填哪些字段，模型从原话中提取具体地址和姓名填入，不用把所有可能的新地址列成选项。

第 4 步，模型返回的答案形状不同。Jev 返回选择结果：要办的事为修改收货信息，新地址为 none（没有匹配的候选），新收件人为林晓——它选对了业务类型，也选到了姓名，但杭州地址不在这次的候选里，没有选出可用的新地址。Xing 返回类别和参数：要办的事为修改收货信息，新地址为杭州市西湖区文三路88号，新收件人为林晓——它识别出业务类别，再把用户原话中的地址和姓名填进对应字段。Jev 原始返回为 answers 结构（action 的 choice 为 change_shipping、address 的 choice 为 none、recipient 的 choice 为 person_lin）；Xing 的输出是 API content 中的 JSON 文本（category 为“修改收货信息”，args 含“新地址”和“新收件人”）。模型给的是答案或参数，此时两条路径都还没有调用订单修改接口。

第 5 步，后台把两种格式整理成统一参数。Jev 路径：读 key 再查表取回原值——answers 取 action.choice 得到 operation，address_key 为 none 时 new_address 为 null，recipient_key 为 person_lin 时查表得到林晓。Xing 路径：先解析 JSON 再按字段取值——data 解析后取唯一匹配当前业务的结果，operation 由 category 映射为 change_shipping，new_address 取“新地址”字段，new_recipient 取“新收件人”字段。整理后的参数对比如下：

第 6 步，同一套业务校验，执行结果分叉。两条路径都必须通过的检查包括：返回格式可读取、类别与字段合法、必要参数不缺失、用户有权限且订单允许修改。Jev：本例缺少新地址，停止修改并追问，不调用修改接口，订单保持原状（北京市朝阳区望京街10号，收件人陈晨），程序等待补充信息，也可以先构造新候选再请求 Jev。Xing：本例参数齐全、订单待发货，可以继续，调用订单修改接口 order.updateShipping，传入 order_id、recipient（林晓）和幂等键 idempotency_key（REQ-DEMO-001），订单修改后的状态为杭州市西湖区文三路88号、收件人林晓，示例回执为 {“ok”: true}。接口调用成功，才有“已完成”；真实订单服务还应在写入时复查状态、处理并发和重试，若超时导致结果未知，应先查询或用同一操作编号重试。

第 7 步，回复用户的是程序确认后的状态。Jev 路径回复「请提供或确认新的收货地址」，状态为 needs_input（需要补充），order_changed 为 false（未修改），没有调用订单修改接口，原地址和收件人都没有变化。Xing 路径回复「已为你将收货地址修改为杭州市西湖区文三路88号，收件人为林晓」，状态为 completed（已完成），order_changed 为 true（已修改），这句“已修改”来自订单接口的成功回执，不能仅因为模型输出了”修改地址”就告诉用户修改成功。

原作者还补了一个关键说明：如果把杭州地址先加入选项，Jev 也能选到——后台可以先让额外的规则、解析器或其他模型从原话里找出新地址，再把它加入 Jev 的候选列表，此时 Jev 就能选到，后面的校验和修改流程也可以走通。这份例子真正要说明的区别是：Jev 这条 Choice 路径需要程序先准备候选值，Xing 这条抽取路径需要程序先定义字段、再由模型从原话填入具体值，两者最终都需要业务程序校验和执行。对比的是两种具体用法，不能据此说”Jev 不能提取参数”或”Xing 返回 JSON 就一定正确”；候选提取、地址校验、模型调用都涉及成本、延迟与准确率，需要在真实业务中验证。整页为静态流程示例，未调用真实模型或修改真实订单，代码用于说明数据流，省略了部分错误处理。

冷启动 5606 道意图分类题：严格全对 61 分，Jev 最低只有 21 分

我自己也跑了一些Xing4.0-29B-Intent和Jev的案例，下面一个个说。先说大家最关心的，跟Jev正面比。GitHub上Xing4.0-29B-Intent有个表格。准备了5606道意图分类题，所有模型同一批题、同一份提示词，一个示例都不给，全靠模型自己读懂类别描述，也就是冷启动。Jev只能做选择题，所以测了两种回答方法：N个选项里挑一个，和每个选项单独判是非。

第一张表是六维评分（总分、类别分值、事件抽取、命名实体识别、关系抽取、意图理解）：

（转录说明：LongCat-2.0 与 GPT-6-Luna 两行原图分值列不全，按 OCR 可见值依序列出，缺列未补。）

第二张表是严格全对与类别 F1 对比。类别F1，Xing4.0是70，比Jev最好的那种答法高出十几个点，也超过了GPT-4.1，跟GPT-5.5基本打平。拉开差距的是严格全对，也就是答案一个不漏、一个不多才算对。Xing4.0-29B-Intent是61，通用大模型在50到56之间，Jev最低只有21。

最让我意外的是题库里那839道正确答案是什么都不该选的题。Xing4.0-29B-Intent拿了70分，Jev逐个判是非的答法只拿了5分。。有点像考场上那种必须选一个的学生，题目明明在说以上都不对，他还是硬着头皮蒙了个C。如果放到产品里面，这就很要命了：用户随口说了句跟业务无关的话，系统非要给他匹配一个意图，然后真的去执行。。肯定有人会问，这种模型到底有什么实际的用途吗？我实际应用之后，发现还真有很多场景可以用。

电商评论测好差评：2000 条样本 Xing 准确率高 1.3 个百分点，还快 5 秒

要是我第一份工作要是有它就好了。我的第一份工作是在一家做跨境电商的创业公司。有一个工作是过滤差评（哈哈 不给老外展示差评，他们能看到的全是好评），几千万个评论，各式各样，当时是写程序去尽量过滤差评，比如关键词过滤，过滤2颗星以下的评论等等，设置了非常多的条件，逻辑复杂。过滤效果还很一般。PS：当然这种做法肯定是不可取的，我们这里主要讨论模型的应用。不过这家公司在疫情的时候就倒闭了。。。现在用像Xing4.0-29B-Intent这样的模型，效果会更好，而且实现逻辑更简单，速度也很快。

为了验证，也为了对比测试一下Xing4.0-29B-Intent和Jev在选择题上到底孰强孰弱，我专门在网上找了6万条真实的电商评论，覆盖各种品类。数据集文件为 online_shopping_10_cats.csv，11.3 MB，然后它里面还有个label，为1表示好评，为0代表差评，经核实共 62,774 条，其中好评 31,728 条、差评 31,046 条。表中还有 1 条空评论、重复文本，以及 18 组同一句话同时标为好评和差评的情况，需要在抽样前按统一规则处理。

6万条太多了，测试起来比较费时。所以我让codex帮我收取了每种品类各200条好评和差评，抽齐2000条，丢给Xing4.0-29B-Intent和jev去判断好评和差评。因为有标准答案，所以最后很方便判断准确性。方案设计如下：数据清理删除空评论、相同文本去重、同文不同标签整组排除并保留清理记录；抽取 2,000 条为好差评各 1,000 条，各标签内部按原有品类占比分层抽样；固定随机种子并保存抽样文件，两个模型使用完全相同的评论；模型输入只给评论和统一判定标准、隐藏原标签、每条独立判断。完成时间口径为：从该模型第一条正式请求发出，到全部 2,000 条处理结束，包括重试和等待，不包括抽样、联调及生成报告，并补充单条请求的中位耗时与 P95 耗时，避免仅看平均值掩盖慢请求。两个模型使用各自的原生分类接口，统一任务含义和类别定义。结论边界也提前写明：准确率是与原数据标签的一致率，原标签也可能有错；耗时是当前网络和 API 接入下的实际完成时间，包含网关、网络及服务端排队，不能直接称为模型自身推理速度。程序页面显示两张模型进度卡，最终给出答对数、全量准确率、有效完成率、总完成时间，可以筛选错题、查看双方分歧并导出 CSV 和报告。正式请求共 4,000 次，另有联调和必要重试。三个默认值为：好差评各 1,000 条、按品类占比分层、每模型并发 5。

测试结果如下。可以看到Xing4.0-29B-Intent的正确率会高一些，完成得也更快。

本批 2000 条评论覆盖 10 个品类，好差评各 1000 条。Xing 多答对 26 条，准确率高 1.30 个百分点。Jev 的单条首次成功响应中位数更低：0.240 秒，Xing 为 0.877 秒——全量更快但单条首响更慢，说明 Xing 把时间花在了吞吐并发上。

接进开源截图工具 Ta：聊天截图自动打码，6.77 秒处理完

还有个非常🐂🍺的用法，我把Xing4.0-29B-Intent融入了我的开源项目Ta，它是一个 AI原生截图工具。先给你们看下我是怎么用的，我通过Xing4.0-29B-Intent的能力，给Ta新增了一个「智能标注」功能。

比如我写文章，经常需要用到一些微信聊天记录的截图。但是每次都需要给聊天记录里面所有头像、昵称、备注的电话、群名等打码。这样不仅繁琐，还容易漏打码，有一次就是忘记给聪哥的电话打码了，都是看评论区有人提醒才知道🤣。。所以这次利用Xing4.0-29B-Intent的判断能力，可以实现截图之后自动打码，而且处理速度也很快，关键可以免费～

Ta（拓）的 GitHub 仓库信息：定位为 AI 原生截图工具，功能覆盖截图、OCR、AI 识图、翻译、长截图、钉图与标注，AI 美化持续开发中；现支持 macOS，Windows 版制作中（.NET8 移植）；仓库 66 Star、12 Fork、31 次提交，MIT 许可，技术标签含 swift、swiftui、appkit、paddleocr、ocr、long-screenshot 等。

Ta 的设置页显示，「智能标注」的模型配置为：自动标注使用 Xing（默认，提取敏感片段）；打码范围仅限微信聊天身份（头像、昵称、群名、引用/置顶作者）和各类私密信息（身份证号、电话、APIKey 等），重点内容、提示词、操作按钮独立加红。模型服务可在 Jev 与 Xing 之间选择，完整接口地址为 api-maas.teleai.com.cn/v1/chat/completions，模型 ID 为 Xing4.0-29B-Intent，APIKey 留空则保留已有密钥；Xing 请求直接连接、绕过系统代理，TLS 校验保持开启，没有自动重试，每次请求都可能产生 API 费用。

实际演示效果：对一张微信聊天截图执行自动标注，结果为马赛克 8 处、红框 0 处、共 6.77 秒，可调整或撤销，双击红框或马赛克可删除。它能快速判断处理哪些地方是要打码的，并自动打码。你看它连引用的那种名字也能打码，确实方便不少～除了打码，写教程需要画红框时，也可以让它自动框选，不需要的框选可以手动去除，还是挺方便的。这里也跟Jev对比了一下，Jev还是有点问题啊，第二次直接啥都没选，第三次还给打上马赛克了。。。

虽然，这种功能用正常的大模型也能实现。但是开源的小模型xing，不仅免费，而且非常快。就是非常适合在这种小节点上发光发热。这就是属于它的位置。所以，大家也可以想想，自己的产品，自己的业务，是否有可以融入的地方，不仅可以提高速率，还能本地部署使用，降低成本，还能保证数据私密性。

最后

写这篇文章的时候，我一直在思考一个问题。做判断的AI，早就有了。ChatGPT出来之前，搜索广告要判断你爱不爱点击，邮箱要判断是不是垃圾邮件，小爱同学、Siri这些语音助手背后，也是一套意图识别加槽位填充：先判断你想干嘛，再把时间、地点这些参数提取出来。Xing4.0-29B-Intent这次评测用到的ATIS，是1990年的航空订票语料；SNIPS是2018年一家语音助手公司放出来的数据集。都是老演员了。更好玩的是，最火的开源Jev平替Laya，底座用的是ModernBERT，算是2018年那个BERT的后代。所以Jev爆火，是不是轮回？我觉得是。但要说是旧瓶装新酒，我不太认同。以前的分类器，标签是训练时就写死的。想加一个查看摄像头回放的意图，得先标几千条数据，再重训一遍。小公司玩不起，所以大家宁愿用程序写规则，就像我第一份工作那样。现在的标签直接写在请求里，相当于现场出题，换一份意图清单就能用。这是有了大模型之后才做得到的，这些专用模型本身就是从大模型底座里练出来的。

再说说小模型。很多人可能觉得大模型越来越强，小模型就没活路了。我感觉不是。Jev这个名字取自经济学家杰文斯：蒸汽机越省煤，煤反而用得越多。AI可能也一样，单次判断越便宜，用到的地方就越多。Agent跑一圈，背后是成百上千次小判断，不可能每次都用最贵的那个模型。这与此前我们讨论本地多 Agent 工作流怎么搭时的结论一致：小判断交给小而快的模型，是控制成本最直接的手段，关于开源大模型到底怎么盈利的讨论也指向同一趋势。

但只会做选择题可能还不够。Agent真要干活，最后都需要调工具，调工具要的是参数。光知道用户想开灯没用，得知道开哪盏、开多亮。所以我觉得，意图模型下一步拼的是谁能把参数填对、填全，这也是我觉得Xing4.0-29B-Intent这条路走对了的地方。还有一点，Jev目前只有托管API，服务在美国西海岸。但手机、车机、智能家居对延迟和隐私都敏感，国内厂商要落地，大概率还得靠开源、能本地部署的模型。所以，我推荐有需要的朋友都可以去试试开源的Xing4.0-29B-Intent。

如果这篇文章阅读量能超过2w，后续我将分享如何在本地部署使用Xing4.0-29B-Intent，感兴趣的朋友可以多多三连😄 我是袋鼠帝，一个致力于帮你把AI变成生产力的博主。我们下期见～ 能看到这里的都是凤毛麟角的存在！如果觉得不错，随手点个赞、在看、转发三连吧~ 如果想第一时间收到推送，也可以给我个星标⭐ 谢谢你耐心看完我的文章～