免费大模型当Agent后台：成本、工具调用与本地部署实战

做agent开发最烧钱的不是服务器，是token。

我去年带过一个办公自动化agent项目，就是很普通的场景：让AI查待办、读邮件、写周报。跑一个完整流程要调用七八次大模型，平均每次消耗2k到4k token，加上工具返回内容、思维链输出，一次任务轻轻松松烧掉2.5万token。那段时间每个月账单一出来，我的表情都跟看见工作流跑崩了一样。

所以从年初开始，我一直在研究一件事：各种大模型，能不能免费拿来当agent后台？

答案是能，而且路不止一条。这篇笔记就是把我的思路和实踩经历整理一遍：从成本和隐私动机，到免费模型的三个来路，再到工具调用这个关键门槛，最后给出几步实际配置和一堆避坑心得。想低成本入坑agent开发的朋友，应该能少走不少弯路。

1. 省钱只是表面动机：免费大模型当agent后台的三个真实价值

1.1 成本账算下来，agent开发是真的烧钱

先说一个我的实际数字。为了让读者有体感，我按一个典型agent任务拆开算笔账：

一次任务下来，基本就是1万到2.5万token。如果agent每天被调用50次，一个月就是150万到350万token。按现在国内主流收费API的价格，中等上下文模型每百万token大概十几到几十块钱，一个月成本就是几十到上百块，看着不多。但一旦业务量上来，agent一次任务动不动十几次工具调用，成本直接指数级上升。

更要命的是，agent在开发调试阶段要反复跑。一次失败的调用链可能烧掉和成功时一样的token，而且你根本不知道是哪一步出的问题。我用收费API调试过一个工具调用解析bug，一下午烧掉几十块，那个心痛感现在还记得。

免费模型把这个问题直接归零了。本地部署的话，成本只有电费。

1.2 数据不出门：本地部署对敏感业务的意义

成本之外，第二个常被忽略的动机是隐私。

agent的特点是必须让模型看到业务上下文才能干活。用户邮件、内部知识库文档、客户记录、公司流程这些数据，如果走第三方API，就等于把数据送到了模型服务商的服务器上。大厂可能有合规协议，但对于很多内部工具、行业应用来说，这仍然是不敢跨的线。

把免费开源大模型本地部署成agent后台，数据链路全程在自己的服务器上走完。模型推理在本地，工具调用在本地，知识库检索在本地，外部只暴露一个agent应用界面。这对我好几个客户来说是刚性需求——他们的数据根本不允许出内网。

1.3 可控性：能微调、能换版本、不受平台条款影响

第三个价值很多人没意识到：可控性。

用开源免费模型，你拿到的是完整的模型权重。今天发现这个版本工具调用成功率低，可以换更早的版本；业务场景足够垂直，可以拿自家数据做LoRA微调；别的团队训练出一个更强的中文模型，拉下来就能替换。

这些事用闭源API完全做不到。你只能在厂商允许的模型列表里选，只能等厂商更新版本，如果某个调用参数被平台限制，你一点办法都没有。我认识几个团队就是被厂商突然调整免费额度坑过，整个agent后台直接停摆，被迫连夜迁移到自部署方案。

2. 免费模型的三个来路：本地部署、平台赠送、开源API

2.1 本地部署路线：Ollama和vLLM的取舍

免费的"零号方案"肯定是自己部署开源模型。现在这条路已经被工具链铺得很平了。

我最常用的是Ollama，它对入门者极度友好。一条命令就能把模型拉下来：

bash复制# 拉取一个小尺寸的Qwen模型
ollama pull qwen2.5:7b

# 启动服务，默认监听 11434 端口
ollama serve

就这两步，一个本地模型服务就跑起来了，而且自带OpenAI兼容接口。对于agent开发来说，这意味着你可以在代码里用标准的SDK直接连它，不用关心Ollama内部细节。

vLLM则是另一个方向。如果你的请求量大、对并发吞吐有要求，vLLM的PagedAttention机制能把显存利用率和推理吞吐提上去，尤其适合多路agent并发调用的场景。代价是配置复杂一些，需要自己处理模型格式转换（有时要转成AWQ或GPTQ量化格式）和服务化。

两条路的取舍，我放在第4章详细聊，这里先给结论：个人开发、demo验证、团队小规模用，选Ollama；线上服务、高并发、多人共用，上vLLM。

