这几年“AI Agent”几乎成了技术圈里绕不开的话题。无论是做自动化办公、智能客服还是做复杂任务编排团队都会优先考虑用大模型来驱动 Agent。但真正落地时很多项目卡住的不是 Prompt 设计也不是 Agent 框架选型而是模型本身的部署成本模型太大、显存不够、推理太慢、私有化环境装不下。本文要聊的 LFM2.5-2.6B正是为解决这类问题而生的轻量级模型。文章会围绕“Deploy Agents Everywhere”这一目标完整拆解如何把 LFM2.5-2.6B 部署到本地环境并基于它构建可运行的 Agent包括工具调用、LangGraph 多步骤编排、Agent 评估等环节。无论你是刚开始了解 Agent 的开发者还是已经在做 LLM 应用落地的工程师都可以按这篇文章的步骤动手跑一遍。1. 为什么“小模型 Agent”是当前最快落地的组合1.1 Agent 应用真正卡在“模型部署”这一步很多人对 Agent 的第一印象是给大模型接上工具让它能查天气、订机票、操作数据库。这个概念本身不复杂复杂的是把模型真正跑起来。以常见的 7B、13B 参数模型为例即使做 4-bit 量化部署到生产环境依然需要 8GB 到 16GB 左右的显存如果再考虑并发请求、长上下文输入对 GPU 的要求会进一步上升。对于个人开发者、中小企业或者需要私有化部署的业务系统来说这个成本并不友好。所以业界开始把目光转向 1B 到 4B 参数区间的模型。这类模型经过量化后可以运行在消费级显卡、M 系列芯片的 Mac、甚至 CPU 环境上同时通过结构设计和训练优化在逻辑推理、工具调用等 Agent 高频能力上做到够用。LFM2.5-2.6B 就属于这个区间。1.2 LFM2.5-2.6B 是什么LFM2.5-2.6B 是 Liquid AI 推出的 LFMLiquid Foundation Model系列模型之一。名字里的“2.6B”指的是模型参数量约为 26 亿属于中小规模语言模型。它是基于非 Transformer 架构思路构建的新一代模型家族目标是在同等参数量下实现更高的推理效率、更低的显存占用和更长的上下文支持。2.6B 这个版本尤其适合个人电脑、边缘设备和资源受限的服务器环境。这里要提醒一点LFM 系列和常见的 Llama 系列、Qwen 系列一样都属于开源模型生态。但它的架构和分词方式可能与其他模型不同因此在集成到 Agent 框架时不能假设所有代码都能直接复用需要以官方文档和实际运行结果为准。1.3 理解“Deploy Agents Everywhere”的目标“Deploy Agents Everywhere”可以理解为一种部署理念让 Agent 不要只停留在云端 GPU 集群里而是能够跑到开发者的笔记本、公司的内网服务器、边缘终端设备、甚至用户本地环境中去。要做到这一点模型体积必须足够小推理成本必须足够低。LFM2.5-2.6B 这类轻量模型的价值就在于把 Agent 的“大脑”成本降下来让更多人可以在自己的环境里部署、调试和运行 Agent。2. 环境准备与版本说明2.1 硬件与系统要求LFM2.5-2.6B 对硬件的要求比较友好但不代表可以完全忽视。根据你选择的运行方式硬件要求大致如下运行方式最低配置建议说明CPU 推理16GB 内存速度较慢适合测试和小流量场景GPU 推理8GB 以上显存可以满足较好的推理速度和并发能力Apple Silicon16GB 统一内存M 系列芯片运行效果较好如果你使用的是 Windows Linux 双系统环境请注意模型权重文件路径和磁盘空间2.6B 模型的全精度权重文件大约在 5GB 到 6GB量化后可以压到 2GB 左右。具体大小以实际下载文件为准。2.2 运行环境与依赖库本文示例以 Python 3.10 版本为基础环境操作系统以 Ubuntu 22.04 和 macOS 为演示对象。你需要准备以下核心依赖Hugging Face Transformers用于加载模型和进行推理建议使用 4.40 以上版本。PyTorchTransformers 依赖 PyTorch建议安装 2.x 版本。本地推理工具可选如 Ollama、llama.cpp用于快速启动模型服务。Agent 编排框架可选如 LangGraph、LangChain用于构建复杂 Agent 流程。在正式安装前建议先创建独立虚拟环境避免依赖冲突。下面是一个基础环境创建命令python3 -m venv lfm-agent-env source lfm-agent-env/bin/activate pip install --upgrade pip版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。2.3 获取 LFM2.5-2.6B 模型文件模型权重可以从 Hugging Face Model Hub 获取。搜索 LFM2.5-2.6B 时你需要关注几个关键信息模型版本号不同版本的中间权重可能不同。量化格式GGUF 格式适合 llama.cpp 和 Ollamasafetensors 格式适合 Transformers。许可证开源模型通常有使用条款商业应用前必须确认合规性。下载时建议使用官方仓库提供的命令例如git lfs install git clone https://huggingface.co/LiquidAI/LFM2.5-2.6B如果没有安装 Git LFS也可以直接用 Hugging Face 网页接口下载单个文件但要注意把模型文件夹中所有必要文件都下载完整。3. LFM2.5-2.6B 核心特性与适用场景3.1 用较小的参数量换来可用的 Agent 推理能力LFM2.5-2.6B 之所以值得关注核心在于它在参数规模和推理效果之间做了平衡。对于 Agent 应用来说模型需要具备几种关键能力指令理解、上下文跟踪、工具调用、结果判断。这些能力并不一定需要 100B 参数才能实现。2.6B 参数的模型经过针对性训练后足以在结构化任务中给出可用结果。换句话说很多业务场景并不需要模型“上知天文下知地理”只需要它在一个专业范围内稳定输出。LFM2.5-2.6B 适合的方式是配合工具和外部数据源使用——模型负责理解和决策业务数据交给专门的系统和接口处理。3.2 长上下文对 Agent 有多重要Agent 和普通聊天机器人最大的区别就是需要处理多轮状态和外部工具返回的长文本结果。比如一个订单查询 Agent需要先获取用户订单号再调用订单接口接口可能返回一长串商品明细、物流信息、售后状态。如果模型上下文太短信息还没读完就已经截断了。LFM2.5-2.6B 支持长上下文输入这能让 Agent 在一次会话中承载更多工具返回结果和中间推理过程。在实际使用中要注意长上下文会增加计算量部署时建议根据业务需要合理设置 max context length不要无脑拉满。3.3 适合做 Agent 场景的整体优势综合来看LFM2.5-2.6B 在 Agent 场景下的优势可以总结为以下几点部署门槛低普通开发机和边缘设备都能运行。私有化友好权重文件本地持有数据不需要上传到云端。易与框架集成通过 Transformers 或本地推理服务可以快速接入 LangChain、LangGraph 等编排工具。成本可控无需高规格 GPU适合做千万级调用次数估算时控制预算。如果你是做原型验证或者业务对响应速度要求较高、对绝对推理上限要求不高那么 LFM2.5-2.6B 是一个值得优先评估的选项。4. 本地部署从模型加载到第一个对话4.1 方式一通过本地推理工具快速启动如果你只是想快速体验 LFM2.5-2.6B 的效果建议直接用支持 GGUF 格式的推理工具。这类工具会把模型封装成命令行服务几步就可以启动。以常见工具为例一个典型流程是# 拉取模型实际模型名称以仓库列出的 tag 为准 ollama pull lfm2.5-2.6b ollama run lfm2.5-2.6b启动成功后终端会进入交互对话模式。你可以直接输入一句话请用一句话介绍你自己的模型规格。如果模型配置正确它会返回一段简短的自我介绍。这种方式的好处是零代码启动适合先验证模型文件是否可用、效果是否符合预期。4.2 方式二编写 Python 推理服务当你要把模型集成到自己的 Agent 代码中时建议使用 Transformers 库直接加载模型。下面是一个最小可运行的推理脚本。将代码保存为infer.py# 文件路径infer.py from transformers import AutoTokenizer, AutoModelForCausalLM model_name LiquidAI/LFM2.5-2.6B # 加载模型和 tokenizer # 注意需要根据本地硬件情况决定是否传入 device_map 参数 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, device_mapauto, torch_dtypeauto ) prompt 请用一句话解释什么是 AI Agent。 messages [{role: system, content: 你是一个乐于助人的助手。}, {role: user, content: prompt}] # 不同的模型对输入格式要求不同需要按照官方模板拼接 text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(text, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens256, do_sampleFalse, temperature0.7 ) response tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) print(response)运行命令python infer.py如果一切正常终端会输出模型生成的回答。需要注意不同的模型版本对对话模板的支持程度不同如果遇到生成结果中包含大量特殊符号或者回答格式异常优先检查apply_chat_template是否受支持必要时改为手动拼接提示词。4.3 验证推理结果模型部署完成后不要急着进入 Agent 开发。建议先做一组基础验证中文指令是否正常回复。多轮上下文是否还能定位到前面的信息。最大输出长度设置是否符合预期。单次请求的耗时和显存占用是否在可接受范围内。记录下这组数据后续做 Agent 性能评估时可以作为基准。5. 给模型装上“工具调用”能力构建 Agent 雏形5.1 工具调用与 Agent 的关系Agent 与普通 LLM 应用最大的不同就是它可以使用工具。工具可以是函数、API、数据库查询也可以是命令行脚本。模型负责理解用户意图然后将意图转化为一次工具调用拿到结果后继续生成回答。这个循环在业界常被称为 ReActReasoning Acting。没有工具调用能力LLM 只能是“聊天机器人”有了工具调用能力它才能成为“Agent”。5.2 用一个可运行的 ReAct 循环演示下面实现一个极简的 ReAct 循环。为了演示效果我们让 Agent 能够调用两个本地函数一个是获取城市天气一个是获取当前时间。# 文件路径react_agent.py import json import datetime # ---------- 工具定义 ---------- def get_weather(city: str): 模拟天气查询实际项目应替换为真实天气 API weather_data {北京: 晴, 上海: 小雨, 广州: 多云} return weather_data.get(city, 未知天气) def get_current_time(): 返回当前时间 return datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) TOOLS { get_weather: get_weather, get_current_time: get_current_time, } TOOL_DESCRIPTION 你可以使用以下工具 - get_weather(city: str): 查询指定城市的天气参数为城市名。 - get_current_time(): 获取当前时间。 当你需要调用工具时请严格按照以下格式输出 工具调用: {name: 工具名, arguments: {参数名: 参数值}} # ---------- 模拟 LLM 调用 ---------- def call_llm(messages): 为了让示例可以在没有 GPU 的环境中直接运行 这里用一个规则函数代替真实 LLM。 实际项目中请替换为 LFM2.5-2.6B 的推理调用。 user_input messages[-1][content] if 天气 in user_input: import re match re.search(r[(]?(\w)[)]?, user_input) city match.group(1) if match else 北京 city user_input.split(天气)[0][-2:] # 简单提取城市名这里从 北京天气 中提取北京 if len(city) 2: city city[-2:] return f工具调用: {{\name\: \get_weather\, \arguments\: {{\city\: \{city}\}}}} if 时间 in user_input: return 工具调用: {name: get_current_time, arguments: {}} return 你说的内容我还没有办法处理。 # ---------- ReAct 主循环 ---------- def run_agent(user_input): messages [ {role: system, content: 你是一个智能助手。 TOOL_DESCRIPTION}, {role: user, content: user_input} ] max_steps 3 for _ in range(max_steps): llm_output call_llm(messages) print(模型原始输出:, llm_output) if llm_output.startswith(工具调用:): arg_str llm_output.replace(工具调用:, ).strip() call_data json.loads(arg_str) tool_func TOOLS.get(call_data[name]) if tool_func is None: break args call_data.get(arguments, {}) result tool_func(**args) print(工具返回结果:, result) messages.append({role: assistant, content: llm_output}) messages.append({role: tool, content: json.dumps(result, ensure_asciiFalse)}) else: print(最终回答:, llm_output) break if __name__ __main__: run_agent(北京天气怎么样) print( 第二轮对话 ) run_agent(现在几点了)运行python react_agent.py这里用了一个规则函数模拟 LLM 输出是为了让你先看懂 ReAct 循环的骨架。实际项目中只需要把call_llm替换成第 4 节写好的 LFM2.5-2.6B 推理函数然后让模型按同一种 JSON 格式输出工具调用意图即可。5.3 在这里容易踩的坑模型输出格式不稳定小模型在输出 JSON 时经常有多余文字或格式错误建议在解析失败时重试一次或者使用更宽松的正则解析。工具名和参数名写错模型如果不知道有哪些工具就无法正确调用。系统提示词中必须给出完整的工具清单。多轮工具调用后上下文过长每次工具返回结果都会追加到消息列表长期运行会累积大量 token建议对历史记录做截断或摘要。6. 使用 LangGraph 编排多步骤 Agent6.1 LangGraph 的核心概念如果业务场景只需要“调一次工具”手写 ReAct 循环就够了。但真实项目往往需要多步骤流程比如先查订单号再查订单状态再根据状态决定是否发起售后每一步都可能需要调用不同工具。LangGraph 是 LangChain 生态中用于构建有状态 Agent 编排的框架。它的核心概念有三个节点表示一个处理步骤可以是调 LLM、调工具、执行逻辑。边表示节点之间的流转关系支持条件跳转。状态在节点之间传递的数据例如消息列表、订单号、当前步骤等。使用 LangGraph 的好处是可以把复杂的 Agent 流程清晰拆开每一步都有明确入口和出口方便调试和维护。6.2 可运行示例一个带状态的多轮 Agent下面示例模拟一个售后客服 Agent 的流程收到用户消息后先查询订单状态如果订单已发货则继续查询物流信息否则提示用户先确认订单。# 文件路径langgraph_agent.py from typing import TypedDict, List try: from langgraph.graph import StateGraph, END except ImportError: raise ImportError(请先安装 langgraph: pip install langgraph) class AgentState(TypedDict): messages: List[dict] order_id: str order_status: str logistics: str def parse_order(state: AgentState): 模拟从用户消息中提取订单号真实项目可接 NLU 或 LLM last_msg state[messages][-1][content] # 这里简单写死订单号真实场景应调用解析逻辑 state[order_id] D20240001 state[order_status] 已发货 return state def query_logistics(state: AgentState): 模拟查询物流信息 if state.get(order_status) 已发货: state[logistics] 包裹已到达华东分拨中心预计明天送达。 else: state[logistics] 订单尚未发货暂无物流信息。 return state def generate_answer(state: AgentState): 把状态中的数据组装成用户可读的回答 state[messages].append({ role: assistant, content: f您好您的订单 {state[order_id]} 当前状态为{state[order_status]}。{state[logistics]} }) return state # 构建图 graph StateGraph(AgentState) graph.add_node(parse_order, parse_order) graph.add_node(query_logistics, query_logistics) graph.add_node(generate_answer, generate_answer) graph.add_edge(parse_order, query_logistics) graph.add_edge(query_logistics, generate_answer) graph.add_edge(generate_answer, END) graph.set_entry_point(parse_order) app graph.compile() # 执行 initial_state { messages: [{role: user, content: 帮我看看订单 D20240001 到哪了}], order_id: , order_status: , logistics: } result app.invoke(initial_state) print(result[messages][-1][content])如果你使用的 LangGraph 版本较新API 可能略有调整以官方发布版本为准。上面的代码是构图的基本框架可以复制到本地运行。6.3 运行与执行结果说明运行上面的脚本最终输出类似您好您的订单 D20240001 当前状态为已发货。包裹已到达华东分拨中心预计明天送达。这个示例中parse_order节点负责解析意图query_logistics节点负责查询信息generate_answer节点负责组装答案。每一步都在 State 中读写数据可以对照打印日志检查流程。实际项目里parse_order和query_logistics中间就接上了第 4 节的 LFM2.5-2.6B 推理能力。7. Agent 评估Evals部署前先回答“Agent 到底行不行”7.1 为什么 Agent 评估不能只看准确率模型评测中常见的“准确率”指标在 Agent 场景下往往不够用。原因是 Agent 的判断标准不只是“回答对不对”还包括是否在正确的时机调用了正确的工具。调用工具的入参是否正确。拿到工具结果后是否正确整合进最终回答。整个流程在多少轮内完成。面对边界输入时是否安全回退。所以 Agent 评估需要针对“流程”而不是“单点输出”来设计。7.2 便宜的评估方案规则 LLM-as-Judge对大多数团队来说第一版评估系统不需要做得很重。可以分两层第一层是规则判断。比如工具名是否匹配预期、输出是否符合 JSON 格式、是否在 3 步内结束流程。这些可以用脚本自动判定。第二层是 LLM-as-Judge。让一个能力较强的模型当裁判把 Agent 的完整对话记录和参考标准一起发给裁判模型让它打分并给出理由。下面是一个最小评估脚本的思路# 文件路径eval_agent.py from react_agent import run_agent def evaluate_case(user_input, expected_tool): # 记录 Agent 执行过程中的工具调用列表 tool_calls [] # 这里通过修改 run_agent 或使用日志记录来捕获工具调用 # 简化演示直接将预期工具名与实际捕获结果比对 run_agent(user_input) # 模拟捕获结果 captured_tools [get_weather] success expected_tool in captured_tools return { case: user_input, expected_tool: expected_tool, actual_tools: captured_tools, success: success } if __name__ __main__: result evaluate_case(北京天气怎么样, get_weather) print(result)这个示例把评估流程简化了。真正落地时建议把测试用例集写成 JSON 文件每条用例包含输入、期望调用工具、期望工具参数、期望最终回答关键词然后批量跑评估。7.3 让 Agent 自我进化基于历史经验的低成本实验方向“Self-Improving Agents”是当前 Agent 领域很受关注的方向核心思路是把每次任务执行的经验记录下来下次遇到相似问题时让 Agent 参考历史成功经验来调整策略。对于小模型驱动的 Agent这个思路尤其有价值。因为模型本身参数有限不可能把所有领域知识都塞进权重但可以通过外部经验库来补充。具体做法可以是把成功完成任务的多轮对话存入向量数据库。新任务进来时检索最相似的成功案例。将案例摘要拼接到 Prompt 中作为参考。这种方式成本低、见效快比反复微调模型更适合同一个业务场景的 Agent。8. 常见问题与排查思路在部署 LFM2.5-2.6B 和构建 Agent 的过程中下面几类问题出现频率较高问题现象常见原因解决思路模型加载时显存不足没有使用量化或者 device_map 设置不当尝试 8-bit / 4-bit 量化使用device_mapauto将部分层放到 CPU推理速度慢使用了 CPU 推理且未做量化优先使用 GPU或者使用 GGUF 量化格式配合 llama.cpp生成回答包含大量特殊符号对话模板不匹配检查tokenizer.apply_chat_template支持情况手动拼接系统提示词和用户消息Agent 工具调用格式经常解析失败模型输出不稳定带多余解释文字在解析代码中增加容错比如用正则提取 JSON提供更明确的输出格式示例多轮对话后模型丢失前文信息上下文过长被截断对历史消息做摘要或裁剪调整 max_new_tokensLangGraph 版本不同导致代码报错API 变更以官方文档为准查看当前版本中 StateGraph 的导入路径和方法签名遇到问题时先定位是模型层、框架层还是代码层的问题。最简单的排查方式是把每一层单独测一遍先直接问模型一句话确认模型正常再用框架跑一个最简单的节点确认框架正常最后再组合完整流程。9. 最佳实践与工程建议9.1 模型层面的建议优先使用量化版本部署。2.6B 模型全精度运行时对显存占用依然不小4-bit 量化可以大幅降低资源需求效果损失在可接受范围内。固定推理参数。temperature、top_p、max_new_tokens等参数应该固化成配置避免每次调用都临时调整保证线上行为可重复。明确上下文长度上限。不要一味追求“长上下文”要根据业务实际需要设置避免无限增长导致推理变慢。9.2 Prompt 与工具定义层面的建议工具描述要精确。模型无法猜到工具的用途必须在系统提示词中写清楚工具名称、参数、返回值格式。给出 one-shot 示例。在提示词中加入一个“用户提问 → 工具调用”的示例可以显著提高模型输出格式的稳定性。对工具返回结果做预清洗。工具返回的 JSON 可能很长模型处理长文本的能力有限应该在外部做摘要。9.3 Agent 工程层面的建议严格做超时和重试。工具调用可能失败或超时Agent 必须能优雅降级。记录完整 trace。每轮 Agent 的输入、模型输出、工具返回、最终回答都要有日志方便后续排查和评估。涉及用户数据和生产系统操作时必须遵循最小权限原则。例如查询订单状态的 Agent只应该授予查询权限不授予修改权限。在测试环境充分验证后再上线尤其是涉及数据库写入、审批、支付等高风险动作的 Agent操作前必须经过二次确认。9.4 关于 Agent 评估的持续迭代建议把评估用例集纳入版本管理每次修改 Prompt 或模型版本后都跑一遍回归评估。Agent 是系统不是单一模型改动任何一个环节都可能影响整体行为。长期维护一个高质量的用例集比反复调 Prompt 更有价值。10. 总结与下一步学习路线本文从“Agent 部署成本”这个真实痛点出发介绍了 LFM2.5-2.6B 的核心定位然后完整演示了本地部署、基础推理、ReAct 工具调用循环、LangGraph 多步骤编排以及 Agent 评估的落地思路。你现在应该能够做到理解 LFM2.5-2.6B 适合哪些 Agent 场景。在本地环境加载模型并完成推理。自己动手写一个带工具调用的 Agent 雏形。用 LangGraph 搭建简单的多步骤 Agent 流程。设计一套最低成本的 Agent 评估方案。下一步可以继续深入的方向包括把 LFM2.5-2.6B 接入 Cursor Agents 等桌面端 AI 工具来做本地化代码助手研究基于历史经验记录的 self-improving Agent让 Agent 从已有案例中学习也可以尝试把多个 Agent 组合成多 Agent 协作系统让不同 Agent 负责不同子任务。如果你也在做轻量模型 Agent 的落地尝试欢迎在实践过程中把遇到的报错和解决思路记录下来团队之间会因此少走很多弯路。