Agent 输出格式总变，工作流怎么接？

Agent 把客服反馈整理成任务时，今天输出一段文字，明天换成几条列表，下游就很难稳定读取。解决办法是先约定输出字段，再用程序检查字段是否齐全、类型是否正确，随后核对负责人和来源等业务信息。只有两层检查都通过，结果才进入创建任务的步骤。

ZGI 是可自托管的智能体运行时（Agent Runtime），能把模型调用、代码处理和条件分支组织在工作流中，并查看运行步骤与结构化输出。在客服反馈转任务的流程里，可以用这些环节连接提取、校验与后续操作，具体字段规则和异常处理需要按业务设置。

从任务系统真正需要的数据开始，先列任务标题、反馈编号、负责人编号和处理优先级，再给每个字段规定用途。任务标题用于展示，反馈编号用于回查原文，负责人编号用于关联人员。把这些约定写清后，下游就能按固定字段取值，不必从整段回答里猜哪句话对应哪个位置。

字段名称相同，内容也可能不同。负责人编号不能一会儿放姓名，一会儿放账号；优先级也应使用任务系统接受的固定选项，不能随意混用"紧急"和"尽快"。给模型的说明应包含字段含义和合法示例，下游读取时仍要检查实际返回的值。

输出可以采用 JSON，也就是用键和值组织数据的文本格式，并用 JSON Schema 描述校验规则。类型约束、必填字段和额外字段处理要分别定义，仅列出字段名称并不会自动要求它必须出现。原文缺少负责人时，可以明确允许空值，并设置待补充状态，避免模型为了凑齐字段编出一个人。

空值、字段缺失和空字符串也要分开处理。空值可以表示已经检查但暂时未知，缺失可能来自生成遗漏，空字符串则可能只是没有填写内容。团队需要约定每种情况能否继续；若负责人是创建任务的必要条件，这几种情况都应停在补充信息环节。

给模型一份正确示例，能够说明期望格式，却不能替代校验。模型可能加解释文字、少输出一个字段，或把列表变成单个对象。原始输出应先保留，再交给解析与校验环节，方便定位问题出在生成、转换还是业务规则。

结构检查关注结果能否被程序按约定读取。无法解析、必填项缺失、字段类型错误，都应返回明确的错误位置；如果约定禁止额外字段，多出的内容也需要处理。不要静默丢弃异常后继续执行，否则下游拿到的结果可能已经偏离原始要求。

业务检查要回答另一组问题：反馈编号是否存在，负责人是否在当前可分配名单里，任务标题是否对应原始反馈。一个格式完整的对象，仍可能指向错误的人或错误的资料。这里适合用数据库查询和确定性规则核对，不能只让模型再读一遍并给出"通过"。

校验失败时，要把问题带回需要修正的环节。字段格式错误可以要求重新生成对应内容，并限制修正次数；来源缺失或负责人未知，则需要补充资料或人工判断。修正后应重新校验，不能把"已经改过"直接当作可执行状态。

后续节点应只接收通过检查的字段对象，供人阅读的说明可以另行保存。运行记录里保留原始输出、校验结论和最终使用值，才能查清一次任务究竟用了哪些信息。任务系统返回的创建结果还需单独核对，字段检查通过并不能证明外部操作已经成功。

验收时可以准备正常输出、缺字段、错误类型、未知负责人和无效反馈编号几类样本。逐项观察它们进入了哪条分支，尤其检查异常结果是否真的停在创建任务之前。只有正常样本能继续、异常样本能说明原因，生成结果与业务动作之间的连接才算检查完整。