AI 开源项目选型最容易被热度带偏。一个仓库刚开源，几天内拿到几万 star，演示视频很漂亮，README 写着支持所有主流模型、所有向量库、所有工作流、所有部署方式，团队就很容易产生错觉：这个项目已经成熟，可以直接作为生产底座。真正进入使用后才发现，示例跑得通，不代表架构可维护；issue 很热闹，不代表问题有人解决；许可证看起来开放，不代表商业使用没有约束；插件很多，不代表质量稳定；替换起来看似容易，实际数据结构、接口、流程和团队习惯都被绑定住了。

AI 开源选型比普通软件选型更复杂。因为 AI 项目往往处在快速变化的链条中：模型供应商变，推理框架变，向量数据库变，Agent 协议变，前端交互变，评测方法变，合规要求也在变。一个项目今天解决了问题，三个月后可能被上游模型能力、协议标准或生态路线改变。选型不能只问“现在能不能用”，还要问“未来能不能跟得上，跟不上时能不能退出”。

活跃度、许可证、架构和退出成本，是 AI 开源项目选型的四个核心维度。活跃度回答这个项目是否还在被认真维护；许可证回答你能否合法、安全、长期使用；架构回答它能否承载你的生产场景；退出成本回答一旦方向不合适，你能否不伤筋动骨地换掉它。只看其中一个维度都不够。高活跃但许可证不合适，不能用；许可证宽松但架构混乱，不宜做底座；架构优雅但社区停滞，要谨慎；当前很好用但退出成本极高，要提前设边界。

一、先判断它是工具、框架还是平台

选型前要先分清项目类型。很多争论来自把不同层级的项目放在一起比较。一个命令行工具、一个 SDK、一个工作流框架、一个模型推理服务、一个向量数据库、一个 Agent 平台、一个完整应用，选型标准完全不同。工具可以轻量试用，框架会进入代码结构，平台会进入组织流程。层级越深，退出成本越高。

工具型项目通常解决单点问题，例如文档解析、prompt 管理、数据标注、评测报告、模型下载、格式转换、日志查看。它们的选型重点是功能是否准确、依赖是否轻、接口是否稳定、输出是否可替换。工具坏了可以换工具，影响有限。对工具型项目，不必过度追求社区规模，但要确认维护者回应关键 bug。

框架型项目会影响代码组织方式，例如 RAG 框架、Agent 编排框架、模型调用 SDK、多模型网关、任务队列和插件协议。它们会把自己的抽象带进业务代码：链、节点、工具、记忆、检索器、运行时、回调、状态机。选框架时不能只看示例短不短，而要看抽象是否贴近你的业务，是否容易调试，是否允许逃逸到底层。

基础设施型项目更重，例如向量数据库、推理引擎、任务调度系统、观测平台、权限系统和模型服务网关。它们进入生产后会承载数据、流量、成本和稳定性。选这类项目，要看架构成熟度、运维复杂度、升级策略、数据迁移能力、高可用方案和社区响应。不能因为本地 demo 快，就直接当生产基座。

完整应用型项目，例如开源聊天平台、知识库系统、客服系统、低代码 AI 平台、智能体工作台，价值在于开箱即用，但风险在于改造边界。它们适合快速验证业务流程，却未必适合深度二开。若团队把完整应用改成自己核心系统，要特别评估前端结构、后端模块、权限模型、数据库设计、升级冲突和二开分支维护。

分清类型后，选型问题会更具体。工具可以重功能，框架要重抽象，基础设施要重可靠性，完整应用要重改造边界。不要用同一套 star、截图和 benchmark 评估所有项目。

二、不要把 star 当成成熟度

GitHub star 是关注度，不是质量保证。一个项目可能因为演示惊艳、标题抓人、正好踩中热点，在短时间内获得大量 star，但代码还很粗糙，测试很少，issue 堆积，维护者也没承诺长期维护。另一个项目 star 不多，却在某个垂直场景稳定运行多年，发布节奏清楚，文档准确，维护者认真。AI 领域尤其容易出现“热度早于成熟度”的现象。

