Agent Runtime 项目 ZGI 上线 Gitee，助力 Agent 运行更稳定可控！

【Agent 运行难题待解】有观点认为做出一个 Agent Demo 并不难真正困难的是让它长期、稳定、可控地运行。【ZGI 项目上线情况】近日Agent Runtime 项目 ZGI 正式同步上线 Gitee (https://gitee.com/zgiai/zgi)并面向开发者开放源代码和部署文档。ZGI 由一支分布在不同城市和地区的远程团队共同开发。过去半年多团队一直在尝试为 Agent 提供一套真正能够承载业务运行的基础环境即 Agent Runtime。ZGI 不是一个大模型也不只是一个创建 Agent 的页面它更关注 Agent 被创建之后的一系列问题如如何接入模型和知识如何调用工具与工作流如何记录每一步执行过程如何管理权限、配额和用量以及如何部署到企业自己的环境中。【从 Demo 到可持续系统的挑战】调用一个大模型接口不难写几段 Prompt接入一份文档再配置几个工具就能做出一个可对话、可回答问题甚至可执行简单任务的 Agent。然而当 Agent 真正进入业务问题会迅速增多。它可能需要在 GPT、Claude、DeepSeek、开源模型和企业私有模型之间切换需要检索企业知识库、读取业务数据、调用外部工具需要执行条件判断和循环也可能在关键步骤暂停等待人工确认。一个完整任务可能包含十几个步骤其中任何一步出错团队都需要了解它使用了哪个模型、检索了哪些知识、调用了什么工具、每一步输入输出是什么、为什么失败以及消耗了多少 Token 和费用。这些问题不是再写几个 Prompt 就能解决的因为模型接入、知识库、工作流、工具执行、运行日志、权限和用量通常分散在不同系统里开发团队不得不编写大量胶水代码。ZGI 就是在这样的背景下逐渐形成的。【ZGI 对 Agent Runtime 的理解】在 ZGI 中Agent Runtime 是整个系统的核心它位于模型、知识、工具和上层应用之间承接 Agent 的实际执行过程。当一个任务进入系统后Runtime 需要决定调用哪个模型是否检索知识接下来执行哪个步骤什么时候调用工具什么情况下等待人工确认以及如何保存每一步结果。一套能够进入真实业务的 Agent Runtime至少需要同时解决四类问题让任务真正执行起来让执行过程能够被观察和回看让组织权限、配额与成本可以被管理并让系统能够接入现有业务、部署在自己的基础设施中。因此ZGI 想做的是让 Agent 的运行过程更清楚、更稳定也更可控。【ZGI 目前提供的 Runtime 能力】【统一接入和管理不同模型】ZGI 提供统一的模型接入和路由能力可以管理 OpenAI、Claude、DeepSeek、Google、Ollama 等模型服务也支持自定义接口和部署在企业内部的模型。模型、供应商、凭据、调用策略、价格和使用记录可以集中管理上层 Agent 与工作流不必因为更换模型而重写整套逻辑。【把知识和数据带入 Agent 执行过程】开发者可以将企业文档、内部知识和数据库表绑定给指定的 Agent用于搭建知识助手、客服知识库和业务查询应用。Runtime 负责在授权范围内完成检索并把结果带入后续步骤。真实的 RAG 不会在上传文档后自动完成旧版本内容、表格解析、重复数据、权限隔离和召回噪声仍然需要持续治理ZGI 也会继续优化文档处理、知识检索和引用追踪。【Agent Runtime 工作流与 Skills】ZGI 的可视化工作流支持模型调用、知识检索、条件分支、循环、HTTP 请求、数据库访问、代码执行、工具调用和人工审批等节点。开发者可以直接查看节点关系、变量传递和运行状态把已经验证的流程沉淀下来。Skills 则用于把文件生成、图表、报告、计算、数据库查询和工作流调用等能力封装为可复用单元减少重复编写 Prompt 和流程代码。可视化工作流并不是为了取代代码而是为了减少维护流程胶水的成本。【查看每一次运行是怎样发生的】Agent 能不能完成任务很重要它是怎样完成任务的同样重要。ZGI 会记录 Agent 和工作流的运行过程包括节点输入输出、执行状态、错误信息、耗时、实际使用的模型以及 Token 和费用数据。当任务失败时开发者可以判断问题来自模型理解、知识检索、工具参数还是工作流逻辑。对长期运行的业务系统而言可追踪的执行过程不仅用于调试也是后续维护和责任确认的重要基础。【管理组织、权限、配额和用量】当 Agent 从个人工具变成企业系统的一部分组织和权限会变得非常实际。ZGI 提供组织、工作空间、成员权限、模型配额和用量统计等基础能力让不同团队在各自的授权范围内使用 Agent、知识和模型并能够查看模型调用量及相关成本。【部署在企业自己的环境中】ZGI 支持通过 Docker 部署 Web、API、Sandbox、Runner、PostgreSQL、Redis 和向量检索服务。企业可以将系统运行在自己的服务器和网络环境中并接入内部模型、知识库、数据库和业务服务。代码执行和工具运行由独立的 Sandbox 与 Runner 承载使 Runtime 的执行边界更加清晰。【ZGI 项目的发展历程】ZGI 最初并不是一个规划完整的大平台团队只是不断遇到具体问题然后把它们放到同一个系统里解决。最开始是模型接入之后是知识库和工作流执行步骤越来越多以后又补充了工具调用、过程记录和调试能力进入多人使用阶段后组织、权限、工作空间和配额管理也随之出现。团队一直采用远程协作方式不同成员负责后端、前端、模型接入、产品体验、文档和社区工作通过文档、Issue、线上会议和多轮修改推进开发。这种协作方式让团队更早意识到复杂系统不能只依赖少数人记住所有上下文过程必须被记录问题必须能够被追踪。某种程度上远程协作对透明度和可追踪性的要求也影响了团队对 Agent Runtime 的理解不仅人的协作过程需要被记录Agent 的执行过程同样需要被看见。ZGI 此前已经在 GitHub 提供源代码此次同步上线 Gitee将进一步方便国内开发者和企业团队浏览代码、拉取仓库、查看文档和提交 Issue降低访问与协作成本。Gitee 仓库将作为持续维护的协作入口承载文档、Issue、版本更新和社区反馈。【ZGI 的未来发展与参与方式】团队期待更多国内开发者部署 ZGI接入自己的模型、知识和工具实际运行一个 Agent。更多真实运行将为 Agent Runtime 的持续优化提供直接依据工具调用结果、执行记录、权限边界和部署体验等具体反馈都将帮助团队进一步完善系统。随着更多业务场景接入ZGI 将持续优化部署流程、示例文档、Agent 执行体验、工作流编排、知识检索和过程追踪能力。开放源代码也将让 Agent Runtime 在更多真实任务中得到验证来自部署、模型接入、知识检索、工具调用和流程编排等环节的反馈将直接推动产品体验与运行能力持续演进。参与 ZGI 不一定要从提交复杂代码开始开发者可以先把项目拉下来接入一个模型创建一个 Agent上传几份文档或者搭建一个简单的工作流。从仓库根目录运行 make dev - docker即可启动本地完整环境启动后访问 http://localhost:2679并创建第一个管理员账号。如果部署、模型接入、知识检索、工作流或工具调用遇到问题欢迎提交 Issue如果某个功能设计得太重、执行过程不够清楚或者认为 ZGI 与现有 Agent 框架、模型网关或 RAG 平台存在能力重叠也欢迎讨论它应该做什么、不应该做什么。ZGI 已具备部署、运行、测试和协作基础欢迎在 Gitee 搜索 ZGI查看项目代码和部署文档也欢迎 Star、Fork、提交 Issue 或通过 PR 参与开发。来自真实运行的具体问题和建议将帮助团队把这套 Agent Runtime 做得更加可靠。ZGI 当前采用 ZGI Community License个人、研究、教育和组织内部使用免费托管多租户、白标等场景需要商业许可具体使用边界以仓库 LICENSE 为准。