过去两年企业里搞AI最尴尬的往往不是模型能力不够而是模型根本走不进业务流。你手上有GPT级别的大模型有几千份内部文档还有一堆等智能化的业务系统但连不起来每个部门自己接API、自己搭知识库、自己写Prompt最后变成一堆新的“AI烟囱”。我这边从0到1落地过一套企业级AI中台核心就是标题里那四样东西模型、知识库、Agent、业务系统。这篇把整个架构的拆解思路、选型理由、实操细节和踩坑记录都整理出来主要给正在做企业AI基础设施的工程师和技术负责人参考产品经理也可以拿去做需求沟通的底稿。不聊PPT式的宏大叙事只讲怎么落地。1. 项目概述与架构整体拆解1.1 企业AI中台到底解决什么问题先说最直接的痛点没有中台的时候AI能力在组织里是“散装”的。销售团队自己买一个AI写作工具运营团队让人开发了一个聊天机器人研发团队偷偷用自己的Key调API财务那边又有独立的知识库。结果就是模型五花八门知识不互通安全没人管费用更是糊涂账。AI中台做的事情是把这些能力收编成统一的公共服务。模型不再是你直接对着厂商API调用而是通过公司内部的模型网关访问知识库不再分散在各团队网盘里而是有统一的数据接入、清洗、向量化管道Agent不再是一个人一个样而是有标准框架可以编排工具、控制权限。业务系统只需要对接中台暴露的API不需要关心底层是哪个模型、知识存在哪里。听起来像是在增加一层复杂度但实际落地之后最大的收益反而不是省钱而是“可演进”。你换了一个更强的模型业务方无感新增了一个知识库所有Agent都能立刻用安全审计有统一的日志出口。这种东西在早期看不出效果等到AI系统铺到十几个部门的时候没有中台就等于给自己埋雷。1.2 四层架构怎么划分我把整个中台分成四个核心层外加两个横切能力。四个核心层分别是模型平台、知识库平台、Agent编排层、业务集成层。模型平台在最底部负责统一接入各种大语言模型包括云厂商的API、开源模型私有化部署甚至是微调过的行业模型。这一层对外暴露一套统一的对话API和embedding API业务方不需要知道背后是哪个模型只需按统一格式传参数。知识库平台做的是“企业记忆”。它负责从各个业务系统、文件系统、网页、甚至IM会话中采集数据经过清洗、切分、向量化之后存进向量数据库和全文索引。RAG检索增强生成就是基于这层实现的。Agent编排层在模型和知识库之上负责把大模型变成能使用工具的智能体。这一层定义Agent的规划逻辑、工具调用规范、记忆管理机制还要处理多轮对话中的状态持久化。它不是简单调一次API而是一段可能持续几分钟的流程。业务集成层是把AI能力嵌入到具体业务系统里的桥梁。工单系统、CRM、审批流、企业微信、钉钉都通过这层接入。这层往往最不被重视但实际实施时90%的体力活都在这里因为每个业务系统的认证方式、数据结构、接口风格都不一样。横切能力是安全和可观测性。所有进来的请求和出去的响应都要做权限校验、内容过滤、日志留痕所有模型调用、知识检索、Agent运行都要有监控指标和链路追踪。没有这两个能力中台上线第一天就会被安全和运维团队喊停。1.3 选型原则自研、开源还是商业化中台最容易犯的错就是“什么都要自研”。我见过一个团队花了三个月自己写了一套模型网关实现的功能开源项目早就已经有了还写得没人家好。选型这件事我的原则很简单路由、限流、鉴权这类基础能力优先用成熟框架不要自研。你可以基于LiteLLM或者Higress这类API网关扩展它们对OpenAI兼容格式的支持已经很完善。知识库管道可以直接用Dify、RAGFlow、FastGPT这类开源项目。这类项目把文档解析、切分、向量化、检索、RAG编排都串好了团队只需要在此基础上做数据接入和调优。Agent编排框架优先选LangGraph或Dify工作流这类有可视化状态管理能力的东西别自己从零写ReAct循环。自己写很容易忽略状态恢复和工具调用的边界情况。真正值得自研的是和内部业务深绑定的部分比如统一身份认证对接、业务系统数据模型映射、企业内部权限体系的继承。这些外部产品做不好也只能自己做。这样分的好处是每一层都能用社区里最成熟的那部分也保留了中台最需要的统一管控入口。很多团队总觉得自己情况特殊非要自研最后连MVP都跑不通。记住中台的核心是“整合”而不是“发明”。2. 模型平台统一网关与管理2.1 模型接入统一与多模型路由模型网关是整个中台的入口所有向上层暴露的模型能力都从这里走。第一步就是把各种模型封装成统一的OpenAI兼容接口内部再按模型厂商做适配。多模型路由是我强烈建议一开始就做的能力。不要只接一个模型哪怕你觉得某家模型特别好。因为模型升级、价格调整、稳定性波动都是常态你要有随时切换的能力。路由策略可以按场景、按用户、按成本优先级来配。举个例子我们当时把内部场景分了三类复杂推理类比如代码生成、文书理解走高端模型日常问答、摘要类走性价比模型大批次离线任务走最便宜的模型甚至本地的开源小模型。网关里配置了优先级规则主模型不可用时就降级到次选模型业务侧无感。路由的配置尽量做成动态的不要写死在代码里。我们用的方案是把路由规则放在配置中心模型服务商可以设置权重。比如默认线上流量按70%和30%分给两个模型灰度一期新模型时就调整这个比例观察业务反馈和成本变化再逐步放量。2.2 关键参数上下文长度、温度与并发控制统一网关不只是转发请求还要负责参数的规范化和控制。各家的模型对参数支持不一样有的支持temperature有的走top_p但上层业务不需要关心这些差异网关要把业务层的通用参数翻译成对应模型的参数。上下文长度是最容易踩坑的地方。业务方经常以为把整份文档塞进Prompt里就行结果模型直接报超长错误或者前面重要信息被截断。我们在网关层做了上下文管理超过模型支持长度时支持截断或者转为检索式压缩也会提示业务方改用知识库方案而不是硬塞上下文。温度和topp这类采样参数建议网关层设置默认值。对话场景默认temperature0.7抽取和分类场景默认temperature0.1甚至temperature0。如果不做默认值每个业务方都会凭感觉乱调最后效果不可复现。并发控制是模型网关的命门。大模型接口的响应速度很慢单个流式请求占用连接时间很长业务方如果不做并发限制很容易把后端模型服务打满。网关层要做三件事一是全局限流每秒钟允许通过多少请求超额排队或拒绝二是用户级配额避免某一个部门刷爆共享资源三是自动重试遇到429限流或超时要带指数退避地重试。这里有个并发估算的参考公式如果目标接口QPS是10每次生成平均耗时为15秒那模型服务的稳态并发至少需要10×15150个并发槽位。实际还得留30%的冗余也就是要考虑200个并发网关的队列长度也按这个来设计。很多团队前期只按API的TPS来配完全没算上生成时长一上线就雪崩。2.3 模型安全与审计模型层最容易忽略的是安全。直接面向业务提供大模型能力意味着Prompt注入、敏感数据泄露、恶意内容生成变成真实威胁。Prompt注入是最常见的。你没法防止每个业务方都在Prompt里加入“忽略之前所有指令”这类攻击所以网关层必须做输入检测和输出过滤。我们接了两层防护第一层是一个小模型做意图分类识别明显恶意的输入第二层是对输出做敏感词和合规过滤过滤不了的生成请求就打回重问同时在审计日志里记录。模型中毒的问题在引入外部微调模型或者开源模型时要特别注意。你有没有想过这个“开源模型”是不是真的安全供应链攻击已经出现过去下载了一个看似正常的模型权重实际在特定Prompt下会执行恶意行为的情况。所以模型文件要做产线校验模型上线前要做对抗性测试不能直接拿社区里的模型就在生产环境跑。审计方面模型网关必须记录每一次请求的完整上下文包括用户身份、业务系统标识、输入的文本、输出结果、模型版本、耗时和费用。这些日志不仅是排查问题用的也是满足企业内部数据合规要求的凭证。3. 知识库建设从数据到RAG3.1 数据接入与清洗知识库是中台里工作量最大的一部分因为企业数据永远是脏的、乱的、散在各处的。先看数据来源。最常见的有PDF、Word、网页、数据库导出、IM聊天记录还有一个被问得特别多的微信公众号文章。很多企业内部的制度、通知、技术文档都是发在公众号里的这些内容要进知识库通常走两条路一是通过公众号提供的接口主动拉取历史文章二是用合规的浏览器插件或脚本把文章另存为HTML或Markdown再导入。后者更常用但要注意版权和授权范围企业内部资料问题不大对外部内容要谨慎。数据清洗的重点是去重和格式统一。同一份文档可能在系统里存了多个版本如果不做去重检索结果就会被重复内容刷屏。我们用内容哈希加标题相似度做去重一轮跑下来能减少三成左右的垃圾数据。格式转换也是个坑尤其是PDF。扫描版PDF必须先OCR直接解析会让你得到一堆空格和乱码。Word和PPT解析出的内容有很多导航文字、页眉页脚需要规则过滤。我的建议是统一转成Markdown格式再进入下游这样切分的时候能利用标题结构。3.2 文档切分、向量化与检索召回切分直接决定RAG效果。切太小单个片段缺乏上下文切太大检索回来的片段包含大量无关内容稀释掉答案信息。我们实践下来的经验是普通技术文档用256到512个字符做主chunk重叠设置在64个字符左右有清晰结构的文档优先按Markdown标题切分保持章节完整。重叠的作用是避免一句话正好被切在边界上导致语义断裂。向量化模型同样很关键。如果企业内部以中文为主推荐用BAAI/bge-m3或者text2vec-large-chinese这类中文友好的embedding模型。商用方案也可以用OpenAI的text-embedding-3-small但要注意文本长度限制和向量维度成本。检索不能只靠向量。向量召回擅长语义匹配但对于精确的编号、人名、型号这些关键词很不友好。我们采用了混合检索向量召回加BM25全文召回两路结果用Reciprocal Rank Fusion做融合最后再接一层rerank模型。前面召回一版取50条rerank之后保留Top 5送到大模型生成。这样既保证语义召回率也避免精确匹配被漏掉。3.3 RAG效果调优与质量评估很多人把知识库搭好就以为完事了但面对真实业务问题首版效果通常惨不忍睹。RAG的调优必须建立在评估上。我建议团队先准备两三百道真实业务问题配上标准答案做成评测集。每次改检索参数、换embedding模型、改Prompt都拿评测集跑一遍用三个指标看效果召回率检索到的片段是否包含答案、答案相关度大模型有没有答非所问、忠实度答案是否忠于检索片段有没有编造。调优的顺序有讲究先调检索再调生成。检索阶段主要看切分大小、检索Top K数量、重排模型类型生成阶段主要看Prompt模板设计、是否让模型“在找不到答案时明确说不知道”、是否需要注入角色和格式要求。有一个比较隐蔽的问题是知识冲突。同一问题在不同文档里有不同说法检索回来的Top 5片段可能互相矛盾大模型就会“取平均值”胡编出一个答案。这种情况单靠模型不行需要在知识库层面做权威源标记把制度文件、官方文档设置成高优先级检索结果按权威性加权同时在Prompt里告诉模型要优先采用高权重的文档。4. Agent编排从单点到流程4.1 Agent框架与核心概念Agent的复杂度比普通的RAG问答高一个档次。普通RAG是“检索一次回答一次”Agent则是让模型自己决定调用什么工具、按什么顺序调用甚至还要根据结果重新决策。我把Agent拆成五个部分大模型大脑、规划器、工具集、记忆模块、状态管理。规划器可以简单到“先调工具A再调工具B”的固定流程也可以复杂到让模型自主写计划像ReAct循环那样“思考-行动-观察”反复迭代。选型上我推荐直接用LangGraph或者Dify的工作流模式。LangGraph适合开发能力强、需要精细控制状态的团队Dify适合快速搭建、业务流程相对标准的团队。两者都支持把Agent流程可视化调试的时候能看到模型走到了哪一步、调用什么工具、返回什么结果比自己在代码里打日志强太多。工具调用是Agent的命根子。所有能暴露给Agent的业务能力都要包成工具接口比如查工单、查库存、写SQL、调用内部API。工具接口要遵循统一的Schema描述包括输入参数、输出格式、错误类型。这里最容易被忽略的是工具文档质量工具描述写得不清楚模型就会乱传参数。尽量用自然语言把“这个工具是干什么的、什么时候用、参数怎么填”写明白。4.2 Agent并发与稳定性设计Agent遇到的最大工程问题是耗时和并发。一个简单Agent调用可能20秒一个涉及多轮工具调用的复杂Agent可能要几分钟。这比普通API请求长了一个量级对稳定性带来很大压力。首先必须做异步化。业务系统不能像调用普通接口一样同步等Agent执行完要改成提交任务、返回任务ID、通过Webhook或轮询拿结果的方式。我们用的是任务队列加工作节点Agent任务进消息队列多个Worker消费执行执行状态和结果存进数据库。其次是Agent的幂等和重试。因为Agent执行过程中可能因为模型超时或工具异常中断重试时不能重复提交外部操作。比如Agent已经给客户发了通知邮件结果网络异常重试一遍就发了两次。解决办法是给工具调用加幂等键每个源自同一个Agent运行的调用共享同一个ID外部系统通过这个ID做去重。再次是并发数要跟底层模型网关匹配好。一个Agent流程会调用多次模型接口如果你允许100个Agent任务并发每个任务平均调用5次模型那瞬间模型网关要承受500个并发请求。前面说的模型网关限流一定要和Agent调度层的并发参数一起规划否则Agent会把模型打崩。4.3 Agent与业务系统的集成模式Agent如果不跟业务系统打通就是个高级聊天机器人。真正的价值是把AI嵌入业务流程。我见过的集成模式有三种按复杂度递增排列第一种是最简单的API嵌入。业务系统在某个功能点比如填写表单调用Agent接口Agent返回生成内容用户在UI里确认后使用。这个模式适合辅助写作、内容总结、文本润色。第二种是事件驱动集成。Agent订阅业务系统的事件流比如“新工单创建”“订单状态变更”一旦触发就自动执行预设流程。这个适合自动化场景比如自动分单、自动回复、异常检测。第三种是人工审核闭环。Agent生成结果但关键动作必须经过人审批后才执行Agent和审批流深度绑定。比如系统自动生成采购申请、拟定合同条款提交给指定负责人审批。这种模式最容易让业务方放心落地阻力也最小。在具体工程上推荐把所有对外集成都收敛到中台统一暴露的OpenAPI业务系统只通过这个接口访问Agent能力。认证用OAuth或企业内部SSO继承权限模型尽量复用业务系统已有的角色权限不要搞一套新的权限体系否则光权限梳理就能拖垮一个迭代。5. 落地实战与排障经验5.1 一个典型场景从模型到业务闭环拿我们做过的一个“企业内部知识助手”来说完整链路可以拆成几步。业务系统是企业微信/钉钉里的集成机器人员工随时可以提问。请求到达中台后第一站是身份鉴权解析出用户所在部门和权限范围决定他能查询哪些知识库。然后请求进入大模型网关通过路由策略选一个适合对话的模型同时把该用户的短期记忆最近几轮对话的摘要拼进上下文。这里我们用了混合检索取回相关文档片段经过rerank之后和用户问题一起组装成最终Prompt。大模型生成时开启了流式输出用户侧能实时看到逐字返回的效果。整个回答结束之后日志系统会把问题、检索到的文档ID、模型答案、用户反馈全部落库。这个链路看起来不复杂但每个环节都回答了一个关键问题身份权限决定了知识库的范围知识库决定了上下文的内容模型决定了回答的流畅度业务集成决定了答案如何触达用户。任何一个环节掉链子用户感知都非常明显。5.2 常见问题与排查速查表我把实际运维中遇到的高频问题整理成一张速查表排查前可以先对照一下现象可能原因排查方式业务方反馈答案质量突然下降模型网关路由权重变化或模型版本更新查网关日志看请求用的是哪个模型和版本知识库检索结果明显不相关数据管道没有跑完新文档没进索引查知识库索引任务状态确认数据采集、切分、向量化的完整度某用户/某部门请求一直失败用户级配额或权限配置错误查身份鉴权日志和配额策略确认该用户的授权范围Agent任务执行到一半卡住工具调用超时或者模型响应超时查Agent状态机检查对应工具的超时配置和错误返回模型网关大量429报错并发配额不足根据接口平均耗时和QPS重新估算并发需求大模型开始编造不存在的制度条款知识库检索到的上下文不足或Prompt未强调说“不知道”检查检索召回数量、混合检索策略、生成Prompt的忠实度约束知识库构建任务总是“排队中”向量化服务的并发能力不足任务队列堆积查embedding服务的并发数和任务队列长度必要时扩容这张表的思路是先判断问题出在输入。比如用户问的问题是不是本身就无法从知识库回答再看检索效果最后才怀疑模型生成。很多时候排查的顺序反了一上来就换Prompt结果问题出在数据没同步。5.3 我藏到最后的心得最后说点个人体会。我踩过最大的坑就是把技术栈先定下来再去套业务。做中台一定是从具体场景反推的。你先找两三个业务方愿意深度配合的场景把端到端跑通再去抽象模型网关、知识库这些通用能力。否则纯做平台做得再漂亮业务方不买单最后就是个自娱自乐的产物。另一个心得是“反馈闭环”特别重要。中台刚上线的时候模型回答错了大家只会觉得AI不行而且没有人知道实际效果如何。我们后来在业务UI上加了一个“这个答案是否有用”的反馈按钮所有反馈都沉淀到日志系统里再定期抽出来做成评测集。三个月之后RAG和Prompt迭代的效果评估才真正有了依据AI中台的复盘才算进入正轨。内容扩展方面这个中台的下一步是做Agent能力和评测体系的标准化以及让知识库支持更多元的数据结构比如把表格和时序数据也纳入进来。但这些都是后话先把当前的业务闭环稳住远比追求架构上的完美更重要。这篇写到的所有模块基本都是可以照着落地的。如果你也在做类似的企业级AI中台有一两句话能让你少踩一个坑就算没白写。
过去两年企业里搞AI最尴尬的往往不是模型能力不够而是模型根本走不进业务流。你手上有GPT级别的大模型有几千份内部文档还有一堆等智能化的业务系统但连不起来每个部门自己接API、自己搭知识库、自己写Prompt最后变成一堆新的“AI烟囱”。我这边从0到1落地过一套企业级AI中台核心就是标题里那四样东西模型、知识库、Agent、业务系统。这篇把整个架构的拆解思路、选型理由、实操细节和踩坑记录都整理出来主要给正在做企业AI基础设施的工程师和技术负责人参考产品经理也可以拿去做需求沟通的底稿。不聊PPT式的宏大叙事只讲怎么落地。1. 项目概述与架构整体拆解1.1 企业AI中台到底解决什么问题先说最直接的痛点没有中台的时候AI能力在组织里是“散装”的。销售团队自己买一个AI写作工具运营团队让人开发了一个聊天机器人研发团队偷偷用自己的Key调API财务那边又有独立的知识库。结果就是模型五花八门知识不互通安全没人管费用更是糊涂账。AI中台做的事情是把这些能力收编成统一的公共服务。模型不再是你直接对着厂商API调用而是通过公司内部的模型网关访问知识库不再分散在各团队网盘里而是有统一的数据接入、清洗、向量化管道Agent不再是一个人一个样而是有标准框架可以编排工具、控制权限。业务系统只需要对接中台暴露的API不需要关心底层是哪个模型、知识存在哪里。听起来像是在增加一层复杂度但实际落地之后最大的收益反而不是省钱而是“可演进”。你换了一个更强的模型业务方无感新增了一个知识库所有Agent都能立刻用安全审计有统一的日志出口。这种东西在早期看不出效果等到AI系统铺到十几个部门的时候没有中台就等于给自己埋雷。1.2 四层架构怎么划分我把整个中台分成四个核心层外加两个横切能力。四个核心层分别是模型平台、知识库平台、Agent编排层、业务集成层。模型平台在最底部负责统一接入各种大语言模型包括云厂商的API、开源模型私有化部署甚至是微调过的行业模型。这一层对外暴露一套统一的对话API和embedding API业务方不需要知道背后是哪个模型只需按统一格式传参数。知识库平台做的是“企业记忆”。它负责从各个业务系统、文件系统、网页、甚至IM会话中采集数据经过清洗、切分、向量化之后存进向量数据库和全文索引。RAG检索增强生成就是基于这层实现的。Agent编排层在模型和知识库之上负责把大模型变成能使用工具的智能体。这一层定义Agent的规划逻辑、工具调用规范、记忆管理机制还要处理多轮对话中的状态持久化。它不是简单调一次API而是一段可能持续几分钟的流程。业务集成层是把AI能力嵌入到具体业务系统里的桥梁。工单系统、CRM、审批流、企业微信、钉钉都通过这层接入。这层往往最不被重视但实际实施时90%的体力活都在这里因为每个业务系统的认证方式、数据结构、接口风格都不一样。横切能力是安全和可观测性。所有进来的请求和出去的响应都要做权限校验、内容过滤、日志留痕所有模型调用、知识检索、Agent运行都要有监控指标和链路追踪。没有这两个能力中台上线第一天就会被安全和运维团队喊停。1.3 选型原则自研、开源还是商业化中台最容易犯的错就是“什么都要自研”。我见过一个团队花了三个月自己写了一套模型网关实现的功能开源项目早就已经有了还写得没人家好。选型这件事我的原则很简单路由、限流、鉴权这类基础能力优先用成熟框架不要自研。你可以基于LiteLLM或者Higress这类API网关扩展它们对OpenAI兼容格式的支持已经很完善。知识库管道可以直接用Dify、RAGFlow、FastGPT这类开源项目。这类项目把文档解析、切分、向量化、检索、RAG编排都串好了团队只需要在此基础上做数据接入和调优。Agent编排框架优先选LangGraph或Dify工作流这类有可视化状态管理能力的东西别自己从零写ReAct循环。自己写很容易忽略状态恢复和工具调用的边界情况。真正值得自研的是和内部业务深绑定的部分比如统一身份认证对接、业务系统数据模型映射、企业内部权限体系的继承。这些外部产品做不好也只能自己做。这样分的好处是每一层都能用社区里最成熟的那部分也保留了中台最需要的统一管控入口。很多团队总觉得自己情况特殊非要自研最后连MVP都跑不通。记住中台的核心是“整合”而不是“发明”。2. 模型平台统一网关与管理2.1 模型接入统一与多模型路由模型网关是整个中台的入口所有向上层暴露的模型能力都从这里走。第一步就是把各种模型封装成统一的OpenAI兼容接口内部再按模型厂商做适配。多模型路由是我强烈建议一开始就做的能力。不要只接一个模型哪怕你觉得某家模型特别好。因为模型升级、价格调整、稳定性波动都是常态你要有随时切换的能力。路由策略可以按场景、按用户、按成本优先级来配。举个例子我们当时把内部场景分了三类复杂推理类比如代码生成、文书理解走高端模型日常问答、摘要类走性价比模型大批次离线任务走最便宜的模型甚至本地的开源小模型。网关里配置了优先级规则主模型不可用时就降级到次选模型业务侧无感。路由的配置尽量做成动态的不要写死在代码里。我们用的方案是把路由规则放在配置中心模型服务商可以设置权重。比如默认线上流量按70%和30%分给两个模型灰度一期新模型时就调整这个比例观察业务反馈和成本变化再逐步放量。2.2 关键参数上下文长度、温度与并发控制统一网关不只是转发请求还要负责参数的规范化和控制。各家的模型对参数支持不一样有的支持temperature有的走top_p但上层业务不需要关心这些差异网关要把业务层的通用参数翻译成对应模型的参数。上下文长度是最容易踩坑的地方。业务方经常以为把整份文档塞进Prompt里就行结果模型直接报超长错误或者前面重要信息被截断。我们在网关层做了上下文管理超过模型支持长度时支持截断或者转为检索式压缩也会提示业务方改用知识库方案而不是硬塞上下文。温度和topp这类采样参数建议网关层设置默认值。对话场景默认temperature0.7抽取和分类场景默认temperature0.1甚至temperature0。如果不做默认值每个业务方都会凭感觉乱调最后效果不可复现。并发控制是模型网关的命门。大模型接口的响应速度很慢单个流式请求占用连接时间很长业务方如果不做并发限制很容易把后端模型服务打满。网关层要做三件事一是全局限流每秒钟允许通过多少请求超额排队或拒绝二是用户级配额避免某一个部门刷爆共享资源三是自动重试遇到429限流或超时要带指数退避地重试。这里有个并发估算的参考公式如果目标接口QPS是10每次生成平均耗时为15秒那模型服务的稳态并发至少需要10×15150个并发槽位。实际还得留30%的冗余也就是要考虑200个并发网关的队列长度也按这个来设计。很多团队前期只按API的TPS来配完全没算上生成时长一上线就雪崩。2.3 模型安全与审计模型层最容易忽略的是安全。直接面向业务提供大模型能力意味着Prompt注入、敏感数据泄露、恶意内容生成变成真实威胁。Prompt注入是最常见的。你没法防止每个业务方都在Prompt里加入“忽略之前所有指令”这类攻击所以网关层必须做输入检测和输出过滤。我们接了两层防护第一层是一个小模型做意图分类识别明显恶意的输入第二层是对输出做敏感词和合规过滤过滤不了的生成请求就打回重问同时在审计日志里记录。模型中毒的问题在引入外部微调模型或者开源模型时要特别注意。你有没有想过这个“开源模型”是不是真的安全供应链攻击已经出现过去下载了一个看似正常的模型权重实际在特定Prompt下会执行恶意行为的情况。所以模型文件要做产线校验模型上线前要做对抗性测试不能直接拿社区里的模型就在生产环境跑。审计方面模型网关必须记录每一次请求的完整上下文包括用户身份、业务系统标识、输入的文本、输出结果、模型版本、耗时和费用。这些日志不仅是排查问题用的也是满足企业内部数据合规要求的凭证。3. 知识库建设从数据到RAG3.1 数据接入与清洗知识库是中台里工作量最大的一部分因为企业数据永远是脏的、乱的、散在各处的。先看数据来源。最常见的有PDF、Word、网页、数据库导出、IM聊天记录还有一个被问得特别多的微信公众号文章。很多企业内部的制度、通知、技术文档都是发在公众号里的这些内容要进知识库通常走两条路一是通过公众号提供的接口主动拉取历史文章二是用合规的浏览器插件或脚本把文章另存为HTML或Markdown再导入。后者更常用但要注意版权和授权范围企业内部资料问题不大对外部内容要谨慎。数据清洗的重点是去重和格式统一。同一份文档可能在系统里存了多个版本如果不做去重检索结果就会被重复内容刷屏。我们用内容哈希加标题相似度做去重一轮跑下来能减少三成左右的垃圾数据。格式转换也是个坑尤其是PDF。扫描版PDF必须先OCR直接解析会让你得到一堆空格和乱码。Word和PPT解析出的内容有很多导航文字、页眉页脚需要规则过滤。我的建议是统一转成Markdown格式再进入下游这样切分的时候能利用标题结构。3.2 文档切分、向量化与检索召回切分直接决定RAG效果。切太小单个片段缺乏上下文切太大检索回来的片段包含大量无关内容稀释掉答案信息。我们实践下来的经验是普通技术文档用256到512个字符做主chunk重叠设置在64个字符左右有清晰结构的文档优先按Markdown标题切分保持章节完整。重叠的作用是避免一句话正好被切在边界上导致语义断裂。向量化模型同样很关键。如果企业内部以中文为主推荐用BAAI/bge-m3或者text2vec-large-chinese这类中文友好的embedding模型。商用方案也可以用OpenAI的text-embedding-3-small但要注意文本长度限制和向量维度成本。检索不能只靠向量。向量召回擅长语义匹配但对于精确的编号、人名、型号这些关键词很不友好。我们采用了混合检索向量召回加BM25全文召回两路结果用Reciprocal Rank Fusion做融合最后再接一层rerank模型。前面召回一版取50条rerank之后保留Top 5送到大模型生成。这样既保证语义召回率也避免精确匹配被漏掉。3.3 RAG效果调优与质量评估很多人把知识库搭好就以为完事了但面对真实业务问题首版效果通常惨不忍睹。RAG的调优必须建立在评估上。我建议团队先准备两三百道真实业务问题配上标准答案做成评测集。每次改检索参数、换embedding模型、改Prompt都拿评测集跑一遍用三个指标看效果召回率检索到的片段是否包含答案、答案相关度大模型有没有答非所问、忠实度答案是否忠于检索片段有没有编造。调优的顺序有讲究先调检索再调生成。检索阶段主要看切分大小、检索Top K数量、重排模型类型生成阶段主要看Prompt模板设计、是否让模型“在找不到答案时明确说不知道”、是否需要注入角色和格式要求。有一个比较隐蔽的问题是知识冲突。同一问题在不同文档里有不同说法检索回来的Top 5片段可能互相矛盾大模型就会“取平均值”胡编出一个答案。这种情况单靠模型不行需要在知识库层面做权威源标记把制度文件、官方文档设置成高优先级检索结果按权威性加权同时在Prompt里告诉模型要优先采用高权重的文档。4. Agent编排从单点到流程4.1 Agent框架与核心概念Agent的复杂度比普通的RAG问答高一个档次。普通RAG是“检索一次回答一次”Agent则是让模型自己决定调用什么工具、按什么顺序调用甚至还要根据结果重新决策。我把Agent拆成五个部分大模型大脑、规划器、工具集、记忆模块、状态管理。规划器可以简单到“先调工具A再调工具B”的固定流程也可以复杂到让模型自主写计划像ReAct循环那样“思考-行动-观察”反复迭代。选型上我推荐直接用LangGraph或者Dify的工作流模式。LangGraph适合开发能力强、需要精细控制状态的团队Dify适合快速搭建、业务流程相对标准的团队。两者都支持把Agent流程可视化调试的时候能看到模型走到了哪一步、调用什么工具、返回什么结果比自己在代码里打日志强太多。工具调用是Agent的命根子。所有能暴露给Agent的业务能力都要包成工具接口比如查工单、查库存、写SQL、调用内部API。工具接口要遵循统一的Schema描述包括输入参数、输出格式、错误类型。这里最容易被忽略的是工具文档质量工具描述写得不清楚模型就会乱传参数。尽量用自然语言把“这个工具是干什么的、什么时候用、参数怎么填”写明白。4.2 Agent并发与稳定性设计Agent遇到的最大工程问题是耗时和并发。一个简单Agent调用可能20秒一个涉及多轮工具调用的复杂Agent可能要几分钟。这比普通API请求长了一个量级对稳定性带来很大压力。首先必须做异步化。业务系统不能像调用普通接口一样同步等Agent执行完要改成提交任务、返回任务ID、通过Webhook或轮询拿结果的方式。我们用的是任务队列加工作节点Agent任务进消息队列多个Worker消费执行执行状态和结果存进数据库。其次是Agent的幂等和重试。因为Agent执行过程中可能因为模型超时或工具异常中断重试时不能重复提交外部操作。比如Agent已经给客户发了通知邮件结果网络异常重试一遍就发了两次。解决办法是给工具调用加幂等键每个源自同一个Agent运行的调用共享同一个ID外部系统通过这个ID做去重。再次是并发数要跟底层模型网关匹配好。一个Agent流程会调用多次模型接口如果你允许100个Agent任务并发每个任务平均调用5次模型那瞬间模型网关要承受500个并发请求。前面说的模型网关限流一定要和Agent调度层的并发参数一起规划否则Agent会把模型打崩。4.3 Agent与业务系统的集成模式Agent如果不跟业务系统打通就是个高级聊天机器人。真正的价值是把AI嵌入业务流程。我见过的集成模式有三种按复杂度递增排列第一种是最简单的API嵌入。业务系统在某个功能点比如填写表单调用Agent接口Agent返回生成内容用户在UI里确认后使用。这个模式适合辅助写作、内容总结、文本润色。第二种是事件驱动集成。Agent订阅业务系统的事件流比如“新工单创建”“订单状态变更”一旦触发就自动执行预设流程。这个适合自动化场景比如自动分单、自动回复、异常检测。第三种是人工审核闭环。Agent生成结果但关键动作必须经过人审批后才执行Agent和审批流深度绑定。比如系统自动生成采购申请、拟定合同条款提交给指定负责人审批。这种模式最容易让业务方放心落地阻力也最小。在具体工程上推荐把所有对外集成都收敛到中台统一暴露的OpenAPI业务系统只通过这个接口访问Agent能力。认证用OAuth或企业内部SSO继承权限模型尽量复用业务系统已有的角色权限不要搞一套新的权限体系否则光权限梳理就能拖垮一个迭代。5. 落地实战与排障经验5.1 一个典型场景从模型到业务闭环拿我们做过的一个“企业内部知识助手”来说完整链路可以拆成几步。业务系统是企业微信/钉钉里的集成机器人员工随时可以提问。请求到达中台后第一站是身份鉴权解析出用户所在部门和权限范围决定他能查询哪些知识库。然后请求进入大模型网关通过路由策略选一个适合对话的模型同时把该用户的短期记忆最近几轮对话的摘要拼进上下文。这里我们用了混合检索取回相关文档片段经过rerank之后和用户问题一起组装成最终Prompt。大模型生成时开启了流式输出用户侧能实时看到逐字返回的效果。整个回答结束之后日志系统会把问题、检索到的文档ID、模型答案、用户反馈全部落库。这个链路看起来不复杂但每个环节都回答了一个关键问题身份权限决定了知识库的范围知识库决定了上下文的内容模型决定了回答的流畅度业务集成决定了答案如何触达用户。任何一个环节掉链子用户感知都非常明显。5.2 常见问题与排查速查表我把实际运维中遇到的高频问题整理成一张速查表排查前可以先对照一下现象可能原因排查方式业务方反馈答案质量突然下降模型网关路由权重变化或模型版本更新查网关日志看请求用的是哪个模型和版本知识库检索结果明显不相关数据管道没有跑完新文档没进索引查知识库索引任务状态确认数据采集、切分、向量化的完整度某用户/某部门请求一直失败用户级配额或权限配置错误查身份鉴权日志和配额策略确认该用户的授权范围Agent任务执行到一半卡住工具调用超时或者模型响应超时查Agent状态机检查对应工具的超时配置和错误返回模型网关大量429报错并发配额不足根据接口平均耗时和QPS重新估算并发需求大模型开始编造不存在的制度条款知识库检索到的上下文不足或Prompt未强调说“不知道”检查检索召回数量、混合检索策略、生成Prompt的忠实度约束知识库构建任务总是“排队中”向量化服务的并发能力不足任务队列堆积查embedding服务的并发数和任务队列长度必要时扩容这张表的思路是先判断问题出在输入。比如用户问的问题是不是本身就无法从知识库回答再看检索效果最后才怀疑模型生成。很多时候排查的顺序反了一上来就换Prompt结果问题出在数据没同步。5.3 我藏到最后的心得最后说点个人体会。我踩过最大的坑就是把技术栈先定下来再去套业务。做中台一定是从具体场景反推的。你先找两三个业务方愿意深度配合的场景把端到端跑通再去抽象模型网关、知识库这些通用能力。否则纯做平台做得再漂亮业务方不买单最后就是个自娱自乐的产物。另一个心得是“反馈闭环”特别重要。中台刚上线的时候模型回答错了大家只会觉得AI不行而且没有人知道实际效果如何。我们后来在业务UI上加了一个“这个答案是否有用”的反馈按钮所有反馈都沉淀到日志系统里再定期抽出来做成评测集。三个月之后RAG和Prompt迭代的效果评估才真正有了依据AI中台的复盘才算进入正轨。内容扩展方面这个中台的下一步是做Agent能力和评测体系的标准化以及让知识库支持更多元的数据结构比如把表格和时序数据也纳入进来。但这些都是后话先把当前的业务闭环稳住远比追求架构上的完美更重要。这篇写到的所有模块基本都是可以照着落地的。如果你也在做类似的企业级AI中台有一两句话能让你少踩一个坑就算没白写。
