LFM2.5-2.6B端侧Agent实战：部署与工具调用闭环构建-二趣网

很多开发者对端侧小模型的印象，还停留在“能跑个问答、做个文本补全”的阶段。直到真正开始做 Agent 时才发现，云端大模型虽然能力强，但每条请求要上传数据、每轮对话要等网络、每个月还要看账单。于是问题自然就变成了：能不能让 Agent 直接跑在用户设备上，不上云、不等待、不烧接口费？

这就是 On-Device Agents 的切入点，也是 LFM2.5-2.6B 这类模型值得关注的原因。从命名和参数规模看，它是一个约 26 亿参数的语言基础模型，目标不是“陪你聊天”，而是“帮你干活”：识别意图、调用工具、完成设备上的具体操作。我的判断是，在端侧 Agent 这个方向上，2.5B 到 2.6B 参数并不是“凑合的妥协方案”，而是一个在算力、内存、体验和效果之间更容易取得平衡的甜点区间。

这篇文章不会堆砌一堆我没有实测过的 benchmark 数字，而是想把几件事讲透：什么是端侧 Agent，为什么小模型做 Agent 比做聊天更难，如何把 LFM2.5-2.6B 部署到本地，以及怎么搭建一个最小可用的工具调用闭环。读完你可以直接照着搭一个端侧 Agent 雏形，并且避开那些最容易踩的坑。

1. 这篇文章真正要解决的问题

先说一个常见场景。你做了一个 AI 助手，功能包括查天气、定闹钟、提醒日程。最开始接入的是云端大模型，效果确实不错，但问题很快就出现了：

成本不可控。每个用户每天都在发起多轮对话，每轮对话都要把历史上下文重新发送一遍，token 消耗量远高于“聊天”场景。
延迟不稳定。Agent 的决策链路长，模型要“思考、决策、调用工具、再生成回复”，网络一波动，用户体感就是卡片转圈。
隐私压力大。日程、通讯录、位置这些本来就在端侧的数据，因为 Agent 要理解上下文，被迫打包上传到云端。

这三个问题单拎出来都不致命，一旦组合在一起，就几乎决定了“云端 Agent”很难成为默认形态。产品只能把它当成一个高级功能，而不是系统级入口。

LFM2.5-2.6B 这类模型要解决的，正是这三件事：推理在本地完成，数据不出设备，延迟只取决于硬件，没有服务端账单。当然，26 亿参数换来不了 70B 模型的复杂推理能力，但它能覆盖大量“低频但高频使用”的 Device Agent 任务，比如设置提醒、控制智能家居、读取屏幕信息、填表单、管理文件。

如果你属于下面任何一类开发者，这篇文章都值得认真看：

移动端或 PC 端应用开发者，想给应用加入端侧 AI Agent 能力；
物联网和边缘设备开发者，设备无法稳定接入云端，但又需要智能交互；
隐私敏感场景的从业者，比如医疗、金融、企业办公，数据不能出本地；
被云端 Agent 成本困扰的产品负责人，想验证“端云混合”方案是否可行。

核心结论先放这里：LFM2.5-2.6B 这类模型的价值，不在于单点能力比云端大模型强，而在于它把“Agent 功能”从云端中心化部署，变回了产品本地能力的一部分。

2. 端侧 Agent 的核心概念与 LFM 模型的定位

2.1 什么是 On-Device Agent

Agent（智能体）在这里指的不是一个聊天框，而是一个能自主完成多步任务的程序。它的典型结构是：

理解用户意图；
规划执行步骤；
调用外部工具（如闹钟、日历、系统 API）；
根据工具返回结果继续决策；
最终给用户回复。

On-Device 指的是整个推理和决策过程发生在用户设备上。设备可以是手机、PC、平板、车载系统、智能音箱或机器人。与云端 Agent 相比，它最大的区别是：模型权重在本地，工具调用也在本地，用户数据不需要离开设备。

2.2 LFM 是什么

LFM 是 Language Foundation Model 的缩写，即语言基础模型。基础模型意味着它未经特定下游任务深度定制，是一个通用的文本理解与生成底座。开发者拿到之后，可以基于它做指令微调、量化部署，或者直接把它接入应用逻辑。

LFM2.5-2.6B 从命名上看，指的是版本号为 2.5、参数规模在 2.6B（约 26 亿参数）的模型。这一类模型和流行的“小参数大能力”路线一致：参数不多，但架构、训练数据和指令遵循能力都在向小型化做针对性优化，目的就是能在端侧高效运行。

