如果企业现在想做一个 AI Agent，技术门槛其实已经没有两年前那么高了。接一个大模型，写一段 Prompt，挂几份文档，很快就能做出一个可以对话、可以回答问题的 Demo。
真正麻烦的，是 Demo 做出来以后。
销售团队希望 Agent 能查 CRM，运营希望它自动生成报表，研发希望它能调用内部 API，管理层又开始关心权限、日志、Token 成本和数据安全。等真正把 AI 接进业务，原本看起来很简单的“做一个 Agent”，很快就会变成一整套基础设施问题。
这也是 ZGI 选择把项目源码开放出来的原因之一。
ZGI 是一个面向企业 AI Agent 的 Runtime，通过开源代码、自托管部署，把模型、知识库、数据库、Skills、Workflow 和运行治理放进同一套体系里。它不是只帮你“做一个机器人”，而是解决 Agent 做出来以后，怎么真正跑进业务的问题。
GitHub：github.com/zgiai/zgi
一、为什么企业做 Agent，最后都会碰到“底座”问题
很多企业的 AI 建设一开始都很像。
客服团队先做一个知识问答机器人，研发团队自己接了一个 Claude API，运营又做了一套 DeepSeek Workflow，另外一个部门可能还在用内部私有模型。刚开始每个项目都能跑。
半年以后，问题就出现了。
同一个公司里有十几套模型配置，API Key 分散在不同项目里；知识库各建各的，同一份资料被重复上传；某个 Workflow 只有最初写它的人知道怎么维护；一个 Agent 出问题以后，也很难知道到底是模型、数据还是工具调用出了问题。
AI 能力越来越多，但企业内部反而形成了新的“AI 孤岛”。
所以 ZGI 做的第一件事，不是继续增加一个聊天窗口，而是把这些零散资源重新放回一个统一的 Workspace。模型、Agent、知识库、Skills、Workflow、API Key、运行记录，都可以在一套系统里持续管理。
企业真正需要的不是更多孤立的 AI 应用，而是把 AI 能力沉淀成可以复用的组织资产。
二、开源 ZGI，不只是一个 Agent Builder
现在市面上已经有很多 Agent Builder。它们可以拖几个节点、接一个模型，很快生成一个应用。
ZGI 更强调的是 Agent Runtime。
因为 Agent 一旦真正开始执行任务，它需要的不再只是一个 Prompt，而是一整条运行链路。
比如一个“销售线索 Agent”，可能需要先读取邮件内容，再查询 CRM 数据，根据历史沟通判断客户意向，然后写回系统。如果属于高价值客户，再通知销售；如果涉及特殊价格或合同，则暂停自动执行，让人确认。
这里同时涉及模型、企业数据、工具调用、Workflow 和权限。
在 ZGI 里，这些能力并不是彼此孤立的。Model Gateway 负责统一接入 GPT、Claude、DeepSeek、Qwen、Gemini、Ollama 以及企业自己的模型；知识库和数据库提供真实业务上下文；Skills 负责生成文件、查询数据、调用工具等具体动作；Workflow 再把这些能力按照业务逻辑组织起来。
所以 ZGI 想解决的是：从“AI 知道应该怎么做”，走到“AI 真的把这件事做完”。
三、模型可以换，但企业自己的 AI 能力不应该重做
大模型变化太快了。
今年某个任务用 Claude 效果最好，过几个月可能换成 GPT；批量任务可能更适合 DeepSeek，敏感业务又必须调用企业自己的私有模型。如果一个 AI 应用和某一个模型深度绑定，模型一换，业务逻辑就可能跟着调整。
ZGI 在模型层做统一管理，就是希望尽量把“模型能力”和“业务流程”拆开。上层 Agent 和 Workflow 可以保持稳定，底层模型则根据业务需要切换。
这件事在 Demo 阶段没那么明显，但到了企业生产环境非常重要。因为企业最终真正想沉淀下来的，应该是自己的业务逻辑、知识、Skills 和 Workflow，而不是对某一个模型 API 的依赖。
四、Skills：把“会做”变成企业可以复用的能力
Skills 是 ZGI 里非常重要的一层。它可以把某一种具体能力封装起来，让不同 Agent 重复调用。
例如企业可以沉淀一个“经营日报 Skill”，自动查数据库、做计算、生成图表，再输出固定格式的报告；也可以做一个“客户资料查询 Skill”，统一调用 CRM 和内部系统；甚至把内部已有的业务工具继续封装成 Agent 可以调用的能力。
过去这些东西很容易散落在脚本、Prompt 和某个人电脑里。一旦变成 Skill，它就可以被持续复用。
这也是开源 ZGI 很适合开发团队的一个地方：如果现有能力不够，可以基于自己的业务继续扩展，而不是只能等待平台官方什么时候增加某个功能。
模型是通用能力，Skills 才更接近企业自己的能力。
五、Workflow 解决的，不是“画流程图”，而是让 Agent 真正进入业务
真实企业流程很少是一问一答。
比如自动质检，可能需要读取材料、识别问题、查询规则、判断风险、生成结果，最后写回业务系统。智能客服可能要先识别问题类型，再查询知识库和订单数据，普通问题自动回答，高风险问题转人工。招聘初筛也一样：读取简历、提取关键信息、对照岗位要求、生成评估结果，最后再把真正需要面试官判断的人筛出来。
这些任务真正落地时，需要的是一条稳定 Workflow。
ZGI 可以把模型调用、知识检索、条件判断、循环、HTTP、数据库、代码执行和工具调用放进同一个流程。这时候 AI 才不是“一个会聊天的页面”，而开始成为业务流程中的一个节点。
六、Agent 越能干，企业越需要运行治理
很多团队第一次做 Agent 时，注意力都放在效果上——回答准不准，任务能不能做完。
但等真正上线以后，很快就会关心另一批问题：这条任务为什么失败？到底调用了哪个模型？用了多少 Token？哪个节点耗时最长？谁运行了这个 Agent？它访问了哪些数据？
如果一天只有十次调用，这些问题还不明显。当一天变成几百、几千次执行以后，日志、成本、权限和错误追踪就不再是附加功能，而是基本要求。
因此 ZGI 不只是做 Agent 和 Workflow，也把运行日志、Token 消耗、模型使用、节点状态、API Key 和权限管理放在 Runtime 层统一治理。Agent 可以越来越主动，但企业不能越来越不知道它做了什么。
七、为什么 ZGI 强调源码开放和自托管
当 AI 只负责写文案时，部署在哪里可能没有那么敏感。但当 Agent 开始接触企业内部知识、客户数据、数据库和业务系统以后，情况完全不同。
企业需要知道系统如何运行，也需要决定数据如何流动。
ZGI 已经开放源代码，并支持自托管部署。团队可以把相关服务部署到自己的基础设施中，连接自己的模型、知识库、数据库和内部业务服务。对于有私有化、内网部署和数据隔离要求的企业，这一点非常关键。
同时也需要说明，ZGI 当前采用的是 ZGI Community License。个人、研究、教育以及组织内部使用可以免费使用；涉及托管式多租户、白标等商业模式时，需要按照许可要求获得商业授权。
所以相比简单喊一句“完全免费”，我们更希望把 ZGI 的开源价值说清楚：源码可以看，系统可以自己部署，企业自己的 AI 能力也可以真正掌握在自己手里。
八、哪些团队更适合试 ZGI
如果只是偶尔问几个问题，一个通用 AI 聊天工具已经足够。
但如果企业已经开始同时使用多个模型，需要连接企业知识和数据库，需要让 Agent 调用工具、执行 Workflow，同时又开始关注权限、Token、日志和私有化部署，那么就已经进入 ZGI 更擅长解决的问题。
客服、销售、运营、研发、人力和内部知识管理，都可以从一个很小的场景开始。比如先做一条日报 Workflow，先搭一个知识库 Agent，或者先把一个过去每天需要人工查询和整理的数据任务交给 Agent。
目前 ZGI 也可以免费开始体验。先让一个真实任务跑通，再决定要不要继续扩展。
写在最后
过去我们谈“开源 AI”，经常关注的是模型权重有没有开放。
但当 Agent 真正进入企业以后，开源还有另一层意义。企业不仅需要一个可以使用的模型，也需要一套自己能够理解、部署、扩展和治理的运行环境。
模型决定 AI 能不能思考。知识和数据决定它懂不懂业务。Skills 决定它会不会真正做事。Workflow 决定这些能力如何协作。而 Runtime 决定这一切能不能长期运行。
这也是 ZGI 希望和“开源”建立的真正关联：不是为了再开源一个 AI Demo，而是希望把企业构建 Agent 所需要的运行底座，也变成一套可以掌握在自己手里的基础设施。
开源地址：
- GitHub：github.com/zgiai/zgi
- 官网：www.zgi.cn/
- 文档：docs.zgi.ai/
如果企业 AI 最终一定会进入真实业务，那么运行它的那一层，也应该足够开放。
