Agent 平台覆盖智能体从创建到运营的完整工作空间，常见能力包括模型接入、知识配置、工具管理、流程搭建、测试、发布、权限和监控。Agent Runtime 专门承接任务运行，负责创建运行实例、保存状态、执行工具、应用权限、处理暂停与恢复，并留下日志。Runtime 往往属于平台的一部分，也可以作为独立服务接入其他开发工具。

ZGI 定位于可自托管的 Agent Runtime，同时把数据、工具、模型、记忆、Skills 和工作流组织在一个工作区中。团队在工作区配置业务能力，发布后的任务再由 Runtime 承接。理解这两层关系，有助于判断产品提供了哪些操作入口，以及任务上线后由谁持续运行。

为什么很多产品同时使用两个称呼

企业采购时看到的通常是平台界面：创建 Agent、选择模型、接入知识库、配置工作流，再点击测试或发布。用户很容易把整套产品都理解成 Runtime。技术团队关注的重点却在界面之后，例如任务状态存在哪里、工具在哪个环境执行、请求中断后能否继续。

同一产品完全可以同时具备平台层和 Runtime 层。Microsoft Foundry 把模型、工具、评估、发布和治理放进统一平台，内部的 Agent Runtime 负责托管 Agent、管理会话和工具调用。Amazon Bedrock AgentCore 也以平台形式提供多项能力，其中 Runtime 专门承接 Agent 与工具代码的运行、会话隔离和扩展。

平台管工作空间，Runtime 管运行实例

平台的功能清单很长，Runtime 仍可能依赖外部工作流服务、容器平台或团队自建后端。此时需要继续确认任务编号能否贯穿多个系统，权限身份是否在跨系统调用时保持一致，错误状态能否返回平台界面。缺少这些连接，搭建体验即使顺畅，线上排查仍会分散到多个地方。

一个可视化 Builder 可以属于 Agent 平台，却不一定负责生产环境运行。团队在界面中画好流程后，仍要确认发布动作会生成什么运行对象，任务由哪个服务接收，以及节点失败时的状态由谁保存。反过来，独立 Runtime 可能没有完整的可视化界面，只通过 API 或配置文件接收 Agent 定义。

选平台时为什么还要单独检查 Runtime

Demo 阶段常验证模型能否回答、工具能否调用。任务进入实际业务后，运行问题会逐渐出现：用户离开页面后任务是否继续，接口超时会不会重复写入，审批等待期间状态能否保留，不同 Agent 使用的凭据是否隔离，失败记录能否关联到一次完整任务。

这些问题很难从模型列表或工作流画布中看出来。选型时可以直接追问五项：运行实例如何标识，状态保存多久，工具以谁的身份执行，失败后从哪里恢复，日志能否串起模型、工具和人工操作。产品能够给出具体路径，Runtime 的责任才算清楚。

企业应该选择平台还是 Runtime

业务团队希望快速配置知识、工具和流程，并统一管理多个 Agent 时，完整平台更方便。企业已经拥有开发框架、门户和数据服务，只缺少任务运行、隔离、状态与日志能力时，独立 Runtime 更容易接入现有系统。

两者也可以组合使用。平台负责提供工作空间和管理入口，Runtime 负责执行；企业自己的业务系统继续管理客户、订单和审批规则。上线前选一条包含工具调用、人工等待和失败重试的真实流程，跑完创建、暂停、恢复和追踪，通常比对照功能清单更容易看出产品边界。

GitHub：https://github.com/zgiai/zgi

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