低成本Agent开发实战：用LlamaFactory微调开源模型，把单次成本降到0.2元

最近群里讨论 AI Agent 时，大家最关心的问题基本不是“能不能做”，而是“做起来划不划算”。一个普通的带工具调用的 Agent 任务，如果直接靠大模型 API 跑完整条链，一次下来轻轻松松消耗几万 token；如果任务链路再长一点，单次执行成本可能就是几毛到几块钱。对于想批量落地 Agent 应用的团队来说，这笔账很难忽略。

社区里关于 LlamaFactory 作者开源新工具、Agent 成本降到 0.2 元的讨论，让很多人看到了另一种思路：不再把希望全部寄托在闭源大模型上，而是用开源微调框架 + 开源模型，把 Agent 的“大脑”也定制出来。这篇文章不打算只讨论新闻，而是从成本构成、模型微调、Agent 代码实现、工程落地方案几个维度，完整走一遍低成本 Agent 开发的闭环。

无论你是刚开始接触 Agent 开发的新手，还是已经在生产环境里踩过 token 成本坑的后端开发者，这篇文章都值得收藏备用。

1. Agent 成本到底高在哪：先从一笔 token 账算起

1.1 Agent 不是一次调用，而是一轮“连环调用”

很多刚接触 Agent 的开发者会有一个误解：Agent 本质上就是“多轮对话 + 调用工具”，比普通 Chat 接口复杂不了多少。

但实际上，一个最简单的带工具调用的 Agent，执行流程是这样的：

1. 用户提出一个问题。
2. Agent 把问题发给大模型。
3. 大模型判断需要调用某个工具。
4. Agent 执行工具，拿到结果。
5. Agent 把工具结果再次发回给大模型。
6. 大模型基于工具结果生成最终回答。

请注意第 5 步：每一次把工具结果发回给大模型时，都需要携带完整的对话历史。也就是说前面提到的用户问题、模型推理过程、工具调用参数，全部要重新发送一遍。

假设一个 Agent 任务需要调用 3 次工具，那么完整的 token 消耗大约是：

• 第 1 轮：用户问题 + 系统提示词
• 第 2 轮：用户问题 + 系统提示词 + 第 1 轮完整历史
• 第 3 轮：用户问题 + 系统提示词 + 前两轮完整历史
• 第 4 轮：用户问题 + 系统提示词 + 前三轮完整历史

输入 token 呈现明显的“重复累积”效应。实际生产环境里，一个 Agent 任务的有效输出可能只有几百字，但累计输入 token 往往达到 2 万到 5 万。成本大头不是模型“生成能力强”，而是“重复读历史”的输入开销。

1.2 算一笔明细账

这里我们可以用一段简单的 Python 脚本，把 Agent 单次执行成本估算出来。

# cost_estimate.py # 模型价格配置，单位：元/千token # 注意：价格随服务商和时段变化，请替换为你的实际报价 MODEL_PRICE = { "local_qwen2.5_7b": {"input": 0.002, "output": 0.002}, "deepseek_chat": {"input": 0.001, "output": 0.002}, } def estimate_agent_cost(input_tokens, output_tokens, model="local_qwen2.5_7b"): price = MODEL_PRICE[model] cost = input_tokens * price["input"] / 1000 + output_tokens * price["output"] / 1000 return cost # 一个普通Agent任务的平均消耗 per_task_input = 20000 per_task_output = 2000 cost = estimate_agent_cost(per_task_input, per_task_output) print(f"单次Agent任务输入约 {per_task_input} token，输出约 {per_task_output} token") print(f"单次任务成本约: {cost:.4f} 元") # 如果每天跑1000次任务 daily_cost = cost * 1000 print(f"每天1000次任务成本约: {daily_cost:.2f} 元")

从数量级上看，如果使用自部署的开源小模型，单次 Agent 任务的 token 成本确实可以压到0.2 元量级。如果换成更贵的商业模型，这个数字会放大几十倍。所以“Agent 成本暴降”的关键，往往不是模型能力的天翻地覆，而是从“商业大模型”切换到“开源小模型 + 微调定制”这条技术路线。

1.3 从“贵”到“便宜”的三条技术路径

结合开源社区的实践经验，Agent 降本通常走这三条路：

路径	做法	解决的问题
模型降本	用 3B/7B 开源小模型替代闭源大模型	单次推理的 token 单价下降
调用降本	引入缓存、压缩历史、精简系统提示词	减少重复输入的 token 数量
微调降本	用 LoRA 低成本微调，让模型学会工具调用	小模型也能达到可用效果

