18 自研、采购与开源组合

本章产出： Build、Buy 与 Open Source 的评估框架、总拥有成本模型和一份可复审的架构决策记录。

AI 数据平台的组件层出不穷。企业很容易陷入两个极端：认为核心能力必须全部自研，才能可控；或认为采购一套平台便能自动获得 AI Ready。前者低估长期维护，后者低估语义、流程和组织责任。开源又常被误解为既免费又可任意定制，忽视升级、安全和运营。

真正的决策单位不是“整个平台”，而是能力。连接器、元数据、目录、质量、血缘、语义、检索、图关系、评测、Agent 编排和业务工具，可以采用不同来源，通过统一架构和治理组合。判断标准是哪些能力构成企业差异，哪些属于成熟通用能力，哪些风险必须掌握，组织能够长期承担什么。

18.1 三条路线的真实含义

自研意味着企业拥有设计与代码控制，也承担产品规划、开发、测试、安全、文档、支持、升级和人员连续性。购买云服务或模型 API 上再写大量胶水，不一定算轻量自研；这些胶水同样是长期产品。

采购意味着购买供应商维护的产品或服务，以缩短交付和获得专业支持。企业仍需负责需求、集成、数据语义、权限、配置、验收和退出。采购的是能力，不是责任转移。

开源意味着使用可查看、修改和自行运行的代码与生态。它提供透明、扩展和避免单一供应商的可能，但不自动提供 SLA。企业可以自运维，也可购买商业支持。许可证、社区健康、发布节奏和贡献策略都是决策内容。

实践中最常见的是组合：购买基础设施和模型服务，采用开源元数据或检索组件，自研领域数据产品、语义和工作流。

18.2 八个评估维度

18.2.1 差异化价值

直接决定客户体验、业务效率或行业知识的能力更值得掌握。山城精工的设备故障语义、保修规则、售后流程和反馈数据是差异资产；通用对象存储、身份协议和日志采集通常不是。

差异化不等于所有代码自己写。企业可以在通用平台上自研规则、数据产品和体验。关键是控制能形成竞争优势的模型与反馈，而不是控制每一行基础设施代码。

18.2.2 成熟度与时间

若市场已有成熟能力，采购或开源能缩短试点。要验证真实功能、集成和规模，而非只看演示。自研时间包括从 PoC 到生产的契约、权限、可观测、升级和支持，不能只估核心功能。

时间价值还取决于窗口。如果三个月后的解决方案仍有价值，可以谨慎建设；若业务机会短，优先组合现有能力验证。

18.2.3 集成与适配

供应商声称拥有许多连接器，不代表支持企业定制字段、网络、增量语义和权限。评估应使用真实系统做技术验证：身份能否传递，血缘是否覆盖关键任务，API 是否稳定，元数据模型能否扩展，错误能否恢复。

自研也会产生集成。组件越多，胶水代码、版本矩阵和故障边界越复杂。组合架构要有清晰责任和契约。

18.2.4 数据主权与安全

敏感数据是否离开指定环境，供应商是否保留或用于训练，密钥与日志如何管理，部署区域和跨境如何，能否删除，审计是否完整。某些能力可以 SaaS，某些必须私有部署，按数据分类和风险分层。

开源代码可审查不代表默认安全，自运维补丁不及时同样危险。采购获得认证也不代表配置和使用自动合规。

18.2.5 扩展与退出

评估数据导出格式、开放 API、插件机制、自定义实体、事件接口和身份标准。关键元数据、契约、评测集、提示、反馈和业务规则应使用企业可控格式保存。

退出计划在采购前设计：如何导出数据和血缘，迁移索引，替换模型，保留审计，合同终止后删除。退出成本过高会削弱未来议价和演进。

18.2.6 团队与运行能力

企业是否具备开发、数据工程、平台、安全、SRE 和领域产品能力？谁值班，谁升级，核心人员离职怎么办？一项技术很强但团队无法运营，就不是合适架构。

采购也需要内部产品所有者和架构能力，否则配置会失控，价值无法落地。开源最好明确维护责任、升级窗口和是否向社区贡献。

18.2.7 总拥有成本

TCO 包括许可或云费用、基础设施、实施集成、定制、数据迁移、培训、运行、支持、安全、升级、停机和退出。自研还包括机会成本与人员流动，采购还包括用量增长和附加模块，开源还包括运维和二次开发。

成本按三年和业务增长情景计算，并转换为每个成功任务或每个数据产品的单位成本。低首年报价不一定低 TCO，免费许可证也不代表免费运营。

18.2.8 供应商与社区风险

供应商评估包括财务稳定、产品路线、服务能力、合同、数据使用、价格变化和并购风险。开源评估包括许可证、贡献者集中度、提交活跃、发布、安全响应、文档、社区和治理。不要只看 GitHub Star。

关键组件准备替代路径，避免模型、向量格式或专有工作流锁定。适度抽象有价值，但不要为理论上的可替换性制造过多复杂度。

18.3 评分不是替代判断

