当 Agent 要批量改状态、更新字段或发送通知时，直接执行会让人很难在动作发生前发现范围错误。模型可能理解错对象，也可能把多条记录合并成一个模糊意图。把“准备改什么”和“真的改了什么”放在同一个节点里，出了问题只能事后追溯。
适合企业流程的做法，是把真实动作拆成四步：预览变更清单，人工确认清单，提交受控动作，回执核对结果。预览阶段只产生结构化草稿，不触碰目标系统；确认阶段锁定范围和字段；提交阶段只执行已确认的内容；回执阶段检查实际状态和编号。ZGI 这类可自托管 Agent Runtime 可以用 Workflow、审批、结构化输出和运行记录组织这条链路，但具体预览字段和确认策略仍需在目标环境设计。
预览要产出一份能被人检查的清单
预览结果不能只是一段“将要更新记录”的说明，而应列出对象、字段、旧值、新值、动作类型和依据。比如更新工单状态时，清单至少要能回答：涉及哪些工单，原状态是什么，准备改成什么，使用了哪条规则，哪些记录被排除。字段缺失或对象无法定位时，预览应停在待补充状态，不进入提交步骤。
预览还要固定版本。资料版本、规则版本、工具 schema 和生成时间都可以作为清单元数据，确认时一起展示。确认人批准的是这一份具体清单，不是一个会在下一次运行中重新生成的模糊意图。清单生成后如果输入资料发生变化，应重新预览，不能沿用旧确认结果。
人工确认也需要边界。低风险的字段整理可以一次确认，高风险的批量写入、对外发送或权限变化则应拆成更小批次，或者要求不同角色复核。确认动作应绑定清单摘要或版本标识，提交节点只接受已确认版本。这样即使模型在前一步提出多个方案，实际执行也只有一条被批准的路径。
提交与回执要证明“实际发生了什么”
提交阶段不再让 Agent 自由发挥，而是读取确认后的清单，逐项执行允许的动作。写入工具应限制目标范围、动作类型和批次大小；失败时保留已完成项、未完成项和失败原因，避免整批重跑造成重复修改。需要重试时，提交节点应复用清单中的动作标识，确保同一项变更可被识别。
回执阶段检查目标系统返回的实际状态，而不是只看提交请求是否发出。每一项变更最好有业务编号、最终状态和时间，无法匹配清单的结果要进入异常分支。回执与预览清单并排保存，人可以快速比较“计划改什么”和“最后改了什么”。发现差异时，流程暂停并留下人工处理点。
ZGI 的公开能力包括可视化 Workflow、审批、分支、数据库、HTTP、代码和结构化输出节点，以及运行状态、步骤和日志观察入口。这些能力可以承接预览产物、确认节点、受控提交和回执检查；文章里的“预览模式”仍是围绕真实动作设计的工程方法，不能据此推断 ZGI 已提供固定的 dry-run 开关或默认审批策略。
可以用一次低风险的字段更新验证流程：先让 Agent 只生成变更清单，准备一组范围正确、一组字段缺失和一组资料版本冲突的输入。确认阶段只批准第一组，提交后逐项回读状态。若团队能在动作发生前看懂范围，能在提交后核对差异，预览链路就有继续扩大的基础；若确认人只能看到一段自然语言摘要，就先补齐结构化清单和版本绑定。
GitHub：https://github.com/zgiai/zgi
Gitee：https://gitee.com/zgiai/zgi
