很多工作不是难，而是一直有人等你处理。

上午十点，销售群里有人问昨天那批线索有没有跟进，邮箱里刚好又进来一封客户回复。你顺手点开，看完之后判断“这个客户有点兴趣，下午再跟”。与此同时，运营同事丢来一张表，说晚上前要补一版数据；Notion 里多了两条用户反馈；还有一个合作方已经三天没回复，你提醒自己“今天记得再问一次”。

这些事情都不难。真正麻烦的是，它们会一直挂在脑子里。

你要记得谁还没回复，记得几点再查一次，记得某个数据异常要通知谁，记得一个任务做到哪一步，记得下班之前还欠哪件事。我们已经有了邮件、CRM、项目管理、表格、知识库和各种自动化工具，但很多时候，它们解决的是“信息放在哪里”，没有真正解决“事情发生以后，谁继续往下做”。

这可能是 Agent 真正进入工作的一个分水岭。

过去两年，大家一直在问 AI 能不能写得更好、回答得更准、代码写得更快。但当模型能力逐渐趋于充足，真正影响企业效率的问题开始从“AI 会不会”转向“AI 能不能一直把事情往下推进”。

真正有价值的 Agent，不应该只是等人提问，而应该能够在事情发生之后接住后面的工作。

提醒不是自动化，真正的自动化应该把后面的判断也接过去

我们今天已经非常习惯“通知”。

客户回邮件了，通知你；任务状态变了，通知你；数据异常了，通知你；库存变了，还是通知你。

问题是，通知只是把原来的工作换了一种方式重新交还给人。

你仍然需要打开、阅读、判断、分类，然后决定下一步做什么。换句话说，系统知道“事情发生了”，但不知道“接下来应该怎么办”。

传统自动化工具解决了一部分问题。它们非常擅长明确规则，例如“收到表单后写入表格”“订单完成后发一封邮件”“每天九点同步一次数据”。只要逻辑可以写成清晰的 If A Then B，自动化就非常高效。

但真实工作里，最耗注意力的恰恰是那些不能完全写死的部分。

客户的回复究竟是明确意向，还是礼貌性询问？一条用户反馈到底是 Bug、需求，还是单纯的使用习惯问题？某个经营指标下滑，是正常波动，还是需要立即升级？一份合同中的条款到底只是表述不同，还是存在真正风险？

这些任务需要理解上下文，也需要判断。

这也是为什么我们认为，Agent 带来的不是“自动化工具的升级版”，而是自动化开始第一次拥有了理解能力。

过去的流程是“事件发生 → 执行动作”；Agent 参与以后，它可以变成“事件发生 → 理解上下文 → 做出判断 → 调用能力 → 执行动作 → 必要时交还给人”。

这中间多出来的“理解”和“判断”，才是这一轮 AI 真正改变工作流的地方。

从“给我答案”，到“把这件事继续做下去”

假设销售团队每天会收到几十封客户邮件。

如果只是接入一个大模型，你可以把邮件复制进去，然后问：“这个客户有没有购买意向？”

AI 会给你一个答案。

但这并没有改变工作方式。因为复制邮件、发起提问、根据结果更新 CRM、通知销售，还是人在做。

真正的 Agent 工作流应该是另一种样子。

新邮件进入以后，系统自动读取内容，结合 CRM 里的历史沟通记录和企业自己的销售规则，判断客户当前所处阶段。如果只是普通咨询，可以进入标准处理流程；如果出现明确采购信号，则自动提取关键信息、写入 CRM，并通知对应销售；如果涉及特殊价格、合同或者高价值客户，则暂停自动执行，把任务交给人。

人没有消失。

只是从每一步都必须参与，变成只在真正需要判断和负责的地方出现。

这也是 ZGI 现在越来越关注的一件事：不是让 Agent 回答得更像人，而是让它能够在真实业务里承担一段完整工作。

概念示意：事件进入后先理解与判断，特殊事项转交人工确认。

为什么一个 Agent 真正开始干活以后，Runtime 会变得重要

当 Agent 只是一个聊天页面时，模型几乎就是全部。

但一旦它开始执行真实任务，情况会迅速复杂起来。

它可能需要调用 Claude 做长文本分析，用 DeepSeek 处理一批成本敏感的任务，再用企业内部模型处理敏感数据；它需要读取知识库，也需要查询数据库；它要调用 CRM、内部 API、文件工具，还可能执行一段代码。