2.3 2.6B 参数意味着什么

参数规模直接决定硬件占用。我们粗略估算一下：

FP16 半精度下，2.6B 参数权重约占 5.2GB；
INT8 量化下，约占 2.6GB；
INT4 量化下，约占 1.3GB 到 1.6GB；
再加上 KV Cache、临时激活值和推理开销，整体内存占用会再高一些。

换算成实际体验：一台 8GB 内存的普通电脑，加载 INT4 量化后的 LFM2.5-2.6B 模型，可以比较流畅地跑 CPU 推理。如果是手机旗舰芯片，配合端侧推理框架，也能实现每秒几十 token 的生成速度。这个量级，正好卡在“手机跑得动”和“效果还够用”之间。

对比 7B 模型：INT4 量化后权重约 3.5GB 到 4GB，对手机内存压力明显更大，CPU 推理速度通常只有 2.6B 的一半左右。对比 70B 级别的云端模型：它完全无法端侧部署，只能走网络请求。所以 2.5B 到 2.6B 这个区间，是兼顾能力、速度与部署成本的合理选择。

2.4 LFM 与云端大模型的分工

一个成熟的端云混合 Agent 架构往往是这样的：

用户请求 │ ▼ 端侧小模型（LFM2.5-2.6B） │ ├── 简单的本地任务：直接调用工具完成 ├── 隐私敏感任务：本地下文理解 + 本地工具执行 └── 复杂推理任务：做意图压缩 + 路由到云端大模型

端侧模型负责“快”和“隐私”，云端模型负责“强”和“博学”。两者不是替代关系，而是共存关系。端侧模型能跑通 70% 的常见请求，就已经能大幅降低成本和延迟，这是 On-Device Agent 商业上成立的前提。

3. 为什么 On-Device Agent 值得关注

很多人会问：既然端侧模型能力有限，为什么不都放云端？要回答这个问题，不能只看模型能力，要看整个产品形态。下面几个维度，对实际项目的影响是决定性的。

3.1 隐私与数据本地化

Agent 类应用和普通问答应用有一个本质差别：Agent 需要做具体操作，必然涉及设备上的私有数据。日程、通讯录、位置、输入习惯、屏幕内容，这些数据一旦上传云端，对用户来说就是风险。

端侧 Agent 把“理解”和“执行”放在本地，数据没有机会离开设备。即使未来需要云端协助，也只会发送去除隐私后的结构化摘要，而不是原始上下文。这会让产品在隐私合规上的压力小很多。

3.2 延迟体验的提升

云端 Agent 的一个典型卡顿点是“多轮工具调用”：模型每调用一次工具，就要经历一次完整的通信往返。如果链路是“端到云 → 云到工具服务 → 云再生成 → 回传”，单次工具调用的延迟可能高达一到三秒，甚至更久。

端侧 Agent 的推理在本地，工具也在本地，延迟主要取决于模型推理速度和工具本身执行速度。在硬件合理的设备上，一次简单意图识别加工具调用可以控制在几百毫秒到一秒以内。这种体感差异，是用户能否把语音助手当成日常功能的关键。

3.3 离线与弱网可用

地铁、电梯、地下室、偏远郊外，网络环境永远不稳定。云端 Agent 在弱网下几乎不可用，而端侧 Agent 可以完整运行。这个能力对特殊行业尤其重要：野外巡检、应急通信、车载导航、医疗便携设备，网络不是“偶尔断”，而是“本来就没有”。

3.4 成本结构的变化

云端 Agent 的成本模型是“按 token 计费”，用户对话越多，Agent 调用工具越频繁，成本越高，而且不可控。端侧 Agent 是一次性部署，模型推理消耗的是设备本身的算力和电量。

对 C 端产品来说，这意味着每个用户的新增边际成本趋近于零。对 B 端产品来说，可以把昂贵的 GPU 资源集中到复杂推理任务上，而不是浪费在“今天天气怎么样”这种高频低难度请求上。

3.5 长期记忆与个性化

端侧 Agent 还有一个容易被忽视的优势：记忆可以长期存放在本地。云端模型受限于上下文窗口和隐私策略，很难为每个用户维护一份完整的个人记忆库。而端侧 Agent 可以把用户偏好、历史操作、常用设置写入本地向量数据库，在每个会话启动时快速加载。

这意味着什么？意味着 Agent 可以越用越懂你，而且不需要上传任何隐私数据。这个能力对需要高粘性的应用来说，商业价值非常大。

