过去一年，Agent 的变化有点猛。
Claude Code、Codex 这些东西已经不满足于回答问题，它们能读文件、跑命令、改项目、连续完成复杂任务。很多人顺理成章地觉得：那以后只要不断换更强的模型、接更强的 Agent 就够了。
我们在 ZGI 内部讨论了一年，结论正好反过来。Agent 越能干，"怎么管它"这个问题就越迫切。
为什么 Agent 够强了，还需要 Workflow？
这是现在经常被问到的问题。
Agent 都能自己判断、自己调工具了，Workflow 这东西不该被淘汰吗？
换个角度想：一个销售再厉害，公司为什么还需要 CRM？不是因为销售能力不够，是组织要的是稳定产出，不是随缘发挥。
Agent 解决的是单个任务怎么完成，Workflow 解决的是这些能力怎么被组织起来、长期运行。比如客户投诉，Agent 可以判断严重等级，但企业还必须规定：写进哪张表、谁收到通知、什么情况转人工、重试几次停掉。模型再聪明也长不出这些东西。
ZGI 对 Workflow 的理解是：不是为了限制 Agent，是让 Agent 的能力真正成为组织能力。
从"临时会做"到"这件事以后都交给它"
运营手动出日报、销售想自动同步 CRM、内容团队想每天扫行业网站------这类需求过去很尴尬：人工做太磨人，排研发又不够优先级。Agent 一来，随手就能把事办了。
但问题在第二次执行。
今天跑通了，明天模型升级怎么办？API 超时怎么办？数据格式变了怎么办？做这事的人离职了，这套能力还在不在？
所以 ZGI 更关心后半段------把一次"即兴完成"变成长期运行的能力。模型可以换，Workflow 保留；能力可以升级，Skill 继续复用。企业需要的不是 AI Demo，是能一直存在的 AI 能力模块。
Skills 的意义，不是多装几个插件
Skill 现在很热，很多人理解成给 Agent 装技能，像手机装 App 一样。
但 ZGI 看到的企业真正需求是另一层：把散落在人、脚本、Prompt 里的业务能力，沉淀成可重复调用的资产。一个"销售日报 Skill"封装好之后，销售能用，总监的 Agent 能用，周报的 Workflow 也能用。它不再属于某个人，变成了组织能力。模型换代，这些不用跟着重做。
企业需要的，不只是一个更聪明的 Agent
Agent 什么都能干，技术负责人看到的是另一面：用了哪个模型？花了多少 Token？访问了哪些数据？失败了是模型错还是工具错？谁有权限？误操作了能不能追溯？
这些问题在 Demo 里没人提，一上线就是门槛。
所以 ZGI 一直把重点放在运行过程本身：模型路由、运行日志、节点状态、Token 消耗、权限控制。这些不炫酷，但决定企业最终敢不敢把业务交出去。本质上就是把软件工程的原则------可观测、可控制、可恢复、可审计------重新装进 AI 时代。
Model Gateway：让模型成为企业资源，不是散落的 Key
现在没几家企业只用一家模型。长文本用 Claude，推理用 GPT，批量用便宜的，敏感业务上私有模型。每个 Agent 都自己管 Key、自己配参数，Agent 一多运维先炸。
ZGI 的 Model Gateway 解决的是：让模型成为统一管理的企业资源，而不是散落在几十个项目里的连接信息。供应商变、价格变，上层业务不用跟着重构。
开源和自托管：AI 越深入，控制权越不能交出去
Agent 只写邮件，放哪都行。一旦碰知识库、客户信息、业务系统，控制权就是合规问题。
ZGI 持续开源、支持自托管，不是为"喜欢自己部署"的开发者，是因为 AI 越深入业务，企业越应该拥有对基础设施的控制权。用自己的模型、自己的数据库、自己的基础设施，按自己的安全要求来。
未来不是超级 Agent，是一群 Agent
很多人想象最终会有一个万能 AI。ZGI 对企业的判断是：未来会有很多 Agent------销售、研发、财务、运营各有一个，模型不同、权限不同、知识不同。有些全自动，有些需协调，有些必须人机配合。
到那时候，核心竞争力不是谁家 Agent 更聪明，是能不能把这些 Agent、Skill、数据、人组织成一个长期可运行的系统。
模型负责即兴，Skill 负责能力，Workflow 负责协作，Runtime 负责让这一切跑下去。从"AI 帮我做了一次"到"这件事放心交给 AI"，中间还很长。ZGI 想做的，就是把这截路走通。