硬件方面，一个参考：

2.2 平台赠送的免费模型额度

本地部署不是唯一答案。现在国内不少大模型平台都会提供免费额度或免费模型，用来做agent开发和学习，效率直接拉满。

这类方案的优点是零硬件成本、上手快、模型能力强。我用过的几个典型方案：

• 智谱AI的GLM-4-Flash，官方长期免费，工具调用能力在国产模型里数一数二，拿来做agent后台很顺手。
• 硅基流动（SiliconFlow） 这类聚合平台，会免费开放一批开源模型（比如Qwen、DeepSeek系列），注册后有免费额度，可以在它上面快速验证agent逻辑，不用先买显卡。
• 阿里云百炼等云平台，新用户一般有一定额度，适合短期的原型验证。

但这个方案有个需要注意的点：免费额度往往有有效期和限流。我见过好几个朋友，把免费额度当成"永久免费"来做生产系统，结果某天突然被限流或者额度到期，agent后台直接瘫痪。我的建议是：平台赠送适合做三件事——快速验证模型效果、学习agent开发、跑通Demo。要上生产，要么买付费服务，要么切本地部署，别把业务押在免费额度上。

2.3 开源免费API的甄别与避坑

还有一个来路，是一些团队或个人搭建的开放API服务，免费或低价提供开源模型的API调用。这类思路分享经常会有人提到，但我的态度一直很谨慎。

甄别这样的服务，我给自己定了几条标准：

1. 看透明度：提供方是否明确说明背后跑的什么模型、什么版本、部署在哪里？
2. 看限流策略：免费服务的限流参数是否公开透明？不明不白的限流等于随时可能断供。
3. 看数据声明：平台是否声明会记录请求内容？如果连基本的数据隐私承诺都没有，那agent的业务数据流过去很危险。
4. 看口碑与持续度：服务上线多久了？社区反馈如何？我见过不少做半年就关停的小服务，中途迁移是很痛苦的。

坦白说，我现在很少依赖这类第三方免费API了。如果一定要用，我的原则是：只做辅助通道，不做主链路。主链路要么本地部署，要么官方有明确免费政策的服务。把宝押在一个来历不明的免费API上，等于把自己的系统根基交给别人顺手托管。

3. agent后台的核心门槛：工具调用能力决定能不能当后台

3.1 从"聊天"到"调用工具"的思维转变

很多人以为把大模型接到agent框架里就能当后台，结果跑起来发现模型完全不按套路出牌——要么不调用工具，要么调用错误的工具，要么返回的JSON格式没法解析。

问题出在哪？他们把"聊天模型"和"代理模型"混为一谈了。

普通聊天场景，模型要做的只是"根据用户问题生成回复"。但agent后台场景，模型要做的更复杂：它要分析用户请求，判断是否需要调用外部工具，如果需要就输出一个特定结构（工具名+参数），程序执行完工具后再把结果喂给模型，模型再决定下一步。

这个过程就是function calling（工具调用）。它要求模型不仅懂语言，还要具备结构化输出能力和决策能力。

拿最直观的对比来说：

想当agent后台，第一件事就是确认模型有没有真正可用的function calling能力，而不是只看它"看起来很聪明"。

3.2 免费模型工具调用能力横向参考

就我实际测过的开源免费模型来说，工具调用能力差距非常大。简单分享几个直观结论，供参考（我的测试方式很朴素：给模型定义5个工具，让它完成10个需要不同工具组合的任务，统计成功率）：

• Qwen系列（7B/14B）：工具调用能力在开源模型里属于第一梯队。Qwen2.5系列的instruct版本对function calling有专门优化，输出JSON的规范性很稳。我拿Qwen做agent后台的默认选择，成功率在80%以上。
• GLM系列（4B/FLASH等）：智谱开源的ChatGLM/GLM-4系列工具调用做得也不错，尤其是它在中文指令理解上有优势，适合中文业务场景。
• DeepSeek系列：DeepSeek的通用能力很强，但在小参数版本（如7B/16B）的工具调用稳定性上，我的测试结果略逊于Qwen和GLM。DeepSeek的强项是R1类推理模型，但目前推理模型在工具调用场景下不如 instruct 型模型稳定。当然DeepSeek官方API和本地部署的模型在能力上有差异，这个需要区分。
• 更小的1.5B~4B模型：这类模型跑起来很轻，但工具调用成功率明显下降。如果任务很简单（只调用一个工具、参数很少），还能用；一旦涉及多步决策、多个工具，就容易掉链子。

