公司做了几十个 AI 小工具以后，最麻烦的事情才刚刚开始

很多公司的第一批 AI 应用，都不是规划出来的。

研发先做了一个代码助手，运营自己搭了一个内容 Agent，HR 做了简历筛选，客服又建了一个知识库机器人。大家各自找到一个模型、写几个 Prompt，很快就能跑起来。

刚开始很兴奋。

三个月以后，问题也开始出现。

有人用 GPT，有人用 Claude，还有团队自己接了 DeepSeek；知识库重复建了几套；API Key 放在不同项目里；某个 Workflow 只有做它的人知道逻辑；一个 Agent 突然花了很多 Token，却没人知道具体发生在哪一步。

AI 应用越来越多，管理方式却还停留在“个人工具”阶段。

这可能是很多企业真正开始做 AI 后都会经历的一段过程。

第一阶段的问题是：我们有没有 AI。第二阶段的问题是：这些 AI 能不能变成公司的能力。

ZGI 想解决的，更接近第二个问题。

一个企业真的需要几十个 Agent 吗？

答案很可能是需要。

客服和研发处理的问题不同，HR 和销售拥有的数据不同，财务的权限又完全不同，所以很难想象未来所有员工只使用同一个“万能 AI”。

更现实的状态，是企业内部会出现很多 Agent。

问题不是 Agent 多。

问题是它们是不是各自为战。

例如三个部门分别接 DeepSeek，可能就有三套 API Key；四个团队需要查产品资料，可能又各自建了一套知识库；同一个“生成 Excel”的能力，在不同 Agent 里重复实现。

这和十几年前企业 SaaS 快速增加时很像。

每一个工具单独看都有效率，但数量一多，就需要统一的身份、权限、数据和管理体系。

Agent 也正在经历这个过程。

所以 ZGI 并不只强调“创建 Agent”。

我们更愿意把它理解成一个 Agent Runtime Workspace：模型、知识、数据、Agent、Skills 和 Workflow 都在同一个环境里运行和管理。

第一件事：别让每一个团队重新接一次模型

过去一年模型更新的速度已经证明了一件事：企业很难长期只使用一个模型。

某项任务今天适合 Claude，明天可能换成 GPT；批量任务更看重成本时可能选择 DeepSeek，涉及内部敏感信息时又可能使用企业自建模型。

因此，ZGI 把模型放到统一的 Model Gateway 中进行管理。

它的目的不是“支持的模型越多越厉害”。

真正重要的是，上层业务不应该和某一个模型永久绑定。

一个 Workflow 已经跑了半年，企业不应该因为换一个模型供应商就重新搭一遍。

模型是一种资源。

业务逻辑才是企业自己的资产。

把这两个东西尽量拆开，是企业 AI 走向长期运行时必须做的一步。

第二件事：知识库不是越多越好，而是不要重复造

类似的问题也会发生在知识库上。

HR 上传一次员工手册，行政又上传一次；销售产品资料建一份库，客服为了回答客户问题又建一份。

半年之后，没有人知道哪一份是最新的。

所以我们更希望把知识库当成企业 AI 资产的一部分，而不是某个 Agent 的附件。

企业资料、业务文档和知识可以统一管理，再让不同 Agent 按权限调用。

需要实时信息时，也不应该什么都塞进向量库。

订单状态、库存、客户信息，这些本来就在数据库里。Agent 应该通过数据库或者 Skill 实时读取，而不是每天重新上传 Excel。

这也是为什么企业 RAG 真正难的地方从来不只是“文档怎么切片”。

而是要判断：什么应该成为知识，什么应该实时查询，谁有权限看到什么。

第三件事：把重复能力做成 Skills，而不是复制 Prompt

假设公司有五个 Agent 都需要生成 Excel。

最差的做法，是在五个 Agent 里分别写一遍“请生成 Excel”。

更合理的方式，是把“生成 Excel”做成一个统一 Skill。

同样，数据库查询、报告生成、图表制作、内部 API 调用，也可以逐渐沉淀成组织可以重复使用的 Skills。

这个变化看起来很小，但长期价值很大。

因为 Agent 会越来越多。

如果每增加一个 Agent 都重新接数据、写 Prompt、实现工具，AI 应用数量越多，维护成本反而越高。

真正可扩展的方式应该是：

Agent 在增加，但底层能力在复用。

