Agent Builder 解决“怎么搭”，Agent Framework 解决“怎么写”，Agent Runtime 解决“怎么持续、可控地跑”。ZGI 是一个可自托管的 Agent Runtime 工作区，适合需要在自有基础设施中构建、运行和管理多个 Agent 的团队。这里的三类概念用于理解产品重心，不是行业统一标准。
LangGraph 的官方概览同时使用 Framework 和 Runtime，OpenAI Agents SDK 也既提供开发抽象，又管理模型回合、工具执行、handoff 和 session。三个概念在真实产品里经常重叠，按名称给产品贴标签，很容易看错重点。
三个词，三段责任
Agent Builder 是组装和调试环境，用来连接模型、Prompt、知识、工具与工作流，主要产物是 Agent 配置、流程图和发布版本。Agent Framework 是开发工具，用代码表达工具调用、状态流转、handoff 和多 Agent 协作，主要产物是代码与执行逻辑。Agent Runtime 承载真实运行，通常关注任务状态、权限、隔离、恢复、审批和追踪，但不同产品覆盖的范围并不相同。
|
概念 |
主要回答的问题 |
常见使用者 |
主要产物 |
|
Agent Builder |
Agent 怎么搭 |
产品、业务、开发者 |
Agent、Workflow、发布配置 |
|
Agent Framework |
Agent 行为怎么写 |
开发者 |
代码、状态图、调用逻辑 |
|
Agent Runtime |
任务怎么持续、可控地跑 |
应用、平台与运维团队 |
Run、状态、日志、任务结果 |
这三类能力不是三选一。Dify、Coze Studio 等包含 Builder 能力的一体化平台，通常也提供执行与日志能力；LangGraph 则同时强调 Framework 和 Runtime。一体化平台可以覆盖整条链，区别在于哪部分能力更完整，以及运行后果最终由平台还是使用团队承担。
Runtime 什么时候会变重要
以合同审查 Agent 为例，Builder 负责连接合同解析、条款知识库、供应商数据和审批流程。Framework 负责表达检索、风险判断、结果合并与异常分支。Runtime 则要确认当前用户能否读取合同、解析代码在哪里执行、审批等待期间怎样保存状态、失败后从哪一步继续，以及写回系统时会不会产生重复记录。
短问答、单人 Demo 或纯读取任务，失败后重新运行一次，代价通常有限。任务一旦开始定时执行、持续数小时、运行代码、访问组织数据、发送消息或修改业务系统，状态、权限、隔离和审计就会从外围问题进入主流程。
Prompt 用来约束模型在任务中的行为，例如发送前请求确认、按权限范围处理数据。Runtime 把这些要求落实为可执行机制：审批节点保存等待状态，权限系统控制数据访问，Sandbox 提供隔离的代码执行环境，调度与状态管理负责持久化、重试和恢复。各组件分工协作，才能让 Agent 从一次回答走向可持续运行。
ZGI 放在哪里
ZGI 把自己定位为 Agent Runtime workspace，同时提供 Agent 应用与可视化 Workflow。Agent、Workflow、Skills、Knowledge、Data 和 Model Routes 用来构建任务，Runner 负责插件会话与工具调用，Sandbox 负责代码、命令、文件和 Skill 包执行，Web 与 API 提供使用入口。这套结构把构建、工具执行、代码环境与运营入口放进同一工作空间；多个 Agent 并行建设时，共享资源也能持续复用。
选型时，先别问产品属于哪一类，可以问五件事：任务中断后能否继续，工具使用谁的身份，代码能访问哪些文件和网络，高风险动作能否等待审批，日志能否还原当时发生了什么。再用审批等待、重复触发和服务重启检查状态恢复。这样一条真实任务就能把身份、隔离、恢复和追踪能力串起来。
跑起来再说。
ZGI 已在 Gitee 同步开源
ZGI 代码已在 Gitee 同步开源。想继续检查 Runtime 工作区的项目结构、部署方式和具体实现，可以直接获取代码并在自有环境中运行。
Gitee：https://gitee.com/zgiai/zgi
