这两年关于大模型的话题基本绕不开两个关键词一个是智能体Agent一个是开源模型。而 GTC 作为 NVIDIA 每年最重要的技术大会几乎成了观察 AI 行业趋势的风向标。最近作者准备前往柏林参加 GTC 相关活动结合会前关注的议题顺手把这两个方向的最新变化和落地路径做了一次系统梳理。这篇文章不打算写成新闻稿而是从一个开发者的视角聊聊智能体到底是什么、开源模型现在发展到什么程度、以及如果你想自己搭建一个智能体应用完整的流程、工具链和避坑点有哪些。无论你是刚开始接触智能体开发还是已经在用 Dify、Coze、AgentScope 这类平台做原型这篇文章都能给你一份可供参考的实战笔记。1. GTC 与智能体、开源模型的关系1.1 GTC 上为什么要聊智能体和开源模型GTC 全称是 GPU Technology Conference早期更多聚焦图形计算、高性能计算和 CUDA 生态。但过去两年AI 大模型成了绝对主角GTC 的议题也随之延伸到了模型训练、推理优化、智能体应用、开源模型生态等多个方向。为什么智能体和开源模型能在 GTC 上占据重要位置一个很现实的原因是大模型本身的边际收益正在下降大家开始关心怎么把模型用起来。而“用起来”最典型的形态就是智能体——让模型不只会聊天还能调用工具、操作软件、自动完成一个完整任务。另一个原因是开源模型极大降低了智能体的开发门槛。闭源 API 虽然方便但存在数据出域、成本不可控、本地化适配难等问题。开源模型则可以部署在本地或私有云配合向量数据库、工作流引擎快速搭建企业级智能体应用。GTC 这类大会恰恰是观察底层算力、模型推理框架和上层应用如何衔接的最佳窗口。1.2 智能体和开源模型的协同关系可以这样理解开源模型是智能体的“大脑”负责理解任务、拆解步骤、生成文案或代码。智能体框架是“骨架”负责把模型能力包装成可执行的 Workflow。工具链和知识库是“手脚”让智能体能够查数据库、调 API、搜索文档。这三者组合起来才是一个真正能落地的智能体应用。过去我们说“模型即产品”现在的趋势变成了“智能体即产品”。模型本身越来越像基础设施而智能体则是跑在基础设施上的应用程序。1.3 为什么现在聊智能体开发正当时开发生态里最近冒出了大量智能体方向和工具比如 Dify、Coze、AgentScope、AutoGen、LangGraph 等很多开发者也明显感觉到智能体开发的人才需求在快速增长。这背后有几个推动力大模型推理成本持续下降让多轮调用、多工具协作的智能体方案在经济上可行。模型能力质变尤其是开源模型在代码生成、工具调用、长文本理解方面的表现越来越接近闭源模型。低代码平台成熟让非算法工程师也能快速搭建智能体原型。所以现在是一个非常适合动手实践智能体开发的窗口期。2. 什么是智能体从概念到核心架构2.1 智能体的通俗理解智能体你可以先把它理解成“一个会用工具的 AI 助手”。普通聊天机器人只能根据用户输入生成文字回复。而智能体可以把用户的一句话任务拆成多个子任务自己决定调用哪个工具或 API根据工具返回结果继续调整下一步动作最终输出一个完整结果比如一份报告、一段代码、一个工单处理结果。举个例子用户说“帮我查一下本周所有未关闭的工单并按优先级列出处理方案。”传统机器人的回答可能是“抱歉我无法查询工单系统。”智能体的执行过程则是调用工单系统 API获取本周未关闭工单列表根据优先级字段对工单排序对高优先级工单调用知识库匹配处理方案汇总生成 Markdown 报告返回给用户。核心区别在于是否具备任务拆解和工具调用的能力。2.2 智能体的核心技术组件一个完整的智能体系统通常包含以下组件组件作用常见实现大语言模型负责理解意图、生成回复、决策GPT、DeepSeek、Qwen、GLM 等任务规划模块将复杂任务拆解为可执行的子任务ReAct、Plan-and-Execute、CoT工具调用模块让模型调用外部 API、函数、代码Function Calling / Tool Calling记忆模块保存对话历史、短期记忆和长期知识Redis、向量数据库知识库模块提供私有知识和外部文档检索Dify Knowledge、LangChain Retriever执行引擎编排整个工作流、处理异常Dify Workflow、LangGraph、AgentScope2.3 智能体的工作模式目前主流的智能体工作模式有三种模式一ReAct 模式推理 行动模型先分析当前状态决定要调用什么工具然后根据工具返回结果继续推理。思考 - 行动 - 观察 - 再思考 - 再行动 - 最终回答这种模式适合需要多步决策的场景但 Token 消耗较高响应时间相对长。模式二Plan-and-Execute 模式先规划再执行先把用户任务拆成一个计划列表再按计划执行。特点是一次性规划执行过程中较少动态调整。适合流程固定的任务比如“每天定时生成日报并发送邮件”。模式三Workflow 模式工作流模式用户或开发者提前定义好节点和流程模型只负责其中生成类的节点。Dify 和 Coze 上大量使用这种方式。优点是稳定可控缺点是不够灵活。2.4 智能体和 RAG 的关系现在很多项目里智能体和 RAG检索增强生成是分不开的。你要做一个企业知识库问答智能体基本流程就是把企业文档切片、向量化存入向量数据库用户提问时先从向量库检索相关内容将检索结果拼接到提示词中交给大模型生成答案。RAG 负责“找到对的资料”智能体负责“理解任务并组织执行流程”。两者结合是目前企业级智能体最常见的落地形式。3. 开源模型的现状与选型思路3.1 开源模型为什么迎来质变过去很多人对开源模型的印象是“能力比闭源模型差一截”。但最近一段时间以 DeepSeek、Qwen千问、GLM、Llama 系列为代表的开源模型在代码生成、数学推理、工具调用、Agent 任务执行上表现越来越亮眼。开源模型的意义不只是省 API 费用更关键的是可以本地部署数据不离开企业内网可以根据业务场景继续微调可以配合开源的推理框架做私有化交付社区反馈迭代速度快版本更新频繁。这也直接带动了智能体开发的开源化趋势更多人开始基于开源模型和开源框架搭建自己的智能体。3.2 开源模型如何选型开源模型选型不能只看跑分要结合你的具体场景。这里给出几点参考第一类通用对话 复杂任务拆解优先选择参数较大、指令遵循能力强的模型例如 DeepSeek 系列、Qwen2.5 系列。它们对中文支持好工具调用能力也比较成熟。第二类代码生成与开发助手如果你做的是代码类智能体比如自动写代码、解释代码、生成单元测试可以选择代码能力更强的模型或者配合 Code Llama、DeepSeek-Coder 这类专用模型。第三类轻量级 低成本部署如果部署资源有限可以考虑量化后的 7B 到 14B 模型配合 vLLM、Ollama 这类推理框架使用。虽然复杂推理能力有所下降但日常信息抽取、文档问答效果已经够用。第四类向量检索 重排智能体应用经常需要做知识库检索除了对话模型还需要两类模型向量模型用于把文本转为向量如 BGE 系列、M3E 等Rerank 模型用于对检索结果做精排提升答案准确率。建议在项目中同时引入 Embedding 模型和 Rerank 模型不要只用粗排结果直接喂给大模型。3.3 开源模型部署的常见方案本地部署开源模型的方案有很多选择哪个主要看你的技术栈和硬件条件。方案一Ollama Open WebUI适合个人开发者和快速验证场景。Ollama 安装简单命令行拉模型即可运行Open WebUI 提供可视化的网页交互界面。缺点是并发能力弱不适合生产环境。方案二vLLM 部署适合生产环境。vLLM 使用 PagedAttention 技术吞吐量高支持 OpenAI 兼容的 API 格式。常见用法是vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000启动后可以像调用 OpenAI API 一样调用本地模型。Dify、Coze 等平台都支持配置这种 OpenAI 兼容接口。方案三Docker Compose 一键部署适合需要集成知识库、工作流、模型管理的完整场景。比如 Dify 社区版一套 Docker Compose 文件就能启动包含模型管理、向量数据库、Agent 编排在内的整套服务。4. 智能体开发工具链全景在正式写代码之前先梳理一下现在主流的智能体开发工具。这样可以避免重复造轮子也能更快理解后面实战案例中每一步的作用。4.1 从底层到上层的完整工具链层次代表工具解决的问题模型层DeepSeek、Qwen、GLM、Llama提供推理能力推理层vLLM、Ollama、TGI部署和加速模型智能体框架Dify、Coze、AgentScope、AutoGen、LangGraph编排、规划、工具调用知识库层Dify Knowledge、LangChain Retriever、Milvus文档切片、向量化、检索应用层Open WebUI、ChatGPT-Next-Web、自建前端用户交互入口4.2 Dify适合快速搭建智能体应用的低代码平台Dify 是目前比较流行的开源 LLMOps 平台它把知识库、工作流、模型管理、Agent 编排都整合到了一起。Dify 的核心优势在于可视化编排 Agent 工作流内置知识库功能支持多种文档格式支持接入 OpenAI、DeepSeek、Qwen 等主流模型也支持本地 vLLM 接口支持发布 API方便集成到现有系统自带日志与标注功能方便调试。Dify 适合两类人非算法工程师想快速搭建知识库问答机器人后端工程师想省掉前端和基础设施搭建时间专注业务逻辑。4.3 Coze扣子适合快速验证和分享Coze 是字节跳动推出的智能体平台支持模型接入、插件、工作流、知识库界面友好非常适合快速做一个 Demo 然后分享链接。不过需要注意海外版和国内版的能力范围、模型配置有差别。另外作为云端平台数据安全边界需要结合企业规范评估。4.4 AgentScope适合算法团队做深入定制AgentScope 是阿里开源的多智能体框架灵活度高适合开发者通过 Python 代码精细控制智能体的行为。如果你需要对智能体内部做深度定制比如自定义记忆机制、自定义工具调度逻辑AgentScope 这类框架更合适。4.5 开发者的选择建议总结一下选择标准可以参考想最快出 Demo、验证可行性选 Coze想做一个正经的、可运维的业务系统选 Dify想研究智能体底层算法和机制选 AgentScope、AutoGen 或 LangGraph想完全掌控代码直接用 LangChain vLLM 自己写。5. 从零搭建智能体实战知识库问答工作流这一节我们通过一个实际的案例把前面讲的概念串起来。假设我们要开发一个“企业技术文档智能助手”功能如下用户输入问题系统从知识库中检索相关文档系统调用一个内部工具查询项目状态系统综合生成回答。下面给出两种实现路径低代码平台Dify和纯代码实现Python LangChain vLLM你可以根据自己的技术水平选一个。5.1 需求分析和整体流程先把任务拆解清楚用户提问 | v [意图识别] 判断是知识库问题还是需要查实时数据 | ---- [知识库检索] - [向量检索] - [Rerank 重排] - [组装上下文] | ---- [调用内部工具] - [获取项目状态] - [格式化数据] | v [大模型生成最终回答]5.2 方案一基于 Dify 搭建第一步准备知识库文档。支持 TXT、Markdown、PDF、HTML 等格式。在 Dify 的“知识库”页面创建数据集上传文档系统会自动完成分段和向量化。分段参数建议分段长度500 到 800 字分段重叠50 到 100 字Embedding 模型选择 BGE-M3 或 Dify 内置模型检索模式混合检索全文 向量。第二步添加工具节点。在工作流中增加 HTTP 请求节点调用内部 API。例如GET https://api.example.com/projects?statusactive Authorization: Bearer ${API_KEY}第三步设置大模型节点。在生成回答的节点配置模型为 DeepSeek 或 Qwen系统提示词可以写成你是一个企业技术文档智能助手。请根据知识库内容和工具查询结果回答问题。 回答要求 1. 优先使用知识库内容 2. 当工具查询结果与知识库冲突时请说明 3. 如果无法回答请明确告知不要编造。第四步发布为 API。Dify 发布应用时会分配一个 API 端点和 API Key可以直接集成到前端聊天窗口或企业微信机器人。5.3 方案二Python 代码实现下面是核心代码框架使用 LangChain vLLM Chroma 作为示例。你需要先安装相关依赖。pip install langchain langchain-community chromadb requests# 文件路径agent_demo/main.py import os import requests from langchain.embeddings import HuggingFaceEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Chroma from langchain.llms import OpenAI # 1. 初始化 embedding 模型 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cpu} ) # 2. 加载文档并切片示例支持 txt/md 文件 def load_documents(file_paths): docs [] for path in file_paths: with open(path, r, encodingutf-8) as f: content f.read() docs.append({content: content, source: path}) return docs # 3. 将文档写入向量库 def build_vector_store(file_paths, persist_dir./chroma_db): raw_docs load_documents(file_paths) splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) texts [] metadatas [] for doc in raw_docs: chunks splitter.split_text(doc[content]) texts.extend(chunks) metadatas.extend([{source: doc[source]}] * len(chunks)) vector_store Chroma.from_texts( textstexts, embeddingembeddings, metadatasmetadatas, persist_directorypersist_dir ) return vector_store # 4. 调用内部工具接口 def query_internal_tool(project_name: str) - str: # 这里只是示例实际业务中替换为真实接口地址 url https://api.example.com/projects/status params {project: project_name} resp requests.get(url, paramsparams, timeout5) if resp.status_code 200: return resp.text return 工具查询失败 # 5. 生成回答 def generate_answer(question: str, vector_store): # 检索知识库 retriever vector_store.as_retriever(search_kwargs{k: 3}) docs retriever.get_relevant_documents(question) context \n\n.join([doc.page_content for doc in docs]) # 调用工具 tool_result query_internal_tool(demo-project) # 构造提示词 prompt f请基于以下知识库内容和工具查询结果回答问题。 ### 知识库内容 {context} ### 工具查询结果 {tool_result} ### 用户问题 {question} 请给出准确、简洁的回答。如果知识库内容不足请说明。 # 调用本地 vLLM 服务也可以替换为 OpenAI SDK from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: prompt}] ) return response.choices[0].message.content if __name__ __main__: # 第一次运行建库第二次运行可跳过建库直接查询 vector_store build_vector_store([docs/help.md]) answer generate_answer(如何重置项目部署密钥, vector_store) print(answer)这段代码的关键点在于使用 BGE 模型做向量化本地即可运行使用 Chroma 做向量数据库适合中小规模知识库通过 OpenAI 兼容接口连接本地 vLLM 服务同一个提示词中融合了知识库上下文和工具查询结果。实际部署时建议替换为项目真实的内部接口并对工具调用错误做兜底处理。5.4 运行与验证启动本地模型服务vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000运行智能体脚本python main.py预期输出效果类似根据知识库文档说明项目部署密钥可以按以下步骤重置 1. 登录控制台进入项目设置 2. 找到 API 密钥管理页面 3. 点击“生成新密钥”确认后旧密钥立即失效。 另外工具查询结果显示 demo-project 当前状态为运行中重置密钥不影响现有服务。这里展示的是最小可运行版本生产环境还需要加上错误处理、日志、权限校验和并发控制。6. 常见问题与排查思路智能体开发在实际操作中会遇到不少问题下面整理几个出现频率较高的情况。6.1 模型有回答但知识库内容检索不到现象常见原因解决思路回答明显没用知识库内容向量检索 TopK 太小没召回正确文档调大检索数量例如 k5 或 k8文档被切碎语义丢失分段长度不合适调整 chunk_size尝试 300/500/800相似内容太多排序不准缺少 Rerank 重排引入 Rerank 模型如 BGE-Reranker特殊术语检索不到Embedding 模型不擅长专有词汇添加同义词扩展规则或使用更好的 embedding 模型6.2 智能体一直调用同一个工具不会分支这是很多初学者的常见困惑。出现这个问题的根本原因通常是提示词对工具的“触发条件”描述得不够清晰或者没有做意图路由。解决方案在每个工具节点的描述里写清楚“当用户提到 XXX 关键词时调用这个工具”在第一个节点前增加一个“意图分类器”节点如果使用 Dify可以先用条件分支节点做规则匹配再做模型判断。6.3 模型多轮对话后忘记前面的内容这是记忆机制没有配置好。对话历史的 token 长度有限超过限制后最早的内容会被丢弃。在 Dify 中可以在“对话开场白”中设置一个“会话总结”节点定时总结对话内容。在代码实现中可以使用消息压缩策略将超出阈值的消息摘要后再继续对话。6.4 工具调用返回 JSON 解析失败模型调用工具时返回的arguments字段可能是残缺的尤其是使用小参数模型时。建议使用支持 Function Calling 的模型不要靠纯文本生成 JSON解析 JSON 时使用json.loads加异常捕获解析失败时不要直接报错可以让模型重新生成最多重试两次可以在提示词中要求“只返回 JSON不要输出任何解释”。import json import re def safe_parse_json(text: str): try: return json.loads(text) except json.JSONDecodeError: match re.search(r\{.*\}, text, re.S) if match: return json.loads(match.group()) raise ValueError(f无法解析JSON: {text})6.5 智能体执行链路过长响应时间飙升多步推理 多次工具调用会导致响应时间从 1 秒变成 10 秒甚至更长。排查思路检查调用链上是否有不必要的串行工具调用能并行的尽量并行大模型请求可以设置更低的 max_tokens 上限在工具调用环节如果内部接口本身响应慢优先优化接口对于固定流程考虑用 Workflow 模式代替自由 ReAct 模式减少模型自主决策带来的额外轮次。7. 最佳实践与工程建议7.1 先做小闭环再做复杂编排我第一次做智能体的时候一上来就设计了 10 多个工具节点还挂了多轮记忆和复杂的提示词。结果问题频出主要集中在工具调用时序和上下文丢失上。后来调整了思路先实现“单轮问答 一个工具调用”跑通后再加知识库检索再加多轮记忆最后才做复杂的任务拆解。现在回头看这个顺序是最不容易劝退自己的方式。7.2 提示词围绕“工具描述”和“边界条件”写智能体的提示词和普通 Chat 提示词有很大区别。普通 Chat 更关注回答风格智能体提示词更要关注工具的触发条件是什么多个工具调用时优先级是什么工具返回错误时怎么处理如果用户意图不明确要不要进一步追问。可以在提示词中增加这样一段你有以下工具可用 - search_knowledge_base当问题涉及产品使用、技术文档时优先使用。 - query_order_status当用户询问订单、物流状态时使用。 - create_ticket当用户想要提交工单、投诉时使用。 调用规则 1. 如果问题同时命中知识库和订单查询先查知识库再查订单状态 2. 工具调用失败时如实告知用户需要稍后重试 3. 如果没有合适工具直接回答“当前无法处理该问题”。7.3 知识库建设要重视数据质量知识库问答的准确性一半取决于模型另一半取决于知识库本身。几个经验文档尽量采用半结构化格式比如 Markdown、HTML比 PDF 更容易切分一个文档文件不要塞进大量无关内容尽量按主题拆分定期更新向量索引文档内容变更后要重新切分和向量化对高频问题可以人工维护“问题-答案”对放到独立的 FAQ 知识库中检索优先级高于原始文档。7.4 安全边界要从一开始设计智能体权限设计很容易被忽视但在企业场景中特别重要。基本原则工具调用需要账号体系不能给智能体一个万能 API Key用户身份信息通过请求头传递智能体不能私自切换用户身份涉及数据查询时工具层做权限过滤不能把数据库全量返回给模型记录所有工具调用的日志便于审计对外发布的 API 需要限流防止被刷。7.5 重视可观测性智能体执行是一个多步骤过程一旦出错很难从最终答案倒推问题出在哪一步。建议从最开始就加上日志每步工具的入参和出参大模型每次调用的 token 消耗向量检索的召回结果每次路由走到了哪个分支。在 Dify 中每次运行都会生成运行日志可以直接看节点执行情况。在代码实现中建议用结构化日志记录关键节点。import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(agent) logger.info(retrieve_docs, extra{question: question, top_k: 3}) logger.info(call_tool, extra{tool: query_order_status, params: params}) logger.info(generate_answer, extra{token_usage: response.usage})7.6 生产环境部署建议如果要上线一个智能体应用建议关注以下事项模型部署和业务应用部署分离模型升级不影响业务为智能体 API 单独配置超时时间避免模型卡死影响调用方使用消息队列或异步任务处理耗时的智能体任务对高频工具调用做缓存比如相同参数的查询结果缓存 5 分钟上线前准备一套评测集覆盖正常问题、边界问题、恶意输入三类。8. 从这次 GTC 看未来的开发方向回到这次柏林 GTC 的议题智能体和开源模型之所以成为焦点本质上是整个 AI 开发范式在变化。过去我们习惯“接入一个 API 就完成功能”现在更强调模型可以本地化部署流程可以动态编排工具可以自由接入应用可以根据业务需求组合不同的模型和组件。对开发者来说这意味着超车机会在于如何把大模型能力转换为具体的业务价值。框架和模型都在快速迭代但核心的解决问题能力、工作流设计能力和工程化能力是长期有价值的。所以如果你也想跟上这波趋势建议从今天开始找一个最贴近业务的小场景尝试用开源模型 智能体框架把它跑通。不用追求一步到位的大系统关键是完整走一遍“模型部署 - 知识库搭建 - 工具接入 - 流程编排 - 上线验证”的闭环。跑通第一个闭环之后你对智能体开发的理解会比看再多资料都有用。 智能体与开源模型：从概念到实战的完整开发指南
这两年关于大模型的话题基本绕不开两个关键词一个是智能体Agent一个是开源模型。而 GTC 作为 NVIDIA 每年最重要的技术大会几乎成了观察 AI 行业趋势的风向标。最近作者准备前往柏林参加 GTC 相关活动结合会前关注的议题顺手把这两个方向的最新变化和落地路径做了一次系统梳理。这篇文章不打算写成新闻稿而是从一个开发者的视角聊聊智能体到底是什么、开源模型现在发展到什么程度、以及如果你想自己搭建一个智能体应用完整的流程、工具链和避坑点有哪些。无论你是刚开始接触智能体开发还是已经在用 Dify、Coze、AgentScope 这类平台做原型这篇文章都能给你一份可供参考的实战笔记。1. GTC 与智能体、开源模型的关系1.1 GTC 上为什么要聊智能体和开源模型GTC 全称是 GPU Technology Conference早期更多聚焦图形计算、高性能计算和 CUDA 生态。但过去两年AI 大模型成了绝对主角GTC 的议题也随之延伸到了模型训练、推理优化、智能体应用、开源模型生态等多个方向。为什么智能体和开源模型能在 GTC 上占据重要位置一个很现实的原因是大模型本身的边际收益正在下降大家开始关心怎么把模型用起来。而“用起来”最典型的形态就是智能体——让模型不只会聊天还能调用工具、操作软件、自动完成一个完整任务。另一个原因是开源模型极大降低了智能体的开发门槛。闭源 API 虽然方便但存在数据出域、成本不可控、本地化适配难等问题。开源模型则可以部署在本地或私有云配合向量数据库、工作流引擎快速搭建企业级智能体应用。GTC 这类大会恰恰是观察底层算力、模型推理框架和上层应用如何衔接的最佳窗口。1.2 智能体和开源模型的协同关系可以这样理解开源模型是智能体的“大脑”负责理解任务、拆解步骤、生成文案或代码。智能体框架是“骨架”负责把模型能力包装成可执行的 Workflow。工具链和知识库是“手脚”让智能体能够查数据库、调 API、搜索文档。这三者组合起来才是一个真正能落地的智能体应用。过去我们说“模型即产品”现在的趋势变成了“智能体即产品”。模型本身越来越像基础设施而智能体则是跑在基础设施上的应用程序。1.3 为什么现在聊智能体开发正当时开发生态里最近冒出了大量智能体方向和工具比如 Dify、Coze、AgentScope、AutoGen、LangGraph 等很多开发者也明显感觉到智能体开发的人才需求在快速增长。这背后有几个推动力大模型推理成本持续下降让多轮调用、多工具协作的智能体方案在经济上可行。模型能力质变尤其是开源模型在代码生成、工具调用、长文本理解方面的表现越来越接近闭源模型。低代码平台成熟让非算法工程师也能快速搭建智能体原型。所以现在是一个非常适合动手实践智能体开发的窗口期。2. 什么是智能体从概念到核心架构2.1 智能体的通俗理解智能体你可以先把它理解成“一个会用工具的 AI 助手”。普通聊天机器人只能根据用户输入生成文字回复。而智能体可以把用户的一句话任务拆成多个子任务自己决定调用哪个工具或 API根据工具返回结果继续调整下一步动作最终输出一个完整结果比如一份报告、一段代码、一个工单处理结果。举个例子用户说“帮我查一下本周所有未关闭的工单并按优先级列出处理方案。”传统机器人的回答可能是“抱歉我无法查询工单系统。”智能体的执行过程则是调用工单系统 API获取本周未关闭工单列表根据优先级字段对工单排序对高优先级工单调用知识库匹配处理方案汇总生成 Markdown 报告返回给用户。核心区别在于是否具备任务拆解和工具调用的能力。2.2 智能体的核心技术组件一个完整的智能体系统通常包含以下组件组件作用常见实现大语言模型负责理解意图、生成回复、决策GPT、DeepSeek、Qwen、GLM 等任务规划模块将复杂任务拆解为可执行的子任务ReAct、Plan-and-Execute、CoT工具调用模块让模型调用外部 API、函数、代码Function Calling / Tool Calling记忆模块保存对话历史、短期记忆和长期知识Redis、向量数据库知识库模块提供私有知识和外部文档检索Dify Knowledge、LangChain Retriever执行引擎编排整个工作流、处理异常Dify Workflow、LangGraph、AgentScope2.3 智能体的工作模式目前主流的智能体工作模式有三种模式一ReAct 模式推理 行动模型先分析当前状态决定要调用什么工具然后根据工具返回结果继续推理。思考 - 行动 - 观察 - 再思考 - 再行动 - 最终回答这种模式适合需要多步决策的场景但 Token 消耗较高响应时间相对长。模式二Plan-and-Execute 模式先规划再执行先把用户任务拆成一个计划列表再按计划执行。特点是一次性规划执行过程中较少动态调整。适合流程固定的任务比如“每天定时生成日报并发送邮件”。模式三Workflow 模式工作流模式用户或开发者提前定义好节点和流程模型只负责其中生成类的节点。Dify 和 Coze 上大量使用这种方式。优点是稳定可控缺点是不够灵活。2.4 智能体和 RAG 的关系现在很多项目里智能体和 RAG检索增强生成是分不开的。你要做一个企业知识库问答智能体基本流程就是把企业文档切片、向量化存入向量数据库用户提问时先从向量库检索相关内容将检索结果拼接到提示词中交给大模型生成答案。RAG 负责“找到对的资料”智能体负责“理解任务并组织执行流程”。两者结合是目前企业级智能体最常见的落地形式。3. 开源模型的现状与选型思路3.1 开源模型为什么迎来质变过去很多人对开源模型的印象是“能力比闭源模型差一截”。但最近一段时间以 DeepSeek、Qwen千问、GLM、Llama 系列为代表的开源模型在代码生成、数学推理、工具调用、Agent 任务执行上表现越来越亮眼。开源模型的意义不只是省 API 费用更关键的是可以本地部署数据不离开企业内网可以根据业务场景继续微调可以配合开源的推理框架做私有化交付社区反馈迭代速度快版本更新频繁。这也直接带动了智能体开发的开源化趋势更多人开始基于开源模型和开源框架搭建自己的智能体。3.2 开源模型如何选型开源模型选型不能只看跑分要结合你的具体场景。这里给出几点参考第一类通用对话 复杂任务拆解优先选择参数较大、指令遵循能力强的模型例如 DeepSeek 系列、Qwen2.5 系列。它们对中文支持好工具调用能力也比较成熟。第二类代码生成与开发助手如果你做的是代码类智能体比如自动写代码、解释代码、生成单元测试可以选择代码能力更强的模型或者配合 Code Llama、DeepSeek-Coder 这类专用模型。第三类轻量级 低成本部署如果部署资源有限可以考虑量化后的 7B 到 14B 模型配合 vLLM、Ollama 这类推理框架使用。虽然复杂推理能力有所下降但日常信息抽取、文档问答效果已经够用。第四类向量检索 重排智能体应用经常需要做知识库检索除了对话模型还需要两类模型向量模型用于把文本转为向量如 BGE 系列、M3E 等Rerank 模型用于对检索结果做精排提升答案准确率。建议在项目中同时引入 Embedding 模型和 Rerank 模型不要只用粗排结果直接喂给大模型。3.3 开源模型部署的常见方案本地部署开源模型的方案有很多选择哪个主要看你的技术栈和硬件条件。方案一Ollama Open WebUI适合个人开发者和快速验证场景。Ollama 安装简单命令行拉模型即可运行Open WebUI 提供可视化的网页交互界面。缺点是并发能力弱不适合生产环境。方案二vLLM 部署适合生产环境。vLLM 使用 PagedAttention 技术吞吐量高支持 OpenAI 兼容的 API 格式。常见用法是vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000启动后可以像调用 OpenAI API 一样调用本地模型。Dify、Coze 等平台都支持配置这种 OpenAI 兼容接口。方案三Docker Compose 一键部署适合需要集成知识库、工作流、模型管理的完整场景。比如 Dify 社区版一套 Docker Compose 文件就能启动包含模型管理、向量数据库、Agent 编排在内的整套服务。4. 智能体开发工具链全景在正式写代码之前先梳理一下现在主流的智能体开发工具。这样可以避免重复造轮子也能更快理解后面实战案例中每一步的作用。4.1 从底层到上层的完整工具链层次代表工具解决的问题模型层DeepSeek、Qwen、GLM、Llama提供推理能力推理层vLLM、Ollama、TGI部署和加速模型智能体框架Dify、Coze、AgentScope、AutoGen、LangGraph编排、规划、工具调用知识库层Dify Knowledge、LangChain Retriever、Milvus文档切片、向量化、检索应用层Open WebUI、ChatGPT-Next-Web、自建前端用户交互入口4.2 Dify适合快速搭建智能体应用的低代码平台Dify 是目前比较流行的开源 LLMOps 平台它把知识库、工作流、模型管理、Agent 编排都整合到了一起。Dify 的核心优势在于可视化编排 Agent 工作流内置知识库功能支持多种文档格式支持接入 OpenAI、DeepSeek、Qwen 等主流模型也支持本地 vLLM 接口支持发布 API方便集成到现有系统自带日志与标注功能方便调试。Dify 适合两类人非算法工程师想快速搭建知识库问答机器人后端工程师想省掉前端和基础设施搭建时间专注业务逻辑。4.3 Coze扣子适合快速验证和分享Coze 是字节跳动推出的智能体平台支持模型接入、插件、工作流、知识库界面友好非常适合快速做一个 Demo 然后分享链接。不过需要注意海外版和国内版的能力范围、模型配置有差别。另外作为云端平台数据安全边界需要结合企业规范评估。4.4 AgentScope适合算法团队做深入定制AgentScope 是阿里开源的多智能体框架灵活度高适合开发者通过 Python 代码精细控制智能体的行为。如果你需要对智能体内部做深度定制比如自定义记忆机制、自定义工具调度逻辑AgentScope 这类框架更合适。4.5 开发者的选择建议总结一下选择标准可以参考想最快出 Demo、验证可行性选 Coze想做一个正经的、可运维的业务系统选 Dify想研究智能体底层算法和机制选 AgentScope、AutoGen 或 LangGraph想完全掌控代码直接用 LangChain vLLM 自己写。5. 从零搭建智能体实战知识库问答工作流这一节我们通过一个实际的案例把前面讲的概念串起来。假设我们要开发一个“企业技术文档智能助手”功能如下用户输入问题系统从知识库中检索相关文档系统调用一个内部工具查询项目状态系统综合生成回答。下面给出两种实现路径低代码平台Dify和纯代码实现Python LangChain vLLM你可以根据自己的技术水平选一个。5.1 需求分析和整体流程先把任务拆解清楚用户提问 | v [意图识别] 判断是知识库问题还是需要查实时数据 | ---- [知识库检索] - [向量检索] - [Rerank 重排] - [组装上下文] | ---- [调用内部工具] - [获取项目状态] - [格式化数据] | v [大模型生成最终回答]5.2 方案一基于 Dify 搭建第一步准备知识库文档。支持 TXT、Markdown、PDF、HTML 等格式。在 Dify 的“知识库”页面创建数据集上传文档系统会自动完成分段和向量化。分段参数建议分段长度500 到 800 字分段重叠50 到 100 字Embedding 模型选择 BGE-M3 或 Dify 内置模型检索模式混合检索全文 向量。第二步添加工具节点。在工作流中增加 HTTP 请求节点调用内部 API。例如GET https://api.example.com/projects?statusactive Authorization: Bearer ${API_KEY}第三步设置大模型节点。在生成回答的节点配置模型为 DeepSeek 或 Qwen系统提示词可以写成你是一个企业技术文档智能助手。请根据知识库内容和工具查询结果回答问题。 回答要求 1. 优先使用知识库内容 2. 当工具查询结果与知识库冲突时请说明 3. 如果无法回答请明确告知不要编造。第四步发布为 API。Dify 发布应用时会分配一个 API 端点和 API Key可以直接集成到前端聊天窗口或企业微信机器人。5.3 方案二Python 代码实现下面是核心代码框架使用 LangChain vLLM Chroma 作为示例。你需要先安装相关依赖。pip install langchain langchain-community chromadb requests# 文件路径agent_demo/main.py import os import requests from langchain.embeddings import HuggingFaceEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Chroma from langchain.llms import OpenAI # 1. 初始化 embedding 模型 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cpu} ) # 2. 加载文档并切片示例支持 txt/md 文件 def load_documents(file_paths): docs [] for path in file_paths: with open(path, r, encodingutf-8) as f: content f.read() docs.append({content: content, source: path}) return docs # 3. 将文档写入向量库 def build_vector_store(file_paths, persist_dir./chroma_db): raw_docs load_documents(file_paths) splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) texts [] metadatas [] for doc in raw_docs: chunks splitter.split_text(doc[content]) texts.extend(chunks) metadatas.extend([{source: doc[source]}] * len(chunks)) vector_store Chroma.from_texts( textstexts, embeddingembeddings, metadatasmetadatas, persist_directorypersist_dir ) return vector_store # 4. 调用内部工具接口 def query_internal_tool(project_name: str) - str: # 这里只是示例实际业务中替换为真实接口地址 url https://api.example.com/projects/status params {project: project_name} resp requests.get(url, paramsparams, timeout5) if resp.status_code 200: return resp.text return 工具查询失败 # 5. 生成回答 def generate_answer(question: str, vector_store): # 检索知识库 retriever vector_store.as_retriever(search_kwargs{k: 3}) docs retriever.get_relevant_documents(question) context \n\n.join([doc.page_content for doc in docs]) # 调用工具 tool_result query_internal_tool(demo-project) # 构造提示词 prompt f请基于以下知识库内容和工具查询结果回答问题。 ### 知识库内容 {context} ### 工具查询结果 {tool_result} ### 用户问题 {question} 请给出准确、简洁的回答。如果知识库内容不足请说明。 # 调用本地 vLLM 服务也可以替换为 OpenAI SDK from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: prompt}] ) return response.choices[0].message.content if __name__ __main__: # 第一次运行建库第二次运行可跳过建库直接查询 vector_store build_vector_store([docs/help.md]) answer generate_answer(如何重置项目部署密钥, vector_store) print(answer)这段代码的关键点在于使用 BGE 模型做向量化本地即可运行使用 Chroma 做向量数据库适合中小规模知识库通过 OpenAI 兼容接口连接本地 vLLM 服务同一个提示词中融合了知识库上下文和工具查询结果。实际部署时建议替换为项目真实的内部接口并对工具调用错误做兜底处理。5.4 运行与验证启动本地模型服务vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000运行智能体脚本python main.py预期输出效果类似根据知识库文档说明项目部署密钥可以按以下步骤重置 1. 登录控制台进入项目设置 2. 找到 API 密钥管理页面 3. 点击“生成新密钥”确认后旧密钥立即失效。 另外工具查询结果显示 demo-project 当前状态为运行中重置密钥不影响现有服务。这里展示的是最小可运行版本生产环境还需要加上错误处理、日志、权限校验和并发控制。6. 常见问题与排查思路智能体开发在实际操作中会遇到不少问题下面整理几个出现频率较高的情况。6.1 模型有回答但知识库内容检索不到现象常见原因解决思路回答明显没用知识库内容向量检索 TopK 太小没召回正确文档调大检索数量例如 k5 或 k8文档被切碎语义丢失分段长度不合适调整 chunk_size尝试 300/500/800相似内容太多排序不准缺少 Rerank 重排引入 Rerank 模型如 BGE-Reranker特殊术语检索不到Embedding 模型不擅长专有词汇添加同义词扩展规则或使用更好的 embedding 模型6.2 智能体一直调用同一个工具不会分支这是很多初学者的常见困惑。出现这个问题的根本原因通常是提示词对工具的“触发条件”描述得不够清晰或者没有做意图路由。解决方案在每个工具节点的描述里写清楚“当用户提到 XXX 关键词时调用这个工具”在第一个节点前增加一个“意图分类器”节点如果使用 Dify可以先用条件分支节点做规则匹配再做模型判断。6.3 模型多轮对话后忘记前面的内容这是记忆机制没有配置好。对话历史的 token 长度有限超过限制后最早的内容会被丢弃。在 Dify 中可以在“对话开场白”中设置一个“会话总结”节点定时总结对话内容。在代码实现中可以使用消息压缩策略将超出阈值的消息摘要后再继续对话。6.4 工具调用返回 JSON 解析失败模型调用工具时返回的arguments字段可能是残缺的尤其是使用小参数模型时。建议使用支持 Function Calling 的模型不要靠纯文本生成 JSON解析 JSON 时使用json.loads加异常捕获解析失败时不要直接报错可以让模型重新生成最多重试两次可以在提示词中要求“只返回 JSON不要输出任何解释”。import json import re def safe_parse_json(text: str): try: return json.loads(text) except json.JSONDecodeError: match re.search(r\{.*\}, text, re.S) if match: return json.loads(match.group()) raise ValueError(f无法解析JSON: {text})6.5 智能体执行链路过长响应时间飙升多步推理 多次工具调用会导致响应时间从 1 秒变成 10 秒甚至更长。排查思路检查调用链上是否有不必要的串行工具调用能并行的尽量并行大模型请求可以设置更低的 max_tokens 上限在工具调用环节如果内部接口本身响应慢优先优化接口对于固定流程考虑用 Workflow 模式代替自由 ReAct 模式减少模型自主决策带来的额外轮次。7. 最佳实践与工程建议7.1 先做小闭环再做复杂编排我第一次做智能体的时候一上来就设计了 10 多个工具节点还挂了多轮记忆和复杂的提示词。结果问题频出主要集中在工具调用时序和上下文丢失上。后来调整了思路先实现“单轮问答 一个工具调用”跑通后再加知识库检索再加多轮记忆最后才做复杂的任务拆解。现在回头看这个顺序是最不容易劝退自己的方式。7.2 提示词围绕“工具描述”和“边界条件”写智能体的提示词和普通 Chat 提示词有很大区别。普通 Chat 更关注回答风格智能体提示词更要关注工具的触发条件是什么多个工具调用时优先级是什么工具返回错误时怎么处理如果用户意图不明确要不要进一步追问。可以在提示词中增加这样一段你有以下工具可用 - search_knowledge_base当问题涉及产品使用、技术文档时优先使用。 - query_order_status当用户询问订单、物流状态时使用。 - create_ticket当用户想要提交工单、投诉时使用。 调用规则 1. 如果问题同时命中知识库和订单查询先查知识库再查订单状态 2. 工具调用失败时如实告知用户需要稍后重试 3. 如果没有合适工具直接回答“当前无法处理该问题”。7.3 知识库建设要重视数据质量知识库问答的准确性一半取决于模型另一半取决于知识库本身。几个经验文档尽量采用半结构化格式比如 Markdown、HTML比 PDF 更容易切分一个文档文件不要塞进大量无关内容尽量按主题拆分定期更新向量索引文档内容变更后要重新切分和向量化对高频问题可以人工维护“问题-答案”对放到独立的 FAQ 知识库中检索优先级高于原始文档。7.4 安全边界要从一开始设计智能体权限设计很容易被忽视但在企业场景中特别重要。基本原则工具调用需要账号体系不能给智能体一个万能 API Key用户身份信息通过请求头传递智能体不能私自切换用户身份涉及数据查询时工具层做权限过滤不能把数据库全量返回给模型记录所有工具调用的日志便于审计对外发布的 API 需要限流防止被刷。7.5 重视可观测性智能体执行是一个多步骤过程一旦出错很难从最终答案倒推问题出在哪一步。建议从最开始就加上日志每步工具的入参和出参大模型每次调用的 token 消耗向量检索的召回结果每次路由走到了哪个分支。在 Dify 中每次运行都会生成运行日志可以直接看节点执行情况。在代码实现中建议用结构化日志记录关键节点。import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(agent) logger.info(retrieve_docs, extra{question: question, top_k: 3}) logger.info(call_tool, extra{tool: query_order_status, params: params}) logger.info(generate_answer, extra{token_usage: response.usage})7.6 生产环境部署建议如果要上线一个智能体应用建议关注以下事项模型部署和业务应用部署分离模型升级不影响业务为智能体 API 单独配置超时时间避免模型卡死影响调用方使用消息队列或异步任务处理耗时的智能体任务对高频工具调用做缓存比如相同参数的查询结果缓存 5 分钟上线前准备一套评测集覆盖正常问题、边界问题、恶意输入三类。8. 从这次 GTC 看未来的开发方向回到这次柏林 GTC 的议题智能体和开源模型之所以成为焦点本质上是整个 AI 开发范式在变化。过去我们习惯“接入一个 API 就完成功能”现在更强调模型可以本地化部署流程可以动态编排工具可以自由接入应用可以根据业务需求组合不同的模型和组件。对开发者来说这意味着超车机会在于如何把大模型能力转换为具体的业务价值。框架和模型都在快速迭代但核心的解决问题能力、工作流设计能力和工程化能力是长期有价值的。所以如果你也想跟上这波趋势建议从今天开始找一个最贴近业务的小场景尝试用开源模型 智能体框架把它跑通。不用追求一步到位的大系统关键是完整走一遍“模型部署 - 知识库搭建 - 工具接入 - 流程编排 - 上线验证”的闭环。跑通第一个闭环之后你对智能体开发的理解会比看再多资料都有用。