这也是我们认为企业 Skills 会成为重要资产的原因。

概念示意：不同 Agent 复用公共能力，同时保留各自的权限与业务边界。

第四件事：Agent 很聪明，但 SOP 还是要留下来

现在 Agent 越来越强，一个常见问题是：

既然模型已经可以自己规划任务，为什么还需要 Workflow？

我们觉得两者解决的并不是同一个问题。

Agent 更擅长处理不确定性。例如“分析这份资料，决定下一步应该查什么”。

Workflow 更适合承载企业已经确定的流程。例如“审核完成以后必须经过谁审批”“金额超过多少必须暂停”“连续失败几次需要转人工”。

现实中的业务通常同时包含这两部分。

所以在 ZGI 中，Workflow 可以把模型、知识库、数据库、Skills、条件判断和人工节点放到一条链路里。

让 Agent 在适合自由判断的地方自由判断，让确定性的业务规则继续保持确定。

企业真正需要的不是 Agent 取代 Workflow。

而是：

Agent 负责灵活，Workflow 负责边界。

真正上线以后，你一定会开始问这些问题

一个 Agent 第一次跑通时，大家通常会非常关注结果。

“哇，它真的做完了。”

但当它运行到第一千次以后，关注点会完全变化。

为什么昨天失败了 17 次？哪个模型消耗最高？某个 Workflow 为什么突然变慢？这个员工能不能调用财务 Agent？一个错误结果到底来自模型还是数据库？

所以 ZGI 在 Runtime 层也关注执行记录、节点输入输出、模型使用、Token、成本以及权限等运行信息。

这些东西没有 Agent Demo 那么漂亮。

但企业最终是否敢把 AI 真正放进生产环境，很大程度上取决于它们。

软件行业已经花几十年证明了一件事：

生产系统不能只追求“能运行”。

还要可观察、可追踪、可控制。

Agent 也不会例外。

为什么选择开放源代码，而不是只做一个云端 SaaS

当企业内部只有一两个 AI 小工具时，云服务是最省事的方式。

但当 Agent 开始接触客户数据、内部知识、数据库和业务系统时，越来越多团队会希望知道整个运行环境发生了什么。

因此 ZGI 选择开放源代码，也支持自托管。

你可以在自己的基础设施中运行相关组件，连接自己的模型、数据库和内部服务，并根据实际业务继续扩展。

这里我们也希望把“开源”的边界说清楚。

ZGI 当前采用 ZGI Community License。个人、科研、教育及组织内部使用可以免费；如果要做托管式多租户、白标等特定商业用途，则需要商业授权。

我们不希望用“完全免费、随便商用”这种听起来更刺激但不准确的说法。

对于企业来说，开源真正重要的也不是省掉几张账单。

而是：

核心 AI 能力能不能看得见、改得动、部署在自己可以控制的地方。

哪些公司其实还不需要 ZGI

这也值得直接说。

如果公司现在只是偶尔用 ChatGPT 写文案、总结会议，那完全没有必要搭一套 Agent Runtime。

如果团队只有一个简单知识问答需求，一个成熟 SaaS 甚至可能更省事。

ZGI 更适合那些已经开始遇到这些问题的团队：

公司同时使用多个模型；已经出现多个 Agent 或 Workflow；需要连接企业知识、数据库和内部系统；希望沉淀公共 Skills；开始关心权限、Token、运行日志和私有部署。

也就是说，当问题从“怎么做一个 AI 应用”，慢慢变成“公司里的 AI 应用怎么统一运行”，Runtime 才真正有价值。

写在最后

AI 应用很可能会经历和 SaaS 类似的路径。

最开始，大家只关心有没有。

后来，工具越来越多。

再后来，企业发现真正的问题不是工具数量，而是这些工具如何被组织起来。

Agent 也正在走到这一步。

未来一个企业里可能有几十个甚至几百个 Agent，它们不会使用同一种模型，也不会处理同一种任务。

但企业自己的知识、数据、Skills、权限和业务流程应该可以继续积累。

模型可以换。

Agent 可以重做。

组织积累下来的 AI 能力，不应该每次从零开始。

这也是 ZGI 想做 Agent Runtime 的原因。

不是为了让公司拥有更多 AI。

而是希望那些已经被做出来的 AI，最终真的能够变成公司的能力。