自动化常常坏在 schema 上
当下游系统期待合法 JSON 时，流畅回答并不够。团队需要测试 schema 稳定性、字段名、日期格式、缺失值，以及 Agent 是否编造数据。
- 自动校验结构。
- 把编造字段视为严重失败。
- 重复运行复测，因为格式稳定性会波动。
应该记录什么
保存原始输出、校验结果、修复后输出、缺失字段和人工修复时间。这样可靠性才不会隐藏在演示里。
决策规则
只有当抽取 Agent 能在真实样本中通过 schema 校验，并诚实处理缺失数据时，才适合进入试点。
怎么把对比结果用于真实选型
模型对比最适合作为候选清单，而不是最终采购结论。读者应该先确认自己的主要语言、任务类型、风险等级和预算，再把文章中的候选 Agent 放进同一套真实样本里复跑。
- 客服场景优先看政策边界和升级能力。
- 写作场景优先看本地语气和品牌一致性。
- 抽取场景优先看合法 JSON、缺失字段和字段准确率。
需要复核的分数盲区
平均分很容易掩盖风险。一个 Agent 可以靠大量低风险任务拉高整体表现，但在退款、法律、账单、安全声明或结构化输出中出现少数严重错误。真正上线前，必须把这些高风险任务单独拿出来看。
上线前检查清单
把这个对比用于生产前，建议至少完成一次小规模复测。复测不需要复杂系统，但要覆盖真实输入、边界案例和失败后的处理方式。
- 是否有明确的人审和升级规则？
- 是否记录了模型版本和评测日期？
- 是否知道哪些输出不能直接发送或写入系统？
- 是否准备了失败后的回滚或人工接管方案？
读者可以马上做的下一步
如果你正在评估这个对比，可以从 10 条真实样本开始：3 条普通案例、3 条边界案例、2 条高风险案例、2 条格式或语言要求严格的案例。让 2 到 3 个候选 Agent 同场运行，再比较输出质量、修复时间和严重失败。