柏林 GTC 上智能体与开源模型是现场讨论密度最高的两个方向。智能体不是新发明出来的聊天框而是让模型在对话之外获得工具、记忆和规划能力开源模型则让这种能力不再被单一厂商绑定。热点归热点实际做项目时还是要回答一个具体问题在本机或内部环境里怎样用开源模型把一个能查订单、读文档的智能体跑起来。下面围绕一条可复现的链路展开用 Ollama 部署开源模型用 Dify 社区版编排智能体再用自定义工具和知识库补齐业务能力。全文不会停留在概念层而是会把部署命令、模型参数、工具接口、验证方式和排查路径都拆开讲。无论你是第一次搭智能体还是已经在用闭源 API、想切到开源模型都能按这个流程得到一个最小可用版本。需要先说明的是下面涉及的具体版本和界面名称在 Dify 与 Ollama 快速迭代时可能会有变化。落地时以你实际安装的版本为准但结构、原理和排查思路基本一致。1. 先看清智能体与开源模型在工程里的分工在动手之前先花几分钟理解三个关键词智能体、开源模型、智能体编排平台。很多人失败不是不会写提示词而是没搞清楚这几层各自负责什么。1.1 智能体是什么从对话模型到会调用工具的决策体如果把大模型比作一个刚入职的新员工他能读懂问题、给出流畅回答但没有电话、没有系统账号、没有公司资料库很多事情做不了。智能体就是给他配上电话、系统权限和资料库让他遇到任务时自己决定先查什么、调什么再回答什么。技术定义上智能体是大模型与外部能力组合而成的闭环系统。这个闭环通常包含四个部分规划、工具调用、记忆、结果验证。模型收到用户请求后先判断需要哪些信息再决定是否调用某个工具拿到工具结果后结合历史对话和业务约束生成最终回答。如果需要多步操作它可能还会根据第一次结果继续调第二个工具。在实际产品里最常见的区分是“对话应用”和“智能体应用”。应用类型是否自主选择工具典型场景依赖对话型 Chat否普通问答、内容生成模型 知识库智能体型 Agent是查订单、多步操作、跨系统处理模型 工具 流程编排这里容易误解的地方是智能体并不是某一个模型而是一种“模型 工具 编排”的组合。另一个容易踩的坑是不是所有模型都适合做智能体底座。工具调用依赖模型理解函数描述、按 JSON 格式填充参数这需要模型在训练阶段专门强化过。直接用不支持工具调用的模型硬接结果往往是它不调用工具只根据训练记忆编答案。1.2 开源模型为什么适合做智能体底座看 GTC 上的讨论会发现很多团队关注开源模型不是因为它“免费”而是因为它解决了两个实际问题数据主权和定制空间。对比维度闭源 API 模型本地开源模型数据去向对话内容发送到第三方平台可完全内网部署敏感数据不出域调用成本按 token 持续计费主要是一次性硬件成本和电费可定制性只能调参数可以量化、微调、换基座部署门槛低申请 Key 即可需要 GPU 或较高内存工具调用稳定性通常较高取决于模型和提示词需要调开源模型近年来的进步主要体现在指令遵循、长上下文和工具调用能力上。以 Qwen 系列为代表的中文开源模型已经能在不少业务场景里承担工具调用任务。但这不意味着开源模型没有成本它把成本从“token 费用”转移到了“硬件、部署、调优和运维”上。落地项目之前建议先做一次小范围评测准备 20 到 50 个真实业务问题给模型配置好工具看它有多少比例能正确决定调用、正确填充参数、正确使用返回结果。这个测试结果比任何榜单都更有参考价值。1.3 选型组合Ollama Dify 开源模型的适用边界下面要用到的技术组合是Ollama Dify 社区版 开源模型。Ollama 负责把模型跑起来解决“模型怎么运行”的问题。Dify 负责应用编排、工具接入、知识库、对话管理解决“智能体怎么组合”的问题。开源模型负责理解和决策解决“大脑”的问题。这套组合适合学习验证、企业内网知识库、内部单据查询、私有数据问答等场景。不适合的场景也很明显面向海量用户的公开服务、对响应时间要求极高、或需要复杂多智能体协作的生产系统需要另外做模型推理加速和分布式编排。注意这只是一个工程参考组合。生产环境可以把 Ollama 换成 vLLM 或类似推理服务Dify 也可以替换为其他编排平台但“模型、工具、编排”这三层的基本边界不会变。2. 环境准备本地先把开源模型和 Dify 跑起来很多教程直接讲 Agent 配置却忽略了运行环境。实际上环境问题占智能体项目起步阶段的大半工作量。先花二十分钟把底座跑通后面才有信号。2.1 硬件与系统要求如果你想从零开始跑通一个带知识库和工具的智能体不需要一开始就上大机器。一个中等配置的开发机足够做验证。组件最低建议更流畅的配置说明Ollama 7B/8B 量化模型8 核 CPU 16 GB 内存6 GB 以上显存的 GPU7B 量化模型能跑 CPU但生成速度有限13B 以上模型不建议纯 CPU 跑12 GB 以上显存大模型需要更高显存或更强量化Dify 社区版4 核 8 GB随并发升高增加主要是 Docker 容器占用资源磁盘20 GB50 GB 以上包含模型文件和 Docker 镜像先说明一个实际教训如果只打算做工具调用验证7B/8B 量级模型足够如果涉及大量文档理解优先保证 Embedding 和 Rerank 模型的部分而不是一味追求超大底座模型。2.2 安装 Ollama 并下载模型Ollama 的安装很直接。Linux 和 macOS 可以使用官方安装脚本Windows 直接下载安装包。启动服务后模型下载和运行都通过命令行完成。# 启动 Ollama 服务 ollama serve另一个终端里下载模型。这里以支持工具调用的 Qwen2.5 7B 量化版为例# 拉取模型tag 以 Ollama 仓库实际提供的为准 ollama pull qwen2.5:7b-instruct-q4_K_M下载完成后确认模型是否就绪# 查看本机已有模型 ollama list再用最简单的方式验证模型能不能正常对话curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct-q4_K_M, messages: [{role: user, content: 你好}] }如果返回正常的补全内容说明模型服务已经可用。这一步要确认的不只是“能启动”还包括模型 tag 是否写对、端口是否被占用、响应速度是否可接受。注意模型 tag 会随仓库更新变化。如果ollama pull拉不下来先打开 Ollama 官网确认当前可用的 tag不要凭记忆硬写。2.3 启动 Dify 社区版Dify 社区版推荐用 Docker Compose 启动。步骤一般如下git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d如果是学习环境可以直接用默认配置。如果是团队协作或后续要长期使用建议先git tag查看稳定的 release 版本并切换到固定版本避免直接用 master 导致下次启动时行为变化。启动完成后确认核心容器全部正常运行docker compose ps正常情况下web、api、worker、db、redis、sandbox 和向量数据库等容器都会处于运行状态。浏览器访问http://localhost或.env中配置的端口完成管理员账号初始化后就进入 Dify 的控制台。2.4 环境检查清单在进入配置前先按这份清单确认一次[ ]ollama list能看到已下载模型。[ ] 访问http://localhost:11434有接口响应文字。[ ] Dify 页面可以打开并创建管理员账号。[ ]docker compose ps没有出现容器反复重启。[ ] 如果内存紧张先关闭不需要的容器再继续。Dify 默认 Compose 文件会启动多个组件首次启动会拉取不少镜像磁盘小的地方需要留意。3. 在 Dify 中接入开源模型并创建 Agent 应用环境就绪后开始把模型接到 Dify 里并创建一个真正能调用工具的 Agent 应用。3.1 添加 Ollama 模型供应商在 Dify 控制台进入“设置 - 模型供应商”找到 Ollama点击添加模型。关键配置项如下。配置项示例值说明Model TypeLLM表示这是对话/工具调用模型API Endpointhttp://host.docker.internal:11434Dify 容器要能访问到 Ollama 服务Model Nameqwen2.5:7b-instruct-q4_K_M必须和ollama list里的 tag 一致Context Size4096 或 8192根据模型和硬件调整这里最容易错的是地址。如果 Dify 用 Docker 启动在容器内部访问宿主机时不能用localhost因为每个容器有独立的网络栈。Windows 和 macOS 上可以用host.docker.internalLinux 上推荐使用宿主机局域网 IP或直接把 Dify 容器配置成 host 网络模式。否则会一直报“连接失败”。3.2 创建 Agent 应用角色与工具设计进入 Dify 控制台创建空白应用时选择“Agent”类型而不是普通“Chat”类型。两者的区别在于Agent 类型会允许模型尝试调用已启用的工具普通 Chat 则只会做纯对话。先把角色提示词写好。提示词不必太长但要把“何时调用工具、何时不调用工具”说清楚。你是一个企业销售助手。你的任务是帮助用户查询订单、报价和产品资料。 规则 1. 当用户询问订单状态或订单信息时必须先调用订单查询工具不要根据记忆编造数据。 2. 当用户询问产品手册、价格政策、售后条款时先检索知识库再结合资料回答。 3. 工具返回结果后用简洁、专业的中文回答用户不要输出多余 JSON。 4. 如果工具或知识库中没有足够信息明确告诉用户当前无法确认。这段提示词的核心是“先查再答”。它并不能保证模型一定照做但能显著提高工具调用的触发概率。更长的提示词不一定是好事规则过多会让模型在真实对话中凌乱。3.3 配置模型参数模型参数直接影响工具调用的稳定性。常用的参数定义如下。参数推荐值作用Temperature0.2 ~ 0.4降低随机性减少模型自由发挥Top P0.7 ~ 0.9控制采样范围配合 Temperature 使用Max Tokens512 ~ 1024限制回答长度避免等待时间过长Function Calling开启让模型可以输出工具调用指令如果在配置页面看到“工具调用”相关的开关建议打开。用 Qwen2.5 这类经过工具调用训练的模型时工具调用成功率会明显高于普通对话模型。小技巧在调试阶段不要一次性把所有能力都打开。可以先只接一个订单查询工具用一条固定问题测试成功后再加知识库和其他工具。智能体项目的复杂度是逐步堆出来的一次加太多能力会很难定位问题。4. 用自定义工具补齐业务能力订单查询示例模型无法直接访问数据库这是智能体必须接工具的根本原因。下面用一个订单查询接口演示完整链路。4.1 为什么 Agent 一定要接工具模型的知识截止到训练时间它无法知道实时订单状态、当前库存或某个用户的私有数据。工具的作用就是给模型一个“可调用的外部接口”。在 Dify 中一个工具通常被描述成“模型能读懂的接口说明”接口路径、入参、出参、用途。模型收到用户问题后判断该问题匹配哪个工具然后按照工具的 JSON Schema 生成参数。Dify 框架负责真正发起 HTTP 请求并把结果返回给模型。因此工具描述写得好不好直接影响模型“想不想调”以及“能不能调”。4.2 用 FastAPI 实现订单查询工具这里用一个最小的 FastAPI 服务演示数据暂时放在内存里。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() FAKE_ORDERS { demoexample.com: [ {order_id: SO-1001, status: 已发货, amount: 299.00}, {order_id: SO-1002, status: 待付款, amount: 59.00}, ] } class QueryRequest(BaseModel): customer_email: str app.post(/api/query_order) def query_order(req: QueryRequest): orders FAKE_ORDERS.get(req.customer_email.strip().lower()) if not orders: raise HTTPException(status_code404, detailorder not found) return {customer_email: req.customer_email, orders: orders}启动服务pip install fastapi uvicorn uvicorn main:app --host 0.0.0.0 --port 8000先用 curl 直接验证接口本身是否正常curl -X POST http://localhost:8000/api/query_order \ -H Content-Type: application/json \ -d {customer_email: demoexample.com}预期返回{ customer_email: demoexample.com, orders: [ {order_id: SO-1001, status: 已发货, amount: 299.0}, {order_id: SO-1002, status: 待付款, amount: 59.0} ] }如果接口本身返回错误请先修接口再继续配置智能体。很多工具调用失败根因不在 Dify而在后端接口自身逻辑或网络不通。4.3 在 Dify 中配置 OpenAPI 工具Dify 支持通过 OpenAPI 规范导入自定义工具。在“工具”页面创建自定义工具选择导入 OpenAPI Schema。下面是一份最小可用的 Schema。{ openapi: 3.0.0, info: { title: Order Query API, version: 1.0.0 }, servers: [ { url: http://host.docker.internal:8000 } ], paths: { /api/query_order: { post: { operationId: queryOrder, summary: 根据客户邮箱查询订单列表, requestBody: { required: true, content: { application/json: { schema: { type: object, properties: { customer_email: { type: string, description: 客户邮箱 } }, required: [customer_email] } } } }, responses: { 200: { description: 订单查询成功 } } } } } }导入后在 Agent 应用的工具区启用这个工具。此时模型是否能正确调用取决于几个方面的配合operationId要唯一并且尽量简洁比如queryOrder。summary要写清楚用途模型根据它判断何时调用。参数描述要准确模型从用户话术里提取参数值。servers.url必须能被 Dify 后端访问到不能用localhost。导入完成后建议先在 Dify 工具页面点一次“测试”输入参数并确认返回结果。这一步通过后再回到 Agent 应用测试。4.4 验证工具调用链路在 Dify Agent 的调试对话框中输入查询 demoexample.com 的订单观察正常路径模型先输出工具调用指令Dify 调用/api/query_order拿到 JSON 结果模型再把结果组织成自然语言回答。如果模型没有调用工具而是自己编了一段订单信息说明工具配置或提示词有问题。还可以在 Dify 的日志或运行追踪里查看工具输入和输出用户问题: 查询 demoexample.com 的订单 工具调用: queryOrder 工具入参: {customer_email: demoexample.com} 工具出参: {orders: [...]} 模型回答: demoexample.com 的订单有两笔其中 SO-1001 已发货SO-1002 待付款。这个链路是智能体能否落地的核心指标。只要工具调用链路稳定后续接多少工具只是按相同模式扩展的问题。5. 知识库增强让智能体读懂企业内部文档工具让智能体能调系统知识库让智能体能读资料。两者结合才像一个真正能处理业务的助手。5.1 文档数据接入与分块在 Dify 中创建知识库上传 Markdown、PDF 或 TXT 文档然后设置分段参数。分块决定检索单元的大小直接影响回答质量。参数推荐值说明分段长度Token200 ~ 500太短检索碎片化太长信息密度低分段重叠10 ~ 50弥补切分边界断句问题索引方式高质量生产环境建议开启效果更好但更耗资源不同文档类型适合不同分段策略。FAQ 适合短片段产品手册适合中等长度片段长合同则要考虑按章节切分。Dify 的可视化分段可以让你看到切分结果这一步不要跳过切得太碎会导致检索结果语义不完整。5.2 Embedding 模型与 Rerank 模型选择知识库检索依赖向量化。文档被切成片段后需要转为向量用户问题也需要转为向量才能做相似度检索。这个转换由 Embedding 模型完成。在 Dify 中可以在模型供应商里同时配置 Ollama 的 Embedding 模型。一个常见的开源组合如下。用途模型说明Embeddingbge-m3中文效果较好支持多语言和多粒度文本Rerankbge-reranker-v2-m3对检索结果二次排序提升精度Agent 底座模型qwen2.5:7b-instruct-q4_K_M负责对话与工具调用先说明这不是“唯一最强”组合而是相对常见、社区资料多的组合。实际选型时拿着自己的业务文档做小批量评测比盲目追求榜单效果更有价值。加入 Rerank 后Dify 会先召回一批候选片段再用 Rerank 模型重新打分最终只把分数最高的片段送给大模型。这个步骤能明显减少“检索到无关内容但模型还硬答”的情况。5.3 在 Agent 中启用知识库检索在 Agent 应用里知识库同样以“工具”的形式存在。创建好知识库并完成索引后回到 Agent 应用在工具区把该知识库添加到检索工具中。根据具体版本Dify 可能会把“知识检索”作为一个独立工具展示。你要做的是在 Agent 提示词里告诉模型何时使用它。当用户询问产品资料、价格政策、售后条款、操作指南时先使用知识库检索再根据检索结果回答。测试时输入一个来自文档的问题比如你们的退款周期是多少天然后检查回答是否来自文档内容以及引用来源是否指向正确片段。注意知识库不是模型的记忆。模型在没有资料或资料不足时仍然可能编造答案。一定要在提示词中要求“没有依据就明确说未找到”而不是让模型自由发挥。6. 常见问题排查从现象到根因本地智能体跑起来之后最常见的不是功能不会写而是链路中某个环节悄悄断开。下面按现象给出排查路径。6.1 模型连接失败或超时现象Dify 保存 Ollama 模型时提示连接失败或对话请求迟迟不返回。现象很可能原因检查方式处理建议提示 connection failedDify 容器访问不到 Ollama在 Dify 容器内curl http://宿主机IP:11434把 Endpoint 改为host.docker.internal或宿主机 IP请求超时模型过大或设备太慢查看系统 GPU/CPU 占用换更小量化模型或调大请求超时时间返回 400模型名不存在或请求格式不对查看 Ollama 日志用ollama list确认模型 tag返回乱码或截断上下文长度设置过小检查 Context Size 设置调大模型上下文或减少知识库片段数量Ollama 日志通常在启动服务的终端里。如果日志中有明显异常优先根据日志内容搜索而不要盲目改 Dify 配置。6.2 智能体不调用工具只会直接回答这是智能体项目最常见的失败模式。原因通常不是 Dify 坏了而是模型没有把问题映射到工具上。可能原因工具没有在 Agent 应用里启用。工具描述太模糊模型不知道什么时候该调用它。模型本身不支持工具调用。Temperature 太高模型随机选择了“直接回答”的路径。用户问题里的说法和工具描述不一致。排查顺序在 Dify 工具页面手动测试工具确认接口可用。检查 Agent 应用是否勾选了该工具。把工具 summary 改成更明确的业务表达例如“当用户给出邮箱并询问订单状态时调用”。降低 Temperature 到 0.2。查看 Dify 日志看模型是否生成了工具调用指令但被框架拦截。工具描述示例订单查询工具根据客户邮箱查询订单状态、金额和发货状态。用户询问“订单”“下单记录”“物流信息”时优先调用。工具描述越贴近用户真实说法模型越容易触发调用。6.3 知识库检索质量差现象模型回答内容与文档无关或引用了错误片段。先查分段和 Embedding。常见的改进路径将分段长度从 500 降到 200 到 300观察回答是否变准确。开启 Rerank让二次排序过滤掉无关片段。调整top_k把传给模型的片段数控制在 3 到 5 个减少噪声。检查问题里是否有专业术语和文档措辞不一致必要时在知识库中补充同义词描述。小技巧先在 Dify 知识库的“召回测试”里输入用户问题查看返回片段的相似度和具体内容。如果召回的是无关片段说明问题出在 Embedding 或分段策略而不是大模型。6.4 接口报错 400 或 429调自定义工具时如果 Dify 返回 400优先检查 OpenAPI Schema 是否合法尤其注意operationId不能重复、required字段是否写对。如果返回 429通常是被限流。对本地 Ollama 来说429 较少见更多是请求排队超时。可以降低并发或在 Dify 侧调大超时时间。6.5 排查链路一览智能体出问题时按这条链路从前到后查不要直接从中间开始改Dify 应用能不能正常发送普通消息不能检查模型供应商和模型参数。工具有没有被调用没有检查工具启用状态、描述和模型是否支持工具调用。工具调用结果是否正确不正确先用 curl 直接测工具接口。模型有没有正确使用工具结果没有检查系统提示词和 Temperature。如果涉及知识库是否召回到正确片段没有检查分段、Embedding 和 Rerank。这条链路基本覆盖了智能体项目的三个核心故障层模型层、工具层、检索层。7. 生产化建议从本地 Demo 到可用服务本地 Agent 能跑通只代表验证完成距离稳定服务还有一段距离。下面几点是在生产环境里最容易忽略的部分。7.1 模型服务化与并发控制Ollama 适合本地开发和低并发场景但生产环境如果直接让多个用户同时请求容易产生排队和超时。更常见的方法是使用支持 OpenAI 兼容接口的推理服务部署开源模型再把 Dify 的模型供应商指向该服务。同样一个模型在生产环境中通常还会选择更合适的量化等级甚至针对业务数据做少量微调。是否微调取决于工具调用的失败率和业务术语的覆盖情况不要为了“用上微调”而强行微调。7.2 工具安全与权限自定义工具是对外暴露的 HTTP 接口必须当成正式接口来保护。对工具接口增加鉴权不能让任何人直接调用。校验用户传入参数比如邮箱格式、订单号长度。在 Dify 侧记录工具的入参和出参方便审计。不要把内部数据库连接串直接写进工具服务。对调用频率做限制避免单个用户刷爆模型和接口资源。一个原则是智能体最终能调到什么接口决定了它的权限边界。上线前要认真盘点工具清单不要图省事把所有接口一次性接入。7.3 日志、监控与回滚生产环境需要做到可观测。至少记录以下几类信息用户问题以及最终回答。模型是否调用工具调用的是哪个工具。工具入参、出参和耗时。知识库检索到的片段和相似度。报错时的异常堆栈和请求 ID。Dify 本身有应用日志但生产环境建议把关键数据同步到统一的日志平台方便关联排障。Dify 版本升级也一样先在预发布环境验证再切生产。数据卷要定期备份避免升级失败后无法回滚。7.4 落地前检查清单上线一个开源模型智能体前可以按这份清单逐项确认[ ] 模型、Embedding、Rerank 是否选型完毕并用真实业务问题做过评测。[ ] 工具接口是否做了鉴权、参数校验和限流。[ ] 模型上下文长度和知识库片段数量是否匹配。[ ] 系统提示词中是否明确“没有依据不要编造”。[ ] 日志是否包含用户问题、工具入参出参、模型回答和错误信息。[ ] 是否有 Dify 数据备份和版本回滚方案。[ ] 敏感数据是否在日志和数据库中脱敏。从 GTC 上讨论的热点回到实际工程最值得做的事不是继续加新功能而是把“工具调用链路是否稳定”这件事验证清楚。对大多数内部知识问答和单据查询场景开源模型加智能体编排平台已经足够用。后续再往前一步就是把这个最小闭环放到真实业务里用日志和用户反馈持续打磨。
柏林 GTC 上智能体与开源模型是现场讨论密度最高的两个方向。智能体不是新发明出来的聊天框而是让模型在对话之外获得工具、记忆和规划能力开源模型则让这种能力不再被单一厂商绑定。热点归热点实际做项目时还是要回答一个具体问题在本机或内部环境里怎样用开源模型把一个能查订单、读文档的智能体跑起来。下面围绕一条可复现的链路展开用 Ollama 部署开源模型用 Dify 社区版编排智能体再用自定义工具和知识库补齐业务能力。全文不会停留在概念层而是会把部署命令、模型参数、工具接口、验证方式和排查路径都拆开讲。无论你是第一次搭智能体还是已经在用闭源 API、想切到开源模型都能按这个流程得到一个最小可用版本。需要先说明的是下面涉及的具体版本和界面名称在 Dify 与 Ollama 快速迭代时可能会有变化。落地时以你实际安装的版本为准但结构、原理和排查思路基本一致。1. 先看清智能体与开源模型在工程里的分工在动手之前先花几分钟理解三个关键词智能体、开源模型、智能体编排平台。很多人失败不是不会写提示词而是没搞清楚这几层各自负责什么。1.1 智能体是什么从对话模型到会调用工具的决策体如果把大模型比作一个刚入职的新员工他能读懂问题、给出流畅回答但没有电话、没有系统账号、没有公司资料库很多事情做不了。智能体就是给他配上电话、系统权限和资料库让他遇到任务时自己决定先查什么、调什么再回答什么。技术定义上智能体是大模型与外部能力组合而成的闭环系统。这个闭环通常包含四个部分规划、工具调用、记忆、结果验证。模型收到用户请求后先判断需要哪些信息再决定是否调用某个工具拿到工具结果后结合历史对话和业务约束生成最终回答。如果需要多步操作它可能还会根据第一次结果继续调第二个工具。在实际产品里最常见的区分是“对话应用”和“智能体应用”。应用类型是否自主选择工具典型场景依赖对话型 Chat否普通问答、内容生成模型 知识库智能体型 Agent是查订单、多步操作、跨系统处理模型 工具 流程编排这里容易误解的地方是智能体并不是某一个模型而是一种“模型 工具 编排”的组合。另一个容易踩的坑是不是所有模型都适合做智能体底座。工具调用依赖模型理解函数描述、按 JSON 格式填充参数这需要模型在训练阶段专门强化过。直接用不支持工具调用的模型硬接结果往往是它不调用工具只根据训练记忆编答案。1.2 开源模型为什么适合做智能体底座看 GTC 上的讨论会发现很多团队关注开源模型不是因为它“免费”而是因为它解决了两个实际问题数据主权和定制空间。对比维度闭源 API 模型本地开源模型数据去向对话内容发送到第三方平台可完全内网部署敏感数据不出域调用成本按 token 持续计费主要是一次性硬件成本和电费可定制性只能调参数可以量化、微调、换基座部署门槛低申请 Key 即可需要 GPU 或较高内存工具调用稳定性通常较高取决于模型和提示词需要调开源模型近年来的进步主要体现在指令遵循、长上下文和工具调用能力上。以 Qwen 系列为代表的中文开源模型已经能在不少业务场景里承担工具调用任务。但这不意味着开源模型没有成本它把成本从“token 费用”转移到了“硬件、部署、调优和运维”上。落地项目之前建议先做一次小范围评测准备 20 到 50 个真实业务问题给模型配置好工具看它有多少比例能正确决定调用、正确填充参数、正确使用返回结果。这个测试结果比任何榜单都更有参考价值。1.3 选型组合Ollama Dify 开源模型的适用边界下面要用到的技术组合是Ollama Dify 社区版 开源模型。Ollama 负责把模型跑起来解决“模型怎么运行”的问题。Dify 负责应用编排、工具接入、知识库、对话管理解决“智能体怎么组合”的问题。开源模型负责理解和决策解决“大脑”的问题。这套组合适合学习验证、企业内网知识库、内部单据查询、私有数据问答等场景。不适合的场景也很明显面向海量用户的公开服务、对响应时间要求极高、或需要复杂多智能体协作的生产系统需要另外做模型推理加速和分布式编排。注意这只是一个工程参考组合。生产环境可以把 Ollama 换成 vLLM 或类似推理服务Dify 也可以替换为其他编排平台但“模型、工具、编排”这三层的基本边界不会变。2. 环境准备本地先把开源模型和 Dify 跑起来很多教程直接讲 Agent 配置却忽略了运行环境。实际上环境问题占智能体项目起步阶段的大半工作量。先花二十分钟把底座跑通后面才有信号。2.1 硬件与系统要求如果你想从零开始跑通一个带知识库和工具的智能体不需要一开始就上大机器。一个中等配置的开发机足够做验证。组件最低建议更流畅的配置说明Ollama 7B/8B 量化模型8 核 CPU 16 GB 内存6 GB 以上显存的 GPU7B 量化模型能跑 CPU但生成速度有限13B 以上模型不建议纯 CPU 跑12 GB 以上显存大模型需要更高显存或更强量化Dify 社区版4 核 8 GB随并发升高增加主要是 Docker 容器占用资源磁盘20 GB50 GB 以上包含模型文件和 Docker 镜像先说明一个实际教训如果只打算做工具调用验证7B/8B 量级模型足够如果涉及大量文档理解优先保证 Embedding 和 Rerank 模型的部分而不是一味追求超大底座模型。2.2 安装 Ollama 并下载模型Ollama 的安装很直接。Linux 和 macOS 可以使用官方安装脚本Windows 直接下载安装包。启动服务后模型下载和运行都通过命令行完成。# 启动 Ollama 服务 ollama serve另一个终端里下载模型。这里以支持工具调用的 Qwen2.5 7B 量化版为例# 拉取模型tag 以 Ollama 仓库实际提供的为准 ollama pull qwen2.5:7b-instruct-q4_K_M下载完成后确认模型是否就绪# 查看本机已有模型 ollama list再用最简单的方式验证模型能不能正常对话curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct-q4_K_M, messages: [{role: user, content: 你好}] }如果返回正常的补全内容说明模型服务已经可用。这一步要确认的不只是“能启动”还包括模型 tag 是否写对、端口是否被占用、响应速度是否可接受。注意模型 tag 会随仓库更新变化。如果ollama pull拉不下来先打开 Ollama 官网确认当前可用的 tag不要凭记忆硬写。2.3 启动 Dify 社区版Dify 社区版推荐用 Docker Compose 启动。步骤一般如下git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d如果是学习环境可以直接用默认配置。如果是团队协作或后续要长期使用建议先git tag查看稳定的 release 版本并切换到固定版本避免直接用 master 导致下次启动时行为变化。启动完成后确认核心容器全部正常运行docker compose ps正常情况下web、api、worker、db、redis、sandbox 和向量数据库等容器都会处于运行状态。浏览器访问http://localhost或.env中配置的端口完成管理员账号初始化后就进入 Dify 的控制台。2.4 环境检查清单在进入配置前先按这份清单确认一次[ ]ollama list能看到已下载模型。[ ] 访问http://localhost:11434有接口响应文字。[ ] Dify 页面可以打开并创建管理员账号。[ ]docker compose ps没有出现容器反复重启。[ ] 如果内存紧张先关闭不需要的容器再继续。Dify 默认 Compose 文件会启动多个组件首次启动会拉取不少镜像磁盘小的地方需要留意。3. 在 Dify 中接入开源模型并创建 Agent 应用环境就绪后开始把模型接到 Dify 里并创建一个真正能调用工具的 Agent 应用。3.1 添加 Ollama 模型供应商在 Dify 控制台进入“设置 - 模型供应商”找到 Ollama点击添加模型。关键配置项如下。配置项示例值说明Model TypeLLM表示这是对话/工具调用模型API Endpointhttp://host.docker.internal:11434Dify 容器要能访问到 Ollama 服务Model Nameqwen2.5:7b-instruct-q4_K_M必须和ollama list里的 tag 一致Context Size4096 或 8192根据模型和硬件调整这里最容易错的是地址。如果 Dify 用 Docker 启动在容器内部访问宿主机时不能用localhost因为每个容器有独立的网络栈。Windows 和 macOS 上可以用host.docker.internalLinux 上推荐使用宿主机局域网 IP或直接把 Dify 容器配置成 host 网络模式。否则会一直报“连接失败”。3.2 创建 Agent 应用角色与工具设计进入 Dify 控制台创建空白应用时选择“Agent”类型而不是普通“Chat”类型。两者的区别在于Agent 类型会允许模型尝试调用已启用的工具普通 Chat 则只会做纯对话。先把角色提示词写好。提示词不必太长但要把“何时调用工具、何时不调用工具”说清楚。你是一个企业销售助手。你的任务是帮助用户查询订单、报价和产品资料。 规则 1. 当用户询问订单状态或订单信息时必须先调用订单查询工具不要根据记忆编造数据。 2. 当用户询问产品手册、价格政策、售后条款时先检索知识库再结合资料回答。 3. 工具返回结果后用简洁、专业的中文回答用户不要输出多余 JSON。 4. 如果工具或知识库中没有足够信息明确告诉用户当前无法确认。这段提示词的核心是“先查再答”。它并不能保证模型一定照做但能显著提高工具调用的触发概率。更长的提示词不一定是好事规则过多会让模型在真实对话中凌乱。3.3 配置模型参数模型参数直接影响工具调用的稳定性。常用的参数定义如下。参数推荐值作用Temperature0.2 ~ 0.4降低随机性减少模型自由发挥Top P0.7 ~ 0.9控制采样范围配合 Temperature 使用Max Tokens512 ~ 1024限制回答长度避免等待时间过长Function Calling开启让模型可以输出工具调用指令如果在配置页面看到“工具调用”相关的开关建议打开。用 Qwen2.5 这类经过工具调用训练的模型时工具调用成功率会明显高于普通对话模型。小技巧在调试阶段不要一次性把所有能力都打开。可以先只接一个订单查询工具用一条固定问题测试成功后再加知识库和其他工具。智能体项目的复杂度是逐步堆出来的一次加太多能力会很难定位问题。4. 用自定义工具补齐业务能力订单查询示例模型无法直接访问数据库这是智能体必须接工具的根本原因。下面用一个订单查询接口演示完整链路。4.1 为什么 Agent 一定要接工具模型的知识截止到训练时间它无法知道实时订单状态、当前库存或某个用户的私有数据。工具的作用就是给模型一个“可调用的外部接口”。在 Dify 中一个工具通常被描述成“模型能读懂的接口说明”接口路径、入参、出参、用途。模型收到用户问题后判断该问题匹配哪个工具然后按照工具的 JSON Schema 生成参数。Dify 框架负责真正发起 HTTP 请求并把结果返回给模型。因此工具描述写得好不好直接影响模型“想不想调”以及“能不能调”。4.2 用 FastAPI 实现订单查询工具这里用一个最小的 FastAPI 服务演示数据暂时放在内存里。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() FAKE_ORDERS { demoexample.com: [ {order_id: SO-1001, status: 已发货, amount: 299.00}, {order_id: SO-1002, status: 待付款, amount: 59.00}, ] } class QueryRequest(BaseModel): customer_email: str app.post(/api/query_order) def query_order(req: QueryRequest): orders FAKE_ORDERS.get(req.customer_email.strip().lower()) if not orders: raise HTTPException(status_code404, detailorder not found) return {customer_email: req.customer_email, orders: orders}启动服务pip install fastapi uvicorn uvicorn main:app --host 0.0.0.0 --port 8000先用 curl 直接验证接口本身是否正常curl -X POST http://localhost:8000/api/query_order \ -H Content-Type: application/json \ -d {customer_email: demoexample.com}预期返回{ customer_email: demoexample.com, orders: [ {order_id: SO-1001, status: 已发货, amount: 299.0}, {order_id: SO-1002, status: 待付款, amount: 59.0} ] }如果接口本身返回错误请先修接口再继续配置智能体。很多工具调用失败根因不在 Dify而在后端接口自身逻辑或网络不通。4.3 在 Dify 中配置 OpenAPI 工具Dify 支持通过 OpenAPI 规范导入自定义工具。在“工具”页面创建自定义工具选择导入 OpenAPI Schema。下面是一份最小可用的 Schema。{ openapi: 3.0.0, info: { title: Order Query API, version: 1.0.0 }, servers: [ { url: http://host.docker.internal:8000 } ], paths: { /api/query_order: { post: { operationId: queryOrder, summary: 根据客户邮箱查询订单列表, requestBody: { required: true, content: { application/json: { schema: { type: object, properties: { customer_email: { type: string, description: 客户邮箱 } }, required: [customer_email] } } } }, responses: { 200: { description: 订单查询成功 } } } } } }导入后在 Agent 应用的工具区启用这个工具。此时模型是否能正确调用取决于几个方面的配合operationId要唯一并且尽量简洁比如queryOrder。summary要写清楚用途模型根据它判断何时调用。参数描述要准确模型从用户话术里提取参数值。servers.url必须能被 Dify 后端访问到不能用localhost。导入完成后建议先在 Dify 工具页面点一次“测试”输入参数并确认返回结果。这一步通过后再回到 Agent 应用测试。4.4 验证工具调用链路在 Dify Agent 的调试对话框中输入查询 demoexample.com 的订单观察正常路径模型先输出工具调用指令Dify 调用/api/query_order拿到 JSON 结果模型再把结果组织成自然语言回答。如果模型没有调用工具而是自己编了一段订单信息说明工具配置或提示词有问题。还可以在 Dify 的日志或运行追踪里查看工具输入和输出用户问题: 查询 demoexample.com 的订单 工具调用: queryOrder 工具入参: {customer_email: demoexample.com} 工具出参: {orders: [...]} 模型回答: demoexample.com 的订单有两笔其中 SO-1001 已发货SO-1002 待付款。这个链路是智能体能否落地的核心指标。只要工具调用链路稳定后续接多少工具只是按相同模式扩展的问题。5. 知识库增强让智能体读懂企业内部文档工具让智能体能调系统知识库让智能体能读资料。两者结合才像一个真正能处理业务的助手。5.1 文档数据接入与分块在 Dify 中创建知识库上传 Markdown、PDF 或 TXT 文档然后设置分段参数。分块决定检索单元的大小直接影响回答质量。参数推荐值说明分段长度Token200 ~ 500太短检索碎片化太长信息密度低分段重叠10 ~ 50弥补切分边界断句问题索引方式高质量生产环境建议开启效果更好但更耗资源不同文档类型适合不同分段策略。FAQ 适合短片段产品手册适合中等长度片段长合同则要考虑按章节切分。Dify 的可视化分段可以让你看到切分结果这一步不要跳过切得太碎会导致检索结果语义不完整。5.2 Embedding 模型与 Rerank 模型选择知识库检索依赖向量化。文档被切成片段后需要转为向量用户问题也需要转为向量才能做相似度检索。这个转换由 Embedding 模型完成。在 Dify 中可以在模型供应商里同时配置 Ollama 的 Embedding 模型。一个常见的开源组合如下。用途模型说明Embeddingbge-m3中文效果较好支持多语言和多粒度文本Rerankbge-reranker-v2-m3对检索结果二次排序提升精度Agent 底座模型qwen2.5:7b-instruct-q4_K_M负责对话与工具调用先说明这不是“唯一最强”组合而是相对常见、社区资料多的组合。实际选型时拿着自己的业务文档做小批量评测比盲目追求榜单效果更有价值。加入 Rerank 后Dify 会先召回一批候选片段再用 Rerank 模型重新打分最终只把分数最高的片段送给大模型。这个步骤能明显减少“检索到无关内容但模型还硬答”的情况。5.3 在 Agent 中启用知识库检索在 Agent 应用里知识库同样以“工具”的形式存在。创建好知识库并完成索引后回到 Agent 应用在工具区把该知识库添加到检索工具中。根据具体版本Dify 可能会把“知识检索”作为一个独立工具展示。你要做的是在 Agent 提示词里告诉模型何时使用它。当用户询问产品资料、价格政策、售后条款、操作指南时先使用知识库检索再根据检索结果回答。测试时输入一个来自文档的问题比如你们的退款周期是多少天然后检查回答是否来自文档内容以及引用来源是否指向正确片段。注意知识库不是模型的记忆。模型在没有资料或资料不足时仍然可能编造答案。一定要在提示词中要求“没有依据就明确说未找到”而不是让模型自由发挥。6. 常见问题排查从现象到根因本地智能体跑起来之后最常见的不是功能不会写而是链路中某个环节悄悄断开。下面按现象给出排查路径。6.1 模型连接失败或超时现象Dify 保存 Ollama 模型时提示连接失败或对话请求迟迟不返回。现象很可能原因检查方式处理建议提示 connection failedDify 容器访问不到 Ollama在 Dify 容器内curl http://宿主机IP:11434把 Endpoint 改为host.docker.internal或宿主机 IP请求超时模型过大或设备太慢查看系统 GPU/CPU 占用换更小量化模型或调大请求超时时间返回 400模型名不存在或请求格式不对查看 Ollama 日志用ollama list确认模型 tag返回乱码或截断上下文长度设置过小检查 Context Size 设置调大模型上下文或减少知识库片段数量Ollama 日志通常在启动服务的终端里。如果日志中有明显异常优先根据日志内容搜索而不要盲目改 Dify 配置。6.2 智能体不调用工具只会直接回答这是智能体项目最常见的失败模式。原因通常不是 Dify 坏了而是模型没有把问题映射到工具上。可能原因工具没有在 Agent 应用里启用。工具描述太模糊模型不知道什么时候该调用它。模型本身不支持工具调用。Temperature 太高模型随机选择了“直接回答”的路径。用户问题里的说法和工具描述不一致。排查顺序在 Dify 工具页面手动测试工具确认接口可用。检查 Agent 应用是否勾选了该工具。把工具 summary 改成更明确的业务表达例如“当用户给出邮箱并询问订单状态时调用”。降低 Temperature 到 0.2。查看 Dify 日志看模型是否生成了工具调用指令但被框架拦截。工具描述示例订单查询工具根据客户邮箱查询订单状态、金额和发货状态。用户询问“订单”“下单记录”“物流信息”时优先调用。工具描述越贴近用户真实说法模型越容易触发调用。6.3 知识库检索质量差现象模型回答内容与文档无关或引用了错误片段。先查分段和 Embedding。常见的改进路径将分段长度从 500 降到 200 到 300观察回答是否变准确。开启 Rerank让二次排序过滤掉无关片段。调整top_k把传给模型的片段数控制在 3 到 5 个减少噪声。检查问题里是否有专业术语和文档措辞不一致必要时在知识库中补充同义词描述。小技巧先在 Dify 知识库的“召回测试”里输入用户问题查看返回片段的相似度和具体内容。如果召回的是无关片段说明问题出在 Embedding 或分段策略而不是大模型。6.4 接口报错 400 或 429调自定义工具时如果 Dify 返回 400优先检查 OpenAPI Schema 是否合法尤其注意operationId不能重复、required字段是否写对。如果返回 429通常是被限流。对本地 Ollama 来说429 较少见更多是请求排队超时。可以降低并发或在 Dify 侧调大超时时间。6.5 排查链路一览智能体出问题时按这条链路从前到后查不要直接从中间开始改Dify 应用能不能正常发送普通消息不能检查模型供应商和模型参数。工具有没有被调用没有检查工具启用状态、描述和模型是否支持工具调用。工具调用结果是否正确不正确先用 curl 直接测工具接口。模型有没有正确使用工具结果没有检查系统提示词和 Temperature。如果涉及知识库是否召回到正确片段没有检查分段、Embedding 和 Rerank。这条链路基本覆盖了智能体项目的三个核心故障层模型层、工具层、检索层。7. 生产化建议从本地 Demo 到可用服务本地 Agent 能跑通只代表验证完成距离稳定服务还有一段距离。下面几点是在生产环境里最容易忽略的部分。7.1 模型服务化与并发控制Ollama 适合本地开发和低并发场景但生产环境如果直接让多个用户同时请求容易产生排队和超时。更常见的方法是使用支持 OpenAI 兼容接口的推理服务部署开源模型再把 Dify 的模型供应商指向该服务。同样一个模型在生产环境中通常还会选择更合适的量化等级甚至针对业务数据做少量微调。是否微调取决于工具调用的失败率和业务术语的覆盖情况不要为了“用上微调”而强行微调。7.2 工具安全与权限自定义工具是对外暴露的 HTTP 接口必须当成正式接口来保护。对工具接口增加鉴权不能让任何人直接调用。校验用户传入参数比如邮箱格式、订单号长度。在 Dify 侧记录工具的入参和出参方便审计。不要把内部数据库连接串直接写进工具服务。对调用频率做限制避免单个用户刷爆模型和接口资源。一个原则是智能体最终能调到什么接口决定了它的权限边界。上线前要认真盘点工具清单不要图省事把所有接口一次性接入。7.3 日志、监控与回滚生产环境需要做到可观测。至少记录以下几类信息用户问题以及最终回答。模型是否调用工具调用的是哪个工具。工具入参、出参和耗时。知识库检索到的片段和相似度。报错时的异常堆栈和请求 ID。Dify 本身有应用日志但生产环境建议把关键数据同步到统一的日志平台方便关联排障。Dify 版本升级也一样先在预发布环境验证再切生产。数据卷要定期备份避免升级失败后无法回滚。7.4 落地前检查清单上线一个开源模型智能体前可以按这份清单逐项确认[ ] 模型、Embedding、Rerank 是否选型完毕并用真实业务问题做过评测。[ ] 工具接口是否做了鉴权、参数校验和限流。[ ] 模型上下文长度和知识库片段数量是否匹配。[ ] 系统提示词中是否明确“没有依据不要编造”。[ ] 日志是否包含用户问题、工具入参出参、模型回答和错误信息。[ ] 是否有 Dify 数据备份和版本回滚方案。[ ] 敏感数据是否在日志和数据库中脱敏。从 GTC 上讨论的热点回到实际工程最值得做的事不是继续加新功能而是把“工具调用链路是否稳定”这件事验证清楚。对大多数内部知识问答和单据查询场景开源模型加智能体编排平台已经足够用。后续再往前一步就是把这个最小闭环放到真实业务里用日志和用户反馈持续打磨。
