ZGI 企业智能体从 Demo 进入生产环境，需要完成一次运行方式的调整。演示阶段通常关注模型能否回答问题，上线后还要管理数据范围、工具权限、任务状态、人工审批和失败记录。ZGI 作为可自托管的智能体运行时（Agent Runtime），可以把 Agent、工作流（Workflow）、知识、技能（Skills）、模型和受控执行放进同一工作区，帮助团队建立可检查的运行链路。
稳定上线也不等于每次模型输出完全一致。企业更需要确认任务在规定范围内执行，关键动作有人确认，发生异常时能够找到节点、输入和工具结果。只要这些环节可以观察和处理，模型产生的变化才不会直接扩散成业务故障。
概念示意图：发布入口、权限、执行、审批和运行记录共同组成生产链路。
先把 Demo 的隐含条件写出来
Demo 往往由开发者使用管理员账号运行，资料已经准备完整，外部接口也处于正常状态。真实用户进入后，输入可能缺字段，账号只能查看部分资料，任务还可能在审批或接口超时时暂停。上线前要把这些隐含条件转成明确规则。
可以先记录五项内容：谁能使用 Agent，可以访问哪些知识，允许调用哪些工具，哪些动作需要审批，失败后从哪里继续。每一项都应有对应的测试账号和失败样本。只用管理员账号跑通一遍，无法验证普通用户看到的实际范围。
用工作区隔离资源和责任
ZGI 工作区可以组织 Agent 配置、知识、数据库、Skills 和 Workflow，并通过工作区权限控制资源使用范围。不同部门处理的数据和工具存在明显差异时，可以分别建立工作区，再决定哪些通用能力允许复用。
这样的划分也方便确定责任。知识内容由谁维护，工具凭据由谁管理，Workflow 由谁发布，异常由谁处理，都可以在上线清单里对应到具体角色。资源边界和维护责任放在一起，后续修改才不会影响无关任务。
| 上线关口 | 需要确认的内容 | 建议测试 |
|---|---|---|
| 使用入口 | WebApp、应用中心或 API | 未登录、无权限和正常账号 |
| 数据范围 | 知识、文件、数据库权限 | 跨部门资料和过期内容 |
| 工具执行 | 参数、凭据、允许动作 | 缺字段、超时和接口拒绝 |
| 人工审批 | 触发条件、审批人、等待状态 | 同意、拒绝和长时间未处理 |
| 运行记录 | 节点输入、输出、错误和结果 | 中断恢复与重复提交 |
把复杂任务放进可追踪 Workflow
以采购申请为例，Agent 先理解用户提交的物品、数量和用途，随后查询采购制度与预算信息。Workflow 负责检查字段、调用数据库、判断金额范围和发送审批。审批通过后再写入业务系统，缺少材料时通过问答节点向用户补充信息。
ZGI Workflow 支持模型调用、条件分支、循环、审批、用户问答、HTTP 请求、数据库操作和文档处理。设计时应让每个节点输出后续步骤真正需要的数据，并为外部写入保留业务对象和处理状态。任务中断后，系统才能判断应该继续等待、重新调用工具，还是交给人工处理。
发布前用批量样本检查边界
单条正常任务适合验证路径，批量样本更容易暴露边界问题。团队可以准备一组真实任务，覆盖正常输入、资料缺失、权限不足、工具超时、审批拒绝和重复提交。检查结果时，不只看最终回答，还要查看工具是否选对、节点状态是否准确、人工介入是否发生在预定位置。
ZGI 提供运行日志和可复用的批量测试能力，可以用来比较修改前后的任务表现。提示词、模型、知识或 Workflow 发生变化后，先跑固定样本，再决定是否发布。线上出现新故障时，把对应问题补进测试集，下一次修改就能检查相同问题有没有重新出现。
企业智能体上线可以先从一条高频、边界清楚的任务开始。把权限、执行、审批和记录跑顺，再逐步增加用户、工具和业务范围，扩展过程会更容易控制。
GitHub：https://github.com/zgiai/zgi