活跃度要看趋势，而不是看总量。最近三个月是否有持续提交？提交是否集中在一个人？release 是否正常？issue 是否有人分类和关闭？PR 是否被 review？安全问题是否回应？文档是否跟随代码更新？这些比 star 更有价值。一个仓库历史很火，但最近半年几乎没有维护，就要警惕。

还要看活跃质量。大量自动依赖更新、格式化提交、文档 typo 修复，并不等于核心功能在演进。真正有意义的活跃，是 bug 修复、架构改进、性能优化、安全补丁、兼容新模型、处理用户反馈、补测试和发布迁移指南。选型时要翻 commit，而不是只看首页徽章。

issue 也要细看。issue 多不一定坏，说明用户多；issue 少也不一定好，可能没人用。关键是 issue 结构：重复问题是否有人合并，严重 bug 是否有回应，维护者是否给出路线，用户是否能提供复现，关闭原因是否合理。若 issue 里大量生产事故无人回应，说明项目不适合作为关键依赖。

PR 状态能反映社区健康。外部贡献是否能被合并？维护者是否给 review？是否有贡献指南？是否有测试要求？是否长期堆积大量无人处理 PR？如果项目表面开源，但实际只有核心团队能改，社区贡献进不去，那么它更像源代码公开的商业产品。这个模式不一定坏，但团队要按供应商风险评估，而不是按社区项目评估。

发布节奏也很关键。AI 项目需要跟随上游模型、SDK、运行时和协议变化，但发布太频繁且缺少兼容说明，也会给生产带来风险。成熟项目通常会有版本号、变更日志、弃用周期、迁移指南和安全补丁。没有 release、只让用户追 main 分支的项目，不适合严肃生产。

三、维护者结构决定长期风险

开源项目背后是谁，比项目当前长什么样更重要。维护者可以是个人、研究团队、创业公司、大厂、基金会、社区联盟或商业供应商。不同结构对应不同风险。个人项目可能响应快但可持续性弱；大厂项目资源多但路线可能服务内部战略；创业公司项目迭代快但可能转向商业闭源；基金会项目治理稳但决策慢。

要看维护者是否有明确承诺。项目是否说明维护范围、长期路线、版本策略、商业支持、社区治理和安全披露？如果维护者只说“欢迎贡献”，但没有路线图和维护策略，团队要保守使用。关键生产依赖不能只靠维护者个人热情。

单维护者风险要单独评估。一个人写出的项目可能很优秀，但如果只有一个人能理解核心代码，issue、release、安全修复都依赖他空闲时间，生产风险就高。可以看 bus factor：核心提交者有几个，是否有共同维护者，是否有组织权限，是否有备份发布流程。AI 基础设施不宜过度依赖单点维护。

商业公司维护的开源项目，要看开源版和商业版关系。开源版是否完整可用，还是只作为引流？核心功能是否逐步转入云服务？许可证是否从宽松改为限制型？issue 是否优先服务付费客户？这些不一定意味着不能选，但要把商业路线纳入风险。企业使用开源项目，最怕低估供应商战略变化。

基金会或中立组织项目通常治理更透明，例如 CNCF 项目会有不同成熟度层级，OpenSSF 和 CHAOSS 也提供项目健康和安全度量思路。虽然这些框架不能替你做决定，但可以帮助团队建立客观检查表。若项目属于成熟基金会生态，通常在治理、发布、安全和社区方面更可预期。

维护者态度也重要。好的维护者会在文档中明确不支持什么，会诚实说明限制，会拒绝不合理需求，会要求复现，会重视测试。差的维护者常见表现是过度承诺、频繁改方向、把所有问题归咎用户、用营销口号替代路线图。选型时要读维护者在 issue 和讨论区里的真实互动。

四、许可证先看业务场景

许可证不是法务最后才看的附录，而是选型第一天就要看的硬条件。开源不等于随便用，免费不等于没有义务，代码公开不等于适合商业产品。AI 项目常见许可证包括 MIT、Apache-2.0、BSD、GPL、AGPL、LGPL、MPL、Elastic License、SSPL、BUSL 以及各种自定义模型或数据许可。不同许可证对修改、分发、专利、网络服务和商业竞争有不同要求。