4. 端侧 Agent 的技术难点与能力边界

如果说“部署一个小模型”是体力活，那么“让小模型稳定做 Agent”才是真正的技术活。这里有几个关键难点。

4.1 工具调用格式的稳定性

云端大模型经过大量指令微调，输出 JSON 或调用函数通常很准。而端侧小模型参数量少，指令遵循能力弱，经常出现以下问题：

不调用工具，直接把工具结果“想象”出来；
参数名写错，多传或少传字段；
把工具说明当成了普通文本回复。

应对方法有两种：一是模型本身微调过 Function Calling；二是在推理层用提示词强制输出 JSON，再靠代码解析。LFM2.5-2.6B 如果具备命令遵循能力，可以优先走 OpenAI 兼容接口的tools参数；如果效果不稳定，就必须做一层格式兜底。

4.2 多轮任务的上下文管理

Agent 场景下，用户往往不会一次说完整需求。例如：“帮我把明天早上的闹钟设到八点……不对，改成八点半。”这种多轮语境对小模型是一个大考验。模型不仅要理解指令，还要能判断“改”指的是改哪个闹钟、从几点改到几点。

端侧模型的上下文窗口通常有限，可能是 4K、8K 或 16K。如果每轮对话都把完整历史塞进去，很快就会撑爆窗口。更合理的方式是：在端侧做记忆裁剪，只保留关键信息，比如当前任务目标、已经确定的参数、最近两轮对话。必要时离线生成摘要，把长历史压缩成结构化记忆。

4.3 系统提示词的长度控制

端侧小模型对长提示词非常敏感。系统提示词越长，模型越容易混淆重点，生成速度也会下降。因此，给端侧 Agent 写系统提示词要尽量精简：

明确角色；
列出可用工具和参数；
规定输出格式；
规定不要做什么。

千万不要把云端模型那套几千字的“角色设定 + 样例 few-shot”直接搬到端侧，效果会明显变差。

4.4 推理速度与设备续航

端侧 Agent 虽然省了网费和云费，但消耗的是设备电量和计算资源。2.6B 模型在 CPU 上推理时，如果线程设置不合理，可能造成设备发烫、掉电加快。在真实产品中，必须考虑：

使用 4bit 或更低量化；
开启部分 GPU 加速；
限制并发请求数；
在低电量时主动降级为云端方案。

4.5 幻觉与安全边界

模型越小，幻觉不一定越严重，但输出稳定性会差一些。尤其在 Agent 场景，模型的错误输出可能直接触发系统操作。比如把闹钟设在“25:00”，或者把文件命名成乱码。因此，端侧 Agent 必须在执行工具前增加“参数校验层”，不能完全信任模型输出。

下面这张表能帮你快速理解云端大模型与端侧小模型在 Agent 任务上的差异：

维度	云端大模型	LFM2.5-2.6B 等端侧模型
推理能力	强	中低，偏简单任务
工具调用稳定性	高	一般，需要格式兜底
延迟	受网络影响，通常较高	本地推理，更快
隐私	数据需上云	数据不出设备
成本	按 token 计费	一次性部署成本
可离线使用	否	是
上下文窗口	大	通常较小，需要裁剪
适合任务	复杂推理、知识问答	设备操作、隐私敏感短任务

这个表格背后有一个清晰的判断：端侧模型不是“穷人版的云端模型”，而是为特定场景重新设计的另一种 Agent 形态。理解这一点，后续做架构选型才不会选错方向。

5. LFM2.5-2.6B 环境准备与基础部署

这一节我们把 LFM2.5-2.6B 跑起来。文章以通用流程演示，具体模型文件、推理框架版本请以你实际拿到的东西为准，但思路完全一致。

5.1 硬件与软件环境

建议最低配置：

内存：8GB 以上（运行 INT4 量化模型）；
操作系统：Windows / macOS / Linux 均可；
磁盘空间：模型文件约 2GB 左右；
推荐工具：llama.cpp 或 Ollama，二者都支持 GGUF 格式，并内置 OpenAI 兼容接口。

如果只有 CPU，也能跑。2.6B 模型在 CPU 上生成速度大概是每秒 15 到 30 token，取决于设备和线程数。对演示 Agent 来说已经足够。

5.2 部署方案一：使用 llama.cpp

先把 llama.cpp 编译出来：

# 拉取代码 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译（需要 cmake 和 C++ 编译器） cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j

