讯飞Spark X2.5 4B端侧小模型实测：断网本地运行Claude Code完成Agent任务

小模型的能力边界正在被打破

很长一段时间里，业界对小模型存在一种刻板印象：参数小意味着能力弱，只能应付简单对话，遇到复杂的、多步骤的任务就会力不从心。但最近开源界的一个动向，正在改写这个认知。

讯飞开源了两个端侧小模型——Spark X2.5 4B 和 Spark X2.5 1.7B。前者定位为能扛住更重智能体任务的主力，后者则更轻量，可以跑在手机或边缘设备上。真正让人意外的不是它们的参数规模，而是它们在断网、本地、无需大显卡的条件下，依然能稳定调用工具、执行 Agent 任务。

为了验证这一点，一个直接的做法是：把 4B 模型装进 Claude Code，然后彻底关掉网络，看它到底能不能干活。

断网实测：合同对比与多语言分析

第一个测试选了一个日常办公中相当头疼的场景——多版本合同对比。任务要求模型比较三份合同的主要条款，标注每处修改所在的条款和页码，并生成一份合同差异表和待确认问题清单。

整个过程在断网状态下完成，数据完全不需要上传云端。模型准确识别出了三个版本合同中的差异点，整理成差异汇总表，对于表述存在冲突的地方还单独列出了确认清单。结果核对下来是正确的。

第二个测试考验的是多语言能力。这个 4B 模型号称支持 200 多种语言，于是设定了一个跨境电商的场景：手上有一批英语和西班牙语的商品评论，需要归纳用户最满意和最不满意的地方，统计高频问题，生成中文分析报告，并为两种语言分别生成客服回复模板。

从跨语言理解、问题分布统计，到产品优势与痛点梳理，再到高频问题的深度分析，最后输出回复模板——整个链路都跑通了。一个 4B 的端侧模型能一口气完成这么长的任务链，确实超出了不少人的预期。

本地办公：文件归类与代码审查

端侧小模型最大的价值之一，是处理那些不方便上传云端的敏感资料。

测试的第三个场景是客户资料的批量整理。指令很简单：把文件夹里的文档按指定格式重新命名，命名完成后统一放进新文件夹归档。模型能够识别每份资料对应的客户名称和创建日期，按统一规则批量重命名，并自动创建新文件夹完成归档。

原本散落在桌面、命名混乱的客户资料，被整整齐齐地归好类。整个过程不需要逐个打开文档、复制名称、修改文件名再移动位置，而且——涉密的客户资料完全没有外传风险。

第四个测试则明显上了强度：在断网状态下处理一个真实代码项目。本地文件夹里放了一份存在多个问题的代码文件，让 Spark X2.5 4B 直接读取并完成审查。

模型开始自主读取项目、逐步审查代码，汇总所有 bug，并写出每个 bug 的具体问题和修改方案。遇到报错就继续检查修正，直到项目重新跑起来。这已经不是简单地补全一段代码，而是在本地完成了读项目、找问题、修改、测试、验证的完整闭环，全程代码和业务数据都留在本机。

值得一提的是，这两个模型可以深度适配 Claude Code、Codex 和 Open Cloud，并且是用全国产算力训练出来的。

为什么端侧小模型值得关注

可能有人会质疑：云端大模型能力更强，为什么还要折腾小模型？

答案在于并非所有任务都适合把数据送出去。很多公司的数据压根不允许外传；云端 Agent 经常出现不稳定的情况；而每天频繁调用 API 的费用也难以控制。

在这个背景下，1.7B 和 4B 的小模型如果能够调用工具、执行多步骤任务、具备 Agent 能力，还带有 100 万上下文，那么部署在本地就不再只是一个离线聊天框，而是一个能实际干活的本地 AI 助手。它满足了「既要数据安全，又要能力可用」的双重需求。

从技术路线上看，讯飞的做法有点反其道而行：当大多数玩家都在把模型做得更大、把能力推向云端时，它选择把 Agent 能力压进 1.7B 和 4B 的小模型，让普通电脑和手机也能在本地干活，断网也能跑。

模型的价值不再只关乎大小

这次实测传递出一个更本质的信号：衡量 AI 是否有用，最终要看我们手边的工作能不能放心地交给它。

从这个角度看，模型的大小已经不是唯一标准，能不能解决实际问题才是关键。当一个本地小模型能在断网环境里处理真实工作、解决日常问题时，这本身就足够有价值了。

把 AI 做强是一种进步，而让这份能力在更多设备上真正用起来，同样是一种进步。对于关心数据隐私、又希望降低使用成本的个人和企业来说，端侧小模型的这一波突破，值得亲自上手体验。