“让 Agent 调一下系统接口”听起来像一个动作运行时却至少包含三段它要带什么资料去调用工具实际执行了什么返回结果能不能继续使用。把三段压成一个“调用工具”节点参数缺失、权限不足和返回格式变化都会在最后才暴露排查时只剩下一条失败消息。更稳的做法是把工具调用拆成准备、执行、回执三个边界。准备阶段确认输入和权限执行阶段限制动作和等待时间回执阶段检查状态、字段和下一步。ZGI 这类可自托管 Agent Runtime 可以把模型、工具、Workflow、审批和结构化输出放在同一条运行链里适合用这个三段模型设计小范围流程。准备阶段先把调用条件写成数据准备阶段的目标是把调用前必须存在的内容变成字段交给 Workflow 或规则节点检查。工具名称、接口版本、业务对象、必填参数、允许使用的身份和数据范围都应该能够被校验。库存查询需要仓库编号和商品编号工单更新还需要状态值和操作者范围缺少其中一项时运行应返回待补充让调用停在入口处。权限也要放在准备阶段确认。读取工具、写入工具和对外发送工具的风险不同工具描述里应写清楚动作范围、可访问对象和是否需要审批。这样模型负责选择合适的工具权限节点负责判断这次选择能不能执行。工具参数还应保留版本号或 schema 标识接口升级后可以在入口处发现不兼容。执行和回执要各自有停止条件执行阶段关心三件事调用做了什么、等待多久、失败后是否重试。超时、限流、网络中断和业务拒绝不应都归为“工具失败”。可以按错误类型定义一次重试、延迟重试、直接暂停或转人工写入类动作还要带幂等键避免重试把同一条记录创建两次。重试次数和总等待时间应由运行层控制不能交给模型临时决定。回执阶段不能只检查 HTTP 状态码。一个成功的响应还需要确认业务状态、关键字段和可追踪编号例如是否真的生成了工单号、返回的版本是否与请求一致、结果是否允许进入下一节点。结构化输出适合承接这些检查缺字段、状态不允许推进或回执无法关联原请求时应停在当前运行实例里留下可读的原因。把三段串进 Workflow 后Agent 的职责会变得清楚它可以根据任务选择工具、补齐自然语言意图和处理可预期的分支运行层负责参数校验、权限判断、超时、重试和回执保存。ZGI 公开能力里包含 HTTP、数据库、代码、审批、分支、循环和结构化输出等 Workflow 节点也提供运行状态、步骤和日志观察入口具体字段、权限和错误码仍需在目标环境用脱敏数据验证。接口契约发生变化时也应从回执处暴露差异。请求里记录实际使用的工具版本和参数摘要响应里保留原始状态、解析后的字段以及未识别字段后续节点只消费经过校验的结构化结果。这样升级工具时问题会停在契约检查处不会悄悄传到通知、写库或下游流程。验证时可以选一个低风险的查询任务准备“参数完整”“缺少字段”“工具返回业务拒绝”三组输入。第一轮只允许读取不开放写入检查每次运行是否记录了调用参数、工具返回、重试次数和最终状态。等三种结果都能被规则节点区分再增加写入或通知动作。若团队无法回答“这次调用带了什么、谁允许它执行、返回什么才算完成”先补齐三段边界再考虑增加工具数量。GitHubhttps://github.com/zgiai/zgiGiteehttps://gitee.com/zgiai/zgi