假设你已经拿到 LFM2.5-2.6B 转换后的 GGUF 文件，名字为lfm2.5-2.6b-q4_k_m.gguf，可以把模型放到models目录下。

启动一个 OpenAI 兼容的本地服务：

./build/bin/llama-server \ -m models/lfm2.5-2.6b-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 8192 \ -t 8

参数说明：

-m：指定模型文件路径；
--host和--port：服务监听地址和端口；
-c：上下文窗口长度，这里设置为 8192；
-t：CPU 推理线程数，建议根据 CPU 物理核心数调整。

启动成功后，日志里会出现类似server is listening on http://127.0.0.1:8080的信息。

5.3 部署方案二：使用 Ollama

如果你更习惯 Ollama 的命令行体验，可以这样做。先把 GGUF 文件导入：

# 1. 安装 ollama（macOS / Linux / Windows） curl -fsSL https://ollama.com/install.sh | sh # 2. 创建 Modelfile，内容如下： # FROM /path/to/lfm2.5-2.6b-q4_k_m.gguf # TEMPLATE "{{ .System }} {{ .Prompt }}" # 3. 创建并启动模型 ollama create lfm2.5 -f Modelfile ollama run lfm2.5

Ollama 会自动管理模型生命周期，并且也提供http://127.0.0.1:11434/v1的 OpenAI 兼容接口。两种方案选一种即可，我后面的示例代码都假设接口是兼容的。

5.4 验证部署是否成功

用 curl 发一个最简单的请求：

curl http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "lfm2.5-2.6b", "messages": [ {"role": "system", "content": "你是一个端侧助手。"}, {"role": "user", "content": "用一句话介绍你自己。"} ] }'

如果返回一个包含choices字段的 JSON，说明部署成功。到这里，模型已经能“说话”了，但它还不是 Agent。下一步，我们把工具调用能力接上。

6. 用 LFM2.5-2.6B 搭建一个最小端侧 Agent

6.1 Agent 的最小闭环

一个端侧 Agent 至少需要四个部分：模型推理、工具定义、消息循环、参数校验。我们用一个“设置闹钟”的示例把这条链路跑通。

整体流程是这样的：

用户输入 → 模型判断意图 → 输出工具调用请求 → 代码解析参数 → 执行本地工具 → 工具结果回填给模型 → 模型生成最终回复 → 返回给用户

6.2 方法一：使用 OpenAI 兼容的 tools 参数

新版 llama.cpp 和 Ollama 都支持 OpenAI 风格的tools参数。如果 LFM2.5-2.6B 版本带有命令遵循能力，优先用这种方式。

# 文件路径：agent_demo.py import json from openai import OpenAI # 这里可以切换为 Ollama 的地址 http://127.0.0.1:11434/v1 client = OpenAI( base_url="http://127.0.0.1:8080/v1", api_key="not-needed", ) tools = [ { "type": "function", "function": { "name": "set_alarm", "description": "在设备上设置一个闹钟。", "parameters": { "type": "object", "properties": { "time": { "type": "string", "description": "闹钟时间，24小时制，格式为 HH:MM。" }, "label": { "type": "string", "description": "闹钟备注，例如：开会、起床。" } }, "required": ["time"] } } } ] def set_alarm(time: str, label: str = "") -> dict: # 实际项目中，在这里调用系统的闹钟 API print(f"[exec] 设置闹钟 {label or '未命名'} 在 {time}") return {"status": "ok", "time": time, "label": label} messages = [ { "role": "system", "content": "你是运行在用户设备上的端侧助手。" "你只能调用提供的工具完成任务，调用工具时参数必须符合 JSON 格式。" }, {"role": "user", "content": "明天早上九点提醒我开周会"}, ] for _ in range(5): # 最多循环 5 次，防止无限调用 resp = client.chat.completions.create( model="lfm2.5-2.6b", messages=messages, tools=tools, temperature=0.2, ) msg = resp.choices[0].message # 没有工具调用，直接输出最终回复 if not msg.tool_calls: print("最终回复:", msg.content) break # 有工具调用，把模型的消息追加进上下文 messages.append(msg) for tc in msg.tool_calls: print("模型请求调用工具:", tc.function.name, tc.function.arguments) try: args = json.loads(tc.function.arguments) except json.JSONDecodeError: args = {} # 执行本地工具 result = set_alarm(**args) # 把工具结果回填给模型 messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result, ensure_ascii=False) }) print("messages 长度:", len(messages))

这段代码有几个关键点：