宽松许可证通常更适合作为生产依赖。MIT、BSD、Apache-2.0 允许商业使用、修改和分发，义务相对清楚。Apache-2.0 还包含专利授权条款，对企业更友好。若项目在基础设施层，宽松许可证可以降低长期合规和退出成本。但即使是宽松许可证，也要保留版权声明，遵守 NOTICE 要求，并确认依赖链没有冲突。

强 copyleft 许可证要谨慎评估。GPL 通常要求分发衍生作品时开放相应源代码，AGPL 还把网络服务场景纳入触发范围。对于要嵌入商业 SaaS、私有产品或闭源系统的团队，AGPL 项目尤其需要提前确认边界。不是说 AGPL 不能用，而是必须清楚使用方式、修改方式、部署方式和合规义务。

源码可见许可证不一定是开源许可证。有些项目把代码放在 GitHub，但许可证限制商业使用、限制提供托管服务、限制竞争、要求额外授权，或使用 OSI 不认可的自定义条款。这类项目可以研究、试用或按协议购买商业授权，但不应误认为“开源可随便用”。AI 领域有不少模型、数据和平台使用自定义许可，尤其要逐条读。

还要看依赖许可证。主项目是 MIT，不代表所有依赖都适合你的业务。前端组件、后端库、模型权重、数据集、评测集、字体、图标、文档模板，都可能有不同许可证。AI 应用还会把模型许可证、数据许可证和代码许可证混在一起。选型时要做依赖扫描，而不是只看根目录 LICENSE。

许可证变更风险也要考虑。开源基础设施项目在商业化压力下更换许可证并不罕见。团队应关注项目是否有 CLA、贡献者协议、版权归属、治理结构和商业主体。若项目未来改许可证，你能继续使用旧版本吗？能不能 fork？旧版本是否有足够社区维护？这些都影响长期风险。

五、架构比功能清单更重要

AI 开源项目的 README 常常功能很满：支持多模型、多向量库、多工具、多 Agent、多租户、多语言、多部署方式。选型时不能被功能清单牵着走，要看这些能力是否在架构里自然成立。一个项目如果靠大量条件分支和适配器堆出功能，短期看全能，长期会难维护。

首先看核心抽象。RAG 项目是否把加载、切分、embedding、索引、检索、重排、生成、引用和评估分清楚？Agent 项目是否把计划、工具、状态、记忆、权限、确认和追踪分清楚？模型网关是否把 provider、model、route、quota、cost、fallback 和 log 分清楚？抽象混乱的项目，二开时会处处打补丁。

其次看边界是否清晰。业务代码能否绕过框架直接调用底层？是否能替换向量库、模型供应商、存储和队列？是否支持自定义工具和中间件？是否把 UI、业务逻辑、模型调用和数据存储强耦合？一个框架若把所有东西藏在魔法链条里，demo 会很短，但排查问题会很痛苦。

再看状态管理。AI 应用不是一次函数调用，常常有多轮对话、长任务、工具步骤、文件处理、人工确认、异步结果和失败恢复。项目是否明确保存任务状态？是否支持幂等？是否能重放？是否能取消？是否能恢复中断？很多开源 Agent demo 靠内存状态跑通，进入生产就暴露问题。

还要看可观测性。项目是否记录模型调用、token、延迟、检索结果、工具参数、错误类型和用户反馈？是否能接入 OpenTelemetry、Prometheus、日志系统或第三方 LLM observability 工具？AI 系统黑箱越多，生产风险越高。没有 trace 的项目不适合承载复杂智能体。

数据模型也要仔细看。知识库、文档、切片、embedding、权限、引用、对话、工具结果、评测样本，这些数据如果设计不清，后面很难迁移。特别要看是否把业务数据和框架内部数据混在一起，是否有迁移脚本，是否支持多租户，是否能导出。数据结构一旦绑定，退出成本会快速上升。

六、性能基准要自己复测

AI 开源项目常附带 benchmark，但不能直接当作你的生产指标。benchmark 的硬件、数据、模型、并发、输入长度、输出长度、检索规模、缓存状态、网络环境和评估方法，往往与你的场景不同。推理框架、向量数据库和 RAG 系统尤其如此。看别人的测试，只能判断大致方向，不能替代自己的压测。

