还有不到一个月，柏林GTC就要开幕了。按惯例，我这种每天跟大模型和Agent打交道的开发者，会把关注的议题分成两类：一类是GPU和基础设施，另一类是模型、框架和应用。今年的情况有些特别——身边同事聊得最凶的，不再是某张卡有多少TFlops，而是两个词：智能体（Agent）和开源模型。
这个变化不是偶然。过去两年大家默认一个判断：闭源模型能力最强，想做出好产品就直接调API。但到了2025年，越来越多团队发现，真正难的不是让模型“会说话”，而是让模型能在一个真实业务系统里“干活”。而一旦要干活，开源自部署模型、可改代码的Agent框架，一下子就从小众玩具变成了生产环境里的必选项。
这篇文章不打算复述GTC的参会指南，也不是新闻稿，而是想聊清楚一件事：为什么“智能体+开源模型”会成为当前AI工程化的主线？以及如果你现在就想亲手跑通一个最小智能体，应该怎么做。读完你会得到一套能直接上手的环境搭建路径、示例代码和排错清单。
1. 智能体为什么把开源模型推上了主场
过去一年，模型层的竞争主线是参数和评测分数。但在真正的业务场景里，模型只是智能体的大脑，而智能体要稳定工作，依赖的是可控性、可观测性和可定制性。这三个词恰好在开源模型上有明显优势。
先说可控性。闭源API无论多强，你都无法查看它在工具调用中的完整决策逻辑。一旦Agent出现“该调用工具时不调，不该调时瞎调”的问题，你只能改Prompt碰运气。开源模型则是本地文件，你可以直接改采样参数、换解码策略，甚至用工具调用的日志反推是哪一层出错。
再说可观测性。Agent系统的失败点非常多：意图识别错、检索结果不相关、工具返回解析失败、上下文被截断。闭源API只能看到一份日志，而自部署的开源模型可以完整打印从输入到输出的每个阶段，这对排错是实质性帮助。
最后是可定制性。真实业务里的工具调用格式五花八门：企业内部API、数据库查询、审批流、低代码平台。开源模型社区通常能更快适配新工具协议，配合微调、LoRA、Q-LoRA等手段，你甚至可以把模型训练成某个垂直领域的“专用Agent大脑”。
当然，闭源模型在综合能力和稳定性上仍然领先。但智能体场景对“正确执行工具调用”的要求，比“生成一段漂亮文案”更高，而开源模型在这条赛道上的进步速度肉眼可见。许多开发者选择开源模型，不是情怀，而是工程上的理性选择。
2. 基础概念：智能体、开源模型和框架的关系
为了避免后面的实操看得一头雾水，这里先把几个核心概念讲清楚。
智能体（Agent）在工程上的定义，可以理解成一个循环：接收任务 → 大模型规划 → 调用工具获取信息 → 根据结果继续决策 → 直到完成任务。它区别于普通聊天机器人的地方在于，它拥有“行动能力”，可以通过工具影响到外部系统。
开源模型，指的是权重公开、允许自由下载和部署的模型，例如 Llama、Qwen、DeepSeek 系列。它们的价值不仅是省API费用，更重要的是可以放在自己的服务器上，数据不出门，推理过程完全透明。
智能体框架，是帮你把“模型 + 工具 + 记忆 + 工作流”串起来的脚手架。常见的有三种形态：
- 代码框架：如 LangChain、LlamaIndex，适合程序员自己编排复杂逻辑。
- 可视化平台：如 Dify、Coze，适合快速搭建企业级应用，Dify 可以本地部署，Coze 主要托管在云端。
- 轻量Agent工具：如 AutoGPT、Claude Code 这类面向特定任务的编程助手。
很多人在概念上容易混淆另外两个东西：工作流（Workflow）和 RAG。
工作流是提前画好的固定路线，用户触发一个节点，流程就按顺序走，中间不改变流向。Agent 则不同，它会在每一步根据当前状态决定“下一步调用哪个工具”。所以如果你的业务逻辑是确定性的，优先用工作流；只有当决策路径足够复杂且动态变化时，才值得引入 Agent。
RAG（检索增强生成）是给模型外挂知识库，先检索相关文档，再让模型基于检索结果生成答案。它可以看作是 Agent 的一种“记忆模块”，但 Agent 的能力边界更宽，它还可以调用搜索、写数据库、发消息等工具。
简单做一张对比表：
| 概念 | 核心特点 | 典型使用场景 |
|---|---|---|
| 工作流 | 固定步骤，人工编排 | 客服咨询流程、定时任务 |
| Agent | 动态决策，自主调用工具 | 智能运维、数据分析助手 |
| RAG | 从外部知识库检索再回答 | 企业知识库问答 |
| 多Agent | 多个智能体分工协作 | 复杂项目拆解、多角色模拟 |
真实项目中，这些概念经常叠加。例如一个企业级智能体，内部先有一个工作流做意图识别，命中知识问题就走 RAG，命中操作类请求就走工具调用，如果路径太复杂，再由 Agent 动态决策。开源模型在这个叠加结构里，所处的层级是统一的“推理引擎”。
3. 环境准备与前置条件
在你本地或者一台 Linux 服务器上跑通智能体 demo，需要准备这样一套环境。
3.1 硬件与系统
如果只做功能验证，不用苛刻的显卡要求。Ollama 在 Mac M系列和 Linux/Windows 上都能跑，CPU 也能运行，只是速度较慢。建议至少 16GB 内存，如果有 NVIDIA 显卡（8GB 以上显存）体验会好很多。生产环境再考虑 A100/H100 甚至多卡推理，验证阶段完全不必。
3.2 软件依赖
- Docker 与 Docker Compose：用于部署 Dify 等平台。
- Python 3.10 以上：用于写调用代码。
- Ollama 或 vLLM：用于本地启动开源模型。vLLM 适合高并发生产，Ollama 适合个人开发和验证。
- Git：拉取 Dify 项目代码。
3.3 模型选择
验证阶段推荐选参数量 7B~8B 级别的开源模型，例如 qwen2.5:7b 或 llama3.1:8b。它们既有不错的工具调用能力，又不会让普通电脑跑不动。如果显存有限，也可以选择 3B/4B 参数量的量化版本。
版本说明：各模型的版本号更新很快，本文以 qwen2.5:7b 为例演示，实际使用时建议以官方仓库最新版本为准。
4. 核心流程拆解：搭一个能查资料的智能体
下面要搭建的 demo 目标很具体：用户问一个问题，智能体先判断是否需要搜索内部知识库，如果需要就从已上传的文档中检索，最后基于检索结果生成回答。整个过程要在本地完成。
4.1 第一步：启动开源模型服务
模型是智能体的心脏。我们先用 Ollama 把开源模型跑起来，它启动后默认监听11434端口，并提供一个 OpenAI 兼容的接口。后面所有环节都可以通过这个接口访问模型，这样万一想把模型换成别的，改一个 URL 就行。
# 启动 Ollama 服务 ollama serve & # 拉取并运行一个 7B 模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b "你好，介绍一下你自己"这里真正容易踩坑的地方是ollama serve &。在部分 Linux 环境下，后台进程会因为终端退出而关闭，更稳妥的方式是使用nohup ollama serve > ollama.log 2>&1 &，或者直接用 systemd 管理。
4.2 第二步：部署 Dify 平台
Dify 是一个开源的LLM应用开发平台，能可视化编排 Agent、知识库、工作流。我们用 Docker Compose 部署它，这样不用手动配置数据库和 Redis。
git clone https://github.com/langgenious/dify.git cd dify/docker cp .env.example .env docker compose up -d注意：仓库地址以官方为准，如果 clone 速度慢，可以先下载 zip 包再解压。启动后访问http://localhost初始化管理员账号。
首次启动需要拉取较多镜像，时间取决于网络。如果中途失败，先执行docker compose pull重试，不要反复up -d。
4.3 第三步：在 Dify 中配置模型供应商
登录 Dify 后，进入“设置 → 模型供应商”，选择 OpenAI-API-compatible 类型，填写：
- API Base URL：
http://host.docker.internal:11434/v1 - API Key：任意非空字符串，比如
ollama - Models 列表：添加
qwen2.5:7b
这里有个关键点：Dify 本身跑在 Docker 容器里，容器内访问宿主机的 Ollama 服务，不能用localhost，要用host.docker.internal。如果你把 Dify 直接装在宿主机上，则可以填http://localhost:11434/v1。
4.4 第四步：创建聊天助手Agent应用
在 Dify 中新建“聊天助手”应用，选择已配置好的 qwen2.5:7b 模型。然后在“编排”页面打开 Agent 模式，并添加工具，例如“知识检索”。上传几篇技术文档到知识库，设置好分段长度和检索模式。
这一阶段不需要写代码，但编排逻辑是整个 demo 的核心。要明确告诉模型：先检索知识库，再基于检索结果回答；如果知识库没有答案，要明确说“不知道”，不能凭空编造。
4.5 第五步：测试并接入API
在 Dify 右上角可以打开调试对话框，直接输入问题测试。确认回答符合预期后，再到“访问 API”页面创建 API Key。后面所有客户端都通过这个 Key 访问智能体能力。
5. 完整示例与代码实现
这一节给出三个可以直接运行的示例。第一个示例负责验证本地模型，第二个示例演示如何用 Python 调用模型接口，第三个示例展示通过 Dify API 与智能体交互。
5.1 示例一：用命令行验证本地模型
模型服务启动后，先用最简单的命令验证，不要把问题直接抛到后面复杂的链路里。
ollama pull qwen2.5:7b curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "请用一句话解释什么是智能体"}], "max_tokens": 128 }'如果返回包含choices[0].message.content的 JSON，说明模型服务正常。注意这里的接口路径是/v1/chat/completions，这是 Ollama 兼容 OpenAI 协议的标准入口。
5.2 示例二：用 Python 调用开源模型
写代码时尽量使用 OpenAI SDK，因为本地模型的接口是兼容模式。这样以后切换到闭源API时，代码改动量很小。
# 文件路径：agent_demo/model_client.py from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", # 指向本地 Ollama 服务 api_key="ollama" # 本地服务不校验，填任意非空值 ) def chat_with_model(prompt: str) -> str: response = client.chat.completions.create( model="qwen2.5:7b", messages=[ { "role": "system", "content": "你是一个严谨的技术助手，回答要简洁，不确定时明确说不知道。" }, { "role": "user", "content": prompt } ], temperature=0.2, max_tokens=512 ) return response.choices[0].message.content if __name__ == "__main__": text = chat_with_model("Agent 中的 tool calling 和普通函数调用有什么区别？") print(text)运行前先安装依赖：
pip install openai python agent_demo/model_client.py这段代码展示了一个最小可用模式：确定性任务用低温度，创造性任务再调高温度。在 Agent 场景里，尽量把temperature控制在 0.2 以下，减少模型随机发挥导致工具调用失败的概率。
5.3 示例三：通过 Dify API 发布智能体服务
Dify 应用配置完成后，可以直接用 HTTP 接口将它变成可供业务系统调用的服务。假设你的 API Key 是app-xxxxx，请求方式如下：
curl --location --request POST 'http://localhost/api/chat-messages' \ --header 'Authorization: Bearer app-xxxxx' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "请查一下知识库里关于模型量化的说明，并提炼出三个要点", "response_mode": "blocking", "user": "csdn-demo" }'response_mode可以填blocking或streaming。开发调试阶段推荐用blocking，返回完整 JSON；生产环境为了用户体验，一般用streaming做流式输出。
下面是一个简单的 Python 调用封装：
# 文件路径：agent_demo/dify_client.py import requests DIFY_URL = "http://localhost/api/chat-messages" API_KEY = "app-xxxxx" def ask_agent(query: str, user_id: str = "csdn-demo") -> dict: headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "inputs": {}, "query": query, "response_mode": "blocking", "user": user_id } response = requests.post(DIFY_URL, headers=headers, json=payload, timeout=120) response.raise_for_status() return response.json() if __name__ == "__main__": result = ask_agent("什么是 Agent 的记忆模块？") print(result["answer"])这个示例是一个通用的接入范式。你可以把它嵌到飞书机器人、Web后端、命令行工具里，让任何入口都具备智能体能力。
6. 运行结果与效果验证
完成上面的示例后，需要从三个层面确认系统真的能工作。
6.1 验证模型层
执行示例二后，正常输出的是一段结构清晰的中文回答。判断标准不是内容“好不好”，而是进程没有报错，返回文本非空。如果模型回答出现“API 连接错误”，第一步先检查curl http://localhost:11434/api/tags是否能列出模型列表。
6.2 验证知识检索层
在 Dify 后台测试知识库问答时，可以打开“日志”面板，观察每次请求的检索链路。关键看两点：
- 是否检索到了相关文档片段；
- 模型是否引用了检索内容而不是自己编造。
如果检索结果为空，多半是文档分段不合理或者 Embedding 模型没有配置正确，需要回到知识库做分段调整。
6.3 验证 API 层
通过curl调用 Dify 接口，如果请求成功，返回的 JSON 会包含answer、conversation_id、message_id字段。其中conversation_id很重要，后续多轮对话需要把它原样传回，否则智能体会丢失上下文。
{ "answer": "知识库中提到，模型量化是将参数从高精度转换为低精度的过程...", "conversation_id": "abc123...", "message_id": "msg-001" }只要answer非空且HTTP 状态码为 200，就说明整条链路已经打通：客户端 → Dify → 本地开源模型 → 知识库检索 → 回复。
7. 常见问题与排查思路
我在不同项目里见过很多类似的问题，这里列出一份高频问题清单：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 连接 Ollama 失败 | Ollama 服务没启动或端口被占用 | curl http://localhost:11434/api/tags | 启动ollama serve，查看端口占用 |
| 容器内访问不到宿主机模型 | 使用了localhost而不是host.docker.internal | 在容器内curl host.docker.internal:11434 | 改用host.docker.internal并开放防火墙 |
| 模型回答质量差 | 模型太小或 Prompt 表达不清 | 查看 Dify 日志中检索到的上下文 | 换更大模型，或优化 system prompt |
| Agent 不调用工具 | tool 描述太模糊，或模型不支持复杂 tool calling | 在编排页面测试单个工具 | 精简工具描述，使用 tool 字段明确参数格式 |
| Dify 镜像拉取慢 | 网络原因 | 查看 Docker 拉取日志 | 配置镜像加速，执行docker compose pull |
| 显存不够导致 OOM | 模型参数量过大 | 执行ollama ps查看显存占用 | 换小模型，或使用量化版，如qwen2.5:3b |
一个容易被忽略的问题是：本地 CPU 推理速度很慢，容易触发 API 超时。如果 Dify 或客户端设置的超时时间太短，模型还在生成时请求就被中断了。解决办法是把超时时间调大，或者减少max_tokens。
8. 最佳实践与工程建议
跑通 demo 只是第一步。如果要把它变成生产系统，下面这些建议值得参考。
8.1 模型选型不要只盯评测分数
评测分数高不等于在 Agent 场景里好用。优先选择社区反馈中“工具调用稳定”的模型，并且用你真实的工具 Schema 去做回归测试。建议准备一组固定的测试用例，每次换模型或升级版本后都跑一遍，防止模型更新带来隐形行为变化。
8.2 把模型层做成可替换的接口
上面的示例中，本地模型和 Dify 都兼容 OpenAI 协议。建议在项目里专门封装一层 model provider，不要直接在业务代码中写死某个模型的 URL。这样一旦生产环境需要切换到更大的闭源模型或者自建 vLLM 集群，只需要改配置，不用改业务逻辑。
8.3 工具调用要有权限边界
Agent 可以调用外部工具，这既是能力也是风险。生产环境要对每个工具做鉴权，不能给 Agent 一把万能钥匙。例如，让 Agent 连接数据库时，应该使用只读账号；调用企业 API 时，要限制 IP 和请求频率。还要设计人工审批节点，涉及高风险操作（删除数据、转账、发布内容）必须停下來等确认。
8.4 建立可观测性和评估体系
每个 Agent 请求都应该记录：用户问题、模型决策链路、调用过的工具、工具返回结果、最终回复、耗时和 token 消耗。这些日志不仅能帮你定位问题，也是未来优化 Prompt 和模型调优的数据基础。评估时不要只看单个回答好不好，要构建一个包含几十到上百条真实场景的评测集，每次改动都对比一次准确率。
8.5 能用工作流就不要强行用 Agent
Agent 很酷，但成本高、不稳定。如果你的业务场景只有固定的3个分支，用工作流十秒就能跑完，而且结果可预期。只有决策路径复杂、需要模型反复判断的情况，才值得引入 Agent。一个比较务实的方式是：外层先用工作流做粗粒度路由，路由到复杂场景后再触发 Agent 子流程。
8.6 开源模型与闭源 API 混合使用
开源模型和闭源 API 不是二选一。很多团队的做法是：简单请求走本地小模型，长尾复杂的请求走闭源大模型；或者用开源模型做前置筛选，把最高价值的请求提升给更贵的模型。这样既保住质量，又能控制成本。
9. 总结与后续学习方向
这次柏林 GTC 大概率会有大量关于智能体、开源模型和硬件协同的讨论。但真正能让你在现场不焦虑的，不是又多看了哪款新品，而是你自己已经跑通过一条最小链路：开源模型加载、本地知识库、工具调用、API 接入。
这套链路并不复杂，但它重新定义了 AI 应用开发的最小单位。过去你可能认为“大模型产品 = 一个 Prompt + 一个 API”，现在你更清楚：智能体是一个由模型、工具、记忆、控制流组成的系统工程。开源模型让这个系统有了透明、可控、可定制的大脑，而 GTC 这样的技术会议，只是帮我们更快看到行业下一步的演进方向。
如果你刚接触智能体，建议先照着本文跑通 demo，不要一开始就追求多 Agent 协作。先让一个 Agent 在一个业务场景里稳定工作，再考虑复杂编排。可以继续关注的方向包括：工具调用协议的标准化、长上下文管理、多 Agent 协同模式、以及基于开源模型的持续微调与评测体系。
在踏上前往柏林的航班之前，我会先把上面的最小 Demo 再跑一遍。技术会议的热度退得很快，真正能留下的，是自己亲手跑通的那套流程。
