打通接入、能力、知识三大孤岛：企业AI落地底座设计与实践

这几年我前后参与了不少企业AI落地的项目，有一个问题几乎每次都会被翻出来讨论：AI价值听着很大，为什么一到生产环节就卡住？我的答案一直很一致——不是模型不够强，而是企业里的接入、能力、知识这三块各自为政，形成了一圈看不见的孤岛。我们后来做了一个叫EAF的平台，专门用来打通这三类孤岛。这篇文章就把这段经历完整拆开，讲讲孤岛是怎么形成的，EAF平台又是怎么接进去的，以及落地过程中那些踩过的坑和比较实用的做法。

1. 三大孤岛是如何拖住企业AI落地的

1.1 接入孤岛：AI应用要数据，数据却在千仓百库

在我参与过的企业AI项目里，第一个被忽略却又最难啃的点，往往不是模型精度，而是数据接入。绝大多数企业内部不只有一个业务系统。ERP管财务和订单，CRM管客户，OA管流程和审批，MES管生产执行，再加上一大堆独立的数据库、文件服务器、报表系统和第三方SaaS，每个系统都有自己的用户体系、接口协议、数据口径和网络区域。

AI应用落到一线时，业务方常提一个朴素需求：帮我做一个智能问答，能答复客户问题时引用我们最新的订单状态、库存数量和物流节点。听起来不复杂，但一拆解就会发现，要拿到这些数据，至少需要对接订单系统、库存系统、物流系统和客户中心的数据。这四个系统的接口协议各不相同，有的走HTTP，有的是老式RFC，有的只提供文件导出；认证方式也分裂，有人用用户名密码，有人用OAuth，还有人直接给了一个无鉴权的内网端口。

更麻烦的是数据口径的问题。订单系统里“成交”和财务系统里“成交”的定义可能不一样，生产系统里的“完工时间”和项目管理系统里的“交付时间”可能差着三天。如果AI应用直接把不同系统的字段拼在一起做推理，输出结果大概率错得离谱。这正是接入孤岛的表现：技术上不能连、管理上不敢连、业务上说不清。

1.2 能力孤岛：AI能力散落在部门墙里

第二种孤岛发生在能力层面。早期数字化转型过程中，很多部门都各自引入过AI能力。客服部门采购过OCR识别服务，供应链团队让外部供应商做过时效预测模型，市场团队可能直接调用了某个通用大模型的API，生产部门自己训练了质量缺陷检测模型。这些能力散落在不同团队、不同技术栈、不同部署环境里。

问题也随之而来：第一，不可发现。你问公司里的人“有没有现成的实体抽取能力”，没人能马上回答。第二，不可复用。就算知道存在，也不清楚入参是什么、出参是什么、稳定程度如何，换一个业务场景就得重新对接。第三，不可治理。模型的前后版本没有管理，谁在调用、成本如何核算、效果如何评估，基本是一笔糊涂账。

能力孤岛的直接后果是重复建设。一个公司里可能同时有三套文本分类服务，两套客户意图识别模块，每一套都是项目制的产物，代码不共享，模型不互通，评估口径也不统一。做平台之前我们需要先回答：到底哪些能力是通用的？怎么让通用能力长出来并被全公司复用？

1.3 知识孤岛：最有价值的资产成了个人私有财产

如果把接入孤岛和能力孤岛比作“管道”和“发动机”的问题，知识孤岛就是“油料”的问题。企业最值钱的东西，不是系统里的原始记录，而是那些被不断验证过的经验、规则、因果联系和决策上下文。但这些知识很少被系统化沉淀下来。

我见过最典型的场景：一个五年经验的设备维保专家，能通过声音判断设备隐患，但他的经验绝大部分存放在他自己的工作笔记里，或者更多时候只是存在于记忆中。他带过的徒弟、写过的报告、处理过的工单，分散在不同格式的文件里，有的是Word，有的是Excel，有的是聊天记录截图。

