“做出一个 Agent Demo 并不难，真正困难的是让它长期、稳定、可控地运行。”

近日，Agent Runtime 项目 ZGI 正式同步上线 Gitee (https://gitee.com/zgiai/zgi)，并面向开发者开放源代码和部署文档。

ZGI 由一支分布在不同城市和地区的远程团队共同开发。过去半年多，我们一直在尝试解决一件事：为 Agent 提供一套真正能够承载业务运行的基础环境。我们把它称为 Agent Runtime，也就是 Agent 运行时。

ZGI 不是一个大模型，也不只是一个创建 Agent 的页面。它更关注 Agent 被创建之后的问题：如何接入模型和知识，如何调用工具与工作流，如何记录每一步执行过程，如何管理权限、配额和用量，以及如何部署到企业自己的环境中。

从一个能跑的 Demo，到一套可以持续运行的系统

调用一个大模型接口并不难。写几段 Prompt，接入一份文档，再配置几个工具，很快就能做出一个可以对话、可以回答问题，甚至可以执行简单任务的 Agent。

但当 Agent 真正进入业务，问题会迅速变多。它可能需要在 GPT、Claude、DeepSeek、开源模型和企业私有模型之间切换；需要检索企业知识库、读取业务数据、调用外部工具；需要执行条件判断和循环，也可能在关键步骤暂停，等待人工确认。

一个完整任务可能包含十几个步骤。其中任何一步出错，团队都需要知道它使用了哪个模型、检索了哪些知识、调用了什么工具、每一步输入输出是什么、为什么失败，以及消耗了多少 Token 和费用。

这些问题已经不是再写几个 Prompt 就能解决的。模型接入、知识库、工作流、工具执行、运行日志、权限和用量通常分散在不同系统里，开发团队不得不编写大量胶水代码。ZGI 就是在这样的背景下逐渐形成的。

我们理解的 Agent Runtime

在 ZGI 中，Agent Runtime 不是一个单独功能，而是整个系统的核心。它位于模型、知识、工具和上层应用之间，承接 Agent 的实际执行过程。

当一个任务进入系统后，Runtime 需要决定调用哪个模型，是否检索知识，接下来执行哪个步骤，什么时候调用工具，什么情况下等待人工确认，以及如何保存每一步结果。

一套能够进入真实业务的 Agent Runtime，至少需要同时解决四类问题：让任务真正执行起来，让执行过程能够被观察和回看，让组织权限、配额与成本可以被管理，并让系统能够接入现有业务、部署在自己的基础设施中。

因此，ZGI 想做的不是让 Agent 看起来更聪明，而是让 Agent 的运行过程更清楚、更稳定，也更可控。

ZGI 目前提供的 Runtime 能力

统一接入和管理不同模型

ZGI 提供统一的模型接入和路由能力，可以管理 OpenAI、Claude、DeepSeek、Google、Ollama 等模型服务，也支持自定义接口和部署在企业内部的模型。模型、供应商、凭据、调用策略、价格和使用记录可以集中管理，上层 Agent 与工作流不必因为更换模型而重写整套逻辑。

把知识和数据带入 Agent 执行过程

开发者可以将企业文档、内部知识和数据库表绑定给指定的 Agent，用于搭建知识助手、客服知识库和业务查询应用。Runtime 负责在授权范围内完成检索，并把结果带入后续步骤。

真实的 RAG 不会在上传文档后自动完成。旧版本内容、表格解析、重复数据、权限隔离和召回噪声仍然需要持续治理，ZGI 也会继续优化文档处理、知识检索和引用追踪。

Agent Runtime

ZGI 的可视化工作流支持模型调用、知识检索、条件分支、循环、HTTP 请求、数据库访问、代码执行、工具调用和人工审批等节点。开发者可以直接查看节点关系、变量传递和运行状态，把已经验证的流程沉淀下来。

Skills 则用于把文件生成、图表、报告、计算、数据库查询和工作流调用等能力封装为可复用单元，减少重复编写 Prompt 和流程代码。可视化工作流并不是为了取代代码，而是为了减少维护流程胶水的成本。

查看每一次运行是怎样发生的

Agent 能不能完成任务很重要，它是怎样完成任务的同样重要。ZGI 会记录 Agent 和工作流的运行过程，包括节点输入输出、执行状态、错误信息、耗时、实际使用的模型，以及 Token 和费用数据。

当任务失败时，开发者可以判断问题来自模型理解、知识检索、工具参数，还是工作流逻辑。对长期运行的业务系统而言，可追踪的执行过程不仅用于调试，也是后续维护和责任确认的重要基础。

管理组织、权限、配额和用量

当 Agent 从个人工具变成企业系统的一部分，组织和权限会变得非常实际。ZGI 提供组织、工作空间、成员权限、模型配额和用量统计等基础能力，让不同团队在各自的授权范围内使用 Agent、知识和模型，并能够查看模型调用量及相关成本。

部署在企业自己的环境中

ZGI 支持通过 Docker 部署 Web、API、Sandbox、Runner、PostgreSQL、Redis 和向量检索服务。企业可以将系统运行在自己的服务器和网络环境中，并接入内部模型、知识库、数据库和业务服务。代码执行和工具运行由独立的 Sandbox 与 Runner 承载，使 Runtime 的执行边界更加清晰。

这个项目是怎样长出来的

ZGI 最初并不是一个规划完整的“大平台”。我们只是不断遇到具体问题，然后把它们放到同一个系统里解决。最开始是模型接入，之后是知识库和工作流；执行步骤越来越多以后，又补充了工具调用、过程记录和调试能力；进入多人使用阶段后，组织、权限、工作空间和配额管理也随之出现。

团队一直采用远程协作方式。不同成员负责后端、前端、模型接入、产品体验、文档和社区工作，通过文档、Issue、线上会议和多轮修改推进开发。这样的协作方式让我们更早意识到：复杂系统不能只依赖少数人记住所有上下文，过程必须被记录，问题必须能够被追踪。

某种程度上，远程协作对透明度和可追踪性的要求，也影响了我们对 Agent Runtime 的理解。不仅人的协作过程需要被记录，Agent 的执行过程同样需要被看见。

ZGI 此前已经在 GitHub 提供源代码，此次同步上线 Gitee，将进一步方便国内开发者和企业团队浏览代码、拉取仓库、查看文档和提交 Issue，降低访问与协作成本。

Gitee 仓库将作为持续维护的协作入口，承载文档、Issue、版本更新和社区反馈。团队也期待更多国内开发者部署 ZGI，接入自己的模型、知识和工具，实际运行一个 Agent。

更多真实运行将为 Agent Runtime 的持续优化提供直接依据。工具调用结果、执行记录、权限边界和部署体验等具体反馈，都将帮助团队进一步完善系统。

随着更多业务场景接入，ZGI 将持续优化部署流程、示例文档、Agent 执行体验、工作流编排、知识检索和过程追踪能力。

开放源代码，也将让 Agent Runtime 在更多真实任务中得到验证。来自部署、模型接入、知识检索、工具调用和流程编排等环节的反馈，将直接推动产品体验与运行能力持续演进。

欢迎一起运行和验证 ZGI

参与 ZGI 不一定要从提交复杂代码开始。你可以先把项目拉下来，接入一个模型，创建一个 Agent，上传几份文档，或者搭建一个简单的工作流。

从仓库根目录运行 make dev-docker，即可启动本地完整环境；启动后访问 http://localhost:2679，并创建第一个管理员账号。

如果部署、模型接入、知识检索、工作流或工具调用遇到问题，欢迎提交 Issue；如果某个功能设计得太重、执行过程不够清楚，或者你认为 ZGI 与现有 Agent 框架、模型网关或 RAG 平台存在能力重叠，也欢迎讨论它应该做什么、不应该做什么。

ZGI 已具备部署、运行、测试和协作基础。欢迎在 Gitee 搜索 ZGI，查看项目代码和部署文档，也欢迎 Star、Fork、提交 Issue 或通过 PR 参与开发。

来自真实运行的具体问题和建议，将帮助团队把这套 Agent Runtime 做得更加可靠。
GITTE 开源仓库地址：https://gitee.com/zgiai/zgi

许可说明：ZGI 当前采用 ZGI Community License。个人、研究、教育和组织内部使用免费；托管多租户、白标等场景需要商业许可，具体使用边界以仓库 LICENSE 为准。