这时候，“模型够不够聪明”只是其中一个问题。

更现实的问题是：模型怎么统一管理？工具怎么复用？任务怎么串起来？失败以后怎么追踪？谁可以调用什么？一次执行花了多少 Token？哪些环节需要人工确认？

这些问题都不属于单个 Prompt。

它们属于 Agent 的运行层。

ZGI 所做的，就是把这些原本分散的问题放进同一个 Runtime 中。模型负责理解和推理，企业知识和数据提供真实上下文，Skills 把数据库查询、文件生成、API 调用、报表制作等能力封装成可以重复调用的动作，Workflow 再把这些能力按照业务逻辑组织起来。

于是，一个 Agent 不再只是“知道应该做什么”。

它开始真正拥有“把事情做完”的能力。

Skills 的价值，不是让 AI 多会几个功能

最近开发者社区越来越频繁地讨论 Skills。

它最容易被理解成“给 Agent 装插件”，但如果放到企业环境里，它真正重要的地方其实是能力复用。

假设一个团队已经做好了一套“生成销售周报”的能力，其中包括查询数据库、处理 Excel、生成图表，再输出固定格式的文档。过去，这段能力很可能散落在脚本、Prompt 和某个人的电脑里。

如果把它变成 Skill，它就可以被不同 Agent、不同 Workflow 反复调用。

同样，一套“查询客户信息”的能力、一套“生成合同摘要”的能力、一套“调用内部系统创建任务”的能力，都可以逐渐沉淀下来。

这意味着企业 AI 的建设方式开始发生变化：从不停做新的 Agent，转向积累可以被 Agent 反复使用的能力资产。

模型会不断更换，但企业自己的能力不应该每次重新开始。

Workflow 真正改变的，是工作“怎么继续”

很多 AI 产品都能完成一次很漂亮的回答，但企业需要的不是一次回答，而是一段连续过程。

一个用户投诉可能要经历识别问题、查询订单、判断责任、生成回复、更新工单，再根据问题严重程度决定是否升级。

这些步骤中，有些适合模型判断，有些是确定性的系统操作，有些必须有人介入。

Workflow 的价值，就是把它们放进同一条链路。

在 ZGI 里，模型调用、知识检索、条件判断、循环、HTTP、数据库、代码执行、人工节点，都可以成为 Workflow 的组成部分。

真正有意思的不是“节点更多了”，而是 AI 开始能够存在于一条完整业务链路中，而不是永远停在流程入口。

Agent 越主动，企业越需要知道它到底做了什么

这也是 Agent 和普通 AI 工具最大的区别之一。

当一个聊天机器人偶尔回答错一次，影响可能有限。但如果一个 Agent 每天自动执行几百甚至几千次任务，企业就必须知道每一次执行到底发生了什么。

为什么这条流程失败？模型当时拿到了什么输入？调用了哪个模型？用了多少 Token？哪个 Skill 报错？是谁触发了这次任务？

Agent 真正进入生产环境以后，可观测性不是锦上添花，而是基础能力。

因此 ZGI 不只关心 Agent 能不能执行，也把运行日志、节点状态、输入输出、模型调用、Token 消耗、权限和成本放进同一套治理体系里。

因为我们始终认为：AI 可以越来越主动，但企业不能因此越来越不知道发生了什么。

下一阶段的竞争，可能不是谁有更多 Agent

今天大家还在比谁能更快做出一个 Agent。

但如果再往前走一步，问题可能完全不同。

未来一个企业里可能同时运行几十个甚至上百个 Agent。销售、客服、研发、运营、财务，都有自己的流程和能力。它们使用不同模型，访问不同数据，调用不同 Skills，并在不同 Workflow 中持续运行。

到那时候，企业真正缺少的就不再是一个“创建 Agent”的页面。

它需要的是一层统一的运行环境，知道这些 Agent 正在做什么、用了什么能力、消耗了多少资源、哪里出了问题，以及什么时候必须由人接管。

这也是我们理解 Agent Runtime 的原因。

ZGI 不是想让企业再多一个需要人打开的软件，而是希望让那些已经存在于邮件、表格、数据库、知识库和业务系统里的工作，被 Agent 真正接起来。

如果一定要给这件事一个最简单的判断，我会这样说：

AI 的第一阶段，是你问它答；第二阶段，是它帮你做；而真正进入企业的下一阶段，是即使你没有一直盯着，它依然知道这件事应该怎样继续。