可以建立加权矩阵：

维度	权重	自研	采购	开源+支持
差异化控制	20	5	2	4
上线速度	15	2	5	4
安全与主权	15	4	依部署而定	4
集成适配	15	4	3	4
三年 TCO	15	依规模而定	依用量而定	依运维而定
团队匹配	10	依能力而定	4	3
退出能力	10	5	2—4	4

数字用于暴露假设，不是自动得出答案。每个分数附证据、置信度和敏感性分析。若把某权重改变后结论反转，说明需要进一步验证。

18.4 OpenMetadata 如何作为参考

OpenMetadata 可有三种用法。第一，作为可部署组件，承担连接、目录、血缘、质量、数据产品和上下文服务的一部分；第二，通过商业服务或支持降低自运维；第三，即使不采用，也把其开放实体模型和源码作为理解现代元数据平台边界的参考。

阅读源码时要区分：

产品现状：当前版本实际具备、文档明确支持的能力；
设计思想：实体、契约、领域、策略和 API 的建模方式；
本书建议：结合企业场景提出的组合和演进，不代表项目官方立场。

例如其数据产品模型包含输入输出端口与 SLA，数据契约包含模式、质量、策略和服务要求，这些可以启发企业设计(OpenMetadata Contributors, 不详)。是否直接采用，仍要通过版本、集成、安全、团队和 TCO 验证。

18.5 能力分层决策

建议把能力分为：

公共基础能力：存储、计算、消息、身份、监控，优先成熟产品；
开放平台能力：元数据、目录、血缘、质量、检索，可采购或开源；
企业共享能力：实体、术语、权限上下文、评测框架，通常需要配置与扩展；
领域差异能力：数据产品、规则、工具、反馈和体验，应由企业掌握；
实验能力：模型、框架、算法，保持可替换并用评测决定。

这避免把供应商平台当业务语义所有者，也避免团队重写成熟基础设施。

18.6 PoC 与技术尽调

候选方案必须用真实切片验证，而非标准演示。测试包括：

两个真实数据源的增量、模式变化和失败恢复；
企业身份、行列/文档权限与审计；
数据产品、契约、质量和血缘的表达；
API、事件、导出与自定义扩展；
真实规模下延迟、吞吐、成本；
升级、回滚、备份和灾难恢复；
数据删除、供应商退出和迁移样例。

PoC 预先定义通过条件和时间盒。若只有供应商工程师能操作，日后内部运行风险要计入。开源方案同样做升级和故障演练，而不只验证安装成功。

18.7 山城精工组合建议

虚构案例首期可：

使用现有云或成熟基础设施承载存储、计算和模型；
评估开源元数据平台连接目录、血缘、质量与上下文；
采用成熟搜索/向量引擎，不自研底层索引；
自研设备上下文产品、故障语义、保修与备件工具；
自建任务评测集和反馈闭环，保持模型可切换；
使用企业身份与策略平台，不在 Agent 中重复权限。

这不是固定技术清单，而是能力归属：通用部分借力，领域知识和业务闭环掌握在自己手中。

18.8 ADR 示例结构

决策记录包括：

背景： 需要在九十天内建立售后上下文，同时未来支持多个 Agent。
选项： 全自研、商业 SaaS、开源自运维、开源商业支持、组合方案。
标准： 数据驻留、集成、模型扩展、上线时间、三年 TCO、团队与退出。
决定： 选定能力组合及边界。
后果： 获得什么，承担什么限制和运营责任。
验证： PoC、性能、安全、升级与出口测试。
复审： 当规模、成本、法规、团队或供应商条件达到阈值时重新决定。

ADR 应保存未选方案和理由，避免人员变化后重复争论，也防止把临时选择永久化。

18.9 本章交付物：能力采购地图

最终交付一张按能力而非品牌组织的地图，标注每项能力的差异化等级、数据风险、来源策略、所有者、TCO、替代和退出。合同、许可证、架构和运营责任保持一致。

自研、采购与开源不是身份选择，而是责任分配。好的组合让企业把稀缺人才投入到真正形成业务差异的数据产品和反馈闭环，同时借助成熟生态获得速度；又通过开放契约、可移植数据和清晰退出保持选择权。架构领导力不在于“什么都自己做”，也不在于“买最贵的平台”，而在于知道什么必须掌握、什么值得借力，以及每个选择将由谁长期承担。

18.10 防止工具组合成为新的平台债务

组合并不意味着无限增加组件。每引入一个产品，都增加身份集成、数据复制、版本升级、监控、合同和故障边界。架构委员会应维护能力地图，发现两个工具解决相同问题时主动收敛；新组件必须说明它替代什么、由谁运营、数据如何退出。

同时避免过早抽象。为未来可能更换供应商而建立层层适配器，可能比真正迁移还昂贵。更实用的做法是守住企业可控资产：使用开放的数据格式和接口，保存评测集、契约、语义与业务规则，定期验证导出和恢复。当替换条件真正出现时，再依据 ADR 和测试实施迁移。