1. 自建AI平台的动机Agent编排、扩展机制与工程化缺口去年下半年我们团队在一个智能客服项目上吃了大亏。一开始大家信心满满觉得直接调模型API、写好Prompt就能交付。结果场景一铺开就崩了——工单分类、知识库问答、售后催办、语音转写后的意图判断每个业务线都在重复造轮子封装LLM调用、拼上下文、接工具、调参数。团队里每个人都在写一套自己的“胶水代码”换一个模型供应商要改十几个文件接一个新工具要写几百行适配逻辑。更头疼的是一旦Agent链路里加了一次工具调用整个链路的调试就开始变得很痛苦你根本不知道是哪一步让模型跑偏了。后来我们决定停下来认真思考一个根本问题大家反复在做的事情到底是什么答案是——把“模型能力”和“业务能力”对接起来的中间层。这个中间层要解决的不只是“调用模型”而是四件事Agent编排把多个模型调用、多个工具步骤、多次知识检索组织成一个有决策能力的执行图而不是一条写死的if-else链。多供应商适配不能让应用被某一家模型厂商绑死用户要能在不同模型之间按需切换、容灾、比价。统一扩展机制工具接入、技能封装、知识库挂载必须有一套标准而不是每次都由业务团队各写各的。工程化底座可观测性、版本管理、权限控制、性能优化这些“非功能需求”决定了一个AI应用能不能从Demo走向生产。XXL-AI这个平台的项目启动就是奔着这四件事去的。它不是又一个LangChain也不是一个IDE插件而是一个贴近业务侧AI应用的开发与运行底座。如果你所在的团队正在做Agent类应用或者在为“AI功能嵌入现有系统”发愁这篇文章里讲的很多设计取舍和踩坑经验应该能给你省下不少时间。我一直有个观点AI应用真正的护城河不是模型选得有多新而是你围绕模型搭建的这套工程体系有多稳。下面我把XXL-AI里的几个核心模块拆开讲说清楚每个模块解决了什么问题、为什么这么设计、落到地上有哪些坑。2. Agent编排引擎的核心取舍图模型、节点抽象与运行时控制2.1 为什么放弃链式编排选择图编排第一版编排引擎我们参考了当时最主流的做法——Chain。一条链路从头走到尾先调用模型A再把结果给模型B中间插几个工具调用。这个模式写起来确实简单但很快暴露出问题Agent的决策是动态的。同样一个用户问题有的需要查知识库有的需要调工具有的直接回答就行。用Chain写等于把所有可能性都铺成一条线要么全部执行一遍浪费资源要么在每个分支处写一堆条件判断代码越来越乱。图编排的核心区别在于把执行流程变成节点和边组成的DAG有向无环图节点是执行单元边是流转条件。每个节点执行完之后根据输出状态决定走哪条边。这天然支持分支、并行、回退和聚合也更贴近Agent“思考-行动-观察-再思考”的真实循环。XXL-AI的编排引擎采用的就是图模型。我们在界面上看到的每一条Agent流程最终都会编译成一个可执行的图定义。这个选择在两个月后的一次实战中得到了验证——当时要做一个“工单自动处置”Agent同一张工单根据不同置信度要走上报、自动答复、人工复核三条不同的路径图编排只需要在条件节点上配置三个出口就搞定了如果用Chain我估计要改三轮重构。2.2 节点类型怎么抽象才不过度设计图引擎的第一步是定义节点类型。这里有个常见的坑节点类型设计得太多拿着锤子找钉子设计得太少又约束不了复杂流程。我们经历了三轮迭代最后沉淀出七种足够用的节点节点类型作用典型使用场景LLM节点调用模型带System Prompt和输出解析生成回复、信息抽取、意图分类工具节点调用MCP/SKILL暴露出来的能力查询订单、写工单、发消息知识节点执行RAG检索返回知识片段问答时先查产品文档Agent节点嵌套调用子Agent递归编排主Agent把任务拆给专项Agent人工节点挂起流程等待人工审批/输入高额退款、敏感操作确认条件节点根据表达式选择出口分支置信度判断、字段值判断聚合节点并行执行多个分支后汇总结果同时查库存、查价格、查物流后再回复设计节点时有个原则每个节点只做一件事并明确输入输出结构。比如LLM节点的输出不能是“最终的文本”而是要解析成结构化字段比如{ reply: string, confidence: number }。只有结构化了后面的条件节点才能做判断下游节点才能拿到可靠的输入。2.3 运行时控制的三个关键机制图编排看起来只是流程引擎真正难的是运行时控制。我们实战中最容易翻车的是三件事上下文管理。Agent多轮调用模型时对话历史会不断膨胀。如果每轮都把全部历史丢给模型Token消耗会指数级上升模型还会被早期信息干扰。我们采用的策略是“滑动窗口总结压缩”最近N轮消息原样保留超过N轮的旧消息交给一个小模型做摘要摘要作为长期记忆挂载在上下文中。实测下来一个20轮的客服会话Token消耗能降低60%以上且回答质量没有明显下降。循环与死循环检测。Agent在处理复杂任务时偶尔会卡在“调用工具-得到结果-再调用工具”的循环里表面看没报错实际已经空转。我们从两个层面做防护一是最大迭代次数默认20次超限强制终止并上报二是工具调用指纹——把“工具名输入参数的关键字段”做一个哈希如果连续出现相同的指纹就判定为循环打断并引导模型换一条路径。超时熔断与重试策略。LLM接口偶尔会慢第三方工具偶尔会挂。每个节点都要配超时但超时时间不是拍脑袋定的。我们的经验法则是LLM节点看模型历史P95延迟乘以1.5倍再加5秒工具节点看MCP Server的约定超时默认10秒重试只对幂等操作开启写操作一律不自动重试避免重复下单或重复发送。2.4 实战例子多Agent协作生成一份周报拿一个我们内部每天都在跑的流程举例——多Agent协作生成周报。这个流程包含三个子Agent代码提交聚合Agent、指标统计Agent、文案生成Agent。主Agent收到“生成周报”指令后先并行触发前两个Agent一个通过Git MCP拉取本周提交记录一个查数据库统计系统关键指标。两个结果到达聚合节点后文案生成Agent拿到结构化数据再结合团队知识库里的周报模板SKILL生成初稿。最后挂一个人工节点由团队负责人在线确认或修改后发布到周知系统。这个流程如果不用图编排代码会非常难维护——三个子Agent的执行顺序、失败处理、结果格式校验全都要手写。用节点图描述后每次改动只需要在界面上增删节点、调整连线发布后即时生效。这也让我们意识到编排引擎不是帮你省掉代码而是帮你把复杂的并发和决策逻辑管理起来让维护者一眼看懂全局。3. 多供应商适配层模型中立架构、路由策略与成本治理3.1 为什么必须做供应商抽象层很多团队接入模型API时图省事直接在一个工具类里写死对某家厂商的请求。前期确实快但一旦业务量上来你会发现几个问题某家模型的限流策略让你被动某天接口升级导致兼容性问题或者出现了更便宜、效果更好的新模型想切换试试结果发现调用代码散落在一百多个文件里。我们做多供应商适配层核心就一个目的让模型变成可插拔的资源而不是绑死的依赖。3.2 以OpenAI兼容协议作为中间层的得与失第一版适配器我们天真地打算为每一家厂商写一套独立适配代码。后来发现这个工作量是永远做不完的——模型厂商的接口在变新厂商层出不穷。最终我们做了一个现实的选择把“OpenAI兼容协议”作为统一的内部门面。为什么选它因为目前主流的商业模型、开源推理框架比如本地部署的vLLM、Ollama几乎都提供了OpenAI兼容的HTTP接口。这样做的好处是新接入一个供应商往往只需要配置base_url、api_key、模型名零代码接入。损失是什么呢部分模型的特色参数会被磨平比如Claude的extended thinking、某些国产模型的JSON mode定制能力。我们的处理方式是协议层兼容能力层面透传——保留一个extra_params字段如果检测到模型名称和供应商支持特有能力就把参数透传进去。供应商抽象层还需要承担模型路由的职责。我们内部有一套基于轻量规则的默认策略默认对话优先使用性价比模型满足日常问答。复杂推理当任务分类器判定为数学、代码、多步规划时路由到旗舰模型。本地优先涉及敏感数据的场景强制路由到私有化部署的开源模型数据不出内网。降级策略主模型返回限流错误或连续超时自动切到备选模型并在响应头里标记x-model-routed便于排查。3.3 成本治理的务实做法多供应商意味着多重计费方式如果不做治理月底账单会让人措手不及。我们做了两层第一层是按节点计量。每次LLM调用都会记录输入Token、输出Token、模型单价然后换算成成本并归因到具体的Agent流程、业务线甚至具体用户。这样复盘时可以直接回答“智能客服这个Agent每万次会话消耗多少钱”。第二层是预算阈值控制。给每个业务线配置月成本阈值达到80%时告警达到100%时自动启用“省电模式”——把高成本模型降级为低成本模型关闭非关键Agent的非核心步骤。这个方法很土但在抢预算的年代特别管用。3.4 本地模型与云模型的混合部署最后提一句混合部署。我们有一些客户数据不能出内网但业务场景又需要AI能力。适配层在这块做了特殊处理同一个模型逻辑名可以指向两个物理实例——一个云端、一个本地。比如text-embedding-v3这个逻辑名在公网环境指向云端接口在内网环境指向本地的Embedding服务。业务代码完全无感知只需要在平台配置中心按环境注入不同的端点配置即可。4. MCP扩展机制从工具协议到Agent执行边界的实践4.1 MCP到底解决的是什么问题——一句话版本很多人问MCP到底是什么。我的回答是它是AI应用界的“USB-C接口标准”。回想硬件世界早期每台设备都有自己的充电口和协议后来USB-C统一了物理接口和通信协议设备即插即用。MCP做的事情类似——定义一个标准的“软件外设”协议让AI应用能够以统一方式发现、连接、调用外部工具和数据源。在MCP出现之前Agent接一个工具要做三件事写接口请求代码、把工具描述喂给模型、处理返回结果的格式差异。这三个步骤每个工具都要单独写一遍。而MCP把这三件事标准化了任何符合MCP协议的Server都可以通过标准接口暴露自己的工具、资源和提示词能力Agent只需要理解MCP协议就能操作所有已连接的工具。4.2 MCP Client端的工程落地细节XXL-AI的MCP接入层主要包含四个生命周期阶段连接初始化。启动时加载配置建立到MCP Server的长连接。传输层我们同时支持三种本地工具走stdio远程服务走SSE或WebSocketWSS。选择哪种传输取决于工具部署位置——比如Playwright MCP跑在本地测试机上用stdio最稳妥企业内部的工单系统通过服务端部署走SSE或WSS更合适。工具发现与注册。连接成功后拉取Server声明的工具列表把每个工具的名称、描述、输入Schema注册到Agent的可用工具表里。这里有个隐藏坑工具列表不能无条件全量注册。几十个工具同时注册会给模型带来选择困难还会增加Token消耗。我们的做法是按需注册——根据任务分类只注册该场景下可能用到的工具子集。调用与结果回传。Agent根据模型输出决定调用哪个工具传入参数。MCP Client负责把调用结果转成统一的文本或结构化数据放回上下文。对于返回内容特别大的工具比如数据库查询返回几千行需要做结果截断或摘要否则会撑爆上下文窗口。连接健康管理。长连接必然要面对断线、超时、Server重启。我们的策略是心跳检测自动重连同时对于关键工具在编排层做一个“工具不可用分支”比如查询库存工具挂了自动让Agent转用“缓存数据告知用户稍后更新”的兜底话术而不是让整条链路崩溃。4.3 接入Example通过MCP把浏览器操作交给Agent我们近期给一个自动化测试团队接入了浏览器自动化MCP服务基于Playwright的能力包装效果很直观。以前写端到端测试用例要手写一套脚本现在测试同学在Agent对话框里说一句“打开登录页用测试账号登录然后把首页的订单列表截图”Agent会自动调工具完成操作链。这件事背后的流程是LLM识别用户意图 → 选择浏览器自动化工具 → 第一步调用navigate到登录页 → 第二步调用fill填入账号密码 → 第三步调用click登录 → 第四步调用screenshot截取列表。每一步执行结果都回到上下文模型再决定下一步。这种场景如果不用MCP每个浏览器动作都要单独写一个函数给模型描述清楚维护成本极高。有了MCP之后工具侧只需要维护一个标准Server所有接入了MCP的Agent都能用。4.4 MCP落地避坑清单工具Schema要写得像API文档而不是散文。模型的参数填充能力依赖工具描述和属性定义的清晰度。某次我们的一个工单查询工具把描述写得含糊其辞模型经常漏传状态参数导致查询结果不对。改成结构化描述并补充示例后准确率明显提升。错误信息要“为模型设计”。工具调用失败时返回给模型的信息不能只有一个“Error 500”。我们规定MCP Server返回错误时必须包含错误类型、可能的修复建议、是否需要人工介入。比如“订单号不存在请检查订单号是否输入正确”模型看到后可以直接修正输入重试而不是对着“Internal Server Error”发呆。权限边界要提前规划。MCP工具通常拥有较高权限特别是数据库工具和文件工具。我们在接入层做了一层“工具权限标签”比如只读、写入、高危。只有当Agent编排定义里显式声明了权限等级且会话用户拥有对应授权工具才会被加载。这能防止“模型无意中删库”这种极端情况——哪怕概率极低也不能赌。5. SKILL技能系统把专家流程封装成可复用的资产5.1 SKILL和MCP工具、RAG知识库的本质区别MCP解决的是“能调什么”RAG解决的是“知道什么”那SKILL解决什么一句话解决‘知道怎么做’的问题。举个例子。同样是代码审查一个初级工程师和一个资深架构师做的事情差异非常大资深工程师会先看变更范围再按变更类型选择检查清单安全、性能、可读性最后输出结构化审查意见并给出改进建议。这个“做事的流程”本身就是宝贵的资产但它既不是一个工具也不是一段知识文档——它是一种可执行的经验流程。SKILL在XXL-AI里的定位就是把这个流程标准化、可执行化。有了SKILL专家团队沉淀的做事方法可以变成Agent能直接执行的资产业务团队不用重复造轮子。5.2 SKILL的定义结构与执行模型一个SKILL文件包含五个核心部分元信息名称、版本、作者、描述、触发条件。输入定义声明技能需要哪些结构化参数每个参数的类型、必填项、约束。前置校验执行前检查输入是否合法、依赖的资源是否存在。执行步骤一组有序的步骤每个步骤可以是LLM任务、工具调用、知识检索或子SKILL调用。输出规范定义技能输出必须包含的字段并约定输出的格式。执行引擎拿到SKILL定义后会一步步解释执行。每个步骤之间可以传递变量。比如代码审查SKILL第一步通过Git MCP获取变更文件列表第二步根据文件类型决定要不要调安全扫描工具第三步把变更内容和团队编码规范知识库片段一起喂给LLM节点第四步按checklist逐项检查最后生成结构化报告。这里有个核心工程原则步骤要小指令要具体尽量避免让LLM在一大段自由文本里摸索该做什么。我们把每个步骤都拆分到“单意图”的粒度每个步骤的指令如同一份精确的工单而不是一段散文。5.3 实战案例从零写一个“代码审查SKILL”我直接分享一个我们沉淀过的SKILL简化骨架你就明白这个东西和写Prompt的差别在哪了。第一步定义输入。这个技能接收repo,branch,commit_range三个参数。第二步获取变更内容——调用Git MCP的get_diff工具。第三步前置分类——用一个小模型判断变更属于前端、后端还是数据变更。第四步按类别挂载知识——如果是后端变更从RAG知识库检索“团队后端开发规范”和“常见安全漏洞清单”。第五步执行审查——把上述内容全部交给一个编码规范审查模型让它逐项比对并输出违规等级。第六步生成报告——把审查结果填入预设的Markdown模板输出为问题清单严重程度修改建议。这个SKILL发布后我们已经跑了四个月。它带来的最大改变不是“取代人工审查”而是把审查的第一步筛选自动化了。以前开发同学提交PR后至少得等一个下午才有反馈现在几分钟内能收到“阻塞性问题列表”修完再约人工深度review。整体效率提升非常明显。5.4 SKILL版本管理、组合与“去AI味”的描述SKILL是运行在LLM之上的资产它的描述直接影响模型能不能正确触发和使用。这里有个很有意思的热搜词叫“去AI味的skill”意思是很多人写的SKILL描述一看就像AI生成的——空泛、形容词堆砌、没有边界。好的SKILL描述应该是产品说明书风格什么条件用、什么条件不用、输入要求、输出承诺。我们内部要求每次发布SKILL时描述必须经过一个“能否三步看懂”自检看名称知道用途看描述知道触发场景看输入定义知道怎么传参。另外SKILL支持依赖和组合。一个“周报生成SKILL”依赖“Git提交汇总SKILL”和“指标查询SKILL”发布新版本时平台会自动检测依赖兼容性防止上层技能用到下层已变更的接口。6. RAG知识库集成从向量检索到混合检索、GraphRAG的演进6.1 直接Embedding向量检索是不够的我们最早做知识库问答思路很简单文档切块、Embedding入库、向量检索、拼Prompt。Demo阶段效果还行一上真实数据就露馅了。问题出在三个方面文本被强行切断。一段有逻辑关系的上下文被切成两个块检索时只命中一半回答自然残缺。无法处理实体关系。用户问“A产品对B场景的支持情况如何”如果B场景分散在多篇文档里向量检索很难把信息聚合出来。术语匹配的幼稚病。“容灾”和“灾备”语义相同但向量表示可能差异巨大。6.2 我们实践下来的RAG架构多路召回重排序摘要生成经历了几轮调优后我们把RAG链路改成了“多路召回重排序摘要生成”的经典架构。切块优化。块大小从固定的500字改成“按章节语义切块”。我们写了一个简单的分割器先按Markdown标题拆出章节章节过长再按段落拆段落再长才按固定长度打断。这样知识块大部分保持了语义完整性。针对表格和图片入知识库前要做处理表格转成Markdown或键值对文本图片用OCR抽文字、用视觉模型生成描述文本一并存储。多路召回。同一查询同时走三路向量检索、BM25关键字检索、以及基于实体关系的Graph遍历检索我们接入了轻量的图数据库保存文档中提取的实体与关系三元组。三路召回结果合并去重后统一用RRFRank Reciprocal Fusion打分。重排序。召回Top50候选后用一个CrossEncoder模型对“查询-文档块”做精排取Top3到Top5。这一步非常关键实测能让Hit Rate提升20个百分点以上。代价是增加了一些延迟我们通过缓存和并行推理做了补偿。结果合成。检索到的多个知识片段不能直接拼成上下文丢给生成模型否则模型会东拼西凑。我们增加了一个“摘要合成”步骤——用一个专门的LLM节点把多个知识片段的内容、来源、关系梳理成一段统一的上下文再交给最终的问答模型。6.3 知识库能存图片吗以及RAG评估指标很多人问“知识库能存图片吗”。答案是能但“存”和“能用”是两码事。如果只是把图片二进制塞进数据库检索时模型根本看不懂。正确做法是两层处理要么OCR成文字进向量库要么用多模态模型生成图片的语义描述文本然后把描述文本进向量库。用户在问答时检索回来的是“图片描述文本”需要看原图时可以返回图片路径。RAG的效果不能靠感觉要建立评估集。我们内部构建了一百多个真实业务问题的问答测试集标注了每个问题对应的标准知识片段。主要盯两个指标Hit Rate检索结果里包含正确片段的比率和MRR正确答案在结果列表中的平均排名。每次调整切块规则、重排序模型或Embedding模型都跑一遍这套测试集再决定是否上线。这比“看起来变聪明了”可靠得多。6.4 Agentic RAG让检索成为决策的一部分传统的RAG是固定的“检索-生成”两步走。但在真实Agent场景里Agent需要自己判断要不要检索什么时候检索检索结果够不够需不需要换一种方式再检索我们在XXL-AI里实践的是“Agentic RAG”——把知识检索变成一个可被Agent调用的能力节点而不是一个机械的预处理步骤。Agent会先自己评估问题是否有知识缺口如果需要它会发起第一轮检索如果发现结果不够具体它会改写查询词再检一轮如果发现答案需要跨多个主题它会并行发多个检索请求。这个模式在客服场景特别有效——用户的问题通常比较口语化直接拿原句去检索效果差Agent改写后再检准确率提升非常明显。7. 工程化底座落地要点可观测性、版本化与安全边界7.1 可观测性让Agent的每一次“思考”都有痕迹Agent应用调试难是因为模型的输出不确定你很难判断问题是出在Prompt写得不清楚、工具返回数据不对还是模型本身理解偏了。我们要求平台提供全链路追踪记录每一次LLM调用的请求参数、返回结果、Token消耗、耗时每一次工具调用的入参、出参、错误信息每一条边的流转条件判断结果。有了这些追踪数据我们才能回答“为什么这个工单被分错了类别”。打开Trace你能看到模型在意图分类节点输出了什么、置信度是多少、条件节点为什么走了误判分支。这个能力在线上排障时简直是救命稻草。7.2 业务资产的版本化与灰度发布Agent应用和传统应用有一个很大的差异它的业务逻辑分散在Prompt、SKILL、知识库、编排图这些“非代码资产”中。这些资产每天都在被修改如果都靠手工维护一定出乱子。我们的版本化策略是Prompt、SKILL、编排图都是可版本化的独立制品。每次修改生成一个新版本支持对比和回滚。发布Agent时锁定一组版本的“黄金组合”。比如客服机器人发布声明使用的编排图版本、SKILL版本、知识库版本保证一致性。支持灰度发布。新版本先让5%的流量体验用自动化评估集和人工抽检共同判断质量确认无误再全量。这比“改完直接上线”稳妥太多了。7.3 安全与合规上的两个最容易被忽略的坑数据隔离。如果一个平台同时服务多个业务线或多租户必须确保A业务线的知识库、工具调用记录不能被B业务线的Agent访问到。我们采用的是“租户项目”双层级空间隔离每一个Agent、每一个MCP连接、每一个知识库都归属于一个项目空间跨空间访问全部在底层拦截。敏感信息脱敏。LLM调用环节有一个天然风险业务数据在对话上下文中流转可能会在日志中留下敏感信息。我们在两个位置做脱敏入Prompt之前——手机号、身份证号、银行卡号用脱敏令牌替换出日志之后——对完整调用内容做KEY扫描发现敏感模式自动抹掉。注意脱敏令牌要保留“参与推理”的能力比如把138****1234变成138[PHONE]1234让模型知道前后文对应但不会记录完整号码。7.4 性能优化流式输出、语义缓存与并行化生产环境的Agent应用性能体验主要看三个指标首字延迟、完整响应时间、并发能力。我们做了三个针对性优化流式输出。所有面向用户侧的场景必须用SSE或WebSocket流式返回让用户先看到打字机效果而不是白屏等待。Agent中间过程比如“正在查询库存…”也可以作为事件流推给前端体感上快很多。语义缓存。对于高频且答案相对稳定的问题比如“发货时间是多久”我们加了一层语义缓存——把用户问题和历史问题的向量做相似度匹配超过阈值的直接复用之前生成的结果。注意只对只读场景启用。这个优化把客服机器人的响应延迟从平均3秒降到了0.8秒左右。并行执行。编排图上的多个独立节点可以并行调度。比如回答“这个订单什么时候到”时同时发起查物流接口、查库存接口、查配送政策知识库全部返回后再统一生成答案。聚合节点把三个结果合并后既保证了回答准确也把总耗时从三次串行调用压到一次最慢调用的耗时。8. 从部署到验收用XXL-AI跑通一个完整业务场景的复盘8.1 选定第一个落地场景工单智能处置助手我们第一个完整落地的场景是一个“工单智能处置助手”。业务背景是客服团队每天收到几千张客户工单需要先分类、再判断紧急程度、最后分派给对应处理组。之前靠人工效率低且标准不一。实际搭建步骤很简单先配置两个模型供应商一个旗舰模型负责复杂推理一个经济模型负责分类设置好路由规则然后画一条编排图接收工单 → 意图分类节点 → 置信度判断 → 高置信度走自动处置低置信度走人工复核接着接入客服系统MCP Server工单查询、历史沟通记录、创建工单等工具再写一个“投诉升级SKILL”用于识别高危投诉并自动触发优先处理流程最后把过往工单和知识库文档做RAG挂载。8.2 上线后踩过的三个大坑坑一上下文爆炸。客服会话动辄几十条消息全部塞进上下文模型开始“乱抓重点”。后来上了前面的滑动窗口总结压缩策略才把Token消耗和准确率拉回正常水平。坑二MCP工具返回字段过载。客服系统MCP返回的工单信息包含几十个字段模型处理起来容易迷路。我们的解决办法是在MCP Server和LLM之间加了一个字段裁剪封装按当前场景只保留关键字段其他字段藏在一个“展开详情”的后缀里需要时再查。坑三模型幻觉引用知识库。自动答复偶尔会编造“根据售后政策您可以享有XX权益”。排查发现是RAG召回的片段不够精准模型找不到依据就开始自由发挥。后来我们做了两层整改一是优化重排序提高正确知识片段的命中率二是在LLM节点指令里明确要求“若没有检索到对应的知识片段必须回答‘该问题需要人工核实’”把幻觉概率压到可接受范围。8.3 验收结果和我的心得上线运行八周后我们统计了几个数字工单分类准确率从人工时期的88%提升到93%平均分派时长从小时级降到分钟级高危投诉的识别率提升了近40%。更重要的是这个流程的可维护性变得非常好——后续加一种新工单类型只需要在SKILL里增加一个分支或者补充一批知识库文档不再需要动主流程代码。回顾整个落地过程我最大的体会是AI应用平台的价值不在于“模型跑得有多快”而在于把Agent编排、工具接入、知识挂载和工程治理这四件事做成了可复用的基础设施。真正复杂的业务逻辑最终是通过SKILL的沉淀和RAG知识库的持续积累来体现的而平台负责让这些资产稳定、可控地运行。最后分享一个实践细节我们给平台接了一个新的数据源时总会先做一个“最小可行验证”——只接一个工具、配一条最简单的流程、跑通一次端到端调用确认协议层没有问题了再往生产环境上堆复杂逻辑。这个习惯让我们避开了很多不必要的返工也推荐你试试。