messages会持续累积，保证模型能看到“用户请求 → 工具调用 → 工具结果”的完整轨迹；
tool_calls是 OpenAI 兼容接口的标准返回字段，本地推理框架会解析模型的输出；
工具执行必须放在真实环境里做校验，不能直接把模型给的参数当最终值。

6.3 方法二：提示词约束 JSON 输出

如果 LFM2.5-2.6B 对tools参数的支持不稳定，可以退回到提示词约束。它的原理是：把工具描述直接写进系统提示词，并要求模型只输出指定格式的 JSON。

# 文件路径：agent_demo_fallback.py import json TOOL_SCHEMA = """ 你可以调用以下工具： - set_alarm(parameters: {"time": "HH:MM", "label": "string"}) 注意： 1. 你需要调用工具时，只输出 JSON，不允许输出其他文字。 2. JSON 格式必须为 {"action": "set_alarm", "params": {...}} 3. 不需要调用工具时，输出 {"action": "reply", "params": {"content": "你的回答"}} """ user_input = "下午三点半提醒我取快递" prompt = TOOL_SCHEMA + "\n用户请求：" + user_input # 请求模型并拿到原始输出 # 这里假设 resp_text 是模型生成的文本 # resp_text = client.chat.completions.create(...).choices[0].message.content # 假设我们已经拿到了模型输出 # resp_text = '{"action": "set_alarm", "params": {"time": "15:30", "label": "取快递"}}'

这段代码只是示意，重点在于你需要在代码层把模型输出作为 JSON 解析，再做参数校验。如果解析失败，可以重试一次，要求模型“只输出 JSON”。这种方法对参数非常小、没有专门微调过 Function Calling 的模型更实用。

6.4 运行方式

python agent_demo.py

预期你会看到类似下面的运行日志：

模型请求调用工具: set_alarm {"time": "09:00", "label": "开周会"} [exec] 设置闹钟 开周会 在 09:00 最终回复: 好的，已经帮你设定明天早上九点的闹钟提醒开周会。

如果模型没有正确触发工具调用，不要急着怪模型，先检查系统提示词是否足够明确，再检查服务是否真的支持tools参数。

7. 运行结果与效果验证

Agent 和普通问答不一样，不能只看“回复是否通顺”，还要看“工具是否被正确调用”。建议从五个角度验证。

7.1 工具调用是否触发

这是第一步。输入“帮我定一个明天早上八点的闹钟”，观察日志里是否出现模型请求调用工具: set_alarm。如果没有触发，先排除三种情况：

模型服务没有启用 tools 支持；
系统提示词里没有强调“必须调用工具”；
模型本身不具备命令遵循能力，需要切换为 JSON 提示词方案。

7.2 参数是否正确

触发工具调用后，重点看参数解析。比如用户说“八点”，设备是 24 小时制，模型应该输出"time": "08:00"，而不是"time": "8点"。出现后者说明参数描述还不够明确，工具描述里要写清楚格式样例。

7.3 最终回复是否自然

工具执行完毕后，模型需要根据工具返回值生成自然语言回复。如果模型把工具返回的原始 JSON 直接读给用户，比如“工具执行结果为 status ok”，说明系统的提示词还需要加一句“根据工具结果生成简洁的回复”。

7.4 多轮对话是否连续

再测试一个更复杂的场景：

用户：帮我设一个明早八点的闹钟 用户：不对，改成八点半

理想情况下，第一轮触发set_alarm并记录，第二轮模型应该知道是“修改已经设置的闹钟”。如果 LFM2.5-2.6B 在第二轮没有调用工具，需要检查messages是否完整传入了历史记录。

7.5 失败时先看哪里

一旦运行结果不符合预期，建议按这个顺序排查：

看模型的原始响应，确认是输出格式错误，还是根本没有触发工具调用；
看llama-server日志，确认请求是否到达、上下文是否被截断；
看代码抛出的异常，是 JSON 解析失败，还是参数校验失败；
做一个最小测试：只用系统提示词，不加工具定义，看模型能否正确理解意图。

记住一个原则：小模型的 Agent 效果问题，八成出在“提示词不够具体”和“没有格式兜底”上。先把这两件事做好，再去怀疑模型能力。

8. 常见问题与排查思路

这里整理我在端侧 Agent 落地过程中最常遇到的问题，直接列成表格方便查阅。

