柏林 GTC 的议题还没正式开始，技术社区里围绕“智能体”和“开源模型”的讨论热度已经很高。我的判断很直接：这两个词放在一起，不是又一个概念热点，而是开发方式正在发生的变化。过去我们调模型接口，拿到的只是“一段文本”，现在可以定义“一个能完成任务的任务单元”，并且用开源模型把成本和数据隐私控制住。
这篇文章不聊发布会口号，只聊一个普通开发者真正要面对的六件事：选场景、选模型、选平台、跑通最小智能体、验证效果、排查问题。下面按实操顺序展开，能直接照着试的，就直接照着试。
1. 智能体和开源模型的组合，为什么值得你花时间
1.1 智能体不是聊天机器人，而是“任务执行单元”
很多人把智能体理解成“更聪明的聊天机器人”，这个理解会误导后面的所有选型。聊天机器人的核心是“对话”，你问一句，它答一句；智能体的核心是“任务”，它需要理解目标、拆分步骤、调用工具、检查结果，直到任务完成。
举个例子。一个销售聊天机器人只会回答“你们产品有什么功能”，而一个销售智能体会先去企业知识库里查产品资料，再根据客户的行业背景生成一段销售话术，然后调用客户关系管理系统把跟进记录更新掉。整个过程由模型驱动，但真正干活的不只是模型，还包括知识库、工具接口和执行流程。
所以搭建智能体的时候，第一件事不是选模型，而是把“任务”定义清楚：输入是什么，输出是什么，中间要用到哪些数据和工具，哪些环节允许模型自由发挥，哪些环节必须规则化。任务定义不清楚，后面每次改提示词都是在打补丁。
1.2 开源模型在智能体里承担三个角色
开源模型并不是智能体的全部，但它是很多人选择智能体方案的起点。在常见架构里，它通常承担三个角色。
第一是推理核心，也就是智能体的“大脑”。模型负责理解用户输入、拆解步骤、生成最终结果。第二是私有化底座。很多企业内部数据不能出内网，于是把开源模型部署在本地或私有云，所有请求都在自己环境里完成。第三是成本控制。按照 Token 计费的在线接口，在批量任务面前账单涨得很快，本地开源自部署可以把每次调用的边际成本压到很低的水平。
这三个角色分别对应三种需求：想要效果、想要隐私、想要省钱。大多数团队不是只选其中一种，而是先用开源模型做原型，再决定哪些模块固定用本地模型，哪些模块换成在线模型。
1.3 为什么这个组合会被反复讨论
柏林 GTC 的议题还没正式开始，围绕它的社区讨论里，智能体和开源模型占了很大篇幅。从讨论内容看，大家已经不太关心“能不能做”，而是关心“怎么做得稳、怎么用得起”。
这背后是两个信号。第一，智能体已经过了“Demo 能跑”的阶段，正在进入“任务能交付”的阶段。第二，开源模型解决了部署、成本和定制化这三个最实际的问题。两者放在一起，结论很清晰：开源模型负责让智能体“用得起、放得下”，智能体负责让模型“干得了活”。对开发者来说，掌握这条技术栈，不只是在追热点，而是在储备下一阶段的工程能力。
2. 动手前先选型：场景、模型、平台、数据
2.1 先定义场景，再选平台
很多人一上来就问“我应该用 Dify、Coze 还是写代码”，这个问题问早了。平台只是达成目标的工具，先回答“我要让智能体做什么”。
按任务类型分，大致有几类：
- 知识问答：基于企业内部文档回答问题，核心是 RAG。
- 内容生成：批量生成文案、公众号文章、营销素材，核心是提示词模板和输出质量控制。
- 业务自动化：把查询、计算、更新、通知等动作串起来，核心是工具调用和流程编排。
- 多角色协同：一个任务需要多个不同职责的智能体协作完成，核心是任务分配和结果汇总。
如果是个人学习或快速验证，Coze 这类在线平台上手最快，不用管部署。如果数据不能出内网，或者要做到更细的流程控制，Dify 这类可私有化部署的低代码平台更合适。如果任务逻辑非常复杂，低代码平台反而受限制，这时就该用 LangGraph 这类代码框架或直接写编排脚本。
平台选择没有绝对优劣，只有匹配度。判断标准是：上线后谁维护、数据放哪里、流程要不要频繁改、团队会不会写代码。
2.2 开源模型怎么选
开源模型的选项很多，常见的包括 Qwen 系列、DeepSeek 系列、Llama 系列、ChatGLM 系列等。选型时不要只看名气，直接拿你自己的任务去测，这是最靠谱的方法。
可以从四个维度筛选：
- 参数量：7B 级别在普通显卡上就能跑，70B 级别需要多卡或大显存，效果通常更好但成本高。
- 上下文长度：输入是长文档时，要关注模型能接受多长的上下文，否则内容会被截断。
- 工具调用能力：智能体需要模型理解“该调用哪个工具、参数怎么填”，不是所有开源模型都擅长这一点。
- 指令跟随能力：同一套任务描述，不同模型的执行稳定度差别很大，需要跑样例观察。
还有一个常见场景是写公众号文章、营销文案这类中文内容生成任务，对模型的中文写作能力和指令跟随能力要求更高，选型时同样要拿真实样例去测，不要只看榜单。我的建议是不要一开始就追求大模型。先选一个 7B 到 14B 级别、兼容性好的模型，把流程跑通，再对照效果决定要不要换更大的模型。很多场景卡住，不是模型不够强，而是知识库没有接好。
2.3 知识库相关组件：向量模型和 Rerank 模型
智能体要基于私有资料回答问题，绕不开 RAG。RAG 里除了大模型，还有两个容易被忽略的组件：向量模型和 Rerank 模型。
向量模型负责把文本变成向量，让智能体能在知识库里做相似度检索。开源选项里 BGE 系列、M3E 等都比较常见，选择时关注三个点：中文效果、支持的文本长度、向量维度是否被你用的向量库兼容。
Rerank 模型负责在检索出一批候选结果后重新排序，把最相关的几条放到最前面。它能改善“召回结果多但相关性乱”的情况。常见开源选项里有 BGE-reranker 等。但要注意，Rerank 不是必须的，知识库规模小、检索结果稳定时可以先不加；当知识库到几千条以上，或者经常出现“明明有答案却答不对”时，再考虑引入。
一句话总结：向量模型决定能不能找到，Rerank 决定找得准不准，大模型决定回答得好不好。三者是流水线关系。
2.4 数据准备有哪些通用要求
无论用哪个知识库平台，数据准备的基本要求是一致的：
- 格式尽量统一。txt、Markdown、PDF、docx、HTML 都可以，但混合格式会放大解析问题。
- 先给小样本。不要一次导入几百份文档，先导入三到五份，检查解析结果和检索命中情况。
- 清洗噪音。页眉页脚、水印、乱码、表格错位，都会污染切块结果。
- 注意权限。敏感信息一定要在进入知识库之前做好访问控制，而不是等模型已经回答出来了再补救。
数据质量决定了 RAG 的效果上限。我见过很多智能体效果差，根因不是模型拉胯，而是知识库里全是没清洗过的扫描 PDF。
3. 从零跑通一个最小开源模型智能体
3.1 最小环境清单
先确认机器条件，再决定走本地部署还是 API 调用。
本地部署方式，最低配置要求取决于模型参数量和量化方式。以 7B 级别模型为例，常见情况是 16GB 内存起步，显存 8GB 左右可以比较勉强地运行，想要流畅就需要更大显存或者使用量化版。这个数字不是绝对标准，实际以你选的具体模型和量化等级为准。如果机器配置不够，不要硬撑，改用在线 API 或者部署到有 GPU 的服务器上。
软件层面，最常见的组合是：Linux 或 macOS 系统、Python 3.10 以上、Docker（如果部署 Dify 这类平台）、模型运行环境。如果只是调用在线模型的 API，只需要一个 HTTP 客户端和 API Key，门槛会低很多。
3.2 低代码路线：用 Dify 或 Coze 搭一个问答智能体
低代码平台是跑通第一版最快的方式。以 Dify 为例，流程大致是：部署或登录平台，进入控制台后配置模型供应商，把模型 API 地址和密钥填进去，然后创建应用，选择“聊天助手”类型，填写系统提示词，发布后就能在对话界面测试。
如果接知识库，就在应用里关联数据集，并配置检索方式。Coze 类似，在线创建机器人后，可以选择模型、添加知识库、编排技能和工作流。
这个过程的目的不是把产品做出来，而是验证三个问题：模型能正常返回、知识库能命中、提示词的基本逻辑成立。只要这三个验证通过，最小智能体就算跑通了。不要在这个阶段过度调整界面和流程。
3.3 代码路线：用本地模型写一个最小调用
低代码平台不能满足需求时，可以用代码直接调用模型服务。现在的模型服务大多提供兼容 OpenAI 格式的接口，调用代码非常短。下面是一个最小示例：
from openai import OpenAI # 示例：连接本地模型服务，实际地址和模型名以你的环境为准 client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="local" ) resp = client.chat.completions.create( model="local-model-name", messages=[ {"role": "system", "content": "你是一个智能体助手。"}, {"role": "user", "content": "用一句话介绍 RAG。"} ], temperature=0.7, ) print(resp.choices[0].message.content)这段代码覆盖了最小闭环：连接模型、发送消息、拿到结果。基于这个基础，再逐步加入工具调用、知识库检索和任务编排。
写代码路线有两条分支：一条是直接用模型 SDK 自己拼逻辑，适合简单任务；另一条是使用 Agent 框架，比如 LangGraph 或各类开源 Agent 框架，适合多步骤、多角色、循环执行等复杂需求。新手先走第一条，等清楚了自己要哪些能力，再引入框架。
3.4 给智能体接上知识库和工具
最小闭环跑通后，下一步增强两个能力：检索能力和行动能力。
检索能力就是接入知识库。在低代码平台里是上传文档、配置切块长度和召回数量；在代码路线里是调用向量数据库，查询后把结果拼进上下文。这里的关键是“检索-回答”的配合：不是把所有文档都塞进模型，而是只把最相关的几段拼进去，否则上下文会被噪音淹没。
行动能力就是工具调用。智能体可以调用搜索、计算器、数据库查询、HTTP 接口等外部能力。在这之前，要先把每个工具的参数格式定义清楚。比如查询天气的工具，参数是城市名；查询订单的工具，参数是订单号。模型根据用户意图决定调用哪个工具、填入什么参数，然后把返回值作为下一步推理的依据。
一个常见的坑是：工具调用通了，但模型不知道什么时候该用工具。解决办法有两个方向：一是在系统提示词里明确工具的使用规则，二是换一个工具调用能力更强的模型。
4. 验证效果：先跑单条，再谈批量
4.1 单条用例怎么测
智能体搭建完成后的第一步，不是立即上线，而是用单条用例做完整验证。我一般会准备一张测试表格，每个用例包含三列：输入、预期结果、实际结果。预期结果不是标准答案，而是“关键信息点清单”。
以知识问答智能体为例：问“报销流程是什么”，预期结果里至少包含“提交审批”“发票要求”“审批时限”三个信息点。只要实际回答覆盖这些点，就算通过。不要求措辞完全一致，因为模型每次生成肯定有差异。
单条测试要覆盖正常输入、边界输入和错误输入。边界输入比如空输入、超长输入、特殊字符；错误输入比如问一个知识库里完全没有的东西。关键看模型在不确定时是明确说不知道，还是编造答案。
4.2 判断输出质量看四个指标
判断智能体是否可用，我习惯看四个维度：
- 完整性：关键信息是否都出现了，有没有漏掉任务要求的一部分。
- 一致性：同一问题在多轮测试中，结论方向是否稳定，不出现前后矛盾。
- 格式正确性：要求输出 JSON、表格、Markdown 时，格式是否合法可用。
- 引用可追溯性：涉及知识库内容时，能否给出来源或定位到原文。
前三个是通用指标，第四个是 RAG 场景特有指标。如果回答看起来流畅但找不到来源，这在内部知识问答场景里是不合格的，因为你无法判断是不是编的。
4.3 参数调整的优先级
智能体效果不好，很多人第一反应是调 temperature，把随机性调低。我不建议这么做，因为参数调整有优先级。
首先是换模型。模型能力决定上限，如果模型本身不具备某个能力，调参数没用。其次是改提示词，把任务要求、输出格式、边界条件写清楚，这是性价比最高的调整手段。再其次是调知识库检索，包括切块策略、召回数量、相似度阈值。最后才是 temperature、top_p 这类生成参数，它们只能做微调，不用指望能解决逻辑问题。
我见过一个案例，知识问答智能体总是回答得不够详细，团队反复调 temperature，最后发现是系统提示词里没有要求“分点回答”。改一行提示词，效果比调十个参数都好。
4.4 资源占用和响应速度怎么观察
验证效果时，资源占用和响应速度也要记录，否则等批量跑任务时会措手不及。
在线 API 方式，需要关注三个指标：单次请求延迟、每分钟请求数上限、费用。并发上去之后，延迟和限流是主要风险。本地部署方式，需要关注显存占用、内存占用、生成速度。如果使用量化模型，显存占用更低但生成速度可能会下降，需要实测。
一个实用的做法是：先以 1 个并发跑 20 条测试任务，记录平均耗时和失败次数；再逐步提高到 5 个并发、10 个并发，观察延迟和错误率的变化。不要一上来就开最大并发，否则一个接口限流或内存不足，很难定位是哪个环节造成的。
5. 什么时候才需要多智能体，怎么设计
5.1 单智能体够用就不要上多智能体
多智能体是热门词，但不是所有场景都需要。单智能体处理不了的复杂度，通常表现为三种：一是任务需要多个角色，比如一个写方案、一个审方案；二是任务可以并行拆分，比如同时查多个数据源；三是单个模型在上下文太长时容易混乱，需要分阶段处理。
如果只是为了演示效果，不要强行上多智能体。多智能体会带来三个额外成本：任务之间的上下文传递容易丢信息、多个模型调用导致费用上升、错误会被级联放大。一个子任务失败，可能产生一串连锁问题。所以我的原则是：单智能体能解决的，绝不上多智能体。
5.2 多智能体架构的核心设计点
如果确实需要多智能体，先设计三个东西：角色定义、通信协议、结果汇总。
角色定义要具体。不要只写“你是专家”，要写清楚职责边界、输入输出格式、不允许做什么。通信协议要明确。智能体 A 的输出要能在智能体 B 的输入中正确解析，最好用结构化格式传递，不要靠自然语言猜。结果汇总要有规则。谁负责最终汇总，哪些内容有权重，冲突时以谁的结论为准。
在低代码平台上，多智能体通常通过工作流实现，每个节点是一个智能体，节点之间的字段映射就是通信协议。在代码框架中，可以用状态图或消息队列来管理。无论哪种方式，都要把每个子任务的输入和输出记录下来，否则出了问题很难回放。
5.3 生产化：批量任务、失败重试和日志
从实验走向生产，最关键的变化是异常开始常态化。演示环境跑一遍是成功的，批量 1000 条任务里一定会出现超时、接口报错、输出格式异常等情况。所以生产化要优先解决三件事：
第一是任务队列。不要让所有任务一次性并发打上去，用队列控制同时执行的数量。第二是失败重试。对超时和临时性错误要设计重试机制，但要限制重试次数，避免死循环。第三是日志。每一条任务都要记录输入摘要、模型、耗时、结果状态和错误信息，否则你无法复盘。
输出文件的命名也要处理。批量任务如果输出文件名冲突，会互相覆盖。我习惯在输出文件名里加任务 ID 和时间戳，保证每个结果可追溯。
6. 常见问题排查：先看什么，后看什么
6.1 现象驱动的排查顺序
智能体出问题时，先别急着改提示词，按以下顺序排查：
- 看现象和日志：是请求失败、超时、返回为空，还是返回内容质量差。
- 看输入：用户输入、系统提示词是否被意外修改，格式是否正确。
- 看模型服务：API 是否正常、上下文是否超长、模型名是否写错。
- 看知识库：知识库是否命中，检索到的片段是否相关，有没有把无关内容拼进上下文。
- 看工具调用：工具参数是否正确，工具返回值有没有被正确处理。
- 看参数和平台限制：并发、超时时间、批量大小、平台配额。
这个顺序的逻辑是：先确认最外层的事实用例，再往内部缩小范围。很多人卡住的时候第一个念头是换模型，但实际经常是知识库切块长度设得太短，或者工具返回了空列表却没有做空值判断。
6.2 本地部署资源不足怎么办
本地部署遇到资源不足时，按这个顺序尝试降级：
- 换更小参数量的模型。
- 使用量化版本，比如 4bit 或 8bit 量化，能明显降低显存占用。
- 缩小上下文窗口，减少每轮请求携带的历史消息。
- 降低并发数，一次只跑一个任务。
- 把大任务拆成小任务，复杂任务分多次调用完成。
如果降级后效果明显变差，说明资源不足已经影响能力上限，这时候可以直接切换到在线 API。不要为了“本地化”而被硬件拖住，很多项目最后都采用混合方式：核心任务用在线模型，批量且不敏感的任务用本地模型。
6.3 我建议的落地顺序
最后给出我平时给团队排任务时的顺序：先跑通最小智能体，不追求完美；然后单条验证，确认模型、知识库、工具三条链路都正常；再小批量测试，记录延迟、费用、失败率；接着优化效果，按照“换模型
