这两年我在不少企业里做AI落地听到最多的不是“模型效果不好”而是“AI根本跑不起来”。不是缺算法不是缺算力而是数据在A系统、模型在B平台、知识在C文档里谁也够不着谁。后来我们在一家制造企业试点用了一套自研的集成方案也就是这次要聊的EAF平台——Enterprise AI Framework。这套平台专门解决三件事把各种业务系统的接入打通把分散的模型能力统一起来把散落在文档和个人经验里的知识抽成可调用的资产。听起来不复杂但真正落地时每一个“打通”都藏着坑。这篇文章我会把EAF平台的设计思路、核心组件、最小搭建步骤以及我们踩过的那些坑一次讲清楚适合正在做企业AI中台、技术架构选型或数字化转型规划的朋友参考。1. 三类孤岛到底怎么形成的企业里谈AI落地前面一定会挡着三堵墙接入墙、能力墙、知识墙。不把这三种孤岛的成因搞清楚后边做平台设计、接口对接、效果调优都是从半空中盖楼。1.1 接入孤岛系统之间的“方言”问题很多集团公司早年是“一套系统管一块”ERP管财务和物料MES管生产执行CRM管客户OA管审批还有一堆Excel表在业务手里当“私有数据库”。这些系统什么年代的都有接口方式五花八门有的是SOAP有的是HTTP有的只能连数据库还有的根本不给接口只能靠定时导出文件。AI要落地首先得拿到数据。可业务系统里的数据口径都不一样同是“客户编号”在CRM里是字符串在ERP里是数字同是“订单状态”A系统用1、2、3B系统用已创建、处理中、已完成。这就是典型的接入孤岛——数据和接口彼此隔离没法被上层应用统一消费。接入孤岛最麻烦的不是技术是组织。每个系统都有自己的部门在管牵一发而动全身。我们曾经为了拿一条生产设备的实时状态数据和车间IT、设备厂商、ERP团队来回开了四轮会。所以打通接入先要把“管系统的人”的诉求纳进来否则后面接口权限都是问题。1.2 能力孤岛模型和应用“各干各的”第二个孤岛是AI能力本身的割裂。企业里通常不是没有AI而是AI太多太乱。有的团队用开源模型做了文本分类有的部门采购了OCR服务还有的供应商给部署了预测性维护模型每个都是独立项目独立账号独立调用入口。这带来两个问题一是重复建设同样的文字识别能力采购部门和仓储部门各买了一套二是无法编排当业务需要“识别发票→提取金额→和ERP对账→触发预警”这样的流程时没有一层东西能把OCR、抽取模型、规则引擎、消息推送串起来。能力孤岛的本质是缺少一个“模型网关”让所有AI能力像水电一样即插即用。但很多企业连这个意识都没有觉得把模型训练出来就完事了结果模型只能在一个固定的Notebook里跑业务系统根本调不到。1.3 知识孤岛文档在仓库、经验在脑子第三个孤岛最隐蔽也最要命。企业里最值钱的资产往往不是结构化数据而是操作规程、故障手册、项目复盘、老师傅脑子里的判断经验。但这些知识90%不在系统里工艺卡在车间铁皮柜排障手册散落在个人电脑质量问题的处理经验只有几个老员工说得清。员工问“这台设备报警F302是什么原因”业务系统给不了答案知识库检索精度又不够。即便有文档也是Word格式堆在共享盘里没有语义化没法被模型直接消费。更别说把多个领域知识关联起来比如“设备F302报警”和“近期换了新批次润滑油”有没有因果关系这种跨文档推理在传统检索系统里根本做不到。知识孤岛不解决AI就永远只能做“人肉问百度”做不了真正的智能体。2. EAF平台的总体设计与关键组件拆解EAF平台的定位不是再搞一套新系统而是做企业现有的“中枢神经系统”向下连接所有数据源向上提供统一的AI能力横向打通知识资产。它的核心设计遵循一个原则接入、能力、知识三者分层解耦但通过统一的元数据和身份体系关联起来。2.1 统一接入层连接器与协议归一化接入层解决的是“方言翻译”和“交通调度”。EAF把每一种外部数据源或系统抽象成一个“连接器”Connector。连接器的职责有三块协议适配、鉴权代理、数据转义。协议适配处理的是接口层面的差异。比如某老系统只有SFTP文件交换连接器就定时拉取文件并解析成标准事件某新系统提供REST API连接器就做OAuth2.0认证和轮询还有的数据库允许只读账号直连连接器就用只读库采集增量变更。数据转义则负责把外部系统的字段映射成平台内的统一模型。例如把CRM的“customer_id”、ERP的“customCode”、数仓的“cust_no”统一映射为“客户标识”这个逻辑字段。这样上层应用不需要关心数据从哪个系统来的只要面向规范模型写代码。我建议接入层最多只做“轻清洗”重清洗交给下游的数据服务。原因是接入层连接了很多实时系统如果做太多聚合或清洗会拖慢链路还会把业务逻辑耦合进连接器里后期一改就崩。2.2 能力中枢模型网关与服务编排能力中枢是EAF和普通数据集成工具最大的区别。它内置了一个模型网关可以把各类AI能力统一发布成标准API。无论底层是本地部署的开源模型、云上的大语言模型API还是供应商提供的私有算法模型网关都用同一套接口暴露给上层。模型网关的关键属性包括模型路由、版本管理、限流降级、内容审核。模型路由解决的是“同一个问题到底调哪个模型”比如简单文本分类用小模型便宜快复杂语义理解用大模型。版本管理避免模型升级后效果回退没有回滚手段。限流降级保证关键业务不会被突发流量打垮。有了标准API后EAF的服务编排引擎就可以用可视化或代码的方式串起多个能力。比如一条工单处理链路先调用OCR识别图片文字再调用信息抽取模型提取工单号然后用规则引擎匹配责任部门最后调企业微信接口推送。整个过程每个环节可观测、可重试比手工调一堆脚本要可靠得多。2.3 知识底座向量库、知识图谱与上下文管理知识底座解决的是“从信息到可推理知识”的最后一公里。EAF的知识底座分三层文档解析层支持PDF、Word、扫描件等格式先做版面分析、表格抽取再切分成合适的文本块。知识存储层采用“向量库知识图谱”双引擎。向量库负责语义检索知识图谱负责实体关系和规则逻辑。比如“F302报警”是一个实体“润滑油更换”是一个事件它们之间通过“可能相关”的边关联。上下文管理层把用户问题、检索到的文档片段、历史对话、业务上下文拼装成一个固定结构在交给大模型之前做一次“知识增强”。知识底座最容易做虚。很多方案吹得天花乱坠最后连数据接入都没搞定。实际操作中我会优先做“高频FAQ结构化文档”的检索增强先把老员工离职带走的隐性知识沉淀下来再谈图谱和推理。3. 从零搭一个EAF最小可用平台理论讲完直接上实操。我们以一家虚拟的装备制造企业为例目标场景是“售后维修知识问答与工单辅助生成”。在这个场景里EAF要接入设备IoT状态数据、历史维修工单、产品手册和维修专家的经验记录能力上用到OCR、文本分类、大模型生成。3.1 第一步梳理接入资源并配置连接器先不要写代码拿一张白纸画清四个清单数据源清单设备IoT接口、ERP工单表、文档服务器、企微通讯录。接口类型清单MQTT、REST、MySQL只读库、SFTP。更新的频率要求实时、分钟级、小时级。访问方式与权限谁提供凭据、有效期多久、是否合规。之后在EAF控制台里分别创建连接器。以IoT接入为例需要填MQTT Broker地址、Topic前缀、客户端ID和证书。这里的坑是工厂车间网络和办公网经常隔离EAF如果部署在办公网就要在车间加数据网关先把数据转发到DMZ区再让EAF拉取。一开始不知道怎么处理总是超时后来加了消息队列缓冲才算稳定。ERP工单表则用CDC方式订阅。我们需要一个能读取MySQL binlog的组件把新增、修改、删除操作转成事件流。配置CDC时注意一定用只读副本别在核心库上直接建触发器。连接器配置完成后逐个做连通性测试同时验证字段映射。尤其注意枚举值的翻译比如工单状态从“已关闭”映射为“Closed”必须在连接器里配置对照表否则下游模型会学到错误的关系。3.2 第二步注册AI能力与服务编排能力注册的第一步是盘点需要哪些模型。我们的最小场景里需要三类设备故障码识别模型输入报警图片输出故障码可以调用私有OCR服务。工单分类模型输入维修描述输出故障类别用小模型就行。维修报告生成大模型输入上下文输出结构化报告用通用大模型API。在EAF中每个能力注册时都要定义输入输出Schema例如“故障码识别”的输入是image_url输出是code、confidence。定义Schema的意义在于后续编排时能做类型校验避免传参错乱。然后我们创建一条叫“维修工单处理”的流程。具体编排逻辑收到企微推送的设备报警图片。触发故障码识别把图片转成故障码。用故障码在知识库做向量检索召回相关手册片段。把工单历史同类型维修记录、故障码、检索到的文档片段一起打包。调大模型生成“维修建议初稿”。按模板填充工单字段推送到ERP系统待人工确认。服务编排时我习惯用“可观测优先”的模式每个节点都输出结构化的trace_id方便随时用日志排查。最怕的是编排像面条一样缠在一起一出错整个链路卡死。EAF支持超时配置和重试策略我们的实践是外部API调用设置3秒超时重试2次中间加指数退避。3.3 第三步构建企业知识库并打通问答链路知识库建设是整个平台里最花时间的模型训练反而快。我们的做法分四步。第一步文档清洗。收集产品手册、维修SOP、历史优质工单、专家访谈纪要。这些材料格式极乱有扫描的PDF、有表格、有手写纪要。先用OCR把非数字化文档转成文本再做段落切分。切分不能简单按字数切要按语义边界比如一个章节、一个步骤、一个完整条目。经验值是每个文本块控制在300到500字方便后边检索和拼装。第二步向量化。把文本块用嵌入模型转成向量存进Vector Store。向量模型要根据内容类型选中英文混杂的文档用支持多语言的模型。这里要分享一个细节不要对整个文档做向量化而要对切分好的块做向量化同时把文档标题、章节路径、更新日期作为元数据存进去检索时可以做过滤。第三步知识图谱抽取。我们先用一个信息抽取模型把“设备型号-故障码-原因-处理方法”的实体关系抽出来再和向量库形成混合检索。比如用户问“F302报警后复位不了怎么办”向量库召回“F302复位说明”的段落知识图谱则直接把“F302→原因电机过热→处理检查散热”的路径找出来两个结果合并后作为上下文给大模型。第四步评测闭环。知识库不能做完就扔要维护一个“黄金问答集”。把经常遇到的问题、标准答案、引用来源都存下来每次改知识库都跑一遍自动评测看回答的准确率和引用率。我们有一次更新了产品手册结果老版本的问答集显示准确率从85%掉到76%排查后发现是文档版本变了但知识库里的元数据没更新导致模型引用到了废弃手册。后来就规定任何文档变更必须走EAF的版本发布流程。3.4 第四步权限、审计与效果评估企业AI平台最容易被管理层质疑的就是权限和数据安全。EAF在设计上把权限拆成两级平台层权限和业务层权限。平台层权限控制谁能接入数据源、谁能注册模型、谁能修改流程。业务层权限控制最终用户能查到哪些知识、能调用哪些能力。我们当时给售后部门配了“全部手册”权限但是对财务相关的工单数据做了行级隔离只能看到维修成本和设备编码看不到利润数据。审计方面要求每个AI回答都保留完整的链路证据用户是谁、问了什么、从知识库召回了哪些段落、调用了哪个模型、生成内容是什么、有没有人工编辑。这一条很关键因为企业用AI最怕的是“模型瞎编责任不清”。有了链路证据就算生成结果出了问题也能回溯到是知识库缺失、检索不准还是模型幻觉。效果评估不能只看准确率还要看业务指标。我们给维修问答场景定了几项指标问题一次解决率、平均处理时长、工单填写完整率、知识库覆盖率。上线前这些问题平均处理时长40分钟上线后降到了25分钟这才是老板愿意继续投入的原因。4. 实施过程中最常见的坑与排查实录EAF平台的每一项能力我们都能对应一次“踩坑实录”。整理出来是希望后来者少走弯路。4.1 连接器反复超时问题出在协议适配第一个坑是物联网连接器一直超时。现场反馈说设备数据收上来总是断断续续我们一开始怀疑网络问题让IT查了一遍带宽和延迟都正常。后来用TCP抓包发现设备网关是走MQTT QoS 1的但我们的连接器用的是QoS 0于是服务端在低带宽时会丢弃大量报文。排查过程花了大半天最后定位在协议细节上。解决办法是在连接器里调整QoS等级同时增加了心跳和离线重连机制。这里给两个经验接入协议时先确认双方用的子协议版本连接器一定要做消息确认机制不能只发不管。还有个相关的坑是时间戳时区。设备的物联网时间用了UTC而ERP用的北京时间连接器没有在解析层做统一导致后续工单分析晚8个小时。这种低级错误做一次就记住了统一接入层里强制所有时间转换为ISO8601带时区格式。4.2 模型返回“答非所问”知识召回策略要调我们上线问答系统后的第一个周末被维修主管拉着看了半小时“胡言乱语”。比如问“冷却液温度超过80度”模型回答出“建议更换机油滤芯”。乍一看是幻觉其实问题出在知识召回向量检索把“设备保养周期”的文档块排到了前面和问题语义相似的“冷却系统故障排查”反而被淹没了。排查后发现嵌入模型对“冷却液温度”和“发动机散热”这些专业词语的向量距离很近容易混淆。解决思路是多路召回加权重除了向量相似度还加了一路关键词匹配对故障码、设备型号、报警代码这种精确性要求高的信息用BM25或正则优先匹配然后把两路召回结果做融合排序。还有一个很实用的调优技巧给知识库自动生成“伪问题”。对于每一段操作手册让模型生成5到10个可能的用户问法把这些伪问题也做成向量索引。这样用户问“温度高了怎么弄”时能匹配到原本在“冷却液温度过高处理流程”段落下的伪问题“降温的方法”召回率明显上升。4.3 权限反复横跳统一身份映射不能省知识库刚上线时我们发现用户A能查到他和用户B都各自创建的技术方案但有的能看有的不能看排查到最后是身份映射出了问题。EAF从企微同步了用户信息但知识库里的文档权限还是按AD域账号管理的两边账号前缀不一致导致权限同步逻辑乱套。后来我们做了统一身份映射表在EAF里把企微用户、AD用户、业务流程里的“责任人”字段拉齐每次业务数据进入知识库时自动按责任人映射反查权限。这个工作不能靠写临时脚本必须做成平台功能。因为企业人员的变动太频繁今天调岗明天离职权限如果不跟着角色走就会出现越权或者无人可用。权限设计的一条经验是“默认最小化”。一开始就想全反而推行不下去不如先从“按团队共享知识”开始再细化到个人。对于涉密文档宁可不进知识库也不要冒险某客户曾经因为把含员工身份证信息的手册传进向量库吓出一身冷汗。4.4 性能瓶颈与容量规划最后一个坑是性能。EAF平台刚上线时只有几十个并发用户感觉很流畅。后来随着接入的设备和文档量暴增向量检索的延迟从200毫秒涨到了2秒模型网关的并发也接近上限。我们做了三件事给向量库加索引分片把热点领域的文档单独建索引查询时先路由到对应分片。对模型网关做“模型实例池”把高频调用的大模型扩到3个实例再用负载均衡把请求分散到不同实例。对知识检索和模型生成做缓存完全相同的问法直接从缓存里出结果不消耗模型算力。容量规划要提前做等到卡死再扩容就会被业务指着鼻子骂。经验值是并发用户数乘以单次问答消耗的Token数再乘一个1.5的系数就是模型API的容量需求。向量库容量则按“文档总量乘以平均切块数”再加50%冗余来规划。另外别忘了调用链路的监控告警。我们最初只看整体延迟后来发现很多错误都是因为一个下游系统偶尔返回500导致整个流程失败。现在每个连接器和模型调用都有成功率、延迟、错误数三个指标并配了告警规则出问题5分钟内就能定位到环节。写在最后这件事难在“打通”而非“技术”EAF平台做完以后我最大的体会是企业AI落地的难点从来不是某个模型有多聪明而是有没有一套机制让数据、能力和知识之间顺畅流动。接入层解决的是“连得上”能力层解决的是“用得起”知识层解决的是“答得准”。三层打通后AI才真正变成业务手里的一把顺手工具。如果只挑一条经验分享我会说先从一个具体场景切入把纵向链路完整跑通再去横向扩展平台。很多企业一上来就想着做“大而全”的AI底座结果半年过去了建了一堆没人用的模块。我们这套EAF平台其实也是从一个售后问答场景起步跑通后才逐步把生产质量分析、采购合同审查都接了上来。最后再分享一个小技巧每个连接器、每个模型、每个知识库文档都要强制打上“负责人标签”。有了负责人出了问题知道找谁后续变更有人跟进平台才不会在人员流动后变成烂尾工程。技术上的孤岛容易打通管理上的孤岛更难但只要把责任和流程理清企业AI落地就能真正走起来。