问题现象	可能原因	排查方式	解决方案
启动时内存不足	模型未量化，或量化等级过高	查看模型文件大小和进程内存占用	改用 q4_k_m 或更低比特量化
响应延迟过高	CPU 线程数不足，上下文太长	观察 prompt eval 和 token gen 速度	增加线程数，减小`-c`，开启 GPU 加速
工具调用一直不触发	模型未有效支持 tools 参数	打印原始响应，确认是否包含`tool_calls`字段	改用提示词 JSON 输出方案，或替换指令遵循更强的模型
模型输出 JSON 解析失败	输出含多余文字或格式不规范	检查错误日志中的模型原始文本	增加重试逻辑，再次要求“只输出 JSON”
中文夹杂英文或重复	采样参数不合理，词表适配一般	观察连续多个输出样例	降低 temperature，提高 repetition_penalty
多轮对话后行为混乱	上下文窗口被截断，记忆丢失	检查`messages`长度和截断逻辑	裁剪历史，保留 system、最近轮次和关键参数
工具执行了但回复不自然	提示词没有要求根据工具结果生成回复	查看最终回复示例	系统提示词增加“根据工具结果生成简洁自然回复”

排查工具调用问题时，最有效的办法不是看最终输出，而是打印完整对话轨迹。把messages里每一轮的role、content、tool_calls全部打出来，问题往往一眼就能看出来。

9. 最佳实践、回归评测与后续学习方向

9.1 量化策略要分场景

如果设备内存充足，优先试 INT8 或较低压缩比的 INT4，测一下准确率能不能接受。如果发现工具调用成功率明显下降，就不要追求极限压缩。更稳妥的做法是：内存紧张的设备用 INT4，开发调试时用 FP16 或 INT8，评测通过后再切换到更小体积的版本。

9.2 系统提示词要保持精简

端侧模型对长提示词的理解能力有限。系统提示词建议控制在 200 到 500 字内，工具描述写清“工具名、参数类型、格式样例、何时使用”。把最重要的“必须输出 JSON、参数必须合规”放在提示词开头，比放在结尾更有效。

9.3 工具列表宁少勿多

每次调用模型时，所有工具描述都会占据上下文空间。工具越多，模型越容易混淆。合理做法是：先根据用户意图做一次粗分类，只把相关工具传给模型。比如识别到是闹钟相关请求时，再把set_alarm、list_alarms等工具传给模型。

9.4 必须设计降级链路

端侧模型不一定能处理所有请求。生产环境务必设计三层降级：第一层端侧模型直接完成；第二层端侧模型识别到复杂任务后，把脱敏后的摘要发给云端；第三层用户主动请求强大模型时，明确提示数据会离开设备。这个降级逻辑既保护体验，也保护隐私。

9.5 工具执行要做校验和授权

模型输出的time参数，可能是 “25:00”，也可能是个空字符串。工具执行前必须有一层参数校验，例如时间格式必须匹配^\d{2}:\d{2}$，且小时在 0 到 23 之间。涉及发送消息、删除文件、访问通讯录等敏感操作，必须经过用户确认，不能由模型静默执行。

9.6 建立回归评测集

端侧模型迭代很快，每次换模型文件、改提示词、调整量化等级，都可能影响 Agent 行为。建议准备一个 20 到 50 条的小规模评测集，覆盖：

不同意图的指令；
带错误参数或缺失参数的指令；
多轮修改指令；
需要拒绝执行的请求。

每条评测都记录“工具是否触发、参数是否正确、最终回复是否合格”。小模型效果不稳定，但通过回归能稳定住下限。

9.7 下一步学习方向

如果你准备在真实产品中落地端侧 Agent，下面这几个方向值得继续深入：

模型微调：用少量工具调用数据对 LFM2.5-2.6B 做 LoRA 微调，是提高工具调用稳定性最直接的办法；
端侧推理优化：研究 KV Cache 量化、Prefill 加速、算子融合，把推理延迟继续压下去；
Agent 记忆管理：实现本地向量数据库 + 摘要压缩，让 Agent 有长期记忆；
设备端框架集成：学习如何在 Android、iOS 或嵌入式 Linux 上调用 LFM 模型，并与系统 API 打通。

端侧 Agent 这个方向最有趣的地方在于，它把大模型的能力从“云端 API”变成了“设备本地能力”。LFM2.5-2.6B 的价值，不是替代云端大模型，而是让 Agent 真正成为用户设备上的基础设施。如果你正在做端侧 AI 产品，建议从今天的最小示例开始，先跑通一条工具调用链路，再逐步扩成完整的 Agent 系统。

企业官网建设流程全解析