OpenClaw 工作流越复杂，越不能让工具返回结果直接进入下一步。一个搜索结果过期、一个 CRM 字段缺失、一个接口返回权限不足，如果没有被识别，后面的总结、审批、写入都会跟着偏。工具输出校验器就是为这一步兜底。
它可以接在 工具调用机制 后面，也能和 结果验收、异常告警 串起来，形成从工具返回到业务交付的检查链。
先统一返回结构
不同工具返回格式各不相同，校验器第一件事是把它们转成统一结构。建议至少包含：工具名称、调用时间、来源链接或对象 ID、核心字段、更新时间、异常状态、风险等级和可继续动作。
这样 Agent 看到的不再是一段杂乱文本，而是一份带边界的证据。字段缺失时，工作流可以选择补查、降级或转人工，而不是继续生成看似完整的结论。
异常状态要比自然语言更稳定
工具报错不要只返回“请求失败”。更好的状态包括 timeout、permission_denied、empty_result、schema_changed、duplicate_record、stale_data。状态越明确，后续处理越稳定。
比如 permission_denied 应该提醒负责人检查凭证和权限；schema_changed 应该暂停写入并通知维护人；stale_data 则需要二次检索或人工确认。
风险等级决定下一步动作
校验器不只是判断成功或失败，还要给出风险等级。低风险结果可以进入下一步；中风险结果需要补充来源或二次核对；高风险结果进入 人工接管队列，不能直接写入。
如果高风险结果连续出现，可以触发 熔断与暂停，等工具、凭证或数据源恢复后再继续。
日志要能复盘校验过程
校验器的每次判断都应该写日志：原始返回摘要、校验规则、风险等级、处理动作和确认人。后面排查“为什么这条工单被升级”“为什么这次没有写入”时，才能找到证据。
这也能补充 决策日志。决策日志记录 Agent 为什么这么做，校验日志记录工具返回为什么能用或不能用。
总结
OpenClaw 工具输出校验器的价值，是在坏数据进入下游前先拦一下。字段结构、来源链接、更新时间、异常状态、风险等级和人工确认统一以后，工作流才不会因为一个错误返回一路错下去。
