柏林 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_urlhttp://127.0.0.1:8000/v1, api_keylocal ) resp client.chat.completions.create( modellocal-model-name, messages[ {role: system, content: 你是一个智能体助手。}, {role: user, content: 用一句话介绍 RAG。} ], temperature0.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 我建议的落地顺序最后给出我平时给团队排任务时的顺序先跑通最小智能体不追求完美然后单条验证确认模型、知识库、工具三条链路都正常再小批量测试记录延迟、费用、失败率接着优化效果按照“换模型 智能体与开源模型落地实践：从选型到部署的六步实操指南
柏林 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_urlhttp://127.0.0.1:8000/v1, api_keylocal ) resp client.chat.completions.create( modellocal-model-name, messages[ {role: system, content: 你是一个智能体助手。}, {role: user, content: 用一句话介绍 RAG。} ], temperature0.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 我建议的落地顺序最后给出我平时给团队排任务时的顺序先跑通最小智能体不追求完美然后单条验证确认模型、知识库、工具三条链路都正常再小批量测试记录延迟、费用、失败率接着优化效果按照“换模型