复测要使用真实样本。若你要做企业知识库，就用自己的文档长度、权限结构、查询类型和并发模式；若要做客服 Agent，就用真实工具延迟、错误率和用户追问；若要做代码助手，就用真实代码库大小和任务类型。只用项目自带 demo 数据，测不出生产瓶颈。

性能要分阶段看。RAG 请求包括鉴权、查询改写、向量检索、重排、上下文拼装、模型调用、引用生成和后处理。Agent 请求包括计划、工具调用、模型多轮推理、状态保存和最终确认。只看总耗时无法定位问题。选型测试要拆分各阶段耗时、token、错误和成本。

并发和长尾比平均值更重要。AI 系统常常在 P95、P99 暴露问题。少数超长文档、超大工具返回、慢供应商、检索空结果重试，会让用户体验变差。项目如果只展示平均延迟，团队要自己压测长尾。生产系统要看 P50、P95、P99、超时率、重试率和资源饱和。

成本也要纳入性能。一个框架为了提高质量，每次请求调用三次模型、两次重排、十段检索，看起来准确率提高，但成本可能不适合业务。开源项目常强调效果，不一定替你优化成本。测试时要记录每次任务 token、模型费用、向量库资源、GPU 占用和人工审核成本。

七、文档质量就是工程质量的一部分

文档不是附属品，文档质量反映项目对开发者体验和长期维护的重视程度。一个生产级开源项目应有清晰的快速开始、概念解释、配置说明、部署指南、API 参考、架构图、常见问题、升级指南、故障排查和安全说明。只有 README 和几段示例的项目，可以试验，但不宜重度依赖。

文档要看是否与代码同步。很多项目开源初期文档很漂亮，后续 API 改了，文档却没更新。开发者复制示例失败，说明项目维护流程存在问题。可以检查文档最近更新时间、示例是否被测试、issue 中是否大量出现“文档不对”。文档过期会直接增加接入成本。

好的文档会说明限制。比如支持哪些模型、不支持哪些场景、最大上下文如何处理、是否支持多租户、权限如何设计、哪些能力仍是实验性、升级可能破坏什么。只讲“支持一切”的文档不可信。成熟项目敢于说边界。

部署文档要特别看。AI 项目常涉及数据库、对象存储、向量库、队列、缓存、模型服务、GPU、浏览器沙箱和外部 API。部署文档如果只给一个 docker compose up，但没有生产建议、备份、升级、监控和安全配置，说明它离生产还有距离。开箱运行和生产可运维是两回事。

故障排查文档也很重要。模型 API 报错、embedding 失败、文档解析乱码、向量检索为空、工具调用超时、前端流式断开、权限过滤失效，这些都是常见问题。项目若能提供清晰排查路径，说明维护者理解真实使用场景。没有排查文档，团队会把大量时间花在读源码和翻 issue。

八、测试覆盖和发布纪律

AI 开源项目不一定容易测试，因为模型输出有随机性，外部 API 不稳定，端到端链路复杂。但越是这样，越要看项目如何测试。单元测试、集成测试、端到端测试、评测样本、回归用例、类型检查、lint、CI、性能测试和安全扫描，都是成熟度信号。

先看 CI 是否真实。徽章显示通过不代表测试充分。要看测试是否覆盖核心模块，是否只是跑格式检查，是否需要外部密钥，是否有 skipped 测试，是否在 PR 中强制执行。一个 AI 框架如果核心工具调用、状态恢复、检索权限和错误处理都没有测试，后续升级风险会很高。

再看 release。项目是否有语义化版本？是否有 changelog？破坏性变更是否标注？是否有迁移指南？是否能安装固定版本？是否经常直接改 main 分支？生产依赖需要可重复构建。没有发布纪律的项目，会把你的部署变成追随开发分支。

安全发布也要看。是否有安全政策？是否说明如何报告漏洞？是否响应依赖漏洞？是否使用 Dependabot 或类似机制？是否有权限、认证、SSRF、路径遍历、提示注入和任意代码执行相关检查？AI 项目常处理外部输入和文件，安全漏洞并不少见。

测试还要覆盖示例。示例项目如果长期不跑，很容易失效。高质量项目会把文档代码片段、模板和示例纳入 CI，至少保证基础路径可运行。对开发者来说，示例失败就是第一印象失败。