而 LlamaFactory 这类开源微调框架，恰好把第三条路的基础设施门槛打下来了。

2. 认识 LlamaFactory 与开源微调生态

2.1 LlamaFactory 是什么

LlamaFactory 是一个开源的大语言模型微调框架，在 GitHub 上社区热度非常高。它把模型加载、数据集处理、LoRA/QLoRA 训练、模型导出、推理测试这些环节，封装成了统一的命令行和 Web UI。

简单理解：你想让一个开源模型学会特定领域知识或工具调用，不需要从头训练模型，也不需要写复杂的训练代码，用 LlamaFactory 准备好数据和配置，就能完成一次高效微调。

它解决的核心痛点是：传统模型微调需要写大量 PyTorch 训练脚本、处理数据格式、管理多卡并行，门槛很高。而 LlamaFactory 把这些复杂的工程细节隐藏起来，让开发者能够集中精力准备数据、调参数。

2.2 支持的模型与训练方式

具体支持哪些模型，建议以官方仓库 README 为准。从社区常见的用例来看，它广泛支持 LLaMA、Qwen、Mistral、Baichuan 等主流开源模型系列。

训练方式方面，LlamaFactory 常见选项包括：

• LoRA：冻结原始模型，只训练一小部分低秩适配参数，显存占用低。
• QLoRA：在 LoRA 基础上进一步量化基础模型，普通消费级显卡也能尝试。
• 全参微调：所有参数都参与训练，效果上限高，但显存和成本也高。

对于 Agent 工具调用这种任务，LoRA 通常是性价比最高的选择。

2.3 为什么微调能降低 Agent 成本

微调不是让模型“变聪明”，而是让模型在特定任务上的表现更稳定、更可控。针对 Agent 场景，微调可以做到：

• 模型更理解你的工具语义，不需要在提示词里写大段工具说明。
• 模型更稳定地输出结构化工具调用参数，减少 JSON 解析失败的次数。
• 可以大幅压缩系统提示词的长度，直接减少每次调用的输入 token。

换句话说，把原本需要靠“堆提示词”才能完成的工作，通过微调固化到模型参数里，运行时就能少传很多字，成本自然降下来。

3. 环境准备与版本说明

在开始之前，我们先把运行环境准备好。下面是本文示例的环境参考，你需要根据自己的实际环境调整：

• 操作系统：Ubuntu 20.04 / 22.04，Windows + WSL2 也可参考
• Python：3.10 或 3.11
• GPU：建议至少 16GB 显存；如果使用 QLoRA，可以放宽到 8GB 左右
• 基座模型：Qwen2.5-7B-Instruct 等开源模型
• 推理接口：OpenAI 兼容接口

3.1 安装 LlamaFactory

这里需要说明一下：开源项目迭代很快，克隆地址、参数命名可能发生变化。推荐先到官方仓库确认最新安装方式，下面给出的是社区最常见的安装流程。

# 1. 克隆仓库 git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory # 2. 创建虚拟环境（推荐） conda create -n llama_factory python=3.11 -y conda activate llama_factory # 3. 安装依赖 pip install -e .

安装过程如果遇到网络慢，可以使用国内镜像源，例如：

pip install -e . -i https://pypi.tuna.tsinghua.edu.cn/simple

安装完成后，可以执行以下命令验证环境是否正常。

llamafactory-cli version

如果你看到版本号输出，说明 LlamaFactory 的命令行工具已经安装成功。

3.2 准备模型权重

本文示例使用 Hugging Face 模型仓库中的 Qwen 系列模型。如果你的服务器无法直接访问 Hugging Face，也可以通过 ModelScope 或国内镜像下载。

下载模型后，将模型路径配置到环境变量中，方便后续命令引用。

export BASE_MODEL_PATH=/data/models/Qwen2.5-7B-Instruct

模型下载是一个比较耗时的过程，建议提前准备好网络环境，并注意磁盘空间。

4. 核心原理：如何构造 Agent 工具调用数据集

4.1 数据决定微调效果

很多初学者以为微调就是把一些问答数据丢进去训练。但在 Agent 场景里，数据格式远比数据量重要。如果你希望模型学会“先调用工具，再根据工具结果回答”，那么训练数据里必须包含完整的 Agent 执行过程，而不是简单的一问一答。

