从“做出 Agent”到“让 Agent 真正运行”，ZGI 正在补上企业 AI 的下一层
过去一年，Agent 的变化非常明显。
最早大家讨论的是模型能力，是 Prompt，是怎样让 AI 回答得更准确。后来，RAG、Workflow、Tools、Skills 相继成为标准配置，Agent 开始从“回答问题”走向“执行任务”。今天，一个团队想搭出一个可以查询知识、调用工具、处理数据的 Agent，门槛已经比两年前低了很多。
但与此同时，一个新的问题也越来越清晰：做出 Agent，已经不再是最难的部分。
真正困难的，是当 Agent 开始进入业务以后，怎样让它持续、稳定、可控地运行。
它需要连接不同模型，需要使用企业自己的知识和数据，需要调用真实系统，需要执行多步骤流程；一旦任务量上来，还要处理权限、额度、日志、成本、异常、审计和部署。
这些问题过去很容易被隐藏在 Demo 后面，但当 AI 真正进入生产环境，它们会一个接一个出现。
这也是 ZGI 最近持续投入的方向。
Agent 真正进入业务以后，问题会变得完全不同
一个演示型 Agent，通常只需要回答三个问题：模型能不能调用、知识能不能检索、任务能不能完成。
一个真正运行在企业里的 Agent，要回答的问题要多得多。
同一个组织里，研发团队可能使用 Claude，运营团队使用 GPT，部分任务考虑 DeepSeek 的成本，敏感数据又要求走企业自己的私有模型。模型不再是一个固定选项，而是一个需要持续管理和调度的资源。
知识也不只是上传几份 PDF。企业真正有价值的信息分散在产品文档、业务系统、数据库、接口和内部服务里。Agent 如果无法调用这些信息，它的能力很容易停留在“会回答”，而无法进入实际业务。
Workflow 同样如此。现实中的工作往往不是输入一句话、输出一个答案，而是查询、判断、执行、审批、再执行。中间任何一步都有可能失败，也可能需要人工介入。
当这些能力被真正串在一起以后，Agent 才开始从一个 AI 功能，变成一套业务系统。
而业务系统一定需要运行层。
ZGI 关注的，正是 Agent 的 Runtime
我们现在更愿意把 ZGI 定义为一个 面向企业 AI Agent 的 Runtime。
它位于模型与业务系统之间，把模型、知识、数据、Skills、Workflow 和运行治理放在同一个环境里。
模型层，ZGI 提供统一的模型接入和管理能力。团队可以在同一套体系中使用 GPT、Claude、DeepSeek、Qwen 以及企业内部模型，并统一管理模型凭证、调用额度、使用量和成本。对于业务层来说，不需要因为底层模型变化而反复重写整套应用逻辑。
知识和数据层，ZGI 提供企业级 RAG 和结构化数据能力，让文档、知识库和业务数据可以真正成为 Agent 的上下文。对企业来说，这一步很关键，因为模型能力决定了 AI 能理解多少，而企业自己的数据，才决定 AI 到底懂不懂这家公司。
再往上，是 Skills 和 Workflow。
Skills 负责把能力沉淀下来。文件生成、数据查询、报表、计算、数据库访问、内部 API，都可以成为 Agent 可复用的能力模块，而不必每一个 Agent 都重新实现一遍。
Workflow 则负责把这些能力组织成真实流程。知识检索、模型调用、条件判断、循环、HTTP、数据库、代码执行、人工审批，都可以组合在同一条流程里。一个 Agent 不再只是完成一次回答，而是能够连续执行一项完整任务。
这也是我们一直强调的一点：企业真正需要的，不只是更聪明的模型，而是能够把模型能力组织成业务执行力的系统。
概念示意：模型、上下文与执行能力由 Runtime 组织，并受到统一治理。
能执行，还必须可治理
AI 越自主，治理越重要。
如果一个 Agent 只是在内部测试环境里回答几个问题，很多事情可以暂时忽略。但一旦它开始访问数据库、调用 API、处理客户信息，甚至执行真实业务动作，企业必须知道它在做什么。
因此，ZGI 在 Runtime 层同时提供运行日志、节点状态、输入输出、模型调用、Token 消耗、成本和错误信息的追踪能力。
一条 Workflow 为什么失败，可以回到具体节点查看；一次任务到底调用了哪个模型、用了多少 Token，也可以被记录下来。对于长期运行的 Agent，这些信息不是附加能力，而是最基本的可观测性。
权限同样如此。
不同成员能够使用哪些 Agent、访问哪些模型、调用哪些能力，需要在组织层面进行管理。模型额度、API Key、Token 预算和运行日志，也不应该散落在个人账号和个人配置里。
我们希望最终形成的是一套很清晰的边界：Agent 可以越来越主动，但它的行为必须始终可理解、可追踪、可控制。
开放源代码，是因为企业最终需要掌握自己的 AI 基础设施
ZGI 已经开放源代码，并持续在 GitHub 和 Gitee 更新。
对我们来说，这件事并不只是为了让更多人能够看到代码。
当 AI 开始接触企业自己的知识、数据和系统以后，团队理应拥有更多控制权。它应该知道这套系统如何运行，也应该能够决定它运行在哪里。
因此，ZGI 支持自托管部署。团队可以将 Web、API、Sandbox、Runner、数据库、缓存和向量检索等组件部署在自己的基础设施中，并继续连接内部模型、知识库、数据库和业务服务。
对于需要数据隔离、内网运行或者更严格安全边界的企业，这意味着 Agent 不必脱离原有 IT 体系单独存在，而可以真正成为企业技术架构的一部分。
开放源代码的意义也在这里：AI 可以越来越智能，但企业不应该因此失去对运行环境的掌控。
现在，ZGI 也可以免费开始
很多 Agent 平台的问题在于，团队需要先投入很高的验证成本，才能知道这套系统是否适合自己的业务。
ZGI 希望把这一步尽量往前移。
目前用户可以免费开始使用 ZGI，创建 Agent、连接模型、配置知识库、体验 Skills 和 Workflow，把一条真实的 Agent 链路先跑起来。
我们更希望开发者和团队先从一个具体问题开始。
可以是一个企业知识助手，可以是一条数据查询流程，可以是一个自动生成报告的 Agent，也可以是一条连接内部系统的 Workflow。
先让它真正运行一次。
因为对于 Agent 来说，真正重要的从来不是页面上写了多少功能，而是它能不能进入一个真实任务，并持续把事情做完。
Agent 的下一阶段，不会只是更多 Agent
过去一段时间，行业里出现了大量 Agent Builder。
这非常重要，因为它降低了 AI 应用的构建门槛。
但我们认为，这只是第一阶段。
当越来越多 Agent 被真正创建出来以后，企业很快会面对另一个问题：这些 Agent 如何长期共存？
未来一个企业里可能不会只有一个 AI 助手。
销售有自己的 Agent，客服有自己的 Agent，研发、运营、财务也会有各自的 Agent。它们使用不同模型，访问不同数据，拥有不同权限，并运行在不同 Workflow 中。
那时，企业真正需要的，不再只是“创建 Agent”的能力。
而是一套能够统一管理这些 Agent 如何连接模型、如何调用能力、如何执行任务、如何消耗资源，以及如何被治理的基础设施。
这也是 ZGI 对 Agent Runtime 的长期判断。
模型决定 Agent 能想多远，Runtime 决定它能不能真正跑起来。
过去，我们更多在解决“怎么让 AI 会做”。
接下来，我们更关心的是：
怎么让它在真实业务里，一直做下去。
而这正是 ZGI 正在持续构建的那一层。