合法 JSON 只是第一道门槛
能解析的 JSON 是必要条件，但不代表字段正确。可靠抽取还需要 schema 覆盖、缺失字段纪律、日期规范化，以及不编造数值的能力。
- 把解析成功率和字段准确率分开看。
- 缺失值要明确返回 null 或说明。
- 下游系统需要纯 JSON 时，不应附加解释文字。
怎么压力测试结构
把干净样本和混乱邮件、不完整发票、模糊客服消息、矛盾日期混在一起。Agent 不应该编造来源里没有的信息。
生产护栏
使用 schema 校验、重试策略、置信标记和审计日志。涉及付款、法律或客户承诺时，人审仍应保留。
如何复用这套方法
评测方法可以被任何团队复用成小型内部评测。关键不是任务数量越多越好，而是任务必须覆盖真实工作、真实风险和真实输出格式。一个 30 条样本的认真评测，常常比 300 条泛泛 demo 更有价值。
- 先定义不可接受失败。
- 再准备代表性样本。
- 最后用同一规则比较候选 Agent。
证据应该怎样保存
建议保存原始输入、提示词版本、模型版本、运行日期、原始输出、人工评分和失败标签。这样后续模型变化、团队复盘或对外说明时，结果才可追溯。
上线前检查清单
把这套方法用于生产前，建议至少完成一次小规模复测。复测不需要复杂系统，但要覆盖真实输入、边界案例和失败后的处理方式。
- 是否有明确的人审和升级规则？
- 是否记录了模型版本和评测日期？
- 是否知道哪些输出不能直接发送或写入系统？
- 是否准备了失败后的回滚或人工接管方案？
读者可以马上做的下一步
如果你正在评估这套方法，可以从 10 条真实样本开始：3 条普通案例、3 条边界案例、2 条高风险案例、2 条格式或语言要求严格的案例。让 2 到 3 个候选 Agent 同场运行，再比较输出质量、修复时间和严重失败。