一句话总结：免费模型里，7B量级的Qwen/GLM是agent后台性价比最稳的选择；更小更轻的模型，只建议在固定单工具场景使用。

3.3 让模型"学会"工具调用：提示词设计的关键

如果你选的开源模型工具调用能力符合预期，但实际跑的时候还是会出问题，大概率是提示词没设计好。

我踩过很多次坑之后，总结出几条针对function calling场景的提示词设计要点：

1. 把所有工具列表、参数含义、使用场景写清楚。模型不是人，它不会"猜"你这个工具是干嘛的。比如一个send_email工具，你要写清楚to参数是收件人邮箱，subject是邮件主题，还要注明"如果用户没有提供收件人，必须向用户询问，不能使用默认值"。
2. 设置确定的格式规则。在系统提示词里直接写：你必须输出JSON格式，包含action和action_input两个字段，action必须是工具列表中的名称，action_input是符合参数说明的JSON对象。
3. 给一个few-shot示例。这是提升效果最有效的手段之一。给模型看一个小工具调用的输入-输出示例，它就能照猫画虎。尤其是小模型，一个代表性示例比十句规则都管用。
4. 控制temperature。工具调用任务需要的是确定性，不是创造性。我把temperature设置在0.1~0.3之间，明显能降低模型的随机失误率。
5. 明确"无匹配工具"时的行为。必须告诉模型：如果用户请求没有对应的工具可以处理，不允许编造工具名，直接回复"无法处理该请求"。否则模型容易幻觉出一个不存在的工具名，导致程序解析崩溃。

4. 实操记录：从本地模型到agent后台的完整接入路径

4.1 第一步：把开源模型跑起来并暴露OpenAI兼容接口

这部分我给一个可以直接照抄的最小化路径。我用Ollama做例子，因为它是现在最省事的本地推理方案。

在目标机器上装好Ollama之后，拉模型：

bash复制# 拉取qwen2.5:7b，这个尺寸在消费级显卡上跑得动
ollama pull qwen2.5:7b

然后启动服务：

bash复制# 前台启动（调试时用）
ollama serve

# 后台启动（服务化，Linux/macOS）
nohup ollama serve > /tmp/ollama.log 2>&1 &

启动后验证接口：

bash复制curl http://localhost:11434/v1/models

如果返回一个包含模型id的JSON数组，说明服务正常。这个/v1路径就是Ollama内置的OpenAI兼容接口，后面agent框架直接认这个地址就行。

如果你用的是WSL2环境，需要注意：Ollama在WSL2里跑没问题，但要保证Windows能访问WSL2的端口，通常需要设置端口转发，或者直接在WSL2里完成所有agent开发，不跨系统访问。

4.2 第二步：在agent框架里配置模型接入

现在你已经有了一个本地模型服务，接下来把它配置到agent框架或自己的代码里。

以Dify为例（也可以用FastGPT、Coze或其他agent平台），配置流程如下：

1. 进入"设置" -> "模型供应商" -> 选择"OpenAI-API-compatible"；
2. 填写API地址：http://<你的服务器IP>:11434/v1；
3. API Key：填写任意字符串，比如ollama（Ollama不校验Key）；
4. 模型名称填写：qwen2.5:7b；
5. 点击测试连接，保存。

这里有一个容易踩的坑：Ollama的模型名称和OpenAI的model参数是对应的，填错了就连接失败。 你拉取的标签是qwen2.5:7b，配置里就写qwen2.5:7b，不要想当然填qwen2.5或qwen。

如果你是自己写代码接入，就更直接了。下面这段Python代码就是完整的最小agent调用链：

python复制from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # 任意值
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名，如北京"}
                },
                "required": ["city"]
            }
        }
    }
]

messages = [
    {"role": "system", "content": "你是助手，用工具回答用户问题。"},
    {"role": "user", "content": "北京今天会下雨吗？"}
]

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=messages,
    tools=tools,
    tool_choice="auto"
)

print(resp.choices[0].message)

这段代码跑通后，你会看到模型返回一个tool_calls字段，里面是模型决定要调用的工具名和参数。这就说明模型已经进入了"agent模式"。