一个理想的 Agent 工具调用训练样本，应该包含：

• 用户原始指令。
• 模型决定调用哪个工具的中间思考。
• 工具调用的具体参数。
• 工具返回的结果。
• 基于工具结果的最终回复。

4.2 数据集文件结构

我们以 LlamaFactory 常见的 Alpaca 格式为例。在项目目录下创建数据目录和数据集文件：

my_agent_project/ ├── data/ │ ├── agent_tool_data.json │ └── dataset_info.json ├── scripts/ │ ├── train_lora.sh │ └── export_model.sh └── agent/ ├── agent_core.py └── config.py

agent_tool_data.json的内容大致如下：

[ { "instruction": "请查询北京今天的天气并告诉我。", "input": "", "output": "我可以先调用天气查询工具获取北京天气信息。\n\nAction: get_weather\nAction Input: {\"city\": \"北京\"}\n\nObservation: 晴，25℃\n\n最终答案：北京今天天气晴，气温25℃。" }, { "instruction": "帮我查一下上海明天会下雨吗？", "input": "", "output": "我来查询上海明天的天气。\n\nAction: get_weather\nAction Input: {\"city\": \"上海\"}\n\nObservation: 小雨，22℃\n\n最终答案：上海明天有小雨，记得带伞。" } ]

在这个数据格式里，我们用Action、Action Input、Observation这样的约定，把 Agent 的“思考-行动-观察”过程写进训练文本。注意，这里只是示例格式，实际使用时需要根据你选择的模板和模型做调整。

要让 LlamaFactory 认识这个数据集，需要在dataset_info.json中注册它：

{ "agent_tool_data": { "file_name": "agent_tool_data.json", "columns": { "prompt": "instruction", "query": "input", "response": "output" } } }

如果你没有自定义数据集，也可以先使用 LlamaFactory 自带的示例数据集跑通流程，再替换成自己的数据。

4.3 数据增强与样本量建议

Agent 工具调用数据集不需要追求几十万条，质量远大于数量。一个能跑通的 Agent 任务，可以先准备 200 到 500 条高质量样本，覆盖：

• 不同工具的组合调用。
• 同一工具的不同参数。
• 工具返回空结果、异常结果时模型的兜底回复。
• 多轮工具调用的链路。

在数据不足时，可以用两类方法扩充：

1. 人工编写种子样本：先人工写几十条，覆盖核心场景。
2. 大模型辅助生成：用能力更强的模型生成候选样本，再人工筛选修正，避免错误数据污染小模型。

5. 完整实战：用 LlamaFactory 微调模型并构建 Agent

5.1 LoRA 微调配置与训练

在my_agent_project/scripts/train_lora.sh中写入以下内容：

#!/bin/bash export BASE_MODEL_PATH=/data/models/Qwen2.5-7B-Instruct export DATA_DIR=./data llamafactory-cli train \ --model_name_or_path $BASE_MODEL_PATH \ --stage sft \ --dataset agent_tool_data \ --dataset_dir $DATA_DIR \ --finetuning_type lora \ --lora_rank 8 \ --lora_alpha 16 \ --template qwen \ --output_dir ./output/my_agent_lora \ --num_train_epochs 3 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 8 \ --learning_rate 5e-5 \ --logging_steps 10 \ --save_steps 200 \ --fp16

参数说明：

• --finetuning_type lora：使用 LoRA 微调，冻结原模型参数，只训练低秩适配矩阵。
• --lora_rank 8：LoRA 低秩矩阵的秩。秩越大，可学习的参数越多，效果上限越高，但显存和过拟合风险也增加。常见范围在 4 到 32。
• --template qwen：对话模板，需要与基座模型匹配。这一步很关键，模板选错会导致模型输出混乱。

训练过程会在终端打印 loss 变化。当 loss 逐渐下降并稳定时，说明模型正在学习。

5.2 训练后测试微调模型

训练完成后，先用命令行和微调后的模型聊两句，确认工具调用格式是否稳定。

llamafactory-cli chat \ --model_name_or_path /data/models/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./output/my_agent_lora \ --template qwen \ --finetuning_type lora

在交互界面输入类似数据集的指令，观察模型输出是否包含工具调用语句。

5.3 将 LoRA 权重与基座模型合并

微调生成的 LoRA 权重不能单独部署，需要合并回基座模型。在scripts/export_model.sh中写入：