选型团队也要建立自己的回归测试。即使上游项目测试充分，也不能保证你的业务场景不受影响。引入项目后，要保存一组真实样本和关键流程，每次升级前跑一遍。AI 项目的升级不只是函数行为变化，还可能改变模型提示、检索排序、工具调用策略和成本。

九、权限、安全和数据边界

AI 开源项目常常为了演示方便，把权限和安全做得很轻。单用户本地运行没问题，生产多租户就会出事。选型时要看项目是否真正理解权限、认证、数据隔离和审计，而不是只在 README 里写“支持企业级”。

身份认证要明确。项目是自带账号系统，还是依赖外部 SSO？是否支持 OAuth、OIDC、SAML、LDAP？是否支持角色、团队、组织、项目？是否能和现有权限系统集成？如果项目只有一个管理员密码或简单 token，就不适合直接放进企业环境。

数据权限要贯穿整个 AI 链路。文档上传时有权限，切片后有没有权限？embedding 入库后有没有租户隔离？检索时是否过滤无权文档？引用返回时是否泄露文件名？日志中是否保存原文？导出时是否检查权限？很多 RAG 项目的权限只停留在 UI 层，后端检索并不可靠。

工具调用要分风险等级。Agent 项目如果允许模型调用外部工具，就必须支持只读、写入、人工确认、审计和回滚。只要工具能发邮件、改数据库、执行脚本、访问内网或上传文件，就不能用普通函数调用方式草率处理。选型时要看项目是否把工具权限作为核心架构，而不是示例代码。

文件处理是高风险点。AI 应用会解析 PDF、Office、图片、压缩包、网页和代码仓库。项目是否隔离文件解析？是否限制大小和类型？是否防止路径遍历和压缩炸弹？是否避免执行文件内脚本？是否能清理临时文件？文档处理链路常被忽视，但很容易成为攻击入口。

日志和观测也要有数据边界。为了调试，项目可能把用户输入、模型输出、检索片段、工具结果全写进日志。如果这些日志没有脱敏、权限和保留期限，就会成为新的泄露源。生产选型要确认日志能配置、能关闭敏感字段、能审计访问。

十、生态适配：上游和下游都要看

一个 AI 开源项目不是孤立存在，它依赖上游，也影响下游。上游包括模型 API、推理引擎、向量数据库、embedding 模型、文档解析库、浏览器驱动、认证服务和云资源。下游包括你的业务代码、前端界面、监控系统、权限系统、数据仓库和运营流程。选型时要看生态适配能力。

上游适配要看更新速度。模型供应商经常改 SDK、接口、模型名、上下文限制、工具调用格式和错误码。项目是否及时跟进？是否把 provider 差异抽象清楚？是否允许你自己写适配器？如果每次供应商变更都要等上游项目发版，你的业务会受制于人。

向量库和存储适配也要看边界。项目支持很多向量库，但是否每个都支持过滤、混合检索、批量写入、删除、更新、多租户和备份？有些适配只是能跑最小示例，生产特性并不完整。支持列表越长，越要验证你要用的那一个是否一等支持。

下游集成要看 API 和事件。项目是否提供稳定 API？是否能嵌入现有后端？是否支持 Webhook、事件流、审计日志导出、指标采集和自定义 UI？完整应用若只能通过它自己的界面使用，很难融入已有产品。框架若只能在它自己的运行时里工作，也会限制架构选择。

生态还包括人才和资料。项目是否有足够开发者熟悉？是否有中文或英文社区？是否有教程、案例、课程和第三方插件？招聘和培训成本也是选型成本。一个技术上不错但资料稀少的项目，可能适合高手小队，不适合需要规模化交付的团队。

十一、退出成本从第一天算

退出成本不是项目失败后才考虑，而是选型前就要设计。任何依赖都可能不再适合：维护停滞、许可证变化、架构不匹配、性能不够、商业路线转变、上游生态迁移、团队能力变化。好的选型不是保证永远不换，而是让未来可换。

第一类退出成本是数据绑定。项目是否把知识库、向量、对话、评测、用户、权限和任务状态存成专有格式？是否能导出原始文档、切片、元数据、embedding、引用关系和历史记录？如果只能通过项目自己的数据库读取，迁移会很痛。选型时要确认导出路径和数据字典。

