Agent 越来越强，企业为什么反而更需要“运行层”？
过去一年，Agent 的变化有点像软件行业突然把“会写代码”和“会做事”之间那道墙推倒了一块。Claude Code、Codex、各种 CLI Agent 开始不再满足于回答问题，它们可以读文件、跑命令、调用工具、修改项目，甚至连续完成一段相当复杂的任务。
很多人因此会自然地得出一个结论：既然 Agent 已经越来越能干，那企业是不是只需要不断换更强的模型、接更强的 Agent 就够了？
我们反而越来越确定，答案不是。
Agent 越来越强，真正暴露出来的问题也越来越明显：“会做”只是第一步，企业真正需要的是让这种能力可组织、可复用、可追踪，并且长期运行。
这也是 ZGI 最近一直在做的事情。
不是再做一个更像人的聊天框，也不是再包装一层 Prompt，而是围绕 Agent 进入真实业务之后那些避不开的问题，把模型、知识、数据、Skills、Workflow 和运行治理放进同一套体系里。
Agent 已经足够强了，为什么还需要 Workflow？
这是现在很容易被问到的一个问题。
如果一个 Agent 已经可以自己判断、自己调用工具、自己执行任务，那为什么还要画 Workflow？为什么还要定义节点、条件、输入输出？是不是等模型再强一点，这些东西都会被淘汰？
如果把 Agent 看成一个能力很强的人，答案其实很直观。
一个人再聪明，也不意味着公司不需要流程。
销售需要 CRM，研发需要 Issue 和 CI/CD，财务有审批制度，客服有升级机制。很多工作并不是因为“员工能力不够”才需要流程，而是因为组织需要稳定、可重复、可交付。
Agent 解决的是单个任务如何完成；Workflow 解决的是这些能力如何被组织起来长期工作。
比如让 Agent 分析一封客户邮件，它可以临时判断这是不是高意向客户。但真正进入业务之后，你还需要规定：高意向客户写入哪里，谁需要收到通知，什么条件下继续自动执行，什么情况必须由销售确认，失败后是否重试，连续失败几次以后应该停止。
这部分不是模型越强就会消失。
恰恰相反，Agent 的执行能力越强，企业越需要给它清晰的边界。
这也是我们理解 Workflow 的方式：它不是为了限制 Agent，而是为了让 Agent 的能力真正成为组织能力。
概念示意：Agent 与 Workflow 各有职责，在共同的运行环境中协作。
从“临时会做”，到“这件事以后都交给它”
Agent 最令人兴奋的地方之一，是它可以快速解决大量过去“不值得专门开发”的需求。
传统软件开发有一个很现实的门槛：一个需求即使技术上只需要几百行代码，只要它足够小众，就很难排进研发计划。
比如运营团队每天都需要把几个渠道的数据整理成一份固定格式的日报；销售希望客户回复以后自动判断意向，再同步 CRM；内容团队想每天扫描一批行业网站和社区，把真正值得关注的信息整理成简报。
这些需求过去通常会落入一个尴尬地带。
人工做，重复又浪费时间；专门开发，投入产出又不够高。
Agent 改变的，恰恰是这部分需求的经济模型。
它可以临时生成脚本，可以理解非结构化内容，可以调用不同工具，还可以在任务执行过程中根据结果继续决定下一步。
但问题也随之而来：
一次能跑通，不等于以后可以放心交给它。
今天成功，明天模型换了怎么办？API 超时怎么办？数据格式改变怎么办？任务执行到第三步失败怎么办？换一个员工以后，这套能力还在不在？
所以 ZGI 更关心的是后半段：如何把一次“即兴完成”变成可以长期运行的能力。
模型可以换，Workflow 保留下来；执行能力可以升级，Skill 继续复用；知识库和数据源可以更新，但整个业务逻辑不必从头重写。
我们希望最终形成的不是一个又一个“AI Demo”，而是一块块可以持续存在于企业里的AI 能力模块。
Skills 的意义，不是给 Agent 多装几个插件
Skills 最近很热。
很多人会把它理解成“给 Agent 装技能”，像手机安装 App 一样：今天加一个 Excel Skill，明天加一个数据库 Skill，后天再装一个画图 Skill。
但从企业角度看，我们认为更有价值的是另外一层：把原本散落在人、脚本和 Prompt 里的业务能力，沉淀成可以重复调用的资产。
例如，一个“销售日报 Skill”可能并不复杂。它只需要查询几个数据源，完成汇总，调用模型分析异常，再输出固定格式的结果。
真正重要的是，一旦这套能力被封装以后，它就不再属于某一个员工的个人经验。
销售可以调用它，管理层的 Agent 可以调用它，每周经营分析的 Workflow 也可以调用它。
同样，一套“客户背景查询”的能力、一套“生成合同摘要”的能力、一套“内部知识检索”的能力，都可以逐渐成为企业自己的 AI 能力库。
这也是我们很看重 Skills 的原因。
模型会不断升级，但企业积累下来的能力，不应该随着模型一起重做。
企业需要的，不只是一个更聪明的 Agent
假设现在有一个 Agent，已经可以完成相当复杂的任务。
它可以读文件、调用数据库、生成文档、执行代码。
听起来已经很好了。
但如果你是企业里的技术负责人，很快还会继续问：
这个 Agent 到底用了哪个模型？
为什么这一轮花了这么多 Token？
它访问了哪些数据？
某一次任务为什么失败？
错误发生在模型判断，还是工具调用？
谁有权限运行它？
一旦它错误执行了某个操作，能不能追溯？
这些问题在 Demo 阶段很容易被忽略，但一旦 Agent 真正开始进入生产环境，就会变成基本要求。
所以 ZGI 一直没有把重点只放在“Agent 能完成多少事情”上。
我们更关注整个运行过程本身。
模型路由、运行日志、节点状态、输入输出、Token 消耗、成本、权限和错误信息，这些能力看起来没有一个新 Agent Demo 那么“炫”，但它们决定了企业最终敢不敢把业务真正交出去。
从这个角度看，Agent Runtime 做的事情其实很传统。
它只是把软件行业已经验证过几十年的原则重新带进 AI：
可观测、可控制、可恢复、可审计。
AI 可以越来越自主，但生产系统不能因此变得越来越不可解释。
Model Gateway 也不只是“多接几个模型”
今天一个企业同时使用多个模型，已经越来越常见。
某些长文本任务更适合 Claude，某些推理任务会用 GPT，批量处理可能更关注 DeepSeek 的成本，内部敏感业务又可能只能运行私有模型。
所以问题已经从“接哪个模型”变成了“如何管理模型”。
如果每个 Agent 都独立保存 API Key、单独维护模型配置、单独计算成本，那么 Agent 越多，企业的管理负担反而越重。
ZGI 的 Model Gateway 希望解决的是这部分问题：让模型成为一种可以统一管理的企业资源，而不是散落在几十个项目里的连接信息。
模型供应商可以变，调用策略可以变，价格也会变，但上层 Agent 和 Workflow 不应该因为这些变化反复重构。
换句话说，我们希望尽可能把“模型能力”和“业务逻辑”解耦。
这也是模型越来越快迭代以后，企业特别需要的一层能力。
开源和自托管，不只是技术团队的偏好
Agent 如果只是帮员工写几封邮件，部署在哪里可能并没有那么重要。
但一旦它开始访问企业知识库、客户信息、内部数据库，甚至能够调用真实业务系统，控制权就变成了一个非常现实的问题。
团队需要知道系统如何运行，也需要决定数据在哪里流转，哪些服务可以访问，哪些能力必须留在内网。
所以 ZGI 持续开放源代码，并支持自托管。
这不仅是为了满足“喜欢自己部署”的开发者。
它背后其实有一个很简单的判断：
AI 越深入业务，企业就越应该拥有对基础设施的理解权和控制权。
你可以使用自己的模型，可以接自己的数据库，可以运行在自己的基础设施里，也可以根据内部安全和合规要求继续扩展。
我们认为，这会是企业真正长期使用 Agent 时绕不开的一件事。
一个更现实的未来：不是“一个超级 Agent”，而是一群 Agent 在工作
关于 AI 的未来，有一种很常见的想象：最终会出现一个无所不能的超级助手，所有事情都交给它。
我们对企业场景的判断可能稍微不同。
未来一个组织里，更可能存在很多 Agent。
销售 Agent 懂客户和 CRM，研发 Agent 熟悉代码和文档，财务 Agent 关注数据和流程，运营 Agent 长期处理内容、数据和外部信息。
它们使用的模型不同，权限不同，知识不同，调用的 Skills 也不同。
有些任务可以完全交给 Agent，有些任务需要 Workflow 协调多个 Agent，有些则必须在人和 Agent 之间来回切换。
到那时候，真正有价值的可能不再是“谁又做出了一个 Agent”。
而是谁能把这些 Agent、Skills、数据和人，组织成一个长期可运行的系统。
这也是 ZGI 对 Agent Runtime 的长期理解。
我们并不认为 Workflow 会被 Agent 取代，也不认为越来越聪明的模型会让基础设施失去价值。
恰恰相反。
Agent 越强，组织能力就越重要。
模型负责即兴。
Skills 负责能力。
Workflow 负责协作。
Runtime 负责让这一切真的跑下去。
从一次“AI 帮我做完了”，到“这件事以后可以放心交给 AI”，中间还有很长一段距离。
而 ZGI 想做的，正是把这段距离缩短。