4.3 第三步：验证工具调用的最小闭环

拿到tool_calls还只是第一步，真正的agent闭环需要"调用工具 -> 把结果返回给模型"。这一步的逻辑是：

1. 从模型响应里提取tool_calls；
2. 程序去执行真正的工具函数（比如查天气API）；
3. 把工具执行结果作为一条role=tool的消息追加到messages里；
4. 带着新消息再次调用模型，让模型根据工具结果生成最终回答。

核心代码如下：

python复制messages = [
    {"role": "system", "content": "你是助手，用工具回答用户问题。"},
    {"role": "user", "content": "北京今天会下雨吗？"}
]

# 第一次调用：模型决定调用工具
resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=messages,
    tools=tools,
)

tool_call = resp.choices[0].message.tool_calls[0]

# 程序执行工具
weather = get_weather("北京")

# 拼装工具结果
messages.append({
    "role": "assistant",
    "content": None,
    "tool_calls": [tool_call]
})
messages.append({
    "role": "tool",
    "tool_call_id": tool_call.id,
    "content": str(weather)
})

# 第二次调用：模型总结回答
resp2 = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=messages,
    tools=tools,
)
print(resp2.choices[0].message.content)

这个最小闭环一旦跑通，恭喜，你的agent后台已经从"聊天模型"升级成了"能调用工具干活的工作流引擎"。后面往上面挂任何工具都遵循这个套路，核心不变。

5. 跑起来之后才会踩的坑：上下文、并发与稳定性

5.1 上下文窗口不够会引发连锁反应

我第一个规模化使用本地模型的时候，最头疼的就是上下文窗口。

7B模型一般只有4k~32k上下文，而agent任务最吃上下文。举个具体例子：我先让模型查询"这个项目相关的所有未完成任务"，工具返回可能就有1000~2000字；再加上系统提示词、历史对话、中间推理，几轮之后上下文就到上限了。

一旦超出窗口，模型要么报错，要么更糟糕——它开始遗忘最早的工具返回结果，然后煞有其事地说"根据前面查到的信息"，实际上它根本没记住。这是agent幻觉的高发场景。

我的解法有三个：

1. 工具返回内容强制截断：工具返回之前先做摘要或只保留关键字段，比如查询数据库只要传回id,name,status,time，不要把整行数据都塞进去。
2. 对话历史裁剪：超过N轮工具调用后，把最早的消息压缩成摘要，再拼到当前上下文。这相当于给模型做"二次记忆"。
3. 独立规划与执行分离：不在同一个上下文中做完所有事。规划模型负责拆解任务，执行模型单次只处理一步，每一步都是干净的上下文。

5.2 并发瓶颈：本地单卡和免费API都不轻松

本地部署的另一个现实是：单卡GPU在推理时是串行的。你发10个并发请求，很可能要排着队跑，每个请求等几十秒。agent又是多步调用的场景，一个用户任务可能触发10次模型调用，稍微多几个人用，体验就会很糟糕。

Ollama默认并发数是1，想提升一些，可以设置环境变量：

bash复制export OLLAMA_NUM_PARALLEL=4

但说实话，这个并行提升有限，因为显存就那么大。如果真要高并发，需要上vLLM，或者多卡负载均衡、多副本部署。这里我的建议是：个人使用、小团队demo，不要过早考虑并发优化，先把功能跑通；真正要上生产了再设计推理集群。

免费API那边也好不到哪去，限流是常态。平台赠送的免费额度通常有每分钟请求数限制，一旦在agent里触发大量工具调用，很容易撞限流。解决办法是在应用层做请求队列和指数退避重试，把限流当成常态来设计系统。

5.3 稳定性兜底：容错、重试与降级

免费模型最大的毛病是不稳定。不是指服务不稳定（这个反而还好），而是指模型输出不稳定。

小模型常见翻车有两种：

• 输出不合法JSON。比如JSON里多了个逗号，或者直接输出了一堆解释性文字而不是纯JSON。解决方法是解析时做容错：先用正则把JSON片段抽出来，再交给解析器；解析失败就带着错误信息重试一次，让模型自己修正。
• 工具参数幻觉。模型写出了一个工具没定义的参数，或者把字符串写进数字类型的字段。这个需要程序侧做参数校验，不符合schema就触发重试，并把校验错误信息告诉模型，让它重新输出。

