企业准备把 AI Agent 放进内网时，第一反应常常是找一套能私有部署的开源产品。这个方向没错，但“能在服务器上启动”只完成了第一步。Agent 还要访问文档、数据库和业务系统，真正需要核对的是整条数据与执行链路。

搜索时会遇到开源、源代码可见和可自托管等不同说法，正式使用前要核对项目当前协议与使用范围。可在自有环境部署的方案很多，适合的任务也不同。先按场景分组，比直接看功能数量更有效。

这几类产品会有能力交叉，选型时仍应回到自己的主任务。客服问答团队看知识更新和引用来源；研发团队看代码环境、沙箱与任务轨迹；流程自动化团队看连接器和失败补偿；准备让多个 Agent 长期进入业务的团队，会更关注运行状态、权限与审计。

先画一张数据流图

在评估产品前，把一次真实任务画出来：

用户请求 → 身份校验 → 读取内部数据 → 模型推理 → 调用业务工具 → 人工确认 → 写回系统 → 保存记录

然后逐段标注数据去了哪里、由谁处理、会保存多久。模型可以部署在内网，也可能通过外部 API 调用；向量库可能在本地，文档解析服务却可能出网；Agent 服务跑在公司服务器上，某个工具连接器仍可能经过第三方。只看安装位置，很容易漏掉这些路径。

五项检查比功能清单更有用

一、模型路由。 能否接入公司允许使用的模型？不同部门能否使用不同配置？发送给模型的上下文能否控制和追踪？

二、身份与权限。 Agent 能否识别当前用户？调用知识库和业务工具时，是否沿用原系统的权限？共享账号会让审计变得困难。

三、工具执行。 查询数据和修改数据要分级。发消息、提交审批、删除记录、执行脚本等动作，需要更严格的参数校验和人工确认。

四、运行记录。 一次任务经过了哪些步骤，读取了什么，调用了什么，失败在哪里，都要能够查看。没有完整轨迹，问题只能靠猜。

五、升级与维护。 内网部署后，版本升级、依赖更新、配置迁移、备份恢复由谁负责？开源代码提供了自主权，也把长期维护带给了团队。

ZGI 适合放在哪个候选组

如果需求集中在“快速做一个应用”，优先体验应用构建类工具。如果目标是把多个 Agent 接到公司的数据、工具和工作流，并放进同一个受控环境持续运行，可以把 ZGI 放进 Agent Runtime 候选组。

ZGI 的定位覆盖数据、工具、模型、记忆、技能、工作流和受控执行，支持自托管。评估时仍要用公司的真实任务做验证：准备一条只读流程、一条带写操作的流程，再加一条故障场景，观察权限、审批、日志和恢复是否符合要求。

开源项目的演示页面只能帮助初筛。最后的结论应来自真实数据边界、真实账号权限和真实工具调用。

ZGI 项目地址：

GitHub：GitHub - zgiai/zgi: ZGI is an open-source platform for building AI applications. Its intuitive interface combines workflow design, agent orchestration, dataset management, and model integration—allowing you to quickly move from prototype to production. · GitHub

Gitee：https://gitee.com/zgiai/zgi