ZGI Runner 与 Sandbox：两层运行边界Runner 负责组织一次 Agent 任务的推进与状态衔接，Sa

Agent 调用模型之后，还可能检索资料、运行 Workflow、执行代码并生成文件。Runner 关注任务从哪里开始、当前走到哪一步、结果回给谁；Sandbox 关注代码和命令在哪里运行、能访问哪些文件与网络、何时停止和清理。两层配合，覆盖任务运行与执行环境两个问题。

ZGI 的自托管运行栈将 Runner 和 Sandbox 作为独立服务部署，并把代码与工具放入隔离运行环境。可以先用“任务组织层”和“受限执行层”理解两者。具体隔离方式、网络策略、资源上限和生命周期需要结合实际部署继续验证。

Runner 盯住任务的完整过程

一次任务可能包含模型调用、知识检索、条件分支、人工审批和工具执行。运行层需要维护任务标识、当前节点、输入输出、等待条件、失败状态和结果回执。外部接口超时后，还要判断继续等待、重试、转人工或结束，避免同一动作被重复执行。

Runner 在这类架构中承接任务推进。它不需要直接运行每段不可信代码，而是把执行请求交给合适环境，再接收结果并更新任务状态。这样，业务流程的生命周期不会和某个临时执行进程绑在一起。

代码节点和文件工具会接触计算资源、文件系统与网络。Sandbox 为这类动作提供受限环境，常见控制项包括可用运行时、文件范围、网络访问、执行时长和资源配额。任务完成后，还要处理文件保留、日志关联和环境清理。

隔离环境仍需配置。NIST SP 800-190 将容器安全拆到镜像、运行时、主机、注册表和编排等环节，说明“放进容器”只能提供一部分基础条件。高风险任务还要结合最小权限、依赖管理、出口限制与审计记录。

用户提交“读取销售数据并生成周报”后，Runner 先关联本次任务与调用身份，推动检索、数据库读取和 Workflow 节点。需要生成图表文件时，运行链路把明确的输入和允许动作交给 Sandbox。Sandbox 执行脚本并返回文件结果，Runner 再记录状态，把产物交给后续审批或下载环节。

如果脚本执行失败，Sandbox 返回错误和退出状态；Runner 根据流程规则决定是否重试或结束。如果用户取消任务，Runner 发出停止请求，执行环境随之终止并进入清理。两层各自留下信息，排查时可以先判断流程状态错了，还是执行环境出了问题。

Runner 侧可以测试任务中断、重复回调、审批等待和状态恢复；Sandbox 侧可以测试超时、越权文件访问、网络出口、依赖缺失和资源耗尽。随后再运行一组端到端任务，确认任务标识、日志与产物能够跨层对应。

ZGI 把 Runner 与 Sandbox 纳入同一套自托管运行栈，为两层协作提供了部署基础。上线前仍需按企业环境设置权限、网络和资源策略。分清两层职责后，故障定位、容量规划和风险检查都会更具体。