1. 演示惊艳、上线就崩这个现象到底卡在哪做企业智能体这一行的人大概率都经历过同一个场景会议室里大屏上演示的智能体对答如流知识问答准确率看着能到九成领导点头业务方鼓掌项目顺利立项。结果一上线用户量一上来问题全冒出来了——回答开始胡编检索结果驴唇不对马嘴接口响应从两秒变成二十秒Function-Calling 调用失败率飙升最后业务方一句“还不如人工查文档”就把项目打进了冷宫。这个落差很多人第一反应是“大模型不行换个更强的”。我见过太多团队把预算砸在换模型上从开源换到闭源从小参数换到大参数结果上线还是崩。问题真不在大模型。大模型是那个站在台前表演的演员而决定这场戏能不能连演三百场的是后台的剧本、灯光、道具、场务——也就是知识库、检索链路、工具调用编排、状态管理这一整套工程体系。这篇内容我想聊的就是这件事企业智能体从演示到生产之间到底隔着哪些坑这些坑分别属于哪个环节以及每一个环节可以怎么补。核心关键词会围绕企业智能体、大模型、RAG、知识图谱、Function-Calling展开但重点不在概念科普而在“为什么演示能过、上线会崩”的工程归因。适合正在做企业智能体落地、被上线效果折磨过的工程师、产品经理和技术负责人看也适合刚接触 RAG 和智能体编排、想少走弯路的朋友。先把结论摆前面演示环境和生产环境本质上是两个不同的系统。演示环境是封闭、静态、低并发、人工兜底的生产环境是开放、动态、高并发、无人兜底的。你在演示环境里验证的是“模型能不能答对”在生产环境里要验证的是“整条链路在真实数据、真实流量、真实边界下能不能稳定答对”。这两件事的难度差了一个数量级而绝大多数团队只做了前者的验证。2. 演示环境与生产环境的本质差异拆解2.1 演示环境为什么总能“惊艳”演示环境的惊艳很大程度上是被设计出来的。我参与过不少项目的演示准备说句实在话演示用的知识库往往是精挑细选过的——文档格式统一、内容干净、没有扫描件、没有表格错位、没有互相矛盾的版本。问题也是提前设计好的问法标准答案唯一检索几乎不会失手。再加上演示时通常是单用户、低并发模型有充足的时间做多轮推理Function-Calling 调用的接口也是测试环境里最稳定的那几个。就算偶尔答错旁边还有个懂业务的工程师随时准备“补充说明”把话题圆回来。这种环境下智能体表现惊艳是正常的因为它面对的是一道被精心布置过的考题。问题在于很多团队把这种“考题环境”下的表现当成了系统能力的真实水平直接拿去承诺业务指标。这是后面所有崩溃的起点。2.2 生产环境的三重暴击数据、流量、边界生产环境对智能体的暴击我习惯归纳成三个维度。第一重是数据暴击。真实企业知识库是什么样PDF 扫描件、Word 老版本、Excel 里藏着关键参数、Confluence 页面半年没更新、同一个制度有三个版本在不同部门流传。你演示时用的那几十篇干净文档在真实知识库面前连零头都算不上。RAG 的检索质量直接取决于知识库的清洗和切分质量而这一步在演示阶段往往被跳过了。第二重是流量暴击。演示时一个请求慢慢跑生产时可能几十上百个请求同时进来。向量检索、重排、大模型推理、工具调用每一个环节都是资源消耗点。并发一上来响应时间指数级上升超时、限流、队列堆积接踵而至。很多智能体不是答不对是根本来不及答。第三重是边界暴击。演示时用户问的都是“正常问题”生产时用户会问各种你想不到的东西错别字、口语化表达、跨领域问题、恶意诱导、超长上下文。这些边界情况在演示里几乎不会出现但在生产里每天都在发生而它们恰恰是最容易让智能体翻车的场景。2.3 一个被忽视的事实瓶颈分布是长尾的我做过一个粗略的统计在一个典型的企业智能体系统里导致上线效果不达标的因素大模型本身的能力占比其实并不高。更多的失败集中在检索召回、知识组织、工具编排、上下文管理这些“非模型”环节。失败环节演示阶段暴露概率生产阶段暴露概率典型表现大模型基础能力高中答非所问、语言不通顺知识库质量低极高检索到过期/错误内容检索召回策略低高该召回没召回答“不知道”工具调用编排中高接口失败、参数错误、死循环并发与性能极低极高超时、限流、响应慢上下文管理低高多轮对话丢失关键信息这张表想说明的是演示阶段暴露的问题和生产阶段暴露的问题几乎不是同一批问题。你在演示里调优模型解决的是生产里占比不高的那部分而生产里真正致命的检索、编排、并发问题演示阶段根本测不出来。这就是“演示惊艳、上线就崩”的结构性原因。3. RAG 链路企业智能体最容易被低估的环节3.1 RAG 不是“接个向量库”那么简单很多人对 RAG 的理解停留在“文档切块、向量化、存库、检索、拼进 prompt”这五步。真做起来每一步都有大量决策点。文档怎么切按固定长度切还是按语义切表格和图片怎么处理检索用纯向量还是混合检索召回多少条要不要重排这些问题在演示阶段可以糊弄过去在生产阶段每一个都会变成事故。我见过一个项目知识库里有一批产品参数表切块时按固定 512 字符硬切结果一个参数被切成两半检索时永远只能召回半张表模型拿着半张表回答参数自然错。这种问题在演示时因为问题简单、文档少根本不会触发上线后用户一问具体参数就翻车。3.2 文档切分决定检索上限的隐形之手切分策略是 RAG 里最容易被忽视、却最影响上限的一环。我的经验是切分要跟着文档的语义结构走而不是跟着字符数走。对于结构化文档比如制度、手册、产品说明优先按标题层级切保证每个块是一个完整的语义单元。对于长段落文本可以用递归切分先按段落再按句子最后才按字符。对于表格要么整表保留要么转成结构化描述绝不能硬切。对于图片如果知识库需要存储图片内容得配合多模态能力或者 OCR 转文字纯文本 RAG 是处理不了图片语义的。提示切分块的大小没有万能值。块太小语义不完整块太大检索精度下降。我一般会先用 300 到 800 字符做基线再根据实际召回效果调整而不是一上来就定死。3.3 检索策略纯向量检索为什么经常失手纯向量检索擅长语义相似但对精确匹配、专有名词、编号类查询经常失手。用户问“工单编号 A12345 的处理流程”向量检索可能召回一堆“处理流程”相关的文档却漏掉那个真正包含编号的文档。生产环境里我强烈建议用混合检索向量检索负责语义召回关键词检索比如 BM25负责精确召回两路结果融合后再重排。这样既能接住口语化提问又能接住精确查询。重排环节可以用轻量级的交叉编码器模型把召回的前几十条重新打分排序显著提升 top 结果的准确率。3.4 知识图谱与本体建模让检索从“找相似”升级到“找关系”当企业知识存在大量实体关系时比如“某设备属于某产线、某产线由某部门负责、某部门适用某制度”纯 RAG 就很难处理这种多跳推理。这时候知识图谱和本体建模就派上用场了。本体建模的核心是把业务里的实体、属性、关系定义清楚形成一套 schema。比如定义“设备”“产线”“部门”“制度”这几类实体以及它们之间的归属、适用关系。有了本体知识图谱就能把散落在文档里的关系结构化检索时可以先定位实体再沿关系扩展回答“这台设备适用哪些制度”这类问题就稳得多。《知识图谱应用实践指南》里提到的思路很实用不要一上来就追求大而全的图谱先从业务最痛的那几个关系入手小步构建边用边补。我自己的做法是先做本体建模把核心实体和关系画出来再用工具生成可视化图谱验证关系是否合理最后才灌数据。3.5 RAG 瓶颈的真实来源召回质量而非模型能力回到那个核心判断RAG 的瓶颈绝大多数时候在召回不在生成。模型再强你喂给它的上下文是错的、过期的、不完整的它也变不出正确答案。所以优化 RAG优先优化召回链路文档清洗、切分策略、混合检索、重排模型这四步做到位效果提升往往比换模型明显得多。4. Function-Calling 与智能体编排演示能跑上线就乱4.1 Function-Calling 的本质是“让模型决定调什么”Function-Calling 让大模型能够根据用户意图决定调用哪个外部工具、传什么参数。演示时工具少、参数简单、调用路径清晰模型很容易做对。生产时工具可能有几十个参数有嵌套结构调用还涉及鉴权、重试、超时复杂度完全不是一个量级。我见过最典型的事故是模型在演示时能正确调用“查询订单”接口上线后因为参数里多了个可选字段没填接口直接报错而智能体没有兜底逻辑整个对话就卡死了。4.2 工具编排的三种常见翻车模式第一种是参数幻觉。模型会“脑补”参数尤其是当工具描述不够清晰时。比如接口需要“订单号”模型可能把用户说的“上周那个单子”直接当成订单号传进去。解决办法是把工具的参数描述写得极其明确并在调用前做参数校验。第二种是调用死循环。模型调用工具失败后可能反复重试同一个调用陷入死循环。必须在编排层设置最大重试次数和失败兜底策略。第三种是工具选择错误。工具一多模型容易选错。这时候可以给工具做分组或者用路由层先判断意图再限定候选工具范围降低选择难度。4.3 编排层才是智能体的“大脑”很多人把大模型当成智能体的大脑我觉得更准确的说法是大模型是语言理解和生成模块编排层才是真正的大脑。编排层负责决定什么时候检索、什么时候调工具、多轮对话怎么管理状态、失败怎么兜底。这部分做不好模型再强也白搭。一个稳健的编排层至少要包含意图识别、路由分发、工具调用管理、状态管理、异常兜底这几个模块。意图识别可以用小模型或者规则先做粗筛路由分发决定走 RAG 还是走工具工具调用管理负责参数校验和重试状态管理维护多轮上下文异常兜底保证任何环节失败都有合理回复。4.4 多轮对话的状态管理被低估的难点演示时通常是一问一答生产时用户会连续追问。“那它的保修期呢”“刚才说的那个流程再讲一遍”这些追问依赖上下文。如果状态管理做得粗糙多轮对话就会丢失关键信息模型只能重新检索效果和体验都差。我的做法是把对话状态显式管理起来记录当前话题、已确认的实体、已调用的工具和结果。每一轮把相关状态拼进上下文而不是把全部历史都塞进去。这样既保证连贯性又控制上下文长度。5. 从演示到上线的完整落地实操5.1 第一步用真实数据重建知识库上线前必须做的一件事是把演示用的“干净知识库”换成真实知识库。具体操作是拉取生产环境里真实的文档源做一次完整的清洗和切分统计文档类型分布、格式问题、版本冲突情况。这一步会暴露大量演示阶段看不到的问题越早做越好。清洗时重点关注扫描件 OCR 质量、表格结构还原、多版本文档的取舍、过期内容的标记。切分后要做抽样检查确认每个块语义完整、没有断裂。5.2 第二步搭建混合检索与重排链路检索链路建议按这个顺序搭文档切分入库同时建向量索引和关键词索引查询时两路并行召回融合去重再用重排模型对候选做精排取 top 若干条拼进上下文。参数上召回数量可以先设向量 top 20、关键词 top 20融合后取 top 30 进重排重排后取 top 5 到 8 进 prompt。这个数字不是固定的要根据实际效果调。重排模型选轻量级的保证延迟可控。5.3 第三步设计工具调用与兜底机制工具定义要清晰每个工具的名称、描述、参数都要写明白参数类型和是否必填要标注。调用前做参数校验调用时设超时和重试上限调用失败要有兜底回复而不是让对话卡死。编排层建议用成熟框架来搭比如 LangChain 这类能省不少重复工作。但要注意框架只是脚手架核心逻辑还得自己设计尤其是异常处理和状态管理。5.4 第四步压测与灰度上线上线前一定要做压测模拟真实并发观察响应时间、错误率、资源占用。压测能暴露性能瓶颈比如向量检索慢、模型推理排队、工具接口限流。灰度上线是必须的先放小流量观察真实用户的问题分布和失败案例持续迭代。我自己的经验是灰度阶段收集到的 bad case比演示阶段所有测试加起来都有价值。6. 常见问题与排查技巧实录6.1 高频问题速查表问题现象可能原因排查方向解决思路回答胡编检索召回错误内容检查召回结果优化切分和混合检索答“不知道”召回为空检查查询改写和索引加查询扩展、调召回数响应超时并发或链路慢分段计时加缓存、限流、异步工具调用失败参数错误或接口异常看调用日志参数校验、重试兜底多轮丢上下文状态管理缺失检查对话状态显式管理状态精确查询失手纯向量检索检查关键词召回上混合检索6.2 几个我踩过的坑第一个坑是过度依赖模型能力。早期我总想着换个更强的模型就能解决问题后来发现检索链路不修换什么模型都一样。第二个坑是忽视文档质量。知识库没清洗干净后面所有优化都是白费。第三个坑是没有兜底。任何环节失败都直接暴露给用户体验极差。第四个坑是演示思维。总想着把演示做漂亮却忘了生产环境是另一套逻辑。6.3 一个实用的排查顺序遇到上线效果差我一般按这个顺序排查先看召回召回对不对再看上下文拼进去的内容对不对再看工具调用有没有失败最后才看模型生成。这个顺序能覆盖大部分问题而且从前往后排查成本最低。7. 一些关于落地节奏的个人体会做企业智能体这几年我最大的体会是别把演示的成功当成系统的成功。演示是验证可行性上线是验证可靠性两者之间隔着一整套工程体系。大模型只是这套体系里的一个组件而且往往不是最脆弱的那个。另一个体会是落地节奏要稳。先把知识库和检索做扎实再上工具调用最后做多轮和复杂编排。每一步都验证过再往下走比一口气全上然后到处救火要快得多。我见过太多团队想一步到位结果每个环节都半成品上线后问题叠问题根本无从下手。最后分享一个小技巧上线前找几个完全不懂技术的业务同事让他们用真实问题去问智能体你在旁边记录。他们问出来的问题往往比你自己设计的测试用例更接近真实场景暴露的问题也更有价值。这个土办法比很多自动化测试都管用。 
长河君 · 2026/10/31 4:16:04 · 阅读 1.2k 企业智能体从演示到上线：RAG与Function-Calling工程避坑指南
1. 演示惊艳、上线就崩这个现象到底卡在哪做企业智能体这一行的人大概率都经历过同一个场景会议室里大屏上演示的智能体对答如流知识问答准确率看着能到九成领导点头业务方鼓掌项目顺利立项。结果一上线用户量一上来问题全冒出来了——回答开始胡编检索结果驴唇不对马嘴接口响应从两秒变成二十秒Function-Calling 调用失败率飙升最后业务方一句“还不如人工查文档”就把项目打进了冷宫。这个落差很多人第一反应是“大模型不行换个更强的”。我见过太多团队把预算砸在换模型上从开源换到闭源从小参数换到大参数结果上线还是崩。问题真不在大模型。大模型是那个站在台前表演的演员而决定这场戏能不能连演三百场的是后台的剧本、灯光、道具、场务——也就是知识库、检索链路、工具调用编排、状态管理这一整套工程体系。这篇内容我想聊的就是这件事企业智能体从演示到生产之间到底隔着哪些坑这些坑分别属于哪个环节以及每一个环节可以怎么补。核心关键词会围绕企业智能体、大模型、RAG、知识图谱、Function-Calling展开但重点不在概念科普而在“为什么演示能过、上线会崩”的工程归因。适合正在做企业智能体落地、被上线效果折磨过的工程师、产品经理和技术负责人看也适合刚接触 RAG 和智能体编排、想少走弯路的朋友。先把结论摆前面演示环境和生产环境本质上是两个不同的系统。演示环境是封闭、静态、低并发、人工兜底的生产环境是开放、动态、高并发、无人兜底的。你在演示环境里验证的是“模型能不能答对”在生产环境里要验证的是“整条链路在真实数据、真实流量、真实边界下能不能稳定答对”。这两件事的难度差了一个数量级而绝大多数团队只做了前者的验证。2. 演示环境与生产环境的本质差异拆解2.1 演示环境为什么总能“惊艳”演示环境的惊艳很大程度上是被设计出来的。我参与过不少项目的演示准备说句实在话演示用的知识库往往是精挑细选过的——文档格式统一、内容干净、没有扫描件、没有表格错位、没有互相矛盾的版本。问题也是提前设计好的问法标准答案唯一检索几乎不会失手。再加上演示时通常是单用户、低并发模型有充足的时间做多轮推理Function-Calling 调用的接口也是测试环境里最稳定的那几个。就算偶尔答错旁边还有个懂业务的工程师随时准备“补充说明”把话题圆回来。这种环境下智能体表现惊艳是正常的因为它面对的是一道被精心布置过的考题。问题在于很多团队把这种“考题环境”下的表现当成了系统能力的真实水平直接拿去承诺业务指标。这是后面所有崩溃的起点。2.2 生产环境的三重暴击数据、流量、边界生产环境对智能体的暴击我习惯归纳成三个维度。第一重是数据暴击。真实企业知识库是什么样PDF 扫描件、Word 老版本、Excel 里藏着关键参数、Confluence 页面半年没更新、同一个制度有三个版本在不同部门流传。你演示时用的那几十篇干净文档在真实知识库面前连零头都算不上。RAG 的检索质量直接取决于知识库的清洗和切分质量而这一步在演示阶段往往被跳过了。第二重是流量暴击。演示时一个请求慢慢跑生产时可能几十上百个请求同时进来。向量检索、重排、大模型推理、工具调用每一个环节都是资源消耗点。并发一上来响应时间指数级上升超时、限流、队列堆积接踵而至。很多智能体不是答不对是根本来不及答。第三重是边界暴击。演示时用户问的都是“正常问题”生产时用户会问各种你想不到的东西错别字、口语化表达、跨领域问题、恶意诱导、超长上下文。这些边界情况在演示里几乎不会出现但在生产里每天都在发生而它们恰恰是最容易让智能体翻车的场景。2.3 一个被忽视的事实瓶颈分布是长尾的我做过一个粗略的统计在一个典型的企业智能体系统里导致上线效果不达标的因素大模型本身的能力占比其实并不高。更多的失败集中在检索召回、知识组织、工具编排、上下文管理这些“非模型”环节。失败环节演示阶段暴露概率生产阶段暴露概率典型表现大模型基础能力高中答非所问、语言不通顺知识库质量低极高检索到过期/错误内容检索召回策略低高该召回没召回答“不知道”工具调用编排中高接口失败、参数错误、死循环并发与性能极低极高超时、限流、响应慢上下文管理低高多轮对话丢失关键信息这张表想说明的是演示阶段暴露的问题和生产阶段暴露的问题几乎不是同一批问题。你在演示里调优模型解决的是生产里占比不高的那部分而生产里真正致命的检索、编排、并发问题演示阶段根本测不出来。这就是“演示惊艳、上线就崩”的结构性原因。3. RAG 链路企业智能体最容易被低估的环节3.1 RAG 不是“接个向量库”那么简单很多人对 RAG 的理解停留在“文档切块、向量化、存库、检索、拼进 prompt”这五步。真做起来每一步都有大量决策点。文档怎么切按固定长度切还是按语义切表格和图片怎么处理检索用纯向量还是混合检索召回多少条要不要重排这些问题在演示阶段可以糊弄过去在生产阶段每一个都会变成事故。我见过一个项目知识库里有一批产品参数表切块时按固定 512 字符硬切结果一个参数被切成两半检索时永远只能召回半张表模型拿着半张表回答参数自然错。这种问题在演示时因为问题简单、文档少根本不会触发上线后用户一问具体参数就翻车。3.2 文档切分决定检索上限的隐形之手切分策略是 RAG 里最容易被忽视、却最影响上限的一环。我的经验是切分要跟着文档的语义结构走而不是跟着字符数走。对于结构化文档比如制度、手册、产品说明优先按标题层级切保证每个块是一个完整的语义单元。对于长段落文本可以用递归切分先按段落再按句子最后才按字符。对于表格要么整表保留要么转成结构化描述绝不能硬切。对于图片如果知识库需要存储图片内容得配合多模态能力或者 OCR 转文字纯文本 RAG 是处理不了图片语义的。提示切分块的大小没有万能值。块太小语义不完整块太大检索精度下降。我一般会先用 300 到 800 字符做基线再根据实际召回效果调整而不是一上来就定死。3.3 检索策略纯向量检索为什么经常失手纯向量检索擅长语义相似但对精确匹配、专有名词、编号类查询经常失手。用户问“工单编号 A12345 的处理流程”向量检索可能召回一堆“处理流程”相关的文档却漏掉那个真正包含编号的文档。生产环境里我强烈建议用混合检索向量检索负责语义召回关键词检索比如 BM25负责精确召回两路结果融合后再重排。这样既能接住口语化提问又能接住精确查询。重排环节可以用轻量级的交叉编码器模型把召回的前几十条重新打分排序显著提升 top 结果的准确率。3.4 知识图谱与本体建模让检索从“找相似”升级到“找关系”当企业知识存在大量实体关系时比如“某设备属于某产线、某产线由某部门负责、某部门适用某制度”纯 RAG 就很难处理这种多跳推理。这时候知识图谱和本体建模就派上用场了。本体建模的核心是把业务里的实体、属性、关系定义清楚形成一套 schema。比如定义“设备”“产线”“部门”“制度”这几类实体以及它们之间的归属、适用关系。有了本体知识图谱就能把散落在文档里的关系结构化检索时可以先定位实体再沿关系扩展回答“这台设备适用哪些制度”这类问题就稳得多。《知识图谱应用实践指南》里提到的思路很实用不要一上来就追求大而全的图谱先从业务最痛的那几个关系入手小步构建边用边补。我自己的做法是先做本体建模把核心实体和关系画出来再用工具生成可视化图谱验证关系是否合理最后才灌数据。3.5 RAG 瓶颈的真实来源召回质量而非模型能力回到那个核心判断RAG 的瓶颈绝大多数时候在召回不在生成。模型再强你喂给它的上下文是错的、过期的、不完整的它也变不出正确答案。所以优化 RAG优先优化召回链路文档清洗、切分策略、混合检索、重排模型这四步做到位效果提升往往比换模型明显得多。4. Function-Calling 与智能体编排演示能跑上线就乱4.1 Function-Calling 的本质是“让模型决定调什么”Function-Calling 让大模型能够根据用户意图决定调用哪个外部工具、传什么参数。演示时工具少、参数简单、调用路径清晰模型很容易做对。生产时工具可能有几十个参数有嵌套结构调用还涉及鉴权、重试、超时复杂度完全不是一个量级。我见过最典型的事故是模型在演示时能正确调用“查询订单”接口上线后因为参数里多了个可选字段没填接口直接报错而智能体没有兜底逻辑整个对话就卡死了。4.2 工具编排的三种常见翻车模式第一种是参数幻觉。模型会“脑补”参数尤其是当工具描述不够清晰时。比如接口需要“订单号”模型可能把用户说的“上周那个单子”直接当成订单号传进去。解决办法是把工具的参数描述写得极其明确并在调用前做参数校验。第二种是调用死循环。模型调用工具失败后可能反复重试同一个调用陷入死循环。必须在编排层设置最大重试次数和失败兜底策略。第三种是工具选择错误。工具一多模型容易选错。这时候可以给工具做分组或者用路由层先判断意图再限定候选工具范围降低选择难度。4.3 编排层才是智能体的“大脑”很多人把大模型当成智能体的大脑我觉得更准确的说法是大模型是语言理解和生成模块编排层才是真正的大脑。编排层负责决定什么时候检索、什么时候调工具、多轮对话怎么管理状态、失败怎么兜底。这部分做不好模型再强也白搭。一个稳健的编排层至少要包含意图识别、路由分发、工具调用管理、状态管理、异常兜底这几个模块。意图识别可以用小模型或者规则先做粗筛路由分发决定走 RAG 还是走工具工具调用管理负责参数校验和重试状态管理维护多轮上下文异常兜底保证任何环节失败都有合理回复。4.4 多轮对话的状态管理被低估的难点演示时通常是一问一答生产时用户会连续追问。“那它的保修期呢”“刚才说的那个流程再讲一遍”这些追问依赖上下文。如果状态管理做得粗糙多轮对话就会丢失关键信息模型只能重新检索效果和体验都差。我的做法是把对话状态显式管理起来记录当前话题、已确认的实体、已调用的工具和结果。每一轮把相关状态拼进上下文而不是把全部历史都塞进去。这样既保证连贯性又控制上下文长度。5. 从演示到上线的完整落地实操5.1 第一步用真实数据重建知识库上线前必须做的一件事是把演示用的“干净知识库”换成真实知识库。具体操作是拉取生产环境里真实的文档源做一次完整的清洗和切分统计文档类型分布、格式问题、版本冲突情况。这一步会暴露大量演示阶段看不到的问题越早做越好。清洗时重点关注扫描件 OCR 质量、表格结构还原、多版本文档的取舍、过期内容的标记。切分后要做抽样检查确认每个块语义完整、没有断裂。5.2 第二步搭建混合检索与重排链路检索链路建议按这个顺序搭文档切分入库同时建向量索引和关键词索引查询时两路并行召回融合去重再用重排模型对候选做精排取 top 若干条拼进上下文。参数上召回数量可以先设向量 top 20、关键词 top 20融合后取 top 30 进重排重排后取 top 5 到 8 进 prompt。这个数字不是固定的要根据实际效果调。重排模型选轻量级的保证延迟可控。5.3 第三步设计工具调用与兜底机制工具定义要清晰每个工具的名称、描述、参数都要写明白参数类型和是否必填要标注。调用前做参数校验调用时设超时和重试上限调用失败要有兜底回复而不是让对话卡死。编排层建议用成熟框架来搭比如 LangChain 这类能省不少重复工作。但要注意框架只是脚手架核心逻辑还得自己设计尤其是异常处理和状态管理。5.4 第四步压测与灰度上线上线前一定要做压测模拟真实并发观察响应时间、错误率、资源占用。压测能暴露性能瓶颈比如向量检索慢、模型推理排队、工具接口限流。灰度上线是必须的先放小流量观察真实用户的问题分布和失败案例持续迭代。我自己的经验是灰度阶段收集到的 bad case比演示阶段所有测试加起来都有价值。6. 常见问题与排查技巧实录6.1 高频问题速查表问题现象可能原因排查方向解决思路回答胡编检索召回错误内容检查召回结果优化切分和混合检索答“不知道”召回为空检查查询改写和索引加查询扩展、调召回数响应超时并发或链路慢分段计时加缓存、限流、异步工具调用失败参数错误或接口异常看调用日志参数校验、重试兜底多轮丢上下文状态管理缺失检查对话状态显式管理状态精确查询失手纯向量检索检查关键词召回上混合检索6.2 几个我踩过的坑第一个坑是过度依赖模型能力。早期我总想着换个更强的模型就能解决问题后来发现检索链路不修换什么模型都一样。第二个坑是忽视文档质量。知识库没清洗干净后面所有优化都是白费。第三个坑是没有兜底。任何环节失败都直接暴露给用户体验极差。第四个坑是演示思维。总想着把演示做漂亮却忘了生产环境是另一套逻辑。6.3 一个实用的排查顺序遇到上线效果差我一般按这个顺序排查先看召回召回对不对再看上下文拼进去的内容对不对再看工具调用有没有失败最后才看模型生成。这个顺序能覆盖大部分问题而且从前往后排查成本最低。7. 一些关于落地节奏的个人体会做企业智能体这几年我最大的体会是别把演示的成功当成系统的成功。演示是验证可行性上线是验证可靠性两者之间隔着一整套工程体系。大模型只是这套体系里的一个组件而且往往不是最脆弱的那个。另一个体会是落地节奏要稳。先把知识库和检索做扎实再上工具调用最后做多轮和复杂编排。每一步都验证过再往下走比一口气全上然后到处救火要快得多。我见过太多团队想一步到位结果每个环节都半成品上线后问题叠问题根本无从下手。最后分享一个小技巧上线前找几个完全不懂技术的业务同事让他们用真实问题去问智能体你在旁边记录。他们问出来的问题往往比你自己设计的测试用例更接近真实场景暴露的问题也更有价值。这个土办法比很多自动化测试都管用。