#!/bin/bash export BASE_MODEL_PATH=/data/models/Qwen2.5-7B-Instruct llamafactory-cli export \ --model_name_or_path $BASE_MODEL_PATH \ --adapter_name_or_path ./output/my_agent_lora \ --template qwen \ --finetuning_type lora \ --export_dir ./output/my_agent_model_merged

合并完成后，./output/my_agent_model_merged就是一个可以直接部署的完整模型目录。

5.4 编写 Agent 执行代码

现在我们来写 Agent 的核心执行代码。为了让示例通用，我们使用 OpenAI 兼容的接口格式，这样既能连接商业 API，也能连接本地部署的模型服务。

# agent/config.py import os # 从环境变量读取配置，避免密钥硬编码 API_BASE = os.getenv("AGENT_API_BASE", "http://localhost:8000/v1") API_KEY = os.getenv("AGENT_API_KEY", "EMPTY") MODEL_NAME = os.getenv("AGENT_MODEL_NAME", "my_agent_model_merged") MAX_STEPS = int(os.getenv("AGENT_MAX_STEPS", "5"))

# agent/agent_core.py import json from openai import OpenAI from .config import API_BASE, API_KEY, MODEL_NAME, MAX_STEPS client = OpenAI(base_url=API_BASE, api_key=API_KEY) # 工具定义：使用 OpenAI function calling 格式 TOOLS = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气信息", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如：北京" } }, "required": ["city"] } } } ] # 工具的具体实现 def get_weather(city: str) -> str: """模拟的天气查询工具。真实项目中可替换为 HTTP 调用。""" mock_data = { "北京": "晴，25℃", "上海": "小雨，22℃", "广州": "多云，30℃", } return mock_data.get(city, f"暂未收录 {city} 的天气信息") TOOL_IMPL = { "get_weather": get_weather, } def run_agent(user_query: str) -> str: """核心 Agent 循环：调用模型 -> 判断是否调用工具 -> 返回结果""" messages = [{"role": "user", "content": user_query}] for step in range(MAX_STEPS): response = client.chat.completions.create( model=MODEL_NAME, messages=messages, tools=TOOLS, tool_choice="auto", ) msg = response.choices[0].message # 模型没有要求调用工具，说明可以直接给出最终答案 if not msg.tool_calls: return msg.content # 模型要求调用工具：把模型决策追加到历史中 messages.append(msg) # 逐个执行工具调用 for tool_call in msg.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) print(f"[Agent Step {step + 1}] 调用工具 {fn_name}, 参数: {fn_args}") tool_result = TOOL_IMPL[fn_name](**fn_args) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(tool_result, ensure_ascii=False), }) return "Agent 执行达到最大步数，请简化问题或检查工具调用。"

5.5 运行与验证

写一个简单的入口脚本：

# main.py from agent.agent_core import run_agent if __name__ == "__main__": result = run_agent("北京今天天气怎么样？") print("最终回答:", result)

启动本地模型服务后，运行：

python main.py

预期输出类似：

[Agent Step 1] 调用工具 get_weather, 参数: {'city': '北京'} 最终回答: 北京今天天气晴，气温25℃。

这里有一个关键点：如果你想体验完整效果，需要先把微调好的模型部署成一个 OpenAI 兼容的推理服务，然后把AGENT_API_BASE指向该服务的地址。如果你的环境暂时不方便部署模型，也可以先把这个 Agent 代码指向任意兼容 OpenAI 格式的模型服务，观察整个执行链路。

6. 常见问题与排查思路

在 Agent 开发和微调过程中，最容易踩到下面这些坑。

问题现象	常见原因	解决思路
微调后模型不调用工具	训练数据里工具调用格式不统一	检查数据集中 Action、Observation 的格式是否一致，增加示例数量
工具参数输出 JSON 解析失败	模型输出的参数不是合法 JSON	在数据里增加损坏 JSON 的修复示例，或在代码里增加二次解析逻辑
Agent 循环多次后始终不结束	模型一直在调用工具，没有给出最终答案	设置MAX_STEPS，同时培养模型在 Observation 后直接给出结论
显存不足，训练中断	LoRA rank 或 batch size 过大	降低per_device_train_batch_size，开启gradient_accumulation_steps，尝试 QLoRA 量化
微调后通用能力下降	数据过于单一，学习率过大	降低学习率到 1e-5 附近，增加一些通用对话数据混合训练