部门内的知识库也不是没有，但常常变成“僵尸库”，一年更新一两次，检索质量低，员工宁愿直接问老同事。更麻烦的是，知识一旦落到数据库字段或聊天上下文里，就没有模型、没有关联、没有语义。你要让大模型回答“我们上次处理类似故障时用了什么方法”，需要一个能把隐性和显性知识统一纳管、统一检索的底座。否则AI永远是“四体不勤、知识贫瘠”的哑巴工具。

2. EAF平台的整体思路：先把孤岛连成群岛

2.1 平台定位：企业AI落地底座，而不是又一个AI应用

当时我们喊出的口号是“一个平台，三个统一”：统一接入、统一能力、统一知识。EAF平台的定位很简单——它不解决某一个具体的业务问题，也不直接充当某个AI模型，更不是把几套算法拿来做个组合。它的使命是给企业的所有AI应用提供一个统一底座，让AI应用可以按需接入业务系统、按需调用通用能力、按需获取统一知识。

为什么要这样定位？因为企业AI落地的最大瓶颈不是缺一两个好模型，而是生产环境里的“连接成本”太高。模型再好，接不到数据就是摆设；能力再强，各部门重复造轮子就是浪费。EAF要解决的是让AI应用从“每个项目都要从零接一遍”变成“一次接入、处处复用”。

2.2 三条设计主线：接入、能力、知识成“三件套”

在架构设计上，我们把平台拆成三大域，每个域对应一条设计主线。

• 接入域：负责把企业内外部的系统、数据源、API统一抽象接入。平台只关心这类资源的连接方式、鉴权方式、数据模型和可用性，不关心具体业务逻辑。
• 能力域：负责把模型和算法服务统一注册、统一调度、统一评估。平台只关心能力的接口契约、版本、运行指标和额度限制。
• 知识域：负责把文档、对话、数据库字段、业务图谱统一建模，提供统一的语义检索和知识回写能力。平台只关心知识的来源、切分粒度、语义关联和权限边界。

三条主线不是互相独立的。知识域要访问数据，最终还是要通过接入域来连数据源；能力域要完成复杂任务，需要调用知识域的检索接口；接入域暴露的系统接口，也可能被能力域包装成上层技能。所以EAF平台在实现上是一个联邦式架构：外部系统不必进入平台内部，平台通过标准协议与之交互；各个域之间通过内部消息和API协作。

2.3 一切皆资源：用元数据把孤岛连接起来

核心设计思路可以概括为“一切皆资源”。任何要纳入平台的东西——一个数据库、一个API、一个OCR模型、一份制度文档——都可以被描述成一份资源元数据。元数据里记录它的名字、类型、位置、调用方式、负责人、权限策略、健康状态。

为什么要这么设计？因为孤岛之所以成“孤”，本质上是缺少统一的描述和发现机制。一旦我们把“哪个系统暴露了哪些接口”、“哪个能力服务有哪些版本”、“哪份知识文档属于哪个业务树”都描述清楚，平台天然就具备了发现能力和治理基础。之后无论是编排、调用还是统计，都变成对元数据编程，而不是对一堆没人维护的硬编码接口编程。

举个配置上的例子。接口接入时，我们会在平台上登记一份接入资源信息，类似这样：

access_resource: name: "erp_order_api" protocol: "rfc" endpoint: "erp://10.20.20.15:3400/order" auth: type: "vault" secret_key: "erp/prod/credential" rate_limit: qps: 300 burst: 600 health_check: interval: 60s timeout: 5s

这段配置有三层含义：一是声明了系统的物理接入方式和认证方式；二是限定了调用频率，防止AI应用把老系统拖垮；三是告诉平台需要定期做健康检查。后续所有AI应用都不直接碰ERP的真实地址，而是通过平台根据元数据自动生成的路由来调用。

3. 接入层打通：让AI应用不再关心系统差异

3.1 接入层的真正难点在于“语义拉齐”

很多技术团队一开始会把接入层做成一个转发网关，觉得把请求转发过去就行。实际用下来会发现，真正的难点不在协议转换，而在“语义拉齐”。

