端侧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 的实现，第一块硬骨头不是模型本身推理能力有多强，而是工具调用链路能不能走通。

工具调用的基本循环是：

1. 用户输入一个自然语言目标。
2. 模型理解意图，输出一个结构化动作：调用哪个工具、传什么参数。
3. 执行层运行工具，得到结果。
4. 执行结果作为文本回传给模型。
5. 模型根据观察结果，决定是继续下一步、结束任务，还是向用户提问。

这个过程很像人在完成一件工作时的闭环：先想清楚目标，再动手，观察结果，调整方案。模型在其中扮演的是“决策大脑”，工具层则是“手和脚”。

端侧 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 看成“小模型大管家”的组合，而不是“小模型全干”。有四个手段最常用：

1. 约束解码：在生成工具调用时，不让模型自由发挥，而是用一份 JSON Schema 限制输出结构。这能大幅减少格式错误。
2. 示例引导：每个工具定义里都附上 1 到 2 个完整调用示例，让模型照着生成。
3. 任务模板：对高频任务做好预设流程，模型只负责填充关键参数，而不是从头自主规划。
4. 外部记忆：用数组、字典、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 循环可以这样设计：

1. 加载模型和 tokenizer。
2. 初始化一个空的历史消息列表。
3. 把 System Prompt、工具定义、用户输入拼接起来。
4. 让模型生成回复。
5. 判断回复内容是“工具调用”还是“直接回复”。
6. 如果是工具调用，解析 JSON，执行工具，把结果作为新的消息追加到历史列表，然后回到第 4 步。
7. 如果是直接回复，输出给用户，结束。

这个过程不需要复杂框架，早期用几百行脚本就能验证。关键是先把“模型输出工具调用 → 执行 → 回传结果”这条链路跑通。常见错误有三类：

• 模型生成了工具调用，但 JSON 解析失败。解决方案是加个兜底解析函数，去掉多余字符后再 json.loads。
• 执行工具返回的结果太长，超出了模型上下文窗口。解决方案是对工具结果做摘要，只保留关键字段。
• 模型进入死循环，反复调用同一个工具。解决方案是设置最大步骤数，比如最多 5 轮，超过就终止并询问用户。

跑通这个流程后，再考虑扩展到更多工具和真实场景。

4. Agent 不能只跑通一次，还要能评估、能迭代

“能跑通”和“能稳定跑通”之间，差着很大的工程投入。很多端侧 Agent 项目在演示时效果很好，一到真实设备上就原形毕露。原因很简单：Agent 是一个多步骤系统，任何一个环节都可能出错。

4.1 评估 Agent 和评估聊天模型完全不同

评估聊天模型可以直接看回答质量，但评估 Agent 要看整条任务链路是否完成。这里有五个维度值得重点盯：

具体执行时，要准备一组固定任务集，覆盖高频、边缘、异常三类场景。每条任务都设好通过标准，比如“复制文件后路径正确，且最终回复包含新路径”算通过，“只给了建议没执行”算失败。

4.2 从失败样本中找到迭代依据

Agent 评测的意义不是给一个分数，而是找到失败模式的规律。我见过最常见的失败类型有：

• 参数理解错误：工具要的是绝对路径，模型给了相对路径。
• 步骤遗漏：任务要求“先搜索再打开”，模型只做了搜索。
• 不必要提问：明明可以从文件名直接判断，模型却非要问用户。
• 错误恢复差：工具返回“文件不存在”，模型没有尝试变体搜索，直接放弃。

针对这些失败，可以做两类改进。

第一类是 prompt 层面的调整，给工具定义加示例、给任务模板加约束。这种方法成本低，但改善有限。

第二类是数据层面的改进，把失败样本收集起来，构造出正确的工具调用序列，然后用这些数据做微调。这个方向对应现在热门的“self-improving agents”思路：让 Agent 从自己执行过的任务里总结经验，生成新的训练数据，再反馈到模型里。

对端侧小模型来说，微调不能太激进。常见做法是先收集几千条高质量的“指令-工具调用序列”数据，做轻量 LoRA 微调。这样可以保留基座模型的通用能力，同时提升工具调用能力。

4.3 在设备端做迭代的局限

有一点要认清：端侧设备通常不适合做全参数微调，因为算力和内存都不够。更现实的做法是：

