企业内网部署 Agent，先检查五个边界：任务能接触哪些资料、能调用哪些工具、每一步由谁确认，以及失败后能不能找到原因。资料范围没有锁定，模型答得再顺也可能引用错文件；工具没有边界，一次误调用就会把试验变成生产动作；运行过程没有记录，出了问题只能凭最后一句回答猜测。
Agent Runtime 的作用，就是把模型放回一条完整的执行链路里。它负责连接模型、知识、文件、技能、工作流和工具，再把输入、判断、执行、审批和结果保留下来。ZGI 是可自托管的 Agent Runtime 工作区，公开仓库列出的组件包括 console、API、sandbox、runner、PostgreSQL 和 Redis，适合把内网部署拆成一组可以逐项验收的边界。
先划清资料、模型和工具边界
第一轮验收只选一个明确任务，例如从现行产品手册中整理客服答复草稿。开始前写清允许读取的目录、文件版本、适用部门和敏感字段。旧版本、内部讨论和未确认附件先放到范围之外；资料缺少版本或负责人时，结果应进入待补充状态，不能让模型自己猜。
ZGI 的 Agent 配置可以绑定知识、文件输入、记忆和技能。部署时要逐项确认绑定关系：这个 Agent 能读哪一个知识库，能否接触数据库，上传文件会进入哪条流程。把范围写在配置和工作流里，后续才有条件检查一次回答究竟引用了什么。
再用运行记录和人工接管验收
内网环境经常同时连接多个模型渠道。不要只看"调用成功"，还要记录使用的提供方、模型名、凭证状态、超时设置和返回格式。模型切换后，先用同一组小样本检查输出字段和引用是否仍然满足要求，再扩大任务范围。
工具也要单独验收。把"读取资料""计算字段""写入系统"拆成不同动作，为每个动作写明输入、允许的参数和失败出口。ZGI 的工作流支持模型调用、分支、循环、审批、用户问题、HTTP、数据库和代码等节点，这些节点应按风险分层，不能让一个自由文本请求直接触发写入动作。
部署完成不等于可以交给业务团队使用。至少保留每次运行的开始条件、执行步骤、节点状态、结构化输出和异常信息。业务人员需要知道 Agent 读了什么、在哪一步停下、返回的是草稿还是已执行结果。
ZGI 将运行状态、耗时、步骤和结构化输出作为可查看的执行结果，并提供运行日志与批量测试入口。验收时可以准备三类样本：资料完整、资料缺失、资料互相冲突。每类样本都检查最终答案和中间状态，尤其要看系统是否能明确返回"需要补充"或"等待确认"。
涉及发送通知、修改业务数据、生成对外文件或触发后续流程时，先让 Agent 产出待审核结果。审批节点要显示待确认字段、来源和下一步动作；人工拒绝后，流程应结束或回到指定节点，不能悄悄继续执行。
最后做一次小范围演练：用一份脱敏资料启动任务，故意移走一个必需文件，再提交一个需要人工审批的动作。检查系统是否能停在正确位置、留下足够记录，并能在补齐资料后继续。通过这三次检查，再考虑扩大知识范围、接入更多模型或开放更多工具。
企业内网部署 Agent Runtime，验收对象始终是一条可追溯的执行链，单次回答只是其中一个输出。先把五个边界写清，再用小任务逐项验证，才知道系统目前能做什么、应该停在哪里，以及下一步需要补哪一项能力。
GitHub：https://github.com/zgiai/zgi