举个真实场景。不同业务系统里都有“客户”这个概念，CRM里叫customer_type，订单系统里叫cust_type，售后系统里叫client_type。AI应用要做跨系统分析时，如果不做字段级映射，模型拿到的是同一概念的不同表达，再怎么调参数都不可能稳定。所以EAF平台在接入层不只是做转发，还引入了资源模型。每一类接入资源，都要在上层暴露一套统一语义接口，比如统一的“客户查询”“订单状态查询”“库存查询”，由平台负责把统一名词翻译成底层系统的字段。

这就需要在为每个接入资源建模时，投入精力做领域分析。前期确实慢，但这部分投入换来的回报非常大：后续所有AI应用都不需要理解底层系统的字段细节，只需要面向平台统一的语义层编程。

3.2 标准接入流程与配置要点

我们最终把接入流程简化成了四个动作，业务团队照着走就能完成一个系统或数据源的接入。

1. 登记资源：在接入域中创建接入资源，填写系统名称、类型、负责人、网络地址、认证凭据，并指定分级权限。
2. 定义语义接口：把底层接口抽象成标准能力，比如“查询库存”“创建工单”，并配置字段映射和默认参数。
3. 发布联通测试：平台生成一次冒烟测试，校验网络、鉴权、超时、返回格式，并输出连通性报告。
4. 绑定消费授权：将资源授权给指定的AI应用、知识域或能力域，设置配额和调用审计。

这四步做完后，接入资源自动进入平台目录，所有被授权的应用都能看到并使用它。常见配置里有一个特别值得注意的点：超时和重试机制必须单独配置。ERP这类老系统经常有慢查询，若网关默认超时是3秒，AI应用调用一次订单查询大概率失败。我建议对外部系统调用统一设置超时上限为五秒，超过即返回降级结果，同时配置幂等重试，重试次数不超过两次。重试次数设太高，或者没有幂等设计，极容易把老系统打崩。

还有权限和审计。AI应用用的凭据不应直接传给底层系统，应在平台里用ticket方式换发短时凭证，避免泄露大范围访问权限。每一步调用都要落审计日志，既用于合规，也用于后期排障。

4. 能力层打通：让AI能力可注册、可编排、可治理

4.1 能力孤岛如何变成能力资产

我们处理能力孤岛的理念是：不强行统一所有模型的实现，只统一它们的“服务形态”。OCR、语音识别、意图分类、预测算法、大模型问答，它们的模型结构千差万别，但对外都可以抽象为“请求-响应”的能力服务。

EAF平台提供了一套能力注册SDK，任何团队都可以把自研模型或外部模型包装成标准能力。注册时只需要描述能力名称、版本、功能分类、输入输出JSON Schema、预算配额和负责人。平台会自动生成服务端点、监控面板和能力文档。曾经一个业务团队的内部预测模型，用了两天时间完成注册，之后其他五个团队直接复用，再也没有人去单独做重复对接。

4.2 统一调用与智能路由

统一调用并不是说所有请求都固定走同一个后端模型。实际业务中我们会根据任务难度和成本做智能路由。比如意图识别，简单指令用本地轻量模型，复杂开放式提问才转给大模型。这样既保证了响应速度，也控制了推理成本。

路由规则可以在平台里配置：

from eaf.capability import CapabilityRouter router = CapabilityRouter(name="intent_recognition") router.add_backend( name="light_local", condition={"max_tokens": 200, "cost_score": 0.2}, fallback_order=1, ) router.add_backend( name="general_llm", condition={"confidence_floor": 0.6}, fallback_order=2, )

这段逻辑的本质是给一次调用多条退路：本地模型能处理就直接返回；不能处理或置信度偏低，自动转给通用大模型；如果大模型也异常，控制器还会选择缓存策略或返回兜底文案。实践中，智能路由让我们的整体模型成本下降大约三成，同时可用率观察到99.2%以上。

4.3 能力治理：版本、灰度与评估闭环

能力一旦被复用，就要引入治理。EAF平台把能力的版本管理做得和软件发布类似：每次模型迭代都走“测试环境评估、小流量灰度、全量上线、效果回归”这条路径。

灰度发布时，平台会按请求比例分配流量，比如先放10%到新版本，观察置信度、耗时、投诉率和业务转化后，再把比例提到30%、50%、100%。灰度过程不需要业务应用改一行代码，因为上层请求只面向能力名称，后端具体调用哪个版本由平台决定。