我总结的稳定三元组是：校验、重试、降级。

• 校验：所有模型输出先过schema验证，不通过不走业务逻辑；
• 重试：校验失败最多重试2~3次，每次都附带具体报错，让模型理解自己哪里错了；
• 降级：重试之后还不行，就进入人工兜底，或者切换到一个更稳的模型（比如从免费模型切换到收费模型）。

这套组合下来，我现在的agent系统稳定性从最初的60%左右提升到95%以上。核心不是让模型不犯错，而是让系统在模型犯错的时候不会崩。

6. 从"能用"到"好用"：混合调度、MCP与技能化的进阶思路

6.1 混合架构：复杂规划交给强模型，简单执行交给免费模型

使用免费模型不等于整个系统都只用一个免费模型。我现在的主力架构反而是"混合调度"：

• 规划层：用一个能力更强的模型（哪怕收费）来做任务分解、复杂推理、异常判断。这一层的调用频率不高，一次任务只调用1~2次，成本可控。
• 执行层：用免费模型（本地部署的7B/14B）干脏活累活，比如意图分类、实体抽取、文本摘要、简单工具的调用。这一层调用频率最高，用免费的就能省下大笔开销。

举个例子，一个客服agent：用户说"帮我查一下订单，然后写一封催发货的邮件"。规划层由强模型识别出这是"查订单 + 写邮件"两个子任务；执行层交给免费模型，一个负责调用订单查询工具，一个负责根据结果起草邮件。最后汇总回复可以由规划层润色，也可以直接让执行层完成。

这个架构的好处是：该花的花，该省的省。复杂任务的成功率有强模型兜底，高频执行环节的成本又降到了接近零。

6.2 MCP统一工具协议，解决"工具格式不统一"的老大难

做agent开发的同学最近应该经常看到MCP（Model Context Protocol）这个词。我自己的理解很朴素：MCP就是模型与工具之间的标准化接口协议。以前每个agent框架都要自己定义一套工具调用格式，你写一个数据库工具，在Dify里是一种写法，在自研框架里得重写一遍。有了MCP，工具服务方按照统一协议暴露能力，agent侧按统一方式调用，一套工具到处用。

对免费模型来说，MCP的影响有两面性：

好处是，工具的一次适配、到处使用，省去了大量的魔法字符串和格式转换工作，模型侧的指令描述也更统一，便于小模型学习。

不利的一面是，MCP协议本身包含较复杂的元数据，会占上下文。小模型上下文本就紧张，加上MCP的工具描述文档后，留给实际任务的token就更少了，工具响应可能变迟钝。我的经验是：如果用的是7B以下的小模型，MCP带来的上下文开销要提前计算好；如果模型在14B以上，基本不用担心。

6.3 agent skill：把高频任务沉淀成可复用技能

最后说一下skill（技能）。之前我专门研究过agent skill和MCP的区别，这里简单说下我自己的理解：

• MCP解决的是"工具怎么连"的问题——标准化协议，接口层面。
• agent skill解决的是"任务怎么做"的问题——它把针对某类任务的提示词、工具调用流程、few-shot示例、前置条件、后处理逻辑，打包成一个可复用的"技能包"。

拿我自己为例。我封装了一个"周报生成"技能，里面包含：系统提示词（要求模型先查项目进展、再查待办、最后写成结构化周报）、需要用到的工具列表、周报的格式规范、常见错误示例。agent只要调起这个技能，自动带着完整上下文去执行，不需要每次重新拼提示词。

对免费模型来说，skill价值特别大——因为小模型单次推导能力弱，但把任务模板化之后，它只需要做"填空"和"按步骤执行"，对推理能力的要求大幅降低，成功率反而上去了。

我把几个高频任务都技能化之后，实测7B模型在"客服工单分类"和"日报生成"场景的准确率从70%出头提升到90%左右。这就是把复杂任务变得简单后的回报。

最后顺便提一句：我现在的agent后台也不是只用免费模型，而是把免费模型放在了执行链路上，把收费模型留在了规划链路上。这个组合跑下来，月度成本比最初的全收费方案低了80%以上，稳定性反而更高了。如果你也在搞agent开发，又不甘心被token账单绑架，建议从今天开始就在电脑上起一个Ollama，拉一个7B模型，把上面那段最小闭环代码跑通。成本为零，收获为零的快乐，谁用谁知道。