第二类退出成本是代码绑定。业务代码是否到处直接使用框架内部类型？是否把 prompt、工具、检索、状态和 UI 都写在项目特定 DSL 里？是否有一层自己的领域接口？如果项目抽象侵入太深，换框架就等于重写业务。团队应在关键位置保留适配层，特别是模型调用、检索、工具和任务状态。

第三类退出成本是流程绑定。运营、客服、教师、销售或开发团队可能习惯了某个开源平台的界面、权限、审批和报表。换掉它不只是改代码，还要迁移工作流和培训人员。完整应用型项目的退出成本尤其高。选型时要问：这个系统是临时试点，还是未来要成为团队日常工作台？

第四类退出成本是生态绑定。插件、模板、评测集、自动化脚本、部署脚本、监控面板、权限策略，都会围绕项目积累。生态越丰富，迁移越难。团队要区分哪些资产是自己的，哪些资产只能在该项目内使用。尽量把业务知识、评测样本、文档和配置保存在可迁移格式里。

第五类退出成本是心理绑定。团队一旦投入数月二开，很容易继续追加投入，即使项目已经不合适。选型时应设定退出阈值：如果三个月内核心 bug 不修、许可证变化、P95 延迟达不到目标、权限无法满足、升级冲突过多，就停止加码。提前写下阈值，可以避免沉没成本绑架。

十二、试点方式决定判断质量

开源选型不能只开会比较，也不能只本地跑 hello world。最有效的方法是做一个有边界的真实试点。试点要小，但必须接近真实：用真实数据样本、真实模型、真实权限、真实并发、真实用户流程和真实部署方式。只有这样才能看出项目能不能进入生产。

试点目标要明确。比如“用该 RAG 框架完成 5000 篇内部文档检索问答，P95 首字延迟低于 3 秒，引用准确率人工抽检达到 85%，支持部门权限过滤，单次成本低于预算”；或者“用该 Agent 框架完成工单自动分类和草拟回复，工具调用成功率达到 98%，所有写入动作需人工确认”。目标越具体，结论越可靠。

试点周期不要无限延长。通常两到四周足够暴露主要问题。第一周跑通和理解架构，第二周接入真实数据，第三周做压测和权限，第四周评估升级、观测和退出路径。如果一个项目需要几个月才看懂基本架构，就要重新评估是否适合团队。

试点记录要结构化。记录安装耗时、文档准确性、改造点、遇到的 bug、上游响应、性能指标、成本、权限缺口、二开复杂度、团队学习成本和退出路径。不要只凭参与者印象做决定。试点报告最好给出“可直接采用、可作为试验、只适合参考、不建议采用”这类明确结论。

试点还要包含负面场景。模型 API 超时怎么办？向量库为空怎么办？用户无权限文档是否被过滤？工具返回错误时 Agent 是否会乱试？升级一个小版本是否破坏接口？导出数据是否完整？这些场景比正常 demo 更能说明项目成熟度。

十三、不同 AI 项目的选型重点

选 RAG 框架，重点看数据管线、权限过滤、检索质量、引用生成、评测能力和可观测性。不要只看能否上传 PDF 后问答。真正难的是文档更新、切片策略、混合检索、重排、过期资料下线、部门权限、引用校验和知识缺口运营。

选 Agent 框架，重点看工具 schema、状态管理、步骤追踪、人工确认、循环控制、错误恢复和权限。不要被“自动完成复杂任务”的演示迷惑。生产 Agent 最重要的是可控、可审计、可中止，而不是看起来自主。

选模型推理框架，重点看吞吐、延迟、显存利用、模型兼容、量化支持、并发调度、服务接口、监控、部署复杂度和升级节奏。自己的硬件、模型和请求模式必须复测。公开 benchmark 只能参考。

选向量数据库，重点看过滤能力、更新删除、备份恢复、水平扩展、混合检索、多租户、权限边界、运维成本和生态集成。只看查询速度不够。企业知识库常常败在权限和数据更新，而不是向量相似度。

选模型网关，重点看多供应商适配、错误归一、限流、预算、路由、回退、审计、用量归因和模型评测。网关如果只转发请求，价值有限；如果能承担治理和观测，才适合作为中台。

