端侧Agent实战：从2.6B模型到稳定工具调用的关键路径

我第一次看到“LFM2.5-2.6B”这个命名时第一反应是去查它的参数量说明。后来发现真正值得关注的不是“2.6B”这串数字而是名字里后半段——On-Device Agents。这两年端侧模型并不少见国内外的手机厂商、芯片厂商、开源社区都在推 1B 到 7B 的小参数模型。但把“Agent”三个字直接写进模型命名里说明设计目标变了它不是为了“让设备能聊天”而是为了让设备具备“自己动手完成任务”的能力。这是一个完全不同的工程命题。如果你也正在做端侧 AI 应用或者想把一个能调用工具、能执行多步任务的 Agent 塞进笔记本、手机、边缘盒子里这篇内容值得往下看。我会从端侧 Agent 和普通端侧大模型的区别讲起再拆解 2.6B 这个规模为什么有代表性最后落到评估、迭代和落地边界上。1. 先搞清楚端侧“Agent”和普通“端侧大模型”到底差在哪很多人容易把“端侧大模型”和“端侧 Agent”混为一谈。它们确实有重叠但目标完全不同。普通端侧大模型的核心能力是文本生成。你输入一句话它输出一段回复。模型被部署在手机或本地设备上解决的是隐私、延迟和离线可用性。它本质上还是一个“对话工具”只是跑在设备上而已。Agent 模型不一样。它的核心能力是“完成任务”。任务可能是查一下本地文件、填一张表单、把一段录音转成会议纪要、根据日历帮你安排下一步动作。这些任务往往不是一次性生成文本就能搞定的而是需要模型理解意图、拆分步骤、调用外部工具、读取执行结果、再决定下一步做什么。1.1 聊天模型只需要“说”Agent 模型需要“做”举个最简单的例子。普通聊天模型拿到这个需求“帮我把桌面上叫《周报模板》的文档复制到工作目录。”它最多给你生成一段文字好的你可以打开文件管理器找到周报模板然后复制粘贴到工作目录。这不算完成。真正的端侧 Agent 应该直接调用文件系统工具找到目标文件执行复制操作然后返回结果“已经帮你复制到工作目录路径是 xxx。”如果文件不存在它还需要告诉用户“没找到叫《周报模板》的文件”或者“找到两个相似文件请确认”。这个差异背后是模型架构和训练目标的变化。普通模型只需要预测下一个 token但 Agent 模型需要学会输出“动作”而不是“描述”。它需要在一段对话里维护任务状态知道当前做到哪一步、下一步调用哪个工具、工具返回的结果是否合理。这也是为什么一个 2.6B 的模型如果只是做文本生成看起来并没有多惊艳但一旦加上工具调用和任务编排能力它就可以从“会聊天的模型”升级成“能办事的代理”。1.2 工具调用才是 Agent 模型的骨架我看过不少端侧 Agent 的实现第一块硬骨头不是模型本身推理能力有多强而是工具调用链路能不能走通。工具调用的基本循环是用户输入一个自然语言目标。模型理解意图输出一个结构化动作调用哪个工具、传什么参数。执行层运行工具得到结果。执行结果作为文本回传给模型。模型根据观察结果决定是继续下一步、结束任务还是向用户提问。这个过程很像人在完成一件工作时的闭环先想清楚目标再动手观察结果调整方案。模型在其中扮演的是“决策大脑”工具层则是“手和脚”。端侧 Agent 落地时工具层往往比模型本身更容易出问题。工具定义得不清晰、参数描述不准确、返回格式不统一模型就很容易产生“幻觉式调用”——它以为自己在调用工具实际输出的参数完全不符合 schema。所以我不建议第一步就追求模型能力而是先把 3 到 5 个工具跑通观察模型能不能稳定输出规范的动作指令。1.3 状态管理和错误恢复是端侧 Agent 比云端 Agent 更麻烦的地方云端 Agent 的优势是服务端可以随时记录完整上下文出错后可以重新开始一轮完整的任务规划。但端侧 Agent 的资源有限内存压力更大能保存的上下文窗口更短。如果任务执行到一半遇到异常模型很容易丢失前文状态。常见做法是在模型外面维护一个轻量的“记忆结构”把关键信息单独存下来已经找到的文件、用户确认过的选项、之前调用工具返回的重要字段。不要把什么都塞进模型上下文里。这个“模型负责思考、外部结构负责记忆”的分离是端侧 Agent 建模的核心思路。LFM2.5-2.6B 这类命名里带着 On-Device Agents 的模型通常也会在基础模型之外配套工具调用和记忆管理的工程方案只是因为模型规模小这些外部依赖会显得更重要。2. 2.6B 这个规模为什么是端侧 Agent 的“甜点位”模型命名里的结构一般是“系列名-版本-参数量”。LFM2.5-2.6B 里的 2.6B指的是模型参数量大约 26 亿是一个小规模语言模型。如果这个型号来自某个研究团队通常版本号代表迭代或者训练数据阶段的标识。为什么这类端侧 Agent 模型倾向于选择 2B 左右而不是 0.5B 或者 13B背后其实是设备约束和任务复杂度之间的平衡。2.1 从部署条件反推模型规模端侧设备不是 A100 集群。手机要控制发热和耗电笔记本要保证多任务运行流畅边缘盒子要兼顾成本。模型每大 1B 参数做推理时需要的内存和算力都会明显上升。在常见实践中2B 左右的模型经过 4-bit 或 8-bit 量化后int8 权重大约占用 2 到 3GB 内存int4 可能只需要 1.5GB 左右。这个体积对 8GB 内存的手机、16GB 内存的笔记本来说是可以接受的。如果模型超过 7B量化后的内存占用通常就会超过 4GB 以上在移动设备上长时间运行的压力会大幅增加发热和降频会直接影响响应速度。而 Agent 任务通常需要多轮工具调用不是单次推理所以延迟和功耗会被放大。2.2 小模型做 Agent 的能力缺口在哪里2.6B 模型能做一些事情但不是所有事情都能做好。指令跟随能力简单的“找出文件并复制”可以但“先按日期排序再读取最近 5 份文档提取每个文档的标题并生成一个表格”这种多约束任务容易出现偏差。长上下文理解上下文窗口可以撑到 8K 或 16K但放到 2B 规模时后面的 token 可能记不住关键信息。工具调用稍长一些就容易乱。复杂推理需要多步逻辑推导的任务比如“如果这个文件夹里没有上周的报告就去归档目录里找只找 3 月之后的版本”小模型容易漏掉条件。输出规范约束模型可能输出一个格式不完整的 JSON或者参数名拼错。这在云端大模型里偶尔也会发生在小模型上会更频繁。所以2.6B 模型适合做“目标清晰、步骤不多、工具调用有限的 Agent 任务”。要让它在真实产品里稳定工作不能只靠模型能力必须靠外部工程手段补齐。2.3 工程手段如何补齐小模型的能力短板我自己更愿意把这类端侧 Agent 看成“小模型大管家”的组合而不是“小模型全干”。有四个手段最常用约束解码在生成工具调用时不让模型自由发挥而是用一份 JSON Schema 限制输出结构。这能大幅减少格式错误。示例引导每个工具定义里都附上 1 到 2 个完整调用示例让模型照着生成。任务模板对高频任务做好预设流程模型只负责填充关键参数而不是从头自主规划。外部记忆用数组、字典、SQLite 之类的结构保存任务中间状态而不是全部依赖模型的上下文记忆。这些手段组合起来2B 级模型就能完成不少实用的端侧任务。3. 从拿到模型到跑出一个能用的端侧 Agent如果现在你手里有一个类似 LFM2.5-2.6B 的端侧模型怎么把它变成真正的 Agent我建议分四步走先跑通推理再做工具层再设计循环最后做验证。3.1 先确定运行框架和推理后端目前在端侧跑大模型的通用路径主要有这几种用 llama.cpp 这类本地推理工具或者用 ONNX Runtime、MNN、TFLite 这类移动端推理框架。不少方案还会提供 GGUF 或 ONNX 格式的量化模型。如果这个模型有对话版和工具调优版优先选工具调优版否则后面还要自己补规划能力。拿到模型后先跑一个最小推理测试确认模型能正常加载、输出中文没有乱码、停止符能生效。不要一开始就搭 Agent 流程。常见问题包括模型文件路径不对或格式不匹配。量化版本加载失败通常需要与推理框架版本对应。输出停止符设置不当模型只会一直生成。上下文长度设置过短稍微长一点的任务就被截断。注意这里先别急着调参数。先固定一个极短的 prompt确认基础推理链路通再往上层加东西。3.2 设计工具调用层工具层是 Agent 能“做事”的关键。常见做法是给模型定义一组 JSON Schema然后在 System Prompt 里描述所有可用工具。工具定义要尽量具体字段名要贴近自然语言。比如{ name: search_files, description: 在指定目录中按关键词搜索文件, parameters: { type: object, properties: { keyword: { type: string, description: 要搜索的关键词 }, directory: { type: string, description: 从哪个目录开始搜索默认是当前目录 } }, required: [keyword] } }这个 JSON 会被拼进 System Prompt模型在生成时看到这个描述就更容易按格式输出调用动作。设计工具时有一点很关键把工具的描述写得像“使用说明书”而不是“接口文档”。不要写“keyword: 字符串类型必填”要写“keyword 是你要搜索的文件名关键词比如‘周报’”。小模型对自然语言描述的理解能力比对强类型定义的理解能力好得多。3.3 最小可运行流程一个最小 Agent 循环可以这样设计加载模型和 tokenizer。初始化一个空的历史消息列表。把 System Prompt、工具定义、用户输入拼接起来。让模型生成回复。判断回复内容是“工具调用”还是“直接回复”。如果是工具调用解析 JSON执行工具把结果作为新的消息追加到历史列表然后回到第 4 步。如果是直接回复输出给用户结束。这个过程不需要复杂框架早期用几百行脚本就能验证。关键是先把“模型输出工具调用 → 执行 → 回传结果”这条链路跑通。常见错误有三类模型生成了工具调用但 JSON 解析失败。解决方案是加个兜底解析函数去掉多余字符后再 json.loads。执行工具返回的结果太长超出了模型上下文窗口。解决方案是对工具结果做摘要只保留关键字段。模型进入死循环反复调用同一个工具。解决方案是设置最大步骤数比如最多 5 轮超过就终止并询问用户。跑通这个流程后再考虑扩展到更多工具和真实场景。4. Agent 不能只跑通一次还要能评估、能迭代“能跑通”和“能稳定跑通”之间差着很大的工程投入。很多端侧 Agent 项目在演示时效果很好一到真实设备上就原形毕露。原因很简单Agent 是一个多步骤系统任何一个环节都可能出错。4.1 评估 Agent 和评估聊天模型完全不同评估聊天模型可以直接看回答质量但评估 Agent 要看整条任务链路是否完成。这里有五个维度值得重点盯评估维度考察内容任务完成率给定一个明确任务Agent 是否真正完成了目标而不是只给出了建议工具调用准确率工具名、参数、格式是否正确是否出现幻觉式调用恢复能力工具报错后Agent 能否识别错误并换一种方式重试效率完成同一个任务需要多少轮工具调用是否有冗余步骤安全合规是否执行了用户没有授权的高风险操作是否泄露敏感信息具体执行时要准备一组固定任务集覆盖高频、边缘、异常三类场景。每条任务都设好通过标准比如“复制文件后路径正确且最终回复包含新路径”算通过“只给了建议没执行”算失败。4.2 从失败样本中找到迭代依据Agent 评测的意义不是给一个分数而是找到失败模式的规律。我见过最常见的失败类型有参数理解错误工具要的是绝对路径模型给了相对路径。步骤遗漏任务要求“先搜索再打开”模型只做了搜索。不必要提问明明可以从文件名直接判断模型却非要问用户。错误恢复差工具返回“文件不存在”模型没有尝试变体搜索直接放弃。针对这些失败可以做两类改进。第一类是 prompt 层面的调整给工具定义加示例、给任务模板加约束。这种方法成本低但改善有限。第二类是数据层面的改进把失败样本收集起来构造出正确的工具调用序列然后用这些数据做微调。这个方向对应现在热门的“self-improving agents”思路让 Agent 从自己执行过的任务里总结经验生成新的训练数据再反馈到模型里。对端侧小模型来说微调不能太激进。常见做法是先收集几千条高质量的“指令-工具调用序列”数据做轻量 LoRA 微调。这样可以保留基座模型的通用能力同时提升工具调用能力。4.3 在设备端做迭代的局限有一点要认清端侧设备通常不适合做全参数微调因为算力和内存都不够。更现实的做法是在设备端记录运行日志和失败样本。定期把日志传回开发环境。在开发环境里构造训练数据做微调。发布更新的量化模型给设备端。这样形成一个“端侧推理 云端训练”的闭环。这个流程和端侧模型的特点有关推理可以在设备上做但训练最好还是放到有 GPU 的环境里。5. 适合做什么、不适合做什么端侧 Agent 的边界与工程化建议不管模型叫什么名字On-Device Agent 都有清晰的适用边界。把这部分想明白比调 100 个参数更重要。5.1 适合场景与不适合场景适合做这类端侧 Agent 的场景通常有三个特点数据敏感、延迟敏感、任务相对标准化。数据敏感比如医疗记录、公司内部资料、个人通讯录不适合上传云端。端侧 Agent 直接把工具调用留在设备里体验会好很多。延迟敏感本地推理避免网络往返一个 2B 模型在主流手机上跑几步的延迟通常比云端一次请求要可预期得多。标准化任务比如文件管理、本地搜索、日历操作、记录整理。这类任务工具边界清晰步骤较少小模型可以胜任。不适合做的场景同样明显需要大量知识的开放域问答比如“解释一下某个学科领域的前沿论文”2.6B 模型的储备有限容易胡说。复杂多系统集成比如要同时操作数据库、邮箱、ERP、调度系统还要跨系统验证一致性。这种任务更适合云端大模型。安全关键操作比如自动删除文件、自动发送邮件。如果不加权限确认Agent 一旦误判后果很严重。5.2 长期运行会遇到的坑演示模式下Agent 跑几分钟就结束问题暴露不出来。真正长期在设备端运行会有几个典型问题上下文累积膨胀多轮对话和工具调用结果会不断增大输入长度最终超出模型上下文上限。应对方法是为历史消息设置保留上限只保留最近几轮同时把内存里的关键字段单独存一份。内存泄漏有些推理框架在反复加载/卸载模型时会出现内存增长。要监控设备内存占用必要时做进程重启。权限边界模糊Agent 在执行文件删除、目录移动等操作时必须有鉴权确认机制。不要给模型无条件执行所有工具的能力。任务中断恢复手机锁屏、应用切后台、进程被杀都会让 Agent 任务中断。设计时要考虑任务状态持久化恢复后能接着跑而不是从头再来。日志缺失Agent 系统链路很长没有日志很难排查。建议在每一步工具调用时记录输入参数、输出摘要、耗时、token 数。5.3 排查链路真正遇到问题时按下面这个顺序排查会更有效率看现象是完全没输出、输出乱码还是工具调用没执行、执行了但结果不对还是执行过程卡在某一轮。看输入用户请求是否模糊工具定义里的字段是否和模型输出对得上。看环境模型文件路径、推理框架版本、量化精度、可用内存是否正常。看参数上下文长度、最大生成步数、温度设置、停止符、超时时间。看工具边界工具本身能不能独立跑通还是被模型传的参数带偏了。其中“工具边界”最容易忽略。很多情况下模型并没有错是工具内部有 bug、路径权限不对、返回格式异常。建议先把每个工具单独测试一次确认能独立工作再接入 Agent 流程。最后一个建议回到开头的问题LFM2.5-2.6B 这种端侧 Agent 模型真正改变的是什么我觉得不是参数规模也不是某个具体功能。它把一个更底层的事实说清楚了未来的智能不必全部放在云端设备本身也可以具备“主动完成任务”的能力。模型负责决策设备负责执行隐私和延迟都留在本地。这个方向一旦跑通很多原来因为数据敏感或网络原因做不了的应用会重新有了可能性。如果你准备上手我的建议是先别急着搭复杂框架。拿一个 2B 左右的开源模型先跑通一个工具调用的最小闭环再慢慢加功能。把输入、输出、日志、权限这些边界弄得清清楚楚比一味追模型版本更有用。端侧 Agent 的难度从来不在“跑起来”而在“稳定地完成一个个真实任务”。这一步值得慢慢磨。