在AI Agent、自动化数据分析、后端接口开发场景，结构化JSON输出是刚需。很多开发者选型时，会凭零散测试结果判定某款模型指令遵循差、生成JSON容易报错。前段时间基于OCaml编写Agent运行框架PAR，需要稳定的结构化返回能力，于是搭建了一套完全公平的标准化测试，横向对比当下热门的GLM-5.2、MiniMax-M2.7、MiniMax-M3三款国产大模型。

本次测试全程不依赖厂商原生response_format接口，统一依靠提示词约束+后置JSON修复循环，最大程度还原真实业务中无专属API兜底的开发环境。如果团队同时对接多家模型厂商，可借助TreeRouter统一管理多模型密钥，不用单独维护多套接口地址。下文完整保留测试参数、代码片段、实测耗时与统计数据，同时复盘测试踩过的关键坑点。

一、标准化测试全流程设计

1.1 统一测试路径，保证公平对比

本次全部调用走降级链路：System强约束提示词+文本JSON提取+Schema校验+最多3轮修复重试。

这么设计的核心原因：MiniMax全系模型不兼容OpenAI标准response_format参数，智谱GLM-5.2原生端点同样采用兼容降级方案，统一链路可以屏蔽厂商API实现差异，只对比模型本身的指令遵循能力。

1.2 全局固定调用参数


temperature = 0.0

max_tokens = 2000

max_repair_attempts = 3

temperature置0消除随机波动，最大重试3次模拟生产环境容错逻辑。

1.3 6类梯度测试场景，覆盖全部结构化难点

从简单单层对象、混合数据类型、嵌套数组、枚举约束逐层提升复杂度：

  1. country-fr：基础字符串对象，校验基础JSON格式；

  2. country-jp：同Schema不同主题，验证输出稳定性；

  3. movie：string/integer/number混合类型，难点是区分数字与字符串；

  4. book：复用电影Schema，跨领域一致性校验；

  5. todo：外层对象嵌套数组，MiniMax原版测试最容易裸数组出错；

  6. word：枚举category约束，双重指令限制考验模型约束力。

以待办列表场景Schema为例：


{

  "type": "object",

  "properties": {

    "items": {"type": "array"},

    "count": {"type": "integer"}

  },

  "required": ["items", "count"]

}

1.4 自动化执行脚本与调用流程

基于OCaml脚本verify_structured.ml批量执行，每款模型跑20轮完整6场景，合计120次调用，仅切换环境变量切换模型：


# GLM-5.2 启动命令

OPENAI_API_KEY="xxx" OPENAI_BASE_URL="https://open.bigmodel.cn/api/coding/paas/v4" \

dune exec examples/verify_structured.exe

单次调用核心逻辑：下发强约束System提示词→获取模型返回→提取JSON→校验Schema；解析/校验失败则追加修复提示词重试，3次失败标记调用失败。

1.5 三款模型耗时实测对比

| 模型 | 120次总耗时 | 单次平均耗时 | 核心原因 |

| ---- | ---- | ---- | ---- |

| GLM-5.2 | ~8分钟 | ~4秒 | 几乎无需重试，1次调用即成功 |

| MiniMax-M2.7 | ~25分钟 | ~12秒 | 频繁触发修复循环，总调用量翻倍 |

| MiniMax-M3 | ~25分钟 | ~12秒 | 与M2.7表现一致，重试次数相近 |

二、测试重大弯路：误判模型能力，根源是工具链缺陷

首轮测试未做特殊处理时，MiniMax-M3整体成功率仅40.8%，M2.7为82.5%，一度判定两款模型结构化输出远弱于GLM-5.2。排查原始响应后找到问题：

MiniMax模型会默认输出推理过程前置块，推理内容内的花括号干扰JSON平衡括号提取逻辑，同时推理块占用token，导致JSON被截断。

修复方案：新增剥离think标签工具函数，同时将max_tokens从500上调至2000：


let strip_think text =

  match find_sub text "" with

  | Some i -> String.trim (String.sub text (i + 8) (String.length text - i - 8))

  | None -> text

修复后所有偏差全部消失，三款模型综合数据拉平。

三、修正后完整测试数据

3.1 整体指标汇总

| 指标 | GLM-5.2 | MiniMax-M2.7 | MiniMax-M3 |

| ---- | ---- | ---- | ---- |

| 总成功率 | 100% | 100% | 100% |

| Schema校验通过率 | 100% | 100% | 100% |

| 平均尝试次数 | 1.0 | 1.1 | 1.0 |

3.2 分场景通过率

6类场景下三款模型全部100%通过，数组嵌套、枚举约束等复杂结构均无格式错误、类型错误。

3.3 综合评级与选型建议

  1. GLM-5.2：无推理标签，输出文本干净，首次成功率接近99%，适合对接口延迟敏感、不想额外处理文本的场景；

  2. MiniMax-M2.7 / M3：推理内容丰富，仅需增加一段剥离``的预处理逻辑，结构化能力完全对标GLM-5.2，复杂推理类Agent任务更适配。

四、本次测试带来的方法论启示

  1. 模型对比先排除工具干扰

很多开发者做评测时直接将结果差异归因为模型能力，忽略中间层解析、token限制、特殊输出标签带来的干扰，得出完全相反的结论。本次测试就是典型案例，工具缺陷造成M3“拉胯”的假象。

  1. 结构化输出测试必须覆盖多梯度场景

只测简单单层JSON无法暴露数组、枚举、多类型混合等边界问题，生产环境下绝大多数报错都来自复杂嵌套结构。

  1. 生产环境建议内置修复循环

即便旗舰模型，少量场景仍会出现格式偏差，3次以内的轻量重试机制，能大幅提升服务稳定性。

五、总结

经过标准化、无差异化链路测试，GLM-5.2、MiniMax-M2.7、MiniMax-M3三款国产主流模型在结构化JSON输出上均达到生产可用标准，整体成功率、Schema合规率全部100%。二者核心区别不在指令遵循能力，而在于是否输出前置推理块，仅需少量文本预处理代码即可抹平差距。

对于开发Agent、自动化脚本、数据解析工具的团队，无需纠结哪款模型结构化更强，可以结合推理深度、调用成本、接口速度综合选型。同时本次测试也给所有做模型评测的开发者提了醒：完整、可控、无干扰的测试环境，远比单次直观结果更有参考价值。