选开源 AI 应用，重点看二开边界、权限模型、数据结构、前端质量、升级冲突、插件机制和商业版关系。完整应用适合快速落地，但也最容易形成流程绑定。试点阶段要避免过早深度二开。

十四、给团队的评分表

可以把选型评分分成八类，每类 1 到 5 分。第一，功能匹配：核心能力是否解决当前问题，是否有太多不需要的复杂度。第二，活跃健康：提交、release、issue、PR、维护者结构是否稳定。第三，许可证合规：商业使用、网络服务、修改分发、依赖链和未来变更风险是否可接受。第四，架构质量：抽象、边界、状态、数据模型和扩展点是否清晰。

第五，生产能力：认证、权限、多租户、观测、部署、备份、升级、错误处理是否足够。第六，性能成本：真实样本下的延迟、吞吐、资源占用和模型成本是否达标。第七，生态适配：模型、向量库、框架、监控、身份系统和团队技术栈是否容易集成。第八，退出成本：数据、代码、流程和生态资产是否可迁移。

评分不是为了制造假精确，而是逼团队把判断写出来。每项都要有证据：链接到 issue、commit、许可证、测试结果、架构图、压测数据或试点记录。不要写“感觉不错”。选型会影响未来几年成本，必须留下可复盘依据。

还可以设置红线。许可证不允许商业使用，直接淘汰；核心数据无法导出，直接淘汰；没有明确许可证，直接淘汰；权限无法满足监管要求，直接淘汰；关键 bug 无维护回应，降级为试验项目；生产依赖只有单维护者且无替代方案，必须有内部 fork 或替换计划。红线比综合分更重要。

十五、常见误区

误区一，按 star 排名选项目。star 代表关注，不代表成熟、稳定、合规和适合你的业务。AI 热点项目尤其要看最近维护和真实试点。

误区二，认为开源就没有供应商锁定。开源项目也会通过数据结构、DSL、插件、流程和团队习惯形成锁定。源码可见不等于退出容易。

误区三，忽略许可证。等二开完成、客户要上线、法务才发现 AGPL、自定义商业限制或模型许可证冲突，返工成本会很高。

误区四，把 demo 能力当生产能力。上传文件能问答，不等于支持权限、更新、引用、监控和质量评估；Agent 能调用工具，不等于能安全执行真实业务动作。

误区五，过早深度二开完整应用。完整应用适合验证流程，但一旦大改前后端和数据库，未来升级会很痛。二开前要确认升级策略和分支维护成本。

误区六，不做自己的 benchmark。别人测试快，不代表你的文档、模型、并发、硬件和网络环境下也快。真实样本复测是必需动作。

误区七，没有退出预案。项目不合适时才发现数据导不出、业务代码到处依赖内部类型、运营流程全部绑定平台，最后只能继续补丁式维护。

误区八，用一个项目解决所有问题。AI 工程链条很长，很多时候组合几个边界清晰的工具，比引入一个全能平台更稳。全能平台只有在治理、架构和退出路径都清楚时才值得做底座。

十六、实施路径

第一步，写清楚当前问题和边界。是要解决知识库问答、模型部署、Agent 编排、内容生成、评测、监控，还是完整工作台？目标用户是谁，数据规模多大，权限要求是什么，预算和上线时间是多少。问题没写清，选型一定会被热度带偏。

第二步，列候选项目。每类最多选三到五个，不要无限比较。候选来源可以是官方生态、基金会项目、成熟商业开源项目、社区口碑项目和已有团队经验。每个候选先检查许可证、维护状态和基本架构，明显不合适的早淘汰。

第三步，做纸面筛选。看 README、文档、LICENSE、release、issue、PR、架构、部署、测试和安全政策。用评分表打初分，记录证据。纸面筛选不是最终结论，但能避免把不合规或停滞项目带进试点。

第四步，做真实试点。只选一到两个项目进入试点。用真实数据和真实流程测试功能、权限、性能、成本、观测和退出。试点过程中不要大规模二开，先看项目原生能力和扩展边界。

第五步，做风险决策。结论可以是采用、暂缓、只做参考、内部 fork、等待成熟或放弃。若采用，要写清版本、部署方式、升级策略、负责人、监控指标、许可证义务和退出预案。选型不是一次讨论，而是进入持续管理。

