ZGI 正式开源企业级 Agent Runtime
企业级 Agent 平台 ZGI 已开放源码，代码可在 GitHub 获取（github.com/zgiai/zgi），原文同时列出了官网与文档地址（www.zgi.cn / docs.zgi.ai）。当前采用 ZGI Community License：个人、研究、教育及组织内部使用免费；涉及托管式多租户、白标等商业模式需商业授权。系统支持自托管部署，满足企业私有化、内网与数据隔离要求。
ZGI 定位为 Agent Runtime，而不是单纯的 Agent Builder，核心目标是解决 Agent 从 Demo 到生产落地之间的基础设施断层问题——包括模型接入、知识串联、工具调用、流程编排与运行治理的统一管理。
从“做一个机器人”到“让 AI 跑进业务”
ZGI 的设计源于企业常见的“AI 孤岛”困局：客服、研发、运营等不同团队各自接入模型（如 GPT、Claude、DeepSeek、Ollama 及私有模型），导致 API Key 分散、知识库重复建设、Workflow 维护失传、故障难以追踪。ZGI 通过统一 Workspace 整合模型、Agent、知识库、Skills、Workflow、运行记录与 API Key。
关键能力分层如下：
- Model Gateway：统一接入多种公有模型与私有模型，实现上层业务逻辑与底层模型解耦
- Skills：封装可复用能力（如经营日报生成、客户资料查询），避免脚本与 Prompt 散落各处
- Workflow：支持条件判断、循环、HTTP 调用、数据库操作、代码执行与工具调用，将 AI 纳入真实业务流程节点
- 运行治理：统一记录日志、Token 消耗、模型使用、节点状态与权限访问
容易被低估的一点在于治理投入：当执行频次达到几百到几千次/日时，日志、成本与错误追踪不再属于“附加功能”，而是生产环境的必备基础设施。
Skills：企业能力沉淀的关键层级
ZGI 明确区分“模型能力”与“Skills 能力”——前者是通用能力，后者更接近企业自身能力的沉淀。例如，销售线索处理涉及邮件读取、CRM 查询、客户意向判断、系统回写等复合动作。如果按传统方式分散开发，模型切换或能力升级往往会牵动整条业务链路。
在 ZGI 架构下：
- Skills 层封装具体动作（查数据库、生成图表、调用内部 API）
- Workflow 层编排 Skills 与模型调用
- Model Gateway 层支持按业务需要切换模型，而不影响上层流程
这意味着：业务逻辑、知识与 Skills 可持续积累，避免因模型迭代而归零重做，同时也能满足企业对私有模型、公共模型和不同任务场景的混合使用需求。
对比表：ZGI 与通用 Agent Builder 的核心差异
| 维度 | 通用 Agent Builder | ZGI |
|---|---|---|
| 定位 | 应用生成工具（拖拽式） | 企业级 Runtime 运行环境 |
| 模型管理 | 更偏向为单个应用接入模型 | 统一网关支持多模型切换 |
| 能力复用 | 逻辑常嵌入 Prompt 或单个流程 | Skills 独立抽象，可跨 Agent 复用 |
| 生产运维 | 日志、Token、权限常为后期补充 | 治理层原生集成，支持高频场景追踪 |
| 部署模式 | 常见形态包括 SaaS 托管 | 支持自托管与内网部署 |
落地建议
适合立即试用的团队：
- 已同时使用多种模型且面临配置混乱的企业
- 需将 Agent 接入 CRM、数据库或内部系统的真实业务场景
- 已开始关注 Token 成本、权限控制与运行追踪的团队
建议再等等的场景：
- 仅需简单问答 Demo、无生产级治理需求的非正式项目
- 对多租户托管服务有强依赖、禁止自建基础设施的组织
写在最后
当 Agent 从演示走向生产，决定成败的已不仅是模型本身的智能程度，更是脚下的运行底座是否开放、可控、可治理。ZGI 开源的意义，是把企业构建 AI 能力所需的基础设施层，交还给自身掌控。