ZGI 已经在 Gitee 同步开源。对国内开发者来说这件事的意义不只是“多了一个仓库地址”而是让一个面向企业 AI 应用构建的项目能够更方便地被搜索、查看、拉取、部署和讨论。过去一段时间很多团队都在尝试用大模型做知识库、问答助手、流程自动化和内部工具但真正进入工程阶段后大家很快会发现模型只是其中一部分围绕模型的应用层能力才是长期要维护的工作。一个 AI Demo 可以很快完成。接入模型写一段 Prompt上传几份文档再加一个简单页面几个小时就能看到效果。但如果要让它服务一个团队问题会成倍增加。文档从哪里来如何清洗如何拆分如何召回答案如何溯源不同成员能看到哪些数据模型调用成本怎么控制工作流失败后怎么排查这些都不是单靠一个模型 API 就能解决的。ZGI 想解决的正是这个“模型之外”的应用层问题。它不是单纯的聊天机器人外壳而是面向知识驱动 AI 应用的开源基础设施。开发者可以基于 ZGI 构建企业知识库、RAG 应用、可视化工作流、Agent 执行链路、多模型网关和运行记录体系。换句话说ZGI 关注的是从“能回答”到“能稳定运行、能被调试、能被管理”的过程。这次同步到 Gitee也希望降低国内开发者的体验门槛。大家可以直接在 Gitee 搜索 “ZGI”进入仓库查看项目说明和部署文档。相比只看介绍真正把项目拉下来跑一遍会更容易理解它的定位它更像一个 AI 应用工程底座帮助开发者把知识、模型、工具、工作流和权限控制连接起来而不是让每个项目都从零开始拼接。对个人开发者来说ZGI 可以作为学习企业 AI 应用架构的参考。你可以看到一个 AI 应用不止包括 Prompt 和模型调用还包括数据接入、知识召回、流程编排、运行日志、权限边界、模型路由等模块。对团队来说它可以作为内部 AI 应用的起点用来验证知识库问答、智能客服、流程助理、数据查询助手等场景。我们也不希望把开源说成一个已经完成的答案。ZGI 仍然有很多地方需要改进比如部署体验、文档细节、示例工作流、插件生态和更多国内开发者常用模型的适配。正因为如此开源才有意义。开发者可以通过 Issue 反馈问题通过 Fork 做自己的尝试也可以围绕实际场景提出新的需求。如果你正在尝试做 RAG、Agent、企业知识库、模型网关或内部 AI 工具欢迎去 Gitee 搜索 ZGI阅读 README按文档完成本地部署体验。Star、Fork、Issue 都很有帮助但更重要的是把真实使用中遇到的问题反馈出来。我们希望 ZGI 不是一个单向发布的项目而是和开发者一起迭代的开源工程。