第六步，建立升级节奏。生产引入后，不要长期锁死老版本，也不要盲目追新。按月或按季度评估上游 release、安全修复、兼容变化和替换风险。AI 开源项目变化快，持续治理比一次选对更重要。

十七、检查清单

• 项目类型是否明确：工具、框架、基础设施、平台还是完整应用。
• 最近三个月是否有实质提交、release、issue 处理和安全修复。
• 核心维护者是否多于一人，是否有组织治理和发布权限备份。
• 许可证是否允许目标业务场景，依赖许可证是否完成扫描。
• 是否存在 AGPL、自定义商业限制、模型权重或数据许可冲突。
• 核心抽象是否清晰，是否能替换模型、向量库、存储、队列和工具。
• 是否支持认证、角色、租户、数据权限、工具确认和审计。
• 是否能记录模型调用、token、延迟、检索、工具步骤、错误和反馈。
• 是否有生产部署、备份、升级、故障排查和安全文档。
• 是否有测试、CI、changelog、语义化版本和迁移指南。
• 真实样本下的 P95 延迟、成本、错误率和质量是否达标。
• 数据、配置、评测样本和业务流程是否有明确导出和替换路径。

十八、引入之后怎样治理

选型通过不代表工作结束。开源项目一旦进入生产，就要像内部系统一样治理。团队需要指定负责人，记录当前版本、部署方式、补丁策略、许可证义务、关键配置、监控指标和回滚路径。没有负责人，依赖会慢慢变成无人维护的生产风险；没有版本记录，事故发生时很难判断是业务代码变化、上游升级还是配置漂移。

第一项治理是版本节奏。不要永远锁在试点时的版本，也不要每次上游发布就立刻升级。更稳的做法是按固定周期检查 release、漏洞、安全公告、依赖风险和兼容变化。小版本可以在测试环境滚动验证，大版本要用真实样本回归。若上游发布频率很高，团队更要有自己的升级窗口和冻结期。

第二项治理是补丁策略。生产中遇到 bug，团队可能会临时改源码。临时补丁必须有记录：改了什么、为什么改、对应上游 issue 是哪个、未来是否提交 PR、升级时如何处理。很多二开项目最后失控，就是因为每次都“先改一下”，几年后没人知道本地分支和上游差在哪里。

第三项治理是合规清单。许可证声明、NOTICE、依赖清单、模型许可、数据许可、镜像来源和安全扫描结果，都要跟随版本更新。尤其是对外发布产品或交付客户时，不能只说“我们用了开源组件”，而要能说明组件来源、许可证和义务。合规工作越早做，后期越少返工。

第四项治理是质量复盘。低满意样本、故障样本、性能异常、权限缺陷和升级冲突，要定期回到选型评分表。若项目持续暴露同类问题，就要触发替代评估，而不是无限加本地补丁。治理的目标不是证明当初选对了，而是持续判断它是否仍然适合当前业务。

第五项治理是退出演练。至少每隔一段时间验证数据是否能导出，关键接口是否能被替换，评测样本是否独立保存，部署脚本是否能重建环境。退出演练不一定意味着马上换项目，而是确认团队仍然有选择权。真正健康的开源依赖关系，是你愿意继续使用它，同时也有能力在必要时离开。

参考资料

• Open Source Initiative, Licenses：https://opensource.org/licenses
• GitHub Docs, Licensing a repository：https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
• GitHub Open Source Guides, Legal：https://opensource.guide/legal/
• OpenSSF Scorecard：https://scorecard.dev/
• OpenSSF Scorecard Checks：https://github.com/ossf/scorecard/blob/main/docs/checks.md
• OpenSSF Best Practices Badge：https://www.bestpractices.dev/en
• CHAOSS Metrics：https://chaoss.community/kbtopic/all-metrics/
• CHAOSS Community Handbook：https://chaoss.community/handbook/
• CNCF Project Maturity Levels：https://www.cncf.io/projects/
• GitHub Docs, About community profiles for public repositories：https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-community-profiles-for-public-repositories
• SPDX License List：https://spdx.org/licenses/
• Choose a License：https://choosealicense.com/