Agent 平台覆盖智能体从创建到运营的完整工作空间常见能力包括模型接入、知识配置、工具管理、流程搭建、测试、发布、权限和监控。Agent Runtime 专门承接任务运行负责创建运行实例、保存状态、执行工具、应用权限、处理暂停与恢复并留下日志。Runtime 往往属于平台的一部分也可以作为独立服务接入其他开发工具。ZGI 定位于可自托管的 Agent Runtime同时把数据、工具、模型、记忆、Skills 和工作流组织在一个工作区中。团队在工作区配置业务能力发布后的任务再由 Runtime 承接。理解这两层关系有助于判断产品提供了哪些操作入口以及任务上线后由谁持续运行。为什么很多产品同时使用两个称呼企业采购时看到的通常是平台界面创建 Agent、选择模型、接入知识库、配置工作流再点击测试或发布。用户很容易把整套产品都理解成 Runtime。技术团队关注的重点却在界面之后例如任务状态存在哪里、工具在哪个环境执行、请求中断后能否继续。同一产品完全可以同时具备平台层和 Runtime 层。Microsoft Foundry 把模型、工具、评估、发布和治理放进统一平台内部的 Agent Runtime 负责托管 Agent、管理会话和工具调用。Amazon Bedrock AgentCore 也以平台形式提供多项能力其中 Runtime 专门承接 Agent 与工具代码的运行、会话隔离和扩展。平台管工作空间Runtime 管运行实例对比项Agent 平台Agent Runtime主要范围创建、测试、发布和运营 Agent运行一次或一批 Agent 任务常见对象模型、知识、工具、工作流、用户和项目运行实例、状态、凭据、工具调用和日志主要使用者产品、运营、开发和平台管理员平台工程、后端和运维团队关键问题能否方便地搭建并管理多个 Agent任务能否安全执行、恢复和追踪平台的功能清单很长Runtime 仍可能依赖外部工作流服务、容器平台或团队自建后端。此时需要继续确认任务编号能否贯穿多个系统权限身份是否在跨系统调用时保持一致错误状态能否返回平台界面。缺少这些连接搭建体验即使顺畅线上排查仍会分散到多个地方。一个可视化 Builder 可以属于 Agent 平台却不一定负责生产环境运行。团队在界面中画好流程后仍要确认发布动作会生成什么运行对象任务由哪个服务接收以及节点失败时的状态由谁保存。反过来独立 Runtime 可能没有完整的可视化界面只通过 API 或配置文件接收 Agent 定义。选平台时为什么还要单独检查 RuntimeDemo 阶段常验证模型能否回答、工具能否调用。任务进入实际业务后运行问题会逐渐出现用户离开页面后任务是否继续接口超时会不会重复写入审批等待期间状态能否保留不同 Agent 使用的凭据是否隔离失败记录能否关联到一次完整任务。这些问题很难从模型列表或工作流画布中看出来。选型时可以直接追问五项运行实例如何标识状态保存多久工具以谁的身份执行失败后从哪里恢复日志能否串起模型、工具和人工操作。产品能够给出具体路径Runtime 的责任才算清楚。企业应该选择平台还是 Runtime业务团队希望快速配置知识、工具和流程并统一管理多个 Agent 时完整平台更方便。企业已经拥有开发框架、门户和数据服务只缺少任务运行、隔离、状态与日志能力时独立 Runtime 更容易接入现有系统。两者也可以组合使用。平台负责提供工作空间和管理入口Runtime 负责执行企业自己的业务系统继续管理客户、订单和审批规则。上线前选一条包含工具调用、人工等待和失败重试的真实流程跑完创建、暂停、恢复和追踪通常比对照功能清单更容易看出产品边界。GitHubhttps://github.com/zgiai/zgiGiteehttps://gitee.com/zgiai/zgi