最近两年，Agent 产品的名字越来越像：AI Agent、Agent Builder、Agent Framework、Agent Runtime。采购时容易把它们放进同一张表，开发时也容易混着用。结果常见：Demo 很快做出来，上线后才发现权限、状态、失败恢复和运行记录没人负责。

先把三个概念放回各自的位置。

可以把一次 Agent 任务拆成一条链路：用户提出目标，Agent 做判断，Builder 里配置的流程与工具开始工作，Runtime 负责承接身份、数据、执行状态和运行记录。三个概念彼此相连，关注点仍然不同。

Agent Builder：先解决“怎么搭”

Builder 往往提供可视化编排、提示词配置、知识库接入、工具注册和调试功能。它适合验证想法，也适合由业务团队维护变化较快的流程。

判断一个 Builder 是否好用，可以看三个细节：修改流程是否顺手，调试时能否看到每一步输入输出，工具和知识源能否重复利用。团队目前只想做一个客服助手、资料问答或简单自动化，Builder 通常已经够用。

Agent Runtime：接住上线后的复杂度

Agent 进入生产环境后，会遇到更多具体问题：任务执行到一半中断怎么办；同一个用户再次发起任务时，历史状态从哪里恢复；某个工具只允许少数人调用，权限在哪里拦截；模型或工具失败后，是否能重试、回放和审计。

这些工作属于 Runtime。它会围绕模型、数据、工具、记忆、技能和工作流提供统一的运行环境，并把身份、权限、状态、日志等能力放到执行链路中。ZGI 的公开定位就在这一层：面向业务团队的可自托管 Agent Runtime，把数据、工具、模型、记忆、技能、工作流和受控执行组织在一个工作空间里。

怎么选，先看当前卡点

如果团队还在寻找高价值场景，先用 Builder 把任务跑通，重点看结果质量和业务反馈。

如果已经有稳定场景，需要多人维护、连接内部系统、长期运行，Runtime 的优先级会快速上升。

如果团队拥有成熟研发体系，也可以用 Agent Framework 自行开发，再补齐运行和治理能力。

这里还有一个容易漏掉的判断：你买到的是“制作 Agent 的工具”，还是“承载 Agent 工作的环境”。前者能缩短搭建时间，后者决定它能否安全地进入日常业务。很多团队反复换产品，原因就在这两个目标没有拆开。

选型时直接问这 6 个问题

1. 任务状态能否保存、恢复和重放？
2. 模型、数据源和工具能否按团队统一管理？
3. 高风险动作能否增加审批或人工确认？
4. 每次执行能否查看完整链路和失败位置？
5. 开发、测试、生产环境能否分开？
6. 部署方式是否符合公司的数据边界？

这六个问题能很快看出产品偏 Builder 还是偏 Runtime。一个团队也可能同时需要两者：Builder 负责低门槛创建，Runtime 负责可靠执行。边界想清楚后，产品对比会简单很多。

ZGI 项目地址：

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

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