Agent Workflow 管任务怎么走，Agent Runtime 管任务在什么环境里持续运行。前者安排步骤、分支和循环，后者承接模型、工具、数据、状态、权限与执行记录。流程已经画出来，却常常卡在上线环节，缺的通常就是运行层。

ZGI 把自己放在 Agent Runtime 的位置，同时提供可视化工作流。这个组合容易理解：工作流负责把事情编排出来，Runtime 负责让它接入真实资源，并在一次次执行中留下可追踪的状态。

Workflow 先回答“下一步做什么”

以一份经营日报为例。流程可以从读取数据开始，接着计算指标，再让模型生成摘要；如果波动超过阈值，就进入人工确认，确认后发送到群里。节点顺序、判断条件、循环次数和异常分支都属于 Workflow 的范围。

它最擅长处理可描述的过程。团队能把一项任务拆成几步，知道每一步吃什么输入、产出什么结果，就能用流程把逻辑固定下来。之后改提示词、换数据源、加审批，也能在这条链上继续调整。

然而，一张流程图不会自动带来可靠运行。模型密钥放在哪里，任务以谁的身份读取数据，执行到第三步中断后从哪里继续，工具调用有没有超时，历史记录保留多久，这些问题都在流程之外。

Runtime 负责接住运行中的复杂度

Runtime 更像任务真正工作的场地。它需要让模型、知识、数据库、工具和沙箱在同一套运行规则里协作，还要记录任务身份、当前节点、输入输出与错误信息。Agent 每执行一步，环境都要知道它做了什么，还剩什么。

同样是一份经营日报，Runtime 会关心另一组问题：定时任务由哪个账号发起；数据权限能否限制到指定表；代码计算放在哪个隔离环境；模型不可用时如何处理；消息发送成功后如何避免再次发送。它们很少出现在流程画布上，却直接决定任务能否长期跑。

两者的关注点可以这样分开：

观察项	Agent Workflow	Agent Runtime
核心对象	步骤与业务逻辑	任务与运行环境
常见能力	节点、分支、循环、审批	身份、状态、资源、隔离、记录
主要产物	一条可执行流程	一次可追踪的任务运行
失败时关心	哪个节点走错	如何恢复、重试和避免副作用
团队角色	业务、产品、自动化人员	平台、研发、运维与安全团队

为什么做出 Demo 后才看到 Runtime

Demo 阶段通常只有一个人、一组测试数据和少量工具。任务失败就重跑，结果重复就手工删除，密钥临时放在配置里也能工作。这个阶段，流程是否顺畅最容易被看到。

进入业务后，执行次数增加，参与者增多，数据范围开始区分。一次工具调用可能创建工单、修改记录或发出通知，重复执行会留下真实后果。此时，任务状态和工具回执需要进入统一记录，人工也要能在关键节点接管。

还有一个常见变化：同一条流程会被多个 Agent、多个部门重复调用。若每条流程各自保存模型配置、数据库连接和工具权限，维护量会很快扩大。Runtime 提供统一承载后，流程只描述任务逻辑，公共资源由运行层管理。

选择时看清自己缺哪一层

团队目前只想验证一个明确过程，例如资料整理、表格汇总或固定审批，先把 Workflow 做通更合适。检查重点放在输入输出是否清楚、分支是否完整、人工节点是否留好。

任务准备进入内网、接触业务数据或触发外部操作时，Runtime 的检查要同步开始。至少需要确认身份传递、权限边界、状态持久化、工具隔离、失败恢复和审计记录。少一项，后续都可能靠人工补洞。

ZGI 的公开仓库包含 Agent 应用、可视化工作流、模型路由、知识与数据接入、可复用 Skill，以及可自托管的 API、Runner、Sandbox、PostgreSQL 和 Redis。它适合用来观察一个 Runtime 工作区如何把这些资源放到同一环境中。具体部署仍需结合组织现有的身份系统、网络边界与运维要求评估。

Workflow 让任务有路线，Runtime 让路线上的每一步有运行依据。把两层分开看，选型时就不会拿“能画流程”替代“能长期运行”，也不会为了简单自动化过早搭一套过重的平台。

GitHub：GitHub - zgiai/zgi: ZGI is an open-source platform for building AI applications. Its intuitive interface combines workflow design, agent orchestration, dataset management, and model integration—allowing you to quickly move from prototype to production. · GitHub

Gitee：https://gitee.com/zgiai/zgi