评估闭环也是很多团队容易漏掉的一环。模型上线后不能只看离线准确率，还要持续采集业务反馈。所以我们规定了每个能力必须有明确的业务指标，比如人工采纳率、问题解决率、平均处理时长变化。没有业务指标的能力只允许内部测试，不允许面向生产用户开放。这个规矩一度让某些部门觉得“走流程”，但坚持下来后，平台里的能力质量整体提高了，后期排障成本反而下来了。

5. 知识层打通：把企业知识变成AI能用的燃料

5.1 知识资产统一建模

知识层设计时，我特别强调要防止一个误区：认为知识库就是几条文档同步进向量库。真正要打通知识孤岛，必须先建立统一的知识资产模型。

我们把知识资产分成四类：

• 结构化知识：数据库字段、业务指标、配置项，可以直接映射为图谱节点。
• 半结构化知识：企业制度文档、接口文档、FAQ，需要解析、切分、标注。
• 非结构化知识：专家的日志、聊天记录、会议纪要、工单文本，需要清洗和实体抽取。
• 过程性知识：流程中的判断规则、经验口诀、问题处理步骤，往往藏在对话和文档描述里，需要用事件抽取和关系抽取提炼。

统一建模后，所有知识资产具备统一的元数据：来源、更新人、更新时间、所属业务域、权限范围、质量评分。这样知识不仅可检索，还能按业务域和安全域进行自动隔离。

5.2 从切分到混合检索：知识检索怎么做才靠谱

文本切分是一项反复试错的工作。切太粗，一块片段里包含多个主题，检索时命中率低；切太细，上下文不完整，问答时答非所问。我们的经验是以段落和章节为基本单元，保留标题层级作为上下文补充维度，而不是机械地按字符数切。

切分完成后，要建立多路检索。EAF平台的知识域内置了三路混合检索：

• 稀疏检索：基于关键词和BM25，适合精确匹配专有名词、编号。
• 稠密检索：基于向量嵌入，适合语义相近但字面不同的查询。
• 图谱检索：基于实体和关系图谱，回答“A部门生产了B产品，C客户购买了它”这类跨对象问题。

实际运行中，三路检索结果会按得分融合，再经过重排模型输出最终结果。我们在某个知识检索项目中，从“只使用向量检索”改成“三路混合检索+重排”之后，检索Top5命中率从68%提升到84%左右。这个提升不是靠某一个大模型，而是靠工程组合。

5.3 知识回流与权限安全

知识层还有一个容易被忽略的点——知识是活的，需要回流。用户使用AI问答后，如果业务人员确认某条回答有效，这个确认行为应该被视为反馈信号，进入知识质量评分系统。经常被采纳的内容逐步提升权重；长期无人使用或负面反馈较多的知识，自动进入老化淘汰队列。

权限安全这块必须单独拎出来说。知识同步时，千万不要把全量数据一股脑灌进向量库。一旦同步，切割后的片段很难再和原始权限体系一一对应。我们的做法是：知识源挂载时继承原系统的ACL权限模型，同步到向量库的每个片段都带上权限标签；检索时首先过滤当前用户无权访问的片段，再做后续查询。没有这层设计，知识越全，泄密风险越大。

6. 打通之后的变化：从项目数据看落地效果

6.1 一个制造企业案例的回溯

在某装备制造企业的落地项目中，我们验证了三大孤岛打通的整体价值。这家企业原来有十一个业务系统，AI应用要获取跨系统数据，通常要项目组到处找接口负责人，平均一次数据接入要两周左右。平台上线初期，我们先把订单、库存、设备维保、质量检测四个系统的接入资源统一纳管。

之后半年里，业务侧陆陆续续开发了七个AI应用，包括采购问答、设备预测维护、质检辅助、售后自动派单。所有应用都复用统一接入层和统一知识检索，没有重新去对接一次业务系统。七个AI应用里，有五个使用了同一个语义检索知识服务，能力复用率明显上升。设备维保专家的经验文档被结构化后，知识资产库里沉淀了数百条处置规则，新员工在智能助手的辅助下，排查常见故障的速度比之前快了不少。