1. 在设备端记录运行日志和失败样本。
2. 定期把日志传回开发环境。
3. 在开发环境里构造训练数据，做微调。
4. 发布更新的量化模型给设备端。

这样形成一个“端侧推理 + 云端训练”的闭环。这个流程和端侧模型的特点有关：推理可以在设备上做，但训练最好还是放到有 GPU 的环境里。

5. 适合做什么、不适合做什么：端侧 Agent 的边界与工程化建议

不管模型叫什么名字，On-Device Agent 都有清晰的适用边界。把这部分想明白，比调 100 个参数更重要。

5.1 适合场景与不适合场景

适合做这类端侧 Agent 的场景，通常有三个特点：数据敏感、延迟敏感、任务相对标准化。

• 数据敏感：比如医疗记录、公司内部资料、个人通讯录，不适合上传云端。端侧 Agent 直接把工具调用留在设备里，体验会好很多。
• 延迟敏感：本地推理避免网络往返，一个 2B 模型在主流手机上跑几步的延迟，通常比云端一次请求要可预期得多。
• 标准化任务：比如文件管理、本地搜索、日历操作、记录整理。这类任务工具边界清晰，步骤较少，小模型可以胜任。

不适合做的场景同样明显：

• 需要大量知识的开放域问答，比如“解释一下某个学科领域的前沿论文”，2.6B 模型的储备有限，容易胡说。
• 复杂多系统集成，比如要同时操作数据库、邮箱、ERP、调度系统，还要跨系统验证一致性。这种任务更适合云端大模型。
• 安全关键操作，比如自动删除文件、自动发送邮件。如果不加权限确认，Agent 一旦误判，后果很严重。

5.2 长期运行会遇到的坑

演示模式下，Agent 跑几分钟就结束，问题暴露不出来。真正长期在设备端运行，会有几个典型问题：

1. 上下文累积膨胀：多轮对话和工具调用结果会不断增大输入长度，最终超出模型上下文上限。应对方法是为历史消息设置保留上限，只保留最近几轮，同时把内存里的关键字段单独存一份。

2. 内存泄漏：有些推理框架在反复加载/卸载模型时会出现内存增长。要监控设备内存占用，必要时做进程重启。

3. 权限边界模糊：Agent 在执行文件删除、目录移动等操作时，必须有鉴权确认机制。不要给模型无条件执行所有工具的能力。

4. 任务中断恢复：手机锁屏、应用切后台、进程被杀，都会让 Agent 任务中断。设计时要考虑任务状态持久化，恢复后能接着跑，而不是从头再来。

5. 日志缺失：Agent 系统链路很长，没有日志很难排查。建议在每一步工具调用时记录输入参数、输出摘要、耗时、token 数。

5.3 排查链路

真正遇到问题时，按下面这个顺序排查会更有效率：

1. 看现象：是完全没输出、输出乱码，还是工具调用没执行、执行了但结果不对，还是执行过程卡在某一轮。
2. 看输入：用户请求是否模糊，工具定义里的字段是否和模型输出对得上。
3. 看环境：模型文件路径、推理框架版本、量化精度、可用内存是否正常。
4. 看参数：上下文长度、最大生成步数、温度设置、停止符、超时时间。
5. 看工具边界：工具本身能不能独立跑通，还是被模型传的参数带偏了。

其中“工具边界”最容易忽略。很多情况下模型并没有错，是工具内部有 bug、路径权限不对、返回格式异常。建议先把每个工具单独测试一次，确认能独立工作，再接入 Agent 流程。

最后一个建议

回到开头的问题：LFM2.5-2.6B 这种端侧 Agent 模型，真正改变的是什么？

我觉得不是参数规模，也不是某个具体功能。它把一个更底层的事实说清楚了：未来的智能不必全部放在云端，设备本身也可以具备“主动完成任务”的能力。模型负责决策，设备负责执行，隐私和延迟都留在本地。这个方向一旦跑通，很多原来因为数据敏感或网络原因做不了的应用，会重新有了可能性。

如果你准备上手，我的建议是先别急着搭复杂框架。拿一个 2B 左右的开源模型，先跑通一个工具调用的最小闭环，再慢慢加功能。把输入、输出、日志、权限这些边界弄得清清楚楚，比一味追模型版本更有用。端侧 Agent 的难度从来不在“跑起来”，而在“稳定地完成一个个真实任务”。这一步，值得慢慢磨。