这里单独说一下工具调用 JSON 解析失败的问题。很多 Agent 在线上运行时报错，根本不是模型能力不够，而是代码没有做容错。一个比较可靠的做法是：先尝试json.loads，如果失败，用正则把最外层的{}提取出来再解析。

import re def safe_json_loads(text: str): try: return json.loads(text) except json.JSONDecodeError: # 提取第一个 { 到最后一个 } 之间的内容 match = re.search(r"\{.*\}", text, re.DOTALL) if match: return json.loads(match.group()) raise ValueError(f"无法解析工具参数: {text}")

这个兜底逻辑能在不少场景下避免线上事故。

7. 最佳实践与工程建议

7.1 数据质量大于模型大小

在实际微调中，我们经常看到两种结果：有人用 500 条高质量数据，微调出一个非常好用的 Agent；也有人堆了 5 万条网上爬来的数据，模型越调越笨。

原因很简单，Agent 工具调用的训练数据是一种“行为数据”，模型从里面学习的不是知识，而是行为模式。如果你的数据里 70% 的样本都是“直接回答”，只有 30% 是“先调工具再回答”，模型学到的行为就会偏向直接回答。因此在准备数据时，要统计一下各类行为的比例，确保工具调用样本占绝对多数。

7.2 建立 token 成本监控

Agent 上线后，一定要做 token 成本监控。只监控 API 费用是不够的，要分解到每个 Agent 任务，统计：

• 平均输入 token 数。
• 平均输出 token 数。
• 平均工具调用次数。
• 单次任务的成本中位数和 P99。

有了这些指标，你才能判断一次系统提示词的改动，到底让成本涨了还是降了。

7.3 大模型出数据，小模型上生产

这是当前 Agent 降本最实用的一条思路。

• 在开发阶段，使用能力更强的模型（闭源或大参数开源模型）来编写 Agent 逻辑、生成工具调用示例。
• 在数据准备阶段，利用强模型对弱模型的错误输出做修正，生成高置信度的训练数据。
• 在正式环境，部署微调后的开源小模型，把单次调用成本压到最低。

用数据蒸馏的方式，把“贵模型的能力”迁移到“便宜模型的权重里”，本质上是花一次训练成本，换长期的低推理成本。

7.4 缓存、重试与降级策略

Agent 工程化不能只考虑“成功路径”，还要考虑“失败路径”。建议在 Agent 执行层增加：

• 结果缓存：完全相同的查询，直接命中缓存，不重复调用模型。
• 失败重试：网络超时、服务返回 5xx 时，按指数退避重试。
• 降级策略：小模型连续失败时，降级到更稳定的模型，保证核心链路可用。

这些策略看起来老生常谈，但在 Agent 成本控制中同样重要，因为每一次重试都意味着一次新的 token 消耗。

7.5 安全与授权边界

Agent 一旦能够调用工具，它就拥有了“行动能力”。在工程实践中，必须注意以下几点：

• 工具调用前做参数校验，禁止通过 Agent 触发危险操作。
• 涉及删除、修改、转账等敏感操作时，增加人工审批环节。
• API Key 和模型密钥通过环境变量或密钥管理服务注入，严禁硬编码到代码仓库。
• Agent 的提示词中不要包含敏感的系统提示和内部逻辑，防止被恶意用户套取。

8. 总结与下一步

这篇文章从 Agent 成本构成、LlamaFactory 微调、工具调用数据集构造、Agent 核心代码、常见问题和工程实践几个方面，完整走了一遍低成本 Agent 开发的闭环路径。

关键技术点可以总结为：

1. Agent 的高成本主要来自多轮对话中重复累计的输入 token。
2. 用 LlamaFactory 对开源小模型做 LoRA 微调，是降低单次推理成本的有效路径。
3. 微调数据决定了模型是否稳定调用工具，数据质量比数据量更关键。
4. 小模型落地生产时，仍然需要缓存、重试、降级、安全校验等工程手段。

低成本的 Agent 开发路线，本质上是一种“模型私有化 + 数据蒸馏”的组合拳。下一次你拿到一个 Agent 需求时，不妨先画出完整调用链路，算一笔 token 账，再决定是用大模型硬跑，还是先用开源模型微调一个“专属 Agent 大脑”。

如果这篇文章对你有帮助，可以收藏备用。后面我会继续拆解更细致的 Agent 数据构造和分布式推理部署方案，欢迎保持关注。