6.2 关键指标的横向对比

下面这些数值是从同类项目中总结出来的一组典型变化，不同行业会有差异，但方向基本一致：

这些数据说明，打通孤岛的价值不是某一个模型变聪明了，而是整体工程的边际成本降下来。后续每新增一个AI应用，新增的成本主要在某些业务逻辑和模型调优，而不是重新铺管道。

7. 常见问题与排查实录

7.1 接入与调用类问题速查

接入层有一个我印象特别深的坑：某个系统使用自定义加密的鉴权头，网关一开始解析不了，日志里看不到真实来源。后来我们决定不魔改网关，而是在这个资源下挂了一个轻量适配插件，只对这一个资源生效，其他资源的调用完全不受影响。这个经验后来成了平台的一个默认原则——特殊适配要以插件方式隔离，而不是把特殊逻辑写进网关主链路。

7.2 能力层和知识层的典型问题

能力层常见问题往往是版本和流量问题。某个能力灰度到30%时，新版本模型推理耗时暴增，导致线上问答超时率上升。我们当时的做法是立即将灰度流量回滚到10%，然后单独压测新版本。排查结果是没有给推理服务配置足够的并发资源。这个案例说明，能力灰度不仅要监控离线指标，还要监控P99耗时、内存占用和GPU利用率。

知识层常见问题是检索结果“看似相关实则无用”。大多数时候出在切分策略上。我们曾经把一份很长的制度文档按固定500字切分，结果一个条款被切开，问“报销周期是几天”时，模型检索到的是半个条款，自然答错。后来我们把切分逻辑改成“标题层级+段落边界”，并允许切片携带父标题作为上下文，问题很快就消失了。

还有一个容易被忽视的坑：文档去重。运维同学每天上传系统巡检报告，因为命名规则变化，同一份报告被解析成多个近似片段，检索时重复内容占了大量位置。后来知识域加入了相似度去重和指纹去重，检索列表才干净下来。

7.3 一个屡试不爽的排障顺序

排障时我建议按这个优先级走：先看接入链路的日志是否完整，再看权限是否被正确传递，再看数据是最新还是过期，最后才怀疑模型提示词和参数。很多AI应用上线初期，业务方怀疑模型不行，结果查来查去都是数据源没同步或者权限缺失。先排查工程链路，能省下大量无效调参时间。

8. 落地复盘：一些只有做过平台才知道的经验

最后分享几条个人经验，算不上真理，但都是踩过坑后沉淀下来的。

第一，不要一上来就追求“大而全”。三大孤岛虽然最终要打通，但启动时最好找一个最痛的孤岛入手。我的建议是先打通知识和接入：知识不打通，AI没有东西可答；接入不打通，AI没有数据可用。能力域可以等前两者稳定后再做编排和复用，否则很容易陷入“平台没人用”的尴尬。

第二，平台建设必须有业务方深度参与。接入层的语义拉齐，必须依赖业务人员解释各个系统字段的真实含义；知识层的权限边界，也必须由业务部门拍板。纯技术团队闭门造车，三个月后交出来的往往是技术完美但业务不接地的平台。

第三，治理要先于服务。能力注册、知识权限、接入审计这些规范，要在平台开放给业务应用之前定好。一旦用户接入后再补治理，牵涉的存量改造会大得多。不少平台项目失败的起点，就是“先让业务跑起来，治理以后再说”，后期返工成本高到让人崩溃。

第四，EAF这类平台本质上不是一次性的交付项目，而是一个可以持续沉淀的数字化底座。后续如果企业要引入新的模型、新的数据源、新的知识领域，只要在对应域中登记新资源，就能以很低的新增成本进入统一生态。这也是我当时最看重的能力：平台是否能持续长出新应用，而不是一场热闹的样板间工程。

我用一个比喻收尾：企业AI落地像是给一个老房子重新铺水电。模型只是家电，光买再贵的家电，没有统一的水管和电路也转不起来。EAF平台要做的，就是把接入、能力、知识这三条管路重新梳理，让每个房间都能随时开灯用电器。等到那一天，AI落地才真正成为企业运营的一部分，而不是一堆孤零零的演示项目。